\n\n
\n\n
\n
\n\n
\n\nAvalanche L1s\n
\n\nDiscover how to build sovereign networks with custom rules and token economics.\n\n\n
\n\n\n\n\n\nDerivation algorithm, canonical bump, findProgramAddress examples with\ndifferent seed types.\n \n\nCreating accounts at PDA addresses, invoke_signed signing, Anchor patterns.\n \n \n## Key facts\n- **Deterministic**: The same seeds and program ID always produce the same\naddress.\n- **Off-curve**: The derived address is verified to not be a valid Ed25519\npublic key. If the hash happens to land on the curve, the derivation fails and\na different bump seed is tried.\n- **No private key**: Because the address is off-curve, no one can produce a\ncryptographic signature for it. The program \"signs\" via the runtime's\n_rs`invoke_signed`_ mechanism instead.\n## When to use PDAs\n- **Deterministic addressing**: Derive the same account from the same seeds\nevery time.\n- **Program signing**: Only the owning program can sign via _rs`invoke_signed`_,\nenabling programs to act as autonomous authorities.\n- **User-scoped state**: Derive per-user accounts from user pubkey seeds (e.g.,\n`[\"user\", user_pubkey]`).\n- **No keypair management**: No private key to store or lose. The address is\nderived purely from seeds.\n## Limits\n| Limit | Value | Source |\n| -------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |\n| Max seeds | 16 | [`MAX_SEEDS`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/pubkey/src/lib.rs#L47) |\n| Max seed length | 32 bytes maximum per seed | [`MAX_SEED_LEN`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/pubkey/src/lib.rs#L45) |\n| Bump range | 0-255 (1 byte) | Appended as the final seed element |\n| `create_program_address` cost | 1,500 CUs | [`create_program_address_units`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L200) |\n| `find_program_address` worst-case cost | 1,500 entry + 1,500 x iterations | 1,500 on entry + 1,500 per failed bump |\n| Max PDA signers per CPI | 16 | [`MAX_SIGNERS`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/cpi.rs#L62) |"}
{"url":"https://bitcoin.org/en/how-it-works","domain":"bitcoin.org","title":"How does Bitcoin work? - Bitcoin","hash":"8c407e795dc3a95579e065a5facbc211e5425fa09ffbec8bb43aaa39c3263595","tokens":1148,"chars":4591,"crawler":"hive-genesis","verified":"exact","ts":1791111963256,"text":"Keep Bitcoin.org independent and available worldwide.\nCommunity support helps maintain and improve this open resource.\nSupport Bitcoin.org\nScan the QR code or open your Bitcoin wallet. You can optionally prefill an amount below.\nSend with Bitcoin\nBitcoin only · On-chain\nOpen in wallet\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nPrefill an amount (optional)\nBTC amount\nUSD amount\nAdd an optional wallet note\nOptional note for your wallet\n- Introduction\n- Individuals\n- Businesses\n- Developers\n- Getting started\n- How it works\n- You need to know\n- White paper\n- Resources\n- Exchanges\n- Community\n- BIPs list\n- Halving\n- Documentation\n- Vocabulary\n- Bitcoin Core\n- Innovation\n- Participate\n- Support Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Running a full node\n- Development\n- Price\n- Fees\n- FAQ\n- English\n-\n- Bahasa Indonesia\n- CatalĂ \n- Dansk\n- Deutsch\n- English\n- Español\n- Français\n- Italiano\n- Magyar\n- Nederlands\n- Polski\n- PortuguĂȘs Brasil\n- RomĂąnÄ\n- SlovenĆĄÄina\n- Srpski\n- Svenska\n-\n- TĂŒrkçe\n- ÎλληΜÎčÎșÎŹ\n- бŃлгаŃŃĐșĐž\n- Đ ŃŃŃĐșĐžĐč\n- ĐŁĐșŃĐ°ŃĐœŃŃĐșĐ°\n- ŐŐĄŐ”Ő„ÖŐ„Ő¶\n- ۧÙŰč۱ۚÙŰ©\n- Ùۧ۱۳Û\n- ŚąŚŚšŚŚȘ\n- à€čà€żà€šà„à€Šà„\n- íê”ìŽ\n- ááááá\n- æ„æŹèȘ\n- çźäœäžæ\n- çčé«äžæ\nLanguage: en\nHow does Bitcoin work?\nThis is a question often surrounded by confusion, so here's a quick explanation!\nThe basics for a new user\nAs a new user, you can get started with Bitcoin without understanding the technical details. Once you've installed a Bitcoin wallet on your computer or mobile phone, it will generate your first Bitcoin address and you can create more whenever you need one. You can disclose your addresses to your friends so that they can pay you or vice versa. In fact, this is pretty similar to how email works, except that Bitcoin addresses should be used only once.\nBalances - blockchain\nThe blockchain is a shared public ledger that the entire Bitcoin network relies on. All confirmed transactions are recorded in it, which lets wallets calculate their spendable balance and lets the network verify that the sender is authorized to spend those coins. The integrity and chronological order of the blockchain are protected by cryptography .\nTransactions - private keys\nA transaction is a transfer of value between Bitcoin wallets that gets recorded in the blockchain. Bitcoin wallets keep a secret piece of data called a private key , which is used to sign transactions, providing a mathematical proof that they came from the owner of the wallet. The signature also prevents the transaction from being altered by anybody after it has been issued. All transactions are broadcast to the network and usually receive their first confirmation within about 10 to 60 minutes, through a process called mining .\nProcessing - mining\nMining is a distributed consensus system that is used to confirm pending transactions by including them in the blockchain. It enforces a chronological order, protects the neutrality of the network, and allows different computers to agree on the state of the system. To be confirmed, transactions must be packed into a block that follows very strict cryptographic rules verified by the network. These rules prevent earlier blocks from being changed, because doing so would invalidate every block that comes after. Mining also works like a competitive lottery that makes it difficult for any single participant to keep adding new blocks one after another. This is what keeps any group or individual from controlling what goes into the blockchain, or rewriting past parts of it to reverse their own spending.\nGoing down the rabbit hole\nThis is just a short summary of Bitcoin. If you want to learn more of the details, you can read the original paper that describes its design, the developer documentation , or explore the Bitcoin wiki .\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroduction:\n-\nIndividuals\n-\nBusinesses\n-\nDevelopers\n-\nGetting started\n-\nHow it works\n-\nYou need to know\n-\nWhite paper\nResources:\n-\nResources\n-\nExchanges\n-\nCommunity\n-\nBIPs list\n-\nHalving\n-\nDocumentation\n-\nVocabulary\n-\nBitcoin Core\nParticipate:\n-\nSupport Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nRunning a full node\n-\nDevelopment\nOther:\nPrice\nFees\nAvoid Scams\nLegal\nPrivacy Policy\nPress\nAbout bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Released under the MIT license\nNetwork Status\n- English\n-\n- Bahasa Indonesia\n- CatalĂ \n- Dansk\n- Deutsch\n- English\n- Español\n- Français\n- Italiano\n- Magyar\n- Nederlands\n- Polski\n- PortuguĂȘs Brasil\n- RomĂąnÄ\n- SlovenĆĄÄina\n- Srpski\n- Svenska\n-\n- TĂŒrkçe\n- ÎλληΜÎčÎșÎŹ\n- бŃлгаŃŃĐșĐž\n- Đ ŃŃŃĐșĐžĐč\n- ĐŁĐșŃĐ°ŃĐœŃŃĐșĐ°\n- ŐŐĄŐ”Ő„ÖŐ„Ő¶\n- ۧÙŰč۱ۚÙŰ©\n- Ùۧ۱۳Û\n- ŚąŚŚšŚŚȘ\n- à€čà€żà€šà„à€Šà„\n- íê”ìŽ\n- ááááá\n- æ„æŹèȘ\n- çźäœäžæ\n- çčé«äžæ\nen"}
{"url":"https://docs.optimism.io/","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"896ea3947522cac643fdfdac031ea4799760bca0a1bcf0faea43c62f85e64ef6","tokens":437,"chars":1745,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111965289,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOptimism Documentation home page\nGet Started\nChain Operators\nNode Operators\nApp Developers\nProtocol\nOP Mainnet\nGovernance\nNotices\nStart here\nOP Stack documentation\nBuild apps on the OP Stack, deploy your own OP Stack chain, run a node, or learn how the protocol works.\nStart building Deploy a chain\nFind your path\nApp developers\nBuild and deploy apps on OP Mainnet and other OP Stack chains. Deploy your first contract, bridge ETH to a testnet, and explore interop.\nChain operators\nLaunch and operate your own OP Stack chain. Deploy the L1 contracts, spin up a sequencer, and run the full stack of services.\nNode operators\nRun a node on OP Mainnet or any OP Stack chain. Docker-based setups, source builds, monitoring, and troubleshooting.\nProtocol learners & contributors\nUnderstand how the OP Stack works - from transaction flow to fault proofs, interop, and more.\nJump straight to a goal\n- Deploy your first smart contract â Deploy a contract to OP Sepolia\n- Bridge ETH or tokens between L1 and L2 â Bridging basics\n- Launch an L2 rollup testnet end to end â Create your own L2 rollup\n- Run an OP Mainnet node with Docker â Running a node with Docker\n- Understand fault proofs â Fault proofs explainer\n- Build cross-chain apps with interop â Interoperability explainer\nReady to go further?\nLaunching a chain for your organization?\nCompare running the stack yourself with OP Enterpriseâs managed and supported options. Either way, these docs are the reference for what your chain runs.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ethena.fi/","domain":"docs.ethena.fi","title":"Ethena Overview | Ethena","hash":"e4719b15ce9c2875e8ee9060faaba0ad23ed3509848165b62cc182bd40cbea6f","tokens":1328,"chars":5312,"crawler":"hive-genesis","verified":"unchecked","ts":1791111965090,"text":"â Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nEthena Overview\n//Enabling Internet Money\nEthena's USDe is not the same as a fiat stablecoin like USDC or USDT. USDe is a synthetic dollar, backed with crypto assets and corresponding short futures positions.\nThis means that the risks implicated by interacting with USDe are inherently different.\nPlease refer to our extensive Risk s section for more information.\nOverview\nEthena is a synthetic dollar protocol built on crypto rails, issuing USDe - a dollar-denominated digital asset - alongside sUSDe, the protocol's autonomously and permissionlessly created globally accessible savings asset.\nUSDe is designed around four principles that together define a superior product for holders of digital dollars:\n-\nCapital efficiency\n-\nIndustry leading ecosystem rewards\n-\nResilience across market cycles\n-\nInfrastructure to capture every available source of dollar returns within reserve assets\nCapital efficiency\nEach unit of USDe is backed by assets held by the protocol. Virtually every dollar of backing remains productive, generating revenue through the strategies described below, and USDe scales without the onerous collateral buffers required by other decentralised stablecoin designs. Capital efficiency at the protocol level translates directly into rewards available to the ecosystem.\nIndustry-leading ecosystem rewards\nRevenue earned on the backing of USDe is utilized in promotional and incentive programs, including sUSDe (which is maintained by a subsidiary of the Ethena Foundation)and certain partner reward programs on partner exchanges, platforms, or protocols. That revenue is generated from a diversified set of strategies, including:\n-\nFunding rates on delta-neutral basis trades in crypto perpetual and futures markets;\n-\nFunding rates on delta-neutral basis trades in non-crypto markets;\n-\nLending revenue from overcollateralised on-chain DeFi lending markets;\n-\nLending revenue from overcollateralised loans to institutional counterparties;\n-\nRewards on tokenised real-world assets, including short-duration government debt and high-liquidity credit;\n-\nRewards on liquid stablecoin holdings where applicable.\nResilience across market cycles\nEach strategy responds to a different driver. Crypto funding rates reflect leverage demand in digital asset markets. Non-crypto funding rates reflect demand for leverage in commodities and other markets. Lending revenue reflects borrowing demand in DeFi and at institutional venues. Real-world asset returns reflect rates in traditional fixed income.\nThese drivers are largely uncorrelated, which means weakness in any one source can be offset by strength in others. That diversification across revenue sources mitigates risk across the entire protocol.\nThe backing portfolio is also dynamic. The protocol can shift weight between strategies as conditions evolve, subject to governance and Risk Committee review. In periods when crypto funding rates compress, the portfolio can lean into lending, real-world assets, and non-crypto basis to mitigate associated risks while being revenue positive. When leverage demand in crypto markets accelerates and perpetual funding rises, the portfolio can shift weight back towards crypto basis trades to capture that opportunity at scale - the only protocol in the industry that has the infrastructure set up to do so.\nPositioned to capture every available source of dollar returns\nAccessing this full set of strategies requires infrastructure that few protocols possess: off-exchange custody with multiple regulated providers, direct relationships with the deepest crypto and commodity derivatives venues, onboarded counterparties for institutional lending, integrations with leading tokenised real-world asset issuers, and exposure into curated DeFi lending markets - all governed by a Risk Committee setting consistent exposure limits across categories.\nEthena has built this infrastructure since launch and is operating it at the scale required to make each category of backing materially additive to USDeâs resilience and profile.\nWebsite: https://ethena.fi/\nTelegram: https://t.me/ethena_labs\nDiscord: https://discord.com/invite/cepXWnXHaa\nX: https://x.com/ethena\nLinkedIn: https://www.linkedin.com/company/ethena-labs/\nThe acquisition of sUSDe is not offered to persons with their habitual residence or registered office in the European Union or the European Economic Area.\nQuick Links\nEthena FAQs | Notion ethena on Notion\nHow to Buy USDe\nUsers are currently able to:\n-\nPermissionless Acquire USDe. Access external AMM pools to acquire or dispose of USDe with assets such as USDT or USDC.\n-\nDirect Mint USDe . Transfer accepted reserve assets and receive USDe, subject to clearing KYC/KYB checks exclusively for approved market making counterparties . See Supplemental USDe Terms and Conditions.\n-\nDirect Redeem USDe . Burn USDe & receive backing assets , subject to clearing KYC/KYB checks exclusively for approved market making counterparties . See Supplemental USDe Terms and Conditions.\n-\nStake & Unstake USDe . Receive rewards from protocol revenue. Available exclusively for users in permitted jurisdictions.\nLast updated 1 month ago\nWas this helpful?\n- Overview\n- Quick Links\nWas this helpful?"}
{"url":"https://solana.com/docs/core/transactions","domain":"solana.com","title":"","hash":"638e58ef5223351ab022ddbad9233d29eb14bf5c668f0a43ddc617ff7cceecf3","tokens":962,"chars":3846,"crawler":"hive-genesis","verified":"unchecked","ts":1791111966851,"text":"---\ntitle: Transactions\ndescription:\nSolana transactions are the atomic unit of network interaction, containing\nsignatures and a message with instructions. Transaction structure, blockhash\nexpiry, versioned transactions, and durable nonces.\nurl: /docs/core/transactions\ntype: conceptual\nprerequisites:\n- /docs/core/accounts\n- /docs/core/instructions\nrelated:\n- /docs/core/transactions/transaction-structure\n- /docs/core/transactions/versioned-transactions\n- /docs/core/fees\n- /docs/tools/production-readiness\n---\nA transaction includes one or more [instructions](/docs/core/instructions), the\nsignatures of accounts that authorize the changes, and a recent blockhash. The\nnetwork processes all instructions in a transaction together. If any instruction\nfails, the entire transaction fails and all state changes are reverted.\n\n\n\nSignatures, message format (header, account addresses, blockhash, compiled\ninstructions), binary encoding, size budget, and a SOL transfer example.\n\n\nLegacy vs V0 format, Address Lookup Tables, ALT resolution, and version\ncomparison.\n\n\nFull 8-stage processing pipeline (receive through commit), reading\ntransaction details from the network, and validation error reference.\n\n\nOffline signing with durable nonces, nonce lifecycle, detection, validation\nflow, and failure behavior.\n \n\nConfigure transaction landing, retries, priority fees, and confirmation for\nmainnet applications.\n \n \n## Key facts\n- **Atomic execution**: All instructions succeed or all revert. Fees are still\ncharged on failure.\n- **Size limit**: 1,232 bytes maximum, derived from the IPv6 minimum MTU (1,280\nbytes) minus 48 bytes for network headers. The\n[v1 format](/docs/core/transactions/versioned-transactions#v1-format) raises\nthis to 4,096 bytes.\n- **Signatures**: Each signer provides one 64-byte Ed25519 signature.\n- **Blockhash expiry**: A transaction's recent blockhash is valid for 150 slots.\n## Limits\n| Limit | Value | Source |\n| ---------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Max transaction size | 1,232 bytes | [`PACKET_DATA_SIZE`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/packet/src/lib.rs#L32) |\n| Max accounts per transaction | 64 | [Enforced limit](https://github.com/anza-xyz/agave/blob/v3.1.8/runtime/src/bank.rs#L2942) (128 when [`increase_tx_account_lock_limit`](https://github.com/anza-xyz/agave/blob/v3.1.8/feature-set/src/lib.rs#L1652) is activated, currently inactive) |\n| Blockhash expiry | 150 slots | [`MAX_PROCESSING_AGE`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/clock/src/lib.rs#L133) |\n| Signature size | 64 bytes (Ed25519) | -- |\n| Base fee per signature | 5,000 lamports | [Fees](/docs/core/fees/fee-structure#base-fee) |\n| Max executed instructions | 64 (top-level + CPIs) | [`MAX_INSTRUCTION_TRACE_LENGTH`](https://github.com/anza-xyz/agave/blob/v3.1.8/transaction-context/src/lib.rs#L41) |\n| Max signatures per packet | 12 | [`MAX_SIGNATURES_PER_PACKET`](https://github.com/anza-xyz/agave/blob/v3.1.8/transaction-view/src/signature_frame.rs#L18) |"}
{"url":"https://docs.monad.xyz/","domain":"docs.monad.xyz","title":"Introduction - Monad Documentation","hash":"d77ac3cdc585eced57fec68175a545414df397bb3e6a25584887a6efdb018f58","tokens":730,"chars":2920,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111967010,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nMonad Documentation home page\nDocumentation\nLearn\nNode Operations\nIntroduction\nMonad is a Layer-1 blockchain delivering high performance, true decentralization, and EVM compatibility.\nQuick hits\n- Network Information\n- Deployment Summary for Developers\n- Guide for Node Operators\nMonad is a Layer-1 blockchain delivering high performance, true decentralization, and EVM\ncompatibility.\nMonadâs north star is making decentralization more powerful, and eliminating the perceived\ntradeoff between decentralization and performance.\nMonad supports a large globally distributed network\n(see the validator map ), with intentionally minimal\nhardware requirements so that anyone may run a node.\nPerformance comes from software architecture improvements rather than reliance on heavy hardware\nor node colocation.\nMonadâs codebase is fully open source ( consensus ,\nexecution ) and is built for extreme performance in\nC++ and rust.\nMonad introduces novel architectures in five major areas:\n- MonadBFT , a frontier BFT consensus mechanism solving the\ntail-forking problem\n- RaptorCast for efficient block transmission\n- Asynchronous Execution for pipelining\nconsensus and execution to raise the time budget for execution\n- Parallel Execution and JIT Compilation for efficient transaction\nexecution\n- MonadDb for efficient storage of Ethereum state\nMonadâs improvements address existing bottlenecks while preserving seamless compatibility for\napplication developers (full EVM bytecode compatibility) and users (Ethereum\nRPC API compatibility).\nThe result is an Ethereum-compatible Layer-1 blockchain with 10,000 tps of throughput,\n300ms block frequency, and 600ms finality.\nSelect a level of detail by visiting either Monad for Users or\nMonad for Developers .\nDeploying on Monad\nSee Deployment Summary for Developers for everything you need to\nknow as a developer deploying on Monad.\nMonad features first-class support for many leading Ethereum developer tools and infra providers.\nSee Tooling and Infrastructure for a summary.\nArchitecture\nMonad is designed with a focus on performance and scalability with commodity hardware.\nThe subsequent pages survey the major architectural changes in Monad as well as the\ninterface for users.\nThe first Monad client is built by\nCategory Labs and is written from scratch in C++ and Rust.\nmonad-bft , Category Labsâs implementation of\na Monad consensus client, and\nmonad , Category Labsâs implementation of a Monad\nexecution client, are both open-source under GPL-3.0 .\nMainnet\nPublic mainnet launched on Nov 24, 2025.\nSee Network Information for access, or check out the\nMonadVision block explorer, the gmonads.com\nnetwork visualization, or app.monad.xyz .\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.optimism.io/chain-operators","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"144312629cbe151bcbabb6700ae25bc1c72ec38df68664b3f9c560e6a17e1dbe","tokens":358,"chars":1429,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111968812,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOptimism Documentation home page\nGet Started\nChain Operators\nNode Operators\nApp Developers\nProtocol\nOP Mainnet\nGovernance\nNotices\nLaunch a chain\nChain operators\nRoutes chain operators to the quickstart, guides, tutorials, tools, and reference for launching and running an OP Stack chain.\nYou are launching or operating your own OP Stack chain. Deploy first, then\nuse the guides, tools, and reference material to run it in production.\nDeploy a chain\nLaunch your first OP Stack chain with op-deployer.\nConfigure and manage your chain\nSet up the batcher, proposer, and challenger, enable features, and follow\nproduction best practices.\nWork through a tutorial\nBuild a rollup component by component, upgrade L1 contracts, and\ncustomize your chain step by step.\nRun the supporting tools\nOperate op-deployer, op-conductor, chain monitoring, and the RPC\nfrontends that keep a chain healthy.\nLook up configuration reference\nCheck flag-level reference for the batcher, challenger, deployment\nconfiguration, and fee parameters.\nNot running your own chain?\nRoute by role from the documentation home: app developers, node\noperators, and protocol learners each have their own section.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://ethereum-magicians.org/latest","domain":"ethereum-magicians.org","title":"Latest topics - Fellowship of Ethereum Magicians","hash":"8c0de6a90fe218c94e255d677b7813b03961b0dc4a9a0bbec112974458e7f4a9","tokens":725,"chars":2900,"crawler":"hive-genesis","verified":"unchecked","ts":1791111969374,"text":"Fellowship of Ethereum Magicians\nTopic\nReplies\nViews\nActivity\nEIP-8425: Quantum Freeze and Account Recovery\nEIPs\nevm\n18\n218\nOctober 4, 2026\n[Research] Steganographic Point Obfuscation via Inverse 2-Isogenies for BLS12 Curves (DPI Censorship Resistance)\ncryptography\n4\n35\nOctober 4, 2026\nSealed-Bid Award Mechanism for Task Tenders (companion to ERC-8183 / 8195 / 8414)\nERCs\nagentic-commerce\n,\nerc\n,\nacution\n3\n38\nOctober 4, 2026\nEIP-TBD: Resolution â Non-Self-Authorizing State Transitions\nEIPs informational\n3\n35\nOctober 4, 2026\n[Draft ERC] Agent Collective Decision Framework (ACDF) â authorized, composable collective decisions with procedural finality\nERCs\nagents\n,\nerc\n0\n35\nOctober 4, 2026\nEIP-2537 (BLS12 precompile) discussion thread\nEIPs core\nprecompile\n,\ncore-eips\n,\nshanghai-candidate\n90\n42976\nOctober 3, 2026\nAll Core Devs - Consensus (ACDC) #189, October 15, 2026\nProtocol Calls & happenings\n0\n16\nOctober 3, 2026\nEIP-7976: Further increase calldata cost\nEIPs\n6\n218\nOctober 2, 2026\nERC-8004: Trustless Agents\nERCs\n391\n19902\nOctober 2, 2026\nEIP-8429: Escalating gas for repeated calls\nEIPs\n13\n126\nOctober 2, 2026\nERC-8414: Token-Bound Task Tenders\nERCs\nnft\n,\nerc\n,\nagent\n,\nagents\n20\n328\nOctober 2, 2026\nERC-8434: Agent Identity (AID)\nERCs\nagents\n,\nidentity\n,\nerc\n9\n98\nOctober 2, 2026\n[Pre-ERC Discussion] A Common Interface for RWA Disclosure Records, Evidence, and History\nERCs\nrwa\n,\nerc\n,\ntoken\n10\n247\nOctober 2, 2026\nERC-7579: Minimal Modular Smart Accounts\nERCs\n30\n5582\nOctober 2, 2026\nEIP-8061: Increase churn limits\nEIPs core\n3\n182\nOctober 2, 2026\nEIP-8430: AA Transaction Type (Split out from 8130)\n5\n68\nOctober 2, 2026\nAll Core Devs - Consensus (ACDC) #188, October 1, 2026\nProtocol Calls & happenings\nacd\n,\nacdc\n3\n68\nOctober 1, 2026\nERC-8421: Frame Transaction Alternative Mempools\nERCs\naccount-abstraction\n,\nmempool\n,\nprivacy\n2\n63\nOctober 1, 2026\nERC-8426: Wallet Pass Extension for NFTs\nERCs\n14\n192\nOctober 1, 2026\nEIP-8363: Tapered Issuance Burn\nEIPs core\n223\n11139\nOctober 1, 2026\nERC-8427: Portable Spend Grants\nERCs\nagents\n,\neip-712\n,\neip-7702\n,\naccount-abstraction\n,\nai-agents\n6\n106\nOctober 1, 2026\nEIP-8148: Custom sweep threshold for validators\nEIPs core\nhegota\n19\n650\nOctober 1, 2026\nMascot needed for HegotĂĄ upgrade\nPrimordial Soup\nnaming\n,\nhegota\n12\n254\nOctober 1, 2026\nERC-8419: Know-Your-Agent (KYA) Framework\nERCs\nidentity\n,\nai-agents\n,\nerc\n,\nzk\n,\nagents\n17\n261\nOctober 1, 2026\nERC-8416: Epoch-Based Fixed-Rate Vault\nERCs\n10\n244\nSeptember 30, 2026\nERC-8195: Task Market Protocol\nERCs\n8\n390\nSeptember 30, 2026\nERC-8183: Agentic Commerce\nERCs\npayments\n,\nagents\n,\nescrow\n410\n7158\nSeptember 30, 2026\nEIP-8288: Frame type for PQ sig and STARK aggregation\nEIPs\n11\n1029\nSeptember 30, 2026\nPost Quantum transaction signature (PQTS) Breakout #16\nProtocol Calls & happenings\n2\n28\nSeptember 30, 2026\nEIP-8433: Retire 0x00 validators\nEIPs core\n1\n32\nSeptember 30, 2026\nnext page â"}
{"url":"https://docs.phantom.com/phantom-mcp-server","domain":"docs.phantom.com","title":"Phantom MCP server - Phantom developer documentation","hash":"35cd018242aad07fc4d59871b7df827d5320ee625d34cf7f8a08b608eeccfec7","tokens":1268,"chars":5070,"crawler":"hive-genesis","verified":"unchecked","ts":1791111970766,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPhantom developer documentation home page\nGet started\nPhantom MCP server\nPhantom CLI\nPhantom Portal\nPhantom Connect SDKs\nRecipes\nDeveloper tools and resources\nOverview\nPhantom MCP server\nThe Phantom MCP server gives AI agents a wallet. Sign transactions, transfer tokens, and interact on-chain across Solana and EVM chains.\nThe 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.\nAgent wallets and your existing accounts\nWhy your agent gets a new wallet when you sign in, and how to access your existing Phantom accounts.\nWhat are you here for?\nSet up the MCP server\nAdd the Phantom MCP server to Claude Desktop, Cursor, or Claude Code and get a wallet for your AI agent.\nUse it with OpenClaw\nInstall the Phantom OpenClaw plugin to bring the same Phantom wallet capabilities directly into OpenClaw.\nQuick 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}\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.\nWhat 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\nTool Description\nget_connection_status Check if the wallet session is active\nget_wallet_addresses Get addresses for Solana, Ethereum, Bitcoin, and Sui. Sui address support has been deprecated.\nget_token_balances View token holdings with live USD pricing\ntransfer_tokens Transfer SOL, ETH, and SPL/ERC-20 tokens with a simulation-first flow\nsend_solana_transaction Simulate, sign, and broadcast Solana transactions\nsend_evm_transaction Simulate, sign, and broadcast EVM transactions\nsign_solana_message Sign UTF-8 messages on Solana\nsign_evm_personal_message EIP-191 personal message signing\nsign_evm_typed_data EIP-712 structured data signing\nsimulate_transaction Preview asset changes for a transaction without submitting on-chain\nget_token_allowance Check ERC-20 token allowance for a spender address\nphantom_login Re-authenticate, switch accounts, or refresh a session\npay_api_access Pay for daily API access when quota is consumed\nSwaps and portfolio\nTool Description\nbuy_token Swap tokens via Phantom routing (Solana, EVM, cross-chain). No fees on swaps.\nportfolio_rebalance Analyze and rebalance portfolio allocation via token swaps\nPerps\nTool Description\nget_perp_markets List perp markets with price, funding, open interest, and max leverage\nget_perp_account View perp account balance and available margin\nget_perp_positions List open positions, leverage, PnL, and liquidation price\nget_perp_orders List open perp orders\nget_perp_trade_history View historical fills, fees, and closed PnL\ndeposit_to_hyperliquid Bridge/swap into the perp account\nopen_perp_position Open a long or short perp position\nclose_perp_position Close a perp position fully or partially\ncancel_perp_order Cancel an open perp order\nupdate_perp_leverage Update leverage and margin mode\ntransfer_spot_to_perps Move USDC from Hypercore spot to perps\nwithdraw_from_perps Bridge USDC from perps directly to an external chain\nPerps tools guide\nHyperliquid-specific funding, trading, and withdrawal flow for the Phantom MCP server.\nSupported clients\nClient How to connect\nClaude Desktop Add to claude_desktop_config.json\nCursor Add to ~/.cursor/mcp.json (or use the Phantom Cursor plugin )\nClaude Code claude mcp add phantom -- npx -y @phantom/mcp-server@latest\nHow 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.\nHow Phantom KMS works\nLearn how KMS handles key storage and signing for agent wallets.\nRelated\nPhantom Connect SDKs\nBuild apps with embedded wallets and social login for traditional user flows.\nPhantom Connect SDK MCP server\nGive your AI coding assistant access to Phantom developer documentation.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.marginfi.com/","domain":"docs.marginfi.com","title":"Project 0 Documentation","hash":"bc575a29b2fa965ad7d31e4a7a4a340242b29e88db7423c4d86da4965a5bebc1","tokens":250,"chars":1000,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111970631,"text":"Learn about the first DeFi native prime broker on Solana.\nWelcome to the documentation for Project 0 (P0), a permissionless prime broker built on Solana. This site provides an accessible overview of the protocol alongside enough technical depth to satisfy experienced builders and integrators.\nP0 is built on mrgnLendv2 , a battle-tested borrow-lending program with a powerful on-chain risk engine. P0 extends this foundation with cross-venue collateral, enabling users to collateralize assets from multiple DeFi venues and borrow against them in a single unified margin account.\nGet Started\nIntroduction\nWhat P0 is, how it works, and why permissionless prime brokerage matters.\nProtocol Overview\nDive into the protocol's architecture, risk engine, interest rates, liquidation mechanics, and more.\nTypeScript SDK\nStart building with the official P0 SDK. Deposit, borrow, and manage accounts programmatically.\nGuides\nStep-by-step guides for users, developers, and liquidators.\nOn this page\nGet Started"}
{"url":"https://developers.uniswap.org/docs","domain":"developers.uniswap.org","title":"Docs | Uniswap Developers","hash":"47b255c73b03c6fcd7d0265de32caa6b27e9694b5f29708c5636c36612b0f414","tokens":200,"chars":800,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111972680,"text":"LLMs.txt: agent-readable Markdown index of this site at /llms.txt\nDevelopers\nDocs API Reference\nAPI keys\nUniswap\nDocumentation\nIntegrate swaps, manage liquidity, launch tokens and more with AI-friendly DeFi tooling.\nQuick start Agent skills\nQuick Start\nnpx skills add uniswap/uniswap-ai --skill swap-integration\nGuides\nSwap tokens\nAdd swaps to your app\nManage liquidity\nEarn fees programmatically\nCreate a hook\nDefine custom logic for pools\nLaunch a token\nBootstrap liquidity\nBecome a filler\nFill swaps via UniswapX\nUse cases\nIntegration methods\nAPI\nGet started in minutes\nTypeScript SDK\nAdd a custom integration\nProtocols\nBuild directly onchain\nResources\nGitHub\nBlog\nCommunity\nTry the Uniswap API\nCreate an account in seconds, get your free API keys, and help build the future of DeFi.\nGet your keys"}
{"url":"https://aave.com/docs","domain":"aave.com","title":"Aave Protocol Overview","hash":"b79c5985a8db1e8c92cd7347ac34c522f1435cdcc4d159ea70d09b27ff1d01aa","tokens":355,"chars":1420,"crawler":"hive-genesis","verified":"unchecked","ts":1791111972650,"text":"Docs\nAave Documentation # Copy\nAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.\nThese docs cover the protocol end to end: concepts and risk parameters, the AaveKit SDKs (React, TypeScript, GraphQL), smart contract references for v3 and v4, GHO, governance, and integration guides. Every page is also available as markdown for agents and tooling: append .md to any URL, or send an Accept: text/markdown header.\nGet Familiar with Aave # Copy\nAave 101\nLearn the basics.\nAave v3\nLearn about the Aave v3.\nAave v4\nLearn about Aave v4.\nAave Horizon\nBorrow stablecoins with RWAs.\nGHO\nLearn about the GHO stablecoin.\nSafety # Copy\nUmbrella\nNative coverage for bad debt.\nSecurity\nSecurity resources and audits.\nIntegrate Aave # Copy\nMarkets\nEarn by supplying assets.\nVaults\nEarn interest on assets.\nQuickstart # Copy\n- Market Data\n- Supply Positions\n- Borrow Positions\n- Supply\nimport { useAaveMarkets , chainId } from \"@aave/react\" ;\nconst { data , loading , error } = useAaveMarkets ( { chainIds : [ chainId ( 1 ) , chainId ( 8453 ) ] , // Ethereum, Base } ) ;\nReact\nTypeScript\nGraphQL\nQuick Links # Copy\nAddresses\nProtocol smart addresses.\nParameters\nView market parameters.\nBuilding On Aave\nNext\nAave 101"}
{"url":"https://raw.githubusercontent.com/Uniswap/v4-core/main/README.md","domain":"raw.githubusercontent.com","title":"Uniswap v4 Core","hash":"226257af46a055f0cd5b5e73386e97a2d44e47ccc61e28198bbd1357efb9a4f0","tokens":1045,"chars":4180,"crawler":"hive-genesis","verified":"unchecked","ts":1791111974155,"text":"# Uniswap v4 Core\n[](https://github.com/Uniswap/v4-core/actions/workflows/lint.yml)\n[](https://github.com/Uniswap/v4-core/actions/workflows/tests-merge.yml)\nUniswap v4 is a new automated market maker protocol that provides extensible and customizable pools. `v4-core` hosts the core pool logic for creating pools and executing pool actions like swapping and providing liquidity.\nThe contracts in this repo are in early stages - we are releasing the draft code now so that v4 can be built in public, with open feedback and meaningful community contribution. We expect this will be a months-long process, and we appreciate any kind of contribution, no matter how small.\n## Contributing\nIf youâre interested in contributing please see our [contribution guidelines](./CONTRIBUTING.md)!\n## Whitepaper\nA more detailed description of Uniswap v4 Core can be found in the draft of the [Uniswap v4 Core Whitepaper](./docs/whitepaper/whitepaper-v4.pdf).\n## Architecture\n`v4-core` uses a singleton-style architecture, where all pool state is managed in the `PoolManager.sol` contract. Pool actions can be taken after an initial call to `unlock`. Integrators implement the `unlockCallback` and proceed with any of the following actions on the pools:\n- `swap`\n- `modifyLiquidity`\n- `donate`\n- `take`\n- `settle`\n- `mint`\n- `burn`\nNote that pool initialization can happen outside the context of unlocking the PoolManager.\nOnly the net balances owed to the user (positive) or to the pool (negative) are tracked throughout the duration of an unlock. This is the `delta` field held in the unlock state. Any number of actions can be run on the pools, as long as the deltas accumulated during the unlock reach 0 by the unlockâs release. This unlock and call style architecture gives callers maximum flexibility in integrating with the core code.\nAdditionally, a pool may be initialized with a hook contract, that can implement any of the following callbacks in the lifecycle of pool actions:\n- {before,after}Initialize\n- {before,after}AddLiquidity\n- {before,after}RemoveLiquidity\n- {before,after}Swap\n- {before,after}Donate\nThe callback logic, may be updated by the hooks dependent on their implementation. However _which_ callbacks are executed on a pool cannot change after pool initialization.\n## Repository Structure\nAll contracts are held within the `v4-core/src` folder.\nNote that helper contracts used by tests are held in the `v4-core/src/test` subfolder within the `src` folder. Any new test helper contracts should be added here, but all foundry tests are in the `v4-core/test` folder.\n```markdown\nsrc/\n----interfaces/\n| IPoolManager.sol\n| ...\n----libraries/\n| Position.sol\n| Pool.sol\n| ...\n----test\n----PoolManager.sol\n...\ntest/\n----libraries/\n| Position.t.sol\n| Pool.t.sol\n```\n## Local deployment and Usage\nTo utilize the contracts and deploy to a local testnet, you can install the code in your repo with forge:\n```markdown\nforge install https://github.com/Uniswap/v4-core\n```\nTo integrate with the contracts, the interfaces are available to use:\n```solidity\nimport {IPoolManager} from 'v4-core/contracts/interfaces/IPoolManager.sol';\nimport {IUnlockCallback} from 'v4-core/contracts/interfaces/callback/IUnlockCallback.sol';\ncontract MyContract is IUnlockCallback {\nIPoolManager poolManager;\nfunction doSomethingWithPools() {\n// this function will call `unlockCallback` below\npoolManager.unlock(...);\n}\nfunction unlockCallback(bytes calldata data) external returns (bytes memory) {\n// disallow arbitrary caller\nif (msg.sender != address(poolManager) revert Unauthorized();\n// perform pool actions\npoolManager.swap(...)\n}\nerror Unauthorized();\n```\n## License\nUniswap V4 Core is licensed under the Business Source License 1.1 (`BUSL-1.1`), see [BUSL_LICENSE](https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE), and the MIT License (`MIT`), see [MIT_LICENSE](https://github.com/Uniswap/v4-core/blob/main/licenses/MIT_LICENSE). Each file in Uniswap V4 Core states the applicable license type in the header."}
{"url":"https://gov.uniswap.org/latest","domain":"gov.uniswap.org","title":"Uniswap Governance - Uniswap is a fully decentralized protocol for automated liquidity provision on Ethereum.","hash":"8aa0ff42acf8e7524a5562f281652d251f6026b579230ec8d2d6c78d835da247","tokens":833,"chars":3330,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111976325,"text":"Uniswap Governance\nTopic\nReplies\nViews\nActivity\nCommunity Governance Process Update [Jan 2023]\nGovernance-Meta\nOn December 21, 2022, the Uniswap community voted to simplify the community governance process (Snapshot poll here).\nThis post is a follow up to that proposal, summarizing the new governance process, and covering a listâŠ\n4\n38240\nJanuary 9, 2026\nUniswap Governance Forum Rules\nUncategorized\nThis forum is dedicated to discussions on Uniswap governance. Relevant topics include:\nGovernance Proposals\nProposal Discussions\nDelegation Pitches\nSite Feedback\nThis is not the place for:\nUNI price discussion\nGenerâŠ\n0\n16461\nSeptember 21, 2020\nUniswap Foundation Security Fund (UFSF): Announcement Thread\nUncategorized\n41\n1956\nOctober 2, 2026\n[Temp Check] Protocol Fee Expansion: Arc\nTemperature Check\n5\n456\nOctober 1, 2026\n[Temp Check] Rotate Sentinel Addresses on the DUNI-Owned Uniswap Earn Vaults\nTemperature Check\n6\n244\nOctober 1, 2026\nAxia Network Delegate Platform\nDelegation Pitch\n11\n332\nOctober 3, 2026\nUniswap-Arbitrum Delegate Program (UADP) Communication Thread\nDelegation Pitch\n39\n6001\nSeptember 29, 2026\nPGov Delegate Platform\nDelegation Pitch\n73\n6447\nSeptember 27, 2026\n[RFC] Native Execution Privacy in the Uniswap Interface via v4 Hooks and UniswapX\nRequests for Comment\n16\n702\nAugust 29, 2026\nURC-2: Custom Accounting Hook Swap Event\nURC Discussion\n1\n171\nAugust 25, 2026\n[RFC] Deploy Uniswap V3 on Gensyn\nRequests for Comment\n5\n451\nAugust 25, 2026\nUniswap Deployment - Guideline\nGovernance-Meta\n2\n930\nAugust 21, 2026\n[Temp Check] Activate v4 Protocol Fees\nTemperature Check\n24\n2776\nAugust 18, 2026\n[RFC] Web4 Autonomous State Engines on Unichain: Utilizing ERC-6551 & Sovereign ERC-721 Force Transfers for Dynamic Asset Orchestration\nRequests for Comment\n0\n94\nAugust 4, 2026\n[RFC] Four for V4\nRequests for Comment\n7\n469\nJuly 24, 2026\n[Discussion] Privacy-Preserving MiCA Compliance â How Is Uniswap Handling EU Users?\nRequests for Comment\n19\n527\nJuly 23, 2026\n$UNI staking for IL reduction\nRequests for Comment\n3\n3176\nJuly 23, 2026\nCuria Delegate Platform\nDelegation Pitch\n53\n2374\nJuly 23, 2026\n[RFC - Update] Deploy Uniswap v3 (1 / 0.3 / 0.05 / 0.01) on BNB Chain (Binance)\nRequests for Comment\n101\n45659\nJuly 22, 2026\n[Temp Check] Protocol Fee Expansion: Robinhood Chain\nTemperature Check\n3\n980\nJuly 22, 2026\nCodeknight Delegate Platform\nDelegation Pitch\n7\n270\nJuly 22, 2026\nURC-4: Active Liquidity Framework Hook Interface\nURC Discussion\n2\n208\nJuly 20, 2026\nDAOplomats Delegation Platform\nDelegation Pitch\n49\n2909\nJuly 18, 2026\nArgonaut Delegate Platform\nDelegation Pitch\n63\n1810\nJuly 11, 2026\nRFC : Tokenomics overhaul : hard-capping supply via auto burn, pivoting unification to staking distribution and staking DAO treasury reserves\nUncategorized\n3\n298\nJuly 10, 2026\nAtiselsts.eth Delegate Platform\nDelegation Pitch\n32\n4667\nJuly 9, 2026\n[Temp Check] - Update Crosschain Governance Parameters for Avalanche, MegaETH, Soneium, and X Layer\nRequests for Comment\n5\n271\nJuly 9, 2026\nFoundation inspection request â Cantina bounty mediation policy enforcement (finding #784, 29-day stalled dispute)\nRequests for Comment\n0\n172\nJuly 4, 2026\nURC-3: Hook TVL and Effective Liquidity Reporting\nURC Discussion\n0\n134\nJune 30, 2026\nURC-1: Uniswap Request for Comment Process\nURC Discussion\n0\n88\nJune 29, 2026\nnext page â"}
{"url":"https://raw.githubusercontent.com/ethereum/EIPs/master/README.md","domain":"raw.githubusercontent.com","title":"Ethereum Improvement Proposals (EIPs)","hash":"44124195c04fdf9fc837b4cd0af5f8990ce9000cb27da3617715cfb4b704b750","tokens":1260,"chars":5039,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111977809,"text":"# Ethereum Improvement Proposals (EIPs)\n> **_ATTENTION_**: The EIPs repository has recently [undergone](https://github.com/ethereum/EIPs/pull/7206) a separation of ERCs and EIPs. ERCs are now accessible at [https://github.com/ethereum/ercs](https://github.com/ethereum/ercs). All new ERCs and updates to existing ones must be directed at this new repository. The editors apologize for this inconvenience.\nThe goal of the EIP project is to standardize and provide high-quality documentation for Ethereum itself and conventions built upon it. This repository tracks past and ongoing improvements to Ethereum in the form of Ethereum Improvement Proposals (EIPs). [EIP-1](https://eips.ethereum.org/EIPS/eip-1) governs how EIPs are published.\nThe [status page](https://eips.ethereum.org/) tracks and lists EIPs, which can be divided into the following categories:\n- [Core EIPs](https://eips.ethereum.org/core) are improvements to the Ethereum consensus protocol.\n- [Networking EIPs](https://eips.ethereum.org/networking) specify the peer-to-peer networking layer of Ethereum.\n- [Interface EIPs](https://eips.ethereum.org/interface) standardize interfaces to Ethereum, which determine how users and applications interact with the blockchain.\n- [ERCs](https://eips.ethereum.org/erc) specify application layer standards, which determine how applications running on Ethereum can interact with each other.\n- [Meta EIPs](https://eips.ethereum.org/meta) are miscellaneous improvements that nonetheless require some sort of consensus.\n- [Informational EIPs](https://eips.ethereum.org/informational) are non-standard improvements that do not require any form of consensus.\n**Before you write an EIP, ideas MUST be thoroughly discussed on [Ethereum Magicians](https://ethereum-magicians.org/) or [Ethereum Research](https://ethresear.ch/t/read-this-before-posting/8). Once consensus is reached, thoroughly read and review [EIP-1](https://eips.ethereum.org/EIPS/eip-1), which describes the EIP process.**\nPlease note that this repository is for documenting standards and not for help implementing them. These types of inquiries should be directed to the [Ethereum Stack Exchange](https://ethereum.stackexchange.com). For specific questions and concerns regarding EIPs, it's best to comment on the relevant discussion thread of the EIP denoted by the `discussions-to` tag in the EIP's preamble.\nIf you would like to become an EIP Editor, please read [EIP-5069](./EIPS/eip-5069.md).\n## Preferred Citation Format\nThe canonical URL for an EIP that has achieved draft status at any point is at .\nConsider any document not published at .bin.gz .json.gz or .json (cannon-kona game type only) â OP_CHALLENGER_CANNON_KONA_PRESTATES_URL\n--cannon-kona-rollup-config Rollup chain parameters (cannon-kona game type only) â OP_CHALLENGER_CANNON_KONA_ROLLUP_CONFIG\n--cannon-kona-server Path to kona executable to use as pre-image oracle server when generating trace data (cannon-kona game type only) â OP_CHALLENGER_CANNON_KONA_SERVER\n--cannon-l1-genesis Path to the L1 genesis file. Only required if the L1 is not mainnet, sepolia, holesky, or hoodi. â OP_CHALLENGER_CANNON_L1_GENESIS\n--cannon-l2-genesis Paths to the op-geth genesis file (cannon game type only) â OP_CHALLENGER_CANNON_L2_GENESIS\n--cannon-prestate Path to absolute prestate to use when generating trace data (cannon game type only) â OP_CHALLENGER_CANNON_PRESTATE\n--cannon-prestates-url Base URL to absolute prestates to use when generating trace data. Prestates in this directory should be name as .bin.gz .json.gz or .json (cannon game type only) â OP_CHALLENGER_CANNON_PRESTATES_URL\n--cannon-rollup-config Rollup chain parameters (cannon game type only) â OP_CHALLENGER_CANNON_ROLLUP_CONFIG\n--cannon-server Path to executable to use as pre-image oracle server when generating trace data (cannon game type only) â OP_CHALLENGER_CANNON_SERVER\n--cannon-snapshot-freq Frequency of cannon snapshots to generate in VM steps (cannon game type only) 1000000000 OP_CHALLENGER_CANNON_SNAPSHOT_FREQ\n--depset-config Interop dependency set config file â OP_CHALLENGER_DEPSET_CONFIG\n--fee-limit-multiplier The multiplier applied to fee suggestions to put a hard limit on fee increases 5 OP_CHALLENGER_TXMGR_FEE_LIMIT_MULTIPLIER\n--game-allowlist List of Fault Game contract addresses the challenger is allowed to play. If empty, the challenger will play all games. â OP_CHALLENGER_GAME_ALLOWLIST\n--game-factory-address Address of the fault game factory contract. â OP_CHALLENGER_GAME_FACTORY_ADDRESS\n--game-types The game types to support. Valid options: alphabet, cannon, cannon-kona, permissioned, fast, super-cannon-kona, super-permissioned, zk \"cannon\", \"cannon-kona\" OP_CHALLENGER_GAME_TYPES\n--game-window The time window which the challenger will look for games to progress and claim bonds. This should include a buffer for the challenger to claim bonds for games outside the maximum game duration. 672h0m0s OP_CHALLENGER_GAME_WINDOW\n--hd-path The HD path used to derive the sequencer wallet from the mnemonic. The mnemonic flag must also be set. â OP_CHALLENGER_HD_PATH\n--http-poll-interval Polling interval for latest-block subscription when using an HTTP RPC provider. 12s OP_CHALLENGER_HTTP_POLL_INTERVAL\n--l1-genesis Path to the L1 genesis file. Only required if the L1 is not mainnet, sepolia, holesky, or hoodi. â OP_CHALLENGER_L1_GENESIS\n--l1-rpc-kind The kind of RPC provider, used to inform optimal transactions receipts fetching, and thus reduce costs. Valid options: alchemy, quicknode, infura, parity, nethermind, debug_geth, erigon, basic, any, standard standard OP_CHALLENGER_L1_RPC_KIND\n--l2-experimental-eth-rpc L2 Address of L2 JSON-RPC endpoint to use (eth and debug namespace required with execution witness support) (cannon game type only) â OP_CHALLENGER_L2_EXPERIMENTAL_ETH_RPC\n--l2-genesis Paths to the op-geth genesis file â OP_CHALLENGER_L2_GENESIS\n--log.color Color the log output if in terminal mode false OP_CHALLENGER_LOG_COLOR\n--log.format Format the log output. Supported formats: text, terminal, logfmt, logfmtms, json, jsonms text OP_CHALLENGER_LOG_FORMAT\n--log.level The lowest log level that will be output INFO OP_CHALLENGER_LOG_LEVEL\n--log.pid Show pid in the log false OP_CHALLENGER_LOG_PID\n--max-concurrency Maximum number of threads to use when progressing games 4 OP_CHALLENGER_MAX_CONCURRENCY\n--max-pending-tx The maximum number of pending transactions. 0 for no limit. 10 OP_CHALLENGER_MAX_PENDING_TX\n--metrics.addr Metrics listening address \"0.0.0.0\" OP_CHALLENGER_METRICS_ADDR\n--metrics.enabled Enable the metrics server false OP_CHALLENGER_METRICS_ENABLED\n--metrics.port Metrics listening port 7300 OP_CHALLENGER_METRICS_PORT\n--min-update-interval Minimum time between scheduling update cycles based on the L1 block time. 0s OP_CHALLENGER_MIN_UPDATE_INTERVAL\n--mnemonic The mnemonic used to derive the wallets for either the service â OP_CHALLENGER_MNEMONIC\n--network Predefined network selection. Available networks: every chain bundled from the superchain-registry at the release; run op-challenger --help for the exact list â OP_CHALLENGER_NETWORK\n--network-timeout Timeout for all network operations 10s OP_CHALLENGER_NETWORK_TIMEOUT\n--num-confirmations Number of confirmations which we will wait after sending a transaction 3 OP_CHALLENGER_NUM_CONFIRMATIONS\n--pprof.addr pprof listening address \"0.0.0.0\" OP_CHALLENGER_PPROF_ADDR\n--pprof.enabled Enable the pprof server false OP_CHALLENGER_PPROF_ENABLED\n--pprof.path pprof file path. If it is a directory, the path is {dir}/{profileType}.prof â OP_CHALLENGER_PPROF_PATH\n--pprof.port pprof listening port 6060 OP_CHALLENGER_PPROF_PORT\n--pprof.type pprof profile type. One of cpu, heap, goroutine, threadcreate, block, mutex, allocs â OP_CHALLENGER_PPROF_TYPE\n--prestates-url Base URL to absolute prestates to use when generating trace data. Prestates in this directory should be name as .bin.gz .json.gz or .json â OP_CHALLENGER_PRESTATES_URL\n--private-key The private key to use with the service. Must not be used with mnemonic. â OP_CHALLENGER_PRIVATE_KEY\n--response-delay Delay before responding to game actions to slow down game progression. 0s OP_CHALLENGER_RESPONSE_DELAY\n--response-delay-after Number of responses after which to start applying the delay (0 = from first response). 0 OP_CHALLENGER_RESPONSE_DELAY_AFTER\n--resubmission-timeout Duration we will wait before resubmitting a transaction to L1 24s OP_CHALLENGER_RESUBMISSION_TIMEOUT\n--rollup-config Rollup chain parameters â OP_CHALLENGER_ROLLUP_CONFIG\n--rollup-rpc HTTP provider URL for the rollup node â OP_CHALLENGER_ROLLUP_RPC\n--safe-abort-nonce-too-low-count Number of ErrNonceTooLow observations required to give up on a tx at a particular nonce without receiving confirmation 3 OP_CHALLENGER_SAFE_ABORT_NONCE_TOO_LOW_COUNT\n--selective-claim-resolution Only resolve claims for the configured claimants false OP_CHALLENGER_SELECTIVE_CLAIM_RESOLUTION\n--signer.address Address the signer is signing requests for â OP_CHALLENGER_SIGNER_ADDRESS\n--signer.endpoint Signer endpoint the client will connect to â OP_CHALLENGER_SIGNER_ENDPOINT\n--signer.header Headers to pass to the remote signer. Format key=value . Value can contain any character allowed in a HTTP header. When using env vars, split with commas. When using flags one key value pair per flag. â OP_CHALLENGER_SIGNER_HEADER\n--signer.tls.ca tls ca cert path \"tls/ca.crt\" OP_CHALLENGER_SIGNER_TLS_CA\n--signer.tls.cert tls cert path \"tls/tls.crt\" OP_CHALLENGER_SIGNER_TLS_CERT\n--signer.tls.enabled Enable or disable TLS client authentication for the signer true OP_CHALLENGER_SIGNER_TLS_ENABLED\n--signer.tls.key tls key \"tls/tls.key\" OP_CHALLENGER_SIGNER_TLS_KEY\n--super-cannon-kona-depset-config Interop dependency set config file (super-cannon-kona game type only) â OP_CHALLENGER_SUPER_CANNON_KONA_DEPSET_CONFIG\n--super-cannon-kona-l1-genesis Path to the L1 genesis file. Only required if the L1 is not mainnet, sepolia, holesky, or hoodi. â OP_CHALLENGER_SUPER_CANNON_KONA_L1_GENESIS\n--super-cannon-kona-l2-genesis Paths to the op-geth genesis file (super-cannon-kona game type only) â OP_CHALLENGER_SUPER_CANNON_KONA_L2_GENESIS\n--super-cannon-kona-prestates-url Base URL to absolute prestates to use when generating trace data. Prestates in this directory should be name as .bin.gz .json.gz or .json (super-cannon-kona game type only) â OP_CHALLENGER_SUPER_CANNON_KONA_PRESTATES_URL\n--super-cannon-kona-rollup-config Rollup chain parameters (super-cannon-kona game type only) â OP_CHALLENGER_SUPER_CANNON_KONA_ROLLUP_CONFIG\n--supernode-rpc Provider URL for supernode roots â OP_CHALLENGER_SUPERNODE_RPC\n--txmgr.already-published-custom-errs List of custom RPC error messages that indicate that a transaction has already been published. â OP_CHALLENGER_TXMGR_ALREADY_PUBLISHED_CUSTOM_ERRS\n--txmgr.cell-proof-time Enables cell proofs in blob transactions for Fusaka (EIP-7742) compatibility from the provided unix timestamp. Should be set to the L1 Fusaka time. May be left blank for Ethereum Mainnet, Sepolia, Holesky, or Hoodi L1s. 18446744073709551615 OP_CHALLENGER_TXMGR_CELL_PROOF_TIME\n--txmgr.fee-limit-threshold The minimum threshold (in GWei) at which fee bumping starts to be capped. Allows arbitrary fee bumps below this threshold. 100 OP_CHALLENGER_TXMGR_FEE_LIMIT_THRESHOLD\n--txmgr.max-basefee Enforces a maximum base fee (in GWei) to assume when determining tx fees, TxMgr returns an error when exceeded. Disabled by default. 0 OP_CHALLENGER_TXMGR_MAX_BASEFEE\n--txmgr.max-retries Maximum number of times to resubmit a transaction to L1 on a transient error. Set to 0 to disable retries. 10 OP_CHALLENGER_TXMGR_MAX_RETRIES\n--txmgr.max-tip-cap Enforces a maximum tip cap (in GWei) to use when determining tx fees, TxMgr returns an error when exceeded. Disabled by default. 0 OP_CHALLENGER_TXMGR_MAX_TIP_CAP\n--txmgr.min-basefee Enforces a minimum base fee (in GWei) to assume when determining tx fees. 1 GWei by default. 1 OP_CHALLENGER_TXMGR_MIN_BASEFEE\n--txmgr.min-tip-cap Enforces a minimum tip cap (in GWei) to use when determining tx fees. 1 GWei by default. 1 OP_CHALLENGER_TXMGR_MIN_TIP_CAP\n--txmgr.not-in-mempool-timeout Timeout for aborting a tx send if the tx does not make it to the mempool. 1m0s OP_CHALLENGER_TXMGR_TX_NOT_IN_MEMPOOL_TIMEOUT\n--txmgr.rebroadcast-interval Interval at which a published transaction will be rebroadcasted if it has not yet been mined. Should be less than ResubmissionTimeout to have an effect. 0s OP_CHALLENGER_TXMGR_REBROADCAST_INTERVAL\n--txmgr.receipt-query-interval Frequency to poll for receipts 12s OP_CHALLENGER_TXMGR_RECEIPT_QUERY_INTERVAL\n--txmgr.retry-interval Duration we will wait before resubmitting a transaction to L1 on a transient error. Values <= 0 will result in retrying immediately. Should be less than ResubmissionTimeout to have an effect. 1s OP_CHALLENGER_TXMGR_RETRY_INTERVAL\n--txmgr.send-timeout Timeout for sending transactions. If 0 it is disabled. 2m0s OP_CHALLENGER_TXMGR_TX_SEND_TIMEOUT\nNotes on selected flags\nConditionally required flags\nThe required table above lists the flags op-challenger always checks at\nstartup. Additional flags become required depending on the configuration: the\nchain must be identified by --network or by --game-factory-address , and\neach enabled game type requires its trace-execution flags (for example the\ncannon-kona game type requires the kona server and an absolute prestate via\n--cannon-kona-prestate or --cannon-kona-prestates-url ).\nnetwork\nWhen --network is set to a chain bundled from the superchain-registry, the\n--game-factory-address is resolved automatically from the registry and does\nnot need to be set.\ngame-types\nSelects which dispute game types the challenger plays. Which type defends\nyour chain depends on the protocol version it runs; see the\nchallenger configuration guide\nfor choosing game types, trace types, and the matching prestates.\ncannon-* and cannon-kona-*\nThe cannon-* flags apply only when a cannon-based game type is enabled, and\nthe cannon-kona-* variants only to the cannon-kona game type. Each of\nthese settings has a default variant plus a game-type-specific variant that\noverrides it (the ( game type only) suffix in the table above).\nNote that op-program, the fault proof program the non-kona cannon game types\nexecute, has\nreached end of support , so only the kona\nvariants are still being maintained.\nUtility subcommands\nBeyond running the challenger service, the op-challenger binary provides\nutility subcommands for inspecting and interacting with dispute games:\nlist-games , list-claims , list-credits , create-game , move ,\nresolve , resolve-claim , and run-trace . Each takes its own flags; run\nop-challenger --help for details.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.berachain.com/","domain":"docs.berachain.com","title":"Introduction - Berachain","hash":"2c28bfb83848ae5d41fbbd654612e955ec8fa5b1d96dafa34cd65b733d3654ab","tokens":273,"chars":1091,"crawler":"hive-genesis","verified":"unchecked","ts":1791111979785,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBerachain home page\nGeneral\nBEX\nBend\nBuild\nNodes\nOverview\nIntroduction\nOfficial documentation for Berachain - the first blockchain powered by Proof-of-Liquidity\nBerachain is a high-performance EVM-identical Layer 1 blockchain utilizing Proof-of-Liquidity (PoL) consensus.\nGet started\nWhat is Berachain?\nLearn about Berachainâs architecture, EVM compatibility, and core concepts.\nProof of Liquidity\nUnderstand how Berachainâs unique consensus mechanism works.\nConnect Your Wallet\nSet up your wallet to interact with Berachain.\nGet $BERA\nLearn how to acquire BERA tokens to use on the network.\nNative dApps\nBEX\nThe native decentralized exchange for trading tokens on Berachain.\nBend\nDecentralized lending protocol for borrowing and lending assets.\nTokens\n$BERA\nNative gas and staking token.\n$BUSD\nNative stablecoin.\n$sWBERA\nYield-bearing staking vault token.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.monad.xyz/introduction/why-monad","domain":"docs.monad.xyz","title":"Why Monad: Decentralization + Performance - Monad Documentation","hash":"e22f9d8cecd02ae4cd7a33588cfa77881ad6e7bd0b87a54f96bf4a79a46b3c8b","tokens":1014,"chars":4054,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111979679,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nMonad Documentation home page\nDocumentation\nLearn\nNode Operations\nWhy Monad: Decentralization + Performance\nMonad addresses todayâs performance bottlenecks through optimization while preserving decentralization.\nMonad is an Ethereum-compatible Layer-1 blockchain. It produces a block every 300 ms, reaches full\nfinality in 600 ms, and has the throughput capacity for more than 10,000 transactions per second.\nMonad reaches these numbers while preserving decentralization, rather than trading it away for\nspeed. The rest of this page explains how.\nPerformance at a glance\nMetric Value Basis\nThroughput 10,000+ TPS Capacity\nBlock time 300 ms Observed (mainnet)\nSpeculative finality 300 ms (1 slot) Protocol\nFinality 600 ms (2 slots) Protocol\nBlock gas budget 150M gas (500M gas/s) Observed (mainnet)\nPer-transaction gas limit 30M gas Protocol\nThe Basis column says where each number comes from. Observed figures are measured on Monad\nmainnet, where the mean block time was about 302 ms in September 2026. Capacity is the design\nthroughput for typical transactions rather than a reading of current demand, so the rate you see in\npractice depends on how much gas each transaction uses. Protocol figures come from MonadBFT\nitself: a block reaches speculative finality\nafter one slot and full finality after two.\nDecentralization matters\nA blockchain has several major components:\n- Consensus mechanism for achieving agreement on transactions to append to the ledger\n- Execution/storage system for maintaining the active state\nIn increasing the performance of these components, one could cut corners, for example by requiring all\nof the nodes to be physically close to each other (to save on the overhead of consensus), or by\nrequiring a huge amount of RAM (to keep much or all of the state in memory), but it would be at a\nsignificant cost to decentralization.\nAnd decentralization is the whole point!\nAs discussed in Why Blockchain? , decentralized shared global state\nallows many parties to coordinate while relying on a single, shared, objective source of truth.\nDecentralization is key to the matter; a blockchain maintained by a small group of node operators (or\nin the extreme case, a single operator!) would not offer benefits such as trustlessness, credible\nneutrality, and censorship-resistance.\nFor any blockchain network, decentralization should be the principal concern. Performance improvements\nshould not come at the expense of decentralization.\nTodayâs performance bottlenecks\nEthereumâs current execution limits (2.5M gas per second) are set conservatively, but for several\ngood reasons:\n- Inefficient storage access patterns\n- Single-threaded execution\n- Very limited execution budget, because consensus canât proceed without execution\n- Concerns about state growth, and the effect of state growth on future state access costs\nMonad addresses these limitations through algorithmic improvements and architectural changes,\npioneering several innovations that will hopefully become standard in Ethereum in the years to come.\nMaintaining a high degree of decentralization, while making material performance improvements, is the\nkey consideration.\nAddressing these bottlenecks through optimization\nMonad enables pipelining and other optimizations in four major areas to enable exceptional Ethereum\nVirtual Machine performance and materially advance the decentralization/scalability tradeoff.\nSubsequent pages describe these major areas of improvement:\n- MonadBFT , a frontier BFT consensus mechanism solving the\ntail-forking problem\n- RaptorCast for efficient block transmission\n- Asynchronous Execution for pipelining\nconsensus and execution to raise the time budget for execution\n- Parallel Execution and JIT Compilation for efficient transaction\nexecution\n- MonadDb for efficient storage of Ethereum state\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.anchor-lang.com/docs/tokens/basics","domain":"www.anchor-lang.com","title":"SPL Token Basics","hash":"7569c32d5dc2ed4e2324d02e6ac80f3bf1f76f95ac6af6f153d97d0a73f7ec55","tokens":343,"chars":1371,"crawler":"hive-genesis","verified":"exact","ts":1791111981402,"text":"Anchor Docs\nGithub Discord Stack Exchange\nInteracting with Tokens\nSPL Token Basics\nLearn how to integrate SPL Tokens into your Solana programs using the Anchor framework.\nThis section covers the basics for interacting with SPL Tokens in Anchor\nprograms, focusing on the most commonly used instructions.\nAll examples in this section work identically with both the original Token\nProgram and the Token Extension Program (Token 2022), as they share the same\nbase implementation.\nBelow are the most common instructions you'll see when interacting with SPL\nTokens:\nCreate a Token Mint\nLearn how to create and initialize token mint accounts in Solana programs using Anchor. Covers creating mint accounts with generated keypairs or PDAs with code examples.\nCreate a Token Account\nLearn how to create and initialize token accounts in Solana programs using Anchor. Covers creating Associated Token Accounts (ATAs) and Program Derived Address (PDA) token accounts with code examples.\nMint Tokens\nLearn how to mint tokens in Solana programs using Anchor. Covers creating new tokens via cross program invocations (CPI) to the Token Program with code examples.\nTransfer Tokens\nLearn how to transfer tokens between token accounts through cross program invocations (CPIs) in Anchor.\nPrevious\nToken Integration with Anchor\nNext\nCreate a Token Mint\nOn this page\nNo Headings\nEdit on GitHub"}
{"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","hash":"80eacec2199a246eac5f8ce3833c073ea69bdcbc1c757189da62b8dec184809b","tokens":2179,"chars":8714,"crawler":"crawler-dfxz","verified":"exact","ts":1791111981378,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: Core\nEIP-197: Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128\nAuthors\nVitalik Buterin < vitalik@ethereum.org >, Christian Reitwiessner < chris@ethereum.org >\nCreated\n2017-02-06\nTable of Contents\n- Simple Summary\n- Abstract\n- Motivation\n- Specification\n- Definition of the groups\n- Encoding\n- Gas costs\n- Rationale\n- Backwards Compatibility\n- Test Cases\n- Implementation\n- Copyright\nSimple Summary\nPrecompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit.\nAbstract\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).\nMotivation\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.\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.\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.\nSpecification\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.\nAddress: 0x8\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 .\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 .\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\nthe respective group or are not encoded correctly, the call fails.\nOtherwise, return one if\nlog_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0\n(in F_q) and zero else.\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.\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 .\nDefinition of the groups\nThe groups G_1 and G_2 are cyclic groups of prime order q = 21888242871839275222246405745257275088548364400416034343698204186575808495617 .\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) .\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 = (\n11559732032986387107991004021392285783925812861821192530917403151452391805634 * i +\n10857046999023057135944570762232829481370756359578518086990519993285655852781,\n4082367875863433681332203403145435568316851327593401208105741076214120093531 * i +\n8495653923123431417604973247489272438418190587263600148770280649306958101930\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 .\nEncoding\nElements of F_p are encoded as 32 byte big-endian numbers. An encoding value of p or larger is invalid.\nElements a * i + b of F_p^2 are encoded as two elements of F_p , (a, b) .\nElliptic curve points are encoded as a Jacobian pair (X, Y) where the point at infinity is encoded as (0, 0) .\nNote that the number k is derived from the input length.\nThe length of the returned data is always exactly 32 bytes and encoded as a 32 byte big-endian number.\nGas costs\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.\nRationale\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.\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.\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).\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.\nBackwards Compatibility\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.\nTest Cases\nTo be written.\nImplementation\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(1) e(m * P1, n * P2) = e(P1, P2)^(m * n)\n(2) e is non-degenerate\nNow observe that\nlog_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q)\nif and only if\ne(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = 1 (in G_T)\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)\nAnd thus, the precompiled contract can be implemented by verifying that\ne(a1, b1) * ... * e(ak, bk) = 1\nImplementations are available here:\n- libff (C++)\n- bn (Rust)\n- Python\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nVitalik 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."}
{"url":"https://docs.jup.ag/","domain":"docs.jup.ag","title":"Jupiter User Docs - Jupiter Documentation","hash":"4d27e93b703af6b2b85ac9e86969159be7b02ac1daad8132831ece8f9d10080f","tokens":651,"chars":2601,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111983326,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nJupiter Documentation home page\nUser Documentation\nAll the Jupiter Products explained\nBrowse documentation for every Jupiter product\nSupport Hub All Jupiter resources, links and support tickets in one place\nAcademy Beginner guides, step-by-step tutorials and use cases\nQuick access\nGacha\nOpen digital packs and pull real graded Pokemon and One Piece cards.\nOfferbook\nAccess fixed-term USDC liquidity peer-to-peer using any Solana token as collateral.\nSpend\nSpend your crypto in the real world with the Jupiter card.\nTrade\nExchange, leverage and predict on Jupiter\nSpot New\nJupiterâs spot trading interface â best-price swaps across all Solana DEXs, plus charts, limit & recurring orders, token discovery and portfolio tracking.\nStocks New\nTokenized stocks on Solana â compare issuers, check the underlying price and trade 24/5 on Jupiter Spot.\nPerps\nTrade perpetual futures with up to 250x leverage on SOL, ETH, BTC and more.\nPredict\nPrediction markets â bet on real-world events and earn from your knowledge.\nGacha\nOpen digital packs and pull real graded Pokemon and One Piece cards.\nEarn\nGrow your assets with yield and rewards\nLend\nLend your assets and earn competitive yield through Jupiterâs lending markets.\nOfferbook\nAccess fixed-term USDC liquidity peer-to-peer, using any Solana token as collateral.\nJLP\nProvide liquidity to the pool that powers Jupiter Perps and earn a share of all trading fees.\nStake SOL\nStake your SOL and earn rewards while securing the Solana network.\nJupUSD\nJupiterâs stablecoin backed by BUIDL, designed to access onchain dollar liquidity.\nRewards Hub\nTrack, manage and claim all your Jupiter rewards from one dashboard.\nManage\nYour wallet, portfolio and tools\nPortfolio\nAsset tracking dashboard\nJupiter Wallet\nBrowser extension wallet for Solana\nLaunch\nCreate, launch and manage tokens\nStudio\nToken creation tools\nVRFD\nVerified token launches\nLock\nToken vesting & locking\nGlobal\nThe mobile app and real-world payments\nJupiter Mobile\nMobile app\nSpend\nVisa card, QR Pay, remittance & cashback\nOnramp\nGet crypto into your wallet from anywhere\nSend\nInstant token transfers\nDeposit\nDeposit crypto, bridge & swap, buy with a card\nMore\nGovernance and the JUP token\nPoker\nBack pro players and earn a share of winnings\nDAO\nStaking, voting & governance\nJUP Token\nTokenomics & transparency\nSecurity\nIndependent audits of every Jupiter program\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://ethereum.org/roadmap/","domain":"ethereum.org","title":"Ethereum roadmap | âŠethereum.orgâ©","hash":"8686639d32303961cbc7b630793d1f5da9c7db379e76b9a574a5607361e698b3","tokens":2524,"chars":10095,"crawler":"hive-genesis","verified":"unchecked","ts":1791111983414,"text":"Skip to main content\nEthereum roadmap\nThe path to more scalability, security and sustainability for Ethereum.\nIn production\nParis (The Merge)\nSeptember 15, 2022\nIn production\nShapella\nApril 12, 2023\nIn production\nDencun\nMarch 13, 2024\nIn production\nPectra\nMay 7, 2025\nIn production\nFusaka\nDecember 3, 2025\nIn development\nGlamsterdam\nQ4 2026\nIn development\nHegotĂĄ\n2027\nParis (The Merge)\nSeptember 15, 2022\nMain features\nTransition to Proof of Stake\n- Replaced energy-intensive mining with staking-based consensus\n- Reduced Ethereum's energy consumption by ~99.95%\nBeacon Chain Integration\n- Merged the Beacon Chain with the Ethereum mainnet\n- Enabled the full transition to PoS consensus mechanism\nDifficulty Bomb Removal\n- Removed the difficulty bomb that was increasing mining difficulty\n- Ensured smooth transition to the new consensus mechanism\nLearn more\nShapella\nApril 12, 2023\nMain features\nStaking withdrawals\n- Enabled validators to withdraw their staked ETH and rewards\n- Introduced partial and full withdrawal capabilities\nEIP-4895: Beacon chain push withdrawals\n- Added a new system-level operation for withdrawals\n- Ensured secure and efficient processing of withdrawal requests\nEIP-3651: Warm COINBASE\n- Reduced gas costs for accessing the COINBASE address\n- Improved efficiency of certain smart contract operations\nLearn more\nDencun\nMarch 13, 2024\nMain features\nProto-danksharding (EIP-4844)\n- Introduced blob transactions to significantly reduce rollup transaction costs\n- Added a new transaction type that stores data temporarily and cheaply\nEIP-1153: Transient storage opcodes\n- Added TSTORE and TLOAD opcodes for temporary storage during transaction execution\n- Enables more efficient smart contract patterns and reduces gas costs\nEIP-4788: Beacon block root in the EVM\n- Exposes consensus layer information to smart contracts\n- Enables new trust-minimized applications and cross-chain bridges\nLearn more\nPectra\nMay 7, 2025\nMain features\nEnhance EOA wallets with smart contract functionality\n- Users can set their address to be represented by a code of an existing smart contract and gain benefits such as transaction batching, transaction fee sponsorship or better recovery mechanisms\nIncrease the max effective balance\n- Stakers can now hold up to 2048 ETH in one validator instead of exactly 32, earning rewards on every ETH above the minimum\nBlob throughput increase\n- Raised the blob target to 6 per block with a maximum of 9, making transactions on rollups cheaper\nLearn more Track changes (opens in a new tab)\nFusaka\nDecember 3, 2025\nMain features\nPeerDAS (Peer-to-Peer Data Availability Sampling)\n- Enables more efficient data availability for rollups\n- Makes running a node more accessible while maintaining decentralization\nBlob Parameter Only (BPO) Forks\n- Allows flexible blob count increases between major upgrades\n- Enables faster adaptation to L2 scaling needs without waiting for coordinated hard forks\nGas Limit & DoS Hardening\n- Transaction gas limit cap of 16.7M gas per transaction\n- Raised the default gas limit to 60M, increasing L1 execution capacity\nLearn more Track changes (opens in a new tab)\nGlamsterdam\nQ4 2026\nMain features\nEnshrined proposer-builder separation\n- Separates block agreement from processing, helping L1 scale by allowing validators to process more data\n- Natively integrates builders so validators can safely outsource block assembly without trusting external software\nBlock-level access lists\n- Introduces mandatory access lists at the block level, rather than for individual transactions\n- Maps dependencies upfront for faster syncs, parallel execution, and parallel disk reads\n- Lowers gas for state-heavy apps and improves gas cost predictability\nLearn more Track changes (opens in a new tab)\nHegotĂĄ\n2027\nMain features\nFork-choice enforced inclusion lists (FOCIL)\n- Lets a committee of validators require that valid transactions are included, so no single block builder can leave them out\n- Decouples censorship resistance from local block building, removing a constraint on scaling L1\n- Strengthens layer 2 settlement guarantees, which can shorten exit windows for optimistic rollups\nFrame transactions\n- Adds a transaction type where the account itself decides what makes a transaction valid, rather than one fixed signature scheme\n- Makes social recovery, spending limits and sponsored gas native to the protocol instead of bolted on\n- Gives accounts a path to post-quantum signature schemes\nScope is not final. These are the changes scheduled so far, and dozens more have been proposed.\nLearn more Track changes (opens in a new tab)\nWhat changes are coming to Ethereum?\nEthereum is already a powerful platform, but it is still being improved. An ambitious set of improvements will upgrade Ethereum from its current form into a fully scaled, maximally resilient platform.\nCheaper transactions\nUpgrades to Ethereum and its rollups are adding capacity to the network, making transactions cheaper and faster for everyone.\nMore on scaling\nExtra security\nEthereum is already very secure but it can be made even stronger, ready to withstand all kinds of attack far into the future.\nMore on security\nBetter user experience\nMore support for smart contract wallets and light-weight nodes will make using Ethereum simpler and safer.\nMore on UX\nPrivacy by default\nPrivacy on Ethereum is moving from an optional add-on to a network-level default, with upgrades that protect what users read, send, and prove onchain.\nMore on privacy\nWhy does Ethereum need a roadmap?\nEthereum gets regular upgrades that enhance its scalability, security, or sustainability. One of Ethereum's core strengths is adapting as new ideas emerge from research and development. Adaptability gives Ethereum the flexibility to tackle emerging challenges and keep up with the most advanced technological breakthroughs.\nHow the roadmap is defined\nThe roadmap is mostly the result of years of work by researchers and developers - because the protocol is very technical - but any motivated person can participate.\nIdeas usually start off as discussions on a forum such as ethresear.ch (opens in a new tab) , Ethereum Magicians (opens in a new tab) or the Eth R&D discord server. They may be responses to new vulnerabilities that are discovered, suggestions from organizations working in the application layer (such as dapps and exchanges) or from known frictions for end users (such as costs or transaction speeds).\nWhen these ideas mature, they can be proposed as Ethereum Improvement Proposals (opens in a new tab) . This is all done in public so that anyone from the community can weigh in at any time.\nMore on Ethereum governance\nWhat technical upgrades are coming to Ethereum?\nPost-quantum security\nQuantum computers could one day break the cryptography that blockchains rely on. Ethereum's post-quantum upgrades will replace vulnerable algorithms before quantum computing becomes a real threat.\nLearn more\nSingle slot finality\nInstead of waiting for fifteen minutes, blocks could get proposed and finalized in the same slot. This is more convenient for apps and difficult to attack.\nLearn more\nzkEVM\nZero-knowledge proofs could allow validators to verify Ethereum blocks without re-executing transactions, enabling higher gas limits without raising hardware requirements.\nLearn more\nStatelessness\nStateless clients will be able to verify new blocks without having to store large amounts of data. This will provide all the benefits of running a node with only a tiny fraction of today's costs.\nLearn more\nAccount abstraction\nAccount abstraction is a class of upgrades that support smart contract wallets natively on Ethereum, rather than having to use complex middleware.\nLearn more\nDanksharding\nDanksharding makes L2 rollups much cheaper for users by adding \"blobs\" of data to Ethereum blocks.\nLearn more\nWhat is the timeline for these upgrades?\nYesâalmost definitely. The roadmap is the current plan for upgrading Ethereum, covering both near-term and future plans. We expect the roadmap to change as new information and technology become available.\nThink of Ethereum's roadmap as a set of intentions for improving Ethereum; it is the core researchers' and developers' best hypothesis of Ethereum's most optimal path forward.\nSome upgrades are lower priority and likely not to be implemented for the next 5-10 years (e.g. quantum resistance). Giving precise timing of each upgrade is complicated to predict as many roadmap items are worked on in parallel and developed at different speeds. The urgency of an upgrade can also change over time depending on external factors (e.g. a sudden leap in the performance and availability of quantum computers may make quantum-resistant cryptography more urgent).\nOne way to think about Ethereum development is by analogy to biological evolution. A network that is able to adapt to new challenges and maintain fitness is more likely to succeed than one that is resistant to change, although as the network becomes more and more performant, scalable and secure fewer changes to the protocol will be required.\nUpgrades tend not to impact end-users except by providing better user-experiences and a more secure protocol and perhaps more options for how to interact with Ethereum. Regular users are not required to actively participate in an upgrade, nor are they required to do anything** to secure their assets. Node operators will need to update their clients to prepare for an upgrade. Some upgrades may lead to changes for application developers. For example, history expiry upgrades may lead application developers to grab historical data from new sources.\nSharding is splitting up the Ethereum blockchain so that subsets of validators are only responsible for a fraction of the total data. This was originally intended to be the way for Ethereum to scale. However, layer 2 rollups have developed much faster than expected and have provided a lot of scaling already, and will provide much more after Proto-Danksharding is implemented. This means \"shard chains\" are no longer needed and have been dropped from the roadmap."}
{"url":"https://www.metaplex.com/docs","domain":"www.metaplex.com","title":"Metaplex Developer Hub","hash":"7aee84d6bbace711bcce991bff86548ab239a438e1553470de94449317a94381","tokens":746,"chars":2983,"crawler":"crawler-dfxz","verified":"exact","ts":1791111985086,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nTokens\nCreate and launch tokens on Solana. Run token generation events (TGE), fair launches, and manage fungible tokens.\nLaunch Token\nFair launch tokens on Solana with Genesis.\nCreate A Token\nCreate a fungible SPL token with metadata.\nMint Tokens\nMint fungible tokens to a wallet address.\nTransfer Tokens\nTransfer tokens between wallet addresses.\nUpdate A Token\nUpdate the metadata of a fungible token.\nBurn Tokens\nBurn fungible tokens from circulation.\nAgents\nCreate, register, and run agents. Use the Metaplex Agent skills and agent registry to manage your autonomous agents.\nAgent Onboarding\nOnboarding guide for AI agents integrating with Metaplex programs.\nSkill\nMetaplex knowledge base for AI agents.\nMint an Agent\nMint an agent and register its Identity PDA.\nRegister an Agent\nRegister an agent on the Metaplex registry.\nRead Agent Data\nRead and verify agent identity on Solana.\nAgent Finance\nCapitalize and govern your AI agent through its own onchain token.\nAgent Commerce\nHow AI agents earn revenue, pay for services, and transact onchain.\nCreate an Agent Token\nLaunch a token from an agent's onchain wallet.\nRun an Agent\nDelegate execution to run an agent on Solana.\nNori\nPay-as-you-go LLM, image, and RPC services for agents, metered in SOL.\nNFTs\nCreate, manage, and trade NFTs on Solana using Metaplex Core and other NFT standards.\nCreate A NFT\nMint an NFT on Solana with Metaplex Core.\nRead A NFT\nFetch NFT metadata from Solana via the DAS API.\nUpdate A NFT\nUpdate NFT metadata or royalties on Solana.\nBurn A NFT\nBurn an NFT and reclaim its rent on Solana.\nTransfer A NFT\nTransfer an NFT between wallets on Solana.\nSmart Contracts\nProduction-ready on-chain programs for NFTs, tokens, and digital assets on Solana.\nToken Metadata\nSPL token creation with onchain metadata.\nCore\nNext-gen NFT standard with a composable plugin system.\nAgent Registry\nOnchain agent identity and execution delegation.\nMPL-3643\nPermissioned token standard for RWAs.\nBubblegum v2\nCompressed NFTs at a fraction of regular costs.\nCore Candy Machine\nNFT launchpad for MPL Core.\nMPL-Hybrid\nSwap NFT traits for fungible tokens and back.\nMPL-Distro\nMerkle-based token distributions.\nGenesis\nLaunch tokens onchain.\nInscription\nInscribe permanent data into Solana state.\nBubblegum v1\nCompressed NFTs on Solana. Use v2 for new projects.\nDeprecated : Candy Machine · Token Auth Rules · Fusion · Hydra · Auction House · Fixed Price Sale · Gumdrop · Token Entangler\nDev Tools\nSDKs, CLIs, and APIs to build, test, and deploy digital asset applications on Solana.\nDAS API\nQuery Solana digital assets at scale.\nMetaplex API\nPublic REST API\nUmi\nJS client for Solana RPC, wallets, and signers.\nCLI\nCLI to mint, transfer, and manage assets.\nShank\nIDL generation from Rust Solana programs.\nAmman\nLocal Solana validator and test toolkit.\nDeprecated : Sugar · Solita · Beet · Cusper · Rust Bin · Mobile SDKs\nSolana\nGuides for the Solana Blockchain"}
{"url":"https://eips.ethereum.org/EIPS/eip-1559","domain":"eips.ethereum.org","title":"EIP-1559: Fee market change for ETH 1.0 chain","hash":"e7b19f82afe578a1ed3c74d564b3e578040db2b6173cd529543db89588a68465","tokens":5366,"chars":21462,"crawler":"hive-genesis","verified":"exact","ts":1791111984991,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: Core\nEIP-1559: Fee market change for ETH 1.0 chain\nAuthors\nVitalik Buterin ( @vbuterin ), Eric Conner ( @econoar ), Rick Dudley ( @AFDudley ), Matthew Slipper ( @mslipper ), Ian Norden ( @i-norden ), Abdelhamid Bakhta ( @abdelhamidbakhta )\nCreated\n2019-04-13\nRequires\nEIP-2718 ,\nEIP-2930\nTable of Contents\n- Simple Summary\n- Abstract\n- Motivation\n- Specification\n- Backwards Compatibility\n- Block Hash Changing\n- GASPRICE\n- Security Considerations\n- Increased Max Block Size/Complexity\n- Transaction Ordering\n- Miners Mining Empty Blocks\n- ETH Burn Precludes Fixed Supply\n- Copyright\nSimple Summary\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.\nAbstract\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]) .\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.\nMotivation\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- 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.\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.\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.\nSpecification\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.\nAs of FORK_BLOCK_NUMBER , a new EIP-2718 transaction is introduced with TransactionType 2.\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 .\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]) .\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])) .\nThe EIP-2718 ReceiptPayload for this transaction is rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]) .\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@ dataclass\nclass TransactionLegacy :\nsigner_nonce : int = 0\ngas_price : int = 0\ngas_limit : int = 0\ndestination : int = 0\namount : int = 0\npayload : bytes = bytes ()\nv : int = 0\nr : int = 0\ns : int = 0\n@ dataclass\nclass Transaction2930Payload :\nchain_id : int = 0\nsigner_nonce : int = 0\ngas_price : int = 0\ngas_limit : int = 0\ndestination : int = 0\namount : int = 0\npayload : bytes = bytes ()\naccess_list : List [ Tuple [ int , List [ int ]]] = field ( default_factory = list )\nsignature_y_parity : bool = False\nsignature_r : int = 0\nsignature_s : int = 0\n@ dataclass\nclass Transaction2930Envelope :\ntype : Literal [ 1 ] = 1\npayload : Transaction2930Payload = Transaction2930Payload ()\n@ dataclass\nclass Transaction1559Payload :\nchain_id : int = 0\nsigner_nonce : int = 0\nmax_priority_fee_per_gas : int = 0\nmax_fee_per_gas : int = 0\ngas_limit : int = 0\ndestination : int = 0\namount : int = 0\npayload : bytes = bytes ()\naccess_list : List [ Tuple [ int , List [ int ]]] = field ( default_factory = list )\nsignature_y_parity : bool = False\nsignature_r : int = 0\nsignature_s : int = 0\n@ dataclass\nclass Transaction1559Envelope :\ntype : Literal [ 2 ] = 2\npayload : Transaction1559Payload = Transaction1559Payload ()\nTransaction2718 = Union [ Transaction1559Envelope , Transaction2930Envelope ]\nTransaction = Union [ TransactionLegacy , Transaction2718 ]\n@ dataclass\nclass NormalizedTransaction :\nsigner_address : int = 0\nsigner_nonce : int = 0\nmax_priority_fee_per_gas : int = 0\nmax_fee_per_gas : int = 0\ngas_limit : int = 0\ndestination : int = 0\namount : int = 0\npayload : bytes = bytes ()\naccess_list : List [ Tuple [ int , List [ int ]]] = field ( default_factory = list )\n@ dataclass\nclass Block :\nparent_hash : int = 0\nuncle_hashes : Sequence [ int ] = field ( default_factory = list )\nauthor : int = 0\nstate_root : int = 0\ntransaction_root : int = 0\ntransaction_receipt_root : int = 0\nlogs_bloom : int = 0\ndifficulty : int = 0\nnumber : int = 0\ngas_limit : int = 0 # note the gas_limit is the gas_target * ELASTICITY_MULTIPLIER\ngas_used : int = 0\ntimestamp : int = 0\nextra_data : bytes = bytes ()\nproof_of_work : int = 0\nnonce : int = 0\nbase_fee_per_gas : int = 0\n@ dataclass\nclass Account :\naddress : int = 0\nnonce : int = 0\nbalance : int = 0\nstorage_root : int = 0\ncode_hash : int = 0\nINITIAL_BASE_FEE = 1000000000\nINITIAL_FORK_BLOCK_NUMBER = 10 # TBD\nBASE_FEE_MAX_CHANGE_DENOMINATOR = 8\nELASTICITY_MULTIPLIER = 2\nclass World ( ABC ):\ndef validate_block ( self , block : Block ) -> None :\nparent_gas_target = self . parent ( block ). gas_limit // ELASTICITY_MULTIPLIER\nparent_gas_limit = self . parent ( block ). gas_limit\n# on the fork block, don't account for the ELASTICITY_MULTIPLIER to avoid\n# unduly halving the gas target.\nif INITIAL_FORK_BLOCK_NUMBER == block . number :\nparent_gas_target = self . parent ( block ). gas_limit\nparent_gas_limit = self . parent ( block ). gas_limit * ELASTICITY_MULTIPLIER\nparent_base_fee_per_gas = self . parent ( block ). base_fee_per_gas\nparent_gas_used = self . parent ( block ). gas_used\ntransactions = self . transactions ( block )\n# check if the block used too much gas\nassert block . gas_used <= block . gas_limit , 'invalid block: too much gas used'\n# check if the block changed the gas limit too much\nassert block . gas_limit < parent_gas_limit + parent_gas_limit // 1024 , 'invalid block: gas limit increased too much'\nassert block . gas_limit > parent_gas_limit - parent_gas_limit // 1024 , 'invalid block: gas limit decreased too much'\n# check if the gas limit is at least the minimum gas limit\nassert block . gas_limit >= 5000\n# check if the base fee is correct\nif INITIAL_FORK_BLOCK_NUMBER == block . number :\nexpected_base_fee_per_gas = INITIAL_BASE_FEE\nelif parent_gas_used == parent_gas_target :\nexpected_base_fee_per_gas = parent_base_fee_per_gas\nelif parent_gas_used > parent_gas_target :\ngas_used_delta = parent_gas_used - parent_gas_target\nbase_fee_per_gas_delta = max ( parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR , 1 )\nexpected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta\nelse :\ngas_used_delta = parent_gas_target - parent_gas_used\nbase_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR\nexpected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta\nassert expected_base_fee_per_gas == block . base_fee_per_gas , 'invalid block: base fee not correct'\n# execute transactions and do gas accounting\ncumulative_transaction_gas_used = 0\nfor 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\nsigner_address = self . validate_and_recover_signer_address ( unnormalized_transaction )\ntransaction = self . normalize_transaction ( unnormalized_transaction , signer_address )\nsigner = self . account ( signer_address )\nsigner . balance -= transaction . amount\nassert 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\nassert signer . balance >= transaction . gas_limit * transaction . max_fee_per_gas\n# ensure that the user was willing to at least pay the base fee\nassert transaction . max_fee_per_gas >= block . base_fee_per_gas\n# Prevent impossibly large numbers\nassert transaction . max_fee_per_gas < 2 ** 256\n# Prevent impossibly large numbers\nassert transaction . max_priority_fee_per_gas < 2 ** 256\n# The total must be the larger of the two\nassert transaction . max_fee_per_gas >= transaction . max_priority_fee_per_gas\n# priority fee is capped because the base fee is filled first\npriority_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\neffective_gas_price = priority_fee_per_gas + block . base_fee_per_gas\nsigner . balance -= transaction . gas_limit * effective_gas_price\nassert signer . balance >= 0 , 'invalid transaction: signer does not have enough ETH to cover gas'\ngas_used = self . execute_transaction ( transaction , effective_gas_price )\ngas_refund = transaction . gas_limit - gas_used\ncumulative_transaction_gas_used += gas_used\n# signer gets refunded for unused gas\nsigner . 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)\nself . account ( block . author ). balance += gas_used * priority_fee_per_gas\n# check if the block spent too much gas transactions\nassert cumulative_transaction_gas_used == block . gas_used , 'invalid block: gas_used does not equal total gas used in all transactions'\n# TODO: verify account balances match block's account balances (via state root comparison)\n# TODO: validate the rest of the block\ndef normalize_transaction ( self , transaction : Transaction , signer_address : int ) -> NormalizedTransaction :\n# legacy transactions\nif isinstance ( transaction , TransactionLegacy ):\nreturn NormalizedTransaction (\nsigner_address = signer_address ,\nsigner_nonce = transaction . signer_nonce ,\ngas_limit = transaction . gas_limit ,\nmax_priority_fee_per_gas = transaction . gas_price ,\nmax_fee_per_gas = transaction . gas_price ,\ndestination = transaction . destination ,\namount = transaction . amount ,\npayload = transaction . payload ,\naccess_list = [],\n)\n# 2930 transactions\nelif isinstance ( transaction , Transaction2930Envelope ):\nreturn NormalizedTransaction (\nsigner_address = signer_address ,\nsigner_nonce = transaction . payload . signer_nonce ,\ngas_limit = transaction . payload . gas_limit ,\nmax_priority_fee_per_gas = transaction . payload . gas_price ,\nmax_fee_per_gas = transaction . payload . gas_price ,\ndestination = transaction . payload . destination ,\namount = transaction . payload . amount ,\npayload = transaction . payload . payload ,\naccess_list = transaction . payload . access_list ,\n)\n# 1559 transactions\nelif isinstance ( transaction , Transaction1559Envelope ):\nreturn NormalizedTransaction (\nsigner_address = signer_address ,\nsigner_nonce = transaction . payload . signer_nonce ,\ngas_limit = transaction . payload . gas_limit ,\nmax_priority_fee_per_gas = transaction . payload . max_priority_fee_per_gas ,\nmax_fee_per_gas = transaction . payload . max_fee_per_gas ,\ndestination = transaction . payload . destination ,\namount = transaction . payload . amount ,\npayload = transaction . payload . payload ,\naccess_list = transaction . payload . access_list ,\n)\nelse :\nraise Exception ( 'invalid transaction: unexpected number of items' )\n@ abstractmethod\ndef parent ( self , block : Block ) -> Block : pass\n@ abstractmethod\ndef block_hash ( self , block : Block ) -> int : pass\n@ abstractmethod\ndef transactions ( self , block : Block ) -> Sequence [ Transaction ]: pass\n# effective_gas_price is the value returned by the GASPRICE (0x3a) opcode\n@ abstractmethod\ndef execute_transaction ( self , transaction : NormalizedTransaction , effective_gas_price : int ) -> int : pass\n@ abstractmethod\ndef validate_and_recover_signer_address ( self , transaction : Transaction ) -> int : pass\n@ abstractmethod\ndef account ( self , address : int ) -> Account : pass\nBackwards Compatibility\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 .\nBlock Hash Changing\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.\nGASPRICE\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.\nSecurity Considerations\nIncreased Max Block Size/Complexity\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.\nTransaction Ordering\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.\nMiners Mining Empty Blocks\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.\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.\nETH Burn Precludes Fixed Supply\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.\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nVitalik 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."}
{"url":"https://vitalik.eth.limo/","domain":"vitalik.eth.limo","title":"Vitalik Buterin's website","hash":"35b4bbce4a8d44a6b54c958f7e4440c08c812745c928d460126300d8eae21ecb","tokens":2301,"chars":9204,"crawler":"hive-genesis","verified":"unchecked","ts":1791111986806,"text":"Dark Mode Toggle\nVitalik Buterin's website\nBlockchains\nCryptography\nEconomics\nFun\nGeneral\nGitcoin\nMath\nPhilosophy\nTranslations\n-\n2026 Sep 27\nThe cryptographic world computer\n-\n2026 Aug 21\nObfuscation (Part III): Local Mixing\n-\n2026 Jul 28\nObfuscation (Part II): Diamond iO\n-\n2026 Jun 29\nObfuscation: building the final boss of cryptography (Part I)\n-\n2026 May 18\nA shallow dive into formal verification\n-\n2026 Apr 02\nMy self-sovereign / local / private / secure LLM setup, April 2026\n-\n2025 Dec 30\nBalance of power\n-\n2025 Dec 17\nLet a thousand societies bloom\n-\n2025 Nov 25\nPlinko PIR tutorial\n-\n2025 Nov 07\nGalaxy brain resistance\n-\n2025 Oct 19\nA GKR Tutorial\n-\n2025 Oct 05\nMemory access is O(N^[1/3])\n-\n2025 Sep 24\nThe importance of full-stack openness and verifiability\n-\n2025 Sep 21\nLow-risk defi can be for Ethereum what search was for Google\n-\n2025 Aug 12\nOn idea-driven ideas\n-\n2025 Aug 12\n\"I support it only if it's open source\" should be a more common viewpoint\n-\n2025 Jul 10\nMy response to AI 2027\n-\n2025 Jul 07\nWhy I used to prefer permissive licenses and now favor copyleft\n-\n2025 Jun 28\nDoes digital ID have risks even if it's ZK-wrapped?\n-\n2025 May 11\nA simple explanation of a/(b+c) + b/(c+a) + c/(a+b) = 4\n-\n2025 May 06\nThe math of when stage 1 and stage 2 make sense\n-\n2025 May 03\nSimplifying the L1\n-\n2025 Apr 14\nWhy I support privacy\n-\n2025 Mar 29\nWe should talk less about public goods funding and more about open source funding\n-\n2025 Mar 29\nThe tree ring model of culture and politics\n-\n2025 Feb 28\nAI as the engine, humans as the steering wheel\n-\n2025 Feb 14\nReasons to have higher L1 gas limits even in an L2-heavy Ethereum\n-\n2025 Jan 23\nScaling Ethereum L1 and L2s in 2025 and beyond\n-\n2025 Jan 05\nd/acc: one year later\n-\n2024 Dec 03\nWhat I would love to see in a wallet\n-\n2024 Nov 09\nFrom prediction markets to info finance\n-\n2024 Oct 29\nPossible futures of the Ethereum protocol, part 6: The Splurge\n-\n2024 Oct 26\nPossible futures of the Ethereum protocol, part 5: The Purge\n-\n2024 Oct 23\nPossible futures of the Ethereum protocol, part 4: The Verge\n-\n2024 Oct 20\nPossible futures of the Ethereum protocol, part 3: The Scourge\n-\n2024 Oct 17\nPossible futures of the Ethereum protocol, part 2: The Surge\n-\n2024 Oct 14\nPossible futures of the Ethereum protocol, part 1: The Merge\n-\n2024 Sep 28\nMaking Ethereum alignment legible\n-\n2024 Sep 02\nGlue and coprocessor architectures\n-\n2024 Aug 21\nPlurality philosophy in an incredibly oversized nutshell\n-\n2024 Aug 03\nReview: museums of the future, Dubai and Tokyo\n-\n2024 Jul 23\nExploring circle STARKs\n-\n2024 Jul 17\nAgainst choosing your political allegiances based on who is \"pro-crypto\"\n-\n2024 Jun 30\nEpochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times\n-\n2024 May 31\nSome reflections on the Bitcoin block size war\n-\n2024 May 29\nLayer 2s as cultural extensions of Ethereum\n-\n2024 May 23\nHow do layer 2s really differ from execution sharding?\n-\n2024 May 17\nThe near and mid-term future of improving the Ethereum network's permissionlessness and decentralization\n-\n2024 May 09\nMultidimensional gas pricing\n-\n2024 Apr 29\nBinius: highly efficient proofs over binary fields\n-\n2024 Apr 01\nDegen communism: the only correct political ideology\n-\n2024 Mar 29\nWhat else could memecoins be?\n-\n2024 Mar 28\nEthereum has blobs. Where do we go from here?\n-\n2024 Feb 09\nAsk security questions\n-\n2024 Jan 31\nThe end of my childhood\n-\n2024 Jan 30\nThe promise and challenges of crypto + AI applications\n-\n2023 Dec 28\nMake Ethereum Cypherpunk Again\n-\n2023 Nov 27\nMy techno-optimism\n-\n2023 Nov 14\nExit games for EVM validiums: the return of Plasma\n-\n2023 Oct 31\nDifferent types of layer 2s\n-\n2023 Sep 30\nShould Ethereum be okay with enshrining more things in the protocol?\n-\n2023 Aug 16\nWhat do I think about Community Notes?\n-\n2023 Jul 24\nWhat do I think about biometric proof of personhood?\n-\n2023 Jun 20\nDeeper dive on cross-L2 reading for wallets and other use cases\n-\n2023 Jun 09\nThe Three Transitions\n-\n2023 May 21\nDon't overload Ethereum's consensus\n-\n2023 Apr 14\nTravel time ~= 750 * distance ^ 0.6\n-\n2023 Mar 31\nHow will Ethereum's multi-client philosophy interact with ZK-EVMs?\n-\n2023 Feb 28\nSome personal user experiences\n-\n2023 Jan 20\nAn incomplete guide to stealth addresses\n-\n2022 Dec 30\nWhat even is an institution?\n-\n2022 Dec 06\nUpdating my blog: a quick GPT chatbot coding experiment\n-\n2022 Dec 05\nWhat in the Ethereum application ecosystem excites me\n-\n2022 Nov 19\nHaving a safe CEX: proof of solvency and beyond\n-\n2022 Oct 28\nThe Revenue-Evil Curve: a different way to think about prioritizing public goods funding\n-\n2022 Sep 20\nDAOs are not corporations: where decentralization in autonomous organizations matters\n-\n2022 Sep 17\nWhat kind of layer 3s make sense?\n-\n2022 Sep 09\nShould there be demand-based recurring fees on ENS domains?\n-\n2022 Aug 04\nThe different types of ZK-EVMs\n-\n2022 Jul 13\nWhat do I think about network states?\n-\n2022 Jun 20\nMy 40-liter backpack travel guide\n-\n2022 Jun 15\nSome ways to use ZK-SNARKs for privacy\n-\n2022 Jun 12\nWhere to use a blockchain in non-financial applications?\n-\n2022 May 25\nTwo thought experiments to evaluate automated stablecoins\n-\n2022 Apr 01\nIn Defense of Bitcoin Maximalism\n-\n2022 Mar 29\nThe roads not taken\n-\n2022 Mar 14\nHow do trusted setups work?\n-\n2022 Feb 28\nEncapsulated vs systemic complexity in protocol design\n-\n2022 Jan 26\nSoulbound\n-\n2021 Dec 19\nThe bulldozer vs vetocracy political axis\n-\n2021 Dec 06\nEndgame\n-\n2021 Nov 16\nReview of Optimism retro funding round 1\n-\n2021 Nov 05\nHalo and more: exploring incremental verification and SNARKs without pairings\n-\n2021 Oct 31\nCrypto Cities\n-\n2021 Sep 26\nOn Nathan Schneider on the limits of cryptoeconomics\n-\n2021 Aug 22\nAlternatives to selling at below-market-clearing prices for achieving fairness (or community sentiment, or fun)\n-\n2021 Aug 16\nMoving beyond coin voting governance\n-\n2021 Jul 29\nAgainst overuse of the Gini coefficient\n-\n2021 Jun 18\nVerkle trees\n-\n2021 May 25\nBlockchain voting is overrated among uninformed people but underrated among informed people\n-\n2021 May 23\nThe Limits to Blockchain Scalability\n-\n2021 Apr 07\nWhy sharding is great: demystifying the technical properties\n-\n2021 Apr 02\nGitcoin Grants Round 9: The Next Phase of Growth\n-\n2021 Mar 23\nThe Most Important Scarce Resource is Legitimacy\n-\n2021 Feb 18\nPrediction Markets: Tales from the Election\n-\n2021 Jan 26\nAn approximate introduction to how zk-SNARKs are possible\n-\n2021 Jan 11\nWhy we need wide adoption of social recovery wallets\n-\n2021 Jan 05\nAn Incomplete Guide to Rollups\n-\n2020 Dec 28\nEndnotes on 2020: Crypto and Beyond\n-\n2020 Nov 08\nConvex and Concave Dispositions\n-\n2020 Nov 06\nWhy Proof of Stake (Nov 2020)\n-\n2020 Oct 18\nGitcoin Grants Round 7 Retrospective\n-\n2020 Sep 11\nCoordination, Good and Bad\n-\n2020 Aug 20\nTrust Models\n-\n2020 Aug 17\nA Philosophy of Blockchain Validation\n-\n2020 Jul 22\nGitcoin Grants Round 6 Retrospective\n-\n2020 Jul 20\nExploring Fully Homomorphic Encryption\n-\n2020 Apr 30\nGitcoin Grants Round 5 Retrospective\n-\n2020 Mar 21\nA Quick Garbled Circuits Primer\n-\n2020 Jan 28\nReview of Gitcoin Quadratic Funding Round 4\n-\n2019 Dec 26\nBase Layers And Functionality Escape Velocity\n-\n2019 Dec 24\nChristmas Special\n-\n2019 Dec 07\nQuadratic Payments: A Primer\n-\n2019 Nov 22\nHard Problems in Cryptocurrency: Five Years Later\n-\n2019 Oct 24\nReview of Gitcoin Quadratic Funding Round 3\n-\n2019 Oct 01\nIn-person meatspace protocol to prove unconditional possession of a private key\n-\n2019 Sep 22\nUnderstanding PLONK\n-\n2019 Aug 28\nThe Dawn of Hybrid Layer 2 Protocols\n-\n2019 Jun 12\nSidechains vs Plasma vs Sharding\n-\n2019 May 12\nFast Fourier Transforms\n-\n2019 May 09\nControl as Liability\n-\n2019 Apr 16\nOn Free Speech\n-\n2019 Apr 03\nOn Collusion\n-\n2019 Apr 01\n[Mirror] Cantor was Wrong: debunking the infinite set hierarchy\n-\n2018 Dec 05\nA CBC Casper Tutorial\n-\n2018 Nov 25\n[Mirror] Central Planning as Overfitting\n-\n2018 Aug 26\nLayer 1 Should Be Innovative in the Short Term but Less in the Long Term\n-\n2018 Aug 07\nA Guide to 99% Fault Tolerant Consensus\n-\n2018 Jul 21\nSTARKs, Part 3: Into the Weeds\n-\n2018 Apr 20\nOn Radical Markets\n-\n2018 Mar 28\nGovernance, Part 2: Plutocracy Is Still Bad\n-\n2017 Dec 31\nProof of Stake FAQ\n-\n2017 Dec 31\nSharding FAQ\n-\n2017 Dec 17\nNotes on Blockchain Governance\n-\n2017 Dec 14\nA Quick Gasprice Market Analysis\n-\n2017 Nov 22\nSTARKs, Part II: Thank Goodness It's FRI-day\n-\n2017 Nov 09\nSTARKs, Part I: Proofs with Polynomials\n-\n2017 Oct 17\nOn Medium-of-Exchange Token Valuations\n-\n2017 Sep 14\nA Prehistory of the Ethereum Protocol\n-\n2017 Jul 27\nA Note on Metcalfe's Law, Externalities and Ecosystem Splits\n-\n2017 Jul 16\nThe Triangle of Harm\n-\n2017 Jun 22\nOn Path Independence\n-\n2017 Jun 09\nAnalyzing Token Sale Models\n-\n2017 May 08\nEngineering Security Through Coordination Problems\n-\n2017 Mar 14\nHard Forks, Soft Forks, Defaults and Coercion\n-\n2017 Mar 11\nA Note On Charity Through Marginal Price Discrimination\n-\n2017 Feb 01\n[Mirror] Zk-SNARKs: Under the Hood\n-\n2017 Jan 14\n[Mirror] Exploring Elliptic Curve Pairings\n-\n2016 Dec 29\n[Mirror] A Proof of Stake Design Philosophy\n-\n2016 Dec 10\n[Mirror] Quadratic Arithmetic Programs: from Zero to Hero"}
{"url":"https://docs.ens.domains/","domain":"docs.ens.domains","title":"ENS Documentation","hash":"be85699d67344533603b9c87e029c7d934c9cdad065fac8c9db195504fad12a8","tokens":213,"chars":851,"crawler":"crawler-dfxz","verified":"exact","ts":1791111986777,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\nENS Documentation\nBuild applications with decentralized self-sovereign identity.\nGet Started Build with AI Learn about ENS\nLive on Sepolia\nOverview\nFor App Developers\nDeployments\nReadiness\nGet Started\nProtocol Docs\nResolution\nTools and Libraries\nBuilding with AI\nENSIPs\nUse ENS\nAddress Lookup\nText Records\nAvatars\nPrimary Names\nList Names\nRegistries\nENS Registrar\nETH Registrar\nDNS Registrar\nReverse Registrar\nResolvers\nPublic Resolver\nWriting a Resolver\nInteracting with a Resolver\nCross Chain Resolvers\nInterface Reference\nGovernance\nWelcome\nConstitution\nFoundation\nToken & Airdrop\nExtra\nNaming Smart Contracts\nName Wrapper\nSubgraph\nSign In With Ethereum (SIWE)\nENSv2 Readiness\nVideos\nETHGlobal Brussels Workshop ENS Evolution Beyond ETH"}
{"url":"https://ethereum.org/apps/","domain":"ethereum.org","title":"Top crypto apps on Ethereum | âŠethereum.orgâ©","hash":"8702b5bc0991af9ef037ff83ac707fa22abcd551ff2517dd36953095be16a17e","tokens":1385,"chars":5538,"crawler":"crawler-dfxz","verified":"exact","ts":1791111988586,"text":"Skip to main content\nApps\nDiscover a list of curated applications that run on Ethereum and layer 2 networks\nLearn about apps\nHighlights\nOwn the Internet. Ethereum Smart Accounts to safeguard your digital assets and build the future of ownership.\nDAO\nSafe\nTreasury management · Multi-sig · Smart account\nZora is an onchain social network revealing new opportunities to create, connect, and earn from your life online.\nSocial\nZora\nSocial network\nA space-themed decentralized RTS built on EVM with zkSNARKs, where players conquer planets across an infinite universe using hidden-information mechanics.\nGaming\nDark Forest Punk\nStrategy\nOwn the Internet. Ethereum Smart Accounts to safeguard your digital assets and build the future of ownership.\nDAO\nSafe\nTreasury management · Multi-sig · Smart account\nZora is an onchain social network revealing new opportunities to create, connect, and earn from your life online.\nSocial\nZora\nSocial network\nA space-themed decentralized RTS built on EVM with zkSNARKs, where players conquer planets across an infinite universe using hidden-information mechanics.\nGaming\nDark Forest Punk\nStrategy\nDiscover\nPrivacy\nPrivacy Pools\nPrivacy Pools by 0xbow is a compliant way to anonymously transact on Ethereum. 0xbow blocks illicit actors to ensure pool integrity.\nPools · Compliance\nCollectibles\nOpenSea\nOpenSea is an online marketplace for non-fungible tokens (NFTs), enabling users to buy, sell, and create NFTs. It functions as a decentralized platform where users can trade various digital assets, including art, music, gaming items, and more, across multiple blockchains.\nMarket\nDAO\nSplits\nSplits is a platform offering financial infrastructure for onchain teams, specializing in managing onchain payments using audited, open-source smart contracts.\nTreasury management\nPrivacy\nFluidkey\nFluidkey 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.\nStealth address · Payments · Identity\nGaming\nSorare\nSorare is a fantasy sports game for football, baseball, and basketball. Players collect, trade, and manage digital player cards that are used to form virtual teams and compete in fantasy leagues, with real-world player performance impacting the fantasy game's outcome.\nProductivity\nEAS\nEthereum Attestation Service (EAS) is an infrastructure public good for making attestations onchain or offchain about anything.\nGovernance\nApplications\nDeFi\nAave\nLending and borrowing\nSky/Maker - USDS\nStablecoin issuance · RWA · Lending and borrowing\nEthena - USDE\nRWA · Stablecoin issuance · Yield\nUniswap\nDEX\nPendle\nRWA\nSocial\nZora\nSocial network\nRodeo\nSocial network\nTowns\nMessaging\nFarcaster\nSocial network · Messaging\nOrb\nSocial network\nPrivacy\nDemocracy Earth Protocol\nVoting\nFileverse\nCommunication\nFluidkey\nStealth address · Payments · Identity\nFreedom Tool\nVoting\nKohaku\nShielded · Payments\nCollectibles\nOpenSea\nMarket\nBlur\nMarket\nHighlight\nArt\nManifold\nArt\nRarible\nMarket\nGaming\nAavagochi\nAdventure · Strategy · RPG\nAsphodel: Prologue\nStrategy\nBattle Bears\nShooter · Multiplayer\nCambria\nRPG · Adventure\nCat Town\nRPG · Casual · Fishing\nDAO\nSnapshot\nGovernance · Organization · Offchain voting\nTally\nOnchain voting · Analytics · Tokenomics · DAO creation · Governor\nHats Protocol\nRole management · Permissions · Organization\nAragon\nDAO creation · Governance · Framework\nDAOhaus\nDAO creation · Treasury management · Framework · Moloch\nProductivity\nENS\nDNS · Identity\nHuddle01\nCommunication\nLivepeer\nStorage · Video\nZK Passport\nIdentity\nQuarkID\nIdentity\nBridge\nParticle Network\nChain abstraction\nLayerswap\nLiquidity network\nHop\nLiquidity network\nStargate\nLiquidity network · Generalized message passing\nAcross\nValidator or oracle · Liquidity network\nApplication categories\nDeFi\nDeFi is a category of decentralized applications that allow users to lend, borrow, trade, and earn interest on their crypto assets.\nCollectibles\nCollectibles are digital assets that are unique and cannot be replicated.\nSocial\nSocial is a category of decentralized applications that allow users to connect with others and share content.\nGaming\nGaming is a category of decentralized applications that allow users to play games and earn rewards.\nBridge\nBridge is a category of decentralized applications that allow users to bridge their assets between different networks.\nProductivity\nProductivity is a category of decentralized applications that allow users to be productive.\nPrivacy\nPrivacy is a category of decentralized applications that allow users to be private.\nDAO\nDAO is a category of decentralized applications that allow users to govern and create decentralized autonomous organizations.\nCommunity picks\nTim Beiko\n@TimBeiko (opens in a new tab)\nSocial\nFarcaster\nSocial network · Messaging\nTrent Van Epps\n@trent_vanepps (opens in a new tab)\nDeFi\nPeer\nOnramp / offramp\nJason Chaskin\n@jchaskin22 (opens in a new tab)\nDeFi\nAave\nLending and borrowing\nSocial\nFarcaster\nSocial network · Messaging\nTim Beiko\n@TimBeiko (opens in a new tab)\nSocial\nFarcaster\nSocial network · Messaging\nTrent Van Epps\n@trent_vanepps (opens in a new tab)\nDeFi\nPeer\nOnramp / offramp\nJason Chaskin\n@jchaskin22 (opens in a new tab)\nDeFi\nAave\nLending and borrowing\nSocial\nFarcaster\nSocial network · Messaging\nSuggest an app\nWe'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.\nSuggest an app (opens in a new tab)"}
{"url":"https://bitcoinops.org/en/newsletters/","domain":"bitcoinops.org","title":"Newsletters | Bitcoin Optech","hash":"fe50ac400df5a2cdc0fa0d1aa83d5eba1177ca3665b034c9f7d34ca555319aee","tokens":9996,"chars":39983,"crawler":"hive-genesis","verified":"unchecked","ts":1791111988873,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\nNewsletters\n- Oct 2, 2026\nBitcoin Optech Newsletter #425\nThis weekâs newsletter summarizes the responsible disclosure of two\ndenial-of-service vulnerabilities affecting older versions of Eclair and\ndescribes a proposal for synchronizing wallet labels between devices\nthrough an untrusted store. Also included are our regular sections summarizing\nproposals and discussion about changing Bitcoinâs consensus rules, announcing\nnew releases and release candidates, and describing notable changes to popular\nBitcoin infrastructure software.\n- Sep 25, 2026\nBitcoin Optech Newsletter #424\nThis weekâs newsletter describes a proposal for upgrading the offchain\nprotocols of the Lightning Network to post-quantum security. Also included are\nour regular sections with selected questions and answers from the Bitcoin\nStack Exchange, announcements of new releases and release candidates, and\ndescriptions of notable changes to popular Bitcoin infrastructure software.\n- Sep 18, 2026\nBitcoin Optech Newsletter #423\nThis weekâs newsletter summarizes an analysis of mining pool difficulty\ncontrollers stranding slowed miners, describes a proposed improvement to\nUtreexoâs initial block download, and links to a draft BIP for specifying\nunspendable taproot internal keys. Also included are our regular sections\ndescribing recent changes to services and client software, announcing new\nreleases and release candidates, and describing notable changes to popular\nBitcoin infrastructure software.\n- Sep 11, 2026\nBitcoin Optech Newsletter #422\nThis weekâs newsletter describes a proposed protocol for probabilistic\ncoinjoins disguised as covert bets and summarizes benchmarks of a silent\npayments indexing server against compact block filters for light clients.\nAlso included are our regular sections announcing new releases and release\ncandidates and describing notable changes to popular Bitcoin infrastructure\nsoftware.\n- Sep 4, 2026\nBitcoin Optech Newsletter #421\nThis weekâs newsletter describes an idea for pools to pay miners using silent\npayments in the coinbase transaction and summarizes the responsible disclosure\nof a denial-of-service vulnerability affecting older versions of Core\nLightning. Also included are our regular sections summarizing proposals and\ndiscussion about changing Bitcoinâs consensus rules, announcing new releases\nand release candidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Aug 28, 2026\nBitcoin Optech Newsletter #420\nThis weekâs newsletter relays advance notice of a planned Core Lightning\nsecurity release, summarizes a discussion about opt-in replay protection for\npotential future forks, notes that the Hardware Wallet Interface (HWI) project\nwill enter maintenance mode, and describes a request for comments on using\nblock-range filters. Also included are our regular sections announcing new\nreleases and release candidates and describing notable changes to popular\nBitcoin infrastructure software.\n- Aug 21, 2026\nBitcoin Optech Newsletter #419\nThis weekâs newsletter summarizes the disclosure of a fixed reorg vulnerability\nin LNDâs channel closes and describes a draft BIP for the rawtr() output\nscript descriptor. Also included are our regular sections describing recent\nchanges to services and client software and notable changes to popular Bitcoin\ninfrastructure software.\n- Aug 14, 2026\nBitcoin Optech Newsletter #418\nThis weekâs newsletter describes a proposed contract protocol for mitigating\nLightning Network channel jamming, reports on the availability of static Bitcoin\nCore binaries for testing, and summarizes a change replacing Bitcoin Coreâs\nper-peer transaction rate-limiting with a global approach. Also included are\nour regular sections announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure software.\n- Aug 7, 2026\nBitcoin Optech Newsletter #417\nThis weekâs newsletter describes a draft BIP for relaying stale block tips\nbetween peers. Also included are our regular sections summarizing proposals and\ndiscussion about changing Bitcoinâs consensus rules, announcing new releases and\nrelease candidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Jul 31, 2026\nBitcoin Optech Newsletter #416\nThis weekâs newsletter warns about a severe vulnerability affecting wallets\ngenerated by COLDCARD signing devices, summarizes the disclosure of two\ndenial-of-service vulnerabilities in Core Lightning, and describes a proof of\nconcept for a zero-knowledge proof of reserves. Also included are our regular\nsections with selected questions and answers from the Bitcoin Stack Exchange,\nannouncements of new releases and release candidates, and descriptions of\nnotable changes to popular Bitcoin infrastructure software.\n- Jul 24, 2026\nBitcoin Optech Newsletter #415\nThis weekâs newsletter describes a draft BIP for full aggregation of BIP340\nsignatures. Also included are our regular sections describing recent changes to\nservices and client software, announcing new releases and release candidates,\nand summarizing notable changes to popular Bitcoin infrastructure software.\n- Jul 17, 2026\nBitcoin Optech Newsletter #414\nThis weekâs newsletter describes a new project to apply formal verification to the\nBitcoin protocol. Also included are our regular sections announcing new releases\nand release candidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Jul 10, 2026\nBitcoin Optech Newsletter #413\nThis weekâs newsletter describes research into using fountain codes to allow\npruned nodes to contribute to initial block download. Also included are our\nregular sections announcing new releases and release candidates, and describing\nnotable changes to popular Bitcoin infrastructure software.\n- Jul 3, 2026\nBitcoin Optech Newsletter #412\nThis weekâs newsletter includes our regular sections summarizing discussion about\nchanging Bitcoinâs consensus rules, announcing new releases and\nrelease candidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Jun 26, 2026\nBitcoin Optech Newsletter #411\nThis weekâs newsletter describes the responsible disclosure of a\ndenial-of-service vulnerability that affected older versions of LND. Also\nincluded are our regular sections with selected questions and answers from the\nBitcoin Stack Exchange, announcements of new releases and release candidates,\nand descriptions of notable changes to popular Bitcoin infrastructure software.\n- Jun 19, 2026\nBitcoin Optech Newsletter #410\nThis weekâs newsletter summarizes a discussion about wallets removing opt-in\nreplace-by-fee signaling from the transactions they create. Also included are\nour regular sections describing recent changes to services and client software\nand notable changes to popular Bitcoin infrastructure software.\n- Jun 12, 2026\nBitcoin Optech Newsletter #409\nThis weekâs newsletter describes a draft BIP to replace the testnet4 test\nnetwork with a successor. Also included are our regular sections announcing\nnew releases and release candidates and describing notable changes to popular\nBitcoin infrastructure software.\n- Jun 5, 2026\nBitcoin Optech Newsletter #408\nThis weekâs newsletter summarizes ideas to make BIP324 transport encryption\nquantum secure and describes a proposal to standardize QR-based signing payloads\nfor miniscript wallets. Also included are our regular sections summarizing\nproposals and discussion about changing Bitcoinâs consensus rules, announcing\nnew releases and release candidates, and describing notable changes to popular\nBitcoin infrastructure software.\n- May 29, 2026\nBitcoin Optech Newsletter #407\nThis weekâs newsletter announces the responsible disclosure of a vulnerability\nthat allowed a remote peer to crash Core Lightning nodes and links to\ntranscripts from a recent Bitcoin Core developer meeting. Also included are our\nregular sections announcing new releases and release candidates and describing\nnotable changes to popular Bitcoin infrastructure software.\n- May 22, 2026\nBitcoin Optech Newsletter #406\nThis weekâs newsletter links to a discussion of updates to BIP322âs generic\nsigned message format and describes an idea to use TCP hole punching to help\nBitcoin nodes behind NATs accept inbound connections. Also included are our\nregular sections describing recent changes to services and client software and\nsummarizing notable changes to popular Bitcoin infrastructure software.\n- May 15, 2026\nBitcoin Optech Newsletter #405\nThis weekâs newsletter announces the responsible disclosure of a vulnerability\nthat could allow an attacker with sufficient proof-of-work to crash Bitcoin Core\nnodes and describes a draft BIP proposal for sharing the UTXO set over the P2P\nnetwork. Also included are our regular sections announcing a new release\ncandidate and describing notable changes to popular Bitcoin infrastructure\nsoftware.\n- May 8, 2026\nBitcoin Optech Newsletter #404\nThis weekâs newsletter describes possible solutions to node fingerprinting and\nlinks to discussion of using public fraud proofs to improve incentives around\njust-in-time channels. Also included are our regular sections describing notable\nchanges to popular Bitcoin infrastructure software.\n- May 1, 2026\nBitcoin Optech Newsletter #403\nThis weekâs newsletter describes research around using binary fuse filters as an\nalternative to the GCS used in compact block filters. Also included are our\nregular sections summarizing proposals and discussion about changing Bitcoinâs\nconsensus rules, announcing new releases and release candidates, and describing\nnotable changes to popular Bitcoin infrastructure software.\n- Apr 24, 2026\nBitcoin Optech Newsletter #402\nThis weekâs newsletter describes Hornet Nodeâs work on a declarative executable\nspecification of consensus rules and summarizes a discussion about onion message\njamming in the Lightning Network. Also included are our regular sections with\nselected questions and answers from the Bitcoin Stack Exchange, announcements of\nnew releases and release candidates, and descriptions of notable changes to\npopular Bitcoin infrastructure software.\n- Apr 17, 2026\nBitcoin Optech Newsletter #401\nThis weekâs newsletter describes an idea for nested MuSig2 Lightning nodes and\nsummarizes a project formally verifying secp256k1âs modular scalar\nmultiplication. Also included are our regular sections describing recent changes\nto services and client software, announcing new releases and release candidates,\nand summarizing notable changes to popular Bitcoin infrastructure software.\n- Apr 10, 2026\nBitcoin Optech Newsletter #400\nThis weekâs newsletter includes our regular sections summarizing a Bitcoin Core\nPR Review Club meeting and describing notable changes to popular Bitcoin\ninfrastructure projects.\n- Apr 3, 2026\nBitcoin Optech Newsletter #399\nThis weekâs newsletter describes how wallet fingerprinting can damage\npayjoin privacy and summarizes a proposal for a wallet backup metadata\nformat. Also included are our regular sections summarizing proposals\nand discussion about changing Bitcoinâs consensus rules, announcing new\nreleases and release candidates, and describing notable changes to\npopular Bitcoin infrastructure software.\n- Mar 27, 2026\nBitcoin Optech Newsletter #398\nThis weekâs newsletter includes our regular sections with selected questions\nand answers from the Bitcoin Stack Exchange, announcements of new releases and\nrelease candidates, and descriptions of notable changes to popular Bitcoin\ninfrastructure software.\n- Mar 20, 2026\nBitcoin Optech Newsletter #397\nThis weekâs newsletter includes our regular sections describing changes\nto services and client software, announcing new releases and release\ncandidates, and summarizing recent changes to popular Bitcoin\ninfrastructure software.\n- Mar 13, 2026\nBitcoin Optech Newsletter #396\nThis weekâs newsletter describes a collision-resistant hash function using\nBitcoin Script and summarizes continued discussion of Lightning Network traffic\nanalysis. Also included are our regular sections with announcements of new releases\nand release candidates and descriptions of notable changes to popular Bitcoin\ninfrastructure software.\n- Mar 6, 2026\nBitcoin Optech Newsletter #395\nThis weekâs newsletter describes a standard for verifying VTXOs across different\nArk implementations and links to a draft BIP for expanding the miner-usable\nnonce space in the block headerâs nVersion field. Also included are our\nregular sections with descriptions of discussions about changing consensus,\nannouncements of new releases and release candidates, and summaries of notable\nchanges to popular Bitcoin infrastructure software.\n- Feb 27, 2026\nBitcoin Optech Newsletter #394\nThis weekâs newsletter looks at a proposed BIP for including supplemental\ninformation with output script descriptors. Also included are our regular\nsections summarizing popular questions on the Bitcoin Stack Exchange, announcing\nnew releases and release candidates, and describing recent changes to popular\nBitcoin infrastructure software.\n- Feb 20, 2026\nBitcoin Optech Newsletter #393\nThis weekâs newsletter summarizes a discussion about recent OP_RETURN usage and\ndescribes a protocol to enforce covenant-like spending conditions without\nconsensus changes. Also included are our regular sections describing recent\nchanges to services and client software, announcing new releases and release\ncandidates, and summarizing recent merges to popular Bitcoin infrastructure\nsoftware.\n- Feb 13, 2026\nBitcoin Optech Newsletter #392\nThis weekâs newsletter summarizes discussion of improving worst-case silent\npayment scanning performance and describes an idea for enabling many spending\nconditions in a single key. Also included are our regular sections with announcements\nof new releases and release candidates and descriptions of notable changes to\npopular Bitcoin infrastructure software.\n- Feb 6, 2026\nBitcoin Optech Newsletter #391\nThis weekâs newsletter links to work on a constant-time parallelized UTXO\ndatabase, summarizes a new high-level language for writing Bitcoin Script, and\ndescribes an idea to mitigate dust attacks. Also included are our regular\nsections summarizing discussion about changing Bitcoinâs consensus rules,\nannouncing new releases and release candidates, and describing notable changes\nto popular Bitcoin infrastructure software.\n- Jan 30, 2026\nBitcoin Optech Newsletter #390\nThis weekâs newsletter summarizes a more efficient approach to garbled\ncircuits and links to an LN-Symmetry update. Also included are our\nregular sections with selected questions and answers from the Bitcoin\nStack Exchange, announcements of new software releases and release\ncandidates, and summaries of notable changes to popular Bitcoin\ninfrastructure software.\n- Jan 23, 2026\nBitcoin Optech Newsletter #389\nThis weekâs newsletter links to a paper on the study of payment channel networks.\nAlso included are our regular sections describing recent updates to services and\nclient software, announcing new releases and release candidates, and summarizing\nnotable changes to popular Bitcoin infrastructure software.\n- Jan 16, 2026\nBitcoin Optech Newsletter #388\nThis weekâs newsletter links to a discussion of incremental mutation testing in\nBitcoin Core and announces deployment of a new BIP process. Also included are\nour regular sections announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure projects.\n- Jan 9, 2026\nBitcoin Optech Newsletter #387\nThis weekâs newsletter warns of a wallet migration bug in Bitcoin Core,\nsummarizes a post about using the Ark protocol as an LN channel factory, and\nlinks to a draft BIP for silent payment descriptors. Also included are our\nregular sections describing release candidates and notable\nchanges to popular Bitcoin infrastructure software.\n- Jan 2, 2026\nBitcoin Optech Newsletter #386\nThis weekâs newsletter summarizes a vault-like scheme using blinded MuSig2 and\ndescribes a proposal for Bitcoin clients to announce and negotiate support for new\nP2P features. Also included are our regular sections describing discussion\nrelated to consensus changes, announcing new releases and release candidates,\nand summarizing notable changes to popular Bitcoin infrastructure software.\n- Dec 19, 2025\nBitcoin Optech Newsletter #385: 2025 Year-in-Review Special\nThe eighth annual Bitcoin Optech Year-in-Review special summarizes notable developments in Bitcoin during all of 2025.\n- Dec 12, 2025\nBitcoin Optech Newsletter #384\nThis weekâs newsletter discloses vulnerabilities in LND and describes a project\nfor running a virtual machine in an embedded secure element. Also included are\nour regular sections describing changes to services and client software,\nsummarizing popular questions and answers of the Bitcoin Stack Exchange, and\nexamining recent changes to popular Bitcoin infrastructure software.\n- Dec 5, 2025\nBitcoin Optech Newsletter #383\nThis weekâs newsletter describes a fixed vulnerability affecting the NBitcoin\nlibrary. Also included are our regular sections summarizing discussion about\nchanging Bitcoinâs consensus rules, announcing new releases and release\ncandidates, and describing notable changes to popular Bitcoin infrastructure\nsoftware.\n- Nov 28, 2025\nBitcoin Optech Newsletter #382\nThis weekâs newsletter provides an update on compact block reconstruction\ndiscussions and relays a call to activate BIP3. Also included are our regular\nsections summarizing top questions and answers from the Bitcoin\nStack Exchange, announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure projects.\n- Nov 21, 2025\nBitcoin Optech Newsletter #381\nThis weekâs newsletter looks at an analysis of how block propagation times may\naffect miner revenue and describes a new approach for resolving protocols where\nmultiple parties share funds. Also included are our regular sections describing\nrecent changes to services and client software and summarizing recent merges to\npopular Bitcoin infrastructure software.\n- Nov 14, 2025\nBitcoin Optech Newsletter #380\nThis weekâs newsletter includes our regular sections with announcements of new\nreleases and release candidates, and descriptions of notable changes to popular\nBitcoin infrastructure software.\n- Nov 7, 2025\nBitcoin Optech Newsletter #379\nThis weekâs newsletter shares an analysis comparing the historical performance\nof the OpenSSL and libsecp256k1 libraries. Also included are our regular sections with\ndescriptions of discussions about changing consensus, announcements of\nnew releases and release candidates, and summaries of notable changes to\npopular Bitcoin infrastructure software.\n- Oct 31, 2025\nBitcoin Optech Newsletter #378\nThis weekâs newsletter announces four vulnerabilities affecting older versions of\nthe Bitcoin Core full node. Also included are our regular sections summarizing\npopular questions and answers from the Bitcoin Stack Exchange, announcing new\nreleases and release candidates, and describing notable changes to popular\nBitcoin infrastructure software.\n- Oct 24, 2025\nBitcoin Optech Newsletter #377\nThis weekâs newsletter summarizes an idea to use cluster mempool to detect\nblock template feerate increases and shares an update on channel jamming\nmitigation simulation results. Also included are our regular sections\ndescribing recent changes to services and client software, announcing\nnew releases and release candidates, and summarizing notable changes to\npopular Bitcoin infrastructure software.\n- Oct 17, 2025\nBitcoin Optech Newsletter #376\nThis weekâs newsletter shares an update on the proposal for nodes to share their\ncurrent block template and summarizes a paper outlining a covenant-less vault\nconstruction. Also included are our regular sections announcing new releases and\nrelease candidates and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Oct 10, 2025\nBitcoin Optech Newsletter #375\nThis weekâs newsletter describes research into tradeoffs between usability and\nsecurity in threshold signatures, summarizes an approach to convert nested\nthreshold signatures into a single-layer signing group, and examines the\nextent to which data could be embedded in the UTXO set under a restrictive set\nof rules. Also included are our regular sections summarizing a Bitcoin Core PR\nReview Club meeting, announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure projects.\n- Oct 3, 2025\nBitcoin Optech Newsletter #374\nThis weekâs newsletter includes our regular sections summarizing\ndiscussion about changing Bitcoinâs consensus rules, announcing new\nrelease and release candidates, and describing notable changes to\npopular Bitcoin infrastructure software.\n- Sep 26, 2025\nBitcoin Optech Newsletter #373\nThis weekâs newsletter summarizes a vulnerability affecting old versions of\nEclair and summarizes research into full node feerate settings. Also included\nare our regular sections summarizing popular questions and answers on the\nBitcoin Stack Exchange, announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure software.\n- Sep 19, 2025\nBitcoin Optech Newsletter #372\nThis weekâs newsletter summarizes a proposal to enhance LN redundant\noverpayments and links to a discussion about potential partitioning\nattacks against full nodes. Also included are our regular sections\ndescribing recent changes to services and client software, announcing\nnew releases and release candidates, and summarizing notable changes to\npopular Bitcoin infrastructure software.\n- Sep 12, 2025\nBitcoin Optech Newsletter #371\nThis weekâs newsletter announces the availability of a workbook\ndedicated to provable cryptography. Also included are our regular\nsections with links to new releases and release candidates, plus\ndescriptions of notable changes to popular Bitcoin infrastructure\nsoftware.\n- Sep 5, 2025\nBitcoin Optech Newsletter #370\nThis weekâs newsletter includes our regular sections summarizing\ndiscussion about changing Bitcoinâs consensus rules, announcing new\nrelease and release candidates, and describing notable changes to\npopular Bitcoin infrastructure software.\n- Aug 29, 2025\nBitcoin Optech Newsletter #369\nThis weekâs newsletter shares an update on differential fuzzing of\nBitcoin and LN implementations and links to a new paper about garbled\nlocks for accountable computing contracts. Also included are our\nregular sections summarizing popular questions and answers from the\nBitcoin Stack Exchange, announcing new releases and release candidates,\nand describing notable changes to popular Bitcoin infrastructure\nsoftware.\n- Aug 22, 2025\nBitcoin Optech Newsletter #368\nThis weekâs newsletter summarizes a draft BIP for block template sharing\nbetween full nodes and announces a library that allows trusted\ndelegation of script evaluation (including for features not available in\nBitcoinâs native scripting languages). Also included are our regular\nsections describing recent updates to services and client software,\nannouncing new releases and release candidates, and summarizing notable\nchanges to popular Bitcoin infrastructure software.\n- Aug 15, 2025\nBitcoin Optech Newsletter #367\nThis weekâs newsletter includes our regular sections announcing new\nrelease candidates and summarizing notable changes to popular Bitcoin\ninfrastructure software.\n- Aug 8, 2025\nBitcoin Optech Newsletter #366\nThis weekâs newsletter announces draft BIPs for Utreexo, summarizes\ncontinued discussion about lowering the minimum transaction relay\nfeerate, and describes a proposal to allow nodes to share their block\ntemplates to mitigate problems with divergent mempool policies. Also\nincluded are our regular sections summarizing a Bitcoin Core PR Review\nClub meeting, announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure projects.\nWe also include a correction to last weekâs newsletter and a\nrecommendation to readers.\n- Aug 1, 2025\nBitcoin Optech Newsletter #365\nThis weekâs newsletter summarizes the results of a test of compact block\nrelay prefilling and links to a mempool-based fee estimation library.\nAlso included are our regular sections summarizing discussion about\nchanging Bitcoinâs consensus rules, announcing new releases and release\ncandidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Jul 25, 2025\nBitcoin Optech Newsletter #364\nThis weekâs newsletter summarizes a vulnerability affecting old versions\nof LND, describes an idea for improving privacy when using co-signer\nservices, and examines the impact of switching to quantum-resistant\nsignature algorithms on HD wallets, scriptless multisig, and silent\npayments. Also included are our regular sections summarizing popular\nquestions and answers on the Bitcoin Stack Exchange, announcing new\nreleases and release candidates, and describing notable changes to\npopular Bitcoin infrastructure software.\n- Jul 18, 2025\nBitcoin Optech Newsletter #363\nThis weekâs newsletter includes our regular sections summarizing updates\nto services and client software, announcing new releases and release\ncandidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Jul 11, 2025\nBitcoin Optech Newsletter #362\nThis weekâs newsletter briefly describes a new library allowing output\nscript descriptors to be compressed for use in QR codes. Also included\nare our regular sections summarizing a Bitcoin Core PR Review Club\nmeeting, announcing new releases and release candidates, and describing\nnotable changes to popular Bitcoin infrastructure software.\n- Jul 4, 2025\nBitcoin Optech Newsletter #361\nThis weekâs newsletter describes a proposal to separate the network connections\nand peer management used for onion message relay from those used for\nHTLC relay in LN. Also included are our regular sections summarizing\ndiscussion about changing Bitcoinâs consensus and listing recent changes\nto popular Bitcoin infrastructure software.\n- Jun 27, 2025\nBitcoin Optech Newsletter #360\nThis weekâs newsletter summarizes research about fingerprinting full\nnodes using P2P protocol messages and seeks feedback about possibly\nremoving support for H in BIP32 paths in the BIP380 specification of\ndescriptors. Also included are our regular sections summarizing top\nquestions and answers on the Bitcoin Stack Exchange, announcing new\nreleases and release candidates, and describing notable changes to\npopular Bitcoin infrastructure software.\n- Jun 20, 2025\nBitcoin Optech Newsletter #359\nThis weekâs newsletter describes a proposal to limit public\nparticipation in Bitcoin Core repositories, announces a significant\nimprovements to BitVM-style contracts, and summarizes research into\nLN channel rebalancing. Also included are our regular sections\nsummarizing recent changes to clients and services, announcing new\nreleases and release candidates, and describing recent changes to popular\nBitcoin infrastructure software.\n- Jun 13, 2025\nBitcoin Optech Newsletter #358\nThis weekâs newsletter describes how the selfish mining danger threshold\ncan be calculated, summarizes an idea about preventing filtering of high\nfeerate transactions, seeks feedback about a proposed change to BIP390\nmusig() descriptors, and announces a new library for encrypting\ndescriptors. Also included are our regular sections with the summary of\na Bitcoin Core PR Review Club, announcements of new releases and release\ncandidates, and descriptions of recent changes to popular Bitcoin\ninfrastructure projects.\n- Jun 6, 2025\nBitcoin Optech Newsletter #357\nThis weekâs newsletter shares an analysis about syncing full nodes\nwithout old witnesses. Also included are our regular sections with\ndescriptions of discussions about changing consensus, announcements of\nnew releases and release candidates, and summaries of notable changes to\npopular Bitcoin infrastructure software.\n- May 30, 2025\nBitcoin Optech Newsletter #356\nThis weekâs newsletter summarizes a discussion about the possible\neffects of attributable failures on LN privacy. Also included are our\nregular sections with selected questions and answers from the Bitcoin\nStack Exchange, announcements of new releases and release candidates,\nand descriptions of recent changes to popular Bitcoin infrastructure\nsoftware.\n- May 23, 2025\nBitcoin Optech Newsletter #355\nThis weekâs newsletter includes our regular sections describing changes\nto services and client software, announcing new releases and release\ncandidates, and summarizing recent changes to popular Bitcoin\ninfrastructure software.\n- May 16, 2025\nBitcoin Optech Newsletter #354\nThis weekâs newsletter describes a fixed vulnerability affecting old\nversions of Bitcoin Core. Also included are our regular sections\nsummarizing recent discussions about changing Bitcoinâs consensus rules,\nannouncing new releases and release candidates, and describing notable\nchanges to popular Bitcoin infrastructure software.\n- May 9, 2025\nBitcoin Optech Newsletter #353\nThis weekâs newsletter describes a recently discovered theoretical\nconsensus failure vulnerability and links to a proposal to avoid reuse\nof BIP32 wallet paths. Also included are our regular sections summarizing\na Bitcoin Core PR Review Club meeting, announcing new releases and\nrelease candidates, and describing notable code changes to popular\nBitcoin infrastructure software.\n- May 2, 2025\nBitcoin Optech Newsletter #352\nThis weekâs newsletter links to comparisons between different cluster\nlinearization techniques and briefly summarizes discussion about\nincreasing or removing Bitcoin Coreâs OP_RETURN size limit. Also\nincluded are our regular sections announcing new releases and release\ncandidates and summarizing notable changes to popular Bitcoin\ninfrastructure software.\n- Apr 25, 2025\nBitcoin Optech Newsletter #351\nThis weekâs newsletter announces a new aggregate signature protocol\ncompatible with secp256k1 and describes a standardized backup scheme for\nwallet descriptors. Also included are our regular sections summarizing\nrecent Bitcoin Stack Exchange questions and answers, announcing new\nreleases and release candidates, and describing notable changes to\npopular Bitcoin infrastructure software.\n- Apr 18, 2025\nBitcoin Optech Newsletter #350\nThis weekâs newsletter includes our regular sections describing recent\nchanges to services and client software, announcements of new releases\nand release candidates, and descriptions of notable changes to popular\nBitcoin infrastructure software. Also included is a correction to some\ndetails from our story last week about SwiftSync.\n- Apr 11, 2025\nBitcoin Optech Newsletter #349\nThis weekâs newsletter describes a proposal for speeding up Bitcoin\nCore initial block download, with a proof-of-concept implementation that\nshows a roughly 5x speed up compared to Bitcoin Coreâs defaults. Also\nincluded are our regular sections summarizing a Bitcoin Core PR Review\nClub meeting, announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure projects.\n- Apr 4, 2025\nBitcoin Optech Newsletter #348\nThis weekâs newsletter links to an educational implementation of\nelliptic curve cryptography for Bitcoinâs secp256k1 curve. Also\nincluded are our regular sections with descriptions of discussions about\nchanging consensus, announcements of new releases and release\ncandidates, and summaries of notable changes to popular Bitcoin\ninfrastructure software.\n- Mar 28, 2025\nBitcoin Optech Newsletter #347\nThis weekâs newsletter describes a proposal to allow LN to support\nupfront and hold fees based on burnable outputs, summarizes discussion\nabout testnets 3 and 4 (including a hard fork proposal), and announces a\nplan to begin relaying certain transactions containing taproot annexes.\nAlso included are our regular sections summarizing selected questions\nand answers from the Bitcoin Stack Exchange, announcing new releases and\nrelease candidates, and describing notable changes to popular Bitcoin\ninfrastructure projects.\n- Mar 21, 2025\nBitcoin Optech Newsletter #346\nThis weekâs newsletter summarizes a discussion about LNDâs updated\ndynamic feerate adjustment system. Also included are our regular\nsections describing recent changes to services and client software,\nannouncing new releases and release candidates, and summarizing recent\nmerges to popular Bitcoin infrastructure software.\n- Mar 14, 2025\nBitcoin Optech Newsletter #345\nThis weekâs newsletter looks at an analysis of P2P traffic experienced\nby a typical full node, summarizes research into LN pathfinding, and\ndescribes a new approach for creating probabilistic payments. Also\nincluded are our regular sections summarizing a Bitcoin Core PR Review\nClub meeting, announcing new releases and release candidates, and\ndescribing notable changes to popular Bitcoin infrastructure projects.\n- Mar 7, 2025\nBitcoin Optech Newsletter #344\nThis weekâs newsletter announces the disclosure of a vulnerability\naffecting old versions of LND and summarizes a discussion about the Bitcoin\nCore Projectâs priorities. Also included are our regular sections\ndescribing discussion related to consensus changes, announcing new\nreleases and release candidates, and summarizing notable changes to\npopular Bitcoin infrastructure software.\n- Feb 28, 2025\nBitcoin Optech Newsletter #343\nThis weekâs newsletter summarizes a post about having full nodes ignore\ntransactions that are relayed without being requested first. Also\nincluded are our regular sections with popular questions and answers\nfrom the Bitcoin Stack Exchange, announcements of new releases and\nrelease candidates, and summaries of notable changes to popular Bitcoin\ninfrastructure software.\n- Feb 21, 2025\nBitcoin Optech Newsletter #342\nThis weekâs newsletter describes an idea for allowing mobile wallets to\nsettle LN channels without extra UTXOs and summarizes continued\ndiscussion about adding a quality-of-service flag for LN pathfinding.\nAlso included are our regular sections describing recent changes to\nclients, services, and popular Bitcoin infrastructure software.\n- Feb 14, 2025\nBitcoin Optech Newsletter #341\nThis weekâs newsletter summarizes continued discussion about\nprobabilistic payments, describes additional opinions about ephemeral\nanchor scripts for LN, relays statistics about evictions from the\nBitcoin Core orphan pool, and announces an updated draft for a revised\nBIP process. Also included are our regular sections summarizing a\nBitcoin Core PR Review Club meeting, announcing new releases and release\ncandidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Feb 7, 2025\nBitcoin Optech Newsletter #340\nThis weekâs newsletter announces a fixed vulnerability affecting LDK,\nsummarizes discussion about zero-knowledge gossip for LN channel\nannouncements, describes the discovery of previous research that can be\napplied to finding optimal cluster linearizations, provides an update on\nthe development of the Erlay protocol for reducing transaction relay\nbandwidth, looks at tradeoffs between different scripts for implementing\nLN ephemeral anchors, relays a proposal for emulating an OP_RAND\nopcode in a privacy-preserving manner with no consensus changes\nrequired, and points to renewed discussion about lowering the minimum\ntransaction feerate.\n- Jan 31, 2025\nBitcoin Optech Newsletter #339\nThis weekâs newsletter describes a vulnerability affecting older\nversions of LDK, looks at a newly disclosed aspect of a vulnerability\noriginally published in 2023, and summarizes renewed discussion about\ncompact block reconstruction statistics. Also included are our regular\nsections summarizing popular questions on the Bitcoin Stack Exchange,\nannouncing new releases and release candidates, and describing recent\nchanges to popular Bitcoin infrastructure software.\n- Jan 24, 2025\nBitcoin Optech Newsletter #338\nThis weekâs newsletter announces a draft BIP for referencing unspendable\nkeys in descriptors, examines how implementations are using PSBTv2, and\ncorrects in depth our description last week of a new offchain DLC\nprotocol. Also included are our regular sections describing changes to\nservices and client software, announcing new releases and release\ncandidates, and summarizing recent changes to popular Bitcoin\ninfrastructure software.\n- Jan 17, 2025\nBitcoin Optech Newsletter #337\nThis weekâs newsletter summarizes continued discussion about rewarding\npool miners with tradeable ecash shares and describes a new proposal for\nenabling offchain resolution of DLCs. Also included are our regular\nsections announcing new releases and release candidates and describing\nnotable changes to popular Bitcoin infrastructure software.\n- Jan 10, 2025\nBitcoin Optech Newsletter #336\nThis weekâs newsletter describes a potential change to Bitcoin Core\naffecting miners, summarizes discussion about creating contract-level\nrelative timelocks, and discusses a proposal for an LN-Symmetry variant\nwith optional penalties. Also included are our regular sections\nannouncing new releases and release candidates and summarizing notable\nchanges to popular Bitcoin infrastructure software.\n- Jan 3, 2025\nBitcoin Optech Newsletter #335\nThis weekâs newsletter links to information about longstanding deanonymization\nvulnerabilities in software using centralized coinjoin protocols and\nsummarizes an update to a draft BIP about the ChillDKG distributed key\ngeneration protocol compatible with scriptless threshold signing. Also\nincluded are our regular sections summarizing discussion about changing\nBitcoinâs consensus rules, announcing new releases and release\ncandidates, and describing notable changes to popular Bitcoin\ninfrastructure software.\n- Dec 20, 2024\nBitcoin Optech Newsletter #334: 2024 Year-in-Review Special\nThe seventh annual Bitcoin Optech Year-in-Review special summarizes notable developments in Bitcoin during all of 2024.\n- Dec 13, 2024\nBitcoin Optech Newsletter #333\nThis weekâs newsletter describes a vulnerability that allowed stealing\nfrom old versions of various LN implementations, announces a\ndeanonymization vulnerability affecting Wasabi and related software,\nsummarizes a post and discussion about LN channel depletion, links to a\npoll for opinions about selected covenant proposals, describes two types\nof incentive-based pseudo-covenants, and references summaries of the\nperiodic in-person Bitcoin Core developer meeting. Also included are our\nregular sections summarizing a Bitcoin Core PR Review Club meeting,\nlisting changes to services and client software, linking to popular\nBitcoin Stack Exchange questions and answers, announcing new releases\nand release candidates, and describing notable changes to popular\nBitcoin infrastructure software.\n- Dec 6, 2024\nBitcoin Optech Newsletter #332\nThis weekâs newsletter announces the disclosure of a transaction\ncensorship vulnerability and summarizes discussion about the consensus\ncleanup soft fork proposal. Also included are our regular sections\nannouncing new releases and release candidates and describing notable\nchanges to popular Bitcoin infrastructure software.\n- Nov 29, 2024\nBitcoin Optech Newsletter #331\nThis weekâs newsletter summarizes several recent discussions about a\nLisp dialect for Bitcoin scripting and includes our regular sections\nwith descriptions of popular questions and answers on the Bitcoin Stack\nExchange, announcements of new releases and release candidates, and\nsummaries of notable changes to popular Bitcoin infrastructure projects.\n- Nov 22, 2024\nBitcoin Optech Newsletter #330\nThis weekâs newsletter summarizes a proposed change to the LN\nspecification to allow pluggable channel factories, links to a report\nand a new website for examining transactions on the default signet\nthat use proposed soft forks, describes an update to the LNHANCE\nmulti-part soft fork proposal, and discusses a paper about covenants"}
{"url":"https://gov.optimism.io/latest","domain":"gov.optimism.io","title":"Optimism Collective - Optimism Collective","hash":"0f6f400acac3ea892d620a74d8ce666bb47d42bc7656588ba2bd2aeed3357a4a","tokens":863,"chars":3450,"crawler":"hive-genesis","verified":"unchecked","ts":1791111990665,"text":"Optimism Collective\nTopic\nReplies\nViews\nActivity\nWorking Constitution of the Optimism Collective\nGet Started đ±\nThe 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âŠ\n628\n61316\nSeptember 8, 2026\nRe-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\nProposals đ\n12\n1297\nSeptember 27, 2026\nExploring execution-time authorization for Superchain applications\nâš General\n4\n63\nSeptember 24, 2026\n[RFC] Civilizational Upgrade: Implementing the ACOM P2P Semantic Mesh & Holographic Chain on the OP Superchain\nGovernance Design and Strategy đ\n4\n116\nSeptember 24, 2026\nEden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\nCommunity Calls\n32\n698\nSeptember 23, 2026\nSeason 9 Final Report\nGrants Updates\n9\n458\nSeptember 23, 2026\nSeason 8 Growth Grants - TVL Impact Review\nâš General\nseason-8\n2\n160\nSeptember 23, 2026\nUpgrade 20 - Super Root Dispute Games & OPCM v8.0.0\nProtocol Upgrade\n2\n277\nSeptember 16, 2026\n[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\nGovernance Fund Missions\n4\n126\nSeptember 8, 2026\nAn Optimism Governance / Ecosystem Grant Proposal\nProposals đ\n0\n51\nSeptember 6, 2026\nOptimism Governance / Ecosystem Grant Proposal\nGet Started đ±\n0\n48\nSeptember 4, 2026\nOP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\nâš General\n3\n103\nSeptember 4, 2026\nSecurity Council Communication Thread\nCouncil Communication Threads\n18\n1435\nSeptember 3, 2026\nPGov - Delegate Communication Thread\nDelegate Updates\n45\n3540\nSeptember 2, 2026\nMaintenance Upgrade Proposal: Unichain ProxyAdmin Owner Transition to Standard Optimism Governance\nProposals đ\n0\n55\nSeptember 2, 2026\nMaintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit\nProposals đ\n0\n53\nSeptember 2, 2026\n[Builder Grant Proposal] Ag^Ï Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s)\nGovernance Fund Missions\n2\n84\nAugust 26, 2026\nAccelerated Decentralization Proposal For Optimism\nâš General\n36\n3594\nAugust 26, 2026\nBuyback Communication Thread\nCommunications đŁ\nseason-9\n6\n862\nAugust 25, 2026\nMaintenance Upgrade Proposal: Update Soneium Fee Vaults Recipient\nProposals đ\n1\n117\nAugust 23, 2026\nBrichis - Delegate Communication Thread\nDelegate Updates\n48\n3927\nAugust 21, 2026\nFranklinDAO (Penn Blockchain) - Delegate Communication Thread\nDelegate Updates\n5\n2223\nAugust 21, 2026\nCollective Year 4 Budget Update and Year 5 Budget Outlook\nFoundation Budgets\n2\n437\nAugust 7, 2026\nSandcastles and Social Mercenaries: Why EVM DAOs Are Being Looted\nâš General\n2\n87\nAugust 7, 2026\n[RFC] Operational Mandate: S9 Impact Autopsy & S10 Capital Efficiency Oracle\nGovernance Design and Strategy đ\n6\n157\nAugust 4, 2026\nMaintenance Upgrade Proposal: Ink Mainnet Fee Vault Config Update and Proposer Rotation\nProposals đ\n0\n97\nJuly 22, 2026\nMaintenance Upgrade: Swell Ownership Transfer to AltLayer\nProposals đ\n1\n112\nJuly 21, 2026\nBreaking the Capitalist Supremacy: How Grant Bottlenecks Drive the Sea Shell Economy\nâš General\n1\n81\nJuly 21, 2026\nThe Capitalist Supremacy Trap: Why Our DAO Governance is a Digitized Feudal State\nâš General\n7\n131\nJuly 21, 2026\nOptimism Security Council Operating Budget for Seasons 10 and 11\nProposals đ\n8\n227\nJuly 18, 2026\nnext page â"}
{"url":"https://docs.phantom.com/phantom-portal/portal","domain":"docs.phantom.com","title":"Phantom Portal overview - Phantom developer documentation","hash":"a97bf3e121d25518f8151edbf1a5ff47b12336d60b05add9b2473a06d8e9404d","tokens":640,"chars":2559,"crawler":"hive-genesis","verified":"exact","ts":1791111992177,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPhantom developer documentation home page\nGet started\nPhantom MCP server\nPhantom CLI\nPhantom Portal\nPhantom Connect SDKs\nRecipes\nDeveloper tools and resources\nOverview\nPhantom Portal overview\nDashboard for managing app configuration, branding, and integration with Phantom\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.\nPhantom Portal is a self-service dashboard where developers manage their appâs configuration, branding, and presence within Phantom.\nExisting accounts sign in at phantom.app/portal with a Google account or Apple ID.\nKey features\nPhantom Portal is the central hub for managing your appâs integration with Phantom. The portal lets you do the following:\n- Configure your app: Set up allowed URLs, network support, and authentication settings.\n- Manage branding: Upload your app icon, cover image, and description.\n- View access mode: See your appâs current access mode ( DISABLED , PRIVATE , or PUBLIC ).\n- Verify your domain: Confirm that you own the domain in order to have your app displayed in Phantom.\nApps that need Phantom Portal access\nYou need to use Phantom Portal if youâre building one of the following:\n- Apps with embedded wallet: Using React SDK , Browser SDK , or React Native SDK\n- Apps with Phantom Connect: Implementing social login or extension-based authentication . Learn about Phantom Connect .\n- Apps that need public listing: Appearing in Phantomâs Explore tab, search results, or recommended apps.\nDomain verification\nDomain verification confirms that you control the domain where your app runs. While domain verification is not required to use Phantom Connect, it is required for your app to appear in Phantomâs public discovery surfaces, including the following:\n- The Explore tab: A curated discovery surface that helps users find your app.\n- Search results: Your app appears when users search within Phantom.\n- Recommended apps: Featured placements that increase visibility.\nResources\nView Phantom Portal terms\nPhantom Developer Portal Terms of Service\nNeed help?\nContact Phantom developer support .\nGet started\nNext: Step-by-step guide for setting up your app in Phantom Portal\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.cardano.org/","domain":"docs.cardano.org","title":"Welcome to Cardano Docs | Cardano Docs","hash":"cb2d9239d861473996d12adbd509f06d72150a474856c3aa71b9f59c3821133a","tokens":280,"chars":1120,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111992196,"text":"Skip to main content\nDocumentation\nCardano ecosystem\nCardano is a decentralized, third-generation, proof-of-stake blockchain, native home to the ada cryptocurrency.\nExplore, learn, create\nYou can do wonderful things with Cardano\nLearn about Cardano\nDive into Cardano's fundamentals, from beginner explainers to in-depth coverage of core concepts, architecture and networking, and the platform's evolution.\nExplore developer resources\nLearn about Cardanoâs features and find references to developer resources, including guides and tutorials, to kickstart your development journey.\nStake pool operations\nLearn about stake pool operation basics, including node connectivity, keys, operational certificates, maintenance, and more, with references to detailed developer tutorials.\nTestnets\nGet started with Cardano's testnet environments and explore how to engage with them effectively.\nEducation\nExplore learning opportunities on Cardano, including details about the Plutus Pioneer program and other educational resources.\nBrowse more documentation websites\nCore tech:\nSmart contracts:\nScalability:\nSustainability:\nIntersect"}
{"url":"https://docs.berachain.com/general/help/faqs","domain":"docs.berachain.com","title":"Frequently Asked Questions - Berachain","hash":"a5fde971afabd7a2d3375061fb23f90a01a5c4a4dca2dce3ac27d458384c5c73","tokens":1739,"chars":6956,"crawler":"hive-genesis","verified":"unchecked","ts":1791111993973,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBerachain home page\nGeneral\nBEX\nBend\nBuild\nNodes\nHelp\nFrequently Asked Questions\nCommon questions about Berachain.\nGeneral & Network\nWhat do Berachain's performance metrics look like?\nBerachain has the following properties:\n- Block time: ~2 seconds.\n- Transactions per Second (TPS): This can vary but the following should help with the number of possible transactions (Block gas limit (30m) / Average gas limit per txn) / Block time (2s) = TPS.\n- Finality: single slot finality\n- 100% EVM compatibility\nWhat is governance?\nGovernance is the process by which the community decides what changes to make to the Berachain protocol. This includes how to upgrade the node and what parameters to set for various components on the chain.\nTokens\nWhat is the actual staking token of the network?\n$BERA is the single staking and emission token:\n- Validator staking : Node operators stake $BERA to run validators, produce blocks, and secure the chain. Additional stakers can deposit $BERA to increase a validatorâs block-production probability.\n- PoL emissions : Block rewards are emitted as $WBERA (wrapped BERA). Validators receive a base rate; the remainder is routed through BeraChef reward allocation to Reward Vaults.\n- $sWBERA : Users deposit $BERA or $WBERA into the Staking Vault to receive $sWBERA, which earns yield from the Incentive Auction.\nWhat is $BUSD?\n$BUSD was previously known as $HONEY . As of August 19, 2026 its token name and symbol have been changed to Bera USD and BUSD respectively. The contract address remains the same.\n$BUSD is the native stablecoin of the Berachain ecosystem. It is a multicollateral backed stablecoin, and is used throughout the Berachain ecosystem.\nDoes $BERA have a maximum supply?\nNo. $BERA has no hard supply cap. The genesis total supply was 500,000,000 $BERA, with ~5% annual inflation via Proof-of-Liquidity reward emissions (distributed as $WBERA), subject to governance. Transaction fees are burned, which reduces circulating supply. See the BERA token page for the full allocation and release schedule.\nWhat was $BGT?\nIt was previously used in early versions of Proof of Liquidity for governance and reward routing. Users who still hold $BGT should unstake it, redeem it 1:1 for native $BERA, and stake their $BERA for $sWBERA to participate in the current Proof of Liquidity system. See the Berachain Hub which will walk you through the process.\nDoes it cost anything to mint or burn $BUSD?\nTo ensure stability, there is a small fee on every mint and burn of $BUSD . Additionally, because minting & burning requires a transaction, there will be a small gas fee in $BERA.\nDo I need to migrate my $HONEY to $BUSD?\nNo. The August 19, 2026 change was a rename of the token name and symbol only. The contract address is unchanged, no new contract was deployed, and no migration, swap, or claim step is required. Balances, allowances, and integrations continue to work as-is. Wallets and explorers may display the token as $BUSD (Bera USD) after they refresh their token lists.\nProof of Liquidity & Validators\nWhat is a validator?\nA validator can refer to three things:\n- A blockchain node that validates transactions, produces blocks, and comes to consensus with other validators in the network\n- The entity that owns and operates the validator node\n- The blend of points #1 and #2 that manages a portion of Proof of Liquidity & Governance votes\nWhy should I stake for $sWBERA?\n$sWBERA earns yield from the Incentive Auction. Protocols fund incentive tokens to attract validator reward allocation; after validator commission, the remaining incentive tokens are redirected to IncentivesCollector . Auction buyers pay WBERA to claim those tokens, and that WBERA is split pro-rata between the $sWBERA Staking Vault and registered LST staker vaults. Holding $sWBERA gives you a share of that yield without needing to manage vault positions or validator selection.\nHow long does unstaking take?\nIt depends on what you are unstaking:\n- $sWBERA (Staking Vault) : withdrawals have a 7-day unbonding period after you queue a withdrawal request.\n- Staking pool withdrawals : requests can be finalized after a delay of 129,600 blocks (â3 days at ~2s block time). See the staking pools operator guide for details.\nCan validators with $BERA alone build blocks and what are the rewards?\nYes, validators only need to stake $BERA within the designated min and max range of 250,000 and 10,000,000 , and once in the active set they will propose blocks. Base rate reward is distributed in $WBERA.\nBEX & Liquidity\nWhat is a DEX?\nDEX stands for Decentralized Exchange. It is a place where you can buy and sell tokens directly on the chain instead of through any one centralized service. This means that all liquidity can be seen directly on-chain, and the smart contracts themselves verifiably own it. A DEX enables you to swap tokens directly from your wallet, as well as allowing anyone to launch their own tokens and provide liquidity.\nWhat is a swap?\nA swap is the process of exchanging one token for another. This can be thought of as a buy or a sell, depending on which token youâre looking at. For example, if youâre looking to buy $BERA with $ETH , you would be swapping $ETH for $BERA. This is essentially âsellingâ $ETH and âbuyingâ $BERA.\nHow much does it cost to swap?\nEach swap has a fee that varies depending on the fee set when the pool was created. Common fees are 0.05%, 0.1%, 0.3% or 1% but you should always check when performing a swap to ensure you are okay with the fee on that pool.\nWhat is liquidity?\nLiquidity is the term for the amount of a token available to swap. The more liquidity a token has, the easier it is to swap that token.\nWhat is a liquidity pool?\nLiquidity pools are pairings of 2 or more tokens that liquidity providers deposit tokens into. This enables DEX users to swap between any of the tokens in the pool.\nWhat is a liquidity provider?\nLiquidity providers deposit tokens into a liquidity pool. They earn a portion of the fees generated from swaps in the pool.\nWhat is APY?\nAPY stands for annual percentage yield. In the context of BEX pools, this refers to the current APY for a given pool. APY yield comes from fees collected on every swap made using that pool.\nOnce I provide liquidity on BEX, how do I earn rewards?\nWhen you deposit liquidity into a BEX pool, you receive an LP token representing your share of the pool. To earn Proof of Liquidity emissions, you must take that LP token and stake it into its corresponding Reward Vault. As validators direct emissions to that vault, you will accumulate claimable rewards denominated in $WBERA. You can claim $WBERA directly from the vault or through the Reward Vault Helper as $sWBERA or native BERA.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.anza.xyz/","domain":"docs.anza.xyz","title":"Home | Agave","hash":"ffa38694837027774485707cd90d0a3a47ade83b7377900dbfd7a9a672386bfe","tokens":487,"chars":1945,"crawler":"crawler-dfxz","verified":"exact","ts":1791111993889,"text":"Skip to main content\nAgave Validator Documentation\nSolana is a blockchain built for mass adoption. It's a high performance network\nthat is utilized for a range of use cases, including finance, NFTs, payments,\nand gaming. Solana operates as a single global state machine, and is open,\ninteroperable and decentralized. Agave is a fork of the original Solana validator\npreviously maintained by the Solana Labs team. Agave is now under active development by the\ncore engineering team at Anza, one of several Solana validator clients.\nCommand Line Interface and Tool Suite\nTo get started using the Solana Command Line (CLI) tools:\n- Install the Solana CLI Tool Suite - Quickly get setup\nlocally with the CLI, optionally build from source\n- Introduction to the CLI conventions - Understand the common\nconventions used within the CLI tool suite\n- Choose a cluster - Select a Solana\nnetwork cluster to connect (e.g. devnet , testnet , mainnet-beta )\n- Create a wallet - Create a command line wallet for\nuse within the CLI and beyond\nUnderstanding the Architecture\nGet to know the underlying architecture of how the proof-of-stake blockchain\nworks:\n- Clusters - a collection of validators that work\ntogether for consensus\n- Validators - the individual nodes that are the\nbackbone of the network\n- Runtime - the native programs that are core to the\nvalidator and the blockchain\nRunning a Validator\nExplore what it takes to operate an Agave validator and help secure the network.\n- Validator vs RPC node - Understand\nthe important differences between voting and non-voting validators on the\nnetwork\n- System requirements - Recommended hardware\nrequirements and expected SOL needed to operate a validator\n- Quick start guide - Setup a validator and\nget connected to a cluster for the first time\nLearn more\nDevelopers\nOperate a Validator\nArchitecture\n- Command Line Interface and Tool Suite\n- Understanding the Architecture\n- Running a Validator\n- Learn more"}
{"url":"https://docs.soliditylang.org/en/latest/","domain":"docs.soliditylang.org","title":"Solidity â Solidity 0.8.38-develop documentation","hash":"8dd418bd9ce3d9bcd141389f904b41a9df4ad1bcc0281c6165124b050f60acf0","tokens":2436,"chars":9741,"crawler":"crawler-dfxz","verified":"exact","ts":1791111995828,"text":"-\n- Solidity\n-\nEdit on GitHub\nSolidity ï\nSolidity is an object-oriented, high-level language for implementing smart contracts.\nSmart contracts are programs that govern the behavior of accounts within the Ethereum state.\nSolidity is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM).\nIt is influenced by C++, Python, and JavaScript.\nYou can find more details about which languages Solidity has been inspired by in the language influences section.\nSolidity is statically typed, supports inheritance, libraries, and complex user-defined types, among other features.\nWith Solidity, you can create contracts for uses such as voting, crowdfunding, blind auctions, and multi-signature wallets.\nWhen deploying contracts, you should use the latest released version of Solidity.\nApart from exceptional cases, only the latest version receives\nsecurity fixes .\nFurthermore, breaking changes, as well as new features, are introduced regularly.\nWe currently use a 0.y.z version number to indicate this fast pace of change .\nWarning\nSolidity recently released the 0.8.x version that introduced a lot of breaking changes.\nMake sure you read the full list .\nIdeas for improving Solidity or this documentation are always welcome,\nread our contributors guide for more details.\nHint\nYou can download this documentation as PDF, HTML or Epub\nby clicking on the versions flyout menu in the bottom-right corner and selecting the preferred download format.\nGetting Started ï\n1. Understand the Smart Contract Basics\nIf you are new to the concept of smart contracts, we recommend you to get started by digging into the âIntroduction to Smart Contractsâ section, which covers the following:\n-\nA simple example smart contract written in Solidity.\n-\nBlockchain Basics .\n-\nThe Ethereum Virtual Machine .\n2. Get to Know Solidity\nOnce you are accustomed to the basics, we recommend you read the âSolidity by Exampleâ\nand âLanguage Descriptionâ sections to understand the core concepts of the language.\n3. Install the Solidity Compiler\nThere are various ways to install the Solidity compiler,\nsimply choose your preferred option and follow the steps outlined on the installation page .\nHint\nYou can try out code examples directly in your browser with the\nRemix IDE .\nRemix is a web browser-based IDE that allows you to write, deploy and administer Solidity smart contracts,\nwithout the need to install Solidity locally.\nWarning\nAs humans write software, it can have bugs.\nTherefore, you should follow established software development best practices when writing your smart contracts.\nThis includes code review, testing, audits, and correctness proofs.\nSmart contract users are sometimes more confident with code than their authors,\nand blockchains and smart contracts have their own unique issues to watch out for,\nso before working on production code, make sure you read the Security Considerations section.\n4. Learn More\nIf you want to learn more about building decentralized applications on Ethereum,\nthe Ethereum Developer Resources can help you with further general documentation around Ethereum,\nand a wide selection of tutorials, tools, and development frameworks.\nIf you have any questions, you can try searching for answers or asking on the\nEthereum StackExchange ,\nor our Gitter channel .\nTranslations ï\nCommunity contributors help translate this documentation into several languages.\nNote that they have varying degrees of completeness and up-to-dateness.\nThe English version stands as a reference.\nYou can switch between languages by clicking on the flyout menu in the bottom-right corner\nand selecting the preferred language.\n-\nChinese\n-\nFrench\n-\nIndonesian\n-\nJapanese\n-\nKorean\n-\nPersian\n-\nRussian\n-\nSpanish\n-\nTurkish\nNote\nWe set up a GitHub organization and translation workflow to help streamline the community efforts.\nPlease refer to the translation guide in the solidity-docs org\nfor information on how to start a new language or contribute to the community translations.\nContents ï\nKeyword Index , Search Page\nBasics\n- Introduction to Smart Contracts\n- A Simple Smart Contract\n- Blockchain Basics\n- The Ethereum Virtual Machine\n- Solidity by Example\n- Voting\n- Blind Auction\n- Safe Remote Purchase\n- Micropayment Channel\n- Modular Contracts\n- Installing the Solidity Compiler\n- Versioning\n- Remix\n- npm / Node.js\n- Docker\n- Linux Packages\n- macOS Packages\n- Static Binaries\n- Building from Source\n- CMake Options\n- The Version String in Detail\n- Important Information About Versioning\nLanguage Description\n- Layout of a Solidity Source File\n- SPDX License Identifier\n- Pragmas\n- Importing other Source Files\n- Comments\n- Structure of a Contract\n- State Variables\n- Functions\n- Function Modifiers\n- Events\n- Errors\n- Struct Types\n- Enum Types\n- Types\n- Value Types\n- Reference Types\n- Mapping Types\n- Operators\n- Conversions between Elementary Types\n- Conversions between Literals and Elementary Types\n- Units and Globally Available Variables\n- Ether Units\n- Time Units\n- Special Variables and Functions\n- Reserved Keywords\n- Expressions and Control Structures\n- Control Structures\n- Function Calls\n- Creating Contracts via new\n- Order of Evaluation of Expressions\n- Assignment\n- Scoping and Declarations\n- Checked or Unchecked Arithmetic\n- Error handling: Assert, Require, Revert and Exceptions\n- Contracts\n- Creating Contracts\n- Visibility and Getters\n- Function Modifiers\n- Transient Storage\n- Composability of Smart Contracts and the Caveats of Transient Storage\n- Constant and Immutable State Variables\n- Custom Storage Layout\n- Functions\n- Events\n- Custom Errors\n- Inheritance\n- Abstract Contracts\n- Interfaces\n- Libraries\n- Using For\n- Inline Assembly\n- Example\n- Access to External Variables, Functions and Libraries\n- Things to Avoid\n- Conventions in Solidity\n- Advanced Safe Use of Memory\n- Cheatsheet\n- Order of Precedence of Operators\n- ABI Encoding and Decoding Functions\n- Members of bytes and string\n- Members of address\n- Block and Transaction Properties\n- Validations and Assertions\n- Mathematical and Cryptographic Functions\n- Contract-related\n- Type Information\n- Function Visibility Specifiers\n- Modifiers\n- Language Grammar\n- SolidityParser\n- SolidityLexer\nCompiler\n- Using the Compiler\n- Using the Commandline Compiler\n- Setting the EVM Version to Target\n- Compiler Input and Output JSON Description\n- Experimental Mode\n- Analysing the Compiler Output\n- Solidity IR-based Codegen Changes\n- Semantic Only Changes\n- Internals\nInternals\n- Layout of State Variables in Storage and Transient Storage\n- Mappings and Dynamic Arrays\n- JSON Output\n- Layout in Memory\n- Differences to Layout in Storage\n- Layout of Call Data\n- Cleaning Up Variables\n- Source Mappings\n- The Optimizer\n- Benefits of Optimizing Solidity Code\n- Differences between Optimized and Non-Optimized Code\n- Optimizer Parameter Runs\n- Opcode-Based Optimizer Module\n- Yul-Based Optimizer Module\n- Codegen-Based Optimizer Module\n- Contract Metadata\n- Encoding of the Metadata Hash in the Bytecode\n- Usage for Automatic Interface Generation and NatSpec\n- Usage for Source Code Verification\n- Contract ABI Specification\n- Basic Design\n- Function Selector\n- Argument Encoding\n- Types\n- Design Criteria for the Encoding\n- Formal Specification of the Encoding\n- Function Selector and Argument Encoding\n- Examples\n- Use of Dynamic Types\n- Events\n- Errors\n- JSON\n- Strict Encoding Mode\n- Non-standard Packed Mode\n- Encoding of Indexed Event Parameters\nAdvisory content\n- Security Considerations\n- Pitfalls\n- Recommendations\n- List of Known Bugs\n- Frequently Reported Non-Bugs\n- Non-canonical ABI-encoded calldata is accepted\n- Different results between the evmasm and the IR pipeline\n- Order of evaluation\n- Stale references into storage\n- Solidity v0.5.0 Breaking Changes\n- Semantic Only Changes\n- Semantic and Syntactic Changes\n- Explicitness Requirements\n- Deprecated Elements\n- Interoperability With Older Contracts\n- Example\n- Solidity v0.6.0 Breaking Changes\n- Changes the Compiler Might not Warn About\n- Explicitness Requirements\n- Semantic and Syntactic Changes\n- New Features\n- Interface Changes\n- How to update your code\n- Solidity v0.7.0 Breaking Changes\n- Silent Changes of the Semantics\n- Changes to the Syntax\n- Removal of Unused or Unsafe Features\n- Interface Changes\n- How to update your code\n- Solidity v0.8.0 Breaking Changes\n- Silent Changes of the Semantics\n- New Restrictions\n- Interface Changes\n- How to update your code\nAdditional Material\n- NatSpec Format\n- Documentation Example\n- Tags\n- Documentation Output\n- SMTChecker and Formal Verification\n- Tutorial\n- SMTChecker Options and Tuning\n- Abstraction and False Positives\n- Real World Assumptions\n- Yul\n- Motivation and High-level Description\n- Simple Example\n- Stand-Alone Usage\n- Informal Description of Yul\n- Specification of Yul\n- Specification of Yul Object\n- Yul Optimizer\n- Complete ERC20 Example\n- Import Path Resolution\n- Virtual Filesystem\n- Imports\n- Base Path and Include Paths\n- Allowed Paths\n- Import Remapping\n- Using URLs in imports\nResources\n- Style Guide\n- Introduction\n- Code Layout\n- Order of Layout\n- Naming Conventions\n- NatSpec\n- Common Patterns\n- Withdrawal from Contracts\n- Restricting Access\n- State Machine\n- Resources\n- General Resources\n- Integrated (Ethereum) Development Environments\n- Editor Integrations\n- Solidity Tools\n- Third-Party Solidity Parsers and Grammars\n- Contributing\n- Team Calls\n- How to Report Issues\n- Workflow for Pull Requests\n- AI-Assisted Contributions\n- Running the Compiler Tests\n- Running the Fuzzer via AFL\n- Whiskers\n- Documentation Style Guide\n- Solidity Language Design\n- Language Influences\n- Solidity Brand Guide\n- The Solidity Brand\n- Solidity Brand Name\n- Solidity Logo License\n- Solidity Logo Guidelines\n- Credits"}
{"url":"https://wormhole.com/docs/","domain":"wormhole.com","title":"Wormhole Docs","hash":"e32fd25d855cd305048f55eff8fa87131655c2246c4de4276f725b1b401c124b","tokens":338,"chars":1351,"crawler":"hive-genesis","verified":"unchecked","ts":1791111995810,"text":"Initializing search\n- Configuration\n- Concepts\n- FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Portal Bridge\n- Connect\n- Guides\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Settlement\n- FAQs\n- Reference\n- Messaging\n- Interact with Core Contracts\n- Query NTT Data and Transfers\n- Concepts\n- Tutorials\n- Reference\n- Protocol\n- Infrastructure Guides\n- Developer Tools\n- Wormhole CLI\n- Wormholescan Explorer\n- Wormholescan API\n- Reference\n- AI Resources\nPage Actions\nEdit this page\nWormhole Documentation\nAccess all the information and resources you need to develop secure multichain applications powered by Wormhole.\nExplore by Product\nNTT (Native Token Transfers)\nMove native tokens across chains.\nSettlement\nBridge faster with intent-based routing.\nConnect\nDrop a bridging widget into your app.\nMessaging\nSend verified cross-chain messages.\nQueries\nRetrieve on-chain data on demand.\nMultiGov\nCreate governance solutions.\nLevel Up with Tutorials\nCreate Token Transfer Workflows\nUse the Wormhole TypeScript SDK and Token Bridge to power cross-chain token transfers.\nCreate a React Bridging App\nLeverage Connect to build a complete UI for multichain transactions with minimal setup.\nCreate Messaging Contracts\nDeploy contracts on two testnets and learn how to send and receive messages across chains."}
{"url":"https://docs.pyth.network/","domain":"docs.pyth.network","title":"Pyth Developer Hub","hash":"95ccd773aac6c27b7a91043b966570faf6b10f8c7b638561c2e23a465cd6ea08","tokens":364,"chars":1456,"crawler":"hive-genesis","verified":"unchecked","ts":1791111997622,"text":"Feed updates\nCommodities.RSV6/USc removed Commodities.BRENTX6/USD removed Crypto.ORBIO/USD added Equity.CN.603416/CNY added Equity.CN.603906/CNY added Equity.CN.300376/CNY added Equity.CN.002683/CNY added Equity.TW.8046/TWD added Equity.TW.2408/TWD added Equity.CN.300308/CNY added Equity.TW.2451/TWD added Equity.TW.2344/TWD added Equity.US.IBB/USD added Crypto.Index.ZTPLUS/USD added\nView all\nDeveloper Hub\nIntegrate with the global price layer.\nPyth Core was upgraded on August 26, 2026\nHermes now requires an API Key â register if you haven't yet\nLearn more\nProducts\nConnect to the global market data and randomness layer.\nPyth Pro\nSubscription-based price data for institutions and advanced use cases. Previously known as Lazer.\nFEATURES\nUltra-low latency\nCrypto, Equities & Indexes\nCustomizable channels and latency\nDedicated support\nQUICK LINKS\nGet Pyth Pro API Key Browse Supported Feeds Pricing\nEntropy\nSecure, Verifiable Random Number Generator for EVM-based smart contracts.\nFEATURES\nOn-chain randomness\nVerifiable results\nPay in native token\nSupports 20+ EVM chains\nQUICK LINKS\nChainlist Protocol Design Entropy Explorer\nResources for Developers\nExplore the Pyth Network for developers\nGet Your API Key\nRequest access for the Pyth Ultra Low Latency price feeds.\nLink\nSupported Feeds -- Pyth Pro\nExplore the complete list of supported price feeds for Pyth Pro.\nLink\nAPI Reference -- Pyth Pro\nExplore the complete API reference for Pyth Pro.\nLink"}
{"url":"https://docs.filecoin.io/","domain":"docs.filecoin.io","title":"Welcome to Filecoin Docs | Filecoin Docs","hash":"5a57fc3d653c027fc6a255b356beedb1bff0eac53c6a4f59c32652dd61a8f824","tokens":320,"chars":1279,"crawler":"crawler-dfxz","verified":"exact","ts":1791111997879,"text":"Filecoin Docs\nâ Ctrl k\nBasics Storage providers Nodes Networks Smart contracts Reference\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nWelcome to Filecoin Docs\nFilecoin is a decentralized, peer-to-peer network enabling anyone to store and retrieve data over the internet. Economic incentives are built in, ensuring files are stored and accessible reliably over\nChoose your own path to start exploring Filecoin:\nđĄ Get started\nNew to Filecoin and looking for foundational concepts? Start with the Getting Started section to understand the essentials and kick off your journey!\nđ§ Build on Filecoin\nReady to develop on the Filecoin network? Head to the Build on Filecoin section for smart contracts, storage integrations, and Filecoin Onchain Cloud.\nâïž Filecoin Onchain Cloud\nStore and retrieve application data with verifiable storage, automated payments, and the Synapse SDK.\nđïž Provide storage\nThinking about running a provider node on Filecoin? Visit the Provide Storage section for comprehensive guidance on getting started.\nđ Store data\nLooking to store large volumes of data? See how storage works to review the various storage options Filecoin offers.\nWas this page helpful?\nNext What is Filecoin\nLast updated 3 months ago"}
{"url":"https://docs.soliditylang.org/en/latest/metadata.html","domain":"docs.soliditylang.org","title":"Contract Metadata â Solidity 0.8.38-develop documentation","hash":"1d1400377c9ae0ff8c6217c181700d0c087b1de6d5399f7749d79965621b4489","tokens":2745,"chars":10979,"crawler":"hive-genesis","verified":"exact","ts":1791111999399,"text":"-\n- Contract Metadata\n-\nEdit on GitHub\nContract Metadata ï\nThe Solidity compiler automatically generates a JSON file.\nThe file contains two kinds of information about the compiled contract:\n-\nHow to interact with the contract: ABI, and NatSpec documentation.\n-\nHow to reproduce the compilation and verify a deployed contract:\ncompiler version, compiler settings, and source files used.\nThe compiler appends by default the IPFS hash of the metadata file to the end\nof the runtime bytecode (not necessarily the creation bytecode) of each contract,\nso that, if published, you can retrieve the file in an authenticated way without\nhaving to resort to a centralized data provider. The other available options are\nthe Swarm hash and not appending the metadata hash to the bytecode. These can be\nconfigured via the Standard JSON Interface .\nYou have to publish the metadata file to IPFS, Swarm, or another service so\nthat others can access it. You create the file by using the solc --metadata\ncommand together with the --output-dir parameter. Without the parameter,\nthe metadata will be written to standard output.\nThe metadata contains IPFS and Swarm references to the source code, so you have to\nupload all source files in addition to the metadata file. For IPFS, the hash contained\nin the CID returned by ipfs add (not the direct sha2-256 hash of the file)\nshall match with the one contained in the bytecode.\nThe metadata file has the following format. The example below is presented in a\nhuman-readable way. Properly formatted metadata should use quotes correctly,\nreduce whitespace to a minimum, and sort the keys of all objects in alphabetical order\nto arrive at a canonical formatting. Comments are not permitted and are used here only for\nexplanatory purposes.\n{\n// Required: Details about the compiler, contents are specific\n// to the language.\n\"compiler\" : {\n// Optional: Hash of the compiler binary which produced this output\n\"keccak256\" : \"0x123...\" ,\n// Required for Solidity: Version of the compiler\n\"version\" : \"0.8.2+commit.661d1103\"\n},\n// Required: Source code language, basically selects a \"sub-version\"\n// of the specification\n\"language\" : \"Solidity\" ,\n// Required: Generated information about the contract.\n\"output\" : {\n// Required: ABI definition of the contract. See \"Contract ABI Specification\"\n\"abi\" : [ /* ... */ ],\n// Required: NatSpec developer documentation of the contract. See https://docs.soliditylang.org/en/latest/natspec-format.html for details.\n\"devdoc\" : {\n// Contents of the @author NatSpec field of the contract\n\"author\" : \"John Doe\" ,\n// Contents of the @dev NatSpec field of the contract\n\"details\" : \"Interface of the ERC20 standard as defined in the EIP. See https://eips.ethereum.org/EIPS/eip-20 for details\" ,\n\"errors\" : {\n\"MintToZeroAddress()\" : {\n\"details\" : \"Cannot mint to zero address\"\n}\n},\n\"events\" : {\n\"Transfer(address,address,uint256)\" : {\n\"details\" : \"Emitted when `value` tokens are moved from one account (`from`) toanother (`to`).\" ,\n\"params\" : {\n\"from\" : \"The sender address\" ,\n\"to\" : \"The receiver address\" ,\n\"value\" : \"The token amount\"\n}\n},\n\"kind\" : \"dev\" ,\n\"methods\" : {\n\"transfer(address,uint256)\" : {\n// Contents of the @dev NatSpec field of the method\n\"details\" : \"Returns a boolean value indicating whether the operation succeeded. Must be called by the token holder address\" ,\n// Contents of the @param NatSpec fields of the method\n\"params\" : {\n\"_value\" : \"The amount tokens to be transferred\" ,\n\"_to\" : \"The receiver address\"\n},\n// Contents of the @return NatSpec field.\n\"returns\" : {\n// Return var name (here \"success\") if exists. \"_0\" as key if return var is unnamed\n\"success\" : \"a boolean value indicating whether the operation succeeded\"\n}\n},\n\"stateVariables\" : {\n\"owner\" : {\n// Contents of the @dev NatSpec field of the state variable\n\"details\" : \"Must be set during contract creation. Can then only be changed by the owner\"\n}\n},\n// Contents of the @title NatSpec field of the contract\n\"title\" : \"MyERC20: an example ERC20\" ,\n\"version\" : 1 // NatSpec version\n},\n// Required: NatSpec user documentation of the contract. See \"NatSpec Format\"\n\"userdoc\" : {\n\"errors\" : {\n\"ApprovalCallerNotOwnerNorApproved()\" : [\n{\n\"notice\" : \"The caller must own the token or be an approved operator.\"\n}\n]\n},\n\"events\" : {\n\"Transfer(address,address,uint256)\" : {\n\"notice\" : \"`_value` tokens have been moved from `from` to `to`\"\n}\n},\n\"kind\" : \"user\" ,\n\"methods\" : {\n\"transfer(address,uint256)\" : {\n\"notice\" : \"Transfers `_value` tokens to address `_to`\"\n}\n},\n\"version\" : 1 // NatSpec version\n}\n},\n// Required: Compiler settings.\n// Reflects the settings in the JSON input during compilation, except:\n// - Different format: \"libraries\" field\n// - Added field in metadata.settings: \"compilationTarget\"\n// - Not in metadata.settings: \"stopAfter\", \"debug.debugInfo\", \"outputSelection\"\n// See the standard JSON input's \"settings\" field docs for the rest.\n\"settings\" : {\n// Required for Solidity: File path and the name of the contract or library this\n// metadata is created for. This field is not present in the standard JSON input settings.\n\"compilationTarget\" : {\n\"myDirectory/myFile.sol\" : \"MyContract\"\n},\n// Optional (false if omitted): Indicates whether experimental mode has been enabled.\n// Always matches the value of the `experimental` flag in CBOR metadata.\n// Note that experimental mode being enabled does not necessarily mean that any\n// experimental features were actually used, or if they were, that those features\n// affected the bytecode.\n\"experimental\" : true ,\n// Required for Solidity: Addresses for libraries used.\n// Note that metadata has a different format for \"libraries\" field than the standard JSON input.\n// metadata format = { \"MyLib.sol:MyLib\": \"0x123123...\" }\n// standard JSON input format = { \"MyLib.sol\": { \"MyLib\": \"0x123123...\" } }\n\"libraries\" : {\n\"MyLib.sol:MyLib\" : \"0x123123...\"\n},\n// ...\n// The rest of the fields and their defaults same as in std JSON input.\n},\n// Required: Compilation source files/source units, keys are file paths\n\"sources\" : {\n\"settable\" : {\n// Required (unless \"url\" is used): literal contents of the source file\n\"content\" : \"contract settable is owned { uint256 private x = 0; function set(uint256 _x) public { if (msg.sender == owner) x = _x; } }\" ,\n// Required: keccak256 hash of the source file\n\"keccak256\" : \"0x234...\"\n},\n\"myDirectory/myFile.sol\" : {\n// Required: keccak256 hash of the source file\n\"keccak256\" : \"0x123...\" ,\n// Optional: SPDX license identifier as given in the source file\n\"license\" : \"MIT\" ,\n// Required (unless \"content\" is used, see above): Sorted URL(s)\n// to the source file, protocol is more or less arbitrary, but an\n// IPFS URL is recommended\n\"urls\" : [ \"bzz-raw://7d7a...\" , \"dweb:/ipfs/QmN...\" ]\n}\n},\n// Required: The version of the metadata format\n\"version\" : 1\n}\nWarning\nSince the bytecode of the resulting contract contains the metadata hash by default, any\nchange to the metadata might result in a change of the bytecode. This includes\nchanges to a filename or path, and since the metadata includes a hash of all the\nsources used, a single whitespace change results in different metadata, and\ndifferent bytecode.\nNote\nThe ABI definition above has no fixed order. It can change with compiler versions.\nStarting from Solidity version 0.5.12, though, the array maintains a certain\norder.\nEncoding of the Metadata Hash in the Bytecode ï\nThe compiler currently by default appends the\nIPFS hash (in CID v0)\nof the canonical metadata file and the compiler version to the end of the bytecode.\nOptionally, a Swarm hash instead of the IPFS, or an experimental flag is used.\nBelow are all the possible fields:\n{\n// Present if \"bytecodeHash\" was \"ipfs\" in compiler settings\n\"ipfs\" : \"\" ,\n// Present if \"bytecodeHash\" was \"bzzr1\" in compiler settings\n\"bzzr1\" : \"\" ,\n// Previous versions were using \"bzzr0\" instead of \"bzzr1\"\n\"bzzr0\" : \"\" ,\n// Present if experimental mode has been enabled either via \"--experimental\" flag or\n// \"settings.experimental\" option in Standard JSON\n\"experimental\" : true ,\n\"solc\" : \"\"\n}\nBecause we might support other ways to retrieve the\nmetadata file in the future, this information is stored\nCBOR -encoded. The last two bytes in the bytecode\nindicate the length of the CBOR encoded information. By looking at this length, the\nrelevant part of the bytecode can be decoded with a CBOR decoder.\nCheck the Metadata Playground to see it in action.\nWhereas release builds of solc use a 3 byte encoding of the version as shown\nabove (one byte each for major, minor and patch version number), pre-release builds\nwill instead use a complete version string including commit hash and build date.\nThe commandline flag --no-cbor-metadata can be used to skip metadata\nfrom getting appended at the end of the deployed bytecode. Equivalently, the\nboolean field settings.metadata.appendCBOR in Standard JSON input can be set to false.\nNote\nThe CBOR mapping can also contain other keys, so it is better to fully\ndecode the data by looking at the end of the bytecode for the CBOR length,\nand to use a proper CBOR parser. Do not rely on it starting with 0xa264\nor 0xa2 0x64 'i' 'p' 'f' 's' .\nUsage for Automatic Interface Generation and NatSpec ï\nThe metadata is used in the following way: A component that wants to interact\nwith a contract (e.g. a wallet) retrieves the code of the contract.\nIt decodes the CBOR encoded section containing the IPFS/Swarm hash of the\nmetadata file. With that hash, the metadata file is retrieved. That file\nis JSON-decoded into a structure like above.\nThe component can then use the ABI to automatically generate a rudimentary\nuser interface for the contract.\nFurthermore, the wallet can use the NatSpec user documentation to display a\nhuman-readable confirmation message to the user whenever they interact with\nthe contract, together with requesting authorization for the transaction signature.\nFor additional information, read Ethereum Natural Language Specification (NatSpec) format .\nUsage for Source Code Verification ï\nIf pinned/published, it is possible to retrieve the metadata of the contract from IPFS/Swarm.\nThe metadata file also contains the URLs or the IPFS hashes of the source files, as well as\nthe compilation settings, i.e. everything needed to reproduce a compilation.\nWith this information it is then possible to verify the source code of a contract by\nreproducing the compilation, and comparing the bytecode from the compilation with\nthe bytecode of the deployed contract.\nThis automatically verifies the metadata since its hash is part of the bytecode, as well\nas the source codes, because their hashes are part of the metadata. Any change in the files\nor settings would result in a different metadata hash. The metadata here serves\nas a fingerprint of the whole compilation.\nSourcify makes use of this feature for âfull/perfect verificationâ,\nas well as pinning the files publicly on IPFS to be accessed with the metadata hash."}
{"url":"https://docs.anza.xyz/validator/anatomy","domain":"docs.anza.xyz","title":"Anatomy of a Validator | Agave","hash":"b2c4c56bd245b651fb5c783df3d6c46825ec0a4157a9b1b16437cac4b12d101c","tokens":401,"chars":1602,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111999357,"text":"Skip to main content\nAnatomy of a Validator\nPipelining\nThe validators make extensive use of an optimization common in CPU design, called pipelining . Pipelining is the right tool for the job when there's a stream of input data that needs to be processed by a sequence of steps, and there's different hardware responsible for each. The quintessential example is using a washer and dryer to wash/dry/fold several loads of laundry. Washing must occur before drying and drying before folding, but each of the three operations is performed by a separate unit. To maximize efficiency, one creates a pipeline of stages . We'll call the washer one stage, the dryer another, and the folding process a third. To run the pipeline, one adds a second load of laundry to the washer just after the first load is added to the dryer. Likewise, the third load is added to the washer after the second is in the dryer and the first is being folded. In this way, one can make progress on three loads of laundry simultaneously. Given infinite loads, the pipeline will consistently complete a load at the rate of the slowest stage in the pipeline.\nPipelining in the Validator\nThe validator contains two pipelined processes, one used in leader mode called the TPU and one used in validator mode called the TVU. In both cases, the hardware being pipelined is the same, the network input, the GPU cards, the CPU cores, writes to disk, and the network output. What it does with that hardware is different. The TPU exists to create ledger entries whereas the TVU exists to validate them.\n- Pipelining\n- Pipelining in the Validator"}
{"url":"https://raw.githubusercontent.com/solana-foundation/anchor/master/README.md","domain":"raw.githubusercontent.com","title":"scaffold a fuzz harness","hash":"1ce3ec6d41206da23cb752d6094fc89ec80d684ed83939874f3d66745693140e","tokens":1692,"chars":6766,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112001256,"text":", start: u64) -> Result<()> {\nlet counter = &mut ctx.accounts.counter;\ncounter.authority = *ctx.accounts.authority.key;\ncounter.count = start;\nOk(())\n}\npub fn increment(ctx: Context) -> Result<()> {\nlet counter = &mut ctx.accounts.counter;\ncounter.count += 1;\nOk(())\n}\n#[derive(Accounts)]\npub struct Initialize<'info> {\n#[account(init, payer = authority, space = 48)]\npub counter: Account<'info, Counter>,\npub authority: Signer<'info>,\npub system_program: Program<'info, System>,\n}\n#[derive(Accounts)]\npub struct Increment<'info> {\n#[account(mut, has_one = authority)]\npub counter: Account<'info, Counter>,\npub authority: Signer<'info>,\n}\n#[account]\npub struct Counter {\npub authority: Pubkey,\npub count: u64,\n}\n```\nFor more, see the [examples](https://github.com/otter-sec/anchor/tree/master/examples)\nand [tests](https://github.com/otter-sec/anchor/tree/master/tests) directories.\n## Fuzzing\n`anchor fuzz` integrates [Crucible](https://github.com/asymmetric-research/crucible) for coverage-guided program fuzzing. See the [fuzzing docs](https://anchor-lang.com/docs/testing/fuzzing) or the [Crucible docs](https://github.com/asymmetric-research/crucible#quick-start).\n```sh\n# scaffold a fuzz harness\nanchor fuzz init program_name\n# run a fuzz test\nanchor fuzz run program_name test_name --release\n```\n## License\nAnchor is licensed under [Apache 2.0](./LICENSE).\nUnless you explicitly state otherwise, any contribution intentionally submitted\nfor inclusion in Anchor by you, as defined in the Apache-2.0 license, shall be\nlicensed as above, without any additional terms or conditions.\nThis code is provided as-is, without warranties or liability.\n## Contribution\nThank you for your interest in contributing to Anchor!\nPlease see the [CONTRIBUTING.md](./CONTRIBUTING.md) to learn how.\n### Thanks â€ïž\n/ prefix\nImage generation image.generation POST /v1/images/generations OpenAI gpt-image-1\nSolana RPC + DAS solana.rpc POST /v1/solana/rpc Operator-configured RPC provider (DAS methods pass through)\nBoth surfaces reach the same services:\n- OpenAI-compatible HTTP ( /v1/* ) â point any OpenAI SDK or AI framework at Nori with baseURL . This is the surface most consumer agents use.\n- A2A JSON-RPC ( /a2a ) â programmatic agent-to-agent calls. Discovery starts at GET /.well-known/agent-card.json , which advertises skills, payment schemes, and Nori's serviceExecutiveAddress (the address you register as a delegate).\nHow Nori Payments Work\nNori picks a payment rail per call: delegate-pay when the caller has onboarded, x402 otherwise.\nRail When it fires How it settles\nDelegate-pay (primary) Caller presents a valid bearer token and Nori is a registered execution delegate on the caller's agent asset Nori signs an MPL Core Execute transaction transferring SOL from the caller's PDA to Nori's service PDA, with a Memo receipt â no payment round-trip\nx402 v2 (fallback) No bearer token, invalid token, or delegation not set up First request returns HTTP 402 with payment requirements; caller pays (SOL or USDC), retries, and receives the cached result\nThe delegate-pay rail is what makes Nori invisible to your agent's end users: after a one-time delegation , every call settles automatically with no wallet prompts and no over-quoted holds. Pricing is published on a versioned rate card with a price-change notice policy.\nNori as a Single Point of Failure\nA delegated agent that sources its inference, image generation, and RPC from Nori has made Nori a single point of failure: if Nori is unavailable, the agent loses those capabilities until Nori recovers. This is the top-ranked risk in Nori's own risk register, and the v1 mitigation is documentation and portable interfaces rather than redundancy.\nPlan for it explicitly:\n- Interfaces are portable by design. chat.completion is canonical OpenAI wire format and solana.rpc is standard Solana JSON-RPC. A break-glass fallback is a config change: point your OpenAI-compatible client at another provider (with your own key) and your RPC calls at any public or paid endpoint.\n- Keep break-glass credentials. Zero-BYOK is Nori's convenience, not a requirement of your architecture. Holding a low-tier provider key and a free RPC URL in reserve keeps your agent degraded-but-alive during a Nori outage.\n- The x402 rail is an independent fallback for payment, not availability. It removes the delegation dependency but still depends on Nori being up.\n- Delegation is revocable at any time. If you migrate off Nori, the asset owner revokes the delegation record and the delegate-pay rail hard-stops .\nSelf-hosting is deferred to v2\nRunning your own Nori instance (eliminating the shared dependency entirely) is planned for v2. In v1, the mitigation is the portable OpenAI/JSON-RPC interfaces above â design your agent so Nori's base URL is a config value, not an assumption.\nUsing Nori as a Reference Implementation\nNori is the working blueprint for a Metaplex service agent â an agent that charges other agents for work. The source repository demonstrates each pattern end-to-end:\nPattern What Nori demonstrates\nAgent card discovery /.well-known/agent-card.json advertising skills, payment schemes, serviceAssetAddress , and serviceExecutiveAddress\nDelegate-pay billing Charging a caller's PDA via MPL Core Execute CPI with Memo receipts, with a 5-minute delegate-status cache\nx402 v2 fallback Canonical HTTP 402 flow with facilitator endpoints ( /verify , /settle ) and facilitator-as-feePayer so callers need no SOL for network fees\nRate card publication GET /rate-card serving a versioned pricebook with a notice-period policy\nCharge-on-success accounting Upstream call first, charge second; failed calls return errors with no charge\nFree delegation onboarding Strictly-validated POST /v1/delegate/submit that co-signs the caller's delegation transaction as fee payer\nTo add a new paid service in your own fork: write a payment-agnostic handler that returns a result plus costUsd , add pricing to the pricebook, wire it into the A2A skill dispatch, and declare it on the agent card.\nQuick Reference\nItem Value\nAgent card GET /.well-known/agent-card.json\nRate card GET /rate-card\nServices chat.completion , image.generation , solana.rpc\nOpenAI-compatible base URL /v1\nA2A endpoint POST /a2a (JSON-RPC 2.0, message/send )\nPayment rails Delegate-pay (primary), x402 v2 (fallback)\nDelegation program mpl-agent-tools â TLREGni9ZEyGC3vnPZtqUh95xQ8oPqJSvNjvB7FGK8S\nSource GitHub\nNotes\n- Nori's deployed base URL is published via its agent registration; examples across this section use NORI_URL as a placeholder for the base URL\n- Charges are priced in USD and converted to SOL at charge time using the live Jupiter SOL/USD price (30-second cache) â see Pricing and Billing\n- Delegation grants Nori billing authority over your agent's PDA wallet. Keep only a working balance there and audit the Memo receipts on each charge\n- message/sendStream is declared on the agent card but returns 501 in v1; A2A calls are synchronous\n- Nori (the hosted Metaplex service) and agent-plumber (the open-source implementation) are the same codebase; this documentation uses \"Nori\" for both\nMaintained by Metaplex Foundation. Last verified: 2026-07-08.\nFAQ\nCommon questions about Nori.\nWhat is Nori?\nNori is a pay-as-you-go service agent operated by the Metaplex Foundation. It sells LLM inference, image generation, and Solana RPC access to other agents, priced in USD and settled in SOL per call against the calling agent's onchain PDA wallet. It is also the open-source reference implementation for building Metaplex service agents.\nDo I need my own LLM provider API keys to use Nori?\nNo. Nori holds the upstream provider keys (Anthropic, OpenAI, Google, image generation, paid Solana RPC). A consumer agent only needs a Solana keypair and a registered agent asset â every call settles per-use in SOL against the agent's PDA wallet.\nWhat happens to my agent if Nori goes down?\nA delegated agent that relies on Nori for inference, images, or RPC loses those capabilities while Nori is unavailable. Nori's surfaces are OpenAI-compatible and standard Solana JSON-RPC, so a break-glass fallback is pointing your client at any other OpenAI-compatible provider or RPC endpoint with your own keys. Self-hosting your own Nori instance is planned for v2.\nIs delegating to Nori safe? Can Nori drain my wallet?\nDelegation grants Nori billing authority over your agent's PDA wallet, so only keep a working balance there. Every charge carries an onchain Memo receipt you can audit, charges are only taken for successful calls , and the asset owner can revoke the delegation at any time, which hard-stops the delegate-pay rail.\nWhat is the difference between the delegate-pay rail and the x402 rail?\nDelegate-pay is the primary rail â after a one-time onchain delegation, Nori charges your agent's PDA directly per call with no payment round-trip. x402 is the fallback for non-delegated callers â the first request returns HTTP 402 with payment requirements, the caller pays (SOL or USDC), then retries.\nGlossary\nCore terms used across the Nori documentation.\nTerm Definition\nNori The Metaplex Foundation's pay-as-you-go service agent, and the reference implementation (agent-plumber) for Metaplex service agents\nService agent An agent that sells services to other agents and charges per call\nDelegate-pay Nori's primary payment rail â after a one-time execution delegation, Nori charges the caller's PDA directly via an MPL Core Execute transaction\nx402 An HTTP 402 Payment Required protocol for machine-to-machine payments; Nori's fallback rail for non-delegated callers\nRate card Nori's published price list at GET /rate-card â versioned, USD-denominated, with a price-change notice policy\nCharge-on-success Nori's billing rule: the upstream call runs first, and only successful calls are charged\nHard stop Immediate end of delegate-pay service when the caller undelegates or the caller's PDA wallet cannot cover a charge\nAsset Signer (PDA wallet) The agent's onchain wallet, an MPL Core PDA derived from [\"mpl-core-execute\", asset] â the account Nori's charges draw from\nExecutive profile The onchain identity of an off-chain signer in mpl-agent-tools ; you delegate to Nori's executive profile\nAgent card The A2A discovery document at /.well-known/agent-card.json advertising skills, payment schemes, and Nori's service addresses\nPrevious\nâ Run an Agent\nNext\nDelegate to Nori â"}
{"url":"https://eips.ethereum.org/","domain":"eips.ethereum.org","title":"Home | Ethereum Improvement Proposals","hash":"a69dab874eabf20389ea74afd0673ed0556b82115990aabcc4208524c864f3a3","tokens":1079,"chars":4314,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112011994,"text":"Ethereum Improvement Proposals\nEIPs\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.\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 .\nEIP status terms\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.\nEIP Types\nEIPs are separated into a number of types, and each has its own list of EIPs.\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.\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 ).\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.\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.\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 ).\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.\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."}
{"url":"https://docs.sui.io/","domain":"docs.sui.io","title":"Sui Documentation","hash":"3448db4d93359d91537c4efcc70d13a2ca060ded702bd87993f23270e145748b","tokens":362,"chars":1448,"crawler":"hive-genesis","verified":"unchecked","ts":1791112013956,"text":"Skip to main content\nSui Documentation\nSui is a next-generation smart contract platform with high throughput, low latency, and an asset-oriented programming model powered by the Move programming language. Explore guides, references, and tutorials to start building on Sui.\nDeveloper Updates\nDeveloper Resources\nGetting Started\nInstall the Sui toolchain, set up a wallet, and publish your first Move package.\nâ\nSui Agent Skills\nEquip AI coding agents with Sui-specific skills and context.\nâ\nDevelop\nWrite and upgrade Move packages, work with objects, and query onchain data.\nâ\nOnchain Finance\nIssue tokens and stablecoins, tokenize assets, and build payments and NFTs.\nâ\nSui Stack\nCompose onchain primitives like zkLogin, Nautilus, and Seal into your app.\nâ\nReferences\nLook up the CLI, SDKs, Move framework, and network API references.\nâ\nUse Cases\nDeepBook\nTrade on Sui's onchain central limit order book across spot, margin, and prediction markets.\nâ\nWalrus\nStore and serve media, blobs, and app data on decentralized storage.\nâ\nzkLogin\nOnboard users with their existing Web2 logins, no seed phrase required.\nâ\nDigital Assets\nBuild NFTs and composable digital collectibles with the object model.\nâ\nNode Operators\nRun a Sui Full Node\nRun a full node to sync the network and serve onchain data.\nâ\nValidators\nSet up and operate a validator to help secure the network.\nâ\nData Management\nSet up archival storage and indexing services for onchain data.\nâ"}
{"url":"https://ethereum.org/developers/docs/consensus-mechanisms/pos/","domain":"ethereum.org","title":"Proof-of-stake (PoS) | ethereum.org","hash":"c3e7711307d6344f322ab7afa5cd7ce13a211e636a57a3b7e12a09a5bdf221b5","tokens":3408,"chars":13632,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112013999,"text":"Skip to main content\nChange page\nProof-of-stake (PoS)\nEdit page (opens in a new tab)\nProof-of-stake (PoS) underlies Ethereum's consensus mechanism . Ethereum switched on its proof-of-stake mechanism in 2022 because it is more secure, less energy-intensive, and better for implementing new scaling solutions compared to the previous proof-of-work architecture.\nPrerequisites\nTo better understand this page, we recommend you first read up on consensus mechanisms .\nWhat is proof-of-stake (PoS)?\nProof-of-stake is a way to prove that validators have put something of value into the network that can be destroyed if they act dishonestly. In Ethereum's proof-of-stake, validators explicitly stake capital in the form of ETH into a smart contract on Ethereum. The validator is then responsible for checking that new blocks propagated over the network are valid and occasionally creating and propagating new blocks themselves. If they try to defraud the network (for example by proposing multiple blocks when they ought to send one or sending conflicting attestations), some or all of their staked ETH can be destroyed.\nValidators\nTo participate as a validator, a user must deposit 32 ETH into the deposit contract and run three separate pieces of software: an execution client, a consensus client, and a validator client. On depositing their ETH, the user joins an activation queue that limits the rate of new validators joining the network. Once activated, validators receive new blocks from peers on the Ethereum network. The transactions delivered in the block are re-executed to check that the proposed changes to Ethereum's state are valid, and the block signature is checked. The validator then sends a vote (called an attestation) in favor of that block across the network.\nWhereas under proof-of-work, the timing of blocks is determined by the mining difficulty, in proof-of-stake, the tempo is fixed. Time in proof-of-stake Ethereum is divided into slots (12 seconds) and epochs (32 slots). One validator is randomly selected to be a block proposer in every slot. This validator is responsible for creating a new block and sending it out to other nodes on the network. Also in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed. Dividing the validator set up into committees is important for keeping the network load manageable. Committees divide up the validator set so that every active validator attests in every epoch, but not in every slot.\nHow a Transaction Gets Executed in Ethereum PoS\nThe following provides an end-to-end explanation of how a transaction gets executed in Ethereum proof-of-stake.\n- A user creates and signs a transaction with their private key. This is usually handled by a wallet or a library such as ethers.js (opens in a new tab) , web3js (opens in a new tab) , web3py (opens in a new tab) etc but under the hood the user is making a request to a node using the Ethereum JSON-RPC API . The user defines the amount of gas that they are prepared to pay as a tip to a validator to encourage them to include the transaction in a block. The tips get paid to the validator while the base fee gets burned.\n- The transaction is submitted to an Ethereum execution client which verifies its validity. This means ensuring that the sender has enough ETH to fulfill the transaction and they have signed it with the correct key.\n- If the transaction is valid, the execution client adds it to its local mempool (list of pending transactions) and also broadcasts it to other nodes over the execution layer gossip network. When other nodes hear about the transaction they add it to their local mempool too. Advanced users might refrain from broadcasting their transaction and instead forward it to specialized block builders such as Flashbots Auction (opens in a new tab) . This allows them to organize the transactions in upcoming blocks for maximum profit ( MEV ).\n- One of the validator nodes on the network is the block proposer for the current slot, having previously been selected pseudo-randomly using RANDAO. This node is responsible for building and broadcasting the next block to be added to the Ethereum blockchain and updating the global state. The node is made up of three parts: an execution client, a consensus client and a validator client. The execution client bundles transactions from the local mempool into an \"execution payload\" and executes them locally to generate a state change. This information is passed to the consensus client where the execution payload is wrapped as part of a \"beacon block\" that also contains information about rewards, penalties, slashings, attestations etc. that enable the network to agree on the sequence of blocks at the head of the chain. The communication between the execution and consensus clients is described in more detail in Connecting the Consensus and Execution Clients .\n- Other nodes receive the new beacon block on the consensus layer gossip network. They pass it to their execution client where the transactions are re-executed locally to ensure the proposed state change is valid. The validator client then attests that the block is valid and is the logical next block in their view of the chain (meaning it builds on the chain with the greatest weight of attestations as defined in the fork choice rules ). The block is added to the local database in each node that attests to it.\n- The transaction can be considered \"finalized\" if it has become part of a chain with a \"supermajority link\" between two checkpoints. Checkpoints occur at the start of each epoch and they exist to account for the fact that only a subset of active validators attest in each slot, but all active validators attest across each epoch. Therefore, it is only between epochs that a 'supermajority link' can be demonstrated (this is where 66% of the total staked ETH on the network agrees on two checkpoints).\nMore detail on finality can be found below.\nFinality\nA transaction has \"finality\" in distributed networks when it is part of a block that can't change without a large amount of ETH getting burned. On proof-of-stake Ethereum, this is managed using \"checkpoint\" blocks. The first block in each epoch is a checkpoint. Validators vote for pairs of checkpoints that it considers to be valid. If a pair of checkpoints attracts votes representing at least two-thirds of the total staked ETH, the checkpoints are upgraded. The more recent of the two (target) becomes \"justified\". The earlier of the two is already justified because it was the \"target\" in the previous epoch. Now it is upgraded to \"finalized\". This process of upgrading the checkpoints is handled by Casper the Friendly Finality Gadget (Casper-FFG) (opens in a new tab) . Casper-FFG is a block finality tool for consensus. Once a block is finalized, it cannot be reverted or changed without a majority slashing of stakers, making it economically inviable.\nTo revert a finalized block, an attacker would commit to losing at least one-third of the total supply of staked ETH. The exact reason for this is explained in this Ethereum Foundation blog post (opens in a new tab) . Since finality requires a two-thirds majority, an attacker could prevent the network from reaching finality by voting with one-third of the total stake. There is a mechanism to defend against this: the inactivity leak (opens in a new tab) . This activates whenever the chain fails to finalize for more than four epochs. The inactivity leak bleeds away the staked ETH from validators voting against the majority, allowing the majority to regain a two-thirds majority and finalize the chain.\nCrypto-economic security\nRunning a validator is a commitment. The validator is expected to maintain sufficient hardware and connectivity to participate in block validation and proposal. In return, the validator is paid in ETH (their staked balance increases). On the other hand, participating as a validator also opens new avenues for users to attack the network for personal gain or sabotage. To prevent this, validators miss out on ETH rewards if they fail to participate when called upon, and their existing stake can be destroyed if they behave dishonestly. Two primary behaviors can be considered dishonest: proposing multiple blocks in a single slot (equivocating) and submitting contradictory attestations.\nThe amount of ETH slashed depends on how many validators are also being slashed at around the same time. This is known as the \"correlation penalty\" (opens in a new tab) , and it can be minor (less than 0.1% stake for a single validator slashed on their own) or can result in 100% of the validator's stake getting destroyed (mass slashing event). It is imposed halfway through a forced exit period that begins with an immediate penalty (1/4096 of the validator's effective balance, up to 0.5 ETH) on Day 1, the correlation penalty on Day 18, and finally, ejection from the network on Day 36. They receive minor attestation penalties every day because they are present on the network but not submitting votes. This all means a coordinated attack would be very costly for the attacker.\nFork choice\nWhen the network performs optimally and honestly, there is only ever one new block at the head of the chain, and all validators attest to it. However, it is possible for validators to have different views of the head of the chain due to network latency or because a block proposer has equivocated. Therefore, consensus clients require an algorithm to decide which one to favor. The algorithm used in proof-of-stake Ethereum is called LMD-GHOST (opens in a new tab) , and it works by identifying the fork that has the greatest weight of attestations in its history.\nProof-of-stake and security\nThe threat of a 51% attack (opens in a new tab) still exists on proof-of-stake as it does on proof-of-work, but it's even riskier for the attackers. An attacker would need 51% of the staked ETH. They could then use their own attestations to ensure their preferred fork was the one with the most accumulated attestations. The 'weight' of accumulated attestations is what consensus clients use to determine the correct chain, so this attacker would be able to make their fork the canonical one. However, a strength of proof-of-stake over proof-of-work is that the community has flexibility in mounting a counter-attack. For example, the honest validators could decide to keep building on the minority chain and ignore the attacker's fork while encouraging apps, exchanges, and pools to do the same. They could also decide to forcibly remove the attacker from the network and destroy their staked ETH. These are strong economic defenses against a 51% attack.\nBeyond 51% attacks, bad actors might also attempt other types of malicious activities, such as:\n- long-range attacks (although the finality gadget neutralizes this attack vector)\n- short range 'reorgs' (although proposer boosting and attestation deadlines mitigate this)\n- bouncing and balancing attacks (also mitigated by proposer boosting, and these attacks have anyway only been demonstrated under idealized network conditions)\n- avalanche attacks (neutralized by the fork choice algorithms rule of only considering the latest message)\nOverall, proof-of-stake, as it is implemented on Ethereum, has been demonstrated to be more economically secure than proof-of-work.\nPros and cons\nPros Cons\nStaking makes it easier for individuals to participate in securing the network, promoting decentralization. validator node can be run on a normal laptop. Staking pools allow users to stake without having 32 ETH. Proof-of-stake is younger and less battle-tested compared to proof-of-work\nStaking is more decentralized. Economies of scale do not apply in the same way that they do for PoW mining. Proof-of-stake is more complex to implement than proof-of-work\nProof-of-stake offers greater crypto-economic security than proof-of-work Users need to run three pieces of software to participate in Ethereum's proof-of-stake.\nLess issuance of new ETH is required to incentivize network participants\nComparison to proof-of-work\nEthereum originally used proof-of-work but switched to proof-of-stake in September 2022. PoS offers several advantages over PoW, such as:\n- better energy efficiency â there is no need to use lots of energy on proof-of-work computations\n- lower barriers to entry, reduced hardware requirements â there is no need for elite hardware to stand a chance of creating new blocks\n- reduced centralization risk â proof-of-stake should lead to more nodes securing the network\n- because of the low energy requirement less ETH issuance is required to incentivize participation\n- economic penalties for misbehavior make 51% style attacks more costly for an attacker compared to proof-of-work\n- the community can resort to social recovery of an honest chain if a 51% attack were to overcome the crypto-economic defenses.\nFurther reading\n- Proof of Stake FAQ (opens in a new tab) Vitalik Buterin\n- What is Proof of Stake (opens in a new tab) ConsenSys\n- What Proof of Stake Is And Why It Matters (opens in a new tab) Vitalik Buterin\n- Why Proof of Stake (Nov 2020) (opens in a new tab) Vitalik Buterin\n- Proof of Stake: How I Learned to Love Weak Subjectivity (opens in a new tab) Vitalik Buterin\n- Proof-of-stake Ethereum attack and defense (opens in a new tab)\n- A Proof of Stake Design Philosophy (opens in a new tab) Vitalik Buterin\n- Video: Vitalik Buterin explains proof-of-stake to Lex Fridman (opens in a new tab)\nRelated topics\n- Proof-of-work\n- Proof-of-authority\nTest your Ethereum knowledge"}
{"url":"https://docs.compound.xyz/","domain":"docs.compound.xyz","title":"Compound III Documentation","hash":"41c23224456ab0fa91b72fdf24b3a86a0b3cabfae08d737ca0dd4d23999641dd","tokens":1270,"chars":5079,"crawler":"hive-genesis","verified":"exact","ts":1791112015713,"text":"Markets Governance Docs\n- Compound III\n- Interest Rates\n- Collateral & Borrowing\n- Liquidation\n- Account Management\n- Protocol Rewards\n- ERC-4626 Wrapper\n- Governance\n- Helper Functions\n- Introduction\n- Networks\n- Protocol Contracts\n- Developer Resources\n- Security\nCompound III\nIntroduction\nCompound III is an EVM compatible protocol that enables supplying of crypto assets as collateral in order to borrow the base asset . Accounts can also earn interest by supplying the base asset to the protocol.\nThe initial deployment of Compound III is on Ethereum and the base asset is USDC.\nPlease join the #development room in the Compound community Discord server as well as the forums at comp.xyz ; Compound Labs and members of the community look forward to helping you build an application on top of Compound III. Your questions help us improve, so please donât hesitate to ask if you canât find what you are looking for here.\nFor documentation of the Compound v2 Protocol, see docs.compound.xyz/v2 .\nNetworks\nThe network deployment artifacts with contract addresses are available in the Comet repository deployments/ folder.\nThe v3 proxy is the only address to be used to interact with a Compound III instance. It is the first address listed in each of the tabs below. To generate the proper Comet Interface ABI ( CometInterface.sol ), compile the Comet project using yarn compile .\nNote: The deployment data shown below is sourced from the compound-docs-aggregator repository. Data collected on: 2026-09-16 15:56:48.594 UTC .\nProtocol Contracts\ncUSDCv3\nThis is the main proxy contract for interacting with the first Compound III market. The address is fixed and independent from future upgrades to the market. It is an OpenZeppelin TransparentUpgradeableProxy contract .\ncUSDCv3 Implementation\nThis is the implementation of the market logic contract, as deployed by the Comet Factory via the Configurator.\nDo not interact with this contract directly; instead use the cUSDCv3 proxy address with the Comet Interface ABI.\ncUSDCv3 Ext\nThis is an extension of the market logic contract which supports some auxiliary/independent interfaces for the protocol. This is used to add additional functionality without requiring contract space in the main protocol contract.\nDo not interact with this contract directly; instead use the cUSDCv3 proxy address with the Comet Interface ABI.\nConfigurator\nThis is a proxy contract for the configurator , which is used to set and update parameters of a Comet proxy contract. The configurator deploys implementations of the Comet logic contract according to its configuration. This pattern allows significant gas savings for users of the protocol by âconstantizingâ the parameters of the protocol.\nConfigurator Implementation\nThis is the implementation of the Configurator contract, which can also be upgraded to support unforeseen changes to the protocol.\nProxy Admin\nThis is the admin of the Comet and Configurator proxy contracts. It is a ProxyAdmin as recommended/implemented by OpenZeppelin according to their upgradeability pattern.\nComet Factory\nThis is the factory contract capable of producing instances of the Comet implementation/logic contract, and invoked by the Configurator.\nRewards\nThis is a rewards contract which can hold rewards tokens (e.g. COMP, WETH) and allows claiming rewards by users, according to the core protocol tracking indices.\nBulker\nThis is an external contract that is not integral to Cometâs function. It allows accounts to bulk multiple operations into a single transaction. This is a useful contract for Compound III user interfaces. The following is an example of steps in a bulked transaction.\n- Wrap Ether to WETH\n- Supply WETH collateral\n- Supply WBTC collateral\n- Borrow USDC\nIn addition to supplying, borrowing, and wrapping, the bulker contract can also transfer collateral within the protocol and claim rewards.\nDeveloper Resources\nThe following developer guides and code repositories serve as resources for community members building on Compound. They detail the protocol deployment process, construction of new features, and code examples for implementing external apps that depend on Compound III as infrastructure.\n- Compound III Developer FAQ\n- Scenarios, Migrations, and Workflows\n- Creating a Compound III Liquidator\n- Building a Comet Extension\nSecurity\nThe security of the Compound protocol is our highest priority; our development team, alongside third-party auditors and consultants, has invested considerable effort to create a protocol that we believe is safe and dependable. All contract code and balances are publicly verifiable, and security researchers are eligible for a bug bounty for reporting undiscovered vulnerabilities.\nWe believe that size, visibility, and time are the true test for the security of a smart contract; please exercise caution, and make your own determination of security and suitability.\nAudits\nThe Compound protocol has been reviewed & audited by OpenZeppelin and ChainSecurity .\n- Compound III Audit by OpenZeppelin\n- Compound III Security Audit by ChainSecurity"}
{"url":"https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/master/README.md","domain":"raw.githubusercontent.com","title":"![\"OpenZeppelin\"](\"logo.svg\")
","hash":"867cfe7ccf651cdedf7769c8adf7d0b35f117310f5a195f3a3489d4f15f63998","tokens":2159,"chars":8635,"crawler":"crawler-dfxz","verified":"exact","ts":1791112015653,"text":"# \n[](https://github.com/OpenZeppelin/openzeppelin-contracts/releases/latest)\n[](https://www.npmjs.org/package/@openzeppelin/contracts)\n[](https://codecov.io/gh/OpenZeppelin/openzeppelin-contracts)\n[](https://docs.openzeppelin.com/contracts)\n[](https://forum.openzeppelin.com/)\n**A library for secure smart contract development.** Build on a solid foundation of community-vetted code.\n* Implementations of standards like [ERC20](https://docs.openzeppelin.com/contracts/erc20) and [ERC721](https://docs.openzeppelin.com/contracts/erc721).\n* Flexible [role-based permissioning](https://docs.openzeppelin.com/contracts/access-control) scheme.\n* Reusable [Solidity components](https://docs.openzeppelin.com/contracts/utilities) to build custom contracts and complex decentralized systems.\n:mage: **Not sure how to get started?** Check out [Contracts Wizard](https://wizard.openzeppelin.com/) â an interactive smart contract generator.\n> [!IMPORTANT]\n> OpenZeppelin 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](https://docs.openzeppelin.com/contracts/backwards-compatibility).\n## Overview\n### Release tags\nWe use NPM tags to clearly distinguish between audited and non-audited versions of our package:\n| Tag | Purpose | Description |\n| :--------- | :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **latest** | â
Audited releases | Stable, audited versions of the package. This is the **default** version installed when users run `npm install @openzeppelin/contracts`. |\n| **dev** | đ§Ș 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. |\n| **next** | đ§ Release candidates | Pre-release versions that are **not final**. Used for testing and validation before the version becomes a final `dev` or `latest` release. |\n### Installation\n#### Hardhat (npm)\n```\n$ npm install @openzeppelin/contracts\n```\nâ Installs the latest audited release (`latest`).\n```\n$ npm install @openzeppelin/contracts@dev\n```\nâ Installs the latest unaudited release (`dev`).\n#### Foundry (git)\n> [!WARNING]\n> When 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.\n> [!WARNING]\n> Foundry installs the latest version initially, but subsequent `forge update` commands will use the `master` branch.\n```\n$ forge install OpenZeppelin/openzeppelin-contracts\n```\nAdd `@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/` in `remappings.txt`.\n### Usage\nOnce installed, you can use the contracts in the library by importing them:\n```solidity\npragma solidity ^0.8.20;\nimport {ERC721} from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\";\ncontract MyCollectible is ERC721 {\nconstructor() ERC721(\"MyCollectible\", \"MCO\") {\n}\n```\n_If you're new to smart contract development, head to [Developing Smart Contracts](https://docs.openzeppelin.com/learn/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.\n## Learn More\nThe guides in the [documentation site](https://docs.openzeppelin.com/contracts) will teach about different concepts, and how to use the related contracts that OpenZeppelin Contracts provides:\n* [Access Control](https://docs.openzeppelin.com/contracts/access-control): decide who can perform each of the actions on your system.\n* [Tokens](https://docs.openzeppelin.com/contracts/tokens): create tradeable assets or collectibles for popular ERC standards like ERC-20, ERC-721, ERC-1155, and ERC-6909.\n* [Utilities](https://docs.openzeppelin.com/contracts/utilities): generic useful tools including non-overflowing math, signature verification, and trustless paying systems.\nThe [full API](https://docs.openzeppelin.com/contracts/api/token/ERC20) 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](https://forum.openzeppelin.com).\nFinally, you may want to take a look at the [guides on our blog](https://blog.openzeppelin.com/), which cover several common use cases and good practices. The following articles provide great background reading, though please note that some of the referenced tools have changed, as the tooling in the ecosystem continues to rapidly evolve.\n* [The Hitchhikerâs Guide to Smart Contracts in Ethereum](https://blog.openzeppelin.com/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05) will help you get an overview of the various tools available for smart contract development, and help you set up your environment.\n* [A Gentle Introduction to Ethereum Programming, Part 1](https://blog.openzeppelin.com/a-gentle-introduction-to-ethereum-programming-part-1-783cc7796094) provides very useful information on an introductory level, including many basic concepts from the Ethereum platform.\n* For a more in-depth dive, you may read the guide [Designing the Architecture for Your Ethereum Application](https://blog.openzeppelin.com/designing-the-architecture-for-your-ethereum-application-9cec086f8317), which discusses how to better structure your application and its relationship to the real world.\n## Security\nThis project is maintained by [OpenZeppelin](https://openzeppelin.com) with the goal of providing a secure and reliable library of smart contract components for the ecosystem. We address security through risk management in various areas such as engineering and open source best practices, scoping and API design, multi-layered review processes, and incident response preparedness.\nThe [OpenZeppelin Contracts Security Center](https://contracts.openzeppelin.com/security) contains more details about the secure development process.\nThe security policy is detailed in [`SECURITY.md`](./SECURITY.md) as well, and specifies how you can report security vulnerabilities, which versions will receive security patches, and how to stay informed about them. We run a [bug bounty program on Immunefi](https://immunefi.com/bounty/openzeppelin) to reward the responsible disclosure of vulnerabilities.\nThe engineering guidelines we follow to promote project quality can be found in [`GUIDELINES.md`](./GUIDELINES.md).\nPast audits can be found in [`audits/`](./audits).\nSmart contracts are a nascent technology and carry a high level of technical risk and uncertainty. Although OpenZeppelin is well known for its security audits, using OpenZeppelin Contracts is not a substitute for a security audit.\nOpenZeppelin Contracts is made available under the MIT License, which disclaims all warranties in relation to the project and which limits the liability of those that contribute and maintain the project, including OpenZeppelin. As set out further in the Terms, you acknowledge that you are solely responsible for any use of OpenZeppelin Contracts and you assume all risks associated with any such use.\n## Contribute\nOpenZeppelin Contracts exists thanks to its contributors. There are many ways you can participate and help build high quality software. Check out the [contribution guide](CONTRIBUTING.md)!\n## License\nOpenZeppelin Contracts is released under the [MIT License](LICENSE).\n## Legal\nYour use of this Project is governed by the terms found at www.openzeppelin.com/tos (the \"Terms\")."}
{"url":"https://aptos.dev/","domain":"aptos.dev","title":"","hash":"8915241adfd83bd0e8322af9af869e258b847034acc1ad56850af2369c54ac31","tokens":602,"chars":2405,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112017492,"text":"Getting Started\n* [Deploy Your First Move Smart Contract](/build/guides/first-move-module) Compile & publish Move modules to devnet in minutes.\n* [Your First Transaction](/build/guides/first-transaction) Write and read on-chain data using the TypeScript SDK.\n* [Code with AI (MCP)](/build/ai/aptos-mcp) Give Cursor, Claude Code, and Codex direct access to Aptos APIs.\n* [Agent Skills](/build/ai/aptos-agent-skills) Move and TS SDK skills for Claude Code, Cursor, Copilot.\nTools\n* [Testnet Faucet](/network/faucet) Fund your testnet account with APT to start building.\n* [Official SDKs](/build/sdks) TypeScript, Python, Go, Rust, and more.\n* [Aptos CLI](/build/cli) Compile, test, publish contracts; accounts & keys; localnet.\nSmart Contracts\n* [NEW! Move on Aptos (VS Code Extension)](/build/smart-contracts/move-vscode-extension) Aptos Labsâ official extension for Move development.\n* [Objects](/build/smart-contracts/objects) Composable on-chain primitives for flexible asset ownership, addressing, & programmability.\n* [The Move Book](https://aptos-labs.github.io/move-book/) Understand Move syntax, types, resources, & best practices.\n* [Vibe Code a full-stack dApp on Learn](https://learn.aptoslabs.com/en/hackathon/vibe-coder-to-aptos-guide/introduction) Interactive AI workshop to quickly build a full-stack dApp.\nOn-Chain Features\n* [Sponsored Transactions](/build/guides/sponsored-transactions) Pay for usersâ gas so they can use your dApp with zero APT.\n* [Keyless Accounts](/build/guides/aptos-keyless) Onboard users and sign without wallets or seed phrases.\n* [NEW! Orderless Transactions](/build/guides/orderless-transactions) High-volume apps can be safer by sending transactions out of order with replay-protection nonce.\n* [On-chain Randomness](/build/smart-contracts/randomness) Verifiable random number = fair games, lotteries, & drops.\nResources\n* [LLMs.txt Integration](/llms-txt) AI-optimized documentation feeds for coding assistants and chat tools.\n* [Query, Index, or Stream On-Chain Data](/build/indexer) Query Indexer API, index contracts, stream raw transactions.\n* [Apply for a Grant](https://aptosnetwork.com/grants)\nConnect\n* [GitHub Developer Discussions](https://github.com/aptos-labs/aptos-developer-discussions/discussions)\n* [Ecosystem Directory](https://aptosnetwork.com/ecosystem/directory)\n* [Discord](https://discord.gg/aptosnetwork)\n* [Telegram](https://t.me/aptos)"}
{"url":"https://docs.velocity.exchange/protocol","domain":"docs.velocity.exchange","title":"Introduction to Velocity | Velocity Protocol","hash":"a7d419b35cf92d8ec90290cb93cebf95699dc185989465344ea1cf83694b2997","tokens":1221,"chars":4881,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112019231,"text":"Velocity Protocol Developers\nView as Markdown\nIntroduction to Velocity\nWhere perpetual futures and lending meet on one balance, what a fill costs, and where to start reading.\nVelocity is a perpetual futures exchange and a money market, deployed as a single Solana program. Each subaccount holds one pool of collateral, that pool backs every perpetual position opened against it, and the same tokens are lent to borrowers while they sit there. Trading is perpetuals only.\nSpot trading has been removed from the Velocity program. Spot markets exist only for collateral and borrow-lend. Spot assets can still be exchanged through swaps .\nOne deposit doing two jobs\nOn most venues margin is money parked: it backs positions and earns nothing, and moving it somewhere that pays means it stops being margin. Velocity never separates the two balances. A deposit lands in that asset's spot market vault, counts toward the account's margin at the asset's collateral weight, and is lendable inventory from the same moment. Three things follow:\n- Margin earns the lending rate while it backs a trade. Interest accrues to the spot balance continuously, priced off that market's utilization.\n- There is no borrow instruction. A borrow is what a withdrawal becomes once it passes the account's balance in that market.\n- A withdrawal is checked twice. The account's own margin has to survive it, and so does the market's withdrawal limit, because the tokens requested have partly been lent out. The second check is usually why a withdrawal is refused, and it usually clears on its own.\nNot every asset counts for its full value as collateral: the quote asset does, anything more volatile is weighted down. Collateral and margin has the weights; Borrow and lend has the utilization curve.\nWhat a trade costs\nPerpetual fills charge the taker a fee on the filled notional, in the quote asset: 4 bps of notional at the base tier, 3 bps above $5,000,000 and 2 bps above $80,000,000 of trailing 30-day volume. The maker on that fill is paid 0.25 bps of notional out of it, flat at every tier. Individual markets can add to the taker fee, capped at 10 bps on top, so a tier rate is a floor rather than a promise.\nSpot markets and the direct swap path charge no maker or taker fee. Funding is not a fee: it is an hourly payment between longs and shorts, and a position can receive it as readily as pay it. See Trading fees and Funding rates .\nHow an order is filled\nThere is no central matching engine. Orders live onchain as accounts, an offchain network of keepers and market makers watches them, and anyone can submit the transaction that fills one. Three sources of liquidity can end up on the other side of a taker order: resting orders on the decentralized orderbook (DLOB), market makers quoting just in time, and the protocol's own AMM. They are not three stages in a fixed order, and one taker order can fill from more than one of them in a single transaction.\nEvery perpetual market order also carries a short Dutch auction, so its price starts somewhere favorable to the taker and walks toward the limit price while makers compete to take it. The exchange enforces a minimum auction duration, and each market sets its own default. See How fills work and Auctions .\nWhere to go next\nThe app is at app.velocity.exchange . Starting from nothing, read What a perpetual is , then A first trade , which follows one $10,000 account from deposit to withdrawal. The rest is reference:\n- Opening an account : Wallet setup , Subaccounts , Delegated accounts\n- Trading : Collateral and margin , Order types , Auctions , Trading fees , Funding rates , Liquidations\n- Lending and borrowing : Borrow and lend , Interest rates , Withdrawal limits\n- The machinery : How fills work , Velocity AMM , Orderbook and keepers , Oracles , Where the money sits\n- Sizing risk : Risks , Contract tiers , Guard rails , Insurance fund , Admin keys\n- Building on it : TypeScript SDK , Keeper bots , Market makers\nSource and audits\nThe Velocity program is not open source yet. The source will be published once the post-fork audit report is final. The TypeScript SDK is on npm today, and this documentation site is open to contributions. See Velocity for Developers .\nOtterSec audited Velocity's own program after the fork, and the final report is published: 154 findings, no Critical, and every High fixed in the deployed code. The Drift Protocol v2 codebase Velocity forked carries earlier audits by Trail of Bits and Neodyme. See Audits for the record, and the migration guide for porting an existing integration.\nEdit on GitHub\nWhat a perpetual is\nA futures contract settles on a fixed date, and that date is the problem. What removing it breaks, how funding fixes it, and what the position actually is.\nOn this page\nOne deposit doing two jobs\nWhat a trade costs\nHow an order is filled\nWhere to go next\nSource and audits"}
{"url":"https://docs.near.org/","domain":"docs.near.org","title":"Home - NEAR Docs","hash":"ff65ebe8f7aae0691398c8b861ea6bbc68fcb768996ce5d75b68b6d4ff5814c8","tokens":590,"chars":2357,"crawler":"hive-genesis","verified":"exact","ts":1791112019371,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNEAR Docs home page\nHome\nProtocol\nSmart Contracts\nWeb3 Apps\nMulti-Chain\nTokens & Primitives\nData Infra\nRPC\nMCP Ready LLMs.txt Ready\nNEAR Developer Docs\nBuild contracts in Rust, create Web3 apps, and sign transactions on any chain from a single NEAR account.\nDeploy your First Contract\nCreate, test and deploy contracts with simple commands.\nWhat is a Contract? â\nQuickstart â\ncargo near new hello-world\n# â
Success! Created 'hello-near', a smart contract in Rust\n# Build, test, and deploy your contract with Cargo\ncargo near build\ncargo test\ncargo near deploy\nYou can easily create testnet accounts and request testnet tokens to the faucet .\nnpx create-near-app@latest\n# â
What do you want to build? âș \"A Web App\"\n# â
Select a framework for your frontend âș \"Vite (React)\"\n# â
Name your project: \"hello-near\"\n#Start using your new NEAR app:\ncd hello-near\nnpm run dev\nBuild Web3 Applications\nEasily authenticate users and call smart contracts from any frontend framework.\nWhat are Web3 Apps? â\nCreate your first app â\nWhy NEAR?\nSub-second block finality\nTransactions reach deterministic finality in 1.3s, no reorgs, no waiting.\nNear-zero fees\nAverage transaction fees are $0.002. Storage costs are fully refundable upon deletion.\nSharded & scalable\nThe network automatically scales as demand grows, with no downtime or hard forks.\nWASM contracts in Rust\nWrite complex contracts in Rustâor use community SDKs for JavaScript, Python, and Go.\nChain Signatures\nControl accounts on Bitcoin, Ethereum, Solana, and more.\nTEE-backed agents\nRun AI inference inside Trusted Execution Environments for verifiable, tamper-proof outputs.\nBrowse the docs\nProtocol\nAccounts, access keys, gas, transactions, consensus, and more.\nSmart contract reference\nState, functions, collections, callbacks, cross-contract calls, and security.\nWeb application guides\nWallet authentication, JavaScript APIs, data types, and contract calls.\nTokens and primitives\nFTs, NFTs, DAOs, linkdrops, staking, oracles, and off-chain compute.\nData infrastructure\nIndex and query on-chain data with NEAR Lake, BigQuery, and indexers.\nAI agent tooling\nUse llms.txt, Docs MCP, agent skills, and on-chain MCP tools.\nWas this page helpful?"}
{"url":"https://docs.ton.org/","domain":"docs.ton.org","title":"TON Docs â developer documentation","hash":"14612662575680cde9a5dbca9e8805a3324e8bc5566161c4fbcbaf7189a5f683","tokens":730,"chars":2920,"crawler":"hive-genesis","verified":"exact","ts":1791112021213,"text":"The Open Network\nTON Documentation\nTON is a blockchain platform designed for scalable smart contracts, applications, and payments at consumer scale.\nUnified toolchain for smart contracts\nActon is a TON smart contract toolkit. One CLI handles project setup, builds, tests, scripts, linting, formatting, debugging, deployment, and verification. Acton Studio adds a browser workspace with comprehensive UI for local tests, virtual environments, and interaction with real networks, such as mainnet and testnet.\nTest contract behavior\nRun tests that follow transaction flows between contracts.\nYour browser does not support video playback.\nDebug failures\nPause at a failure and inspect the code, call stack, and local values.\nYour browser does not support video playback.\nConnect contracts to apps\nGenerate typed interfaces for web apps that connect to TON wallets.\nYour browser does not support video playback.\nDeploy and verify\nManage wallets, get testnet funds, deploy and verify contracts.\nYour browser does not support video playback.\nReady to build?\nInstall Acton, then choose a guide below.\ncurl -LsSf https://github.com/ton-blockchain/acton/releases/latest/download/acton-installer.sh | sh\nBuilding a frontend? See the Acton dApp guide .\nTelegram Mini Apps selling digital goods or services must use Stars .\nLearning paths\nOnboarding\nFor newcomers entering Web3 through TON.\n- Overview of TON and the documentation\n- Create a TON wallet\n- Read blockchain data with explorers\n- Enable TON for agents with @ton/mcp\nApplications\nBuild dApps, wallets, and payment services on TON.\n- Overview\n- Create tools using SDKs\n- Integrate dApps and wallets with TON Connect\n- Process payments in business applications\nNodes\nRun and manage TON blockchain nodes.\n- Overview\n- C++ node setup\n- Run a validator node\n- Run a liteserver node\n- Run an archive liteserver\nAPIs\nAccess TON data via hosted APIs or self-hosted options.\n- Overview\n- API v2: direct liteserver\n- API v3: indexed database\n- Streaming API: status updates\n- Get API key\nSmart contracts\nBuild, debug, and deploy smart contracts.\n- Overview\n- Toolchain and IDEs\n- Wallet contracts\n- Jettons and NFTs\n- Advanced techniques\nTolk language\nMaster the language of TON smart contracts.\n- Overview\n- Basic syntax\n- Idioms and conventions\n- Type system\n- Standard library reference\nTVM: TON Virtual Machine\nSkim the detailed reference of the smart-contract runtime.\n- Overview\n- Exit codes\n- Instructions\n- Gas\n- Registers\nBlockchain foundations\nLearn all the ins and outs of the TON blockchain.\n- Overview\n- Addresses\n- Transaction fees\n- Config\n- TL-B\nTroubleshooting\nPress Ctrl K to search the docs. Still stuck? Discuss issues and best practices with other community members.\nGet support\nLearn how to get help on the dedicated page.\nTelegram folder\nAdd the folder with many developer chats.\nTON Dev chat\nJoin the discussion in the main TON development chat on Telegram."}
{"url":"https://raw.githubusercontent.com/anza-xyz/agave/master/README.md","domain":"raw.githubusercontent.com","title":"Building","hash":"5b46d746eb8b2a5194233084775203dd1f493cb61835ebd82ccdf713634f6503","tokens":1117,"chars":4466,"crawler":"crawler-dfxz","verified":"exact","ts":1791112020998,"text":"\n```\nFor XDP zero-copy mode (`--xdp-zero-copy`), additional capabilities are needed:\n```bash\n$ sudo setcap 'cap_net_admin,cap_net_raw,cap_bpf,cap_perfmon+eip' \n```\n# Testing\n**Run the test suite:**\n```bash\n$ ./cargo nextest run --profile ci --cargo-profile ci --config-file .config/nextest.toml\n```\n### Starting a local testnet\nStart your own testnet locally, instructions are in the [online docs](https://docs.anza.xyz/clusters/benchmark).\n### Accessing the remote development cluster\n* `devnet` - stable public cluster for development accessible via\ndevnet.solana.com. Runs 24/7. Learn more about the [public clusters](https://docs.anza.xyz/clusters)\n# Benchmarking\nFirst, install the nightly build of rustc. `cargo bench` requires the use of the\nunstable features only available in the nightly build.\n```bash\n$ rustup install nightly\n```\nRun the benchmarks:\n```bash\n$ cargo +nightly bench\n```\n# Release Process\nThe release process for this project is described [here](RELEASE.md).\n# Code coverage\nTo generate code coverage statistics:\n```bash\n$ scripts/coverage.sh\n$ open target/cov/lcov-local/index.html\n```\nWhy coverage? While most see coverage as a code quality metric, we see it primarily as a developer\nproductivity metric. When a developer makes a change to the codebase, presumably it's a *solution* to\nsome problem. Our unit-test suite is how we encode the set of *problems* the codebase solves. Running\nthe test suite should indicate that your change didn't *infringe* on anyone else's solutions. Adding a\ntest *protects* your solution from future changes. Say you don't understand why a line of code exists,\ntry deleting it and running the unit-tests. The nearest test failure should tell you what problem\nwas solved by that code. If no test fails, go ahead and submit a Pull Request that asks, \"what\nproblem is solved by this code?\" On the other hand, if a test does fail and you can think of a\nbetter way to solve the same problem, a Pull Request with your solution would most certainly be\nwelcome! Likewise, if rewriting a test can better communicate what code it's protecting, please\nsend us that patch!"}
{"url":"https://solana.com/docs/core/accounts","domain":"solana.com","title":"","hash":"aa0c37ebffb266d1ca09d7b54f294929708c85141bcd42f6b712b58055ca53c5","tokens":821,"chars":3281,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112022864,"text":"---\ntitle: Accounts\ndescription:\nSolana accounts are the fundamental data unit for storing state on the\nnetwork. Account structure, addresses, types, rent, ownership, and\nmodification rules.\nurl: /docs/core/accounts\ntype: conceptual\nprerequisites: []\nrelated:\n- /docs/core/accounts/account-structure\n- /docs/core/accounts/account-types\n- /docs/core/programs\n- /docs/core/transactions\n---\nAn account is Solana's fundamental data unit for storing state. The network\nstores all state in a key-value store where each key is a 32-byte address and\neach value is an account.\n\n\n\nAccount addresses (public key, PDA), the five fields every account contains,\nstorage balance, and the deprecated rent field, with an interactive code\nwalkthrough.\n \n\nProgram accounts (executable code), data accounts (program state), system\naccounts, and sysvars (cluster-wide state).\n \n\nRuntime-enforced rules for lamports, data, owner, executable flag, and\nborrows.\n\n\nAccount loading validation, BPF serialization format, and deserialization.\n \n \n## Key facts\n- **Structure**: Every account has the same\n[five fields](/docs/core/accounts/account-structure): lamports, data, owner,\nexecutable, rent_epoch.\n- **Address**: Each account is identified by a unique 32-byte address (either an\nEd25519 public key or a [PDA](/docs/core/pda)).\n- **Ownership**: Only the account's owner program can modify its data or debit\nlamports. Any program can credit lamports to any writable account.\n- **Account storage**: Every account must hold a refundable minimum lamport\nbalance proportional to its data size to remain onchain.\n## Limits\n| Limit | Value | Source |\n| --------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |\n| Max account data size | 10 MiB (10,485,760 bytes) | [`MAX_ACCOUNT_DATA_LEN`](https://github.com/anza-xyz/agave/blob/v3.1.8/transaction-context/src/lib.rs#L34) |\n| Max data growth per instruction | 10 KiB (10,240 bytes) | [`MAX_PERMITTED_DATA_INCREASE`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/account-info/src/lib.rs#L17) |\n| Max data growth per transaction | 20 MiB (20,971,520 bytes) | [`MAX_ACCOUNT_DATA_GROWTH_PER_TRANSACTION`](https://github.com/anza-xyz/agave/blob/v3.1.8/transaction-context/src/lib.rs#L38) |\n| Account base storage overhead | 64 bytes per account | [`TRANSACTION_ACCOUNT_BASE_SIZE`](https://github.com/anza-xyz/agave/blob/v3.1.8/svm/src/account_loader.rs#L45) |\n| Address size | 32 bytes (Ed25519 public key) | -- |\n| Minimum storage balance (formula) | (account_size + 128) \\* 3,480 lamports/byte-year \\* 2 years | [`minimum_balance()`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/rent/src/lib.rs#L93) |"}
{"url":"https://docs.polkadot.com/","domain":"docs.polkadot.com","title":"Polkadot Developer Docs","hash":"de6e254c6060b29c5fae8930e89adcf547bf1f9e6be23ce660dee638e4b573c9","tokens":395,"chars":1577,"crawler":"hive-genesis","verified":"unchecked","ts":1791112022851,"text":"Initializing search\n- Concepts\n- Build\n- Deploy Your App\n- Register a .dot Domain\n- List Your App\n- Product SDK\n- Tutorials\n- Troubleshooting\n- Smart Contracts\n- Cookbook\n- Deploy an ERC-20\n- Deploy an NFT\n- Create a DApp\n- Port Ethereum DApps\n- Uniswap V3\n- Precompiles\n- Development Environments\n- Libraries\n- Integrations\n- Parachains\n- Customize Your Runtime\n- Test Your Runtime\n- Maintain and Upgrade Your Parachain\n- Enable Interoperability\n- Integrations\n- Chain Interactions\n- Send Transactions\n- Manage Tokens\n- Store Data\n- Manage Accounts\n- Node Infrastructure\n- Parachain RPC Node\n- Run a Validator\n- Operational Tasks\n- Staking Mechanics\n- Run a Collator\n- Tech Reference\n- Asset Management\n- Bridging\n- People and Identity\n- Collectives and DAOs\n- Data Storage\n- Parachains\n- Accounts\n- Blocks, Transactions, and Fees\n- Node and Runtime\n- Interoperability\n- Randomness\n- Cryptography\n- Data Encoding\n- Chain Data\n- Networks\n- On-Chain Governance\n- App Development\n- Polkadot Desktop\n- Polkadot Web\n- Protocol\n- Infrastructure\n- Statement Store\n- dotNS\n- Proof of Personhood\n- HOP\n- Skills\n- Glossary\n- Tools\n- AI Resources\n- Support\n- Policies\nPage actions\nEdit this page Report an issue\nPolkadot Documentation\nEverything you need to start building on Polkadot.\nApps\nCreate a Product quick start Set up your app dev environment Build an app locally Deploy and publish an app\nSmart Contracts\nConnect to Polkadot Deploy a contract Leverage precompiled contracts\nBlockchains\nInstall the Polkadot SDK Launch a simple blockchain Customize your chain Upgrade your chain"}
{"url":"https://eips.ethereum.org/EIPS/eip-7702","domain":"eips.ethereum.org","title":"EIP-7702: Set Code for EOAs","hash":"76c896d31057cba944080f3e08dcbfdcf32a01082d85c894ff2b2190c09ced26","tokens":7237,"chars":28947,"crawler":"crawler-dfxz","verified":"exact","ts":1791112024606,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: Core\nEIP-7702: Set Code for EOAs\nAdd a new tx type that permanently sets the code for an EOA\nAuthors\nVitalik Buterin ( @vbuterin ), Sam Wilson ( @SamWilsn ), Ansgar Dietrichs ( @adietrichs ), lightclient ( @lightclient )\nCreated\n2024-05-07\nRequires\nEIP-2 ,\nEIP-161 ,\nEIP-1052 ,\nEIP-2718 ,\nEIP-2929 ,\nEIP-2930 ,\nEIP-3541 ,\nEIP-3607 ,\nEIP-4844\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- Parameters\n- Set code transaction\n- Rationale\n- General design philosophy\n- Rationale for technical details\n- Backwards Compatibility\n- Security Considerations\n- Implementation of secure delegate contracts\n- Front running initialization\n- Storage management\n- Setting code as tx.origin\n- Sponsored transaction relayers\n- Transaction propagation\n- Copyright\nAbstract\nAdd a new EIP-2718 transaction type that allows Externally\nOwned Accounts (EOAs) to set the code in their account. This is done by\nattaching a list of authorization tuples â individually formatted as [chain_id,\naddress, nonce, y_parity, r, s] â to the transaction. For each tuple, a\ndelegation indicator (0xef0100 || address) is written to the authorizing\naccountâs code. All code executing operations must load and execute the code\npointed to by the delegation.\nMotivation\nDespite great advances in the smart contract wallet ecosystem, EOAs have held\nback broad adoption of UX improvements across applications. This EIP therefore\nfocuses on adding short-term functionality improvements to EOAs which will allow\nUX improvements to permeate through the entire application stack. Three\nparticular features this EIP is designed around are:\n- Batching : allowing multiple operations from the same user in one atomic\ntransaction. One common example is an ERC-20 approval followed by\nspending that approval. This is a common workflow in DEXes that requires two\ntransactions today. Advanced use cases of batching occasionally involve\ndependencies: the output of the first operation is part of the input to the\nsecond operation.\n- Sponsorship : account X pays for a transaction on behalf of account Y.\nAccount X could be paid in some other ERC-20 for this service, or it could be an\napplication operator including the transactions of its users for free.\n- Privilege de-escalation : users can sign sub-keys and give them specific\npermissions that are much weaker than global access to the account. For example,\na permission to spend ERC-20 tokens but not ETH, or to spend up to 1% of the\ntotal balance per day, or to interact only with a specific application.\nSpecification\nParameters\nParameter\nValue\nSET_CODE_TX_TYPE\n0x04\nMAGIC\n0x05\nPER_AUTH_BASE_COST\n12500\nPER_EMPTY_ACCOUNT_COST\n25000\nSet code transaction\nA new EIP-2718 transaction known as the âset code transactionâ\nis introduced, where the TransactionType is SET_CODE_TX_TYPE and the\nTransactionPayload is the RLP serialization of the following:\nrlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,\ndestination, value, data, access_list, authorization_list, signature_y_parity,\nsignature_r, signature_s])\nauthorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]\nThe fields chain_id , nonce , max_priority_fee_per_gas , max_fee_per_gas ,\ngas_limit , destination , value , data , and access_list of the outer\ntransaction follow the same semantics as EIP-4844 . Note, this\nimplies a null destination is not valid.\nThe signature_y_parity, signature_r, signature_s elements of this transaction\nrepresent a secp256k1 signature over keccak256(SET_CODE_TX_TYPE ||\nTransactionPayload) .\nThe authorization_list is a list of tuples that indicate what code the signer\nof each tuple desires to execute in the context of their EOA. The transaction is\nconsidered invalid if the length of authorization_list is zero.\nThe transaction is also considered invalid when any field in an authorization\ntuple cannot fit within the following bounds:\nassert auth . chain_id < 2 ** 256\nassert auth . nonce < 2 ** 64\nassert len ( auth . address ) == 20\nassert auth . y_parity < 2 ** 8\nassert auth . r < 2 ** 256\nassert auth . s < 2 ** 256\nThe EIP-2718 ReceiptPayload for this transaction is\nrlp([status, cumulative_transaction_gas_used, logs_bloom, logs]) .\nBehavior\nThe authorization list is processed before the execution portion of the\ntransaction begins, but after the senderâs nonce is incremented.\nFor each [chain_id, address, nonce, y_parity, r, s] tuple, perform the\nfollowing:\n- Verify the chain ID is 0 or the ID of the current chain.\n- Verify the nonce is less than 2**64 - 1 .\n- Let authority = ecrecover(msg, y_parity, r, s) .\n- Where msg = keccak(MAGIC || rlp([chain_id, address, nonce])) .\n- Verify s is less than or equal to secp256k1n/2 , as specified in\nEIP-2 .\n- Add authority to accessed_addresses , as defined in EIP-2929 .\n- Verify the code of authority is empty or already delegated.\n- Verify the nonce of authority is equal to nonce .\n- Add PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST gas to the global refund\ncounter if authority is not empty.\n- Set the code of authority to be 0xef0100 || address . This is a delegation\nindicator.\n- If address is 0x0000000000000000000000000000000000000000 , do not write\nthe delegation indicator. Clear the accountâs code by resetting the accountâs\ncode hash to the empty code hash\n0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 .\n- Increase the nonce of authority by one.\nIf any step above fails, immediately stop processing the tuple and continue to\nthe next tuple in the list. When multiple tuples from the same authority are\npresent, set the code using the address in the last valid occurrence.\nNote, if transaction execution results in failure (e.g. any exceptional\ncondition or code reverting), the processed delegation indicators is not rolled\nback .\nDelegation indicator\nDelegation indicators use the banned opcode 0xef , defined in\nEIP-3541 , to indicate that the code must be handled differently\nthan regular code. The delegation forces all code executing operations to follow\nthe address pointer to obtain the code to execute. For example, CALL loads the\ncode at address and executes it in the context of authority .\nThe affected executing operations are:\n- CALL\n- CALLCODE\n- DELEGATECALL\n- STATICCALL\n- any transaction where destination points to an address with a delegation\nindicator present\nFor code reading, only CODESIZE and CODECOPY instructions are affected. They\noperate directly on the executing code instead of the delegation. For example,\nwhen executing a delegated account EXTCODESIZE returns 23 (the size of\n0xef0100 || address ) whereas CODESIZE returns the size of the code residing\nat address .\nNote, this means during delegated execution CODESIZE and CODECOPY produce a\ndifferent result compared to calling EXTCODESIZE and EXTCODECOPY on the\nauthority.\nPrecompiles\nWhen a precompile address is the target of a delegation, the retrieved code is\nconsidered empty and CALL , CALLCODE , STATICCALL , DELEGATECALL\ninstructions targeting this account will execute empty code, and therefore\nsucceed with no execution when given enough gas to initiate the call.\nLoops\nIn case a delegation indicator points to another delegation, creating a\npotential chain or loop of delegations, clients must retrieve only the first\ncode and then stop following the delegation chain.\nGas Costs\nThe intrinsic cost of the new transaction is inherited from\nEIP-2930 , specifically 21000 + 16 * non-zero calldata bytes +\n4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access\nlist address count . Additionally, add a cost of PER_EMPTY_ACCOUNT_COST *\nauthorization list length .\nThe transaction sender will pay for all authorization tuples, regardless of\nvalidity or duplication.\nIf a code executing instruction accesses a cold account during the resolution of\ndelegated code, add an additional EIP-2929\nCOLD_ACCOUNT_READ_COST cost of 2600 gas to the normal cost and add the\naccount to accessed_addresses . Otherwise, assess a WARM_STORAGE_READ_COST\ncost of 100 .\nTransaction origination\nModify the restriction put in place by EIP-3607 to allow EOAs\nwhose code is a valid delegation indicator, i.e. 0xef0100 || address , to\noriginate transactions. Accounts with any other code values may not originate\ntransactions.\nAdditionally, if a transactionâs destination has a delegation indicator, add\nthe target of the delegation to accessed_addresses .\nRationale\nBelow is the rationale for both general design directions of the EIP, as well as\nspecific technical choices.\nGeneral design philosophy\nPersistence of code delegation\nThe first draft of this proposal had a clever idea to avoid disagreement on\nwhether in-protocol revocation was needed or not. The idea was to temporarily\nset code in the account with the authorization. After the transaction finished,\nthe code would be completely cleared. This was a new design space for enriching\nEOA functionality.\nEven this approach was not without its flaws. Fundamentally, there was not much\nfriction for users including set code authorizations. This meant that some users\nand applications would opt to treat the extension as more of a scripting\nfacility, rather than a full-fledged upgrade to a smart contract wallet. The\noutcome of this would be two somewhat competing workstreams for UX improvements:\nsmart contract wallets and EOA scripts.\nPrevious proposals had been met with similar criticisms. To counteract this,\npersistent delegations were introduced. They create enough friction in\ndeployment that users will not deploy new, unique ones regularly. This will\nhopefully unify the workstreams and minimize fragmentation in UX developments.\nNo initcode\nRunning initcode is not desirable for many reasons. It creates a new mode of\nexecution that needs extensive testing, and may be used for purposes not\npossible with standard smart contract wallets. It also forces developers to\nperform initialization as a standard call to the EOA after delegation. The lack\nof atomicity in these operations is another factor that will push users to\ncomplete smart contract wallet solutions, instead of EOA scripts.\nAdditionally, initcode tends to be propagated inside the transaction calldata.\nThis means it would need to be included in the authorization tuple and signed\nover. The minimum initcode is around 15 bytes â it would simply copy the\ncontract code from an external address. The total cost would be 16 * 15 = 240\ncalldata cost, plus the EIP-3860 cost of 2 * 15 = 30 , plus\nthe runtime costs of around 150 . So nearly 500 additional gas would be spent\npreparing the account. Even more likely, 1200+ gas if not copying from an\nexternal account.\nCreation by template\nInitcode or not, there is a question of how users should specify the code they\nintend to run in their account. The two main options are to specify the bytecode\ndirectly in the transaction or to specify a pointer to the code. The simplest\npointer would just be the address of code deployed on-chain.\nThe cost analysis makes the answer clear. The smallest proxy would be around 50\nbytes and an address is 20 bytes. The 30 byte difference provides no useful\nadditional functionality and will be inefficiently replicated billions of times.\nFurthermore, specifying code directly would again make it possible for EOAs to\nhave a new, unique ability to execute arbitrary code specified in the\ntransaction calldata. It is for these reasons that creation by template is\nchosen.\nInteraction with applications and wallets\nWhile this EIP provides a lot of flexibility to applications and EOAs, there are\nincorrect ways of using it. Applications must not expect that they can\nsuggest the user sign an authorization, and therefore it is the duty of the\nwallet to not provide an interface to do so.\nThere is no safe way to provide this interface . The code specified by an\nauthorization has unrestricted access to the account and must always be closely\naudited by the wallet. Few users have the level of sophistication to reasonably\nverify the code they are delegating to.\nIt is also not possible to implement a system of permissions at this level to\nminimize the risk. If applications require custom wallet functionality, they\nmust use standardized extension / module systems built on top of the delegated\ncode that correctly implements permissions.\nForward-compatibility with future account abstraction\nThis EIP is designed to be forward-compatible with endgame account abstraction,\nwithout over-enshrining any fine-grained details of ERC-4337 or\nRIP-7560.\nTo start, the address that users sign could directly point to existing\nERC-4337 wallet code. This essentially requires the âcode pathwaysâ that are\nused are code pathways that would, in most cases, continue to make sense in a\npure-smart-contract-wallet world. Hence, it avoids the problem of creating two\nseparate UX workstreams because, to a large extent, they would be the same\necosystem.\nThere will be some workflows that require kludges under this solution that would\nbe better done in some different âmore nativeâ under âendgame AAâ, but this is\nrelatively a small subset. The EIP does not require adding any opcodes, that\nwould become dangling and useless in a post-EOA world, and it allows EOAs to\nmasquerade as contracts to be included in ERC-4337 bundles, in a way thatâs\ncompatible with the existing EntryPoint .\nSelf-sponsoring: allowing tx.origin to set code\nAllowing tx.origin to set code and execute its own delegated code enables what\nis called self-sponsoring. It allows users to take advantage of EIP-7702 without\nrelying on any third party infrastructure.\nHowever, that means the EIP breaks the invariant that msg.sender == tx.origin\nonly happens in the topmost execution frame of a transaction. This will affect\nsmart contracts containing require(msg.sender == tx.origin) style checks. This\ncheck is used for at least three purposes:\n- Ensuring that msg.sender is an EOA (given that tx.origin always has to be\nan EOA). This invariant does not depend on the execution layer depth and,\ntherefore, is not affected.\n- Protecting against atomic sandwich attacks like flash loans, which rely on\nthe ability to modify state before and after the execution of the target\ncontract as part of the same atomic transaction. This protection would be broken\nby this EIP. However, relying on tx.origin in this way is considered bad\npractice, and can already be circumvented by miners conditionally including\ntransactions in a block.\n- Preventing reentrancy.\nExamples of (1) and (2) can be found in contracts deployed on Ethereum mainnet,\nwith (1) being more common (and unaffected by this proposal). On the other hand,\nuse case (3) is more severely affected by this proposal, but the authors of this\nEIP did not find any examples of this form of reentrancy protection, though the\nsearch was non-exhaustive.\nThis distribution of occurrencesâmany (1), some (2), and no (3)âis exactly what\nthe authors of this EIP expect because:\n- Determining if msg.sender is an EOA without tx.origin is difficult, if not\nimpossible.\n- The only execution context which is safe from atomic sandwich attacks is the\ntopmost context, and tx.origin == msg.sender is the only way to detect that\ncontext.\n- In contrast, there are many direct and flexible ways of preventing reentrancy\n(e.g., using a transient storage variable). Since msg.sender == tx.origin is\nonly true in the topmost context, it would make an obscure tool for preventing\nreentrancy, rather than other more common approaches.\nThere are other approaches to mitigate this restriction which do not break the\ninvariant:\n- Set tx.origin to a constant ENTRY_POINT address when using the CALL*\ninstruction in the context of an EOA.\n- Set tx.origin to a special address derived from the sender or signer\naddresses.\n- Disallow tx.origin from setting code. This would make the simple batching\nuse cases impossible, but could be relaxed in the future.\nRationale for technical details\nCost of delegation\nThe PER_AUTH_BASE_COST is the cost to process the authorization tuple and set\nthe delegation destination. To compute a fair cost for this operation, the\nauthors review its impact on the system:\n- ferry 101 bytes of calldata = 101 * non-zero cost (16) = 1616\n- recovering the authority address = 3000\n- reading the nonce and code of authority = 2600\n- storing values in already warm account = 200\n- cost to deploy code = 200 * 23 = 4600\nThe impact-based assessment identifies 12016 gas of comparable computation for\nthe operation. It is rounded up to 12500 to account for miscellaneous costs\nassociated with shuttling data around the state transition.\nClearing delegation indicators\nA general design goal in state transition changes is to minimize the number of\nspecial cases an EIP has. In early iterations, this EIP resisted a special case\nfor clearing an accountâs delegation indicator.\nFor most intents and purposes, an account delegated to 0x0 is\nindistinguishable from a true EOA. However, one particular unfortunate case is\nunavoidable. Even if a user has a zeroed out delegation indicator, most\noperations that interact with that account will incur an additional\nCOLD_ACCOUNT_READ_COST upon the first touch caused by attempting to load the\ncode at 0x0 .\nFor this reason, the authors have opted to include a special case which allow\nusers to restore their EOA to its original purity.\nLack of instruction prohibition\nConsistency is a valuable property in the EVM, both from an implementation\nperspective and a user-understanding-perspective. Despite considering bans on\nseveral families of instructions in the context of EOAs, the authors feel there\nis not a compelling reason to do so, as it would cause smart contract wallets\nand EOA smart contract wallets to proceed down distinct UX workstreams.\nThe main instruction families where a ban was considered were storage related\nand contract creation related. The decision to not ban storage instructions\nhinged mostly on their importance to smart contract wallets. Although itâs\npossible to have an external storage contract that the smart contract wallet\ncalls into, it is unnecessarily complicated and inefficient. In the future, new\nstate schemes may allow substantially cheaper access to certain storage slots\nwithin an account. This is something smart contract wallets will want to take\nadvantage of that a storage contract wouldnât support.\nCreation instructions were considered for a ban as well on other similar EIPs,\nhowever because this EIP allows EOAs to spend value intra-transaction, the\nconcern with bumping the nonce intra-transaction and invalidating pending\ntransactions is not significant.\nProtection from malleability cross-chain\nOne consideration when signing a code pointer is what code that address points\nto on another chain. While it is possible to create a deterministic deployment,\ni.e. via Nickâs method, verifying such a deployment may not always be desirable.\nIn such situations, the chain ID can be set to reduce the scope of the\nauthorization. When universal deployment is preferred, simply set chain ID to 0.\nAn alternative to adding chain ID could be to substitute in the actual code for\nthe address in the signature. This seems to have the benefit of both minimizing\nthe on-chain size of auth tuples, by continuing to serialize only the address,\nwhile retaining specificity of the actual code running in the account, by\npulling in the code for the signature. One unfortunate issue of this format,\nthough, is that it imposes a database lookup to determine the signer of each\nauth tuple. This imposition itself seems to create enough complexity in\ntransaction propagation that it is decided to avoid and simply sign over the\naddress directly.\nDelegation of code execution only\nOther code retrieving operations like EXTCODEHASH do not automatically follow\ndelegations, they operate on the delegation indicator itself. If instead\ndelegations were followed, an account would be able to temporarily masquerade as\nhaving a particular codehash, which would break contracts that rely on\ncodehashes as a definition of possible account behavior. A change of behavior in\na contract is currently only possible if its code explicitly allows it (in\nparticular via DELEGATECALL ), and a change of codehash is only possible in the\npresence of SELFDESTRUCT (which, as of Cancun, only applies in the same\ntransaction as contract creation), so choosing to follow delegations in\nEXTCODE* opcodes would have created a new type of account breaking prior\nassumptions.\nCharge maximum cost upfront\nWhile computing the intrinsic gas cost, the transaction is charged the\nworst-case cost for each delegation. Later, while processing the authorization\nlist, a refund is issued if the account already exists in state. This mechanism\nis designed to avoid state lookups for each authorization when computing the\nintrinsic gas and can quickly determine the validity of the transaction with\nonly a state lookup on the senderâs account.\nNo blobs, no contract creation\nTransactions should be thought of as specialized tools and not necessarily a\none-type-does-all solution. EIP-4844 is treated differently at the p2p level due\nto burden blobs place on a nodeâs bandwidth. EIP-7702 has different implications\non transaction gossiping and there is no need to complicate those rules\nunnecessarily by making it a superset of all possible functionality. The authors\nultimately do not expect there to be much demand for atomic delegation and blob\nsubmission.\nContract creation is another specialized use case that has been grandfathered\ninto several transaction types. It adds complexity to testing, because it is a\nnew distinct branch of execution that needs to be tested when any change to the\nEVM occurs and verify the change works as expected in that context.\nFor these reasons, the authors have chosen to keep the scope of the EIP focused\non improving UX.\nDisallow delegation to precompiles\nPrecompiles are themselves edge cases, so allowing delegations to precompiles or\nnot requires some focus in implementation. Considering the fact that precompiles\ntechnically do not have code associated with their accounts, the authors decided\nit would be marginally simpler to not execute the precompile logic when a user\ndelegates to one. This is somewhat unintuitive.\nNon-empty authorization list required\nSet code transactions are required to have at least one authorization to be\nconsidered valid. This is to disincentivize senders from using type 4\ntransactions as a generic transaction format, because this transaction has\ndifferent implications on the transaction pool than, say,\nEIP-1559 transactions.\nBackwards Compatibility\nThis EIP breaks a few invariants:\n- An account balance can only decrease as a result of a transaction originating\nfrom that account.\n- Once an account has been delegated, any call to the account may also cause\nthe balance to decrease.\n- An EOA nonce may not increase after transaction execution has begun.\n- Once an account has been delegated, the account may call a create operation\nduring execution, causing the nonce to increase.\n- tx.origin == msg.sender can only be true in the topmost frame of execution.\n- Once an account has been delegated, it can invoke multiple calls per\ntransaction.\nSecurity Considerations\nImplementation of secure delegate contracts\nThe following is a non-exhaustive list of pitfalls that delegate contracts\nshould be wary of and require a signature over from the accountâs authority:\n- Replay protection (e.g., a nonce) should be implemented by the delegate and\nsigned over. Without it, a malicious actor can reuse a signature, repeating its\neffects.\n- value â without it, a malicious sponsor could cause unexpected effects in\nthe callee.\n- gas â without it, a malicious sponsor could cause the callee to run out of\ngas and fail, griefing the sponsee.\n- target / calldata â without them, a malicious actor may call arbitrary\nfunctions in arbitrary contracts.\nA poorly implemented delegate can allow a malicious actor to take near complete\ncontrol over a signerâs EOA .\nFront running initialization\nSmart contract wallet developers must consider the implications of setting code\nin an account without execution. Contracts are normally deployed by executing\ninitcode to determine the exact code to be placed in the account. This gives\ndevelopers the opportunity to initialize storage slots at the same time. The\ninitial values of the account cannot be replaced by an observer, because they\nare either signed over by an EOA in the case of a creation transaction or they\nare committed to by computing the contractâs address deterministically from the\nhash of the initcode.\nThis EIP does not provide developers the opportunity to run initcode and set\nstorage slots during delegation. To secure the account from an observer\nfront-running the initialization of the delegation with an account they control,\nsmart contract wallet developers must verify the initial calldata to the account\nfor setup purposes be signed by the EOAâs key using ecrecover. This ensures the\naccount can only be initialized with desirable values.\nStorage management\nChanging an accountâs delegation is a security-critical operation that should\nnot be done lightly, especially if the newly delegated code is not purposely\ndesigned and tested as an upgrade to the old one.\nIn particular, in order to ensure a safe migration of an account from one\ndelegate contract to another, itâs important for these contracts to use storage\nin a way that avoids accidental collisions among them. For example, using\nERC-7201 a contract may root its storage layout at a slot\ndependent on a unique identifier. To simplify this, smart contract languages may\nprovide a way of re-rooting the entire storage layout of existing contract\nsource code.\nIf all contracts previously delegated to by the account used the approach\ndescribed above, a migration should not cause any issues. However, if there is\nany doubt, it is recommended to first clear all account storage, an operation\nthat is not natively offered by the protocol but that a special-purpose delegate\ncontract can be designed to implement.\nSetting code as tx.origin\nAllowing the sender of an EIP-7702 to also set code has the possibility to:\n- Break atomic sandwich protections which rely on tx.origin ;\n- Break reentrancy guards of the style require(tx.origin == msg.sender) .\nThe authors of this EIP believe the risks of allowing this are acceptable for\nthe reasons outlined in the Rationale section.\nSponsored transaction relayers\nIt is possible for the authorized account to cause sponsored transaction\nrelayers to spend gas without being reimbursed by either invalidating the\nauthorization (i.e., increasing the accountâs nonce) or by sweeping the relevant\nassets out of the account. Relayers should be designed with these cases in mind,\npossibly by requiring a bond to be deposited or by implementing a reputation\nsystem.\nTransaction propagation\nAllowing EOAs to behave as smart contracts via the delegation indicator poses\nsome challenges for transaction propagation. Traditionally, EOAs have only been\nable to send value via a transaction. This invariant allows nodes to statically\ndetermine the validity of transactions for that account. In other words, a\nsingle transaction has only been able to invalidate transactions pending from\nthe senderâs account.\nWith this EIP, it becomes possible to cause transactions from other accounts to\nbecome stale. This is due to the fact that once an EOA has delegated to code,\nthat code can be called by anyone at any point in a transaction. It becomes\nimpossible to know if the balance of the account has been swept in a static\nmanner.\nWhile there are a few mitigations for this, the authors recommend that clients\ndo not accept more than one pending transaction for any EOA with a non-zero\ndelegation indicator. This minimizes the number of transactions that can be\ninvalidated by a single transaction.\nAn alternative would be to expand the EIP-7702 transaction with a list of\naccounts the caller wishes to âhydrateâ during the transaction. Those accounts\nbehave as the delegated code only for EIP-7702 transactions which include them\nin such a list, thus returning to clients the ability to statically analyze and\nreason about pending transactions.\nA related issue is that an EOAâs nonce may be incremented more than once per\ntransaction. Because clients already need to be robust in a worse scenario\n(described above), it isnât a major concern. However, clients should be aware\nthis behavior is possible and design their transaction propagation accordingly.\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nVitalik Buterin ( @vbuterin ), Sam Wilson ( @SamWilsn ), Ansgar Dietrichs ( @adietrichs ), lightclient ( @lightclient ), \"EIP-7702: Set Code for EOAs,\" Ethereum Improvement Proposals , no. 7702, May 2024. Available: https://eips.ethereum.org/EIPS/eip-7702."}
{"url":"https://raw.githubusercontent.com/bitcoin/bips/master/README.mediawiki","domain":"raw.githubusercontent.com","title":"","hash":"89d7d3ac8bf5500141f7d6bcaeb695843d5a98f8e544d622696756dc1cb8211e","tokens":8954,"chars":35816,"crawler":"hive-genesis","verified":"exact","ts":1791112024722,"text":"People wishing to submit a BIP should first describe their idea to the [https://groups.google.com/g/bitcoindev bitcoindev@googlegroups.com]\nmailing list to gather feedback on viability and community interest before working on a\nformal description. Please open a pull request to this repository only when substantial progress on the draft has been\nmade, preferably when the draft is nearing completion. Authors do not assign a number to their own proposal.\nAfter a proposal meets the editorial criteria, a BIP Editor will assign a number to it and publish the proposal by\nmerging the pull request to the repository. Please see [[bip-0003.md|BIPâŻ3: Updated BIP Process]] for the full process.\nThe BIPs repository serves as a publication medium and archive. Having a BIP published here indicates that the proposal\nis in scope and has met other formal criteria for this repository, but does not indicate that it is a good idea, has\ncommunity consensus, or that it is about to be adopted. The BIP Editors are expected to be liberal with publishing BIPs\nand to try not to be too involved in decision-making on behalf of the community. Beyond the formal criteria, evaluation of\nthe proposals is left to the audience of the repository. When a proposal is controversial and it cannot be agreed upon\nwhether it should be published, the conservative option will always be preferred: the proposal will be closed.\nThose proposing and opposing changes should consider that ultimately acceptance and adoption rests with the Bitcoin\nusers (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority]).\n{| class=\"wikitable sortable\" style=\"width: auto; text-align: center; font-size: smaller; table-layout: fixed;\"\n!Number\n!Layer\n!Title\n!Owner\n!Type\n!Status\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0001.mediawiki|1]]\n|\n| BIP Purpose and Guidelines\n| Amir Taaki\n| Process\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0002.mediawiki|2]]\n|\n| BIP process, revised\n| Luke Dashjr\n| Process\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0003.md|3]]\n|\n| Updated BIP Process\n| Murch\n| Process\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0008.mediawiki|8]]\n|\n| Version bits with lock-in by height\n| Shaolin Fry, Luke Dashjr\n| Informational\n| Complete\n|- style=\"background-color: #cfffcf\"\n| [[bip-0009.mediawiki|9]]\n|\n| Version bits with timeout and delay\n| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell\n| Informational\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0010.mediawiki|10]]\n| Applications\n| Multi-Sig Transaction Distribution\n| Alan Reiner\n| Informational\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0011.mediawiki|11]]\n| Applications\n| M-of-N Standard Transactions\n| Gavin Andresen\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0012.mediawiki|12]]\n| Consensus (soft fork)\n| OP_EVAL\n| Gavin Andresen\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0013.mediawiki|13]]\n| Applications\n| Address Format for pay-to-script-hash\n| Gavin Andresen\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0014.mediawiki|14]]\n| Peer Services\n| Protocol Version and User Agent\n| Amir Taaki, Patrick Strateman\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0015.mediawiki|15]]\n| Applications\n| Aliases\n| Amir Taaki\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0016.mediawiki|16]]\n| Consensus (soft fork)\n| Pay to Script Hash\n| Gavin Andresen\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0017.mediawiki|17]]\n| Consensus (soft fork)\n| OP_CHECKHASHVERIFY (CHV)\n| Luke Dashjr\n| Specification\n| Closed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0018.mediawiki|18]]\n| Consensus (soft fork)\n| hashScriptCheck\n| Luke Dashjr\n| Specification\n| Complete\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0019.mediawiki|19]]\n| Applications\n| M-of-N Standard Transactions (Low SigOp)\n| Luke Dashjr\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0020.mediawiki|20]]\n| Applications\n| URI Scheme\n| Luke Dashjr\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0021.mediawiki|21]]\n| Applications\n| URI Scheme\n| Nils Schneider, Matt Corallo\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0022.mediawiki|22]]\n| API/RPC\n| getblocktemplate - Fundamentals\n| Luke Dashjr\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0023.mediawiki|23]]\n| API/RPC\n| getblocktemplate - Pooled Mining\n| Luke Dashjr\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0030.mediawiki|30]]\n| Consensus (soft fork)\n| Duplicate transactions\n| Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0031.mediawiki|31]]\n| Peer Services\n| Pong message\n| Mike Hearn\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0032.mediawiki|32]]\n| Applications\n| Hierarchical Deterministic Wallets\n| Pieter Wuille\n| Informational\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0033.mediawiki|33]]\n| Peer Services\n| Stratized Nodes\n| Amir Taaki\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0034.mediawiki|34]]\n| Consensus (soft fork)\n| Block v2, Height in Coinbase\n| Gavin Andresen\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0035.mediawiki|35]]\n| Peer Services\n| mempool message\n| Jeff Garzik\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0036.mediawiki|36]]\n| Peer Services\n| Custom Services\n| Stefan Thomas\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0037.mediawiki|37]]\n| Peer Services\n| Connection Bloom filtering\n| Mike Hearn, Matt Corallo\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0038.mediawiki|38]]\n| Applications\n| Passphrase-protected private key\n| Mike Caldwell, Aaron Voisine\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0039.mediawiki|39]]\n| Applications\n| Mnemonic code for generating deterministic keys\n| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe\n| Specification\n| Deployed\n|-\n| 40\n| API/RPC\n| Stratum wire protocol\n| Marek Palatinus\n| Standard\n| BIP number allocated\n|-\n| 41\n| API/RPC\n| Stratum mining protocol\n| Marek Palatinus\n| Standard\n| BIP number allocated\n|- style=\"background-color: #cfffcf\"\n| [[bip-0042.mediawiki|42]]\n| Consensus (soft fork)\n| A finite monetary supply for Bitcoin\n| Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0043.mediawiki|43]]\n| Applications\n| Purpose Field for Deterministic Wallets\n| Marek Palatinus, Pavol Rusnak\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0044.mediawiki|44]]\n| Applications\n| Multi-Account Hierarchy for Deterministic Wallets\n| Marek Palatinus, Pavol Rusnak\n| Specification\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0045.mediawiki|45]]\n| Applications\n| Structure for Deterministic P2SH Multisignature Wallets\n| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia\n| Specification\n| Complete\n|-\n| [[bip-0046.mediawiki|46]]\n| Applications\n| Address Scheme for Timelocked Fidelity Bonds\n| Chris Belcher, Thebora Kompanioni\n| Specification\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0047.mediawiki|47]]\n| Applications\n| Reusable Payment Codes for Hierarchical Deterministic Wallets\n| Justus Ranvier\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0048.mediawiki|48]]\n| Applications\n| Multi-Script Hierarchy for Multi-Sig Wallets\n| Fontaine\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0049.mediawiki|49]]\n| Applications\n| Derivation scheme for P2WPKH-nested-in-P2SH based accounts\n| Daniel Weigl\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0050.mediawiki|50]]\n|\n| March 2013 Chain Fork Post-Mortem\n| Gavin Andresen\n| Informational\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0052.mediawiki|52]]\n| Consensus (hard fork)\n| Durable, Low Energy Bitcoin PoW\n| Michael Dubrovsky, Bogdan Penkovsky\n| Specification\n| Closed\n|-\n| [[bip-0053.mediawiki|53]]\n| Consensus (soft fork)\n| Disallow 64-byte transactions\n| Chris Stewart\n| Specification\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0054.md|54]]\n| Consensus (soft fork)\n| Consensus Cleanup\n| Antoine Poinsot, Matt Corallo\n| Specification\n| Complete\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0060.mediawiki|60]]\n| Peer Services\n| Fixed Length \"version\" Message (Relay-Transactions Field)\n| Amir Taaki\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0061.mediawiki|61]]\n| Peer Services\n| Reject P2P message\n| Gavin Andresen\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0062.mediawiki|62]]\n| Consensus (soft fork)\n| Dealing with malleability\n| Pieter Wuille\n| Specification\n| Closed\n|-\n| 63\n| Applications\n| Stealth Addresses\n| Peter Todd\n| Standard\n| BIP number allocated\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0064.mediawiki|64]]\n| Peer Services\n| getutxo message\n| Mike Hearn\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0065.mediawiki|65]]\n| Consensus (soft fork)\n| OP_CHECKLOCKTIMEVERIFY\n| Peter Todd\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0066.mediawiki|66]]\n| Consensus (soft fork)\n| Strict DER signatures\n| Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0067.mediawiki|67]]\n| Applications\n| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting\n| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries\n| Specification\n| Complete\n|- style=\"background-color: #cfffcf\"\n| [[bip-0068.mediawiki|68]]\n| Consensus (soft fork)\n| Relative lock-time using consensus-enforced sequence numbers\n| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona\n| Specification\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0069.mediawiki|69]]\n| Applications\n| Lexicographical Indexing of Transaction Inputs and Outputs\n| Kristov Atlas\n| Informational\n| Complete\n|- style=\"background-color: #cfffcf\"\n| [[bip-0070.mediawiki|70]]\n| Applications\n| Payment Protocol\n| Gavin Andresen, Mike Hearn\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0071.mediawiki|71]]\n| Applications\n| Payment Protocol MIME types\n| Gavin Andresen\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0072.mediawiki|72]]\n| Applications\n| bitcoin: uri extensions for Payment Protocol\n| Gavin Andresen\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0073.mediawiki|73]]\n| Applications\n| Use \"Accept\" header for response type negotiation with Payment Request URLs\n| Stephen Pair\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0074.mediawiki|74]]\n| Applications\n| Allow zero value OP_RETURN in Payment Protocol\n| Toby Padilla\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0075.mediawiki|75]]\n| Applications\n| Out of Band Address Exchange using Payment Protocol Encryption\n| Justin Newton, Matt David, Aaron Voisine, James MacWhyte\n| Specification\n| Deployed\n|-\n| [[bip-0077.md|77]]\n| Applications\n| Async Payjoin\n| Dan Gould, Yuval Kogman\n| Specification\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0078.mediawiki|78]]\n| Applications\n| A Simple Payjoin Proposal\n| Nicolas Dorier\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0079.mediawiki|79]]\n| Applications\n| Bustapay :: a practical coinjoin protocol\n| Ryan Havar\n| Informational\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0080.mediawiki|80]]\n|\n| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets\n| Justus Ranvier, Jimmy Song\n| Informational\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0081.mediawiki|81]]\n|\n| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets\n| Justus Ranvier, Jimmy Song\n| Informational\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0083.mediawiki|83]]\n| Applications\n| Dynamic Hierarchical Deterministic Key Trees\n| Eric Lombrozo\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0084.mediawiki|84]]\n| Applications\n| Derivation scheme for P2WPKH based accounts\n| Pavol Rusnak\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0085.mediawiki|85]]\n| Applications\n| Deterministic Entropy From BIP32 Keychains\n| Ethan Kosakovsky, Aneesh Karve\n| Informational\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0086.mediawiki|86]]\n| Applications\n| Key Derivation for Single Key P2TR Outputs\n| Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0087.mediawiki|87]]\n| Applications\n| Hierarchy for Deterministic Multisig Wallets\n| Robert Spigler\n| Specification\n| Complete\n|- style=\"background-color: #ffffcf\"\n| [[bip-0088.mediawiki|88]]\n| Applications\n| Hierarchical Deterministic Path Templates\n| Dmitry Petukhov\n| Informational\n| Complete\n|- style=\"background-color: #cfffcf\"\n| [[bip-0089.mediawiki|89]]\n| Applications\n| Chain Code Delegation\n| Jesse Posner, Jurvis Tan\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0090.mediawiki|90]]\n|\n| Buried Deployments\n| Suhas Daftuar\n| Informational\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0091.mediawiki|91]]\n| Consensus (soft fork)\n| Reduced threshold Segwit MASF\n| James Hilliard\n| Specification\n| Deployed\n|-\n| [[bip-0093.mediawiki|93]]\n| Applications\n| codex32: Checksummed SSSS-aware BIP32 seeds\n| Leon Olsson Curr, Pearlwort Sneed, Andrew Poelstra\n| Informational\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0094.mediawiki|94]]\n| Applications\n| Testnet 4\n| Fabian Jahr\n| Specification\n| Deployed\n|-\n| [[bip-0095.md|95]]\n| Applications\n| Testnet 5\n| Pol Espinasa, Fabian Jahr\n| Specification\n| Draft\n|-\n| [[bip-0098.mediawiki|98]]\n| Consensus (soft fork)\n| Fast Merkle Trees\n| Mark Friedenbach, Kalle Alm, BtcDrak\n| Specification\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0099.mediawiki|99]]\n|\n| Motivation and deployment of consensus rule changes ([soft/hard]forks)\n| Jorge TimĂłn\n| Informational\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0100.mediawiki|100]]\n| Consensus (hard fork)\n| Dynamic maximum block size by miner vote\n| Jeff Garzik, Tom Harding, Dagur Valberg Johannsson\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0101.mediawiki|101]]\n| Consensus (hard fork)\n| Increase maximum block size\n| Gavin Andresen\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0102.mediawiki|102]]\n| Consensus (hard fork)\n| Block size increase to 2MB\n| Jeff Garzik\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0103.mediawiki|103]]\n| Consensus (hard fork)\n| Block size following technological growth\n| Pieter Wuille\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0104.mediawiki|104]]\n| Consensus (hard fork)\n| 'Block75' - Max block size like difficulty\n| t.khan\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0105.mediawiki|105]]\n| Consensus (hard fork)\n| Consensus based block size retargeting algorithm\n| BtcDrak\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0106.mediawiki|106]]\n| Consensus (hard fork)\n| Dynamically Controlled Bitcoin Block Size Max Cap\n| Upal Chakraborty\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0107.mediawiki|107]]\n| Consensus (hard fork)\n| Dynamic limit on the block size\n| Washington Y. Sanchez\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0109.mediawiki|109]]\n| Consensus (hard fork)\n| Two million byte size limit with sigop and sighash limits\n| Gavin Andresen\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0110.mediawiki|110]]\n| Consensus (soft fork)\n| Reduced Data Temporary Softfork\n| Dathon Ohm\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0111.mediawiki|111]]\n| Peer Services\n| NODE_BLOOM service bit\n| Matt Corallo, Peter Todd\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0112.mediawiki|112]]\n| Consensus (soft fork)\n| CHECKSEQUENCEVERIFY\n| BtcDrak, Mark Friedenbach, Eric Lombrozo\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0113.mediawiki|113]]\n| Consensus (soft fork)\n| Median time-past as endpoint for lock-time calculations\n| Thomas Kerin, Mark Friedenbach\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0114.mediawiki|114]]\n| Consensus (soft fork)\n| Merkelized Abstract Syntax Tree\n| Johnson Lau\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0115.mediawiki|115]]\n| Consensus (soft fork)\n| Generic anti-replay protection using Script\n| Luke Dashjr\n| Specification\n| Closed\n|-\n| [[bip-0116.mediawiki|116]]\n| Consensus (soft fork)\n| MERKLEBRANCHVERIFY\n| Mark Friedenbach, Kalle Alm, BtcDrak\n| Specification\n| Draft\n|-\n| [[bip-0117.mediawiki|117]]\n| Consensus (soft fork)\n| Tail Call Execution Semantics\n| Mark Friedenbach, Kalle Alm, BtcDrak\n| Specification\n| Draft\n|-\n| [[bip-0118.mediawiki|118]]\n| Consensus (soft fork)\n| SIGHASH_ANYPREVOUT for Taproot Scripts\n| Christian Decker, Anthony Towns\n| Specification\n| Draft\n|-\n| [[bip-0119.mediawiki|119]]\n| Consensus (soft fork)\n| CHECKTEMPLATEVERIFY\n| Jeremy Rubin\n| Specification\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0120.mediawiki|120]]\n| Applications\n| Proof of Payment\n| Kalle Rosenbaum\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0121.mediawiki|121]]\n| Applications\n| Proof of Payment URI scheme\n| Kalle Rosenbaum\n| Specification\n| Closed\n|-\n| [[bip-0122.mediawiki|122]]\n| Applications\n| URI scheme for Blockchain references / exploration\n| Marco Pontello\n| Specification\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0123.mediawiki|123]]\n|\n| BIP Classification\n| Eric Lombrozo\n| Process\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0124.mediawiki|124]]\n| Applications\n| Hierarchical Deterministic Script Templates\n| Eric Lombrozo, William Swanson\n| Informational\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0125.mediawiki|125]]\n| Applications\n| Opt-in Full Replace-by-Fee Signaling\n| David A. Harding, Peter Todd\n| Specification\n| Deployed\n|-\n| [[bip-0126.mediawiki|126]]\n|\n| Best Practices for Heterogeneous Input Script Transactions\n| Kristov Atlas\n| Informational\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0127.mediawiki|127]]\n| Applications\n| Simple Proof-of-Reserves Transactions\n| Steven Roose\n| Specification\n| Complete\n|-\n| [[bip-0128.mediawiki|128]]\n| Applications\n| Timelock-Recovery Storage Format\n| Oren Z\n| Specification\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0129.mediawiki|129]]\n| Applications\n| Bitcoin Secure Multisig Setup (BSMS)\n| Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak\n| Specification\n| Complete\n|- style=\"background-color: #cfffcf\"\n| [[bip-0130.mediawiki|130]]\n| Peer Services\n| sendheaders message\n| Suhas Daftuar\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0131.mediawiki|131]]\n| Consensus (hard fork)\n| \"Coalescing Transaction\" Specification (wildcard inputs)\n| Chris Priest\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0132.mediawiki|132]]\n|\n| Committee-based BIP Acceptance Process\n| Andy Chase\n| Process\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0133.mediawiki|133]]\n| Peer Services\n| feefilter message\n| Alex Morcos\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0134.mediawiki|134]]\n| Consensus (hard fork)\n| Flexible Transactions\n| Tom Zander\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0135.mediawiki|135]]\n|\n| Generalized version bits voting\n| Sancho Panza\n| Informational\n| Closed\n|-\n| [[bip-0136.mediawiki|136]]\n| Applications\n| Bech32 Encoded Tx Position References\n| ĐДлДŃлаĐČ, Jonas Schnelli, Daniel Pape\n| Informational\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0137.mediawiki|137]]\n| Applications\n| Signatures of Messages using Private Keys\n| Christopher Gilliard\n| Specification\n| Deployed\n|-\n| [[bip-0138.md|138]]\n| Applications\n| Compact Encryption Scheme for Non-seed Wallet Data\n| Pyth\n| Specification\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0140.mediawiki|140]]\n| Consensus (soft fork)\n| Normalized TXID\n| Christian Decker\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0141.mediawiki|141]]\n| Consensus (soft fork)\n| Segregated Witness (Consensus layer)\n| Eric Lombrozo, Johnson Lau, Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0142.mediawiki|142]]\n| Applications\n| Address Format for Segregated Witness\n| Johnson Lau\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0143.mediawiki|143]]\n| Consensus (soft fork)\n| Transaction Signature Verification for Version 0 Witness Program\n| Johnson Lau, Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0144.mediawiki|144]]\n| Peer Services\n| Segregated Witness (Peer Services)\n| Eric Lombrozo, Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0145.mediawiki|145]]\n| API/RPC\n| getblocktemplate Updates for Segregated Witness\n| Luke Dashjr\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0146.mediawiki|146]]\n| Consensus (soft fork)\n| Dealing with signature encoding malleability\n| Johnson Lau, Pieter Wuille\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0147.mediawiki|147]]\n| Consensus (soft fork)\n| Dealing with dummy stack element malleability\n| Johnson Lau\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0148.mediawiki|148]]\n| Consensus (soft fork)\n| Mandatory activation of segwit deployment\n| Shaolin Fry\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0149.mediawiki|149]]\n| Consensus (soft fork)\n| Segregated Witness (second deployment)\n| Shaolin Fry\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0150.mediawiki|150]]\n| Peer Services\n| Peer Authentication\n| Jonas Schnelli\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0151.mediawiki|151]]\n| Peer Services\n| Peer-to-Peer Communication Encryption\n| Jonas Schnelli\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0152.mediawiki|152]]\n| Peer Services\n| Compact Block Relay\n| Matt Corallo\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0154.mediawiki|154]]\n| Peer Services\n| Rate Limiting via peer specified challenges\n| Karl-Johan Alm\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0155.mediawiki|155]]\n| Peer Services\n| addrv2 message\n| Wladimir J. van der Laan\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0156.mediawiki|156]]\n| Peer Services\n| Dandelion - Privacy Enhancing Routing\n| Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0157.mediawiki|157]]\n| Peer Services\n| Client Side Block Filtering\n| Olaoluwa Osuntokun, Alex Akselrod, Jim Posen\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0158.mediawiki|158]]\n| Peer Services\n| Compact Block Filters for Light Clients\n| Olaoluwa Osuntokun, Alex Akselrod\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0159.mediawiki|159]]\n| Peer Services\n| NODE_NETWORK_LIMITED service bit\n| Jonas Schnelli\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0171.mediawiki|171]]\n| Applications\n| Currency/exchange rate information API\n| Luke Dashjr\n| Specification\n| Closed\n|-\n| [[bip-0172.mediawiki|172]]\n| Applications\n| Define Bitcoin Subunits as Satoshis\n| OceanSlim\n| Informational\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0173.mediawiki|173]]\n| Applications\n| Base32 address format for native v0-16 witness outputs\n| Pieter Wuille, Greg Maxwell\n| Informational\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0174.mediawiki|174]]\n| Applications\n| Partially Signed Bitcoin Transaction Format\n| Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0175.mediawiki|175]]\n| Applications\n| Pay to Contract Protocol\n| Omar Shibli, Nicholas Gregory\n| Informational\n| Closed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0176.mediawiki|176]]\n|\n| Bits Denomination\n| Jimmy Song\n| Informational\n| Complete\n|-\n| [[bip-0177.mediawiki|177]]\n|\n| Redefine Bitcoin's Base Unit\n| John Carvalho\n| Informational\n| Draft\n|-\n| [[bip-0178.mediawiki|178]]\n| Applications\n| Version Extended WIF\n| Karl-Johan Alm\n| Specification\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0179.mediawiki|179]]\n|\n| Name for payment recipient identifiers\n| Emil Engler, Luke Dashjr\n| Informational\n| Complete\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0180.mediawiki|180]]\n| Peer Services\n| Block size/weight fraud proof\n| Luke Dashjr\n| Specification\n| Closed\n|-\n| [[bip-0197.mediawiki|197]]\n| Applications\n| Hashed Time-Locked Collateral Contract\n| Matthew Black, Tony Cai\n| Specification\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0199.mediawiki|199]]\n| Applications\n| Hashed Time-Locked Contract transactions\n| Sean Bowe, Daira Hopwood\n| Specification\n| Closed\n|-\n| [[bip-0300.mediawiki|300]]\n| Consensus (soft fork)\n| Hashrate Escrows (Consensus layer)\n| Paul Sztorc, CryptAxe\n| Specification\n| Draft\n|-\n| [[bip-0301.mediawiki|301]]\n| Consensus (soft fork)\n| Blind Merged Mining (Consensus layer)\n| Paul Sztorc, CryptAxe\n| Specification\n| Draft\n|-\n| [[bip-0310.mediawiki|310]]\n| Applications\n| Stratum protocol extensions\n| Pavel Moravec, Jan Äapek\n| Informational\n| Draft\n|-\n| [[bip-0320.mediawiki|320]]\n|\n| nVersion bits for general purpose use\n| BtcDrak\n| Specification\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0321.mediawiki|321]]\n| Applications\n| URI Scheme\n| Matt Corallo\n| Specification\n| Complete\n|- style=\"background-color: #ffffcf\"\n| [[bip-0322.mediawiki|322]]\n| Applications\n| Generic Signed Message Format\n| Karl-Johan Alm, Oliver Gugger\n| Specification\n| Complete\n|-\n| [[bip-0323.mediawiki|323]]\n|\n| 24 nVersion bits for general purpose use\n| Matt Corallo\n| Specification\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0324.mediawiki|324]]\n| Peer Services\n| Version 2 P2P Encrypted Transport Protocol\n| Dhruv Mehta, Tim Ruffing, Jonas Schnelli, Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0325.mediawiki|325]]\n| Applications\n| Signet\n| Karl-Johan Alm, Anthony Towns\n| Specification\n| Complete\n|-\n| [[bip-0326.mediawiki|326]]\n| Applications\n| Anti-fee-sniping in taproot transactions\n| Chris Belcher\n| Informational\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0327.mediawiki|327]]\n|\n| MuSig2 for BIP340-compatible Multi-Signatures\n| Jonas Nick, Tim Ruffing, Elliott Jin\n| Informational\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0328.mediawiki|328]]\n| Applications\n| Derivation Scheme for MuSig2 Aggregate Keys\n| Ava Chow\n| Informational\n| Complete\n|-\n| [[bip-0329.mediawiki|329]]\n| Applications\n| Wallet Labels Export Format\n| Craig Raw\n| Informational\n| Draft\n|-\n| [[bip-0330.mediawiki|330]]\n| Peer Services\n| Transaction announcements reconciliation\n| Gleb Naumenko, Pieter Wuille\n| Specification\n| Draft\n|-\n| [[bip-0331.mediawiki|331]]\n| Peer Services\n| Ancestor Package Relay\n| Gloria Zhao\n| Specification\n| Draft\n|-\n| [[bip-0332.md|332]]\n| Peer Services\n| Stale Tip Relay\n| Anthony Towns, w0xlt, Ram\n| Specification\n| Draft\n|-\n| [[bip-0337.mediawiki|337]]\n| API/RPC\n| Compressed Transactions\n| Tom Briar\n| Specification\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0338.mediawiki|338]]\n| Peer Services\n| Disable transaction relay message\n| Suhas Daftuar\n| Specification\n| Closed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0339.mediawiki|339]]\n| Peer Services\n| WTXID-based transaction relay\n| Suhas Daftuar\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0340.mediawiki|340]]\n|\n| Schnorr Signatures for secp256k1\n| Pieter Wuille, Jonas Nick, Tim Ruffing\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0341.mediawiki|341]]\n| Consensus (soft fork)\n| Taproot: SegWit version 1 spending rules\n| Pieter Wuille, Jonas Nick, Anthony Towns\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0342.mediawiki|342]]\n| Consensus (soft fork)\n| Validation of Taproot Scripts\n| Pieter Wuille, Jonas Nick, Anthony Towns\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0343.mediawiki|343]]\n| Consensus (soft fork)\n| Mandatory activation of taproot deployment\n| Shinobius, Michael Folkson\n| Specification\n| Closed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0345.mediawiki|345]]\n| Consensus (soft fork)\n| OP_VAULT\n| James O'Beirne, Greg Sanders\n| Specification\n| Closed\n|-\n| [[bip-0346.md|346]]\n| Consensus (soft fork)\n| OP_TXHASH\n| Steven Roose, Brandon Black\n| Specification\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0347.mediawiki|347]]\n| Consensus (soft fork)\n| OP_CAT in Tapscript\n| Ethan Heilman, Armin Sabouri\n| Specification\n| Complete\n|-\n| [[bip-0348.md|348]]\n| Consensus (soft fork)\n| CHECKSIGFROMSTACK\n| Brandon Black, Jeremy Rubin\n| Specification\n| Draft\n|-\n| [[bip-0349.md|349]]\n| Consensus (soft fork)\n| OP_INTERNALKEY\n| Brandon Black, Jeremy Rubin\n| Specification\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0350.mediawiki|350]]\n| Applications\n| Bech32m format for v1+ witness addresses\n| Pieter Wuille\n| Specification\n| Deployed\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0351.mediawiki|351]]\n| Applications\n| Private Payments\n| Alfred Hodler, Clark Moody\n| Specification\n| Closed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0352.mediawiki|352]]\n| Applications\n| Silent Payments\n| josibake, Ruben Somsen, Sebastian Falbesoner\n| Specification\n| Complete\n|- style=\"background-color: #ffffcf\"\n| [[bip-0353.mediawiki|353]]\n| Applications\n| DNS Payment Instructions\n| Matt Corallo, Bastien Teinturier\n| Specification\n| Complete\n|-\n| [[bip-0360.mediawiki|360]]\n| Consensus (soft fork)\n| Pay-to-Merkle-Root (P2MR)\n| Hunter Beast, Ethan Heilman, Isabel Foxen Duke\n| Specification\n| Draft\n|-\n| [[bip-0361.mediawiki|361]]\n| Consensus (soft fork)\n| Post Quantum Migration and Legacy Signature Sunset\n| Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers\n| Informational\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0370.mediawiki|370]]\n| Applications\n| PSBT Version 2\n| Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0371.mediawiki|371]]\n| Applications\n| Taproot Fields for PSBT\n| Ava Chow\n| Specification\n| Deployed\n|-\n| [[bip-0372.mediawiki|372]]\n| Applications\n| Pay-to-contract tweak fields for PSBT\n| Maxim Orlovsky\n| Specification\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0373.mediawiki|373]]\n| Applications\n| MuSig2 PSBT Fields\n| Ava Chow\n| Specification\n| Complete\n|-\n| [[bip-0374.mediawiki|374]]\n| Applications\n| Discrete Log Equality Proofs\n| Andrew Toth, Ruben Somsen, Sebastian Falbesoner\n| Specification\n| Draft\n|-\n| [[bip-0375.mediawiki|375]]\n| Applications\n| Sending Silent Payments with PSBTs\n| Andrew Toth, Ava Chow, josibake\n| Specification\n| Draft\n|-\n| [[bip-0376.mediawiki|376]]\n| Applications\n| Spending Silent Payment outputs with PSBTs\n| nymius\n| Specification\n| Draft\n|-\n| [[bip-0379.md|379]]\n| Applications\n| Miniscript\n| Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Antoine Poinsot, Ava Chow\n| Specification\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0380.mediawiki|380]]\n| Applications\n| Output Script Descriptors General Operation\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0381.mediawiki|381]]\n| Applications\n| Non-Segwit Output Script Descriptors\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0382.mediawiki|382]]\n| Applications\n| Segwit Output Script Descriptors\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0383.mediawiki|383]]\n| Applications\n| Multisig Output Script Descriptors\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0384.mediawiki|384]]\n| Applications\n| combo() Output Script Descriptors\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0385.mediawiki|385]]\n| Applications\n| raw() and addr() Output Script Descriptors\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0386.mediawiki|386]]\n| Applications\n| tr() Output Script Descriptors\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #cfffcf\"\n| [[bip-0387.mediawiki|387]]\n| Applications\n| Tapscript Multisig Output Script Descriptors\n| Pieter Wuille, Ava Chow\n| Specification\n| Deployed\n|- style=\"background-color: #ffffcf\"\n| [[bip-0388.mediawiki|388]]\n| Applications\n| Wallet Policies for Descriptor Wallets\n| Salvatore Ingala\n| Specification\n| Complete\n|-\n| [[bip-0389.mediawiki|389]]\n| Applications\n| Multipath Descriptor Key Expressions\n| Ava Chow\n| Specification\n| Draft\n|-\n| [[bip-0390.mediawiki|390]]\n| Applications\n| musig() Descriptor Key Expression\n| Ava Chow\n| Specification\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0391.mediawiki|391]]\n| Applications\n| Binary Output Descriptors\n| SeedHammer\n| Specification\n| Closed\n|-\n| [[bip-0392.mediawiki|392]]\n| Applications\n| Silent Payment Output Script Descriptors\n| Craig Raw\n| Specification\n| Draft\n|-\n| [[bip-0393.mediawiki|393]]\n| Applications\n| Output Script Descriptor Annotations\n| Craig Raw\n| Specification\n| Draft\n|-\n| [[bip-0431.mediawiki|431]]\n| Applications\n| Topology Restrictions for Pinning\n| Gloria Zhao\n| Informational\n| Draft\n|-\n| [[bip-0433.mediawiki|433]]\n| Applications\n| Pay to Anchor (P2A)\n| Gregory Sanders\n| Informational\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0434.md|434]]\n| Peer Services\n| Peer Feature Negotiation\n| Anthony Towns\n| Specification\n| Complete\n|-\n| [[bip-0440.mediawiki|440]]\n| Consensus (soft fork)\n| Varops Budget For Script Runtime Constraint\n| Rusty Russell, Julian Moik\n| Specification\n| Draft\n|-\n| [[bip-0441.mediawiki|441]]\n| Consensus (soft fork)\n| Restoration of disabled script (Tapleaf 0xC2)\n| Rusty Russell, Julian Moik\n| Specification\n| Draft\n|-\n| [[bip-0442.md|442]]\n| Consensus (soft fork)\n| OP_PAIRCOMMIT\n| moonsettler, Brandon Black\n| Specification\n| Draft\n|-\n| [[bip-0443.mediawiki|443]]\n| Consensus (soft fork)\n| OP_CHECKCONTRACTVERIFY\n| Salvatore Ingala\n| Specification\n| Draft\n|-\n| [[bip-0446.md|446]]\n| Consensus (soft fork)\n| OP_TEMPLATEHASH\n| Gregory Sanders, Antoine Poinsot, Steven Roose\n| Specification\n| Draft\n|-\n| [[bip-0448.md|448]]\n| Consensus (soft fork)\n| Taproot-native (Re)bindable Transactions\n| Gregory Sanders, Antoine Poinsot, Steven Roose\n| Specification\n| Draft\n|-\n| [[bip-0449.md|449]]\n| Consensus (soft fork)\n| OP_TWEAKADD - x-only key tweak addition\n| Jeremy Rubin\n| Specification\n| Draft\n|-\n| [[bip-0450.mediawiki|450]]\n| Applications\n| FormosaâSeed encoding by themed mnemonic stories\n| Yuri S Villas Boas, AndrĂ© Fidencio Gonçalves\n| Specification\n| Draft\n|-\n| [[bip-0451.md|451]]\n| Applications\n| Dust UTXO Disposal Protocol\n| bubb1es, haris\n| Specification\n| Draft\n|-\n| [[bip-0461.md|461]]\n| Applications\n| Deterministic ECDSA Signatures\n| Liam Gilligan\n| Specification\n| Draft\n|}\n"}
{"url":"https://docs.marinade.finance/","domain":"docs.marinade.finance","title":"Welcome to Marinade | Marinade Documentation","hash":"1f83a138e28b993919631920ed0a6102261dec8bb09569db3093a2c4ec2e9abe","tokens":778,"chars":3112,"crawler":"crawler-dfxz","verified":"exact","ts":1791112026649,"text":"Marinade Documentation\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nđ Welcome to Marinade\nThe best place to stake your SOL.\nWhat is Marinade?\nMarinade is a stake automation platform that helps you maximize SOL staking rewards while supporting the decentralization and performance of the Solana network. It continuously monitors the validator landscape and delegates your stake across a carefully selected set of high-performance validators using an open, transparent strategy.\nUsers can stake their SOL either natively or through liquid staking for mSOL, a tokenized version of staked SOL. Both methods use the same validator delegation logic and receive rewards every epoch (approximately 2 days).\nCreation of Marinade\nMarinade was born out of the merger of two projects trying to accomplish a similar goal: offer a liquid staking solution on Solana that participates to the decentralization of the network and its security.\nThe teams joined forces to work more efficiently towards making this idea a reality. Marinade formed around a set of values and a common objective and started building.\nGoals\nSpread adoption\nTo onboard the next 1 billion people to crypto, we believe that the user experience must dramatically evolve and adapt to the needs of more users.\nWhile early adopters donât care about writing down seeds and pin codes for multiple wallets, storing it around their house, or burying it in the ground, we canât imagine a world where this is still a standard after 5, 10, or 20 years.\nThatâs why we emphasize having our solution well-designed, seamless, and a pleasure to use, so that a friend can tell a friend that staking is as easy as clicking a button.\nWhat are the benefits of staking SOL?\nBlockchains use consensus protocols to validate transactions in a secure and decentralized way. Solana relies on a proof-of-stake mechanism, where staking plays a key role in maintaining the networkâs security and performance.\nWhen you stake your SOL tokens to a validator, you contribute to the decentralization and efficiency of the Solana blockchain. In return, you receive rewards in SOL for each epoch, which lasts approximately 2 to 3 days, depending on the validatorâs performance.\nStaking is important for the health of the network. The more SOL that is staked to efficient validators, the more decentralized and secure the system becomes. However, with the growing number of DeFi use cases, a significant amount of SOL remains unstaked and is actively used in decentralized applications across the ecosystem.\nWhat can you do with Marinade?\n-\nStake and unstake SOL at any time\n-\nUse mSOL in DeFi protocols to multiply yield strategies\n-\nRedelegate existing stake without unstaking\n-\nConvert staked SOL into mSOL to make it liquid\n-\nParticipate in Marinade DAO governance and shape the future of staking on Solana\nNext Marinade DAO\nLast updated 5 months ago\nWas this helpful?\n- What is Marinade?\n- Creation of Marinade\n- Goals\n- Spread adoption\n- What are the benefits of staking SOL?\n- What can you do with Marinade?\nWas this helpful?"}
{"url":"https://docs.curve.finance/","domain":"docs.curve.finance","title":"Curve Knowledge Hub","hash":"7a573b34a503a60f387bf300d2520913de7e5e331fa4a62fa416e496c836a02f","tokens":136,"chars":543,"crawler":"hive-genesis","verified":"exact","ts":1791112026437,"text":"Skip to main content\nCurve Knowledge Hub\nUsers\nSwap and provide liquidity on the Curve DEX, borrow and lend with Llamalend, and participate in governance with veCRV and voting rights.\nLearn more â\nDevelopers\nTechnical documentation for developers building integrations, understanding smart contracts, and working with Curve APIs.\nLearn more â\nBuild on Curve\nResources for protocols and projects looking to integrate with Curve, understand the ecosystem, and leverage Curve infrastructure.\nLearn more â\nINTERESTING READS\nLoading latest posts..."}
{"url":"https://docs.polkadot.com/apps/product-sdk/contracts/","domain":"docs.polkadot.com","title":"Contracts | Polkadot Developer Docs","hash":"8e774f7a30fc2f75e2b204df7707950414b98096e784a72509b3a808e3052913","tokens":1327,"chars":5306,"crawler":"hive-genesis","verified":"unchecked","ts":1791112028326,"text":"Skip to content\nInitializing search\n- Concepts\n- Build\n- Deploy Your App\n- Register a .dot Domain\n- List Your App\n- Product SDK\n- Keys\n- Individuality\n- Host\n- Terminal\n- Auth\n- Tutorials\n- Troubleshooting\n- Smart Contracts\n- Cookbook\n- Deploy an ERC-20\n- Deploy an NFT\n- Create a DApp\n- Port Ethereum DApps\n- Uniswap V3\n- Precompiles\n- Development Environments\n- Libraries\n- Integrations\n- Parachains\n- Customize Your Runtime\n- Test Your Runtime\n- Maintain and Upgrade Your Parachain\n- Enable Interoperability\n- Integrations\n- Chain Interactions\n- Send Transactions\n- Manage Tokens\n- Store Data\n- Manage Accounts\n- Node Infrastructure\n- Parachain RPC Node\n- Run a Validator\n- Operational Tasks\n- Staking Mechanics\n- Run a Collator\n- Tech Reference\n- Asset Management\n- Bridging\n- People and Identity\n- Collectives and DAOs\n- Data Storage\n- Parachains\n- Accounts\n- Blocks, Transactions, and Fees\n- Node and Runtime\n- Interoperability\n- Randomness\n- Cryptography\n- Data Encoding\n- Chain Data\n- Networks\n- On-Chain Governance\n- App Development\n- Polkadot Desktop\n- Polkadot Web\n- Protocol\n- Infrastructure\n- Statement Store\n- dotNS\n- Proof of Personhood\n- HOP\n- Skills\n- Glossary\n- Tools\n- AI Resources\n- Support\n- Policies\nPage actions\nEdit this page Report an issue\nContracts ¶\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nIntroduction ¶\n@parity/product-sdk-contracts gives your Product typed access to smart contracts deployed on Asset Hub . It calls pallet-revive (PolkaVM) contracts through the typed chain API, resolves each contract's address and ABI from a cdm.json manifest, and exposes reads, signed writes, and atomic batches on a typed handle.\nIt is the frontend counterpart to deploying a contract: once a contract is deployed and registered, this package turns its manifest entry into a typed object you call by name.\nWhen to Use It ¶\n- To call a contract deployed on Asset Hub: reads with query , signed writes with tx , or atomic multi-call batches with prepare .\n- When you have a cdm.json manifest (address and ABI per installed contract), which is the primary path via ContractManager.fromClient .\n- Not for deploying contracts; deployment is handled by the cdm toolchain, covered in Add a Smart Contract to Your Product . The target chain must expose the Revive pallet.\nCore Concepts ¶\n- ContractManager : Resolves contracts from a cdm.json manifest. fromClient(...) is synchronous and uses the addresses snapshotted in the manifest; getContract(name) returns a typed handle and throws ContractNotFoundError if the name is not in the manifest.\n- Contract handle : Each ABI method exposes query , tx , and prepare .\n- query returns a discriminated result : A read is a dry run that returns { success, value, gasRequired } . It does not throw on a revert, so branch on .success rather than using try / catch .\n- tx returns a Result : A signed write returns a Result (check .ok ). Before signing, it dry-runs the call to size gas and fail fast on a revert.\n- Account mapping : pallet-revive requires each signing account to be mapped to its H160 address once. Call ensureContractAccountMapped at startup, or every tx on a fresh account fails with AccountNotMapped .\n- Product-account signing : Writes are signed by your Product-scoped account, so contract calls route to the user's phone for approval like any other transaction.\nCall a Contract ¶\nBuild a manager from the manifest and the chain client, map the account once, then read and write:\nimport {\nContractManager ,\nensureContractAccountMapped ,\n} from '@parity/product-sdk-contracts' ;\nimport { paseo_asset_hub } from '@parity/product-sdk-descriptors/paseo-asset-hub' ;\nimport cdmJson from './cdm.json' ;\nconst manager = ContractManager . fromClient (\ncdmJson ,\nchain . raw . assetHub ,\npaseo_asset_hub ,\n{ signerManager },\n);\nawait ensureContractAccountMapped ( manager . getRuntime (), account . address , signer );\nconst counter = manager . getContract ( '@my-app/counter' );\n// Read: a dry run. Check .success, not .ok.\nconst count = await counter . getCount . query ();\nif ( count . success ) console . log ( count . value );\n// Write: signs through the Host. Check .ok.\nconst result = await counter . increment . tx ({ signer });\nif ( ! result . ok ) console . error ( result . error . message );\nLimitations ¶\n- query never throws on a chain-side failure; it returns { success: false, value: } , so branch on .success .\n- A fresh signing account fails every tx with AccountNotMapped until ensureContractAccountMapped runs once.\n- Passing both gasLimit and storageDepositLimit skips the dry-run, including the revert pre-check, so a reverting transaction is still submitted and its gas paid.\n- The /codegen and /pvm subpaths pull in Node-only modules; keep them out of browser bundles.\nWhere to Go Next ¶\n-\nGuide Add a Smart Contract to Your Product\nThe task-focused recipe: scaffold, deploy, and register a contract, then wire it into your frontend.\nAdd a Smart Contract to Your Product\n-\nLearn Transactions\nThe submission layer this package builds on for its signed writes and batches.\nTransactions\n-\nExternal API Reference\nThe complete contracts surface: ContractManager , contract handles, and the pvm subpath.\nVisit Site\nLast update: September 2, 2026\n| Created: September 2, 2026"}
{"url":"https://developer.bitcoin.org/devguide/","domain":"developer.bitcoin.org","title":"Developer Guides â Bitcoin","hash":"9badf1b848cd9abd472d87018cdc87694565a108b39134bf78fbdba9d455c993","tokens":204,"chars":813,"crawler":"crawler-dfxz","verified":"exact","ts":1791112028217,"text":"-\nBitcoin\n- Developer Guides\n« Getting Started\nBlock Chain »\nTable Of Contents\n- Developer Guides\n- Block Chain\n- Transactions\n- Contracts\n- Wallets\n- Payment Processing\n- Operating Modes\n- P2P Network\n- Mining\n- Reference\n- Introduction\n- Block Chain\n- Transactions\n- Wallets\n- P2P Network\n- RPC API Reference\n- Examples\n- Introduction\n- Testing Applications\n- Transactions\n- Payment Processing\n- P2P Network\n- Glossary\nPrevious topic\nGetting Started\nNext topic\nBlock Chain\nContribute\nEdit Page\nDeveloper Guides ¶\nFind detailed information about the Bitcoin protocol and related specifications.\n- Block Chain\n- Transactions\n- Contracts\n- Wallets\n- Payment Processing\n- Operating Modes\n- P2P Network\n- Mining\nĂ\nDonate to Bitcoin.org\nUse this QR code or address below\n3E8ociqZa9mZUSwGdSmAEMAoAxBK3FNDcd"}
{"url":"https://ethereum.org/developers/docs/scaling/","domain":"ethereum.org","title":"Scaling | ethereum.org","hash":"54b661b4755080f687b80b41cfb745ccba31352db14e70e14135037253bab1a1","tokens":2277,"chars":9106,"crawler":"hive-genesis","verified":"unchecked","ts":1791112030129,"text":"Skip to main content\nChange page\nScaling\nEdit page (opens in a new tab)\nScaling overview\nAs the number of people using Ethereum has grown, the blockchain has reached certain capacity limitations. This has driven up the cost of using the network, creating the need for \"scaling solutions.\" There are multiple solutions being researched, tested and implemented that take different approaches to achieve similar goals.\nThe main goal of scalability is to increase transaction speed (faster finality) and transaction throughput (higher number of transactions per second) without sacrificing decentralization or security. On the layer 1 Ethereum blockchain, high demand leads to slower transactions and nonviable gas prices . Increasing the network capacity in terms of speed and throughput is fundamental to the meaningful and mass adoption of Ethereum.\nWhile speed and throughput are important, it is essential that scaling solutions enabling these goals remain decentralized and secure. Keeping the barrier to entry low for node operators is critical in preventing a progression towards centralized and insecure computing power.\nConceptually we first categorize scaling as either onchain scaling or offchain scaling.\nPrerequisites\nYou should have a good understanding of all the foundational topics. Implementing scaling solutions is advanced as the technology is less battle-tested, and continues to be researched and developed.\nOnchain scaling\nOnchain scaling requires changes to the Ethereum protocol (layer 1 ). For a long time, sharding the blockchain was expected to scale Ethereum. This was going to involve splitting the blockchain into discrete pieces (shards) to be verified by subsets of validators. However, scaling by layer-2 rollups has taken over as the primary scaling technique. This is supported by the addition of a new cheaper form of data attached to Ethereum blocks that is specially designed to make rollups cheap for users.\nSharding\nSharding is the process of splitting a database. Subsets of validators would be responsible for individual shards rather than keeping track of all of Ethereum. Sharding was on the Ethereum roadmap for a long time, and was once intended to be shipped before The Merge to proof-of-stake. However, the rapid development of layer 2 rollups and the invention of Danksharding (adding blobs of rollup data to Ethereum blocks that can be very efficiently verified by validators) has led the Ethereum community to favour rollup-centric scaling instead of scaling by sharding. This will also help to keep Ethereum's consensus logic simpler.\nOffchain scaling\nOffchain solutions are implemented separately from layer 1 Mainnet - they require no changes to the existing Ethereum protocol. Some solutions, known as \"layer 2\" solutions, derive their security directly from layer 1 Ethereum consensus, such as optimistic rollups , zero-knowledge rollups or state channels . Other solutions involve the creation of new chains in various forms that derive their security separately from Mainnet, such as sidechains , validiums , or plasma chains . These solutions communicate with Mainnet but derive their security differently to obtain a variety of goals.\nLayer 2 scaling\nThis category of offchain solutions derives its security from Mainnet Ethereum.\nLayer 2 is a collective term for solutions designed to help scale your application by handling transactions off the Ethereum Mainnet (layer 1) while taking advantage of the robust decentralized security model of Mainnet. Transaction speed suffers when the network is busy, making the user experience poor for certain types of dapps. And as the network gets busier, gas prices increase as transaction senders aim to outbid each other. This can make using Ethereum very expensive.\nMost layer 2 solutions are centered around a server or cluster of servers, each of which may be referred to as a node, validator, operator, sequencer, block producer, or similar term. Depending on the implementation, these layer 2 nodes may be run by the individuals, businesses or entities that use them, or by a 3rd party operator, or by a large group of individuals (similar to Mainnet). Generally speaking, transactions are submitted to these layer 2 nodes instead of being submitted directly to layer 1 (Mainnet). For some solutions, the layer 2 instance then batches them into groups before anchoring them to layer 1, after which they are secured by layer 1 and cannot be altered. The details of how this is done vary significantly between different layer 2 technologies and implementations.\nA specific layer 2 instance may be open and shared by many applications, or may be deployed by one project and dedicated to supporting only their application.\nWhy is layer 2 needed?\n- Increased transactions per second greatly improves user experience, and reduces network congestion on Mainnet Ethereum.\n- Transactions are rolled up into a single transaction to Mainnet Ethereum, reducing gas fees for users and making Ethereum more inclusive and accessible for people everywhere.\n- Any updates to scalability should not be at the expense of decentralization or security â layer 2 builds on top of Ethereum.\n- There are application-specific layer 2 networks that bring their own set of efficiencies when working with assets at scale.\nMore on layer 2 .\nRollups\nRollups perform transaction execution outside layer 1 and then the data is posted to layer 1 where consensus is reached. As transaction data is included in layer 1 blocks, this allows rollups to be secured by native Ethereum security.\nThere are two types of rollups with different security models:\n- Optimistic rollups : assumes transactions are valid by default and only runs computation, via a , in the event of a challenge. More on Optimistic rollups .\n- Zero-knowledge rollups : runs computation offchain and submits a to the chain. More on zero-knowledge rollups .\nState channels\nState channels utilize multisig contracts to enable participants to transact quickly and freely offchain, then settle finality with Mainnet. This minimizes network congestion, fees, and delays. The two types of channels are currently state channels and payment channels.\nLearn more about state channels .\nSidechains\nA sidechain is an independent EVM-compatible blockchain that runs in parallel to Mainnet. These are compatible with Ethereum via two-way bridges and run under their own chosen rules of consensus and block parameters.\nLearn more about Sidechains .\nPlasma\nA plasma chain is a separate blockchain that is anchored to the main Ethereum chain and uses fraud proofs (like optimistic rollups ) to arbitrate disputes.\nLearn more about Plasma .\nValidium\nA Validium chain uses validity proofs like zero-knowledge rollups but data is not stored on the main layer 1 Ethereum chain. This can lead to 10k transactions per second per Validium chain and multiple chains can be run in parallel.\nLearn more about Validium .\nWhy are so many scaling solutions needed?\n- Multiple solutions can help reduce the overall congestion on any one part of the network and also prevent single points of failure.\n- The whole is greater than the sum of its parts. Different solutions can exist and work in harmony, allowing for an exponential effect on future transaction speed and throughput.\n- Not all solutions require utilizing the Ethereum consensus algorithm directly, and alternatives can offer benefits that would otherwise be difficult to obtain.\nMore of a visual learner?\nEthereum layer 2 scaling explained\nAn overview of layer 2 scaling solutions for Ethereum, including rollups, Plasma, state channels, and sidechains.\nWatch with transcript\nNote the explanation in the video uses the term \"Layer 2\" to refer to all offchain scaling solutions, while we differentiate \"Layer 2\" as an offchain solution that derives its security through layer 1 Mainnet consensus.\nRollups: the ultimate Ethereum scaling strategy?\nA deep dive into rollups as Ethereum's primary scaling strategy.\nWatch with transcript\nFurther reading\n- A rollup-centric Ethereum roadmap (opens in a new tab) Vitalik Buterin\n- Up-to-date analytics on Layer 2 scaling solutions for Ethereum (opens in a new tab)\n- Evaluating Ethereum layer 2 Scaling Solutions: A Comparison Framework (opens in a new tab)\n- An Incomplete Guide to Rollups (opens in a new tab)\n- Ethereum-powered ZK-Rollups: World Beaters (opens in a new tab)\n- Optimistic Rollups vs ZK Rollups (opens in a new tab)\n- Why rollups + data shards are the only sustainable solution for high scalability (opens in a new tab)\n- What kind of Layer 3s make sense? (opens in a new tab)\n- Data Availability Or: How Rollups Learned To Stop Worrying And Love Ethereum (opens in a new tab)\n- The Practical Guide to Ethereum Rollups (opens in a new tab)\nKnow of a community resource that helped you? Edit this page and add it!\nTutorials: Build scalable Layer 2s on Ethereum\n- All you can cache â How to build and use a caching contract to reduce calldata costs on rollups.\n- Short ABIs for Calldata Optimization â How to use shorter ABIs to reduce calldata costs for layer 2 transactions."}
{"url":"https://docs.polygon.technology/","domain":"docs.polygon.technology","title":"Polygon Developer Docs - Polygon Developer Docs","hash":"d94d66f241e1bfb3aa9370ac9cae79bf8259dee11586dfa78dd6dd71864b842f","tokens":102,"chars":405,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112030243,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPolygon Developer Docs home page\nPlatform\nPayments\nWallets\nCross-chain\nAPI Reference\nInfrastructure\nPolygon Chain\nPolygon CDK\nAgglayer\nAgentic\nAssistant\nResponses are generated using AI and may contain mistakes.\nSuggestions\nContact support"}
{"url":"https://forum.solana.com/latest","domain":"forum.solana.com","title":"Latest topics - Solana Developer Forums","hash":"21b814c5b9ffe5fd0f13590ce1c85b4bb28853a86df878f0501bc918c6973f7a","tokens":733,"chars":2929,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112032131,"text":"Solana Developer Forums\nTopic\nReplies\nViews\nActivity\nhttp://Bets.io withheld $15,148 USDC - how can I trace and recover it?\nUncategorized\nfeature\n1\n73\nSeptember 23, 2026\nTesting Compatibility Across Solana Program Changes\nResearch\ninterfaces\n0\n31\nSeptember 18, 2026\nWhat Can a Landed Solana Transaction Actually Prove About DeFi Execution?\nResearch\nfeature\n0\n127\nAugust 28, 2026\nSIMD-0550: Proposal to Double Disinflation\nGovernance\neconomics\n9\n1972\nAugust 18, 2026\nDecreasing number of validators, centralizing steak, and overall network health / resilience under extreme events\nGovernance\n0\n74\nAugust 12, 2026\nTest Validator Plugin Framework\nRFP\n15\n2172\nJuly 31, 2026\nVOTE! First Governance Advisory Vote by Validators\nGovernance\nvote\n6\n2810\nJuly 30, 2026\nI lost a significant ammout of solona by mistake to offcurve account\nRFP\naccount-resolution\n0\n142\nJuly 4, 2026\nSteak Proposal - A Solana Proposal For Memecoins\nResearch\n0\n388\nJuly 2, 2026\nSIMD-0326: Proposal for the New Alpenglow Consensus Protocol\nGovernance\ncore\n117\n11680\nJune 13, 2026\nSIMD-0411: Proposal for Doubling the Disinflation Rate\nGovernance\neconomics\n1\n3386\nJune 4, 2026\nHelius-stream: a small Rust crate I extracted from a mainnet MEV experiment, sharing for feedback\nRFP\ndev-tooling\n0\n106\nMay 22, 2026\nA Practical Overview of Scheduler Implementations in Solana Validators\nResearch\ncore\n1\n303\nMay 22, 2026\nState of BLS signature verification on Solana\nResearch\n6\n726\nMay 3, 2026\nState of tinydancer / light clients on Solana\nResearch\n0\n81\nMay 3, 2026\nSIMD-0520: On-Chain Agent Identity Standard - request for comments\nSIMD\nsimd\n0\n238\nMay 2, 2026\nProposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet\nGovernance\nfeature\n,\ncore\n25\n5613\nOctober 4, 2025\nProgressive Minimum Commissions\nSIMD\n1\n323\nSeptember 8, 2025\nSRFCs have moved to Github\nsRFC\n0\n243\nAugust 5, 2025\nHas the problem described in this paper \"Halting the Solana Blockchain with Epsilon Stake\" been mitigated?\nResearch\ncore\n1\n422\nJuly 31, 2025\nsRFC 37: Efficient Block/Allow List Token Standard\nsRFC\naccount-resolution\n,\ninterfaces\n4\n1391\nJune 30, 2025\nSolana Request for Comments Info READ FIRST\nsRFC\n2\n1448\nApril 22, 2025\nsRFC 30: Account Abstraction Interfaces\nsRFC\ninterfaces\n1\n521\nApril 16, 2025\nsRFC 00002: Off-Chain Instruction Account Resolution\nsRFC\naccount-resolution\n,\ninterfaces\n,\nspl\n,\nanchor\n4\n1057\nApril 16, 2025\nsRFC-35 - Address/Domain Association Specification\nsRFC\n19\n1236\nApril 16, 2025\nAligning the \"What\" of Governance with the Existing SIMD Process\nGovernance\n1\n1085\nApril 16, 2025\nWho votes - three proposals\nGovernance\n24\n2936\nApril 16, 2025\nFeedback on the SIMD-123 and SIMD-228 governance process\nGovernance\n2\n983\nApril 16, 2025\nA Framework for Governance - Introduction\nGovernance\n3\n2612\nApril 16, 2025\nsRFC 36 - Typed Message Payload Rendering in Wallets\nsRFC\ninterfaces\n,\nfeature\n,\ncryptography\n1\n384\nApril 16, 2025\nnext page â\nDiscourse Footer"}
{"url":"https://docs.meteora.ag/get-started","domain":"docs.meteora.ag","title":"We Build Liquidity Pools - Meteora Documentation","hash":"37bd58f29367e77bd7d39bd842b7862cda1651c27405da0eaac314de1c663848","tokens":1346,"chars":5381,"crawler":"hive-genesis","verified":"exact","ts":1791112033699,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nMeteora Documentation home page\nGet Started\nInvent\nAgents\nProtocol\nResources\nWe Build Liquidity Pools\nThe Most Composable Liquidity Layer for Liquidity Providers, Launchpads and Token Launches on Solana.\nWhy Meteora?\nMeteora is the dynamic liquidity infrastructure powering Solanaâs most successful token launches and biggest LP community. Whether youâre an LP maximizing returns, a launchpad delivering deep day-one liquidity, a team launching a token, or a builder integrating liquidity primitives, Meteora gives you the tools to ship fast with unmatched capital efficiency.\nThe same battle-tested infrastructure powering Meteoraâs DLMM, DAMM, and Dynamic Bonding Curve pools is available to you through robust TypeScript and Rust SDKs, as well as free public REST APIs. We handle the complex math, so you can focus on building your product, with world-class support from the Meteora team that wants you to win.\nBuilt for Liquidity Providers\nEarn fees and rewards across Solanaâs largest, most active LP community.\nBuilt for Launchpads\nPower day-one liquidity for every project you launch with battle-tested pools.\nBuilt for Token Launches\nBring your token to market with deep, reliable liquidity from block one.\nProducts\nCore Products\nWhat is DLMM?\nConcentrated liquidity in discrete price bins with dynamic, volatility-aware fees, zero-slippage swaps within a bin and native onchain limit orders.\nWhat is DAMM v2?\nConstant-product AMM with position NFTs, optional concentrated ranges, and built-in anti-sniper suite.\nWhat is Dynamic Bonding Curve?\nFully customizable bonding curves for token launches that auto-graduate to a DAMM pool once the quote threshold is hit.\nHelper Products\nWhat is Presale Vault?\nRun token presales with whitelists, tiers, and contributions in any SPL token.\nWhat is Alpha Vault?\nEarly-access launch vault that lets genuine supporters buy in before public trading opens.\nWhat is Dynamic Fee Sharing?\nAutomatically split pool fees across multiple recipients by configurable share allocations.\nWhat is Zap?\nConvert tokens and manage positions in a single transaction with the ability to zap in or zap out instantly.\nLegacy Products\nWhat is DAMM v1?\nConstant-product AMM with infinite price range, earning swap fees plus extra yield from lending integrations.\nWhat is Dynamic Vault?\nAuto-rebalances idle LP capital across Solana lending markets to boost yield on DAMM v1 pools.\nWhat is Stake2Earn?\nReward top token stakers with a share of locked LP trading fees from DAMM v1 pools.\nDeveloper Guides\nBuild with DLMM\nBuild with bin-based concentrated liquidity, native limit order and dynamic fees.\nBuild with DAMM v2\nBuild constant-product pools with NFT positions, anti-sniping mechanisms, and multiple fee collection modes support.\nBuild with Dynamic Bonding Curve\nBuild custom token launches with programmable 16-point curve segments that auto-graduate to a DAMM pool.\nBuild with Presale Vault\nBuild presales with fixed-price, FCFS, or prorata modes including tier systems, whitelists, and deposit fees.\nBuild with Alpha Vault\nAdd anti-bot deposit vaults to DLMM, DAMM v1, or DAMM v2 launches with FCFS or prorata modes.\nBuild with Dynamic Fee Sharing\nCreate fee vaults that split collected fees across recipients natively onchain.\nBuild with Zap\nCombine program actions and Jupiter swaps in one transaction across DAMM v2 and DLMM pools.\nBuild with DAMM v1\nBuild with the legacy infinite-range AMM that contains integrated lending yield.\nBuild with Dynamic Vault\nIntegrate auto-rebalancing yield vaults powered by the Hermes yield aggregation engine.\nBuild with Stake2Earn\nDistribute trading fees from locked liquidity to top token stakers.\nAgents\nMeteora is built for AI agents and LLM-powered development. Drop these tools into your stack to ship integrations faster.\nMeteora CLI\nManage pools and run swaps from the terminal â JSON-native and agent-ready.\nAgent Skills\nDrop-in skill files that teach coding agents how to integrate Meteora correctly.\nDocumentation MCP\nSearch and query Meteora docs from any MCP-compatible AI editor.\nllms.txt\nLLM-optimized documentation index for RAG pipelines and AI agents.\nInvent on Meteora\nWe abstract the need for understanding Meteora integration complexities by providing an all-in-one interface that any developer can use to create, enter commands and deploy liquidity pools on Solana.\nDLMM\nSpin up a concentrated liquidity pool, with optional Alpha Vault for anti-bot protection.\nDAMM v2\nSpin up a balanced or one-sided pool with optional Alpha Vault and onchain anti-sniping mechanisms.\nDAMM v1\nSpin up a freshly minted DAMM v1 pool with optional Alpha Vault.\nDynamic Bonding Curve\nSpin up a fully customizable bonding curve that auto-graduates to a DAMM pool.\nCommunity\nDiscord\nGet developer support and chat with the Meteora community.\nLP Army\nJoin Solanaâs largest LP community and learn winning strategies from active LPs.\nDeveloper Updates\nReal-time program updates and product releases on Telegram.\nSocials\nBlog\nProduct updates, technical deep dives, and launch information.\nTwitter / X\nReal-time announcements, ecosystem news, and releases.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.morpho.org/get-started/","domain":"docs.morpho.org","title":"Get Started","hash":"a44a7f095414960964fd604f961974b0eef1d89f64bc6e02cb7072054e0c5708","tokens":680,"chars":2717,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112033689,"text":"# Get Started\nSource: https://docs.morpho.org/get-started\n{/* Main container with 20px top margin */}\n\n{/* Docs introduction */}\n\nMorpho Docs\n \n\n\n{/* MCP */}\n \n \n{/* Use cases */}\n\n\n{/* For app builders */}\n\n\nIntegrate Earn\n \n\nIntegrate Borrow\n \n \n{/* For vault curators */}\n\n\nCreate a vault\n \n\nSetup vault roles\n \n \n{/* For protocol developers */}\n\n\nExplore contracts\n \n \n \n \n{/* Integration methods */}\n\n\n{/* API */}\n\n \n{/* Typescript SDK */}\n\n \n \n \n "}
{"url":"https://raw.githubusercontent.com/solana-labs/solana-program-library/master/README.md","domain":"raw.githubusercontent.com","title":"PLEASE READ: This repo no longer contains the SPL program implementations","hash":"3644862fe3d400441a648ea59d6e6f1c65b83c575f4c1a9c6ccb0710f62a118a","tokens":5278,"chars":21110,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112035418,"text":"# PLEASE READ: This repo no longer contains the SPL program implementations\nThis repo still exists in archived form, feel free to fork any reference\nimplementations it still contains.\n## Migrated Packages\nThe Solana Program Library repository has been broken up into separate repos for\neach program and set of clients, under the\n[solana-program organization](https://github.com/solana-program).\nThe following programs have been moved:\n* [Associated-Token-Account](https://github.com/solana-program/associated-token-account)\n* [Feature Proposal](https://github.com/solana-program/feature-proposal)\n* [Instruction Padding](https://github.com/solana-program/instruction-padding)\n* [Libraries](https://github.com/solana-program/libraries)\n* [Memo](https://github.com/solana-program/memo)\n* [Record](https://github.com/solana-program/record)\n* [Single Pool](https://github.com/solana-program/single-pool)\n* [Slashing](https://github.com/solana-program/slashing)\n* [Stake Pool](https://github.com/solana-program/stake-pool)\n* [Token](https://github.com/solana-program/token)\n* [Token-2022](https://github.com/solana-program/token-2022)\n* [Token-Group](https://github.com/solana-program/token-group)\n* [Token-Metadata](https://github.com/solana-program/token-metadata)\n* [Token-2022 Transfer Hook](https://github.com/solana-program/transfer-hook)\nThe governance programs have been moved to https://github.com/Mythic-Project/solana-program-library/tree/master/governance\n# Solana Program Library\nThe Solana Program Library (SPL) is a collection of on-chain programs targeting\nthe [Sealevel parallel\nruntime](https://medium.com/solana-labs/sealevel-parallel-processing-thousands-of-smart-contracts-d814b378192).\nThese programs are tested against Solana's implementation of Sealevel,\nsolana-runtime, and some are deployed to Mainnet Beta. As others implement\nSealevel, we will graciously accept patches to ensure the programs here are\nportable across all implementations.\nFor more information see the [SPL documentation](https://spl.solana.com) and the [Token TypeDocs](https://solana-labs.github.io/solana-program-library/token/js/).\n## Deployments\nOnly a subset of programs within the Solana Program Library repo are deployed to\nthe Solana Mainnet Beta. Currently, this includes:\n| Program | Version |\n| --- | --- |\n| [token](https://github.com/solana-program/token/tree/main/program) | [3.4.0](https://github.com/solana-labs/solana-program-library/releases/tag/token-v3.4.0) |\n| [associated-token-account](https://github.com/solana-program/associated-token-account/tree/main/program) | [1.1.0](https://github.com/solana-labs/solana-program-library/releases/tag/associated-token-account-v1.1.0) |\n| [token-2022](https://github.com/solana-program/token-2022/tree/main/program) | [1.0.0](https://github.com/solana-labs/solana-program-library/releases/tag/token-2022-v1.0.0) |\n| [governance](https://github.com/solana-labs/solana-program-library/tree/master/governance/program) | [3.1.0](https://github.com/solana-labs/solana-program-library/releases/tag/governance-v3.1.0) |\n| [stake-pool](https://github.com/solana-program/stake-pool/tree/main/program) | [1.0.0](https://github.com/solana-labs/solana-program-library/releases/tag/stake-pool-v1.0.0) |\n| [account-compression](https://github.com/solana-labs/solana-program-library/tree/master/account-compression/programs/account-compression) | [0.1.3](https://github.com/solana-labs/solana-program-library/releases/tag/account-compression-v0.1.3) |\n| [shared-memory](https://github.com/solana-labs/solana-program-library/tree/master/shared-memory/program) | [1.0.0](https://github.com/solana-labs/solana-program-library/commit/b40e0dd3fd6c0e509dc1e8dd3da0a6d609035bbd) |\n| [feature-proposal](https://github.com/solana-program/feature-proposal/tree/main/program) | [1.0.0](https://github.com/solana-labs/solana-program-library/releases/tag/feature-proposal-v1.0.0) |\n| [name-service](https://github.com/solana-labs/solana-program-library/tree/master/name-service/program) | [0.3.0](https://github.com/solana-labs/solana-program-library/releases/tag/name-service-v0.3.0) |\n| [memo](https://github.com/solana-program/memo/tree/main/program) | [3.0.0](https://github.com/solana-labs/solana-program-library/releases/tag/memo-v3.0.0) |\n| [single-pool](https://github.com/solana-program/single-pool/tree/main/program) | [1.0.1](https://github.com/solana-labs/solana-program-library/releases/tag/single-pool-v1.0.1) |\n## Audits\nOnly a subset of programs within the Solana Program Library repo are audited. Currently, this includes:\n| Program | Last Audit Date | Version |\n| --- | --- | --- |\n| [token](https://github.com/solana-program/token) | 2022-08-04 (Peer review) | [4fadd55](https://github.com/solana-labs/solana-program-library/commit/4fadd553e1c549afd1d62aeb5ffa7ef31d1999d1) |\n| [associated-token-account](https://github.com/solana-program/associated-token-account) | 2022-08-04 (Peer review) | [c00194d](https://github.com/solana-labs/solana-program-library/commit/c00194d2257302f028f44a403c6dee95c0f9c3bc) |\n| [token-2022](https://github.com/solana-program/token-2022) | [2023-11-03](https://github.com/solana-labs/security-audits/blob/master/spl/OtterSecToken2022Audit-2023-11-03.pdf) | [e924132](https://github.com/solana-labs/solana-program-library/tree/e924132d65ba0896249fb4983f6f97caff15721a) |\n| [stake-pool](https://github.com/solana-program/stake-pool) | [2023-12-31](https://github.com/solana-labs/security-audits/blob/master/spl/HalbornStakePoolAudit-2023-12-31.pdf) | [a17fffe](https://github.com/solana-labs/solana-program-library/commit/a17fffe70d6cc13742abfbc4a4a375b087580bc1) |\n| [account-compression](https://github.com/solana-labs/solana-program-library/tree/master/account-compression/programs/account-compression) | [2022-12-05](https://github.com/solana-labs/security-audits/blob/master/spl/OtterSecAccountCompressionAudit-2022-12-03.pdf) | [6e81794](https://github.com/solana-labs/solana-program-library/commit/6e81794) |\n| [shared-memory](https://github.com/solana-labs/solana-program-library/tree/master/shared-memory/program) | [2021-02-25](https://github.com/solana-labs/security-audits/blob/master/spl/KudelskiTokenSwapSharedMemAudit-2021-02-25.pdf) | [b40e0dd](https://github.com/solana-labs/solana-program-library/commit/b40e0dd3fd6c0e509dc1e8dd3da0a6d609035bbd) |\n| [single-pool](https://github.com/solana-program/single-pool) | [2024-01-02](https://github.com/solana-labs/security-audits/blob/master/spl/ZellicSinglePoolAudit-2024-01-02.pdf) | [ef44df9](https://github.com/solana-labs/solana-program-library/commit/ef44df985e76a697ee9a8aabb3a223610e4cf1dc) |\nAll other programs may be updated from time to time. These programs are not\naudited, so fork and deploy them at your own risk. Here is the full list of\nunaudited programs:\n* [binary-option](https://github.com/solana-labs/solana-program-library/tree/master/binary-option/program)\n* [binary-oracle-pair](https://github.com/solana-labs/solana-program-library/tree/master/binary-oracle-pair/program)\n* [feature-proposal](https://github.com/solana-program/feature-proposal)\n* [instruction-padding](https://github.com/solana-program/instruction-padding)\n* [managed-token](https://github.com/solana-labs/solana-program-library/tree/master/managed-token/program)\n* [name-service](https://github.com/solana-labs/solana-program-library/tree/master/name-service/program)\n* [record](https://github.com/solana-program/record)\n* [stateless-asks](https://github.com/solana-labs/solana-program-library/tree/master/stateless-asks/program)\n* [token-lending](https://github.com/solana-labs/solana-program-library/tree/master/token-lending/program)\n* [token-swap](https://github.com/solana-labs/solana-program-library/tree/master/token-swap/program)\n* [token-upgrade](https://github.com/solana-labs/solana-program-library/tree/master/token-upgrade/program)\nMore information about the repository's security policy at\n[SECURITY.md](https://github.com/solana-labs/solana-program-library/tree/master/SECURITY.md).\nThe [security-audits repo](https://github.com/solana-labs/security-audits) contains\nall past and present program audits.\n## Program Packages\n| Package | Description | Version | Docs |\n| :-- | :-- | :--| :-- |\n| `spl-token` | ERC20-like token program on Solana | [](https://crates.io/crates/spl-token) | [](https://docs.rs/spl-token) |\n| `spl-token-2022` | Token program compatible with `spl-token`, with extensions | [](https://crates.io/crates/spl-token-2022) | [](https://docs.rs/spl-token-2022) |\n| `spl-associated-token-account` | Stateless protocol defining a canonical \"associated\" token account for a wallet | [](https://crates.io/crates/spl-associated-token-account) | [](https://docs.rs/spl-associated-token-account) |\n| `spl-governance` | DAO program using tokens for voting | [](https://crates.io/crates/spl-governance) | [](https://docs.rs/spl-governance) |\n| `spl-account-compression` | Program for managing compressed accounts stored in an off-chain merkle tree | [](https://crates.io/crates/spl-account-compression) | [](https://docs.rs/spl-account-compression) |\n| `spl-feature-proposal` | Program using tokens to vote on enabling Solana network features | [](https://crates.io/crates/spl-feature-proposal) | [](https://docs.rs/spl-feature-proposal) |\n| `spl-noop` | Program that does nothing, used for logging instruction data | [](https://crates.io/crates/spl-noop) | [](https://docs.rs/spl-noop) |\n| `spl-name-service` | Program for managing ownership of data on-chain | [](https://crates.io/crates/spl-name-service) | [](https://docs.rs/spl-name-service) |\n| `spl-shared-memory` | Program for sharing data between programs | [](https://crates.io/crates/spl-shared-memory) | [](https://docs.rs/spl-shared-memory) |\n| `spl-stake-pool` | Program for pooling stake accounts, managed by another entity | [](https://crates.io/crates/spl-stake-pool) | [](https://docs.rs/spl-stake-pool) |\n| `spl-instruction-padding` | Program to padding to other instructions | [](https://crates.io/crates/spl-instruction-padding) | [](https://docs.rs/spl-instruction-padding) |\n| `spl-concurrent-merkle-tree` | Library for on-chain representation of merkle tree | [](https://crates.io/crates/spl-concurrent-merkle-tree) | [](https://docs.rs/spl-concurrent-merkle-tree) |\n| `spl-math` | Library for on-chain math | [](https://crates.io/crates/spl-math) | [](https://docs.rs/spl-math) |\n| `spl-token-lending` | Over-collateralized lending program for tokens | [](https://crates.io/crates/spl-token-lending) | [](https://docs.rs/spl-token-lending) |\n| `spl-token-swap` | AMM for trading tokens | [](https://crates.io/crates/spl-token-swap) | [](https://docs.rs/spl-token-swap) |\n| `spl-token-upgrade` | Protocol for burning one token type in exchange for another | [](https://crates.io/crates/spl-token-upgrade) | [](https://docs.rs/spl-token-upgrade) |\n## CLI Packages\n| Package | Description | Version |\n| :-- | :-- | :--|\n| `spl-token-cli` | CLI for the token, token-2022, and associated-token-account programs | [](https://crates.io/crates/spl-token-cli) |\n| `spl-stake-pool-cli` | CLI for the stake-pool program | [](https://crates.io/crates/spl-stake-pool-cli) |\n| `spl-feature-proposal-cli` | CLI for the feature-proposal program | [](https://crates.io/crates/spl-feature-proposal-cli) |\n| `spl-token-lending-cli` | CLI for the token-lending program | [](https://crates.io/crates/spl-token-lending-cli) |\n| `spl-token-upgrade-cli` | CLI for the token-upgrade program | [](https://crates.io/crates/spl-token-upgrade-cli) |\n## JavaScript Packages\n| Package | Description | Version | Docs |\n| :-- | :-- | :--| :-- |\n| `@solana/spl-token` | Bindings for the token, token-2022, and associated-token-account programs | [](https://www.npmjs.com/package/@solana/spl-token) | [](https://solana-labs.github.io/solana-program-library/token/js) |\n| `@solana/spl-governance` | Bindings for the governance program | [](https://www.npmjs.com/package/@solana/spl-governance) | N/A |\n| `@solana/spl-account-compression` | Bindings for the account-compression program | [](https://www.npmjs.com/package/@solana/spl-account-compression) | [](https://solana-labs.github.io/solana-program-library/account-compression/sdk/docs) |\n| `@solana/spl-name-service` | Bindings for the name-service program | [](https://www.npmjs.com/package/@solana/spl-name-service) | N/A |\n| `@solana/spl-stake-pool` | Bindings for the stake-pool program | [](https://www.npmjs.com/package/@solana/spl-stake-pool) | N/A |\n| `@solana/spl-token-lending` | Bindings for the token-lending program | [](https://www.npmjs.com/package/@solana/spl-token-lending) | N/A |\n| `@solana/spl-token-swap` | Bindings for the token-swap program | [](https://www.npmjs.com/package/@solana/spl-token-swap) | N/A |\n## Development\n### Environment Setup\n1. Install the latest [Solana tools](https://docs.solana.com/cli/install-solana-cli-tools).\n2. Install the latest [Rust stable](https://rustup.rs/). If you already have Rust, run `rustup update` to get the latest version.\n3. Install the `libudev` development package for your distribution (`libudev-dev` on Debian-derived distros, `libudev-devel` on Redhat-derived).\n### Build\n### Build on-chain programs\n```bash\n# To build all on-chain programs\n$ cargo build-sbf\n# To build a specific on-chain program\n$ cd /program\n$ cargo build-sbf\n```\n### Build clients\n```bash\n# To build all clients\n$ cargo build\n# To build a specific client\n$ cd /cli\n$ cargo build\n```\n### Test\nUnit tests contained within all projects can be run with:\n```bash\n$ cargo test # <-- runs host-based tests\n$ cargo test-sbf # <-- runs BPF program tests\n```\nTo run a specific program's tests, such as SPL Token:\n```bash\n$ cd token/program\n$ cargo test # <-- runs host-based tests\n$ cargo test-sbf # <-- runs BPF program tests\n```\nIntegration testing may be performed via the per-project .js bindings. See the\n[token program's js project](token/js) for an example.\n### Common Issues\nSolutions to a few issues you might run into are mentioned here.\n1. `Failed to open: ../../deploy/spl_.so`\nUpdate your Rust and Cargo to the latest versions and re-run `cargo build-sbf` in the relevant `` directory,\nor run it at the repository root to rebuild all on-chain programs.\n2. [Error while loading shared libraries. (libssl.so.1.1)](https://solana.stackexchange.com/q/3029/36)\nA working solution was mentioned [here](https://solana.stackexchange.com/q/3029/36).\nInstall libssl.\n```bash\nwget http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1l-1ubuntu1.2_amd64.deb\nsudo dpkg -i libssl1.1_1.1.1l-1ubuntu1.2_amd64.deb\n```\n3. CPU or Memory usage at 100%\nThis is to be expected while building some of the programs in this library.\nThe simplest solution is to add the `--jobs 1` flag to the build commands to limit the number of parallel jobs to 1 and check if that fixes the issue. Although this will mean much longer build times.\n### Clippy\n```bash\n$ cargo clippy\n```\n### Coverage\n```bash\n$ ./coverage.sh # Help wanted! Coverage build currently fails on MacOS due to an XCode `grcov` mismatch...\n```\n#### MacOS\nYou may need to pin your grcov version, and then rustup with the apple-darwin nightly toolchain:\n```bash\n$ cargo install grcov --version 0.6.1\n$ rustup toolchain install nightly-x86_64-apple-darwin\n```\n## Release Process\nSPL programs are currently tagged and released manually. Each program is\nversioned independently of the others, with all new development occurring on\nmaster. Once a program is tested and deemed ready for release:\n### Bump Version\n* Increment the version number in the program's Cargo.toml\n* Run `cargo build-sbf ` to build binary. Note the\nlocation of the generated `spl_.so` for attaching to the GitHub\nrelease.\n* Open a PR with these version changes and merge after passing CI.\n### Create GitHub tag\nProgram tags are of the form `-vX.Y.Z`.\nCreate the new tag at the version-bump commit and push to the\nsolana-program-library repository, eg:\n```\n$ git tag token-v1.0.0 b24bfe7\n$ git push upstream --tags\n```\n### Publish GitHub release\n* Go to [GitHub Releases UI](https://github.com/solana-labs/solana-program-library/releases)\n* Click \"Draft new release\", and enter the new tag in the \"Tag version\" box.\n* Title the release \"SPL vX.Y.Z\", complete the description, and attach the `spl_.so` binary\n* Click \"Publish release\"\n### Publish to Crates.io\nNavigate to the program directory and run `cargo package`\nto test the build. Then run `cargo publish`.\n# Disclaimer\nAll claims, content, designs, algorithms, estimates, roadmaps,\nspecifications, and performance measurements described in this project\nare done with the Solana Labs, Inc. (âSLâ) best efforts. It is up to\nthe reader to check and validate their accuracy and truthfulness.\nFurthermore nothing in this project constitutes a solicitation for\ninvestment.\nAny content produced by SL or developer resources that SL provides, are\nfor educational and inspiration purposes only. SL does not encourage,\ninduce or sanction the deployment, integration or use of any such\napplications (including the code comprising the Solana blockchain\nprotocol) in violation of applicable laws or regulations and hereby\nprohibits any such deployment, integration or use. This includes use of\nany such applications by the reader (a) in violation of export control\nor sanctions laws of the United States or any other applicable\njurisdiction, (b) if the reader is located in or ordinarily resident in\na country or territory subject to comprehensive sanctions administered\nby the U.S. Office of Foreign Assets Control (OFAC), or (c) if the\nreader is or is working on behalf of a Specially Designated National\n(SDN) or a person subject to similar blocking or denied party\nprohibitions.\nThe reader should be aware that U.S. export control and sanctions laws\nprohibit U.S. persons (and other persons that are subject to such laws)\nfrom transacting with persons in certain countries and territories or\nthat are on the SDN list. Accordingly, there is a risk to individuals\nthat other persons using any of the code contained in this repo, or a\nderivation thereof, may be sanctioned persons and that transactions with\nsuch persons would be a violation of U.S. export controls and sanctions law."}
{"url":"https://docs.zksync.io/","domain":"docs.zksync.io","title":"ZKsync Docs","hash":"aea0a0c8b4912678d882a6ead390826b9e1db4a9d8937cab6c562eff063f5836","tokens":262,"chars":1047,"crawler":"hive-genesis","verified":"unchecked","ts":1791112035486,"text":"- ZKsync Network\n- ZK Stack\n- ZKsync Protocol\n-\nA network of interoperable chains, secured by ZK.\nExplore comprehensive guides, developer tools, and resources to innovate on ZKsync.\nLaunch Your Chain Build Apps on ZKsync\nLaunch your chain\nZKsync Chains\nLearn about interoperable ZK rollups connected through a shared Ethereum bridge.\nRunning a ZKsync Chain\nGet your first ZKsync chain running locally using ZK Stack CLI.\nPrividiumâą\nPrivate, permissioned ZK-Rollup with Ethereum-anchored security and enterprise-grade privacy.\nBuild on the Elastic Network\nQuickstart\nBuild your first app and deploy it on any chain of the Elastic Network.\nZKsync Chain List\nExplore all the chains on the Elastic Network.\nLocal setup\nLearn about the recommended paths of testing and debugging your projects on ZKsync.\nJoin the Community\nDeveloper Updates\nKeep up to date with the latest from the ZKsync team on X.\nGitHub Discussions\nGet help from the community and contribute to the ZKsync project.\nZKsync Discord\nConnect with devs and ZKsync enthusiasts on Discord."}
{"url":"https://wormhole.com/docs/products/token-transfers/wrapped-token-transfers/tutorials/transfer-workflow/","domain":"wormhole.com","title":"Transfer Tokens via Wrapped Token Transfers (WTT) Tutorial | Wormhole Docs","hash":"7c47f3a875b245a408681585565936477f572bd7281080b35057637b6a1c1bb8","tokens":6907,"chars":27625,"crawler":"hive-genesis","verified":"unchecked","ts":1791112037526,"text":"Skip to content\nInitializing search\n- Configuration\n- Concepts\n- FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\n- Tutorials\n- Token Transfers\n- Run the Native Token Transfer\n- Resources\n- Conclusion\n- Next Steps\n- Create Multichain Tokens\n- Concepts\n- FAQs\n- Reference\n- Portal Bridge\n- Connect\n- Guides\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Settlement\n- FAQs\n- Reference\n- Messaging\n- Interact with Core Contracts\n- Query NTT Data and Transfers\n- Concepts\n- Tutorials\n- Reference\n- Protocol\n- Infrastructure Guides\n- Developer Tools\n- Wormhole CLI\n- Wormholescan Explorer\n- Wormholescan API\n- Reference\n- AI Resources\nPage Actions\nEdit this page\n- Token Transfers\n- Run the Native Token Transfer\n- Resources\n- Conclusion\n- Next Steps\nComplete Token Transfer Workflow ïŒ\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nSource code on GitHub\nThis tutorial guides you through building a cross-chain token transfer application using the Wormhole TypeScript SDK and its Wrapped Token Transfers (WTT) protocol. The WTT protocol enables secure and efficient cross-chain asset transfers across different blockchain networks, allowing users to move tokens seamlessly.\nBy leveraging Wormholeâs WTT, this guide shows you how to build an application that supports multiple transfer types:\n- EVM to EVM (e.g., Ethereum to Avalanche)\n- EVM to non-EVM chains (e.g., Ethereum to Solana)\n- Non-EVM to EVM chains (e.g., Sui to Avalanche)\n- Non-EVM to non-EVM chains (e.g., Solana to Sui)\nExisting solutions for cross-chain transfers can be complex and inefficient, requiring multiple steps and transaction fees. However, the WTT protocol from Wormhole simplifies the process by handling the underlying attestation, transaction validation, and message passing across blockchains.\nAt the end of this guide, youâll have a fully functional setup for transferring assets across chains using Wormholeâs WTT protocol.\nIf your goal is to transfer native USDC between chains that support CCTP, we recommend using the CCTP protocol . WTT is intended for other assets or for USDC on chains where CCTP is not available.\nTerminology\nThe SDK and smart contracts use the name Token Bridge. In documentation, this product is referred to as Wrapped Token Transfers (WTT). Both terms describe the same protocol.\nPrerequisites ïŒ\nBefore you begin, ensure you have the following:\n- Node.js and npm installed on your machine.\n- TypeScript installed globally.\n- Native tokens (testnet or mainnet) in Solana and Sui wallets.\n- A wallet with a private key, funded with native tokens (testnet or mainnet) for gas fees.\n- Sui token compatibility : If you're working with custom Sui tokens, ensure they are created with the legacy CoinMetadata type for WTT. Once created, the token can be migrated to the Currency standard, but the legacy CoinMetadata type must exist initially.\nSupported Chains ïŒ\nThe Wormhole SDK supports a wide range of EVM and non-EVM chains, allowing you to facilitate cross-chain transfers efficiently. You can find a complete list of supported chains on the Supported Networks page, which includes every network where WTT is supported, across both mainnet and testnet.\nProject Setup ïŒ\nIn this section, weâll guide you through initializing the project, installing dependencies, and preparing your environment for cross-chain transfers.\n-\nInitialize the project : Start by creating a new directory for your project and initializing it with npm , which will create the package.json file for your project.\nmkdir native-transfers\ncd native-transfers\nnpm init -y\n-\nInstall dependencies : Install the required dependencies. This tutorial uses the SDK version 4.14.1 :\nnpm install @wormhole-foundation/sdk@4.14.1 tsx\n-\nSet up secure access to your wallets : This guide assumes you are loading your SOL_PRIVATE_KEY , EVM_PRIVATE_KEY and SUI_MNEMONIC from a secure keystore of your choice, such as a secrets manager or a CLI-based tool like cast wallet .\nWarning\nIf you use a .env file during development, add it to your .gitignore to exclude it from version control. Never commit private keys or mnemonics to your repository.\n-\nCreate a helpers.ts file : To simplify the interaction between chains, create a file to store utility functions for fetching your private key, setting up signers for different chains, and managing transaction relays.\n-\nCreate the helpers file.\nmkdir -p src/helpers\ntouch src/helpers/helpers.ts\n-\nOpen the helpers.ts file and add the following code.\nimport {\nChainAddress ,\nChainContext ,\nNetwork ,\nSigner ,\nWormhole ,\nChain ,\nTokenId ,\nisTokenId ,\n} from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport sui from '@wormhole-foundation/sdk/sui' ;\nimport aptos from '@wormhole-foundation/sdk/aptos' ;\nimport { config } from 'dotenv' ;\nconfig ();\nexport interface SignerStuff < N extends Network , C extends Chain > {\nchain : ChainContext < N , C > ;\nsigner : Signer < N , C > ;\naddress : ChainAddress < C > ;\n}\n// Signer setup function for different blockchain platforms\nexport async function getSigner < N extends Network , C extends Chain > (\nchain : ChainContext < N , C > ,\ngasLimit? : bigint\n) : Promise < {\nchain : ChainContext < N , C > ;\nsigner : Signer < N , C > ;\naddress : ChainAddress < C > ;\n} > {\nlet signer : Signer ;\nconst platform = chain . platform . utils (). _platform ;\nswitch ( platform ) {\ncase 'Solana' :\nsigner = await (\nawait solana ()\n). getSigner ( await chain . getRpc (), 'SOL_PRIVATE_KEY' );\nbreak ;\ncase 'Evm' :\nconst evmSignerOptions = gasLimit ? { gasLimit } : {};\nsigner = await (\nawait evm ()\n). getSigner ( await chain . getRpc (), 'ETH_PRIVATE_KEY' , evmSignerOptions );\nbreak ;\ncase 'Sui' :\nsigner = await (\nawait sui ()\n). getSigner ( await chain . getRpc (), 'SUI_MNEMONIC' );\nbreak ;\ncase 'Aptos' :\nsigner = await (\nawait aptos ()\n). getSigner ( await chain . getRpc (), 'APTOS_PRIVATE_KEY' );\nbreak ;\ndefault :\nthrow new Error ( 'Unsupported platform: ' + platform );\n}\nreturn {\nchain ,\nsigner : signer as Signer < N , C > ,\naddress : Wormhole.chainAddress ( chain . chain , signer . address ()),\n};\n}\nexport async function getTokenDecimals <\nN extends 'Mainnet' | 'Testnet' | 'Devnet'\n> (\nwh : Wormhole < N > ,\ntoken : TokenId ,\nsendChain : ChainContext < N , any >\n) : Promise < number > {\nreturn isTokenId ( token )\n? Number ( await wh . getDecimals ( token . chain , token . address ))\n: sendChain . config . nativeTokenDecimals ;\n}\n- getSigner : Based on the chain you're working with (EVM, Solana, Sui, etc.), this function retrieves a signer for that specific platform. The signer is responsible for signing transactions and interacting with the blockchain. It securely uses the private key stored in your .env file.\n- getTokenDecimals : Fetches the number of decimals for a token on a specific chain. It helps handle token amounts accurately during transfers.\nCheck and Create Wrapped Tokens ïŒ\nBefore tokens are transferred across chains, it should be checked whether a wrapped version exists on the destination chain. If not, an attestation must be generated to wrap it so it can be sent and received on that chain.\nIn this section, you'll create a script that automates this process by checking whether Arbitrum Sepolia has a wrapped version on Base Sepolia and registering it if needed.\nConfigure the Wrapped Token Script ïŒ\n-\nCreate the create-wrapped.ts file : Set up the script file that will handle checking and wrapping tokens in the src directory.\nmkdir -p src/scripts\ntouch src/scripts/create-wrapped.ts\n-\nOpen create-wrapped.ts and import the required modules : Import the necessary SDK modules to interact with Wormhole, EVM, Solana, and Sui chains, as well as helper functions for signing and sending transactions.\nimport { Wormhole , signSendWait , wormhole } from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport sui from '@wormhole-foundation/sdk/sui' ;\nimport { inspect } from 'util' ;\nimport { getSigner } from '../helpers/helpers' ;\n-\nInitialize the Wormhole SDK : Initialize the wormhole function for the Testnet environment and specify the platforms (EVM, Solana, and Sui) to support.\n( async function () {\nconst wh = await wormhole ( 'Testnet' , [ evm , solana , sui ]);\nNote\nYou can replace 'Testnet' with 'Mainnet' if you want to perform transfers on mainnet.\n-\nConfigure transfer parameters : Specify Arbitrum Sepolia as the source chain and Base Sepolia as the destination, retrieve the token ID from the source chain for transfer, and set the gas limit (optional).\nconst srcChain = wh . getChain ( 'ArbitrumSepolia' );\nconst destChain = wh . getChain ( 'BaseSepolia' );\nconst token = await srcChain . getNativeWrappedTokenId ();\nconst gasLimit = BigInt ( 2 _500_000 );\n-\nSet up the destination chain signer : The signer authorizes transactions, such as submitting the attestation.\nconst { signer : destSigner } = await getSigner ( destChain , gasLimit );\n-\nCheck if the token is wrapped on the destination chain : Verify if the token already exists as a wrapped asset before creating an attestation.\nconst tbDest = await destChain . getTokenBridge ();\ntry {\nconst wrapped = await tbDest . getWrappedAsset ( token );\nconsole . log (\n`Token already wrapped on ${ destChain . chain } . Skipping attestation.`\n);\nreturn { chain : destChain.chain , address : wrapped };\n} catch ( e ) {\nconsole . log (\n`No wrapped token found on ${ destChain . chain } . Proceeding with attestation.`\n);\n}\nIf the token is already wrapped, the script exits, and you may proceed to the next section . Otherwise, an attestation must be generated.\n-\nSet up the source chain signer : The signer creates and submits the attestation transaction.\nconst { signer : origSigner } = await getSigner ( srcChain );\n-\nCreate an attestation transaction : Generate and send an attestation for the token on the source chain to register it on the destination chain, then save the transaction ID to verify the attestation in the next step.\nconst tbOrig = await srcChain . getTokenBridge ();\nconst attestTxns = tbOrig . createAttestation (\ntoken . address ,\nWormhole . parseAddress ( origSigner . chain (), origSigner . address ())\n);\nconst txids = await signSendWait ( srcChain , attestTxns , origSigner );\nconsole . log ( 'txids: ' , inspect ( txids , { depth : null }));\nconst txid = txids [ 0 ] ! . txid ;\nconsole . log ( 'Created attestation (save this): ' , txid );\n-\nRetrieve the signed VAA : Once the attestation transaction is confirmed, use parseTransaction(txid) to extract Wormhole messages, then retrieve the signed VAA from the messages. The timeout defines how long to wait for the VAA before failure.\nconst msgs = await srcChain . parseTransaction ( txid );\nconsole . log ( 'Parsed Messages:' , msgs );\nconst timeout = 25 * 60 * 1000 ;\nconst vaa = await wh . getVaa ( msgs [ 0 ] ! , 'TokenBridge:AttestMeta' , timeout );\nif ( ! vaa ) {\nthrow new Error (\n'VAA not found after retries exhausted. Try extending the timeout.'\n);\n}\n-\nSubmit the attestation on the destination chain : Submit the signed VAA using submitAttestation(vaa, recipient) to create the wrapped token on the destination chain, then send the transaction and await confirmation.\nconst subAttestation = tbDest . submitAttestation (\nvaa ,\nWormhole . parseAddress ( destSigner . chain (), destSigner . address ())\n);\nconst tsx = await signSendWait ( destChain , subAttestation , destSigner );\n-\nWait for the wrapped asset to be available : Poll until the wrapped token is available on the destination chain.\nasync function waitForIt () {\ndo {\ntry {\nconst wrapped = await tbDest . getWrappedAsset ( token );\nreturn { chain : destChain.chain , address : wrapped };\n} catch ( e ) {\nconsole . error ( 'Wrapped asset not found yet. Retrying...' );\n}\nconsole . log ( 'Waiting before checking again...' );\nawait new Promise (( r ) => setTimeout ( r , 2000 ));\n} while ( true );\n}\nconsole . log ( 'Wrapped Asset: ' , await waitForIt ());\n})(). catch (( e ) => console . error ( e ));\nIf the token is not found, it logs a message and retries after a short delay. Once the wrapped asset is detected, its address is returned.\nComplete script\nimport { Wormhole , signSendWait , wormhole } from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport sui from '@wormhole-foundation/sdk/sui' ;\nimport { inspect } from 'util' ;\nimport { getSigner } from '../helpers/helpers' ;\n( async function () {\nconst wh = await wormhole ( 'Testnet' , [ evm , solana , sui ]);\n// Define the source and destination chains\nconst srcChain = wh . getChain ( 'ArbitrumSepolia' );\nconst destChain = wh . getChain ( 'BaseSepolia' );\nconst token = await srcChain . getNativeWrappedTokenId ();\nconst gasLimit = BigInt ( 2 _500_000 );\n// Destination chain signer setup\nconst { signer : destSigner } = await getSigner ( destChain , gasLimit );\nconst tbDest = await destChain . getTokenBridge ();\ntry {\nconst wrapped = await tbDest . getWrappedAsset ( token );\nconsole . log (\n`Token already wrapped on ${ destChain . chain } . Skipping attestation.`\n);\nreturn { chain : destChain.chain , address : wrapped };\n} catch ( e ) {\nconsole . log (\n`No wrapped token found on ${ destChain . chain } . Proceeding with attestation.`\n);\n}\n// Source chain signer setup\nconst { signer : origSigner } = await getSigner ( srcChain );\n// Create an attestation transaction on the source chain\nconst tbOrig = await srcChain . getTokenBridge ();\nconst attestTxns = tbOrig . createAttestation (\ntoken . address ,\nWormhole . parseAddress ( origSigner . chain (), origSigner . address ())\n);\nconst txids = await signSendWait ( srcChain , attestTxns , origSigner );\nconsole . log ( 'txids: ' , inspect ( txids , { depth : null }));\nconst txid = txids [ 0 ] ! . txid ;\nconsole . log ( 'Created attestation (save this): ' , txid );\n// Retrieve the Wormhole message ID from the attestation transaction\nconst msgs = await srcChain . parseTransaction ( txid );\nconsole . log ( 'Parsed Messages:' , msgs );\nconst timeout = 25 * 60 * 1000 ;\nconst vaa = await wh . getVaa ( msgs [ 0 ] ! , 'TokenBridge:AttestMeta' , timeout );\nif ( ! vaa ) {\nthrow new Error (\n'VAA not found after retries exhausted. Try extending the timeout.'\n);\n}\nconsole . log ( 'Token Address: ' , vaa . payload . token . address );\n// Submit the attestation on the destination chain\nconsole . log ( 'Attesting asset on destination chain...' );\nconst subAttestation = tbDest . submitAttestation (\nvaa ,\nWormhole . parseAddress ( destSigner . chain (), destSigner . address ())\n);\nconst tsx = await signSendWait ( destChain , subAttestation , destSigner );\nconsole . log ( 'Transaction hash: ' , tsx );\n// Poll for the wrapped asset until it's available\nasync function waitForIt () {\ndo {\ntry {\nconst wrapped = await tbDest . getWrappedAsset ( token );\nreturn { chain : destChain.chain , address : wrapped };\n} catch ( e ) {\nconsole . error ( 'Wrapped asset not found yet. Retrying...' );\n}\nconsole . log ( 'Waiting before checking again...' );\nawait new Promise (( r ) => setTimeout ( r , 2000 ));\n} while ( true );\n}\nconsole . log ( 'Wrapped Asset: ' , await waitForIt ());\n})(). catch (( e ) => console . error ( e ));\nRun the Wrapped Token Creation ïŒ\nOnce the script is ready, execute it with:\nnpx tsx src/scripts/create-wrapped.ts\nIf the token is already wrapped, the script exits. Otherwise, it generates an attestation and submits it. Once complete, youâre ready to transfer tokens across chains.\nToken Transfers ïŒ\nIn this section, you'll create a script to transfer native tokens across chains using Wormhole's WTT protocol. The script will handle the transfer of Sui native tokens to Solana, demonstrating the seamless cross-chain transfer capabilities of the Wormhole SDK. Since both chains are non-EVM compatible, you'll need to manually handle the attestation and finalization steps.\nConfigure Transfer Details ïŒ\nBefore initiating a cross-chain transfer, you must set up the chain context and signers for both the source and destination chains.\n-\nCreate the native-transfer.ts file in the src directory to hold your script for transferring native tokens across chains.\ntouch src/scripts/native-transfer.ts\n-\nOpen the native-transfer.ts file and begin by importing the necessary modules from the SDK and helper files.\nimport {\nChain ,\nNetwork ,\nWormhole ,\namount ,\nwormhole ,\nTokenId ,\nTokenTransfer ,\n} from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport sui from '@wormhole-foundation/sdk/sui' ;\nimport { SignerStuff , getSigner , getTokenDecimals } from '../helpers/helpers' ;\n-\nInitialize the Wormhole SDK : Initialize the wormhole function for the Testnet environment and specify the platforms (EVM, Solana, and Sui) to support.\n( async function () {\nconst wh = await wormhole ( 'Testnet' , [ evm , solana , sui ]);\n-\nSet up source and destination chains : Specify the source chain (Sui) and the destination chain (Solana) using the getChain method. This allows us to define where to send the native tokens and where to receive them.\nconst sendChain = wh . getChain ( 'Sui' );\nconst rcvChain = wh . getChain ( 'Solana' );\n-\nConfigure the signers : Use the getSigner function to retrieve the signers responsible for signing transactions on the respective chains. This ensures that transactions are correctly authorized on both the source and destination chains.\nconst source = await getSigner ( sendChain );\nconst destination = await getSigner ( rcvChain );\n-\nDefine the token to transfer : Specify the native token on the source chain (Sui in this example) by creating a TokenId object.\nconst token = Wormhole . tokenId ( sendChain . chain , 'native' );\n-\nDefine the transfer amount : The amount of native tokens to transfer is specified. In this case, we're transferring 1 unit.\nconst amt = '1' ;\n-\nSet transfer mode : Specify manual or automatic transfer using route . Set route = 'TokenBridge' for manual transfers, where you will handle the attestation and finalization steps yourself. To use automatic relaying on EVM chains, set route = 'AutomaticTokenBridge' .\nconst route = 'TokenBridge' ;\nNote\nAutomatic transfers are only supported for EVM chains. For non-EVM chains, such as Solana and Sui, you must manually handle the attestation and finalization steps.\n-\nDefine decimals : Fetch the number of decimals for the token on the source chain (Sui) using the getTokenDecimals function.\nconst decimals = await getTokenDecimals ( wh , token , sendChain );\n-\nPerform the token transfer and exit the process : Initiate the transfer by calling the tokenTransfer function, which weâll define in the next step. This function takes an object containing all required details for executing the transfer, including the source and destination chains, token , mode , and transfer amount .\nconst xfer = await tokenTransfer ( wh , {\ntoken ,\namount : amount.units ( amount . parse ( amt , decimals )),\nsource ,\ndestination ,\nroute ,\n});\nFinally, we use process.exit(0); to close the script once the transfer completes.\nprocess . exit ( 0 );\n})();\nToken Transfer Logic ïŒ\nThis section defines the tokenTransfer function, which manages the core steps for executing cross-chain transfers. This function will handle initiating the transfer on the source chain, retrieving the attestation, and completing the transfer on the destination chain.\nDefining the Token Transfer Function ïŒ\nThe tokenTransfer function initiates and manages the transfer process, handling all necessary steps to move tokens across chains with the Wormhole SDK. This function uses types from the SDK and our helpers.ts file to ensure chain compatibility.\nasync function tokenTransfer < N extends Network > (\nwh : Wormhole < N > ,\nroute : {\ntoken : TokenId ;\namount : bigint ;\nsource : SignerStuff < N , Chain > ;\ndestination : SignerStuff < N , Chain > ;\nroute : string ;\npayload? : Uint8Array ;\n}\n) {\n// Token Transfer Logic\n}\nSteps to Transfer Tokens ïŒ\nThe tokenTransfer function comprises several key steps to facilitate cross-chain transfers. Letâs break down each step:\n-\nInitialize the transfer object : The tokenTransfer function begins by creating a TokenTransfer object, xfer , which tracks the state of the transfer process and provides access to relevant methods for each transfer step.\nconst xfer = await wh . tokenTransfer (\nroute . token ,\nroute . amount ,\nroute . source . address ,\nroute . destination . address ,\nroute . route ,\nroute . payload\n);\n-\nEstimate transfer fees and validate amount : We obtain a fee quote for the transfer before proceeding. This step is significant in automatic mode ( automatic = true ), where the quote will include additional fees for relaying.\nconst quote = await TokenTransfer . quoteTransfer (\nwh ,\nroute . source . chain ,\nroute . destination . chain ,\nxfer . transfer\n);\nif ( xfer . transfer . route === 'AutomaticTokenBridge' && quote . destinationToken . amount < 0 )\nthrow 'The amount requested is too low to cover the fee and any native gas requested.' ;\n-\nSubmit the transaction to the source chain : Initiate the transfer on the source chain by submitting the transaction using route.source.signer , starting the token transfer process.\nconst srcTxids = await xfer . initiateTransfer ( route . source . signer );\nconsole . log ( `Source Trasaction ID: ${ srcTxids [ 0 ] } ` );\n- srcTxids : The resulting transaction IDs are printed to the console. These IDs can be used to track the transferâs progress on the source chain and Wormhole network .\nHow Cross-Chain Transfers Work in the Background\nWhen xfer.initiateTransfer(route.source.signer) is called, it initiates the transfer on the source chain. Hereâs what happens in the background:\n- Token lock or burn : Tokens are either locked in a smart contract or burned on the source chain, representing the transfer amount.\n- VAA creation : Wormholeâs network of Guardians generates a Verifiable Action Approval (VAA)âa signed proof of the transaction, which ensures itâs recognized across chains.\n- Tracking the transfer : The returned transaction IDs allow you to track the transfer's progress both on the source chain and within Wormholeâs network.\n- Redemption on destination : Once detected, the VAA is used to release or mint the corresponding token amount on the destination chain, completing the transfer.\nThis process ensures a secure and verifiable transfer across chains, from locking tokens on the source chain to redeeming them on the destination chain.\n-\nWait for the attestation : Retrieve the Wormhole attestation (VAA), which serves as cryptographic proof of the transfer. In manual mode, you must wait for the VAA before redeeming the transfer on the destination chain.\nawait xfer . fetchAttestation ( 60 _000 );\n-\nComplete the transfer on the destination chain : Redeem the VAA on the destination chain to finalize the transfer.\nconst destTxids = await xfer . completeTransfer ( route . destination . signer );\nconsole . log ( `Completed Transfer: ` , destTxids );\nComplete script\nimport {\nChain ,\nNetwork ,\nWormhole ,\namount ,\nwormhole ,\nTokenId ,\nTokenTransfer ,\n} from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport sui from '@wormhole-foundation/sdk/sui' ;\nimport { SignerStuff , getSigner , getTokenDecimals } from '../helpers/helpers' ;\n( async function () {\nconst wh = await wormhole ( 'Testnet' , [ evm , solana , sui ]);\n// Set up source and destination chains\nconst sendChain = wh . getChain ( 'Sui' );\nconst rcvChain = wh . getChain ( 'Solana' );\n// Get signer from local key but anything that implements\nconst source = await getSigner ( sendChain );\nconst destination = await getSigner ( rcvChain );\n// Shortcut to allow transferring native gas token\nconst token = Wormhole . tokenId ( sendChain . chain , 'native' );\n// Define the amount of tokens to transfer\nconst amt = '1' ;\n// Set route for manual transfers\nconst route = 'TokenBridge' ;\n// Used to normalize the amount to account for the tokens decimals\nconst decimals = await getTokenDecimals ( wh , token , sendChain );\n// Perform the token transfer if no recovery transaction ID is provided\nconst xfer = await tokenTransfer ( wh , {\ntoken ,\namount : amount.units ( amount . parse ( amt , decimals )),\nsource ,\ndestination ,\nroute ,\n});\nprocess . exit ( 0 );\n})();\nasync function tokenTransfer < N extends Network > (\nwh : Wormhole < N > ,\nroute : {\ntoken : TokenId ;\namount : bigint ;\nsource : SignerStuff < N , Chain > ;\ndestination : SignerStuff < N , Chain > ;\nroute : string ;\npayload? : Uint8Array ;\n}\n) {\n// Token Transfer Logic\n// Create a TokenTransfer object to track the state of the transfer over time\nconst xfer = await wh . tokenTransfer (\nroute . token ,\nroute . amount ,\nroute . source . address ,\nroute . destination . address ,\nroute . route ,\nroute . payload\n);\nconst quote = await TokenTransfer . quoteTransfer (\nwh ,\nroute . source . chain ,\nroute . destination . chain ,\nxfer . transfer\n);\nif ( xfer . transfer . route === 'AutomaticTokenBridge' && quote . destinationToken . amount < 0 )\nthrow 'The amount requested is too low to cover the fee and any native gas requested.' ;\n// Submit the transactions to the source chain, passing a signer to sign any txns\nconsole . log ( 'Starting transfer' );\nconst srcTxids = await xfer . initiateTransfer ( route . source . signer );\nconsole . log ( `Source Trasaction ID: ${ srcTxids [ 0 ] } ` );\nconsole . log ( `Wormhole Trasaction ID: ${ srcTxids [ 1 ] ?? srcTxids [ 0 ] } ` );\n// Wait for the VAA to be signed and ready (not required for auto transfer)\nconsole . log ( 'Getting Attestation' );\nawait xfer . fetchAttestation ( 60 _000 );\n// Redeem the VAA on the dest chain\nconsole . log ( 'Completing Transfer' );\nconst destTxids = await xfer . completeTransfer ( route . destination . signer );\nconsole . log ( `Completed Transfer: ` , destTxids );\n}\nRun the Native Token Transfer ïŒ\nNow that youâve set up the project and defined the transfer logic, you can execute the script to transfer native tokens from the Sui chain to Solana. You can use tsx to run the TypeScript file directly:\nnpx tsx src/scripts/native-transfer.ts\nThis initiates the native token transfer from the source chain (Sui) and completes it on the destination chain (Solana).\nYou can monitor the status of the transaction on the Wormhole explorer .\nResources ïŒ\nIf you'd like to explore the complete project or need a reference while following this tutorial, you can find the complete codebase in Wormhole's demo GitHub repository . The repository includes all the example scripts and configurations needed to perform native token cross-chain transfers, including manual, automatic, and partial transfers using the Wormhole SDK.\nConclusion ïŒ\nYou've successfully built a cross-chain token transfer application using Wormhole's TypeScript SDK and the WTT protocol. This guide walks you through the setup, configuration, and transfer logic required to move native tokens across non-EVM chains, such as Sui and Solana.\nThe same transfer logic will apply if youâd like to extend this application to different chain combinations, including EVM-compatible chains.\nNext Steps ïŒ\n-\nDemo Tutorials Repository\nLooking for more hands-on tutorials? Check out the Wormhole Tutorial Demo repository on GitHub for additional examples.\nExplore the Demo Repository\nLast update: September 28, 2026\n| Created: September 28, 2026"}
{"url":"https://docs.polygon.technology/payments/get-started","domain":"docs.polygon.technology","title":"Get started - Polygon Developer Docs","hash":"c19c0eb4de42e9a0b4e40a88462f15bf890c534f6b920f087ae303fe2a9dfa93","tokens":3523,"chars":14089,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112037505,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPolygon Developer Docs home page\nPlatform\nPayments\nWallets\nCross-chain\nAPI Reference\nInfrastructure\nPolygon Chain\nPolygon CDK\nAgglayer\nAgentic\nIntroduction\nGet started\nRequest access, authenticate, and run your first transaction on the Open Money Stack.\nOMS gives you a single API for moving money between fiat and stablecoins. This guide takes you from zero to a working transaction in five steps.\n1\nRequest access and authenticate\nOMS is in early access. Start by requesting access from the dashboard.\nRequest OMS access\nSubmit your details to get sandbox credentials.\nOnce approved, open the OMS Dashboard and navigate to API Keys . Generate a new key and store the secret immediately, it is shown only once. Keys do not expire by default, support an optional enforced expiration, and can be rotated from the dashboard at any time.\nTreat your API key secret like a password. If it is ever compromised, revoke the key from the dashboard and generate a new one immediately.\nYou do not send the API key directly on requests. Exchange the key and secret for a short-lived bearer token at POST /auth/token , then send that token on every other call.\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/auth/token \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"apiKey\": \"{api_key}\",\n\"apiSecret\": \"{api_secret}\"\n}'\ncurl -X POST https://api.polygon.technology/v0.13/auth/token \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"apiKey\": \"{api_key}\",\n\"apiSecret\": \"{api_secret}\"\n}'\n{\n\"accessToken\" : \"eyJhbGc...\" ,\n\"tokenType\" : \"bearer\" ,\n\"expiresIn\" : 3600 ,\n\"expiresAt\" : \"2026-01-15T11:00:00Z\"\n}\nThe token is valid for 60 minutes. Send the accessToken as a bearer token on every other request:\nAuthorization: Bearer {accessToken}\nEvery mutating request ( POST and PATCH ) also requires an Idempotency-Key header. Replaying the same key returns the original result instead of re-executing.\nWhen a request returns 401 , the token has expired. Exchange your key for a fresh one and retry. If POST /auth/token returns 429 , the endpoint is rate-limited: back off before retrying using the Retry-After header.\n2\nCreate a customer\nEvery wallet, transaction, and payment route in OMS belongs to a customer record. Create one before anything else. To onboard a customer who can move USD or use cash services, send the full set of identifying fields, not just a name, and request the endorsements the customer needs.\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/customers \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: cst-first-customer-001\" \\\n-d '{\n\"type\": \"individual\",\n\"firstName\": \"Jane\",\n\"lastName\": \"Smith\",\n\"email\": \"jane@example.com\",\n\"phone\": \"+12125551234\",\n\"birthDate\": \"1990-05-15\",\n\"nationality\": \"US\",\n\"residentialAddress\": {\n\"line1\": \"123 Main St\",\n\"city\": \"New York\",\n\"state\": \"NY\",\n\"country\": \"US\",\n\"zipCode\": \"10001\"\n},\n\"identifyingInformation\": [\n{ \"type\": \"ssn\", \"issuingCountry\": \"US\", \"number\": \"123-45-6789\" }\n],\n\"endorsements\": [\"basic\", \"cryptoCustody\", \"usd\"]\n}'\ncurl -X POST https://api.polygon.technology/v0.13/customers \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: cst-first-customer-001\" \\\n-d '{\n\"type\": \"individual\",\n\"firstName\": \"Jane\",\n\"lastName\": \"Smith\",\n\"email\": \"jane@example.com\",\n\"phone\": \"+12125551234\",\n\"birthDate\": \"1990-05-15\",\n\"nationality\": \"US\",\n\"residentialAddress\": {\n\"line1\": \"123 Main St\",\n\"city\": \"New York\",\n\"state\": \"NY\",\n\"country\": \"US\",\n\"zipCode\": \"10001\"\n},\n\"identifyingInformation\": [\n{ \"type\": \"ssn\", \"issuingCountry\": \"US\", \"number\": \"123-45-6789\" }\n],\n\"endorsements\": [\"basic\", \"cryptoCustody\", \"usd\"]\n}'\n{\n\"id\" : \"cst_01H9Xa...\" ,\n\"object\" : \"customer\" ,\n\"type\" : \"individual\" ,\n\"status\" : \"active\" ,\n\"endorsements\" : [\n{ \"name\" : \"basic\" , \"status\" : \"ACTIVE\" },\n{ \"name\" : \"cryptoCustody\" , \"status\" : \"ACTIVE\" },\n{ \"name\" : \"usd\" , \"status\" : \"PENDING\" }\n],\n\"wallets\" : [],\n\"createdAt\" : \"2026-01-15T10:00:00Z\"\n}\nStore the cst_ ID; you pass it to every wallet, quote, and transaction. Each endorsement tracks its own status in SCREAMING_CASE and must reach ACTIVE before its capability unlocks. PII fields ( birthDate , residentialAddress , ipAddress , identifyingInformation ) are write-only: OMS accepts them but never returns them.\nThe API accepts a customer with only type , but a customer created without the identifying fields below cannot be provisioned to move fiat. The record is created, yet calls that need a provisioned fiat account (cash-in or a fiat transaction) fail. For USD and cash flows, always provide:\n- A structured residentialAddress (the object above, not a free-text string)\n- phone in E.164 format\n- birthDate\n- A government ID in identifyingInformation (for US customers, an ssn or itin )\nSupply these at creation, or add them later with PATCH /customers/{customerId} . Products that never touch fiat rails may not need them. Only individual is supported for type today.\nIn sandbox, endorsements are auto-approved so you can test without a live KYC integration. Provisioning still reads the identifying fields above, so include them in sandbox too.\n3\nProvision a wallet\nCreate a custodial wallet for the customer. The path carries the customer ID; the body names the asset and chain to hold. OMS derives the on-chain address and manages the keys, with no wallet SDK or user signing.\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/customers/cst_01H9Xa.../wallets \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: wlt-first-wallet-001\" \\\n-d '{\n\"asset\": \"usdc\",\n\"chain\": \"polygon\"\n}'\ncurl -X POST https://api.polygon.technology/v0.13/customers/cst_01H9Xa.../wallets \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: wlt-first-wallet-001\" \\\n-d '{\n\"asset\": \"usdc\",\n\"chain\": \"polygon\"\n}'\n{\n\"id\" : \"wlt_01H9Xb...\" ,\n\"object\" : \"wallet\" ,\n\"customerId\" : \"cst_01H9Xa...\" ,\n\"type\" : \"internal\" ,\n\"status\" : \"active\" ,\n\"asset\" : \"usdc\" ,\n\"chain\" : \"polygon\" ,\n\"address\" : \"0xBEEF4a2c891D56e72b67a3f21d0cf94F1D7c5911\" ,\n\"blockchainAsset\" : {\n\"protocol\" : \"evm\" ,\n\"chainId\" : \"137\" ,\n\"tokenId\" : \"0x3c499c542cef5e3811e1192ce70d8cc03d5c3359\"\n},\n\"createdAt\" : \"2026-01-15T10:01:00Z\"\n}\nThe address is the on-chain address. The wlt_ ID is what you pass as the source or destination in quotes and transactions. Read the current balance with GET /wallets/{walletId}/balance .\n4\nRun your first transaction\nThe cash-in flow is the quickest path for your first run: it needs no external account. The bank transfer flow shows the standard quote-to-transaction pattern for fiat payouts.\n-\nCash-in\n-\nBank transfer\nLet a customer deposit physical cash at a retail location and receive USDC in their wallet.\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/cash-ins \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: ci-first-001\" \\\n-d '{\n\"customerId\": \"cst_01H9Xa...\",\n\"cash\": {\n\"locationId\": \"loc_01H9Xd...\",\n\"locationReference\": \"R1JFRU5ET1QtMjQzNDpsYXQ9...\"\n},\n\"source\": {\n\"asset\": \"usd\",\n\"indicatedAmount\": \"100.00\"\n},\n\"destination\": {\n\"asset\": \"usdc\",\n\"network\": \"polygon\",\n\"wallet\": { \"id\": \"wlt_01H9Xb...\" }\n}\n}'\ncurl -X POST https://api.polygon.technology/v0.13/cash-ins \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: ci-first-001\" \\\n-d '{\n\"customerId\": \"cst_01H9Xa...\",\n\"cash\": {\n\"locationId\": \"loc_01H9Xd...\",\n\"locationReference\": \"R1JFRU5ET1QtMjQzNDpsYXQ9...\"\n},\n\"source\": {\n\"asset\": \"usd\",\n\"indicatedAmount\": \"100.00\"\n},\n\"destination\": {\n\"asset\": \"usdc\",\n\"network\": \"polygon\",\n\"wallet\": { \"id\": \"wlt_01H9Xb...\" }\n}\n}'\nOMS returns a depositInstructions.code valid for one hour. The customer presents the code at the retail location, hands over cash, and USDC lands in their wallet automatically. See the Cash-in guide for the full flow.\nPay out from a wallet to a bank account. Register the destination bank account with POST /external-accounts , then quote and execute against the returned external account ID ( ext_... ). A quoteâs source is always an OMS wallet or a card.\nBank payouts require the customerâs usd endorsement to be ACTIVE .\nRegister the destination bank account: The body carries an owner , a type , and exactly one per-type object matching the type (here bankUs ).\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/external-accounts \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: ext-bank-first-001\" \\\n-d '{\n\"owner\": { \"kind\": \"customer\", \"customerId\": \"cst_01H9Xa...\" },\n\"type\": \"bankUs\",\n\"bankUs\": {\n\"accountNumber\": \"123456789012\",\n\"routingNumber\": \"021000021\",\n\"accountType\": \"checking\",\n\"bankName\": \"Chase\"\n}\n}'\ncurl -X POST https://api.polygon.technology/v0.13/external-accounts \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: ext-bank-first-001\" \\\n-d '{\n\"owner\": { \"kind\": \"customer\", \"customerId\": \"cst_01H9Xa...\" },\n\"type\": \"bankUs\",\n\"bankUs\": {\n\"accountNumber\": \"123456789012\",\n\"routingNumber\": \"021000021\",\n\"accountType\": \"checking\",\n\"bankName\": \"Chase\"\n}\n}'\nThe response returns the external accountâs ext_ ID. The account starts pending and flips to active once provisioning completes. The full account number is write-only; reads expose only bankUs.accountNumberLast4 . Pay out from a wallet to a bank account (USDC to fiat):\n# Step 1: create a quote against the registered bank account\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/quotes \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: qt-bank-out-001\" \\\n-d '{\n\"customerId\": \"cst_01H9Xa...\",\n\"source\": {\n\"type\": \"walletCrypto\",\n\"details\": { \"id\": \"wlt_01H9Xb...\", \"asset\": \"usdc\", \"network\": \"polygon\" },\n\"amount\": \"100.00\"\n},\n\"destination\": {\n\"type\": \"bankUs\",\n\"details\": {\n\"id\": \"ext_01H9X...\",\n\"asset\": \"usd\",\n\"network\": \"ach\",\n\"accountHolder\": \"customer\"\n}\n}'\n# Step 2: execute\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/transactions \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: txn-bank-out-001\" \\\n-d '{ \"quoteId\": \"qt_01H9Xq...\" }'\n# Step 1: create a quote against the registered bank account\ncurl -X POST https://api.polygon.technology/v0.13/quotes \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: qt-bank-out-001\" \\\n-d '{\n\"customerId\": \"cst_01H9Xa...\",\n\"source\": {\n\"type\": \"walletCrypto\",\n\"details\": { \"id\": \"wlt_01H9Xb...\", \"asset\": \"usdc\", \"network\": \"polygon\" },\n\"amount\": \"100.00\"\n},\n\"destination\": {\n\"type\": \"bankUs\",\n\"details\": {\n\"id\": \"ext_01H9X...\",\n\"asset\": \"usd\",\n\"network\": \"ach\",\n\"accountHolder\": \"customer\"\n}\n}'\n# Step 2: execute\ncurl -X POST https://api.polygon.technology/v0.13/transactions \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: txn-bank-out-001\" \\\n-d '{ \"quoteId\": \"qt_01H9Xq...\" }'\nSee the Bank transfers guide for both directions and ACH-specific flows.\n5\nConfigure webhooks\nOMS fires webhooks at every meaningful state change. You can poll GET /transactions/{transactionId} instead, but webhooks are strongly recommended for production. Register an endpoint with POST /webhooks (or in the OMS Dashboard under Webhooks ). OMS returns a cleartext signingKey once in the create response, so store it immediately; it is never returned again. Rotate it later with POST /webhooks/{webhookId}/rotate-key .\ncurl -X POST https://sandbox-api.polygon.technology/v0.13/webhooks \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: whk-first-001\" \\\n-d '{\n\"url\": \"https://api.yourapp.com/webhooks/oms\",\n\"subscriptions\": [\"*\"]\n}'\ncurl -X POST https://api.polygon.technology/v0.13/webhooks \\\n-H \"Authorization: Bearer {accessToken}\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Idempotency-Key: whk-first-001\" \\\n-d '{\n\"url\": \"https://api.yourapp.com/webhooks/oms\",\n\"subscriptions\": [\"*\"]\n}'\nPass [\"*\"] in subscriptions to receive every event, or list specific event names to filter. Manage endpoints with GET /webhooks , PATCH /webhooks/{webhookId} , POST /webhooks/{webhookId}/enable | /disable for lifecycle, POST /webhooks/{webhookId}/test to verify signature and reachability, and DELETE /webhooks/{webhookId} for soft delete. Inspect delivery history at GET /webhooks/{webhookId}/deliveries and requeue failures at POST /webhooks/{webhookId}/deliveries/retry . Every event carries the full resource object under data , so you rarely need to poll for additional information. Some events you will see early on:\nEvent Fires when\ntransaction.statusChanged A transaction changed status, in either direction and on any rail\ncashIn.completed A cash deposit was received and converted\nexternalAccount.verified A registered bank account passed validation and is usable on quotes\nvirtualAccount.deposit.settled An inbound bank deposit to a virtual account settled\nSee Webhook events for the envelope and the full catalog.\nVerify every webhook with the Webhook-Signature header before acting on it. The signature is an HMAC-SHA256 keyed with your endpointâs signingKey ; compare it in constant time and reject events with a stale timestamp.\nWhatâs next\nCash-in\nFull walkthrough of the cash deposit flow, including deposit code generation and retail location selection.\nBank transfers\nMove money between bank accounts and wallets in both directions using ACH and card rails.\nPayments overview\nHow OMS handles payments, stablecoin settlement, and compliant fiat access end to end.\nAPI reference\nComplete endpoint reference for all OMS resources.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes.\nSuggestions\nContact support"}
{"url":"https://bitcoinops.org/en/newsletters/2026/07/24/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #415 | Bitcoin Optech","hash":"3b35c0f4a96acd7aafe55044d949484020c85eae8b001220262dd9a6b8f6e17f","tokens":2791,"chars":11161,"crawler":"hive-genesis","verified":"unchecked","ts":1791112039453,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #415\nJul 24, 2026\nThis weekâs newsletter describes a draft BIP for full aggregation of BIP340\nsignatures. Also included are our regular sections describing recent changes to\nservices and client software, announcing new releases and release candidates,\nand summarizing notable changes to popular Bitcoin infrastructure software.\nNews\n-\nâ Draft BIP for full aggregation of BIP340 signatures : Fabian Jahr posted to\nthe Bitcoin-Dev mailing list about a new draft BIP for full aggregation of\nBIP340 schnorr signatures , a standard for the DahLIAS aggregate signature scheme\n(see Newsletter #351 ), which describes a process to\ncombine a collection of signatures into a single aggregate one, with a size\nof only 64 bytes, regardless of the number of signers. However, the described\nprotocol is interactive and requires cooperation among all the signers and involves\nthe presence of an untrusted coordinator to reduce communication complexity.\nThe coordinator role can be taken by any of the signers participating in the process.\nThe process is divided into two rounds:\n-\nEach signer starts the signing session by computing a secret nonce\n( secnonce ) and a public nonce ( pubnonce ). pubnonce is sent to the\ncoordinator, which aggregates them ( aggnonce ) and sends the result back to\nsigners, together with other pieces of information.\n-\nEach signer computes a partial signature using the secret key, secnonce ,\nthe message to sign, and the information provided. Partial signatures are then\nsent to the coordinator, which aggregates them in a single 64-byte signature.\nAccording to Jahr, one of the possible applications of the proposal would\nbe cross-input signature aggregation (CISA) , a change to Bitcoin\nconsensus that would reduce size and thus on-chain fees of multi-input transactions.\nHowever, the author specified that the consensus change is outside the scope of this BIP.\nThe draft BIP, which is now referred to as BIP459, is currently being discussed in BIPs #2210\nand the proposal is gathering feedback from the community.\nChanges to services and client software\nIn this monthly feature, we highlight interesting updates to Bitcoin\nwallets and services.\n-\nâ Wasabi Wallet 2.8.0 released:\nWasabi Wallet 2.8.0 downloads compact block filters directly from the P2P network, removing the previously\nrequired centralized backend server. The release also adds the ability to pay\nrecipients directly within a coinjoin , support for\nfeerates below 1 sat/vbyte , and payment batching , among other\nfeatures.\n-\nâ Coinswap v0.2.2 released:\nCoinswap v0.2.2 adds multi-transaction swaps, deniability\nproofs, and marketplace improvements to its coinswap\nprotocol implementation (see Newsletter #338 ). The\nrelease also includes fixes for findings from a security audit performed\nusing Loupe, Spiralâs open source, AI-powered security scanner.\n-\nâ Go secp256k1 library announced:\nAllocz announced a Go library that\nuses libsecp256k1 bindings when C interoperability is\nenabled and falls back to a pure-Go implementation otherwise, preserving Goâs\ncross-compilation capability. The author reports ECDSA and schnorr\nsignature verification times drop 70% compared to\nthe pure-Go implementation.\n-\nâ ASMap dashboard announced:\nJoris Strakeljahn announced an ASMap\ndashboard that tracks the history of ASMap\ndata releases (see Newsletter #394 ),\nincluding how much address space shifts between operators from release to\nrelease and how well each release covers actually observed Bitcoin nodes as\nthe data ages.\n-\nâ Wavelength alpha released:\nLightning Labs announced an alpha version of Wavelength,\na toolkit for adding self-custodial payments to applications. It pays and\nreceives BOLT11 LN invoices, and batches off-chain transfers using an\nArk -like settlement layer, without requiring users to manage their own\nchannels. The alpha is available on signet and testnet.\nReleases and release candidates\nNew releases and release candidates for popular Bitcoin infrastructure\nprojects. Please consider upgrading to new releases or helping to test\nrelease candidates.\n-\nâ Core Lightning v26.06.6 is a maintenance release of this LN node\nimplementation. It updates the bundled pyln-proto libraryâs coincurve\ndependency to fix Python build environments and adds a check that rejects\nany channel reusing the funding outpoint of an existing channel.\n-\nâ Bitcoin Inquisition 29.4 is a release of this signet\nfull node designed for experimenting with proposed soft forks and other\nmajor protocol changes. Based on Bitcoin Core 29.4, it adds activation of\nBIP446 ( OP_TEMPLATEHASH ), a proposed tapscript\nopcode that pushes a hash of the spending transaction onto the stack (see\nNewsletter #365 ), to its existing set of\nexperimentally-activated soft-fork proposals.\nNotable code and documentation changes\nNotable recent changes in Bitcoin Core , Core\nLightning , Eclair , LDK ,\nLND , libsecp256k1 , Hardware Wallet\nInterface (HWI) , Rust Bitcoin , BTCPay\nServer , BDK , Bitcoin Improvement\nProposals (BIPs) , Lightning BOLTs ,\nLightning BLIPs , Bitcoin Inquisition , and BINANAs .\n-\nâ Bitcoin Core #35215 speeds up lookups in the in-memory UTXO cache\n( CCoinsMap ) by replacing SipHash-2-4 , the function used to hash its\nCOutPoint keys, with a faster, purpose-built SipHash variant,\nSipHasher13UJ . Each coin is looked up by a key that combines its txid and\noutput number, and every lookup runs that key through a hash function.\nSipHash-2-4 digests a coinâs 32-byte txid in four separate 64-bit pieces,\nso hashing one outpoint runs 14 internal rounds. SipHasher13UJ instead\ntakes in the whole txid in one 256-bit step and does fewer rounds, cutting\nthat to five. The author reports roughly double the hashing throughput in\nisolated benchmarks and about a 5% reduction in one chainstate-reindex run.\n-\nâ Bitcoin Core #35766 enables BIP324 v2 p2p transport by default when first connecting to addresses from DNS seeds and\nthe compiled-in fixed seeds. Experimental support for BIP324 shipped in\nBitcoin Core 26.0 and was enabled by default in 27.0. Since these seed\nmechanisms provide addresses without service flags, Bitcoin Core previously\ntreated the peers as v1 only and a nodeâs earliest automatic connections\nnever attempted encrypted transport. The new SeedsAssumedServiceFlags()\nfunction now assumes NODE_P2P_V2 for those addresses. If this assumption\nis incorrect for a given peer, the node simply reconnects using v1.\nConnections made through the -seednode option and address fetching\nalready attempt v2 by default.\n-\nâ BIPs #2075 clarifies BIP174 âs description of how PSBTs\nare combined. The specification had asserted that combining independently\nupdated PSBTs is unconditionally order-independent, but this only holds when\nthe participants add distinct fields. When two PSBTs contain the same key\nwith different values, a combiner may pick either value or refuse to combine,\nso the specification now notes that in this case the result is not\ncommutative.\n-\nâ BIPs #2204 updates the draft BIP440 and BIP441 Great Script\nRestoration specifications (see Newsletter #400 ). It\nintroduces wordspan notation, which rounds up the byte length of a stack\nelement to the next eight-byte boundary, and reworks numerous operation cost\nformulas so that operations that process data in 64-bit words are charged by\nwordspan while those that work on the exact bytes stay costed by length .\nThe update also corrects the definition of OP_RIGHT and clarifies costs\nand range checks for several other opcodes.\n-\nâ Core Lightning #8935 fixes a bug that could cause a node to repeatedly\nRBF a transaction, even after a replacement had already\nconfirmed. CLN stores pending transactions in an outgoing_tx_map keyed by\nthe original txid, but it replaces the transaction object with each\nhigher-fee version without changing the key. The per-block\nrebroadcast_txs() loop checked for confirmation using the stale original\ntxid, which was never mined, so it kept invoking the rebroadcast and\nreplacement logic even though the latest transaction had confirmed. Since\nthe txid serves as the hash-table key and cannot be updated in place, the\nloop now computes the current transactionâs txid with each iteration and\nuses it for confirmation checks.\n-\nâ Core Lightning #9324 fixes a Renepay regression (see Newsletter\n#263 ) present since v26.04 that built HTLCs\nwith CLTV expiries roughly one block height too far in the future. Renepayâs\nroute data already incorporated the current block height into each hopâs\nCLTV value, but route_sendpay_request() added the block height a second\ntime when passing the route to sendpay , roughly doubling the expiry.\nForwarding nodes could then reject the onion with expiry_too_far .\n-\nâ libsecp256k1 #1765 adds an optional silentpayments module that\nimplements the elliptic-curve operations defined by BIP352 silent\npayments . For\nsenders, one function combines the senderâs input private keys, the\ntransactionâs lowest outpoint, and the recipientâs published scan and spend\npublic keys to derive the output keys that the transaction should pay. For\nreceivers, full-node scanning detects which of a transactionâs outputs\nbelong to the recipient and returns the tweaks needed to spend them, working\nfrom only the recipientâs scan secret key and spend public key so the spend\nprivate key can stay offline. Separate functions manage labels, an optional\nBIP352 feature that lets recipients derive distinguishable variants of\ntheir address to tell incoming payments apart and flag their own change.\nLight client scanning support was deferred to a later PR.\n-\nâ Rust Bitcoin #6317 updates its compact block relay decoding to reject sendcmpct messages whose boolean announcement\nfield is not exactly 0 or 1 , as required by BIP152 . Previously, Rust\nBitcoin decoded the field with a non-zero test, accepting any non-zero value\nas true (high-bandwidth mode). This PR mirrors the hardening equivalent in\nBitcoin Core (see Newsletter #412 ).\n-\nâ BTCPay Server #7457 adds the ability to import wallet labels in BIP329 JSON Lines format, complementing the existing\nexport functionality. Previously labels were effectively lost when moving to\nanother server, and label files produced by BIP329-aware wallets such as\nSparrow or Envoy could not be loaded at all. The importer reads the formatâs\ntx , addr , and output records and maps them to BTCPayâs transaction,\naddress, and UTXO objects, skipping any records it canât apply.\n-\nâ BLIPs #71 adds a dnssec_error response to BLIP32 , the protocol\nthat resolves BIP353 human-readable payment names by carrying DNSSEC\nqueries and proofs over Lightning onion messages (see Newsletter\n#306 ). Previously the protocol only defined dnssec_query\nand dnssec_proof , so resolvers that could not respond had no standardized\nway to indicate this to the requester, who would continue to wait. The new\nfinal-hop TLV (type 65550 ) echoes the queried domain_name and includes a\ndefinitely_unresolvable boolean that a resolver should set for terminal\nfailures, such as NXDOMAIN or an unsigned name, and not set for other,\npossibly transient failures."}
{"url":"https://docs.berachain.com/general/introduction/what-is-proof-of-liquidity","domain":"docs.berachain.com","title":"What is Proof of Liquidity? - Berachain","hash":"e6d227c8e1cafd66a25dbca674256b43937d2db0d3beced4bfbe0823c125c7e8","tokens":710,"chars":2840,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112039039,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBerachain home page\nGeneral\nBEX\nBend\nBuild\nNodes\nOverview\nWhat is Proof of Liquidity?\nBerachainâs economic coordination system for turning network emissions into productive liquidity, application growth, and ecosystem value.\nProof of Liquidity (PoL) is Berachainâs answer to the emissions problem. Most chains spend emissions like a faucet: tokens flow out to secure the network, subsidise activity, and attract applications, but little value flows back.\nBerachain flips this model with Proof of Liquidity. Instead of treating emissions as a pure cost, PoL turns them into growth capital for applications building on the chain. Emissions are directed toward useful liquidity, application activity, and businesses that can generate value back into the ecosystem.\nThe loop is simple: emissions to businesses â businesses grow and earn more â revenue is shared with the chain directly or through the incentive market â $BERA strengthen â more businesses funded with emissions â repeat.\nThe PoL value cycle: emissions fund businesses, businesses return revenue, revenue strengthens BERA, and a stronger BERA economy underwrites the next emissions.\nHow PoL works\nPoL starts when validators stake $BERA to secure the chain and produce blocks. When blocks are produced, the network emits $WBERA.\nA portion of those emissions goes to validator operators. The rest flows through Berachainâs reward allocation system and is directed toward Reward Vaults, where applications connect useful liquidity and activity to network incentives.\nApplications can fund incentives to attract emissions. Users can earn rewards by providing liquidity or activity through eligible vaults, or by participating through simpler staking paths such as $sWBERA.\nIncentives earned through the system are converted into $BERA and accrued into $sWBERA, creating a cleaner value path for users and keeping rewards aligned with the broader $BERA economy.\nThis creates a market for useful activity. Validators compete for stake, applications compete for emissions, and users choose where to supply liquidity or participate in staking.\nIn addition to market-based allocation, selected businesses can receive Dedicated Emission Streams : predictable emissions they can plan around and use for long-term growth. These businesses use emissions to grow, then return value to Berachain through premium repayments and long-term revenue sharing.\nFor a comprehensive breakdown of all PoL components, roles, and pathways, continue to Proof of Liquidity Overview . If youâre building on Berachain, start your integration journey with Integration Basics .\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://raw.githubusercontent.com/ethereum/go-ethereum/master/README.md","domain":"raw.githubusercontent.com","title":"","hash":"91d0e5a67228b54610ce481a81b23d09e5b19f261eb0c19c73245407d8766c8a","tokens":3535,"chars":14139,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112040834,"text":"## Go Ethereum\nGolang execution layer implementation of the Ethereum protocol.\n[](https://pkg.go.dev/github.com/ethereum/go-ethereum?tab=doc)\n[](https://goreportcard.com/report/github.com/ethereum/go-ethereum)\n[](https://app.travis-ci.com/github/ethereum/go-ethereum)\n[](https://discord.gg/nthXNEv)\n[](https://x.com/go_ethereum)\nAutomated builds are available for stable releases and the unstable master branch. Binary\narchives are published at https://geth.ethereum.org/downloads/.\n## Building the source\nFor prerequisites and detailed build instructions please read the [Installation Instructions](https://geth.ethereum.org/docs/getting-started/installing-geth).\nBuilding `geth` requires both a Go (version 1.25 or later) and a C compiler. You can install\nthem using your favourite package manager. Once the dependencies are installed, run\n```shell\nmake geth\n```\nor, to build the full suite of utilities:\n```shell\nmake all\n```\n## Executables\nThe go-ethereum project comes with several wrappers/executables found in the `cmd`\ndirectory.\n| Command | Description |\n| :--------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **`geth`** | Our main Ethereum CLI client. It is the entry point into the Ethereum network (main-, test- or private net), capable of running as a full node (default) or archive node (retaining all historical state). It can be used by other processes as a gateway into the Ethereum network via JSON RPC endpoints exposed on top of HTTP, WebSocket and/or IPC transports. `geth --help` and the [CLI page](https://geth.ethereum.org/docs/fundamentals/command-line-options) for command line options. |\n| `devp2p` | Utilities to interact with nodes on the networking layer, without running a full blockchain. |\n| `abigen` | Source code generator to convert Ethereum contract definitions into easy-to-use, compile-time type-safe Go packages. It operates on plain [Ethereum contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html) with expanded functionality if the contract bytecode is also available. However, it also accepts Solidity source files, making development much more streamlined. Please see our [Native DApps](https://geth.ethereum.org/docs/developers/dapp-developer/native-bindings) page for details. |\n| `evm` | Developer utility version of the EVM (Ethereum Virtual Machine) that is capable of running bytecode snippets within a configurable environment and execution mode. Its purpose is to allow isolated, fine-grained debugging of EVM opcodes (e.g. `evm --code 60ff60ff --debug run`). |\n| `rlpdump` | Developer utility tool to convert binary RLP ([Recursive Length Prefix](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp)) dumps (data encoding used by the Ethereum protocol both network as well as consensus wise) to user-friendlier hierarchical representation (e.g. `rlpdump --hex CE0183FFFFFFC4C304050583616263`). |\n## Running `geth`\nGoing through all the possible command line flags is out of scope here (please consult our\n[CLI Wiki page](https://geth.ethereum.org/docs/fundamentals/command-line-options)),\nbut we've enumerated a few common parameter combos to get you up to speed quickly\non how you can run your own `geth` instance.\n### Hardware Requirements\nMinimum:\n* CPU with 4+ cores\n* 8GB RAM\n* High-performance SSD with at least 2TB of free space\n* 8 MBit/sec download Internet service\nRecommended:\n* Fast CPU with 8+ cores\n* 16GB+ RAM\n* High-performance NVMe SSD with 2TB-4TB of space for long term growth and maintenance headroom\n* 25+ MBit/sec download Internet service\n### Full node on the main Ethereum network\nBy far the most common scenario is people wanting to simply interact with the Ethereum\nnetwork: create accounts; transfer funds; deploy and interact with contracts. For this\nparticular use case, the user doesn't care about years-old historical data, so we can\nsync quickly to the current state of the network. To do so:\n```shell\n$ geth console\n```\nThis command will:\n* Start `geth` in snap sync mode (default, can be changed with the `--syncmode` flag),\ncausing it to download more data in exchange for avoiding processing the entire history\nof the Ethereum network, which is very CPU intensive.\n* Start the built-in interactive [JavaScript console](https://geth.ethereum.org/docs/interacting-with-geth/javascript-console),\n(via the trailing `console` subcommand) through which you can interact using [`web3` methods](https://github.com/ChainSafe/web3.js/blob/0.20.7/DOCUMENTATION.md)\n(note: the `web3` version bundled within `geth` is very old, and not up to date with official docs),\nas well as `geth`'s own [management APIs](https://geth.ethereum.org/docs/interacting-with-geth/rpc).\nThis tool is optional and if you leave it out you can always attach it to an already running\n`geth` instance with `geth attach`.\n### A Full node on the Sepolia test network\nTransitioning towards developers, if you'd like to play around with creating Ethereum\ncontracts, you almost certainly would like to do that without any real money involved until\nyou get the hang of the entire system. In other words, instead of attaching to the main\nnetwork, you want to join the **test** network with your node, which is fully equivalent to\nthe main network, but with play-Ether only.\n```shell\n$ geth --sepolia console\n```\nThe `console` subcommand has the same meaning as above and is equally\nuseful on the testnet too.\nSpecifying the `--sepolia` flag, however, will reconfigure your `geth` instance a bit:\n* Instead of connecting to the main Ethereum network, the client will connect to the Sepolia\ntest network, which uses different P2P bootnodes, different network IDs and genesis\nstates.\n* Instead of using the default data directory (`~/.ethereum` on Linux for example), `geth`\nwill nest itself one level deeper into a `sepolia` subfolder (`~/.ethereum/sepolia` on\nLinux). Note, on OSX and Linux this also means that attaching to a running testnet node\nrequires the use of a custom endpoint since `geth attach` will try to attach to a\nproduction node endpoint by default, e.g.,\n`geth attach /sepolia/geth.ipc`. Windows users are not affected by\nthis.\n*Note: Although some internal protective measures prevent transactions from\ncrossing over between the main network and test network, you should always\nuse separate accounts for play and real money. Unless you manually move\naccounts, `geth` will by default correctly separate the two networks and will not make any\naccounts available between them.*\n### Configuration\nAs an alternative to passing the numerous flags to the `geth` binary, you can also pass a\nconfiguration file via:\n```shell\n$ geth --config /path/to/your_config.toml\n```\nTo get an idea of how the file should look like you can use the `dumpconfig` subcommand to\nexport your existing configuration:\n```shell\n$ geth --your-favourite-flags dumpconfig\n```\n#### Docker quick start\nOne of the quickest ways to get Ethereum up and running on your machine is by using\nDocker:\n```shell\ndocker run -d --name ethereum-node -v /Users/alice/ethereum:/root \\\n-p 8545:8545 -p 30303:30303 \\\nethereum/client-go\n```\nThis will start `geth` in snap-sync mode with a DB memory allowance of 1GB, as the\nabove command does. It will also create a persistent volume in your home directory for\nsaving your blockchain as well as map the default ports. There is also an `alpine` tag\navailable for a slim version of the image.\nDo not forget `--http.addr 0.0.0.0`, if you want to access RPC from other containers\nand/or hosts. By default, `geth` binds to the local interface and RPC endpoints are not\naccessible from the outside.\n### Programmatically interfacing `geth` nodes\nAs a developer, sooner rather than later you'll want to start interacting with `geth` and the\nEthereum network via your own programs and not manually through the console. To aid\nthis, `geth` has built-in support for a JSON-RPC based APIs ([standard APIs](https://ethereum.org/en/developers/docs/apis/json-rpc/)\nand [`geth` specific APIs](https://geth.ethereum.org/docs/interacting-with-geth/rpc)).\nThese can be exposed via HTTP, WebSockets and IPC (UNIX sockets on UNIX based\nplatforms, and named pipes on Windows).\nThe IPC interface is enabled by default and exposes all the APIs supported by `geth`,\nwhereas the HTTP and WS interfaces need to manually be enabled and only expose a\nsubset of APIs due to security reasons. These can be turned on/off and configured as\nyou'd expect.\nHTTP based JSON-RPC API options:\n* `--http` Enable the HTTP-RPC server\n* `--http.addr` HTTP-RPC server listening interface (default: `localhost`)\n* `--http.port` HTTP-RPC server listening port (default: `8545`)\n* `--http.api` API's offered over the HTTP-RPC interface (default: `eth,net,web3`)\n* `--http.corsdomain` Comma separated list of domains from which to accept cross-origin requests (browser enforced)\n* `--ws` Enable the WS-RPC server\n* `--ws.addr` WS-RPC server listening interface (default: `localhost`)\n* `--ws.port` WS-RPC server listening port (default: `8546`)\n* `--ws.api` API's offered over the WS-RPC interface (default: `eth,net,web3`)\n* `--ws.origins` Origins from which to accept WebSocket requests\n* `--ipcdisable` Disable the IPC-RPC server\n* `--ipcpath` Filename for IPC socket/pipe within the datadir (explicit paths escape it)\nYou'll need to use your own programming environments' capabilities (libraries, tools, etc) to\nconnect via HTTP, WS or IPC to a `geth` node configured with the above flags and you'll\nneed to speak [JSON-RPC](https://www.jsonrpc.org/specification) on all transports. You\ncan reuse the same connection for multiple requests!\n**Note: Please understand the security implications of opening up an HTTP/WS based\ntransport before doing so! Hackers on the internet are actively trying to subvert\nEthereum nodes with exposed APIs! Further, all browser tabs can access locally\nrunning web servers, so malicious web pages could try to subvert locally available\nAPIs!**\n### Operating a private network\nMaintaining your own private network is more involved as a lot of configurations taken for\ngranted in the official networks need to be manually set up.\nUnfortunately since [the Merge](https://ethereum.org/en/roadmap/merge/) it is no longer possible\nto easily set up a network of geth nodes without also setting up a corresponding beacon chain.\nThere are three different solutions depending on your use case:\n* If you are looking for a simple way to test smart contracts from go in your CI, you can use the [Simulated Backend](https://geth.ethereum.org/docs/developers/dapp-developer/native-bindings#blockchain-simulator).\n* If you want a convenient single node environment for testing, you can use our [Dev Mode](https://geth.ethereum.org/docs/developers/dapp-developer/dev-mode).\n* If you are looking for a multiple node test network, you can set one up quite easily with [Kurtosis](https://geth.ethereum.org/docs/fundamentals/kurtosis).\n## Contribution\nThank you for considering helping out with the source code! We welcome contributions\nfrom anyone on the internet, and are grateful for even the smallest of fixes!\nIf you'd like to contribute to go-ethereum, please fork, fix, commit and send a pull request\nfor the maintainers to review and merge into the main code base. If you wish to submit\nmore complex changes though, please check up with the core devs first on [our Discord Server](https://discord.gg/invite/nthXNEv)\nto ensure those changes are in line with the general philosophy of the project and/or get\nsome early feedback which can make both your efforts much lighter as well as our review\nand merge procedures quick and simple.\nPlease make sure your contributions adhere to our coding guidelines:\n* Code must adhere to the official Go [formatting](https://golang.org/doc/effective_go.html#formatting)\nguidelines (i.e. uses [gofmt](https://golang.org/cmd/gofmt/)).\n* Code must be documented adhering to the official Go [commentary](https://golang.org/doc/effective_go.html#commentary)\nguidelines.\n* Pull requests need to be based on and opened against the `master` branch.\n* Commit messages should be prefixed with the package(s) they modify.\n* E.g. \"eth, rpc: make trace configs optional\"\nPlease see the [Developers' Guide](https://geth.ethereum.org/docs/developers/geth-developer/dev-guide)\nfor more details on configuring your environment, managing project dependencies, and\ntesting procedures.\n### Contributing to geth.ethereum.org\nFor contributions to the [go-ethereum website](https://geth.ethereum.org), please checkout and raise pull requests against the `website` branch.\nFor more detailed instructions please see the `website` branch [README](https://github.com/ethereum/go-ethereum/tree/website#readme) or the\n[contributing](https://geth.ethereum.org/docs/developers/geth-developer/contributing) page of the website.\n## License\nThe go-ethereum library (i.e. all code outside of the `cmd` directory) is licensed under the\n[GNU Lesser General Public License v3.0](https://www.gnu.org/licenses/lgpl-3.0.en.html),\nalso included in our repository in the `COPYING.LESSER` file.\nThe go-ethereum binaries (i.e. all code inside of the `cmd` directory) are licensed under the\n[GNU General Public License v3.0](https://www.gnu.org/licenses/gpl-3.0.en.html), also\nincluded in our repository in the `COPYING` file."}
{"url":"https://aave.com/docs/aave-v4/positions/withdraw","domain":"aave.com","title":"Withdraw Assets | Aave Protocol Documentation","hash":"19ea340de0837b35d5ed4ab164ef4cd13ffe986bd83d7a14d959826e06127206","tokens":2556,"chars":10224,"crawler":"hive-genesis","verified":"unchecked","ts":1791112041053,"text":"Docs\nWithdraw Assets # Copy\nLearn how to withdraw assets from your Aave v4 supply positions.\nWithdraw supplied assets from your Aave v4 positions to access your funds and any earned interest.\nWithdrawing assets while having an open borrow position may reduce the\ncollateralization ratio and lower the position's health factor. In some cases,\nthis may put the position at risk of being liquidated.\nWithdrawing # Copy\nWithdrawing can be broken down into the following steps:\n-\nIdentify the supply position to withdraw from\n-\nPreview the impact of the withdraw operation\n-\nWithdraw the assets\nIdentify the Supply Position # Copy\nGiven a list of user's supply positions , identify the supply position matching the token you want to withdraw and with a withdrawable amount that covers your needs.\nThe supplied position reserve should not be paused in order to withdraw from\nit.\nFor example, letâs say you have identified the following UserSupplyItem object.\nExample UserSupplyItem\nconst supplyPosition : UserSupplyItem = { reserve : { id : \"SGVsbG8h\" , onChainId : \"42\" , chain : { chainId : 1 , name : \"Ethereum\" , } , spoke : { address : \"0x123âŠ\" , // ⊠} , asset : { underlying : { address : \"0xa0b86a33e6e2ad05ad6c9ac3b6e5e5f6e7b6c1b2\" , // USDC } , // ⊠} , status : { paused : false , } , // ⊠other reserve properties } , isCollateral : true , balance : { amount : { value : BigDecimal ( 1042.5 ) , // principal + accrued interest // ⊠} , // ⊠} , withdrawable : { amount : { value : BigDecimal ( 1000.0 ) , // 1,000 USDC supplied // ⊠} , // ⊠} , // ⊠} ;\nKeep in mind that if the asset is used as collateral ( isCollateral: true ), withdrawing may:\n-\nReduce your borrowing capacity and lower the positionâs health factor, increasing the risk of liquidation.\n-\nIf the collateral has a reserve.settings.collateralRisk greater than 0, lower the borrow APY on any open borrow positions in the same Spoke, effectively making those positions cheaper to maintain.\nPreview Withdraw # Copy\nPreview the impact of a withdraw operation before committing to it.\n- React\n- TypeScript\n- GraphQL\n- Solidity\nUse the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the withdraw operation on the user's position.\nimport { type WithdrawRequest , usePreview } from \"@aave/react\" ;\nfunction WithdrawPreview ( { request } : { request : WithdrawRequest } ) { const { data , error , loading } = usePreview ( { action : { withdraw : request , } , } ) ;\nif ( loading ) return < div > Loading⊠; if ( error ) return < div > Error: { error . message } ;\n// data: PreviewUserPosition return ( < div > < h3 > Health Factor: < p > From: { data . healthFactor ?. current ?? \"N/A\" } < p > To: { data . healthFactor ?. after ?? \"N/A\" } \n< h3 > User Risk Premium: < p > From: { data . riskPremium . current . normalized . toFixed ( 2 ) } % < p > To: { data . riskPremium . after . normalized . toFixed ( 2 ) } % \n< h3 > Net APY: < p > From: { data . netApy . current . normalized . toFixed ( 2 ) } % < p > To: { data . netApy . after . normalized . toFixed ( 2 ) } % \n< h3 > Net Collateral: < p > From: { data . netCollateral . current . value . toDisplayString ( 2 ) } < p > To: { data . netCollateral . after . value . toDisplayString ( 2 ) } ) ; }\nWhere the WithdrawRequest can be as follows:\nconst request : WithdrawRequest = { sender : evmAddress ( \"0x789âŠ\" ) , // User's address reserve : supplyPosition . reserve . id , amount : { erc20 : { value : { exact : bigDecimal ( 500 ) , // 500 USDC } , } , } , } ;\nThe PreviewUserPosition shows the impact of the withdraw operation by comparing current and after states, with the table below outlining key fields and how to interpret them.\nField Impact\nhealthFactor.[current â after]: BigDecimal|null Higher is better\n( null if not applicable)\nriskPremium.[current â after]: PercentNumber Lower is better\nnetApy.[current â after]: PercentNumber Higher is better\nnetCollateral.[current â after]: ExchangeAmount Higher is better\nnetBalance.[current â after]: ExchangeAmount Updated balance\nmaxBorrowingPower.[current â after]: ExchangeAmount Maximum borrowing power\nremainingBorrowingPower.[current â after]: ExchangeAmount Remaining borrowing power\notherConditions: UserPositionConditionVariation[] Dynamic config changes\nWithdrawing collateral updates the Dynamic Config within the same user position.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\n-\nCollateralFactorVariation â Collateral factor change\n-\nLiquidationFeeVariation â Liquidation fee change\n-\nMaxLiquidationBonusVariation â Maximum liquidation bonus change\nYou can also specify a different currency to return fiat amounts in.\nimport { Currency } from \"@aave/react\" ;\nconst { data , error , loading } = usePreview ( { action : { withdraw : request , } , currency : Currency . Eur , } ) ;\nStep-by-Step # Copy\nNow that we know how to preview the impact of a withdraw operation, let's see how to withdraw assets from a supply position.\nWithdrawing collaterals while having an open borrow position is a\nrisk-increasing action and will update the Dynamic\nConfig , which in turn updates the\nUser Risk Premium for the given position.\n- React\n- TypeScript\n- GraphQL\n- Solidity\nTo withdraw assets from an Aave supply position with AaveKit React, follow these steps.\n1\nConfigure Wallet Integration # Copy\nFirst, instantiate the useSendTransaction hook for the wallet library of your choice .\nViem\nimport { useWalletClient } from \"wagmi\" ; import { useSendTransaction } from \"@aave/react/viem\" ;\n// âŠ\nconst { data : wallet } = useWalletClient ( ) ; const [ sendTransaction ] = useSendTransaction ( wallet ) ;\n2\nDefine the Withdraw Flow # Copy\nThen, use the useWithdraw hook to prepare the withdraw operation.\nimport { useWithdraw } from \"@aave/react\" ;\nconst [ withdraw , { loading , error } ] = useWithdraw ( ( plan ) => { switch ( plan . __typename ) { case \"TransactionRequest\" : return sendTransaction ( plan ) ;\ncase \"PreContractActionRequired\" : return sendTransaction ( plan . transaction ) ; } } ) ;\n3\nExecute the Withdraw Operation # Copy\nThen, execute the desired withdraw operation.\nimport { bigDecimal , evmAddress } from \"@aave/react\" ;\nconst execute = async ( ) => { const result = await withdraw ( { sender : evmAddress ( wallet . account . address ) , // User's address reserve : supplyPosition . reserve . id , amount : { erc20 : { value : { exact : bigDecimal ( 500 ) , // Withdraw 500 USDC } , } , } , } ) ;\n// ⊠} ;\n4\nHandle the Result # Copy\nFinally, handle the result.\nExample\nconst execute = async ( ) => { const result = await withdraw ( /* ⊠*/ ) ;\nif ( result . isErr ( ) ) { switch ( result . error . name ) { case \"CancelError\" : // The user cancelled the operation return ;\ncase \"SigningError\" : console . error ( ` Failed to sign the transaction: ${ result . error . message } ` , ) ; break ;\ncase \"TimeoutError\" : console . error ( ` Transaction timed out: ${ result . error . message } ` ) ; break ;\ncase \"TransactionError\" : console . error ( ` Transaction failed: ${ result . error . message } ` ) ; break ;\ncase \"ValidationError\" : console . error ( ` Invalid withdrawal amount: ${ result . error . message } ` ) ; break ;\ncase \"UnexpectedError\" : console . error ( result . error . message ) ; break ; } return ; }\nconsole . log ( \"Withdraw successful with hash:\" , result . value . txHash ) ; } ;\nAdvanced Usage # Copy\nNetwork Fee # Copy\nThis experimental AaveKit React hook currently works only with Viem or Wagmi\nintegrations. Support for additional wallet libraries may be added later.\nEstimate the network cost of any action using the same PreviewAction you pass to the usePreview hook.\nLet's consider the following example:\nPreviewAction\nimport { type PreviewAction } from \"@aave/react\" ;\nconst action : PreviewAction = { withdraw : { sender : evmAddress ( \"0x123âŠ\" ) , // User's address reserve : supplyPosition . reserve . id , amount : { erc20 : { value : { exact : bigDecimal ( 42 ) , // USDC } , } , } , } , } ;\nUse the useNetworkFee hook to estimate both the network fee for the provided action and its fiat equivalent.\nViem\nimport { type PreviewAction , Currency } from \"@aave/react\" ; import { useNetworkFee } from \"@aave/react/viem\" ;\nfunction NetworkFee ( { action } : { action : PreviewAction } ) { const { data : fee , loading , error , } = useNetworkFee ( { query : { estimate : action } , currency : Currency . Eur , } ) ;\nif ( loading ) return < p > Loading fee⊠; if ( error ) return < p > Error: { error . message } ;\nreturn ( < p > Network Fee: { fee . amount . value . toDisplayString ( 2 ) } { fee . token . info . symbol } < span > â { fee . exchange . symbol } { fee . exchange . value . toDisplayString ( 2 ) } ) ; }\nNative Tokens # Copy\nWhen the Reserve's underlying token is the wrapped version of the chain's native token (e.g., WETH on Ethereum), you can withdraw the asset as the chain's native token using the Native Token Gateway.\nUse the reserve.asset.underlying.isWrappedNativeToken flag to determine if the underlying token is a wrapped native token. The Native Gateway address is available from the chain details.\nWETH Supply Position\nconst supplyPosition : UserSupplyItem = { reserve : { id : \"SGVsbG8h\" , onChainId : \"42\" , asset : { underlying : { address : \"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2\" , info : { name : \"Wrapped Ether\" , symbol : \"WETH\" , decimals : 18 , // ⊠} , isWrappedNativeToken : true , // ⊠} , // ⊠} , spoke : { address : \"0x123âŠ\" , // ⊠} , chain : { chainId : 1 , name : \"Ethereum\" , nativeGateway : \"0xabcâŠ\" , } , // ⊠} , balance : { amount : { value : BigDecimal ( 1.25 ) , // ⊠} , // ⊠} , // ⊠} ;\nSpecify the amount in the amount field as a native value.\n- React\n- TypeScript\n- GraphQL\n- Solidity\nconst execute = async ( ) => { const result = await withdraw ( { sender : evmAddress ( wallet . account . address ) , // User's address reserve : supplyPosition . reserve . id , amount : { native : { exact : bigDecimal ( 1 ) , // Withdraw 1 ETH } , } , } ) ;\n// ⊠} ;\nPrevious\nBorrow Assets\nNext\nRepay Loans"}
{"url":"https://docs.phantom.com/phantom-mcp-server/openclaw-plugin","domain":"docs.phantom.com","title":"OpenClaw Plugin - Phantom developer documentation","hash":"ac5dd0b4cf9929ebe63484942aceca55c82f5f29105d0f81e5e6d49fac849df3","tokens":1080,"chars":4319,"crawler":"hive-genesis","verified":"unchecked","ts":1791112042810,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPhantom developer documentation home page\nGet started\nPhantom MCP server\nPhantom CLI\nPhantom Portal\nPhantom Connect SDKs\nRecipes\nDeveloper tools and resources\nSetup and reference\nOpenClaw Plugin\nInstall the Phantom OpenClaw plugin to give OpenClaw agents direct Phantom wallet capabilities\nThe 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.\nInstall\nInstall the plugin:\nopenclaw plugins install @phantom/phantom-openclaw-plugin\nIf you are testing a local checkout instead of the published package:\nopenclaw plugins install -l /absolute/path/to/packages/phantom-openclaw-plugin\nEnable 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}\nIf you already have other plugins configured, add phantom-openclaw-plugin to your existing allow array and entries object.\nOptional: 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}\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.\nAuthenticate on first use\nAfter installing and enabling the plugin:\n- Restart OpenClaw.\n- Ask the agent to perform a wallet action such as What are my Phantom wallet addresses?\n- OpenClaw will trigger Phantomâs browser-based authentication flow.\n- Sign in, approve the wallet session, and return to OpenClaw.\nThe session is stored locally and reused across restarts until it is deleted or expires.\nWhat the plugin exposes\nThe plugin wraps the Phantom MCP server and exposes the same wallet tool surface inside OpenClaw, including:\n- get_connection_status\n- get_wallet_addresses\n- get_token_balances\n- send_solana_transaction\n- send_evm_transaction\n- sign_solana_message\n- sign_evm_personal_message\n- sign_evm_typed_data\n- simulate_transaction\n- get_token_allowance\n- transfer_tokens\n- buy_token\n- portfolio_rebalance\n- phantom_login\n- pay_api_access\n- The 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 )\nSee the tool reference for the current tool behavior and parameters.\nNotes\n- No manual MCP server wiring is required inside OpenClaw.\n- The plugin uses Phantomâs authentication flow automatically.\n- Transaction sends and transfers use simulation-first flows where supported. Review the preview before approving execution.\nTroubleshooting\nPlugin loads but Phantom tools do not appear\n- Confirm the plugin is present in both plugins.allow and plugins.entries .\n- Verify the entry is enabled: \"enabled\": true .\n- Restart OpenClaw after config changes.\nAuthentication does not start\n- Trigger a wallet action such as get_wallet_addresses .\n- Ensure the machine can open a browser window.\n- Check that OpenClaw is using the expected installed plugin copy if you are testing a local path install.\nConfig invalid for phantom-openclaw-plugin\n- Make sure the installed plugin copy matches the version of the manifest you expect.\n- If you are testing a local path install, reinstall or resync the plugin so OpenClaw validates against the current manifest.\nRelated\nPhantom MCP Server setup\nStandalone MCP server setup for Claude Desktop, Cursor, and Claude Code\nTool reference\nParameters and behavior for the current Phantom wallet tool surface\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.squads.so/main","domain":"docs.squads.so","title":"Welcome to Squads Multisig | Squads Docs","hash":"d6f1ddf41959f6e68a62dc360cb472e6a3c5d6985363747a09979c589ca653e1","tokens":632,"chars":2528,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112042775,"text":"Squads Docs\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nWelcome to Squads Multisig\nLearn more about Squads and Squads Protocol.\nAbout Squads\nSquads Multisig is a multisig platform to secure and manage Solana assets. With Squads, teams can deploy a multisig in a few clicks, configure it to satisfy their security and organizational requirements, and then use it to manage a wide range of onchain assets such as:\n-\nTreasury;\n-\nProgram upgrade authorities;\n-\nAdmin keys;\n-\nTokens;\n-\nand Validators.\nWith Squads, our goal is to bring a traditional SaaS-like product experience to onchain asset management in a way that feels familiar and intuitive to both traditional and crypto-native businesses.\nSquads achieves this by solving three core problems when it comes to managing onchain assets:\n-\nUser experience - We have transformed a lot of the experiences that previously required developers to interact with the CLI into well-designed user flows all contained within an intuitive interface.\n-\nSecurity - Squads is built on top of Squads Protocol, Solana's autonomous finance layer. Each multisig's rules, security and workflows are enforced by Squads Protocol and Solana's 1,000+ global validators, not a centralized exchange, black box algorithm or trusted 3rd-party.\n-\nTransparency - We enhance transparency for teams by giving main stakeholders increased visibility and the ability to approve critical actions for project development. This is achieved by requiring multisig approvals for managing assets, making relevant data accessible and human-readable.\nWe provide teams with greater transparency, allowing for the main stakeholders to have more visibility and a way to approve actions critical for the development of their project by requiring multisig approvals for the management of assets, parsing a lot of the relevant data in our interface and making it human readable.\nSquads Protocol\nSquads Protocol is the autonomous finance layer built on Solana.\nIt replaces legacy banking infrastructure and centralized servers with a blockchain-native operating system â delivering programmable payments, 24/7 USD liquidity, competitive yields, and security enforced by deterministic code, not corporate promises.\nTrusted by over 350 teams and thousands of individuals, Squads Protocol secures more than $10 billion in assets and has processed over $3 billion in stablecoin transfers.\nNext What is a multisig\nLast updated 8 months ago\n- About Squads\n- Squads Protocol"}
{"url":"https://docs.lightning.engineering/","domain":"docs.lightning.engineering","title":"Welcome to the Builder's Guide to the LND Galaxy! | Builder's Guide","hash":"88d0679effb4ccf9f758f66b866094683a966b2c4a0ac9654168805c5c350575","tokens":434,"chars":1734,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112044626,"text":"Builder's Guide\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nWelcome to the Builder's Guide to the LND Galaxy!\nThis repository is designed as a home for those looking to learn about the Lightning Network, use and build on LND, Lightning Terminal, Loop, Pool as well as those developing their own LAPPS.\nStart here if the terms \"payment channel\" and \"hash time-locked contract\" are foreign to you.\nLND\nLook here if you're getting started with LND, want to configure it optimally or learn how to integrate LND into your production environment.\nLightning Terminal\nLightning Terminal is a browser-based, self-hosted dashboard for Lightning Labs products. Read this guide to learn how to set up Lightning Terminal and get the most out of it.\nLoop\nLoop is a service that makes it easier to send and receive funds on Lightning, serving as an on and off ramp between the Lightning Network and the Bitcoin blockchain. Read our guides to Loop to optimally use Loop.\nPool\nPool is a non-custodial marketplace where users can buy inbound liquidity from node operators. Read our guides on how to join Pool as either a buyer or seller.\nTaproot Assets\nTaproot Assets is a protocol for issuing assets on the bitcoin blockchain that can be transferred over the Lightning Network for instant, high volume, low fee transactions.\nL402\nL402 tokens cleverly combine the capabilities of macaroons with that of a Lightning payment, making it easy to charge satoshis for API requests.\nAdditional external resources include our Developer Slack , Github organization , and API documentation, including LND, Loop, Pool, Faraday & Taproot Assets .\nNext Overview\nLast updated 7 months ago\nWas this helpful?"}
{"url":"https://governance.aave.com/latest","domain":"governance.aave.com","title":"Aave - Governance Forum","hash":"9b0865d93707c578ec826f23acde94ebe7dab0044d3786c62c05e45152d8c05a","tokens":662,"chars":2645,"crawler":"hive-genesis","verified":"unchecked","ts":1791112044695,"text":"Aave\nTopic\nReplies\nViews\nActivity\n[Question] Any idea what happened here?\nFinance\n4\n209\nOctober 3, 2026\n[ARFC] The Aave Foundation, Phase 1\nGovernance\n1\n787\nOctober 2, 2026\n[GHO Stewards] October 2026 - GHO Borrow Rate Update\nGovernance\n0\n123\nOctober 2, 2026\n[ARFC] Deploy Aave V4 on the Monad Network\nNew Market\n1\n328\nOctober 2, 2026\nAave Chan Initiative Delegate platform\nDelegate Platforms\n43\n13812\nOctober 2, 2026\n[ARFC] Aave Institutional\nGovernance\n7\n499\nOctober 2, 2026\n[Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\nNew Asset\n1\n111\nOctober 2, 2026\nRisk Stewards: Cap and IRM Changes on Aave V3 / 2026.10.01\nRisk\n0\n81\nOctober 1, 2026\nAL Development Update | September 2026\nDevelopment\n0\n162\nOctober 1, 2026\n[Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\nGeneral\n1\n78\nOctober 1, 2026\n[ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\nNew Market\n2\n675\nOctober 1, 2026\n[ARFC] Aave V4 Activation on Ethereum Mainnet\nGovernance\n50\n7811\nOctober 1, 2026\n[ARFC] Activate Aave Risk Stewards on Aave V4\nGovernance\n7\n519\nSeptember 30, 2026\n[ARFC] Onboard OUSD to Aave V3 Core Instance and Aave V4 Core Hub\nNew Asset\n0\n210\nSeptember 30, 2026\n[Direct-to-AIP] Onboard PT-USDG-25FEB2027 on X Layer\nNew Asset\n0\n66\nSeptember 30, 2026\nRisk Stewards: Supply and Borrow Cap Reductions on Aave V3 / 2026.08.10\nRisk\n2\n178\nSeptember 30, 2026\n[ARFC] Onboard syrupUSDC to Aave V4 on Arc\nGovernance\n2\n172\nSeptember 30, 2026\n[ARFC] Onboard mWIN (Midas / Wellington Management) to Aave Horizon\nHorizon\n9\n563\nSeptember 29, 2026\nSyrup USDC (syrupUSDC) on Aave Arc Assessments\nAssessments\n1\n78\nSeptember 29, 2026\n[TEMP CHECK] Aave Will Win Framework\nGeneral\n135\n17918\nSeptember 29, 2026\nRisk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.28\nRisk\n0\n104\nSeptember 28, 2026\n[ARFC] Deploy Aave V4 on Base\nNew Asset\n7\n1306\nSeptember 25, 2026\n[ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE\nGovernance\n3\n759\nSeptember 25, 2026\n[RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\nGovernance\n0\n102\nSeptember 25, 2026\n[Direct-To-AIP] Umbrella - Renew Allowances\nGovernance\n0\n80\nSeptember 25, 2026\nwstETH borrows enabled\nGovernance\n2\n113\nSeptember 24, 2026\n[RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\nGeneral\n0\n87\nSeptember 24, 2026\nRisk Stewards: Supply and Borrow Cap Changes on Aave V3 / 2026.09.22\nRisk\n1\n166\nSeptember 24, 2026\nHow Aave Stable Vaults work\nDevelopment\n0\n87\nSeptember 24, 2026\nCoinbase B20 Equities on Base Assessments\nAssessments\n1\n147\nSeptember 24, 2026\nnext page â"}
{"url":"https://solana.com/docs","domain":"solana.com","title":"","hash":"bf5695c19f765a0be824e4bbf52667304f93a4347df8e2cee66970a37e709420","tokens":349,"chars":1394,"crawler":"crawler-dfxz","verified":"exact","ts":1791112046233,"text":"---\ntitle: Start Here\nseoTitle: Start building on Solana\ndescription:\nChoose a quickstart, code with an AI agent, or learn how Solana works.\n---\n\nSet up Solana MCP or install the official Solana skill for your coding agent.\n \n## Want to learn how Solana works?\n\nLearn the building blocks that make Solana work.\n \n### Try Solana: Play 2048\nPlay 2048 on Solana, where every move sends a transaction. Click \"Play\" to start\nwith a funded devnet wallet, then use the arrow keys or swipe on mobile.\n\n\n\n \n \nBuilt by [Jonas](https://x.com/SolPlay_jonas), from the Solana Foundation DevRel\nteam."}
{"url":"https://raw.githubusercontent.com/solana-foundation/solana-improvement-documents/main/README.md","domain":"raw.githubusercontent.com","title":"Solana Improvement Documents (SIMDs)","hash":"d47eb0bdc3c3b4488dc05115c0030c3182d95e384a1923887a995ca6476728f2","tokens":545,"chars":2178,"crawler":"hive-genesis","verified":"exact","ts":1791112046216,"text":"# Solana Improvement Documents (SIMDs)\nThe goal of the SIMD project is to standardize and provide high-quality\ndocumentation for Solana and its ecosystem. This repository tracks past and\nongoing improvements to Solana in the form of Solana Improvement Documents\n(SIMDs).\n[SIMD-0001](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0001-simd-process.md)\ngoverns the SIMD process.\n## SIMD Types\nSIMDs can be divided into the following categories:\n- **Standard SIMDs**:\nDescribe changes that affect most or all Solana implementations, such as:\n- **Core**:\nChanges affecting consensus or substantial changes to the validator.\n- **Networking**:\nChanges or substantial improvements to network protocol specifications.\n- **Interfaces**:\nBreaking changes around the client JSON RPC API specifications and standards.\n- **Meta SIMDs**:\nDescribe a process surrounding Solana or propose a change to (or an event in)\na process.\n## Before You Begin\nBefore you write a SIMD, ideas MUST be thoroughly discussed and vetted on the\n[ideas section](https://github.com/solana-foundation/solana-improvement-documents/discussions/categories/ideas)\nwithin this\n[repo's discussion page](https://github.com/solana-foundation/solana-improvement-documents/discussions).\nRead and review [SIMD-0001](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0001-simd-process.md),\nwhich describes the SIMD process in detail.\nThis repository is for documenting standards and not for implementation help.\nFor specific questions and concerns regarding SIMDs, it's best to discuss them\nin the [questions section](https://github.com/solana-foundation/solana-improvement-documents/discussions/categories/questions)\nof this [repo's discussion page](https://github.com/solana-foundation/solana-improvement-documents/discussions).\n## Access Policy\nThe SIMD repository has three levels of access, as detailed in\n[SIMD-0007](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0007-access-policy.md):\n1. Triage\n2. Write\n3. Maintain\nTo request access or report misuse, please follow the procedures outlined in\nSIMD-0007."}
{"url":"https://solana.com/docs/core/cpi","domain":"solana.com","title":"","hash":"92a89596610a5e4f7e2b17e95cc1f0c7af2c1314968517eecbbd66dd50c7a437","tokens":1301,"chars":5203,"crawler":"crawler-dfxz","verified":"exact","ts":1791112048121,"text":"---\ntitle: Cross Program Invocation\ndescription:\nCross Program Invocation (CPI) on Solana â how programs call other programs\nusing invoke and invoke_signed, handle PDA signers, and compose onchain\nfunctionality.\nurl: /docs/core/cpi\ntype: conceptual\nprerequisites:\n- /docs/core/instructions\n- /docs/core/programs\nrelated:\n- /docs/core/cpi/cpi-without-pda\n- /docs/core/cpi/cpi-with-pda\n- /docs/core/pda\n---\nA Cross-Program Invocation (CPI) is when one [program](/docs/core/programs)\ncalls an [instruction](/docs/core/instructions) on another program during\nexecution. CPIs enable composability: any program's instructions can be invoked\nby any other program on the network.\n\n\n\nUsing the invoke function, Anchor CpiContext, Native Rust examples, SOL\ntransfer CPI examples.\n \n\nUsing invoke_signed with signer seeds, Anchor CpiContext with PDA, Native\nRust PDA signing examples.\n \n\n11-step CPI execution flow, privilege extension rules, reentrancy, account\nvalidation.\n\n\nCPI cost formula, serialization costs, account data synchronization, PDA\nsigning, return data.\n\n \n## Key facts\n- **Two functions**: _rs`invoke`_ (no PDA signing) and _rs`invoke_signed`_ (with\nPDA signing).\n- **Privilege extension**: [Account](/docs/core/accounts) privileges (signer,\nwritable) extend from caller to callee. A callee cannot escalate privileges\nbeyond what the caller passed.\n- **Shared compute budget**: A callee's CU consumption reduces the caller's\nremaining budget.\n- **Reentrancy**: Direct self-recursion is allowed (A->A->A). Indirect\nreentrancy is not (A->B->A returns _rs`ReentrancyNotAllowed`_).\n## Limits\n| Limit | Value | Source |\n| -------------------------------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Max instruction stack depth | 5 (9 with SIMD-0268) | [`MAX_INSTRUCTION_STACK_DEPTH`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L8), [`MAX_INSTRUCTION_STACK_DEPTH_SIMD_0268`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L10) |\n| CPI invocation cost | 1,000 CUs (946 with SIMD-0339) | [`DEFAULT_INVOCATION_COST`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L21), [`INVOKE_UNITS_COST_SIMD_0339`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L23) |\n| Max PDA signers per CPI | 16 | [`MAX_SIGNERS`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/cpi.rs#L62) |\n| Max CPI instruction data | 10 KiB (10,240 bytes) | [`MAX_INSTRUCTION_DATA_LEN`](https://github.com/anza-xyz/agave/blob/v3.1.8/transaction-context/src/lib.rs#L33) |\n| Max return data | 1,024 bytes | [`MAX_RETURN_DATA`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/cpi/src/lib.rs#L329) |\n| Max CPI account infos | 128 (255 with SIMD-0339)\\* | [`MAX_CPI_ACCOUNT_INFOS`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/cpi.rs#L122), [`MAX_CPI_ACCOUNT_INFOS_SIMD_0339`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/cpi.rs#L124) |\n| CPI serialization cost | 1 CU per 250 bytes | [`cpi_bytes_per_unit`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L205) |\n| Max account data realloc per CPI | 10,240 bytes (10 KiB) | [`MAX_PERMITTED_DATA_INCREASE`](https://github.com/anza-xyz/solana-sdk/blob/clock%40v2.2.3/account-info/src/lib.rs#L17) |\n## `invoke` vs `invoke_signed`\nSolana provides two functions for making CPIs:\n| Function | Use case | PDA signing |\n| --------------- | ---------------------------------------------------------------------------- | --------------------- |\n| `invoke` | CPIs where all required signers have already signed the original transaction | No |\n| `invoke_signed` | CPIs where the calling program needs to sign on behalf of a PDA it owns | Yes, via signer seeds |\nUnder the hood, _rs`invoke`_ simply calls _rs`invoke_signed`_ with an empty\nsigner seeds array. Use _rs`invoke`_ when you don't need PDA signing, and\n_rs`invoke_signed`_ when the program must authorize an action on behalf of a\nPDA.\nBoth functions ultimately trigger the same syscall\n([`sol_invoke_signed_rust`](https://github.com/anza-xyz/agave/blob/v3.1.8/syscalls/src/cpi.rs#L11-L33))\nand flow through the same runtime path\n([`cpi_common`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/cpi.rs#L802-L925)).\nThe only difference is whether signer seeds are provided. When seeds are\nprovided, the runtime derives PDA pubkeys and adds them to the set of valid\nsigners before privilege checking."}
{"url":"https://docs.getmonero.org/multisignature/","domain":"docs.getmonero.org","title":"Multisignature - Monero Docs","hash":"9e8e0c332153f83821981f0cde2a3af003d7ed0201d9a18fd07b29b6a65c05b5","tokens":5590,"chars":22357,"crawler":"hive-genesis","verified":"unchecked","ts":1791112048582,"text":"Skip to content\nInitializing search\nmonero-project/monero-docs\n- Download & Verify\n-\nMining\n- Pool\n- P2Pool\n- Help\n-\nMonerod\n- Sample Configs\n- Wallets\n- Receiving funds\n- Spending funds\n- Mnemonic Seeds\n- About the experimental feature warning message\n- References\n- Offline Transaction Signing\n- Blockchain Tools\n- External\n- RPC Library\n-\nR&D\n-\nCryptography\n- Base58\n- Keccak-256\n- PRNG\n-\nMnemonics\n-\nProof of Work\n- Wallet Files\n- Receiving funds\n- Spending funds\n- Mnemonic Seeds\n- About the experimental feature warning message\n- References\nMultisignature ¶\nIn cryptocurrencies, multisig allows one to sign a transaction with more than one private key. Funds protected with multisig can only be spent by signing with M-of-N keys.\nExample use cases:\n- shared account (1-of-2; both husband and wife individually have full access to their funds)\n- consensus account (2-of-2; both husband and wife must agree to spend their funds)\n- threshold account (2-of-3; an escrow service is involved as an independent 3rd party, to co-sign with either the seller, or with the buyer, if seller and buyer do not agree)\n- secure account (2-of-3; a single owner controls all 3 keys but secures them via different means to diversify risks)\n- arbitrary threshold account (M-of-N; some cryptocurrencies provide full flexibility on the number of signers)\nMonero's multisig design ¶\nMonero doesn't directly implement multisignatures (at least not in a classical sense). Monero emulates the feature by secret splitting.\nTransactions are still signed with a single spend key. The spend key is a sum of all N private keys. The rationale for such a design is to decouple multisig from ring signatures.\nLet's consider the 2-of-3 scheme. We have 3 participants. Each participant is granted exactly 2 private keys in a way that pairs do not repeat between participants. This way any 2 participants together have all 3 private keys required to create the private spend key.\nMulti-signing is a wallet-level feature, and there is no separate multisig address type. This means there is no way to learn from the blockchain which transactions were created using multiple signatures.\nAfter multisig wallet setup every participant ends up knowing the public address and private view key. This is necessary for participants to recognize and decipher transactions they are supposed to co-sign.\nMultisig wallet setup ¶\nMultisig is currently only available via the Command Line Interface (CLI). This tutorial will assume you have some familiarity with the CLI before beginning.\nIn this example we will use a 2-of-3 multisig scheme, as it generalizes well.\nInitially, while you're becoming familiar with multisig, it's suggested you begin by using stagenet , such that no valuable Monero are lost.\nIf you're not already familiar with stagenet, it is a separate, but functionally identical instance of the Monero network, created for testing purposes. To use it you simply add the --stagenet flag when creating and running your stagenet wallet.\n1: Create a new wallet ¶\nTo begin you will need to create a new wallet. Multisig cannot be applied to a wallet that has previously received funds.\nFirst you create a new wallet. The below the code assumes you're using a remote node, but using a local node is ideal:\n./monero-wallet-cli --stagenet --daemon-address address-URL # Create your wallet\nIn the above, replace address-URL with the actual URL that you want to connect to. At the time of writing, a list of remote nodes can be found at: monero.fail . The default view shows mainnet servers, so make sure to filter by stagenet servers first.\nNext, enable multisig via:\nset enable-multisig-experimental 1\nIf you try to issue the first command without first setting this flag, you will see:\nError: Multisig is disabled.\nError: Multisig is an experimental feature and may have bugs. Things that could go wrong include: funds sent to a multisig wallet can't be spent at all, can only be spent with the participation of a malicious group member, or can be stolen by a malicious group member.\nError: You can enable it with:\nError: set enable-multisig-experimental 1\nThis warning message is there to let people know that Multisig is still an experimental feature and may have bugs. You can read more about this message below.\nRecommendation: By default the CLI applies a screen timeout of 90 seconds. After which, you will be asked to input your password to continue using the wallet. Unfortunately, once the wallet times out, it interrupts the multisig creation process.\nTo extend the timeout to 10 minutes, use the command:\nset inactivity-lock-timeout 600\nTo disable the timeout entirely (for this session only), use the command:\nset inactivity-lock-timeout 0\n2: prepare_multisig ¶\nTo begin, every participant independently generates initialization data , which is not an address.\nParticipants then send their initialization data manually to all other participants over a secure channel.\nHowever, if you're creating the multisig wallet without external participants, then you simply transfer the data between terminal windows.\nBegin by using the command:\nprepare_multisig\nNote: if you try to use this command on a wallet that has already been used, you will see the error message:\nError: This wallet has been used before, please use a new wallet to create a multisig wallet\nAfter prepare_multisig you will see a message that looks similar to the below:\nMultisigxV2R1C9Bd2LNS9oDXLwDWbVbWc53nfUJpFnQqPDDtHksVVrY33DADgnhKetL5Swgk477uP1AENAy2pz11zW73NGqZojTai2TSDyARK3QR8uVt1t26oW21mFdZtd8iuNqTPBjuCc2q9jaRzqUG75rXtnn8eD5DwJX6NaMP63o2n2fta7dXZcpM\nSend this multisig info to all other participants, then use make_multisig [...] with others' multisig info\nThis includes the PRIVATE view key, so needs to be disclosed only to that multisig wallet's participants\nThe long string that begins Multisig is important, and will be shared with the other wallets in the next step.\nBefore you move to the next step, you'll want to run the prepare_multisig command on the rest of the wallets you want to use in your multisig setup. For example, 2 more if you're doing a 2/3 multisig.\n3: make_multisig ¶\nThis command is where you set the threshold for your multisig wallet and then pass the initialization data from the other participants. The initialization data is the long string beginning Multisig mentioned above.\nFor example, if you're doing a 2 of 2 multisig, then your threshold is 2 and you'll pass 1 piece of data. If you're doing a 3 of 5 multisig, then your threshold is 3 and you'll pass 4 pieces of data.\nContinuing with our 2/3 multisig example, you would then type into your CLI:\nmake_multisig 2 \nWhich in practice would look similar to:\nmake_multisig 2 MultisigxV2R1MyhE1hgED7AFwytsfW44s7G4abNHFKhwfJH9kvB2Q7xNVBdJAyY9gm7eJkHVRo1T3Hb6PeYsyzUrqQsmpBByDq4iRywanpRLxLN2JKuvKPBDayAywAHBzGxdnGiyoXhLdnZiU6Azy3VNocwH1jgfFvYDUUCo7H8mFacnLUFVLC8LjEfz MultisigxV2R1CzwgGBTPxb51nWfvLg7mYPRBnqDgppZq85E745qR1NvGNCLBaHSCmUQ4JRb41tW9PUerAgz9pKHJ5NpKgE6vsZnpLJkCP3u4zwcXJW3UHjABc446jdQegP1hyHnGgJpah8RmdeLcLCAqa6WXgt3xJoz6QF5o66tnCiyJkYyebjWeXV2y\nIf you were doing a 3/5 multisig, you'd instead run:\nmake_multisig 3 \nOnce this command is run on each wallet, you will then receive a second round of initialization data, that looks similar to:\nAnother step is needed\nMultisigxV2Rn1LVYohry597ZfzPhWnuL6qcueBNdq4ivrP7zqDm4W5eKBhxgdcERcSvFs8F5EkLSuYFyKfBEeh4Fui6xHTeRqb7cWshXY96WruxMaSxMafTdPn48ko52e8UHvA4kWwpuPidBYg5dyVWoQLWgqCMDANxWnjhenw6HTwpT96yB8n1a16oQEYyQWg66r2sZHi9RMmivTsihnMq66rTHKPKKau1SHButDwQ\nSide note: If you make a mistake, such as inputting the wrong threshold or missing out some initialization data, there isn't an undo function. That individual wallet will get created incorrectly, and you will need to re-do it.\n4: exchange_multisig_keys ¶\nWith the threshold established in the prior command, the exchange_multisig_keys command simply takes the init data from the other participants, no threshold parameter needed.\nFor example:\nexchange_multisig_keys \nIt is either run once or twice in total.\nOnce if your wallet has the same threshold as the total number of participants, e.g. 2 of 2.\nTwice if you have a different threshold, e.g. 2 of 3.\nContinuing our 2/3 multisig example, after inputting the above exchange_multisig_keys command, we would then see:\nAnother step is needed\nMultisigxV2Rn1WCSNqbsjuTXaPVfFsk3ekFF444yFN5PMCXcQHv1Pv794ZdkDZRnfVGgeP5JwpysR3ingQtQMMnmQDEXnP4qgdnh3SU2NXvfe7kMaSxMafTdPn48ko52e8UHvA4kWwpuPidBYg5JdJwdEAh8Ud7kBFX34zP33ZBbrYXcQbQKTcM3XQ8AEP8bVXHVqQSGzkAkjZRp3H63k6ZSXSYdH9WaC9pdr9FV3tx\nSend this multisig info to all other participants, then use exchange_multisig_keys [...] with others' multisig info\nThen for a second, and last time, we input:\nexchange_multisig_keys \nAnd we receive back:\nMultisig wallet has been successfully created. Current wallet type: 2/3\nMultisig address: 56MD1L4zky3bFXDQb9qvSx7PDbg8F4x1HgPrFNrDnGnYDqFZcWGswWc1p2moFa1F44ccJniY9Wkzk6urkJbEDvubHqYtkcs\nThis results in a wallet public address and private view key to be known for all participants.\nSo if you're the sole participant in the multisig setup, you'll know it has worked when you see the same multisig address across all the wallets.\nReceiving funds ¶\n1: Funding the Multisig Account ¶\nAddresses created by a multisig wallet operate the same as normal, non-multisig addresses. This means:\n-\nEach wallet can create subaddresses independently, no collaboration needed.\n-\nAll participants can see incoming funds as they share the private view key.\nThe main difference comes when trying to spend funds from a multisig wallet. See the Spending Funds section below for how to do this.\n2: Check Account Balance ¶\nTo check the account balance, open one of the multisig wallets and type the refresh command.\nThis will refresh the wallet and display your balance. The output will look similar to the below, but with a different amount:\nStarting refresh...\nRefresh done, blocks received: 0\nCurrently selected account: [0] Primary account\nTag: (No tag assigned)\nBalance: 10.000000000000, unlocked balance: 10.000000000000 (Some owned outputs have partial key images - import_multisig_info needed)\nIf you see that last sentence:\n(Some owned outputs have partial key images - import_multisig_info needed)\nThis means that you haven't synchronized your wallet with the threshold amount of wallets needed (1 other in the case of 2/3 multisig) for the outputs to become spendable.\nYou can also use the command show_transfers to display a list of funds received and the transfer date, with the output looking similar to:\n1263592 in unlocked 2023-01-09 21:13:59 10.000000000000 c5a3eec347401b1e263f45577b840c036568aa841eb2ebc6eb1332c1bc281f28 0000000000000000 0.000000000000 76Matb:10.000000000000 1 -\nSpending funds ¶\nPrior to explaining the process for spending multisig funds, it may help to have a high level overview of the process. There are two core steps:\n1) First, the sharing of partial key-images - At minimum, the spender needs to get a partial key image from the people (1 or more) who will sign the transaction with him later. They need to export a file and share it with the future spender, who then imports the file to their wallet.\n2) Second, creating, signing & submitting the transaction - A transfer is created, written to file, and then this file needs to be signed by the co-signers, before it can lastly be submitted to the network.\nPreparation for spending ¶\nPreparation Step 1: Export partial key image\nPrior to constructing a transaction, the spender will need to get a partial key image from the wallet or wallet s which will later co-sign the transaction.\nIn our 2/3 multisig example, the spender needs to get 1 partial key image, because the threshold is 2.\nThe wallet that will provide the partial key image needs to enter the command:\nexport_multisig_info key1\nWhere key1 can be any filename. The output will then be:\nMultisig info exported to key1\nThe file will be saved to the present working directory in the terminal.\nIt then needs to be shared with the wallet which will create the spending transaction.\nPreparation Step 2: Import partial key image\nNow that the spending wallet has the partial key image it can import it. Assuming the file is in the present working directory, the command would be:\nimport_multisig_info key1\nIf two or more key images were being imported, you would specify them side by side, such as:\nimport_multisig_info key1 key2 key3\nAfter issuing that command, the wallet will display how many new inputs it has verified, for example if 1 output is verified:\nHeight 1263592, txid , 10.000000000000, idx 0/1\nMultisig info imported. Number of outputs updated: 1\nSpending ¶\nSpending Step 1 - Create Unsigned Transaction\nCreating a new transaction can be done by any of the multisig wallets. However, to avoid weird things from happening, only do it for 1 transaction at a time. If anything weird happens, re-do steps 1 & 2 again to fix.\nThe wallet initiating the transfer should create a transfer, as per the normal CLI transfer process:\ntransfer \nSo for example:\n[wallet 56MD1L]: transfer 72Qv1pqug5rX1qS77Bj9C4XBbrvdYRJLM6769bseDytqVZWV2iQxGDnZ85KmubdiCQgtZjeb4fPdUNGq8Foae5b1Bo77T64 5\nWallet password:\nTransaction 1/1:\nSpending from address index 1\nSending 5.000000000000. The transaction fee is 0.000167640000\nIs this okay? (Y/Yes/N/No): Yes\nThe output will look like:\nUnsigned transaction(s) successfully written to file: multisig_monero_tx\nThe present working directory will now contain a file named multisig_monero_tx , which should then be shared with the co-signer.\nSpending Step 2 - Sign Transaction\nThe wallet that has been chosen to co-sign the transaction now needs to run the command:\nsign_multisig multisig_monero_tx\nWhich will result in an output similar to:\nLoaded 1 transactions, for 10.000000000000, fee 0.000167640000, sending 5.000000000000 to 72Qv1pqug5rX1qS77Bj9C4XBbrvdYRJLM6769bseDytqVZWV2iQxGDnZ85KmubdiCQgtZjeb4fPdUNGq8Foae5b1Bo77T64, 4.999832360000 change to 56MD1L4zky3bFXDQb9qvSx7PDbg8F4x1HgPrFNrDnGnYDqFZcWGswWc1p2moFa1F44ccJniY9Wkzk6urkJbEDvubHqYtkcs, with min ring size 16, dummy encrypted payment ID. Is this okay? (Y/Yes/N/No): y\nTransaction successfully signed to file multisig_monero_tx, txid 82132a4302188b15c87916c05df79755dafb9ada78c39164937c246a4c2dee0a\nIt may be relayed to the network with submit_multisig\nNote: Once you synchronize the partial key images, there is a certain time window by which you can create and send your transaction. I'm unsure exactly how long the time window is. If you leave it too long you will see the output:\nError: Multisig error: This signature was made with stale data: export fresh multisig data, which other participants must then use\nThe solution is to re-do steps 1 and 2 of the preparation for sending. Once that's completed, you can return to the sending steps.\nSpending Step 3 - Submit Transaction\nNow that your transaction has been co-signed, it is possible to submit it. You can do this from any of the wallets, as long as they have the co-signed multisig_monero_tx file. Using the command:\nsubmit_multisig multisig_monero_tx\nYou will then see an output similar to:\n[wallet 56MD1L]: submit_multisig multisig_monero_tx\nWallet password:\nLoaded 1 transactions, for 10.000000000000, fee 0.000167640000, sending 5.000000000000 to 72Qv1pqug5rX1qS77Bj9C4XBbrvdYRJLM6769bseDytqVZWV2iQxGDnZ85KmubdiCQgtZjeb4fPdUNGq8Foae5b1Bo77T64, 4.999832360000 change to 56MD1L4zky3bFXDQb9qvSx7PDbg8F4x1HgPrFNrDnGnYDqFZcWGswWc1p2moFa1F44ccJniY9Wkzk6urkJbEDvubHqYtkcs, with min ring size 16, dummy encrypted payment ID. Is this okay? (Y/Yes/N/No): y\nTransaction successfully submitted, transaction <82132a4302188b15c87916c05df79755dafb9ada78c39164937c246a4c2dee0a>\nYou can check its status by using the `show_transfers` command.\nThe transaction has now been broadcast to the network. If you want to create another one, you will need to go back to the preparation stage and re-sync the partial key images.\nSpending concerns ¶\nIn a multisig wallet constructed between untrusted parties, it is possible for a single malicious signer to trick other signers into sending a payment twice. For most uses this is not a concern ; common exempt uses include a single person controlling a multisig, or a 2 of 2 multisig in a decentralized exchange which only has to send all funds once. If you are operating a multisig with other holders for repeat transfer of funds, however, you should be aware of the following issue, illustrated by example (no fees for simplicity):\n- A 3 of 3 multisig is created between signers 1, 2, and 3\n- The multisig owns two outputs A and B, both size 1 XMR\n- Signer 1: \"I want to withdraw 1 XMR to my address X\". 2 and 3 agree\n- Signer 2 is selected to begin signing the transaction. 2 constructs the transaction sending output A -> X\n- Signer 3 signs, the transaction now has 2/3 signatures\n- Signer 1 signs, the transaction has 3/3 signatures and is valid and can be broadcasted to the network\n- Signer 1 does not broadcast the A -> X transaction. 1 lies and says he could not sign. He claims he got the error This signature was made with stale data .\n- Signer 1 says \"We should do it again, it didn't work\"\n- Signer 1 constructs the transaction sending B -> X\n- Signer 2 and 3 sign, 3 broadcasts B -> X\n- Signer 1 broadcasts the withheld A -> X transaction\n- Signer 1 has drained all the funds!\nThe withheld transaction will succeed because it does not conflict with the B -> X transaction as it spends a different input. As a holder, you should only ever sign for a given transfer once in normal multisig operation. If the signature fails due to the stale data error or any other reason, you must re-check the inputs of the transaction and make sure they are the same, which prevents a hidden transaction being respent. Viewing the inputs is not currently possible in any user wallet, but can be done with the wallet RPC method describe_transfer . If the inputs do not match the first transaction, do not sign the second transaction.\nThis is possible in other cryptocurrencies, but is more feasible in Monero because of the stale data error mentioned earlier, which provides an excuse for why the transaction failed. Work is in progress to reduce the chance of encountering the stale data error and remove this excuse. Other cryptocurrencies' technical user wallets sometimes display inputs, which can help you examine transactions more easily, but for Monero this is not yet the case, and you have to use the wallet RPC.\nMnemonic Seeds ¶\nWith a regular wallet is it possible to create a mnemonic seed that you can back up, and later use to recreate the wallet.\nFortunately, multisig wallets have the same feature. The only difference is that the seed is a long string of letters and numbers, rather than a set of dictionary words. Unfortunately, it needs to encode too much data to fit neatly into the regular mnemonic seed dictionary output.\nTo access your wallet seed, open the wallet within the CLI and type seed . You will see an output similar to this:\nNOTE: the following string can be used to recover access to your wallet. Write them down and store them somewhere safe and secure. Please do not store them in your email or on file storage services outside of your immediate control.\n020000000300000051512b513c603a023df44e2400ad58b3f4751e2dcba44b1d4316be5adffd330b773b3818a07ab6ccc4ffcee1feed5526296b52f5ea0844eb8562cb3e63e8154c5c91f0cfd102a830d8692cec64e662f7ffac4cb82dd950c891a92a22dc80930ab78dd01a1ec7ed04d90eff530d2af9d4e40670576863492357727c6615620e95d2e962632518d958040b710474a4c944cb3a286e3fe9ad0b1d651ff6d8b4c50c81a74423650210bbcb7b427435e90b3eb494cb108bd148cab56e5352303d55070d35e703217b7b051a96af50c1c912bc372f65a4ffa93631ae009a544106bd5dfcf477573387f159ce6cae10fb2ffe63f55e75ed94d0893ece9b67b0a1cf0fc2034ca04ef7c862494a13237bfaa8e822f824ea59de561353f2ac01fbc279280c\nNote: This seed will only recreate the individual wallet it is created from. Each wallet would need to be backed up separately.\nAbout the experimental feature warning message ¶\nPrior to a pull request in mid 2022 ( PR #8149 ) Monero's multisig feature had some known bugs.\nPR #8149 fixed these issues, including findings identified by an independent audit of multisig.\nHowever, there is still a possibility of a yet unknown bug that would allow a malicious group member, in a worst-case scenario, to acquire all funds within the multisig wallet.\nTwo potential steps to get Monero's multisig implementation further tested and more secure would be the completion of a formal specification and a third-party audit. However, there is currently no timeline for this.\nIt's worth noting that the risks implied by this unknown bug scenario depend upon the individual use-case. For example:\na) If one planned to use multisig in collaboration with other people, then this risk is there.\nb) If one planned to use multisig solely to shard a cold wallet, and store it in multiple locations, then this risk may be lessened. On the basis that it requires two coincidences to come together:\ni) A malicious actor who has the capability to exploit an unknown bug in Monero's multisig.\nii) This malicious actor is then able to access one of the, presumably secured, multisig wallets.\nHowever, if an exploit was made public knowledge, then the risk increases, because the attacker no longer needs to figure out the exploit, they simply need to locate your wallet and then implement the public exploit.\nThus, if one took the risk to use multisig in method b), they would be prudent to stay up to date on multisig development. Such that they would learn quickly if such an exploit was discovered.\nReferences ¶\nThe below guides are very detailed, and were formative in the creation of this document. Note that they are both a little out of date, as a few of the CLI commands have been updated in the interim.\n- https://monero.stackexchange.com/questions/5646/how-to-use-monero-multisignature-wallets-2-2-2-3\n- https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/23-multisig-in-cli-wallet"}
{"url":"https://docs.optimism.io/notices","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"24ca819f17ef48235809a960b135a87aee2a1bd2a35b3a8d9b7a4a6aedae0dd0","tokens":383,"chars":1532,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112049893,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOptimism Documentation home page\nGet Started\nChain Operators\nNode Operators\nApp Developers\nProtocol\nOP Mainnet\nGovernance\nNotices\nNetwork Notices\nActive upgrade notices, deprecations, and network change announcements for OP Stack operators.\nNotices are time-bound action items for application developers, node operators, and chain operators: upcoming\nnetwork upgrades, deprecations, and operational changes. Each hardfork also\nhas a permanent entry in the\nhardfork registry recording its\nactivation times, governing spec, and minimum component versions, and\ncontract-only upgrades are listed in the registryâs\ncontract upgrades table â\nnotices are archived after activation, registry pages are forever.\nNetwork upgrades\nUpgrade 20\nPrepare Fault Proof services for Super Root Dispute Games and other maintenance smart contract upgrades\nInterop Activation Prep\nOP Sepolia and Unichain Sepolia interop activation preparation\nOperations\nSpecialized Node Topology\nGuidance for Supernode and Light CL node topology\nSubblocks: 200 ms interval and payload changes\nA 200 ms subblock interval and four zeroed stream payload fields on OP Sepolia and OP Mainnet\nPreconfirmation Architecture Transition\nOP Labs is ending support for the Flashblocks stack; Subblocks is the supported path\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.openzeppelin.com/contracts/5.x/erc4626","domain":"docs.openzeppelin.com","title":"ERC-4626 | OpenZeppelin Docs","hash":"4647ab726c629de55665b7ce8bae6a8ece2fc436bfc0d57e02839ec8aa672d0c","tokens":3545,"chars":14179,"crawler":"hive-genesis","verified":"unchecked","ts":1791112050236,"text":"Home Forum Website Impact\nOpenZeppelin Contracts Tokens\nERC-4626\nOpen in Claude\nERC-4626 is an extension of ERC-20 that proposes a standard interface for token vaults. This standard interface can be used by widely different contracts (including lending markets, aggregators, and intrinsically interest bearing tokens), which brings a number of subtleties. Navigating these potential issues is essential to implementing a compliant and composable token vault.\nWe provide a base implementation of ERC-4626 that includes a simple vault. This contract is designed in a way that allows developers to easily re-configure the vaultâs behavior, with minimal overrides, while staying compliant. In this guide, we will discuss some security considerations that affect ERC-4626. We will also discuss common customizations of the vault.\nSecurity concern: Inflation attack\nVisualizing the vault\nIn exchange for the assets deposited into an ERC-4626 vault, a user receives shares. These shares can later be burned to redeem the corresponding underlying assets. The number of shares a user gets depends on the amount of assets they put in and on the exchange rate of the vault. This exchange rate is defined by the current liquidity held by the vault.\n- If a vault has 100 tokens to back 200 shares, then each share is worth 0.5 assets.\n- If a vault has 200 tokens to back 100 shares, then each share is worth 2.0 assets.\nIn other words, the exchange rate can be defined as the slope of the line that passes through the origin and the current number of assets and shares in the vault. Deposits and withdrawals move the vault in this line.\nWhen plotted in log-log scale, the rate is defined similarly, but appears differently (because the point (0,0) is infinitely far away). Rates are represented by \"diagonal\" lines with different offsets.\nIn such a representation, widely different rates can be clearly visible in the same graph. This wouldnât be the case in linear scale.\nThe attack\nWhen depositing tokens, the number of shares a user gets is rounded towards zero. This rounding takes away value from the user in favor of the vault (i.e. in favor of all the current shareholders). This rounding is often negligible because of the amount at stake. If you deposit 1e9 shares worth of tokens, the rounding will have you lose at most 0.0000001% of your deposit. However if you deposit 10 shares worth of tokens, you could lose 10% of your deposit. Even worse, if you deposit <1 share worth of tokens, then you get 0 shares, and you basically made a donation.\nFor a given amount of assets, the more shares you receive the safer you are. If you want to limit your losses to at most 1%, you need to receive at least 100 shares.\nIn the figure we can see that for a given deposit of 500 assets, the number of shares we get and the corresponding rounding losses depend on the exchange rate. If the exchange rate is that of the orange curve, we are getting less than a share, so we lose 100% of our deposit. However, if the exchange rate is that of the green curve, we get 5000 shares, which limits our rounding losses to at most 0.02%.\nSymmetrically, if we focus on limiting our losses to a maximum of 0.5%, we need to get at least 200 shares. With the green exchange rate that requires just 20 tokens, but with the orange rate that requires 200000 tokens.\nWe can clearly see that the blue and green curves correspond to vaults that are safer than the yellow and orange curves.\nThe idea of an inflation attack is that an attacker can donate assets to the vault to move the rate curve to the right, and make the vault unsafe.\nFigure 6 shows how an attacker can manipulate the rate of an empty vault. First the attacker must deposit a small amount of tokens (1 token) and follow up with a donation of 1e5 tokens directly to the vault to move the exchange rate \"right\". This puts the vault in a state where any deposit smaller than 1e5 would be completely lost to the vault. Given that the attacker is the only shareholder (from their donation), the attacker would steal all the tokens deposited.\nAn attacker would typically wait for a user to do the first deposit into the vault, and would frontrun that operation with the attack described above. The risk is low, and the size of the \"donation\" required to manipulate the vault is equivalent to the size of the deposit that is being attacked.\nIn math that gives:\n- a 0 the attacker deposit\n- a 1 the attacker donation\n- u the user deposit\n| |\n| --- | --- | --- | --- |\n| Assets | Shares | Rate | initial |\n| 0 | 0 | - | after attackerâs deposit |\n| a 0 | a 0 | 1 | after attackerâs donation |\nThis means a deposit of u will give a 0 + a 1 u Ă a 0 shares.\nFor the attacker to dilute that deposit to 0 shares, causing the user to lose all its deposit, it must ensure that\na 0 + a 1 u Ă a 0 < 1 âș u < 1 + a 0 a 1\nUsing a 0 = 1 and a 1 = u is enough. So the attacker only needs u + 1 assets to perform a successful attack.\nIt is easy to generalize the above results to scenarios where the attacker is going after a smaller fraction of the userâs deposit. In order to target n u , the user needs to suffer rounding of a similar fraction, which means the user must receive at most n shares. This results in:\na 0 + a 1 u Ă a 0 < n âș n u < 1 + a 0 a 1\nIn this scenario, the attack is n times less powerful (in how much it is stealing) and costs n times less to execute. In both cases, the amount of funds the attacker needs to commit is equivalent to its potential earnings.\nDefending with a virtual offset\nThe defense we propose is based on the approach used in YieldBox . It consists of two parts:\n- Use an offset between the \"precision\" of the representation of shares and assets. Said otherwise, we use more decimal places to represent the shares than the underlying token does to represent the assets.\n- Include virtual shares and virtual assets in the exchange rate computation. These virtual assets enforce the conversion rate when the vault is empty.\nThese two parts work together in enforcing the security of the vault. First, the increased precision corresponds to a high rate, which we saw is safer as it reduces the rounding error when computing the amount of shares. Second, the virtual assets and shares (in addition to simplifying a lot of the computations) capture part of the donation, making it unprofitable for a developer to perform an attack.\nFollowing the previous math definitions, we have:\n- ÎŽ the vault offset\n- a 0 the attacker deposit\n- a 1 the attacker donation\n- u the user deposit\n| |\n| --- | --- | --- | --- |\n| Assets | Shares | Rate | initial |\n| 1 | 1 0 ÎŽ | 1 0 ÎŽ | after attackerâs deposit |\n| 1 + a 0 | 1 0 ÎŽ Ă ( 1 + a 0 ) | 1 0 ÎŽ | after attackerâs donation |\nOne important thing to note is that the attacker only owns a fraction 1 + a 0 a 0 of the shares, so when doing the donation, he will only be able to recover that fraction 1 + a 0 a 1 Ă a 0 of the donation. The remaining 1 + a 0 a 1 are captured by the vault.\nloss = 1 + a 0 a 1\nWhen the user deposits u , he receives\n1 0 ÎŽ Ă u Ă 1 + a 0 + a 1 1 + a 0\nFor the attacker to dilute that deposit to 0 shares, causing the user to lose all its deposit, it must ensure that\n1 0 ÎŽ Ă u Ă 1 + a 0 + a 1 1 + a 0 < 1\nâș 1 0 ÎŽ Ă u < 1 + a 0 1 + a 0 + a 1\nâș 1 0 ÎŽ Ă u < 1 + 1 + a 0 a 1\nâș 1 0 ÎŽ Ă u †loss\n- If the offset is 0, the attackerâs loss is at least equal to the userâs deposit.\n- If the offset is greater than 0, the attacker will have to suffer losses that are orders of magnitude bigger than the amount of value that can hypothetically be stolen from the user.\nThis shows that even with an offset of 0, the virtual shares and assets make this attack non profitable for the attacker. Bigger offsets increase the security even further by making any attack on the user extremely wasteful.\nThe following figure shows how the offset impacts the initial rate and limits the ability of an attacker with limited funds to inflate it effectively.\nÎŽ = 3 , a 0 = 1 , a 1 = 1 0 5\nÎŽ = 3 , a 0 = 100 , a 1 = 1 0 5\nÎŽ = 6 , a 0 = 1 , a 1 = 1 0 5\nCustom behavior: Adding fees to the vault\nIn an ERC-4626 vaults, fees can be captured during the deposit/mint and/or during the withdraw/redeem steps. In both cases it is essential to remain compliant with the ERC-4626 requirements with regard to the preview functions.\nFor example, if calling deposit(100, receiver) , the caller should deposit exactly 100 underlying tokens, including fees, and the receiver should receive a number of shares that matches the value returned by previewDeposit(100) . Similarly, previewMint should account for the fees that the user will have to pay on top of shareâs cost.\nAs for the Deposit event, while this is less clear in the EIP spec itself, there seems to be consensus that it should include the number of assets paid for by the user, including the fees.\nOn the other hand, when withdrawing assets, the number given by the user should correspond to what he receives. Any fees should be added to the quote (in shares) performed by previewWithdraw .\nThe Withdraw event should include the number of shares the user burns (including fees) and the number of assets the user actually receives (after fees are deducted).\nThe consequence of this design is that both the Deposit and Withdraw events will describe two exchange rates. The spread between the \"Buy-in\" and the \"Exit\" prices correspond to the fees taken by the vault.\nThe following example describes how fees proportional to the deposited/withdrawn amount can be implemented:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20 ;\nimport { IERC20 } from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\" ;\nimport { ERC4626 } from \"@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol\" ;\nimport { SafeERC20 } from \"@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol\" ;\nimport { Math } from \"@openzeppelin/contracts/utils/math/Math.sol\" ;\n/// @dev ERC-4626 vault with entry/exit fees expressed in https://en.wikipedia.org/wiki/Basis_point[basis point (bp)].\n///\n/// NOTE : The contract charges fees in terms of assets, not shares. This means that the fees are calculated based on the\n/// amount of assets that are being deposited or withdrawn, and not based on the amount of shares that are being minted or\n/// redeemed. This is an opinionated design decision that should be taken into account when integrating this contract.\n///\n/// WARNING: This contract has not been audited and shouldn't be considered production ready. Consider using it with caution.\nabstract contract ERC4626Fees is ERC4626 {\nusing Math for uint256 ;\nuint256 private constant _BASIS_POINT_SCALE = 1e4 ;\n// === Overrides ===\n/// @dev Preview taking an entry fee on deposit. See {IERC4626-previewDeposit}.\nfunction previewDeposit ( uint256 assets ) public view virtual override returns ( uint256 ) {\nuint256 fee = _feeOnTotal (assets, _entryFeeBasisPoints ());\nreturn super . previewDeposit (assets - fee);\n}\n/// @dev Preview adding an entry fee on mint. See {IERC4626-previewMint}.\nfunction previewMint ( uint256 shares ) public view virtual override returns ( uint256 ) {\nuint256 assets = super . previewMint (shares);\nreturn assets + _feeOnRaw (assets, _entryFeeBasisPoints ());\n}\n/// @dev Preview adding an exit fee on withdrawal. See {IERC4626-previewWithdraw}.\nfunction previewWithdraw ( uint256 assets ) public view virtual override returns ( uint256 ) {\nuint256 fee = _feeOnRaw (assets, _exitFeeBasisPoints ());\nreturn super . previewWithdraw (assets + fee);\n}\n/// @dev Preview taking an exit fee on redeem. See {IERC4626-previewRedeem}.\nfunction previewRedeem ( uint256 shares ) public view virtual override returns ( uint256 ) {\nuint256 assets = super . previewRedeem (shares);\nreturn assets - _feeOnTotal (assets, _exitFeeBasisPoints ());\n}\n/// @dev Send entry fee to {_entryFeeRecipient}. See {ERC4626-_deposit}.\nfunction _deposit ( address caller , address receiver , uint256 assets , uint256 shares ) internal virtual override {\nuint256 fee = _feeOnTotal (assets, _entryFeeBasisPoints ());\naddress recipient = _entryFeeRecipient ();\nsuper . _deposit (caller, receiver, assets, shares);\nif (fee > 0 && recipient != address ( this )) {\nSafeERC20. safeTransfer ( IERC20 ( asset ()), recipient, fee);\n}\n/// @dev Send exit fee to {_exitFeeRecipient}. See {ERC4626-_withdraw}.\nfunction _withdraw (\naddress caller ,\naddress receiver ,\naddress owner ,\nuint256 assets ,\nuint256 shares\n) internal virtual override {\nuint256 fee = _feeOnRaw (assets, _exitFeeBasisPoints ());\naddress recipient = _exitFeeRecipient ();\nsuper . _withdraw (caller, receiver, owner, assets, shares);\nif (fee > 0 && recipient != address ( this )) {\nSafeERC20. safeTransfer ( IERC20 ( asset ()), recipient, fee);\n}\n// === Fee configuration ===\nfunction _entryFeeBasisPoints () internal view virtual returns ( uint256 ) {\nreturn 0 ; // replace with e.g. 100 for 1%\n}\nfunction _exitFeeBasisPoints () internal view virtual returns ( uint256 ) {\nreturn 0 ; // replace with e.g. 100 for 1%\n}\nfunction _entryFeeRecipient () internal view virtual returns ( address ) {\nreturn address ( 0 ); // replace with e.g. a treasury address\n}\nfunction _exitFeeRecipient () internal view virtual returns ( address ) {\nreturn address ( 0 ); // replace with e.g. a treasury address\n}\n// === Fee operations ===\n/// @dev Calculates the fees that should be added to an amount `assets` that does not already include fees.\n/// Used in {IERC4626-mint} and {IERC4626-withdraw} operations.\nfunction _feeOnRaw ( uint256 assets , uint256 feeBasisPoints ) private pure returns ( uint256 ) {\nreturn assets. mulDiv (feeBasisPoints, _BASIS_POINT_SCALE, Math.Rounding.Ceil);\n}\n/// @dev Calculates the fee part of an amount `assets` that already includes fees.\n/// Used in {IERC4626-deposit} and {IERC4626-redeem} operations.\nfunction _feeOnTotal ( uint256 assets , uint256 feeBasisPoints ) private pure returns ( uint256 ) {\nreturn assets. mulDiv (feeBasisPoints, feeBasisPoints + _BASIS_POINT_SCALE, Math.Rounding.Ceil);\n}\nERC-1155\nPrevious Page\nERC-6909\nNext Page\nOn this page\nSecurity concern: Inflation attack Visualizing the vault The attack Defending with a virtual offset Custom behavior: Adding fees to the vault"}
{"url":"https://ethereum.org/developers/docs/","domain":"ethereum.org","title":"Ethereum development documentation | ethereum.org","hash":"657aa3321641bc01c5249cf0180fca59a36739cd3abae993d7403143a31eb2e6","tokens":1242,"chars":4966,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112051668,"text":"Skip to main content\nChange page\nEthereum development documentation\nEdit page (opens in a new tab)\nThis 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- Building 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.\n- Writing a smart contract. Skim the intro if EVM concepts are new, then jump to smart contracts and a programming language .\n- Running a node or staking. Go to nodes and clients , then networking and consensus mechanisms .\n- Understanding the protocol from the bottom up. The modules below are ordered for this. Read them in sequence.\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\n- Intro to Ethereum â A quick overview of Ethereum\n- Intro to Ether â A quick overview of Ether\n- Intro to dapps â An introduction to decentralized applications\n- Web2 vs Web3 â The fundamental differences that blockchain-based applications provide\n- Accounts â Entities in the network that can hold a balance and send transactions\n- Transactions â Transfers and other actions that cause Ethereum's state to change\n- Blocks â The way transactions are batched to ensure state is synchronised across all actors\n- Ethereum virtual machine (EVM) â The EVM handles all the computation on the Ethereum network\n- Opcodes\n- Gas â Computational power required to process transactions, paid for in ETH by transaction senders\n- Nodes and clients â The individuals participating in the network and the software they run to verify transactions\n- Run a node\n- Client diversity\n- Nodes as a service\n- Node architecture\n- Light clients\n- Archive nodes\n- Bootnodes\n- Networks â Implementations of Ethereum including test networks\n- Consensus mechanisms â How the individual nodes of a distributed network agree on the current state of the system\n- Proof-of-stake\n- Proof-of-work\n- Proof-of-authority\nEthereum stack\n- Intro to the stack â An overview of the Ethereum/web3 stack\n- Smart contracts â Programs that reside at an Ethereum address and run functions when triggered by transactions\n- Smart contract languages\n- Smart contract anatomy\n- Smart contracts libraries\n- Interacting with smart contracts\n- Testing smart contracts\n- Compiling smart contracts\n- Deploying smart contracts\n- Naming smart contracts\n- Verifying smart contracts\n- Upgrading smart contracts\n- Smart contract security\n- Smart contract formal verification\n- Composability\n- Development networks â Local blockchain environments used to test dapps before deployment\n- Development frameworks â Tools that make developing with Ethereum easier\n- Ethereum client APIs â Convenience libraries that allow your web app to interact with Ethereum and smart contracts\n- JavaScript APIs\n- Backend APIs\n- JSON-RPC\n- Authentication â How users sign in to Ethereum apps with their wallet instead of a password\n- Data and analytics â How blockchain data is aggregated, organized and implemented into dapps\n- Block explorers\n- Storage â Decentralized storage structures and mechanism\n- Integrated Development Environments (IDEs) â The best environments to write dapp code\n- Programming languages â How to get started with Ethereum using languages you may already know\n- Dart\n- Delphi\n- .NET\n- Elixir\n- Golang\n- Java\n- JavaScript\n- Python\n- Ruby\n- Rust\nAdvanced\n- Bridges â An overview of bridging for developers\n- Standards â Agreed upon protocols for maintaining efficiency and accessibility of projects to the community\n- Token standards\n- Maximal extractable value (MEV) â How value is extracted from the Ethereum blockchain beyond the block reward\n- Oracles â How information is injected into the Ethereum blockchain\n- Scaling â Methods for preserving decentralization and security as Ethereum grows\n- Optimistic rollups\n- Zero-knowledge rollups\n- State channels\n- Sidechains\n- Plasma\n- Validium\n- Data availability â An overview of problems and solutions relating to data availability in Ethereum\n- Blockchain data storage strategies\n- Networking layer â Explanation of Ethereum's networking layer\n- Network addresses\n- Portal Network\n- Data structures and encoding â Explanation of the data structures and encoding schema used across the Ethereum stack\n- Patricia Merkle Trie\n- Recursive-length prefix (RLP)\n- Simple serialize (SSZ)\n- Web3 secret storage definition"}
{"url":"https://www.helius.dev/docs","domain":"www.helius.dev","title":"Helius Docs: Solana RPC, APIs & Data Streaming","hash":"e645c1ad5bdc06b3a7ddb3183bc87a34179db735e30cbe5e434fefce07a0f983","tokens":739,"chars":2956,"crawler":"hive-genesis","verified":"exact","ts":1791112051796,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNew: Try Gatekeeper (Beta) for significantly lower latency. Learn More\nHelius Docs home page\n- Support\n-\nGet started\nHelius Docs home page\nHelius Documentation\nThe engine behind Solanaâs best teams, traders, and tinkerers. RPCs, APIs, gRPC streaming, webhooks, and dedicated infrastructure to build and ship crypto apps, fast.\nGet Started\nQuickstart\nCreate a free account and make your first API call in seconds\nPlans and pricing\nCompare plans from the free tier to enterprise, plus credits and rate limits\nData Streaming & Event Listening\nData streaming overview\nChoose the right way to stream on-chain data and listen for events\nLaserStream gRPC\nHigh-performance gRPC streaming with historical replay and delivery guarantees\nLaserStream WebSocket\nWebSocket subscriptions for accounts, transactions, and program activity\nWebhooks\nReal-time HTTP notifications for the addresses and events you care about\nData APIs & RPCs\nGetting data\nRead and query on-chain data with standard and Helius-exclusive RPC methods\ngetTransactionsForAddress\nFull, parsed transaction history for any address in a single call\nWallet API\nBalances, token holdings, and transaction history through REST endpoints\nDAS API\nThe Digital Asset Standard API for tokens, NFTs, and compressed NFTs\nTrading\nTrading overview\nLow-latency infrastructure for traders, market makers, and exchanges\nPre Confirmations\nSub-slot confirmation signals so you can act before the block lands\nShred Delivery\nThe fastest path to transaction data, streamed as raw or preprocessed shreds\nSender\nLand transactions reliably with dual routing to validators and Jito\nSending Transactions\nSending transactions overview\nBuild, optimize, and land transactions with priority fees, retries, and bundles\nPriority Fee API\nEstimate the right priority fee to land transactions fast without overpaying\nBackrun rebates\nEarn rebates on the backrun MEV your transactions create\nMEV Protect\nRoute transactions privately to reduce frontrunning and sandwich attacks\nThe Solana Privacy Protocol\nOverview\nProgrammable privacy for transfers with native Solana performance\nConcepts\nHow Solana Rings work, user flows, and privacy guarantees\nAdditional Resources\nSDKs\nOfficial TypeScript and Rust SDKs for the Helius API\nAPI reference\nComplete method reference for every Helius RPC and REST endpoint\nHelius for Agents\nThe MCP server, CLI, expert skills, and SDKs for building AI agents\nRPC Benchmarks\nOpen-source latency and reliability comparisons vs other providers\nAsk the AI assistant\nGet instant answers from the docs assistant, trained on everything here\nSupport\nReach the Helius team through chat, email, or the status page\nDiscord\nJoin the community for help, updates, and discussion\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ethena.fi/backing-custody-and-security/overview","domain":"docs.ethena.fi","title":"Overview | Ethena","hash":"9ac09692a3c655c8c3263288a7cb79ec127b44dd61a94736fd220a91bd2375bd","tokens":904,"chars":3613,"crawler":"hive-genesis","verified":"exact","ts":1791112121987,"text":"â Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nOverview\nA focus on security & control\n\"Backing Custody\" refers to where protocol backing assets are held.\nTo access centralized exchange liquidity, Ethena must provide backing assets to support the delta hedging derivative positions that act as the peg stability mechanism.\nEthena holds all backing assets with \"Off-Exchange Settlement\" solutions. These providers both custody deposited assets as well as enable Ethena to delegate/undelegate assets to/from centralized exchanges without ever transferring the assets to the exchanges.\n\"Off-Exchange Settlement\" providers enable Ethena to settle the outstanding PnL of Ethena's derivatives positions frequently. This enables Ethena to mitigate potential impact in the event of an exchange failure between settlement cycles.\nMost importantly, Ethena depositing backing assets assets with an \"Off-Exchange Settlement\" provider does not transfer beneficial title over the assets to the provider or exchange partners. In the event of an agreed exchange failure, Ethena should be able to delegate funds to another exchange to support hedging requirements.\n\"Off-Exchange Settlement\" providers such as Copper , Ceffu , and Fireblocks have long been used by institutional participants in the space to ameliorate this exact risk.\nTransparency\nEthena strongly believes in users' ability to independently verify the existence and control of the protocol backing as well as the hedging derivatives positions.\n-\nAll \"Off-Exchange Settlement\" providers may enable the provision of onchain wallet addresses so users can validate the existence of the protocol backing assets; however, as some backing assets are held in omnibus accounts with other assets, this might not be feasible.\n-\nPeriodic attestations (at least monthly) by custodial partners of backing asset value held within institutional custodial solutions will be published to provide transparency where addresses are not able to be provided.\n-\nEthena is actively exploring tools to help publicly prove & enable users to independently verify the existence of hedging derivatives positions.\nApproach to Decentralization\nThere are a variety of trade-offs to consider when evaluating the degree to which the protocol relies on maximally decentralized solutions.\nThe core mission of creating a stablecoin equivalent that is not reliant on banking infrastructure has to date required either:\n-\nCapital inefficient overcollateralized \"loans\" onchain.\n-\nUnstable algorithmic designs.\n-\nUnscalable delta-neutral designs that are fully reliant on decentralized exchanges.\nIn order to address the shortcomings of prior delta-neutral peg mechanism designs it is necessary to interact with centralized liquidity venues where open interest and trading volume on derivatives are >25x larger than onchain liquidity venues.\nHowever, doing so introduces new custodial risks with exchanges. How does Ethena address this?\nThe focus is generally on leveraging solutions for the most important qualities of decentralized exchanges, namely:\n-\nHolding of assets outside opaque centralized servers.\n-\nFully auditable and transparent.\n-\nPermissionless and programmatic withdrawal.\nThe use of \"Off-Exchange Settlement\" providers largely addresses these qualities & enables Ethena to create a synthetic dollar that can meaningfully scale without being overly reliant upon a single source of liquidity, a single custodian of funds, etc.\nLast updated 1 year ago\nWas this helpful?\n- Transparency\n- Approach to Decentralization\nWas this helpful?"}
{"url":"https://www.helius.dev/docs/getting-data/quickstart","domain":"www.helius.dev","title":"Getting Data Quickstart - Helius Docs","hash":"48033ad632ab437bd77676f5fe2206da3b4e599670dfe9ace4b70cfb97b4c267","tokens":1813,"chars":7249,"crawler":"hive-genesis","verified":"exact","ts":1791112123719,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNew: Try Gatekeeper (Beta) for significantly lower latency. Learn More\nHelius Docs home page\n- Support\n-\nGet started\nHelius Docs home page\nData APIs & RPCs\nGetting Data Quickstart\nMake your first Solana data query in minutes. Copy-paste examples for getTransactionsForAddress, getTransfersByAddress, the DAS API, and the Wallet API.\nQuick setup\nEvery example below needs only your Helius API key from dashboard.helius.dev . Replace YOUR_API_KEY , then pick the path that matches what youâre fetching:\nYou want Use this Returns\nAn addressâs full transaction history getTransactionsForAddress Decoded transactions for one address\nAn addressâs full transfers history getTransfersByAddress Token and native SOL transfers for one address\nTokens, NFTs, and assets owned by a wallet DAS API â getAssetsByOwner Assets with metadata, ownership, and balances\nWallet balances with USD values over REST Wallet API â /balances Token and NFT balances with USD pricing\nOption 1: Backfill transaction history (getTransactionsForAddress)\ngetTransactionsForAddress returns the full, decoded transaction history for an address in a single method â the fastest way to backfill data for indexing. Pass the address first, then an options object with optional filters.\nconst response = await fetch ( `https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY` , {\nmethod: 'POST' ,\nheaders: { 'Content-Type' : 'application/json' },\nbody: JSON . stringify ({\njsonrpc: '2.0' ,\nid: 1 ,\nmethod: 'getTransactionsForAddress' ,\nparams: [\n'86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY' ,\n{\ntransactionDetails: 'full' ,\nsortOrder: 'desc' ,\nlimit: 100 ,\n},\n],\n}),\n});\nconst { result } = await response . json ();\nconsole . log ( `Fetched ${ result . data . length } transactions` );\nimport requests\nurl = \"https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY\"\npayload = {\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"getTransactionsForAddress\" ,\n\"params\" : [\n\"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\" ,\n{ \"transactionDetails\" : \"full\" , \"sortOrder\" : \"desc\" , \"limit\" : 100 },\n],\n}\nresult = requests.post(url, json = payload).json()[ \"result\" ]\nprint ( f \"Fetched { len (result[ 'data' ]) } transactions\" )\ncurl https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY \\\n-X POST \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"jsonrpc\": \"2.0\",\n\"id\": 1,\n\"method\": \"getTransactionsForAddress\",\n\"params\": [\n\"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\",\n{ \"transactionDetails\": \"full\", \"sortOrder\": \"desc\", \"limit\": 100 }\n]\n}'\ngetTransactionsForAddress guide\nFilters, pagination, response format, and best practices.\nIndexing guide\nBuild, backfill, and keep a Solana index up to date.\nOption 2: Get transfer history (getTransfersByAddress)\ngetTransfersByAddress returns parsed token and native SOL transfer history for an address â at the transfer level rather than the transaction level, ready for reconciliation. Pass the address; add an options object for filters.\nconst response = await fetch ( `https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY` , {\nmethod: 'POST' ,\nheaders: { 'Content-Type' : 'application/json' },\nbody: JSON . stringify ({\njsonrpc: '2.0' ,\nid: 1 ,\nmethod: 'getTransfersByAddress' ,\nparams: [ '86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY' ],\n}),\n});\nconst { result } = await response . json ();\nconsole . log ( `Fetched ${ result . data . length } transfers` );\nimport requests\nurl = \"https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY\"\npayload = {\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"getTransfersByAddress\" ,\n\"params\" : [ \"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\" ],\n}\nresult = requests.post(url, json = payload).json()[ \"result\" ]\nprint ( f \"Fetched { len (result[ 'data' ]) } transfers\" )\ncurl https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY \\\n-X POST \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"jsonrpc\": \"2.0\",\n\"id\": 1,\n\"method\": \"getTransfersByAddress\",\n\"params\": [\"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\"]\n}'\ngetTransfersByAddress guide\nTransfer types, filters, reconciliation, and response format.\ngetTransfersByAddress reference\nFull parameters and response schema.\nOption 3: Get a walletâs assets (DAS API)\nThe DAS API returns the NFTs, fungible tokens, and compressed assets a wallet owns in a single call â the most common starting point for wallets, portfolio views, and analytics.\nconst response = await fetch ( `https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY` , {\nmethod: 'POST' ,\nheaders: { 'Content-Type' : 'application/json' },\nbody: JSON . stringify ({\njsonrpc: '2.0' ,\nid: '1' ,\nmethod: 'getAssetsByOwner' ,\nparams: {\nownerAddress: '86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY' ,\npage: 1 ,\nlimit: 1000 ,\noptions: {\nshowFungible: true ,\nshowNativeBalance: true ,\n},\n}),\n});\nconst { result } = await response . json ();\nconsole . log ( `Found ${ result . total } assets` );\nimport requests\nurl = \"https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY\"\npayload = {\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : \"1\" ,\n\"method\" : \"getAssetsByOwner\" ,\n\"params\" : {\n\"ownerAddress\" : \"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\" ,\n\"page\" : 1 ,\n\"limit\" : 1000 ,\n\"options\" : {\n\"showFungible\" : True ,\n\"showNativeBalance\" : True ,\n},\n}\nresult = requests.post(url, json = payload).json()[ \"result\" ]\nprint ( f \"Found { result[ 'total' ] } assets\" )\ncurl https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY \\\n-X POST \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"jsonrpc\": \"2.0\",\n\"id\": \"1\",\n\"method\": \"getAssetsByOwner\",\n\"params\": {\n\"ownerAddress\": \"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\",\n\"page\": 1,\n\"limit\": 1000,\n\"options\": {\n\"showFungible\": true,\n\"showNativeBalance\": true\n}\n}'\nDAS API overview\nAll asset methods, special asset types, and best practices.\ngetAssetsByOwner reference\nFull parameters and response schema.\nOption 4: Get wallet balances over REST (Wallet API)\nThe Wallet API is a high-level REST API. The balances endpoint returns a walletâs token and NFT holdings with USD values â no JSON-RPC envelope required.\nconst address = '86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY' ;\nconst response = await fetch (\n`https://api.helius.xyz/v1/wallet/ ${ address } /balances?api-key=YOUR_API_KEY` ,\n);\nconst data = await response . json ();\nconsole . log ( `Current page value: $ ${ data . totalUsdValue } ` );\nimport requests\naddress = \"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\"\nurl = f \"https://api.helius.xyz/v1/wallet/ { address } /balances\"\ndata = requests.get(url, headers = { \"X-Api-Key\" : \"YOUR_API_KEY\" }).json()\nprint ( f \"Current page value: $ { data[ 'totalUsdValue' ] } \" )\ncurl \"https://api.helius.xyz/v1/wallet/86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY/balances?api-key=YOUR_API_KEY\"\nWallet API overview\nAll wallet endpoints, authentication, and units.\nWallet Balances reference\nQuery parameters and full response schema.\nNext steps\nGetting Data overview\nCompare every data API and choose the right one for your use case.\nAPI Reference\nComplete method and endpoint documentation.\nNeed help? Join our Discord or see the support docs .\nWas this page helpful?\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.skyeco.com/latest","domain":"forum.skyeco.com","title":"Latest topics - Sky Forum","hash":"64f3d72adc37e065aca09a773a8865af0f9fe1e763e56f283f3f049e9bb52590","tokens":856,"chars":3424,"crawler":"crawler-v8wo","verified":"exact","ts":1791112123516,"text":"Sky Forum\nTopic\nReplies\nViews\nActivity\nS&P Report Question re: Fixed Sky Reserve target\nSky Core\n0\n15\nOctober 4, 2026\nTechnical scope of the Beacon and Configurator launch on Arbitrum\nSky Core\npas-configurator\n,\narbitrum\n,\ntechnical-scope\n0\n28\nOctober 3, 2026\n[October 8, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\narbitrum\n,\ncctp\n,\nspark-savings\n,\nx-layer\n6\n198\nOctober 3, 2026\nConfirming interest rate mechanism scope across SparkLend Ethereum reserves\nSpark Prime\n0\n18\nOctober 2, 2026\nHow to get back DAI mistakenly transferred?\nMiscellaneous\n13\n4527\nOctober 2, 2026\nMSC #13 - Settlement Summary (September 2026)\nSky Core\noea\n,\nmsc\n,\nmonthly-settlement-cycle\n0\n32\nOctober 2, 2026\nSettlement Reconciliation â MSC #5â#12 (JanuaryâAugust 2026)\nSky Core\noea\n,\nmsc\n,\nmonthly-settlement-cycle\n0\n26\nOctober 2, 2026\nGrove cBEAM Configuration\nGrove Prime\noea\n,\npas\n24\n381\nOctober 2, 2026\n[October 8, 2026] - Proposed Changes to Grove for Upcoming Spell\nGrove Prime\n8\n190\nOctober 2, 2026\nA free, read-only checker for MKR still sitting in old contracts\nGeneral Discussion\nmigration\n,\ntool\n,\ntoken-migration\n0\n26\nOctober 2, 2026\nRevisiting DAI sent to the DAI token contract after MIP13c3-SP14\nGovernance\npublic-call\n,\nsummary\n3\n59\nOctober 2, 2026\nIntroducing the Redline Portal\nGeneral Discussion\n0\n26\nOctober 1, 2026\n[ChainFundamentals AI Research] Two years in, steadying out - September2026\nGeneral Discussion\nchain-fundamentals\n0\n35\nOctober 1, 2026\nRisk Month in Review: September 2026\nGeneral Discussion\nba-labs\n0\n29\nOctober 1, 2026\nRemi's Spark Delegate Communications\nSpark Prime\ngovernance\n26\n596\nOctober 1, 2026\nYvonPiPi's Grove Delegate Communications\nGrove Prime\n9\n220\nOctober 1, 2026\n[October 8, 2026] Proposed changes to Osero for upcoming Spell\nOsero Prime\ntechnical-scope\n4\n168\nSeptember 30, 2026\nCloaky AD Recognition Submission\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n230\n11587\nSeptember 30, 2026\nTango AD Recognition Submission\nAlignment Conservers\naligned-delegates\n72\n1281\nSeptember 29, 2026\nAegisD AD Recognition Submission\nAlignment Conservers\naligned-delegates\n100\n1562\nSeptember 29, 2026\nBLUE AD Recognition Submission\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n240\n11834\nSeptember 29, 2026\nPBG Aligned Delegate Communication Platform\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n237\n14598\nSeptember 28, 2026\nWBC Aligned Delegate Communications\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n208\n11820\nSeptember 28, 2026\nMax Staking Yield AD Recognition Submission\nAlignment Conservers\naligned-delegates\n105\n1731\nSeptember 28, 2026\nAtlas Edit Weekly Cycle Proposal - Week Of 2026-09-28\nSky Core\natlas-edit-weekly-proposal\n2\n108\nSeptember 28, 2026\nBONAPUBLICA Aligned Delegate Communication\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n,\ndelegates\n273\n17562\nSeptember 28, 2026\nThe Solution for Stuck DAI\nProposal Ideas\ngovernance\n0\n38\nSeptember 25, 2026\nSky Core Executive Vote Address Handover Thread\nSky Core\nexecutive\n27\n458\nSeptember 25, 2026\nOne of two restricted wallets cleared on its own, the other didn't â how do I request a review?\nGeneral Discussion\n1\n108\nSeptember 25, 2026\nBA Labs: Sky Ecosystem Product Updates\nGeneral Discussion\nmakerburn\n,\nspark\n,\nsparklend\n,\nspark-liquidity-layer\n,\nsky-ecosystem\n,\nsky-risk-and-analytics-dash\n29\n1541\nSeptember 24, 2026\nnext page â"}
{"url":"https://solana.com/docs/core/fees","domain":"solana.com","title":"","hash":"ced6ad4c86706d641bd28fb30948f5ebd6b05c96241c3b6a5fb741145307cb7d","tokens":676,"chars":2703,"crawler":"hive-genesis","verified":"exact","ts":1791112125427,"text":"---\ntitle: Fees\ndescription:\nSolana transaction fees consist of a base fee of 5,000 lamports per signature\nand an optional prioritization fee, priced in micro-lamports per compute unit\nfor legacy and v0 transactions and as an absolute lamport total for v1. Fee\ncalculation, distribution, and compute budget.\nurl: /docs/core/fees\ntype: conceptual\nprerequisites:\n- /docs/core/transactions\nrelated:\n- /docs/core/fees/fee-structure\n- /docs/core/fees/compute-budget\n- /docs/core/transactions/transaction-structure\n---\nEvery Solana [transaction](/docs/core/transactions) requires a fee paid in SOL.\nThe fee has two components: a **base fee** and an optional **prioritization\nfee**. The base fee compensates validators for the cryptographic work of\nverifying signatures. The prioritization fee increases the likelihood that the\ncurrent leader schedules your transaction ahead of competing ones.\n\n\nBase fee calculation, fee distribution, prioritization fee formula, and code\nexamples for setting fees.\n \n\nCompute unit limits, ComputeBudgetInstruction variants, scheduler cost\nmodel, block limits, and execution budget constants.\n \n \n## Key facts\n- **Base fee**: per-signature, split 50% burned / 50% to the validator.\n- **Prioritization fee**:\n`ceil(compute_unit_price * compute_unit_limit / 1,000,000)` lamports. 100% to\nthe validator. In the\n[v1 format](/docs/core/transactions/versioned-transactions#v1-format) the fee\nis an absolute lamport total set in the message config instead.\n## Limits\n| Limit | Value | Source |\n| ------------------------------ | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |\n| Base fee per signature | 5,000 lamports | [`lamports_per_signature`](https://github.com/anza-xyz/agave/blob/v3.1.8/fee/src/lib.rs#L64-L71) |\n| Default CU limit / instruction | 200,000 | [`DEFAULT_INSTRUCTION_COMPUTE_UNIT_LIMIT`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L44) |\n| Builtin instruction default CU | 3,000 | [`MAX_BUILTIN_ALLOCATION_COMPUTE_UNIT_LIMIT`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L47) |\n| Max CU limit / transaction | 1,400,000 | [`MAX_COMPUTE_UNIT_LIMIT`](https://github.com/anza-xyz/agave/blob/v3.1.8/program-runtime/src/execution_budget.rs#L39) |\n| Micro-lamports per lamport | 1,000,000 | [`MICRO_LAMPORTS_PER_LAMPORT`](https://github.com/anza-xyz/agave/blob/v3.1.8/compute-budget/src/compute_budget_limits.rs#L17) |"}
{"url":"https://docs.base.org/get-started/base","domain":"docs.base.org","title":"Base - Base Documentation","hash":"f60b6c992deb6dce4cb6abe501c17d97b6f87183903cb8e88d8cb3bc96fd3b42","tokens":304,"chars":1216,"crawler":"crawler-v8wo","verified":"exact","ts":1791112125272,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBase Documentation home page\nGet Started\nBuild on Base\nSpecifications\nSDKs & APIs\nUpgrades\nQuickstart\nBase\nThe blockchain for global finance.\nBase is built by Coinbase, trusted by leading institutions, and open to all. Stablecoin issuance, payments, and compliance controls ship as native chain primitives you can use out of the box, without building or auditing your own contracts. Transactions settle in under a second, and cost less than one cent.\nIntegrate DeFi\nAdd direct lending, collateralized borrowing, or a vault-based earn product.\nTokenize Assets\nRepresent real-world assets with B20 Asset controls and distributions. A stock token is one example.\nIssue Stablecoins\nLaunch a fiat-backed stablecoin with minting, compliance, and reconciliation onchain.\nAccept Payments\nTake instant stablecoin and agent-driven payments with low fees.\nPrivate Transactions\nMove value through confidential ledgers with selective disclosure.\nWas this page helpful?\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://solana.com/docs/tokens","domain":"solana.com","title":"","hash":"6873484169bc77d41c277288c73cf9d8f70ba9c6d7a01c6c1200c5e99a19b148","tokens":1881,"chars":7523,"crawler":"crawler-v8wo","verified":"exact","ts":1791112126921,"text":"---\ntitle: Assets on Solana\nseoTitle: Solana Tokens, Token Accounts, and Token Extensions\ndescription:\nLearn how digital assets are represented on Solana using Token Programs, mint\naccounts, token accounts, and Token-2022 extensions.\n---\nTokens are digital assets that represent ownership over diverse categories of\nassets. Tokenization enables the digitalization of property rights. Tokens on\nSolana are referred to as SPL\n([Solana Program Library](https://github.com/solana-program)) Tokens.\n\n\nCreate a mint, mint supply, and transfer tokens on devnet from your browser.\n \n \nThis section covers the basic concepts of how tokens are represented on Solana.\nRefer to the [SPL Token Basics](/docs/tokens/basics) section for code examples.\n## Key Points\n- [Token Programs](#token-programs) contain all instruction logic for\ninteracting with tokens on the network (both fungible and non-fungible).\n- A [Mint Account](#mint-account) represents a specific token and stores global\nmetadata about the token such as the total supply and mint authority (address\nauthorized to create new units of a token).\n- A [Token Account](#token-account) tracks individual ownership of tokens for a\nspecific mint account for a specific owner.\n- An [Associated Token Account](#associated-token-account) is a Token Account\ncreated with an address derived from the owner and mint account addresses.\n## Token Programs\nThe Solana ecosystem has two main Token Programs. Source code for both programs\nbelow.\n\n\n- Basic token capability (mint, transfer, etc.)\n- Immutable and widely used\n \n\n- Includes all original Token Program features\n- Adds features through \"extensions\"\n \n \nToken Programs contains all instruction logic for interacting with tokens on the\nnetwork (both fungible and non-fungible). All tokens on Solana are effectively\n[data accounts](/docs/core/accounts/account-types#data-accounts) owned by a\nToken Program.\n\n### Mint Account\nTokens on Solana are uniquely identified by the address of a\n[Mint Account](https://github.com/solana-program/token/blob/6d18ff73b1dd30703a30b1ca941cb0f1d18c2b2a/program/src/state.rs#L16-L30)\nowned by the Token Program. This account acts as a global counter for a specific\ntoken and stores data such as:\n- **Supply**: Total supply of the token\n- **Decimals**: Decimal precision of the token\n- **Mint authority**: The account authorized to create new units of the token,\nincreasing the supply\n- **Freeze authority**: The account authorized to freeze tokens in a Token\nAccount, preventing them from being transferred or burned\nThe mint authority is configured when the mint is initialized. It authorizes\nfuture minting, but it does not have to be the account that created or paid for\nthe mint account.\n\nThe full details stored on each Mint Account include the following:\n```rust title=\"Mint Account State\"\npub struct Mint {\n/// Optional authority used to mint new tokens. The mint authority may only\n/// be provided during mint creation. If no mint authority is present\n/// then the mint has a fixed supply and no further tokens may be\n/// minted.\npub mint_authority: COption,\n/// Total supply of tokens.\npub supply: u64,\n/// Number of base 10 digits to the right of the decimal place.\npub decimals: u8,\n/// Is `true` if this structure has been initialized\npub is_initialized: bool,\n/// Optional authority to freeze token accounts.\npub freeze_authority: COption,\n}\n```\nFor reference, here is a Solana Explorer link to the\n[USDC Mint Account](https://explorer.solana.com/address/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v).\n### Token Account\nThe Token Program creates\n[Token Accounts](https://github.com/solana-program/token/blob/6d18ff73b1dd30703a30b1ca941cb0f1d18c2b2a/program/src/state.rs#L87-L108)\nto track individual ownership of each token unit. A Token Account stores data\nsuch as:\n- **Mint**: The token the Token Account holds units of\n- **Owner**: The account authorized to transfer tokens from the Token Account\n- **Amount**: Number of the tokens the Token Account currently holds\n\nThe full details stored on each Token Account include the following:\n```rust title=\"Token Account State\"\npub struct Account {\n/// The mint associated with this account\npub mint: Pubkey,\n/// The owner of this account.\npub owner: Pubkey,\n/// The amount of tokens this account holds.\npub amount: u64,\n/// If `delegate` is `Some` then `delegated_amount` represents\n/// the amount authorized by the delegate\npub delegate: COption,\n/// The account's state\npub state: AccountState,\n/// If is_native.is_some, this is a native token, and the value logs the\n/// rent-exempt reserve. An Account is required to be rent-exempt, so\n/// the value is used by the Processor to ensure that wrapped SOL\n/// accounts do not drop below this threshold.\npub is_native: COption,\n/// The amount delegated\npub delegated_amount: u64,\n/// Optional authority to close the account.\npub close_authority: COption,\n}\n```\nA wallet needs a token account for each token (mint) it wants to hold, with the\nwallet address set as the token account owner. Each wallet can own multiple\ntoken accounts for the same token (mint), but a token account can only have one\nowner and hold units of one token (mint).\n\n\nNote that each Token Account's data includes an `owner` field identifying who\nhas authority over the Token Account. This differs from the program owner\nspecified in the base\n[Account](/docs/core/accounts/account-structure#account-fields) type, which is\nthe Token Program for all Token Accounts.\n \n### Associated Token Account\nAssociated Token Accounts simplify the process of finding a token account's\naddress for a specific mint and owner. Think of the Associated Token Account as\nthe \"default\" token account for a specific mint and owner.\nAn Associated Token Account is created with an address derived from the owner's\naddress and the mint account's address. It's important to understand that an\nAssociated Token Account is just a token account with a specific address.\nCreating an ATA requires a refundable minimum balance for its account storage.\nThe instruction's payer funds that balance even when another wallet owns the\nATA. See\n[ATA cost and payer](/docs/tokens/basics/create-token-account#cost-and-payer)\nfor current costs and Token-2022 sizing differences.\nThis introduces a key concept in Solana development:\n[Program Derived Address (PDA)](/docs/core/pda). A PDA derives an address\ndeterministically using predefined inputs, making it easy to find the address of\nan account.\n\nNote that each wallet needs its own token account to hold tokens from the same\nmint.\n"}
{"url":"https://ethresear.ch/latest","domain":"ethresear.ch","title":"Ethereum Research","hash":"1c93ced06d728edb4f4a82f81b55cbf02e1551113fbc723224e941d872136405","tokens":807,"chars":3225,"crawler":"hive-genesis","verified":"exact","ts":1791112127787,"text":"Ethereum Research\nTopic\nReplies\nViews\nActivity\nRead this before posting\nAdministrivia\n13\n61454\nAugust 20, 2026\nProposal for a minimal compute-anchored purchasing power signal\nEconomics\n0\n40\nOctober 2, 2026\nSix defects in one signature verification tool, found from outside in six rounds\nSecurity\n0\n37\nOctober 2, 2026\nThe Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\nExecution Layer Research\nstateless\n10\n775\nOctober 2, 2026\nMempool Account Transaction Capacity from Historical Activity (MATCHA)\nExecution Layer Research\naccount-abstraction\n,\ntransaction-privacy\n10\n513\nOctober 2, 2026\nStaking rewards as venture capital, governed by futarchy\nEconomics\nfutarchy\n,\ndao\n2\n206\nOctober 1, 2026\nTrust minimized transaction simulation using state proofs\nSecurity\n7\n627\nOctober 1, 2026\nPQ anonymity for Stealth Address Protocol\nPrivacy\n4\n195\nOctober 1, 2026\nLetting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559\nEconomics\neip-1559\n,\nfee-market\n,\nmev\n,\nproposer-builder-separation\n1\n145\nSeptember 30, 2026\nTowards Encrypted Mempools from Threshold IBE without Batching\nCryptography\n4\n230\nSeptember 29, 2026\nEthereum's TCB, Part 1: The client\nSecurity\nsecurity\n3\n335\nSeptember 29, 2026\nPQ spending for Stealth Address Protocol\n0\n61\nSeptember 28, 2026\nEthereum lessons from a live end-to-end PQ proof-native protocol\nArchitecture\npost-quantum\n,\nzero-knowledge\n6\n400\nSeptember 27, 2026\nFormal Verification of Execution and Consensus Clients\nSecurity\nsecurity\n13\n591\nSeptember 25, 2026\nSnappy with a memory: ~40% less gossip traffic\nNetworking\nsingle-slot-finality\n1\n149\nSeptember 25, 2026\nCapacity oracles\nEconomics\n4\n403\nSeptember 25, 2026\nDesigns for EVM gas accounting in EIP-7999\nExecution Layer Research\nfee-market\n7\n457\nSeptember 24, 2026\nProprietary AMMs and Ethereum\nExecution Layer Research\nmev\n13\n1314\nSeptember 24, 2026\nCHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\nExecution Layer Research\nnetworking\n,\np2p\n1\n104\nSeptember 24, 2026\nLattice-based signature aggregation\nCryptography\npost-quantum\n9\n2776\nSeptember 24, 2026\nPost-Poseidon: Hash Function Variants for Ethereum\nCryptography\n0\n301\nSeptember 23, 2026\nEIP-8411 payload segmentation under the Shadow simulator\nNetworking\nscaling\n,\np2p\n1\n79\nSeptember 23, 2026\nEIP-8411: what segmented payload diffusion is made of\nNetworking\nscaling\n,\np2p\n1\n218\nSeptember 23, 2026\nPost-Quantum Lattice or Hash-Based: One Question, Two Right Answers\nCryptography\npost-quantum\n2\n177\nSeptember 22, 2026\nPost-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\nEconomics\n1\n143\nSeptember 22, 2026\nEtheorem update: the complete executable consensus specs written in Lean 4\nConsensus\n0\n189\nSeptember 21, 2026\nEIL: Trust minimized cross-L2 interop\nLayer 2\n19\n4087\nSeptember 20, 2026\nStrict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)\nPrivacy\n0\n52\nSeptember 19, 2026\nEvidence Review Framework for Project Applications in Decentralized Guilds/Agent Systems\nApplications\ndao\n,\ngovernance\n0\n53\nSeptember 19, 2026\nCryptographic canaries and backups\nCryptography\n8\n7554\nSeptember 18, 2026\nnext page â"}
{"url":"https://docs.squads.so/main/basics/who-we-are-squads-labs","domain":"docs.squads.so","title":"Who we are - Squads Labs | Squads Docs","hash":"02d6b9d29782c36092f81c35272f50d9126611812f83cdb226d26241cd758318","tokens":269,"chars":1075,"crawler":"crawler-v8wo","verified":"exact","ts":1791112128892,"text":"Squads Docs\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nWho we are - Squads Labs\nLearn more about the team.\nSquads Labs\nSquads Labs is a technology company that builds tools to enable efficient economic activity onchain.\nOur mission is to grow the onchain economy by developing smart account technology and products that make it easy for businesses, teams and individuals to securely transact, manage and own digital assets.\nLeveraging this smart account technology, we offer a product suite that includes Squads for enterprises and Fuse for individuals.\nWe are trusted and used by over 250 teams in the ecosystem, such as Jupiter, Pyth, Raydium, Marginfi, Backpack, Drift, Helius, Kamino, Jito, Tensor, Helium and many others.\nOur partners and investors include Electric Capital, RockawayX, Coinbase Ventures, L1D, Placeholder, Multicoin Capital, 6th Man Ventures, Jump Crypto, Collab+Currency, Delphi Digital, Reciprocal Ventures, Solana Ventures.\nPrevious What is a multisig\nNext Security\nLast updated 1 year ago"}
{"url":"https://kamino.com/docs","domain":"kamino.com","title":"Overview - Kamino Docs","hash":"556e5cc10a88192985ecd7db19b36e88247346ec4b92c2b384b57c0834c5f65d","tokens":1006,"chars":4023,"crawler":"hive-genesis","verified":"exact","ts":1791112130014,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nKamino Docs home page\nOverview\nProducts\nSecurity & Risk\nKMNO\nLearn\nResources\nKamino Documentation\nExplore the Kamino protocol with comprehensive documentation for developers, curators, and institutions.\nEarn\nBorrow\nMultiply\nSwap\nAudits\nRisk\nSafety\nDocs\nProduct\nProduct and risk docs for understanding Kamino.\nRead about product mechanics, usage guides, audits, safeguards, and the risk framework behind Kamino.\nProducts âą Learn âą Security & Risk\nconst vault = new KaminoVault(rpc, address);\nconst shares = await vault.getUserShares(user);\nREST API\nTS SDK\nBuildkit\nDeveloper\nAI-ready docs for faster Kamino integrations.\nBuild on Kamino with APIs, SDKs, Rust tooling, and practical examples.\nAPI Reference âą SDK Guides âą AI Tools\nCREATE VAULT\nALLOCATIONS\nSET UP FARMS\nMARKETS\nRESERVES\nREWARDS\nCurators\nOperator\nVault and market docs.\nDesign and manage custom lending strategies on Kamino for institutions and professional risk managers.\nVaults âą Markets âą Parameters\nCurators on Kamino\nKamino gives curators granular control over institutional-grade lending infrastructure.\nVaults\n1\nDeploy Vault\nInitialize a lending vault that accepts a single deposit token.\n2\nSet Allocation Strategy\nConfigure allocation weights, caps, and risk parameters across reserves.\n3\nRoute Assets\nDistribute depositor assets across lending reserves and issue share tokens.\n4\nEarn Revenue\nCollect fees from vault operations and manage rewards distribution.\nMarkets\n1\nCreate Market\nDeploy an isolated lending market with your own risk parameters.\n2\nAdd Reserves\nConfigure reserves with LTV, liquidation thresholds, rate curves, and oracles.\n3\nConfigure Rewards\nSet up collateral and debt farms to distribute rewards to depositors and borrowers.\n4\nTransfer to Multisig\nTransfer market administration to a Squads multisig before launch.\nA complete toolchain for faster integrations.\nREST API\nData, analytics, user positions, unsigned transactions.\nTypeScript SDK\nOn-chain reads, transaction building, advanced operations.\nRust Crate\nRust clients, bots, on-chain CPI.\nAI Tools\nllms.txt, skill.md, agent assisted development.\nCLI\nManaging markets, reserves, vaults, and operational workflows.\nconst res = await fetch ( 'https://api.kamino.finance/ktx/kvault/deposit' , {\nmethod: 'POST' ,\nheaders: { 'Content-Type' : 'application/json' },\nbody: JSON . stringify ({\nwallet: 'YOUR_WALLET_ADDRESS' ,\nkvault: 'HDsayqAsDWy3QvANGqh2yNraqcD8Fnjgh73Mhb3WRS5E' ,\namount: '100.0' ,\n}),\n});\nconst { transaction } = await res . json ();\nimport { createSolanaRpc , address , generateKeyPairSigner } from '@solana/kit' ;\nimport { KaminoVault } from '@kamino-finance/klend-sdk' ;\nimport { Decimal } from 'decimal.js' ;\nconst signer = await generateKeyPairSigner ();\nconst vault = new KaminoVault (\ncreateSolanaRpc ( 'https://api.mainnet-beta.solana.com' ),\naddress ( 'HDsayqAsDWy3QvANGqh2yNraqcD8Fnjgh73Mhb3WRS5E' )\n);\nconst depositIxs = await vault . depositIxs (\nsigner ,\nnew Decimal ( 100.0 )\n);\nuse kvault_interface :: {helpers, pda, VaultInfo , KVAULT_PROGRAM_ID };\nuse spl_associated_token_account :: get_associated_token_address;\nlet vault = VaultInfo :: from_account_data (\nvault_pubkey , & vault_data . data, & reserve_infos\n) ? ;\nlet user_token_ata = get_associated_token_address ( & owner , & vault . token_mint);\nlet ( shares_mint , _ ) = pda :: shares_mint ( & KVAULT_PROGRAM_ID , & vault_pubkey );\nlet user_shares_ata = get_associated_token_address ( & owner , & shares_mint );\nlet deposit_ix = helpers :: deposit :: deposit (\n& vault , owner , user_token_ata , user_shares_ata ,\n1_000_000 ,\n);\nKamino MCP Server\nnpx add-mcp https://kamino.com/docs/mcp\nKamino CLI\nyarn kamino-manager create-market âmode execute\nHow can we help?\nBuild with Kamino. Get the support you need to ship.\nRisk dashboard Security App Terms\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.arbitrum.foundation/latest","domain":"forum.arbitrum.foundation","title":"Latest topics - Arbitrum","hash":"941afa10e0bf9e8ffa0621d933552f24f582e4847fb6344ab482cce4d409c4ff","tokens":846,"chars":3383,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112130651,"text":"Arbitrum\nTopic\nReplies\nViews\nActivity\nWelcome to Discourse\nGeneral\n41\n21687\nMarch 23, 2026\nStableGuard by FintechCheck: Real-Time Stablecoin Depeg Detection for Treasury & DeFi Protection\nGeneral\nproposal\n,\nproposal-discussions\n12\n127\nOctober 4, 2026\n[CONSTITUTIONAL]: Establish an L1 Voting Recovery System\nProposals\nproposal\n0\n29\nOctober 2, 2026\nSecurity Council Emergency Action â 2/10/2026\nSecurity Council\n0\n176\nOctober 2, 2026\nFrom Governance Token to Utility Token: Evolving ARB Beyond Governance\nGeneral\n35\n1258\nOctober 2, 2026\n[Final Report] Paros: Automated Treasury Management for Arbitrum\nDomain Allocator Offerings (prev Questbook)\n0\n24\nOctober 2, 2026\nMoTZ Ă Arbitrum â Campaign Final Report\nDomain Allocator Offerings (prev Questbook)\n0\n13\nOctober 2, 2026\n[Final Report] T3tris.finance - Zero-fee, permissionless vault infrastructure\nDomain Allocator Offerings (prev Questbook)\n0\n20\nOctober 1, 2026\n[Constitutional] AIP: Transition Arbitrum One ordering policy to Priority Gas Auctions (PGA)\nFinalized AIPs\n30\n2147\nOctober 1, 2026\nQuestion: How would sequencer decentralization affect Arbitrum users?\nTechnical Discussion\n3\n73\nOctober 1, 2026\n[Final Report] Salt : Permissionless MPC Treasury Management\nDomain Allocator Offerings (prev Questbook)\n1\n40\nOctober 1, 2026\nStylus Manager - Final Report & Grant Completion\nDomain Allocator Offerings (prev Questbook)\n2\n36\nOctober 1, 2026\nFree API with GMX open interest, funding and liquidations next to CEX data.\nGeneral\n2\n45\nSeptember 30, 2026\nRewarding Active Delegates - September 2026 Results\nRewarding Active Delegates Program (RAD)\n0\n53\nSeptember 29, 2026\nArbitrum Security Program is Live: Applications Now Open\nAnnouncements\n0\n66\nSeptember 29, 2026\nArbitrumDAO Factsheet: Robinhood Chain Mainnet Launch\nAnnouncements\n5\n909\nSeptember 27, 2026\nWhat Makes People Stay in an L2 Ecosystem?\nGeneral\n2\n46\nSeptember 27, 2026\nATM Council Updates\nArbitrum Treasury Management Council\n22\n1399\nSeptember 25, 2026\n[RFC] Operational Mandate: Arbitrum Stylus Developer Impact Oracle & Sybil-Resistant ROI Matrix\nEarly Idea Discussion\n6\n114\nSeptember 24, 2026\nSecurity Council key exposure across three chains â draft for review\nTechnical Discussion\nsecurity-council\n14\n171\nSeptember 23, 2026\n[Constitutional] AIP Fast Feed\nFinalized AIPs\n22\n999\nSeptember 22, 2026\nSeptember 22nd - Open Discussion of Proposals Governance Call\nBiweekly Proposals Discussions Call\n0\n56\nSeptember 21, 2026\nBanning projects identified in the high-severity Watchdog Program cases\nFinalized AIPs\n11\n393\nSeptember 21, 2026\nFinal report - Arbitrum and GMX Python tooling for onchain trading\nDomain Allocator Offerings (prev Questbook)\n3\n65\nSeptember 21, 2026\nHow can small ARB holders participate meaningfully in Arbitrum governance?\nGeneral\n2\n57\nSeptember 21, 2026\n[Final Report] Building Regenerative Impact with Green Goods\nDomain Allocator Offerings (prev Questbook)\n4\n72\nSeptember 20, 2026\n[final report] SolDB â CLI debugger and simulator for Solidity and Stylus\nDomain Allocator Offerings (prev Questbook)\n4\n106\nSeptember 20, 2026\nSEEDGov Delegate Communication Thread\nDelegate Statements\n3\n261\nSeptember 18, 2026\nPractical examples of how Stylus and Orbit help developers\nTechnical Discussion\n2\n39\nSeptember 18, 2026\nParticipation Architecture - Final Grant Report\nDomain Allocator Offerings (prev Questbook)\n28\n372\nSeptember 17, 2026\nnext page â"}
{"url":"https://raw.githubusercontent.com/ethereum/consensus-specs/master/README.md","domain":"raw.githubusercontent.com","title":"Ethereum Consensus Specifications","hash":"f666481980e801298d7786c04363b8cb1070f3ca46e5b7fb134725be7caffe2e","tokens":831,"chars":3323,"crawler":"hive-genesis","verified":"exact","ts":1791112131537,"text":"# Ethereum Consensus Specifications\n[](https://github.com/ethereum/consensus-specs/actions/workflows/tests.yml)\n[](https://pypi.python.org/pypi/eth-consensus-specs)\n[](https://pypi.python.org/pypi/eth-consensus-specs)\n[](https://discord.gg/qGpsxSA)\nThis repository hosts the Ethereum\n[proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/)\nspecifications for consensus-layer clients. Design rationale and proposed\nchanges are discussed in issues. Agreed-upon changes are made through pull\nrequests. Specifications can be found in [specs](specs), arranged by upgrade.\nEach upgrade builds on the previous, specifying only what it changes. Individual\n[features](specs/_features) are developed in parallel and are folded into an\nupgrade when ready.\n### Stable specifications\n| Seq. | Code Name | Fork Epoch | Link |\n| ---- | ------------- | ---------- | ----------------------- |\n| 0 | **Phase0** | `0` | [Spec](specs/phase0) |\n| 1 | **Altair** | `74240` | [Spec](specs/altair) |\n| 2 | **Bellatrix** | `144896` | [Spec](specs/bellatrix) |\n| 3 | **Capella** | `194048` | [Spec](specs/capella) |\n| 4 | **Deneb** | `269568` | [Spec](specs/deneb) |\n| 5 | **Electra** | `364032` | [Spec](specs/electra) |\n| 6 | **Fulu** | `411392` | [Spec](specs/fulu) |\n### Unstable specifications\n| Seq. | Code Name | Fork Epoch | Link |\n| ---- | --------- | ---------- | ------------------- |\n| 7 | **Gloas** | TBD | [Spec](specs/gloas) |\n| 8 | **Heze** | TBD | [Spec](specs/heze) |\n### Rendered viewers\n- https://ethereum.github.io/spec-viewer/\n- https://ethereum.github.io/consensus-specs/\n### Reference tests\n- [Release assets](https://github.com/ethereum/consensus-specs/releases)\n- [Nightly artifacts](https://github.com/ethereum/consensus-specs/actions/workflows/tests.yml)\n### Design goals\n- Minimize complexity, even at the cost of some losses in efficiency.\n- Remain live through major network partitions and mass node outages.\n- Select components that are quantum-secure or easy to swap out.\n- Use crypto and design techniques that support a large validator set.\n- Minimize hardware requirements such that a consumer laptop can participate.\n### External specifications\n- [Beacon APIs](https://github.com/ethereum/beacon-apis)\n- [Beacon Metrics](https://github.com/ethereum/beacon-metrics)\n- [Builder Specs](https://github.com/ethereum/builder-specs)\n- [Cryptography Specs](https://github.com/ethereum/cryptography-specs)\n- [Deposit Contract](https://github.com/ethereum/solidity-deposit-contract)\n- [Engine APIs](https://github.com/ethereum/execution-apis/tree/main/src/engine)\n- [SimpleSerialize Specs](https://github.com/ethereum/ssz-specs)\n### Useful resources\n- [Design Rationale](https://notes.ethereum.org/s/rkhCgQteN#)\n- [Phase0 for Humans](https://notes.ethereum.org/s/Bkn3zpwxB)\n- [Combining GHOST and Casper](https://arxiv.org/abs/2003.03052)\n- [Vitalik's annotated spec](https://github.com/ethereum/annotated-spec)\n- [Upgrading Ethereum](https://eth2book.info)"}
{"url":"https://docs.lido.fi/","domain":"docs.lido.fi","title":"Introduction | Lido Docs","hash":"efe199bbd8d6c9bf66b79724077ab3f4e4d379149445615563dc8cfcd4018afb","tokens":2267,"chars":9065,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112132304,"text":"Skip to main content\nIntroduction\nThis documentation is intended to introduce the general user to the project, as well as to serve as a guide for anyone who may be developing software using Lido.\nâ Get started with FAQ\nđ„ See guides for Node Operators, Vault managers or Oracle Operators at Run on Lido\nđ Follow the bug bounty program\nđ° Access grants with LEGO\nđ Everything about Lido Node Operators\nđ Integrate your DApp following this guide\nđ Participate in governance forum\nđ·ïž Audit source code\nđ€ Support, partnerships and more in Discord , Telegram\nâ
Updates in blog and X/Twitter\nâčïž Find support at help center\nWhat is Lido\nLido is the leading liquid staking solution - providing a simple way to get rewards on your digital tokens. By staking with Lido your tokens remain liquid and can be used across a range of DeFi applications, getting extra rewards.\n- Staking pool . Protocol to manage deposits, staking rewards, and withdrawals. A separate one for every supported network.\n- st[token] . Unlike staked tokens, the Lido st[token] are freely transferable instead of locked as in the case of native staking. Lido lets users operate with staked tokens by leveraging collateral, lending, farming, and other kinds of DeFi protocols.\n- DAO . Lido liquid protocols management entity, responsible for picking node operators, configuring the protocol parameters and much more.\nđ To dive into the details of governance design and implementation, proceed to DAO\n- Node Operators . Entities that manage a secure and stable infrastructure for running validator clients for the benefit of the protocols. Theyâre dedicated staking providers who can ensure the safety of funds belonging to the protocol users and correctness of validator operations.\nEthereum is and remains a primary focus of Lido. Thatâs affected the organisational structure - the governance is implemented through ERC20 LDO token on Ethereum.\nLiquid staking\nProblem statement\nTraditionally, staking in Proof-of-Stake (PoS) protocol based projects has been about locking oneâs tokens in one project for a long time and expecting a fixed, predetermined staking reward in return. While it guarantees the return on staked tokens much like a bond, it also limits the opportunities of generating higher returns on those tokens from the DeFi ecosystem. If youâve staked all of your crypto holdings, you canât invest or trade in more profitable crypto pairs on exchanges.\nSolution\nLiquid staking allows using the st[token] in other trading opportunities to let the user get the best of both worlds - a reward on your staked tokens, as well as the returns from new trading opportunities. Liquid staking introduces various fundamental benefits by:\n- Making staking process simple - no need to worry about hardware setup and maintenance;\n- Making it possible to get rewards on as small a deposit as users want (i.e, Ethereum requires minimum 32 ETH staked);\n- Providing the st[token] a building block for other applications and protocols (e.g., as collateral in lending or other trading DeFi solutions). Liquid staking gives an opportunity to maximize the potential while having the best of both worlds;\n- Providing an alternative to or even encompassing exchange staking, solo staking, and other semi-custodial and decentralised protocols.\nComparison with other staking options\nSolo staking is great, but it comes with some disadvantages. Setting up a validator node requires a pristine technical understanding, brings with it a minimum deposit of 32 ETH in Ethereum case, slashing and offline penalties can get very severe if the staking is managed improperly and finally the staked amount is locked up for a significant period.\nSolo staking is similar to other option SaaS staking in that you are having your own validator keys. Nevertheless, with SaaS you must trust a third-party (usually centralised), which may act maliciously, attacked or simply regulated. Going back to the Ethereum example, there remains a requirement for a minimum amount of 32 ETH staked.\nAlternatively, it may be possible to produce staking through centralised exchanges . Needless to say, crypto tokens and CeFi are not suited well together from the fundamental standpoint. It is also worth mentioning the economic aspect - by staking within some centralised entities, the user does not receive a corresponding token in return and, thus, loses the opportunity to perform any subsequent activity within DeFi or the same centralised entity, where tokens were staked. Yes, APR, when staking on centralised exchanges might be higher, but with a significant amount aggregated within the centralised entity comes a huge potential influence to the ecosystem that was fundamentally designed decentralised.\nThrough the use of a liquid staking solution such as Lido, users can eliminate these inconveniences and benefit from non-custodial staking backed by the actively maintained validators set. Liquid staking is unlocking the potential of PoS by giving users the ability to not only stake their tokens, but have the liquidity to use those tokens in DeFi projects that way not only increasing rewards for the individual, but growing the staking participation in general.\nLido on Ethereum APR\nnote\nAPR provides only the current estimation of the rewards without any upfront forecasts.\nUser's APR (Lido staking APR) = Protocol APR * (1 - Protocol fee)\nProtocol APR\nBy Protocol APR we mean gross annual percentage rate â the overall Consensus Layer (CL) and Execution Layer (EL) rewards received by Lido validators to total pooled ETH estimated as moving average of the last 7 days.\nConsensus Layer\nValidators receive rewards when they perform consensus layer validatorsâ duties:\n- attest blocks\n- propose blocks\n- participate in sync committees.\nThe value of the rewards in each epoch is calculated from a base reward. This is the base unit representing the average reward received by a validator under optimal conditions per epoch. Base rewards are inversely proportional to the square root of the total staked ether in Ethereum, that's why the amount of reward per validator decreases as the overall number of validators on Ethereum grows.\nIn addition to rewards, penalties and slashing can be applied to validators on the CL.\nA penalty is a form of reducing the validatorâs stake, which is not online or doesnât meet certain specifications criteria when attesting the blocks.\nBeing slashed means that the misbehaving validator is forced to exit the beacon chain at a point in the future, receiving a number of penalties until it leaves . As a result of it, APR can also reduce.\nPerformance of Lido validators\nThe better the underlying operator sets are, the more robust, resilient, and performant the underlying protocol. Check Operator Statistics and Metrics .\nLearn more about rewards and penalties - ethereum.org\nExecution Layer\nValidators began to receive EL rewards after the Merge . EL rewards consist of four parts:\n-\nPriority fee\nPriority fee refers to optional additional fees (for example it may refer to EIP-1559) paid directly to validators in order to incentivize them to include the given transaction in a block. Also it depends on network demand: as higher network demand, as higher could be priority fee.\n-\nMaximal Extractable Value (MEV) rewards\nMEV refers to the maximum value that can be extracted by the validator from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block.\nRewards socialization model\nWith Lido, you receive staking rewards within 24 hours of your deposit being made, without waiting for validator activation.\nProtocol fee\nLido applies a 10% fee on staking rewards that are split between node operators and the DAO Treasury. The fee can be changed by the DAO pending a successful vote.\nMore about APR calculation\nPlease refer to the API doc page for further details.\nSecurity\nThe security of Lido is highest priority beginning at the time of its initial deployment, but still users should investigate risks involved with Lido before engaging with it. We are constantly working on security improvements:\n- Using of DAO for governance decisions & to manage risk factors.\n- Having multiple audits finished (see more ).\n- Having a committee of elected, best-in-class validators to minimise staking risk.\n- Allowing staking across multiple validators (i.e. current Ethereum staking mechanism only allows to choose only a single validator)\n- Using of non-custodial staking service to eliminate counterparty risk.\nIn the scorecard you may find an outlined set of attributes that we think are important for the decentralisation of the protocol, and how Lido is faring against these targets.\nđ As for now, scorecard has only Ethereum related content.\n- What is Lido\n- Liquid staking\n- Problem statement\n- Solution\n- Comparison with other staking options\n- Lido on Ethereum APR\n- Protocol APR\n- Consensus Layer\n- Execution Layer\n- Rewards socialization model\n- Protocol fee\n- More about APR calculation\n- Security"}
{"url":"https://docs.ipfs.tech/how-to/troubleshooting/","domain":"docs.ipfs.tech","title":"Troubleshooting IPFS | IPFS Docs","hash":"a1f53f4a59af893df3827982e27092e1714c6e661eb4ebe1ea96ad03b323c1b1","tokens":3786,"chars":15142,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112134192,"text":"IPFS Docs\n# Introduction to troubleshooting IPFS\nFrom a high level, troubleshooting IPFS typically comes down to finding the root cause of a problem in one of the following operations:\n- Retrieval - Retrieving data by CID from other peers in the network.\n- Providing - Providing data to other peers in the network.\nRetrieval and providing are complementary operations, as one cannot be done without the other. Hence, their failure modes are closely related, and can be attributed to the following causes:\n- Content routing : providers for a CID cannot be found in the DHT or the IPNI.\n- Network connectivity : connecting to a provider is not possible, either because the provider is offline, or because the provider is not reachable over the network.\nThis guide outlines techniques to troubleshoot and identify the root cause of common issues with retrieval and providing in the public IPFS Mainnet network.\nFor the purposes of this guide, we will use the following tools:\n- IPFS Check (opens new window) - A browser-based debugging tool that can help you identify the root cause of a problem with retrieval.\n- Kubo (opens new window) - A popular implementation of IPFS with a CLI that can be used to troubleshoot retrieval and providing from the terminal.\n- Helia Identify tool (opens new window) - A browser-based tool to run libp2p identify (opens new window) with a given peer id, testing whether the peer is dialable from a browser.\n- Public Delegated Routing Endpoint at https://delegated-ipfs.dev/routing/v1 - which can be used to find providers for a CID.\n# Troubleshooting retrieval\nIn this section, you will learn to troubleshoot common issues with retrieval. For a more detailed overview of the retrieval process, see the lifecycle of data in IPFS .\n# Troubleshooting retrieval from public recursive IPFS gateways\nIf you are troubleshooting retrieval from a public recursive IPFS gateway , keep in mind that the gateway is just another IPFS node and an additional point of failure that you commonly have no insight into. This means that it's harder to troubleshoot, because as a user you cannot determine whether the problem is with the gateway or the provider node.\nWe therefore recommended using Kubo or IPFS Check to troubleshoot retrieval, which give you direct insight into the retrievability of the data by CID from providers\n# What causes failure to retrieve data by CID?\nWhen failing to fetch the data for a given CID, there are main classes of errors that may be the reason for this:\n- Content routing: providers for the CID cannot be found in the DHT or the IPNI:\n- Because there are no providers for the CID.\n- Because the providers aren't announcing the CID to the DHT or IPNI\n- Because there are problems with the DHT (opens new window) or the IPNI (opens new window) .\n- Connectivity:\n- The provider is offline or unreachable over the network due to NAT or firewall issues.\n- The provider is not dialable from browsers:\n- Because the provider doesn't have a public IP.\n- Because the provider doesn't support browser transports like Secure WebSockets, WebTransport, or WebRTC.\nIn the next section, you will learn how to use the delegated routing endpoint to check for providers for a CID, and how to get a more detailed overview of the root cause with IPFS Check.\n# Checking for providers with the Delegated Routing Endpoint\nTo get a quick overview of the providers for a given CID from both the DHT and the IPNI, you can use the Delegated Routing Endpoint at https://delegated-ipfs.dev/routing/v1 , which you can query with a simple HTTP GET request.\nFor example, open delegated-ipfs.dev/routing/v1/providers/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi (opens new window) in your browser.\nOr alternatively, use curl to query the endpoint:\ncurl -H \"Accept: application/x-ndjson\" \"https://delegated-ipfs.dev/routing/v1/providers/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi\"\nNote : By setting the Accept header to application/x-ndjson , the response will be streamed, so you don't need to wait for the entire response to be received before you can start processing the results.\nIf the response body contains be an array of providers with Peer IDs and Multiaddrs, and other information, as defined in the spec (opens new window) , you can proceed to the next section to troubleshoot retrieval with IPFS Check.\nIf you get back an HTTP 200 response with no providers (an empty body when using the application/x-ndjson Accept header shown above, or {\"Providers\":[]} in the default JSON response), check out the section on No providers returned for more information. Some older routing endpoints signal the same outcome with a 404 response, which clients must treat as zero results.\n# Troubleshooting retrieval with IPFS Check\nIPFS Check (opens new window) is a web app that helps you troubleshoot retrieval by CID.\nIt helps you answer the following questions:\n- How many providers for this CID could be found on IPFS Mainnet?\n- In which routing system was each of those providers found, the Amino DHT or the IPNI?\n- Is the data for the CID retrievable from the providers that are announcing it?\n- Is the data for the CID retrievable over Bitswap and/or HTTP?\n- What multiaddresses and network transports are used to connect to successful providers for a CID?\n- Was NAT hole punching necessary to retrieve the data?\nIPFS Check is comprised of a frontend interacting with a backend. The backend is a set of Go libraries that are used to query the DHT and IPNI, and to probe retrieval from the providers for a given CID. The frontend is a web app that allows you to interact with the backend and see the results.\n# IPFS Check modes of operation\nIPFS Check supports two modes of operation:\n- Multi-provider check : you pass a CID and IPFS Check will search for providers both in the IPNI and the DHT, and return the retrievability results for multiple providers.\n- Provider-specific check : you pass a CID and a provider's multiaddr or peer id, with /p2p/ prepended.\n# Provider-specific checks with IPFS Check\n- Navigate to the IPFS Check (opens new window) tool.\n- In the CID field, enter the CID you are trying to check\n- In the Multiaddr field , enter the multiaddress (either Peer ID or full multiaddr) of the IPFS peer you are trying to check.\n- Click Run Test .\nThe Multiaddr field can be either:\n- Just the Peer ID, with /p2p/ prepended, e.g. /p2p/12D3KooWBgwLwbTX5YYgASx8sqv49WBhy9gzLCLFVCP9jshfVdC5 . IPFS Check will route the Peer ID to find the full multiaddr.\n- The full multiaddr, e.g. /ip4/1.1.1.1/tcp/4001/p2p/12D3KooWBgwLwbTX5YYgASx8sqv49WBhy9gzLCLFVCP9jshfVdC5 .\nFor example, the output will look as follows, when doing a Peer ID specific check for a CID:\nLooking at the output, you can know the following:\n- The provider and the CID were routable via the DHT.\n- The provider is online, and the data for the CID is retrievable over Bitswap.\n- The provider was reachable over IPv6 with the QUIC transport, and also supports Secure WebSockets (the multiaddr with dns4.../...libp2p.direct/tls/ , ), WebTransport,\n- No NAT hole punching was necessary to retrieve the data, you can know this because there is a single connection multiaddr in the output, and it doesn't contain p2p-circuit .\nYou can also test a specific multiaddr and transport combination, by entering the full multiaddr in the Multiaddr field. For example, this is what the output looks like when testing the Secure WebSockets multiaddr:\nSince the Secure WebSockets multiaddr is also supported by all browsers, you can also test connectivity to the provider directly from a browser (rather than the IPFS Check backend like in this example) with the Helia Identify tool .\n# Multi-provider checks with IPFS Check\nIn this mode, IPFS Check will search for providers both in the IPNI and the DHT, and return the retrievability results for multiple providers.\n- Navigate to the IPFS Check (opens new window) tool.\n- In the CID field, enter the CID you are trying to check\n- Click Run Test .\nThe output will look as follows:\nLooking at the output, you can know the following:\n- The routing query found 9 working providers for the CID.\n- Some providers were found in the IPNI, some in the DHT.\n- Some providers are providing the data with HTTP (the first result), and others with Bitswap over a libp2p QUIC connection (the second result).\n# Identifying NAT hole punching\nWhen using IPFS Check, you can identify whether NAT hole punching was necessary to connect to a provider, by looking at the connection multiaddrs in the output. If there are two connection multiaddrs, and one of them contains p2p-circuit , for example:\nThis is because when a provider peer is behind NAT, it will acquire a circuit relay reservation as part of the NAT hole punching process (DCUtR) (opens new window) .\nIf NAT traversal is necessary to connect to a provider, and you are also behind NAT, there's a chance that NAT hole punching will fail for you. Unlike the IPFS Check backend which has a public IP (allowing DCUtR to leverage dialback for direct connection), when two peers are behind NAT, they cannot dial back to each other and require hole punching, which is not guaranteed to be successful.\n# Debug browser connectivity\nHelia Identify (opens new window) is a browser-based tool to run libp2p identify with a given peer id, testing whether the peer is dialable from a browser. This is useful to test whether a provider is reachable from a browser, which is a common cause of browser-based retrieval failures.\nThe following gif shows how to use Helia Identify to test whether a provider is reachable from a browser, by entering a Peer ID in the input field and clicking the Identify button.\n# Troubleshooting retrieval with Kubo\nThis procedure assumes that you have the latest version of Kubo installed . To debug manually:\n-\nOpen up a terminal window.\n-\nUsing Kubo, determine if any peers are advertising the you are requesting:\nipfs routing findprovs < CID >\nIf providers are found , their Peer IDs are returned. Example output:\n12D3KooWSvjCTS6w6f6nyJQ615p4ipiW3L7BTbt9XvpR6Kxi385m\n12D3KooWDCNa4MmDPHr3916gpk2PcQJbJXyKxfByTL6UBmSwBM2H\n12D3KooWDEYGGZAH4v1Hu75nqyF4vnN8UyfgCCwerTD98F1Z8Q1z\n12D3KooWHr9MZJVKwe7tZyD6Z8uRcZFQ7XUqhM2nQvpeQxDyAN4E\n12D3KooWGLyBGRMdNQe5KnkeT2g3QYp7uM71tpn77somfRHaWmmS\nIn this case, complete the steps described in Providers returned .\nIf no providers were returned , the cause of your problem might be content publishing. Complete the steps described in No providers returned .\n# Providers returned\nIf providers were found, do the following:\n-\nIn the terminal, retrieve the network addresses of one of the peers returned using its :\nipfs id -f '' < peer-id >\nUpon success, you'll see a list of addresses like:\n/ip4/145.40.90.155/tcp/4001/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT\n/ip4/145.40.90.155/tcp/4002/ws/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT\nip6/2604:1380:45e1:2700::d/tcp/4001/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT\n/ip6/2604:1380:45e1:2700::d/tcp/4002/ws/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT\n-\nTry fetching the block:\nipfs block get < CID >\nIf the block is successfully retrieved, you'll see the block data in the terminal.\n# No providers returned\nIf no providers are could be found in the DHT or IPNI, it could be due to one of the following reasons:\n- All providers for the CID are currently offline.\n- The provider is having trouble announcing the CID to the DHT or IPNI.\n- There is a problem with the content routing system (either the DHT or IPNI).\nIf that happens, check the IPNI website (opens new window) to rule out an issue with the IPNI.\nBroadly speaking, the Amino DHT is resilient to outages, so it's less likely to be the cause of the issue. A more likely cause is that the provider is having trouble announcing the CID to the DHT.\nIf you are the provider for the CID, see the next section on troubleshooting providing .\nIf you rely on a pinning service to provide the content, check the status page of the pinning service.\nIf you are not the provider for the CID and cannot find any providers, there's not much more you can do. However, if you still have a copy of the content or can fetch it as a .car file from somewhere, you can provide it to the network by importing it into Kubo with ipfs dag import .car .\n# Troubleshooting providing\nIn this section, you will learn to troubleshoot common issues with providing. For a more detailed overview of the providing process, see the lifecycle of data in IPFS .\nIf clients are unable to find providers for a CID, the issue may lie in the content providing lifecycle, specifically reprovider runs , the continuous process in which a node advertises provider records. Provider records are mappings of CIDs to network addresses, and have an expiration time of 48 hours, which accounts for provider churn.\nGenerally speaking, as more files are added to an IPFS node, the longer reprovide runs take. When a reprovide run takes longer than 48 hours (the expiration time for provider records), CIDs will no longer be discoverable.\n# Troubleshooting providing with Kubo\nWith this in mind, if no providers are returned, do the following:\n-\nFirst, determine how long a reprovide run takes:\nipfs stats reprovide\nThe output should look something like this:\nTotalReprovides: 4k ( 4,140 )\nAvgReprovideDuration: 12 .870309s\nLastReprovideDuration: 44m32.507618s\nLastReprovide: 2025 -06-10 09:45:18\n-\nNote the value for LastReprovideDuration . If it is close to 48 hours, or if you notice a \"reprovide taking too long\" warning in your ipfs daemon output log, select one of the following options, keeping in mind that each has tradeoffs:\n-\nEnable the Accelerated DHT Client (opens new window) in Kubo . This configuration improves content providing times significantly by maintaining more connections to peers and a larger routing table and batching advertising of provider records. However, this performance boost comes at the cost of increased resource consumption, most notably network connections to other peers, and can lead to degraded network performance in home networks.\n-\nChange the Reprovider Strategy (opens new window) from all to either pinned+mfs or roots . In both cases, only provider records for explicitly pinned content are advertised. Differences and tradeoffs are noted below:\n- The pinned+mfs strategy will advertise both the root CIDs and child block CIDs (the entire DAG) of explicitly pinned content and the locally available part of MFS.\n- The roots strategy will only advertise the root CIDs of pinned content, reducing the total number of provides in each run. This strategy is the most efficient, but should be done with caution, as it will limit discoverability only to root CIDs. In other words, if you are adding folders of files to an IPFS node, only the CID for the pinned folder will be advertised. All the blocks will still be retrievable with Bitswap once a connection to the node is established.\n-\nManually trigger a reprovide run:\nipfs routing reprovide\nHelp us improve this site!\nEdit this page\nor\nopen an issue"}
{"url":"https://docs.orca.so/liquidity/manage/portfolio","domain":"docs.orca.so","title":"Managing Your Portfolio - Orca Documentation","hash":"47ea2635173e936a53374e7690177d466c927c8ac94e8062ee1acc464e9309a9","tokens":2496,"chars":9982,"crawler":"hive-genesis","verified":"unchecked","ts":1791112135217,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nManaging Positions\nManaging Your Portfolio\nReview and manage your liquidity positions on Orca.\nThe Portfolio page lets you review and manage liquidity positions on Orca. You can view positions, review estimated metrics, harvest accrued fees and rewards, and access position actions.\nPortfolio values and yield metrics are estimates based on available data. Actual results may differ based on token prices, liquidity, trading activity, fees, rewards, slippage, transaction costs, and market conditions.\nAccessing Your Portfolio\n1\nVisit the Portfolio page\nGo to orca.so/portfolio .\n2\nConnect your wallet\nClick Connect Wallet and approve the connection.\n3\nView your positions\nYour positions load after your wallet is connected.\nWhatâs on the Portfolio Page\nThe Portfolio page shows two top-level tabs:\n- Liquidity Positions â Your concentrated liquidity positions across Whirlpools\n- Vault Positions â Your deposits into managed Vaults\nAbove the position list, you will see a set of header metrics:\nMetric What it shows\nTotal Portfolio Value Estimated combined value of liquidity positions and vault positions\nTotal Liquidity Value Estimated combined value of LP positions only\nPending Yield Accrued but unharvested fees and rewards across positions\nEstimated Yield (24H) Estimated yield over 24 hours based on current or recent activity\nA Harvest All button next to Pending Yield lets you submit a transaction to collect accrued fees and rewards from eligible positions.\nThree sub-tabs let you scope the view:\n- Positions â Active LP positions\n- History â Historical activity for your positions\n- Closed Positions â Positions that have been fully closed\nPosition row columns\nEach position row displays:\nColumn Description\nPool Token pair and fee tier, such as SOL / USDC · 0.04%\nBalance Estimated USD value of the position\nTotal PnL Estimated change in position value, shown in USD and as a percentage delta\nPending Yield Accrued but unharvested fees and rewards for this position\nEst. Yield Estimated yield, with a selectable timeframe, such as 7D by default\nPosition Range Min and max prices, with deltas from the current price\nCurrent Price Current price for the pool pair\nA ⯠button on the right opens the position action menu.\nPortfolio metrics are estimates and may change as pool prices, token prices, liquidity, rewards, and market conditions change.\nPosition Action Menu\nThe ⯠menu on each position row gives you access to position actions:\nAction What it does\nHarvest Yield Collect accrued fees and rewards into your wallet\nPosition Details Opens the full Position Details sidebar\n+ Deposit Liquidity Opens the Deposit tab to add liquidity to the position\nâ Withdraw Liquidity Opens the Withdraw tab to remove liquidity from the position\nĂ Close position Closes the position and may burn the position NFT, depending on the selected option\nOpen Position In â Liquidity Terminal Opens this position inside the Liquidity Terminal for chart-based review\nClick the ⯠on a position row to open the action menu; the Position Details sidebar opens on the right\nFor a deeper view, click anywhere on a position row to open the Position Details Sidebar :\nPosition Details Sidebar\nReview Details, Deposit, and Withdraw tabs, plus alerts\nHarvest Yield\nUse Harvest Yield to collect accrued fees and rewards\nAdd Liquidity\nAdd more liquidity to an existing position\nWithdraw Liquidity\nRemove some or all liquidity from a position\nUnderstanding Position Status\nIn Range\nThe current price is within your selected range. The position may accrue swap fees when swaps use your liquidity.\nOut of Range\nThe current price is outside your selected range. The position does not accrue swap fees while it is out of range.\nYou can set up position alerts to get notified when selected position conditions occur.\nUnderstanding Position NFTs\nLiquidity positions are represented by NFTs. Each position has one unique NFT in your wallet that represents ownership of that position.\nWhy this matters\n- Whoever holds the NFT controls the position it represents\n- Transferring the NFT transfers control of the position\n- If the NFT is burned, you lose access to the position it represents\nProtect your position NFTs:\n- Do not sell, transfer, or burn a position NFT unless you intend to transfer ownership of the position or permanently give up access to it.\n- Keep position NFTs in a wallet you control.\n- Be cautious of scams asking you to send or burn NFTs.\n- Orca cannot recover liquidity if the position NFT is burned or transferred away.\nTransferring positions\nTo move a position to another wallet:\n- Transfer the position NFT to the new wallet.\n- The new wallet can manage the position.\n- The original wallet loses access to the position after the NFT is transferred.\nThis may be used for:\n- Moving a position to a hardware wallet\n- Moving a position to a multisig\n- Transferring ownership of a position\nReviewing Position Metrics\nWhat each metric means\nThe Portfolio page and Position Details sidebar surface these fields. Names below match labels in the app.\nMetric What it means\nBalance Estimated current USD value of the tokens in your position\nTotal PnL Estimated change in position value, shown in USD and as a percentage delta\nPending Yield Fees and rewards accrued on this position but not yet harvested\nEstimated Yield Estimated yield over the selected timeframe, such as 7D by default, based on current or recent pool activity\nPosition Range The min and max prices that define your range\nCurrent Price The current price for the pool pair\nAverage Entry Price The reference price recorded for this position\nHarvested Yield Total fees and rewards already collected from this position\nPosition Duration How long the position has been open\nPosition Address The onchain address of the position; click to open in a block explorer\nThe first six appear on each position row in the list. The full set is visible in the Details tab of the Position Details sidebar .\nComparing LP position value with holding\nThe Portfolio shows estimated position metrics, including accrued and harvested yield. It does not fully determine how the position compares with simply holding the deposited tokens outside the pool.\nA simplified comparison may consider:\nLP comparison = Harvested Yield + Pending Yield - Impermanent Loss\nWhere impermanent loss , also known as divergence loss, is the difference between your positionâs current value and what the deposited tokens would be worth if held outside the pool.\nThis comparison is an estimate. It may not include all relevant factors, such as slippage, transaction costs, priority fees, taxes, price movement during transactions, or reward changes.\nFor more detail, see Impermanent Loss .\nPosition review considerations\nMonitoring frequency\nHow often you review a position may depend on range width, token volatility, position size, and your own preferences.\nPosition type Possible review frequency\nFull-range Less frequent range review\nWide custom range Occasional review\nTight custom range More frequent review\nYou can set up alerts for selected position conditions.\nHarvest timing\nWhen reviewing whether to harvest, consider:\n- Accrued fees and rewards\n- Network fees and transaction costs\n- Whether you are already making another position change\n- Tax or record-keeping needs\nTax treatment varies by jurisdiction. Consult a tax professional for your specific situation.\nWhen users may review or adjust positions\nUsers may review or adjust positions when:\n- A position is out of range\n- Token composition has changed\n- Pool conditions or market conditions have changed\n- Fees or rewards have changed\n- The user wants to withdraw, add liquidity, or create a new range\nAdjusting a position can involve transaction costs, slippage, price movement, and changes in token exposure.\nTroubleshooting\nPosition not showing\n- Check wallet connection â Reconnect if needed.\n- Refresh the page â Wait for data to load.\n- Verify correct wallet â Ensure you are using the address that holds the position NFT.\n- Check NFT ownership â The position NFT must be in the connected wallet.\nIncorrect values displayed\n- Refresh the page â Values can change as data updates.\n- Check network status â Solana RPC issues can cause delays.\n- Clear browser cache â Cached data may show stale values.\nCan't interact with position\n- Verify NFT ownership â The position NFT must be in the connected wallet.\n- Check SOL balance â SOL is required for transaction fees and any account costs.\n- Review network conditions â Network congestion can cause transaction failures or delays.\nSecurity Tips\nProtect NFTs\nDo not sell, transfer, or burn position NFTs unless you intend to transfer ownership or give up access\nReview Wallet Setup\nConsider your wallet setup carefully, especially for larger positions\nVerify Transactions\nAlways review transaction details before approving\nAvoid Scams\nBe cautious of links from DMs and requests to transfer or burn NFTs\nImportant reminders\n- Portfolio values and yield metrics are estimates and can change.\n- Fee and reward accrual are not guaranteed.\n- Positions only accrue swap fees while in range and used by swaps.\n- Position NFTs represent ownership of liquidity positions.\n- Burning or transferring a position NFT can result in loss of access to the position it represents.\n- Review all wallet prompts before signing transactions.\nNext Steps\nPosition Sidebar\nReview quick actions for position management\nHarvest Yield\nUse Harvest Yield to collect accrued fees and rewards\nAdd Liquidity\nAdd more liquidity to an existing position\nPosition Alerts\nSet up notifications for selected position conditions\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.arbitrum.foundation/t/motz-x-arbitrum-campaign-final-report/31528","domain":"forum.arbitrum.foundation","title":"MoTZ Ă Arbitrum â Campaign Final Report - Domain Allocator Offerings (prev Questbook) - Arbitrum","hash":"ca5c25def7022b693a6900d1618f809528defe5cefe2069ec850db9f571b2e32","tokens":2133,"chars":8529,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112136065,"text":"Arbitrum\nMoTZ Ă Arbitrum â Campaign Final Report\nDAO Programs & Initiatives\nDomain Allocator Offerings (prev Questbook)\nkyroh\nOctober 2, 2026, 1:57am\n1\nKyroh LLC / Mark of The Zeal | Campaign activity through July 25, 2026\n1 Executive Summary\nMoTZ delivered six tournaments and 588 successful onchain tournament registrations, reaching 337 distinct wallets. The campaign combined public and community tournaments, a dedicated Founders Coin competition, creator rewards and broadcasts. Across the four larger tournaments, 33.2% of participating wallets returned for another event and 23 wallets attended all four.\nOur team built two lasting products for this campaign: a gasless transaction relayer on Arbitrum One and Zeal Survivors, a full original Arbitrum game. The relayer sponsored registration transactions so players could join the free events without paying gas fees. We built and shipped the game ourselves, then hosted the two closing tournaments in it.\nWe received the first $5,000 of the approved $15,000 award and allocated it across tournament rewards and event operations. This report presents the campaign results, the products we built and the initial payment breakdown for review and release of the applicable remaining milestone payments.\n- Questbook application\n- Campaign hub\n- MoTZ on X\n- Kyroh on X\n2 Performance Against KPIs\nApplication target\nCampaign delivery\n500 new, unique Arbitrum wallets\n588 successful onchain event registrations across 337 distinct wallets, including returning players registering for multiple events. The ledger measures campaign wallet participation; it does not identify first-ever Arbitrum use.\n3 major livestreamed tournaments + 3 secondary community tournaments\n6 completed tournaments: April Amiko Legends, The Beacon public event, The Beacon Founders Coin exclusive event, June Amiko community tournament, and two Zeal Survivors events.\n6 short videos and 3 long-form threads\nThe campaign report records six short videos and three long-form threads. Selected announcements, recaps and highlights are linked below.\n3 livestream events\nThe campaign report records three livestream events. The Beacon broadcast is included in the supporting links below.\nFinal report with retention and analytics\nPublic onchain registration ledger, event-level participation totals and a repeat-participation analysis: 110 of 331 wallets returned across the four larger tournaments (33.2%).\nCompleted campaign event\nRegistration window in 2026\nSignups\nAmiko Legends\nApril 22-30\n160\nThe Beacon\nMay 21-29\n139\nThe Beacon - Founders Coin exclusive\nMay 31-June 5\n34\nAmiko Legends - community tournament\nJune 13-20\n38\nMoTZ Survival Competition\nJune 30-July 6\n103\nZeal Survivors Tournament 2\nJuly 19-25\n114\nSix completed events\n337 distinct wallets\n588\nAcross the April Amiko, May Beacon and both Zeal Survivors events, 331 wallets generated 516 registrations. Of those wallets, 110 registered for at least two events (33.2%) and 23 registered for all four, demonstrating sustained participation throughout the campaign.\nRegistrations grew across the three campaign phases: 160, 211 and 217. Community tournaments included the Founders Coin Beacon event (34 signups, $250 pool) and June Amiko (38 signups). The public Beacon and final Zeal events also included holder reward leaderboards.\n-\nPublic transaction ledger\n-\nArbiscan contract events\n-\nAmiko event post\n-\nAmiko recap\n-\nBeacon announcement\n-\nBeacon livestream\n-\nBeacon highlight\n-\nSurvivors first event\n-\nSurvivors second event\n3 Qualitative Impact and Community Feedback\nBuilt by MoTZ: a gasless Arbitrum transaction relayer\nWe built a gasless transaction relayer on Arbitrum One to submit registration transactions and sponsor the gas. Players could join the free tournaments without paying transaction fees or acquiring ETH for gas. Successful registrations are recorded onchain, with wallet and transaction links in the public ledger.\nBuilt by MoTZ: Zeal Survivors, a full original Arbitrum game\nWe built and shipped Zeal Survivors, a full original Arbitrum game created for this campaign, and ran both closing tournaments in it. Seeded runs gave competitors the same conditions. This delivered a playable product and practical experience building, launching and operating community gaming experiences.\nCommunity participation and creator engagement\nWe created incentives for participants to share gameplay, publish tournament content and introduce their audiences to Arbitrum gaming. The Zeal creator competition allocated $360 across two $125 winning entries and eleven additional $10 awards. These rewards gave participants another way to contribute beyond competing, encouraging community-created content around the game and campaign.\n- Creator competition announcement\n- Creator competition awards\n4 Financial Summary\nQuestbook milestone\nAmount\nPayment / review position\nMonth 1 Launch and Onboarding Push\n$5,000\nPaid; confirmed by MoTZ\nMonth 2 Expansion and Engagement Growth\n$5,000\nRemaining milestone allocation\nMonth 3 Retention and Final Reporting\n$3,500\nRemaining milestone allocation\nPost Campaign Survey and Reporting\n$1,500\nTotal grant\n$15,000\n$5,000 received; $10,000 remaining\nThe first payment represents 33.3% of the award. The following allocation summary accounts for the initial $5,000, including the additional rewards identified in campaign records.\nInitial payment allocation\nAmount\nTournament prize allocations\n$3,500\nZeal creator rewards\n$360\nAmiko wheel rewards\n$30\nBeacon promotional giveaway\n$20\nVarious onchain prizes + operational expenses for the events\n$1,090\nTotal initial payment\n$5,000\nReward allocations follow the campaign announcements and claims. The combined onchain-prize and operations category includes MoTZ Coin and MoTZ Key NFT prizes, event operating expenses and any unused funds from the initial payment. This table summarizes allocation of the initial payment, including any remaining funds.\nFor the full $15,000 award, the proposal budget allocated $5,000 (33.3%) to prizes and tournament operations, $3,000 (20%) to short-form production, $2,000 (13.3%) to livestream production, $2,000 (13.3%) to promotion, and $3,000 (20%) to tracking, analytics and reporting. These are the original full-award budget categories; percentages are rounded.\nThe remaining award allocation is $10,000: $8,500 across the two remaining main campaign milestones and $1,500 for the separate survey milestone. We request review and release of the applicable remaining campaign milestone payments, taking into account the $5,000 already received.\n5 Future Plans and Continued Ecosystem Alignment\nWe are interested in experimenting with GameFi on Robinhood Chain. Our team now has the experience to build full games together and a community that can help bring those games to more users. We want to apply what we learned from Zeal Survivors and from running wallet-based tournament registration to future game experiments.\nRobinhood Chain is built using Arbitrum technology, giving this exploration a connection to the wider Arbitrum ecosystem. Our next step is to explore how the game-development and community-onboarding experience from this campaign can support future GameFi experiments.\n- Play Zeal Survivors\n- Gasless check-in app\n- Robinhood Chain documentation\n6 Additional Remarks\nThe campaign leaves MoTZ with two substantial products built by our team: Zeal Survivors, a full original Arbitrum game, and a reusable gasless Arbitrum transaction relayer. Together with the public registration ledger and a community that returned across events, they provide a practical foundation for future onchain gaming campaigns.\nThank you to the Arbitrum grant team for the opportunity to explore the ecosystem, build within it and bring our community along. Your support helped us turn ideas into playable experiences and show more people the potential of gaming on Arbitrum.\nRelated topics\nTopic\nReplies\nViews\nActivity\nWayfinders x Arbitrum Gaming Final Grant Report 2025â2026\nDomain Allocator Offerings (prev Questbook)\n1\n42\nJuly 7, 2026\nArbitrum Academic Bridge @ NTUA â Final Grant Report (Ethereum Greece)\nDomain Allocator Offerings (prev Questbook)\n10\n169\nAugust 10, 2026\nArbitrum Bites: Gaming Content Propulsion\nDomain Allocator Offerings (prev Questbook)\n0\n47\nAugust 5, 2025\n[Final Report] - Pavelski X Arbitrum Gaming\nDomain Allocator Offerings (prev Questbook)\n5\n87\nAugust 15, 2026\nWayfinders Ă Arbitrum Gaming â Final Grant Report\nDomain Allocator Offerings (prev Questbook)\n0\n50\nJanuary 27, 2026"}
{"url":"https://docs.orca.so/create/rewards/overview","domain":"docs.orca.so","title":"Adding Pool Rewards - Orca Documentation","hash":"a0f90a9a2456b630b210b46a855945cc71be11377e19a3a88640dc4e8a2ce612","tokens":1955,"chars":7818,"crawler":"hive-genesis","verified":"unchecked","ts":1791112137101,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nRewards\nAdding Pool Rewards\nAdd token rewards for liquidity providers on your pool.\nPool rewards allow projects or other reward providers to distribute tokens to eligible liquidity providers in an Orca pool over a set period.\nRewards are reviewed and coordinated with Orca. Adding rewards does not guarantee liquidity, trading activity, price impact, route availability, or LP participation.\nHow rewards work\nWhen rewards are added to a pool:\n- A reward provider supplies tokens to be distributed over a set period.\n- Eligible liquidity providers may accrue a share of rewards.\n- Rewards are calculated based on the reward configuration and eligible liquidity.\n- Liquidity providers can claim accrued rewards through the Orca interface.\nWhat rewards may affect\nArea Description\nLP participation Rewards may provide an additional reason for liquidity providers to review a pool\nLiquidity distribution Rewards may affect how liquidity is allocated during the reward period\nPool information Reward information may be displayed in the Orca interface\nClaimable rewards Eligible liquidity providers may claim accrued rewards through the Orca interface\nPrerequisites\nBefore requesting rewards, prepare the following:\n- An existing pool â Rewards are added to existing Orca pools.\n- Reward tokens â These are the tokens to be distributed.\n- Token list status â The reward token may need to be on the Orca Token List.\n- Orca coordination â Rewards require review and coordination with Orca.\nProcess overview\nAdding rewards involves coordination with Orca. The general flow is:\n1. Prepare â 2. Contact Orca â 3. Confirm details â 4. Transfer tokens â 5. Rewards are activated\nStep-by-step guide\nStep 1: Prepare your information\nGather the following details:\nInformation Description\nPool address The Orca pool you want to add rewards to\nReward token The token you want to distribute\nTotal amount The total number of tokens to distribute\nDuration How long the reward period should run\nStart date When you want the reward period to begin\nStep 2: Check token list status\nThe reward token may need to be on the Orca Token List before rewards can be configured.\n- Already listed? Continue to Step 3.\n- Not listed? Submit token information for review: Orca Token List .\nInclude your contact details in the token list request if you also plan to request rewards.\nStep 3: Contact Orca\nReach out through one of these channels:\n- In-app Support â Use the Support button in the wallet menu.\n- Community â Reach out on Discord or Telegram .\n- Existing channels â Use an existing communication channel with the Orca team, if you have one.\nInclude the following in your message:\nSubject: Reward Program Request\nPool: [pool address or token pair]\nReward Token: [token name and mint address]\nAmount: [total tokens to distribute]\nDuration: [e.g., 30 days, 90 days]\nPreferred Start: [date]\nContact: [your preferred contact method]\nStep 4: Wait for review\nThe Orca team will review the request and may follow up to:\n- Confirm whether the requested reward setup can be supported.\n- Provide transfer instructions if the request proceeds.\n- Confirm the proposed start date and reward duration.\nReview timing may vary based on request completeness, queue, and any follow-up information required.\nStep 5: Transfer reward tokens\nIf Orca confirms that the reward setup can proceed:\n- Transfer the reward tokens to the address provided by Orca.\n- Send the transaction signature to Orca.\n- Wait for confirmation that the transfer was received.\nOnly transfer reward tokens to an address provided through an official Orca support or communication channel.\nStep 6: Rewards are activated\nAfter Orca configures the rewards:\n- Reward information may appear in the Orca interface.\n- Eligible liquidity providers may begin accruing rewards according to the reward configuration.\n- Rewards are distributed over the configured duration.\nReward parameters\nDuration options\nReward duration is coordinated with Orca and depends on the requested setup.\nDuration Common context\n14 days Shorter reward periods\n30 days Standard reward periods\n90 days Longer reward periods\nCustom Subject to Orca review and coordination\nDistribution method\nRewards may be distributed:\n- Continuously â Over the configured reward period.\n- Proportionally â Based on eligible liquidity and the reward configuration.\n- To eligible liquidity â For CLMM pools, reward eligibility may depend on whether liquidity is in range.\nClaiming rewards\nLiquidity providers can claim accrued rewards:\n- Through the Orca interface\n- Alongside accrued trading fees, where applicable\n- Using the Harvest function\nScenarios\nNew pool, new token\n- Create your pool: Splash Pool or CLMM Pool .\n- Submit token information for review: Orca Token List .\n- Contact Orca about rewards and include relevant token list information.\n- If the request proceeds, transfer reward tokens according to Orcaâs instructions.\nExisting pool, listed token\n- Contact Orca with the pool and reward details.\n- Confirm program parameters with Orca.\n- If the request proceeds, transfer reward tokens according to Orcaâs instructions.\n- Rewards are activated after configuration is complete.\nExtending an existing reward period\n- Contact Orca before the current reward period ends.\n- Provide the proposed additional token amount and duration.\n- If supported, Orca will provide next steps for extending the reward period.\nPlanning considerations\nReward amount\nWhen planning a reward request, consider:\n- Total reward token amount\n- Reward duration\n- Existing pool liquidity\n- Expected reward display in the Orca interface\n- Whether the reward token is already listed or needs review\nTiming\nWhen planning timing, consider:\n- Requested start date\n- Token list review, if required\n- Orca review and coordination\n- Any announcements or community communications you plan to make\nMonitoring\nAfter rewards are activated, you can monitor:\n- Reward display in the Orca interface.\n- Accrued rewards for eligible liquidity providers.\n- Pool liquidity and trading activity.\n- Whether the reward period needs to be extended or updated.\nCosts\n- Reward tokens â You provide the tokens to distribute.\n- Setup â There is no fee for standard reward setup.\n- Network fees â Transactions may require standard Solana network fees.\n- Protocol fees â Standard Orca protocol fees apply to trades.\nFrequently Asked Questions\nCan I add multiple reward tokens?\nSome pools may support multiple reward tokens. Contact Orca to review the requested setup.\nCan I cancel a reward program early?\nReward programs generally cannot be canceled early once configured. Review the token amount and duration carefully before proceeding. Contact Orca to discuss edge cases.\nHow are rewards displayed to LPs?\nThe Orca interface may display estimated reward APR based on the current reward rate and pool TVL. Displayed APR is an estimate and can change as pool conditions change.\nWhat if no one provides liquidity?\nIf no eligible liquidity is provided, rewards may not be distributed as expected. Contact Orca if you have questions about a specific reward setup.\nCan I reward a pool I did not create?\nYou may be able to add rewards to an existing Orca pool, subject to review and coordination with Orca.\nRelated Resources\n- Creating a Splash Pool - Simple pool creation\n- Creating a CLMM Pool - Advanced pool creation\n- Token List - Submit token display information for review\n- Harvesting Yield - How LPs claim rewards\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.anchor-lang.com/docs/references/avm","domain":"www.anchor-lang.com","title":"Anchor Version Manager","hash":"6bd76ac473204ac1d472e0844b1f1a420d48db619756bd5300abdbcb6486ce9f","tokens":1146,"chars":4582,"crawler":"hive-genesis","verified":"exact","ts":1791112138715,"text":"Anchor Docs\nGithub Discord Stack Exchange\nProgram Development\nAnchor Version Manager\nAVM reference documentation\nAnchor Version Manager (avm) is provided to manage multiple installations of the\nanchor-cli binary. This may be required to produce verifiable builds, or if\nyou'd prefer to work with an alternate version.\nAnchor version manager\nUSAGE:\navm < SUBCOMMAN D >\nOPTIONS:\n-h, --help Print help information\n-V, --version Print version information\nSUBCOMMANDS:\nhelp Print this message or the help of the given subcommand ( s )\ninstall Install a version of Anchor\nlist List available versions of Anchor\nuninstall Uninstall a version of Anchor\nupdate Update to the latest Anchor version\nuse Use a specific version of Anchor\nsolana Resolve or install the Solana CLI for the current project\nplatform-tools Inspect or manage the Solana platform-tools toolchain\nself-update Update avm itself to the latest version\nInstall\navm install < VERSION_OR_COMMI T >\nInstall the specified version of anchor-cli. The version argument should follow\nsemver versioning. It is also possible to use latest as the version argument\nto install the latest stable version, or latest-pre-release for the latest\npre-release:\navm install latest\navm install latest-pre-release\nIt's also possible to install based on a specific commit hash or a pre-release\nversion tag:\n# Specific pre-release\navm install 1.0.0-rc.3\n# -\navm install 0.30.1-cfe82aa682138f7c6c58bf7a78f48f7d63e9e466\n# Full commit hash\navm install cfe82aa682138f7c6c58bf7a78f48f7d63e9e466\n# Short commit hash\navm install cfe82aa\nList\navm list [--pre-release]\nList available versions. Pass --pre-release to include pre-release versions\nin the output:\navm list --pre-release\nUninstall\navm uninstall < versio n >\nUpdate\navm update [--pre-release]\nUpdate to the latest stable version. Pass --pre-release to allow updating to\nthe latest pre-release instead:\navm update --pre-release\nUse\navm use < versio n >\nUse a specific version. This version will remain in use until you change it by\ncalling the same command again. Similarly to avm install , you can use\nlatest or latest-pre-release for the version argument:\navm use latest\navm use latest-pre-release\nSolana\navm solana resolve\navm solana install [version] [--force]\nResolve or install the Solana CLI version for the current project. When no\nversion is passed to install , AVM first checks [toolchain] solana_version\nin Anchor.toml , then the solana-program dependency in Cargo.toml . If the\nproject does not pin Solana directly, AVM resolves the Anchor version and maps\nit to Anchor's recommended Solana version.\nProject Solana versions are parsed as semver requirements. AVM chooses the\nnewest hosted Solana CLI installer that satisfies the requirement; use an exact\ncomparator such as =4.1.2 to require one specific hosted version.\nWhen anchor is invoked through the AVM stub, AVM also ensures the resolved\nSolana CLI version is active before spawning the selected anchor-cli binary.\nPlatform Tools\navm platform-tools resolve\navm platform-tools install [version] [--force]\navm platform-tools list\navm platform-tools uninstall < versio n >\nResolve or manage the platform-tools version used by Solana's SBF toolchain.\nWhen no version is passed to install , AVM uses the project-resolved Solana\nversion and the embedded platform-tools map. If the Solana version is a semver\nrequirement, AVM considers hosted Solana CLI versions satisfying that\nrequirement and prefers one whose platform-tools rustc can compile the locked\nprogram dependency graph.\nAVM also queries the latest platform-tools release at most once every 24 hours\nand checks whether it is present in cargo build-sbf 's cache. If it is\nmissing, AVM prints the exact cargo build-sbf --install-only command needed\nto install it; it never installs the toolchain automatically.\nSelf-update\navm self-update [--pre-release] [--bleeding-edge]\nUpdate avm itself. By default installs the latest stable release of avm .\nFlag Description\n--pre-release Update to the latest pre-release version instead of the latest stable\n--bleeding-edge Build and install from the latest commit on the master branch (conflicts with --pre-release )\n# Update avm to latest stable\navm self-update\n# Update avm to latest pre-release\navm self-update --pre-release\n# Install from the tip of master\navm self-update --bleeding-edge\navm will also passively warn you when it detects that a newer version of\nitself is available.\nPrevious\nNO_DNA\nNext\nAccount Space\nOn this page\nInstall List Uninstall Update Use Solana Platform Tools Self-update\nEdit on GitHub"}
{"url":"https://docs.sei.io/learn/accounts","domain":"docs.sei.io","title":"Sei Network Accounts: Dual Address System Explained - Sei Docs","hash":"a377392256dfaf588a1c5943e87d463f37d646fd5c7aa7dd9e38f6b81519f3e6","tokens":5701,"chars":22804,"crawler":"crawler-v8wo","verified":"exact","ts":1791112137874,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nSei Docs home page\nLearn\nEVM\nCosmos-SDK\nNodes\nAI\nSei Network Accounts: Dual Address System Explained\nUnderstand how Seiâs unified account system works with both EVM (0x) and Cosmos (sei1) addresses, including association methods, security considerations, and cross-environment interactions.\nEvery account on Sei has a unique public key. You can use this public key to\ngenerate multiple wallet addresses, and these addresses are functionally the\nsame. They look different, but they both point to the same destination: your\naccount. Depending on the dApp, they may be used interchangeably. The difference\nis like the difference between the numeral â2â and the word âtwoâ. They both\ndefine the same value, but they may be used in different contexts.\n-\nâhexâ address : Starts with 0x and is EVM-based.\n-\nâbech32â address : Starts with sei1 and is used for Cosmos functions.\nAlthough these addresses look different, they share the same underlying\naccount. After the two addresses are linked through association (described\nbelow), any action that you take with one address also affects the other.\nAfter association, if you deposit funds into your EVM address, you can access\nand use the same funds with your Sei address. The reverse is also true. The two\naddresses behave as one account. Until the addresses are associated, they are\ntreated as separate accounts with separate balances (see Before linking\nbelow).\nBoth addresses of an account are derived from the same public key . The chain can recognize the link between them only after it knows the public key . The chain learns the public key through association.\nKey points\nBefore linking\n- The Bech32 ( sei... ) and EVM ( 0x... ) addresses are treated as separate\naccounts .\n- They have separate balances until they are linked.\n- If the EVM address receives Cosmos tokens before association, a temporary\nCosmos Bech32 address holds them. The tokens transfer to the associated\naddress when the addresses are linked.\n- Some types of transactions are not possible (see the table below).\nAfter linking\n- Both addresses show the same balance.\n- Applications can query either address format.\nWallet association and transfer limitations\nSome actions are not possible before the wallets are associated:\n- Transfers of CW-based tokens (for example, CW20, CW721, and CW1155) from a\nnon-EVM wallet to an unassociated EVM address .\n- Transfers of ERC-based tokens (for example, ERC-20, ERC-721, and ERC-1155)\nfrom an EVM wallet to an unassociated Cosmos address .\nMethods of association\nMethod Security risk User action required\n1. Broadcast a transaction Low Association happens automatically\n2. Direct private key High Use the private key directly\n3. Signed message Medium Sign a predefined message to prove ownership (recommended for wallets)\n4. Public key Low Send a compressed public key for association\nEach method makes the public key known to the chain. The chain then associates the EVM-compatible and Bech32 addresses automatically. All four methods go through the on-chain addr precompile ( 0x0000000000000000000000000000000000001004 ) or the EVM ante handler. They are available on every Sei EVM RPC.\nThe legacy sei_associate JSON-RPC method is no longer available. Method 3 offers the same wallet-signed-message flow through the addr precompile.\nYou can also find constants for the addr precompile in the\nSei-Chain/precompiles repository.\nMethod 1: Broadcast a transaction\n- When an account broadcasts a transaction, such as a token transfer, its public\nkey is recorded on-chain.\n- After the public key is known, the EVM address and the Bech32 address are\nlinked automatically.\n- As a result, balances and transactions are accessible from both address\nformats.\nMethod 2: Direct private key association\nSecurity risk : High . This method requires direct access to the private key. An exposed private key can compromise the wallet.\nThis method uses the private key directly to interact with the network.\nimport { createPublicClient , createWalletClient , http } from 'viem' ;\nimport { privateKeyToAccount } from 'viem/accounts' ;\nimport { seiTestnet } from 'viem/chains' ;\nimport { ADDRESS_PRECOMPILE_ABI , ADDRESS_PRECOMPILE_ADDRESS } from '@sei-js/precompiles' ;\nconst PRIVATE_KEY = '' ;\nconst publicClient = createPublicClient ({\nchain: seiTestnet ,\ntransport: http ()\n});\nconst client = createWalletClient ({ chain: seiTestnet , transport: http () });\nconst account = privateKeyToAccount ( PRIVATE_KEY );\nconst response = await client . writeContract ({\naccount ,\naddress: ADDRESS_PRECOMPILE_ADDRESS ,\nabi: ADDRESS_PRECOMPILE_ABI ,\nfunctionName: 'associate' ,\nargs: [ '0' , '0' , '0' , 'example_message' ],\ngasPrice: BigInt ( 100_000_000_000 )\n});\nconsole . log ( response );\nMethod 3: Associate via signed message\nSecurity risk : Medium . This method requires you to sign a specific message with the private key.\nIn this method, you sign a predefined message to prove that you own the account.\nimport { createWalletClient , http , parseSignature , toHex } from 'viem' ;\nimport { privateKeyToAccount , generatePrivateKey } from 'viem/accounts' ;\nimport { seiTestnet } from 'viem/chains' ;\nimport { ADDRESS_PRECOMPILE_ABI , ADDRESS_PRECOMPILE_ADDRESS } from '@sei-js/precompiles' ;\nconst client = createWalletClient ({ chain: seiTestnet , transport: http () });\nconst associate = async () => {\nconst account = privateKeyToAccount ( '' );\nconst newPk = generatePrivateKey ();\nconst newAccount = privateKeyToAccount ( newPk );\nconst message = 'associate' ;\nconst signature = await newAccount . signMessage ({ message });\nconst parsedSignature = parseSignature ( signature );\nconst customMessage = ` \\x19 Ethereum Signed Message: \\n ${ message . length }${ message } ` ;\nconst response = await client . writeContract ({\naccount ,\naddress: ADDRESS_PRECOMPILE_ADDRESS ,\nabi: ADDRESS_PRECOMPILE_ABI ,\nfunctionName: 'associate' ,\nargs: [ toHex ( Number ( parsedSignature . v ) - 27 ), parsedSignature . r , parsedSignature . s , customMessage ],\ngasPrice: BigInt ( 100_000_000_000 )\n});\nconsole . log ( response );\n};\nassociate ();\nMethod 4: Associate via public key\nSecurity risk : Low . This method uses the public key, which is less sensitive than the private key.\nThis method compresses the public key and sends it for association.\nimport secp256k1 from 'secp256k1' ;\nimport { createWalletClient , http } from 'viem' ;\nimport { privateKeyToAccount , generatePrivateKey } from 'viem/accounts' ;\nimport { seiTestnet } from 'viem/chains' ;\nimport { ADDRESS_PRECOMPILE_ABI , ADDRESS_PRECOMPILE_ADDRESS } from '@sei-js/precompiles' ;\nconst client = createWalletClient ({ chain: seiTestnet , transport: http () });\nconst associateViaPubkey = async () => {\nconst account = privateKeyToAccount ( '' );\nconst newPk = generatePrivateKey ();\nconst newAccount = privateKeyToAccount ( newPk );\nconst publicKeyBuffer = Buffer . from ( newAccount . publicKey . slice ( 2 ), 'hex' );\nconst compressedPubKey = secp256k1 . publicKeyConvert ( publicKeyBuffer , true );\nconst response = await client . writeContract ({\naccount ,\naddress: ADDRESS_PRECOMPILE_ADDRESS ,\nabi: ADDRESS_PRECOMPILE_ABI ,\nfunctionName: 'associatePubKey' ,\nargs: [ Buffer . from ( compressedPubKey ). toString ( 'hex' )],\ngasPrice: BigInt ( 100_000_000_000 )\n});\nconsole . log ( response );\n};\nassociateViaPubkey ();\nQuery linked addresses\nTo resolve either side of an existing association, call the addr precompile at 0x0000000000000000000000000000000000001004 with a standard eth_call . The precompile is available on every Sei RPC.\nFetch Bech32 address for an EVM address\ncurl -X POST $SEIEVM -H \"Content-Type: application/json\" -d '{\n\"jsonrpc\": \"2.0\",\n\"method\": \"eth_call\",\n\"params\": [{\n\"to\": \"0x0000000000000000000000000000000000001004\",\n\"data\": \"0x0c3c20ed000000000000000000000000\"\n}, \"latest\"],\n\"id\": 1\n}'\nThe selector 0x0c3c20ed is getSeiAddr(address) . The call returns the bech32 sei1⊠address as an ABI-encoded string. If the EVM address is not associated yet, the call reverts.\nIn TypeScript with viem:\nimport { createPublicClient , http } from 'viem' ;\nimport { sei } from 'viem/chains' ;\nconst ADDR_PRECOMPILE = '0x0000000000000000000000000000000000001004' ;\nconst ADDR_ABI = [\n{ name: 'getSeiAddr' , type: 'function' , stateMutability: 'view' ,\ninputs: [{ name: 'addr' , type: 'address' }],\noutputs: [{ name: 'response' , type: 'string' }] },\n{ name: 'getEvmAddr' , type: 'function' , stateMutability: 'view' ,\ninputs: [{ name: 'addr' , type: 'string' }],\noutputs: [{ name: 'response' , type: 'address' }] },\n] as const ;\nconst client = createPublicClient ({ chain: sei , transport: http () });\nconst seiAddr = await client . readContract ({\naddress: ADDR_PRECOMPILE ,\nabi: ADDR_ABI ,\nfunctionName: 'getSeiAddr' ,\nargs: [ '0xâŠ' ],\n});\nFetch EVM address for a Sei address\nconst evmAddr = await client . readContract ({\naddress: ADDR_PRECOMPILE ,\nabi: ADDR_ABI ,\nfunctionName: 'getEvmAddr' ,\nargs: [ 'sei1âŠ' ],\n});\nIf the address has never been associated, the precompile reverts. Handle the revert as a ânot linkedâ result instead of re-throwing it.\nDeriving addresses from the public key\nBoth address formats come from the same secp256k1 public key, but they use\ndifferent hashing schemes . The bech32 ( sei1⊠) side follows the standard\nCosmos derivation ( SHA256 then RIPEMD160 of the compressed public key).\nThe EVM ( 0x⊠) side follows the standard Ethereum derivation ( keccak256 of\nthe uncompressed public key without its 0x04 prefix byte).\nSei address derivation\nThe Cosmos address is derived from the public key in these steps:\n- Take the compressed secp256k1 public key (33 bytes, with a first byte of 0x02 or 0x03 ).\n- Hash it with SHA256 .\n- Hash the result with RIPEMD160 to get a 20-byte digest.\n- Encode that digest in Bech32 format with the sei prefix.\nExample implementation:\nimport { bech32 } from 'bech32' ;\nimport { sha256 } from '@noble/hashes/sha256' ;\nimport { ripemd160 } from '@noble/hashes/ripemd160' ;\n/**\n* @param compressedPublicKey 33-byte secp256k1 pubkey in compressed form\n*/\nexport function deriveSeiAddress ( compressedPublicKey : Uint8Array ): string {\nconst digest = ripemd160 ( sha256 ( compressedPublicKey ));\nreturn bech32 . encode ( 'sei' , bech32 . toWords ( digest ));\n}\nEVM address derivation\nThe EVM-compatible address is derived in these steps:\n- Take the uncompressed secp256k1 public key (65 bytes, with a first byte of 0x04 ).\n- Drop the leading 0x04 prefix byte, so that the input to the hash is the bare 64-byte (x, y) coordinate pair.\n- Hash these bytes with keccak256 .\n- Take the last 20 bytes of the hash and format them as 0x⊠hex.\nExample implementation:\nimport { keccak_256 } from '@noble/hashes/sha3' ;\n/**\n* @param uncompressedPublicKey 65-byte secp256k1 pubkey in uncompressed form (leading 0x04)\n*/\nexport function deriveEVMAddress ( uncompressedPublicKey : Uint8Array ): string {\nconst hash = keccak_256 ( uncompressedPublicKey . slice ( 1 ));\nreturn `0x ${ Buffer . from ( hash . slice (- 20 )). toString ( 'hex' ) } ` ;\n}\nSummary\n- Sei address : bech32('sei', RIPEMD160(SHA256(compressedPubKey))) (20 bytes, Cosmos-standard derivation).\n- EVM address : '0x' + keccak256(uncompressedPubKey[1:])[-20:] (the last 20 bytes of the keccak256 hash, Ethereum-standard derivation).\n- The two formats share an account because the chain stores the public key itself on association. Either format can be derived deterministically from the public key.\nWhy it works\nBoth formats are deterministic address schemes derived from the public key. The\npublic key is recorded on-chain through any of the four association methods\nabove, or implicitly through a first signed transaction. After that, the chain can derive\nboth formats itself and route any incoming reference to the same account.\nRecap\n- Accounts are linked automatically when a transaction is broadcast. You can\nalso associate them manually through the addr precompile ( associate or\nassociatePubKey ).\n- Both address formats share the same public key .\n- After linking, dApps and tools can access balances consistently across both\naddress formats.\nHD paths and coin types\nWhen you derive a private key from a mnemonic phrase, the hierarchical\ndeterministic (HD) path has multiple parameters, including the coin type. The\ncoin type determines the blockchain ecosystem that the key is derived for. This\nmatters when you work with different wallets and blockchains.\nCoin type parameter\nThe second parameter in the HD path specifies the coin type, which the BIP-44\nstandard defines. This parameter identifies the blockchain ecosystem of the\nderived keys.\n- Ethereum (coin type 60) : Wallets such as MetaMask use coin type 60. The\ntypical HD path for Ethereum is m/44'/60'/0'/0/0 .\n- Cosmos (coin type 118) : Wallets for Cosmos-based chains, such as OKX,\nuse coin type 118. The typical HD path for Cosmos is m/44'/118'/0'/0/0 .\nImplications\nYou cannot use an Ethereum mnemonic phrase (coin type 60) directly in a Cosmos\nwallet (coin type 118) to access the same accounts. The HD path determines a\ndifferent set of keys for each coin type, so the derived addresses differ.\nPrivate key export\nYou can export your private key from MetaMask (derived with coin type 60) and\nimport it into any Cosmos wallet. This works because a derived private key can\nbe used across different blockchain ecosystems, if the receiving wallet supports\nthe import function. You can then manage your assets across various blockchains\nwith the same underlying cryptographic key.\nExample HD paths\n- Traditional Cosmos path : m/44'/118'/0'/0/0\n- Traditional EVM path : m/44'/60'/0'/0/0\nGenerating wallets\nDeriving bech32 and hex addresses from pubkey\nSei derives a bech32 address (Cosmos and Tendermint style) and a hex address\n(Ethereum style) from the same public key. Each format uses its own hashing\nscheme. The bech32 address uses the Cosmos-standard\nSHA256 then RIPEMD160 . The hex address uses the keccak256 method, which is\ncommon in EVM networks. These snippets have detailed comments. They show the\ncorrect method to derive both bech32 and hex addresses from a given ECDSA\nsecp256k1 key:\nPython - from pubkey\nimport base64\nimport json\nfrom hashlib import sha256, new as hashlib_new\nfrom coincurve import PublicKey\nfrom bech32 import bech32_encode, convertbits\nfrom Crypto.Hash import keccak\n# Example input, replace with the actual pubkey JSON string\npubkey_json = '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Agmik4xkmF57hNjzykYHP3gRu1Mpae4B5BCiwx7jmRzI\"}'\n# Extract the base64-encoded key from the JSON-like string\npubkey_dict = json.loads(pubkey_json)\npubkey_base64 = pubkey_dict[ 'key' ]\n# Decode the base64-encoded public key\npublic_key_compressed = base64.b64decode(pubkey_base64)\n# Ensure the public key length is 33 bytes (compressed key format)\nif len (public_key_compressed) != 33 :\nraise ValueError ( f \"Invalid public key length, expected 33 bytes for compressed format, got { len (public_key_compressed) } \" )\n# Debugging: Print the public key details\nprint ( f \"Compressed public key (hex): { public_key_compressed.hex() } \" )\n# SHA-256 on the compressed public key\nsha256_digest = sha256(public_key_compressed).digest()\n# Debugging: Print SHA-256 digest\nprint ( f \"SHA-256 Digest: { sha256_digest.hex() } \" )\n# RIPEMD-160 on SHA-256 hash\nripemd160 = hashlib_new( 'ripemd160' )\nripemd160.update(sha256_digest)\nripemd160_digest = ripemd160.digest()\n# Debugging: Print RIPEMD-160 digest\nprint ( f \"RIPEMD-160 Digest: { ripemd160_digest.hex() } \" )\n# Convert the digest to 5-bit groups for Bech32 encoding\nfive_bit_ripemd160 = convertbits(ripemd160_digest, 8 , 5 , pad = True )\nbech32_address = bech32_encode( \"sei\" , five_bit_ripemd160)\nprint ( f \"Bech32 Cosmos Address: { bech32_address } \" )\n# Decompress the public key to 65 bytes\npublic_key = PublicKey(public_key_compressed).format( compressed = False )\n# Debugging: Print the public key details\nprint ( f \"Decompressed public key length: { len (public_key) } \" )\nprint ( f \"Decompressed public key (hex): { public_key.hex() } \" )\n# Derive Ethereum Address using Keccak-256\nkeccak_hash = keccak.new( digest_bits = 256 )\nkeccak_hash.update(public_key[ 1 :]) # Exclude the first byte (0x04)\ndigest_keccak = keccak_hash.digest()\neth_address = digest_keccak[- 20 :]\neth_address_hex = '0x' + eth_address.hex()\nprint ( f \"Ethereum Address: { eth_address_hex } \" )\nTypeScript - from pubkey\nimport { fromBase64 } from '@cosmjs/encoding' ;\nimport { sha256 } from '@noble/hashes/sha256' ;\nimport { ripemd160 } from '@noble/hashes/ripemd160' ;\nimport { keccak_256 } from '@noble/hashes/sha3' ;\nimport { secp256k1 } from '@noble/curves/secp256k1' ;\nimport { bech32 } from 'bech32' ;\n// Utility function to convert bits for Bech32 encoding\nfunction convertBits ( data : Uint8Array , fromBits : number , toBits : number , pad : boolean ): number [] {\nlet acc = 0 ;\nlet bits = 0 ;\nconst result : number [] = [];\nconst maxv = ( 1 << toBits ) - 1 ;\nfor ( const value of data ) {\nacc = ( acc << fromBits ) | value ;\nbits += fromBits ;\nwhile ( bits >= toBits ) {\nbits -= toBits ;\nresult . push (( acc >> bits ) & maxv );\n}\nif ( pad ) {\nif ( bits > 0 ) {\nresult . push (( acc << ( toBits - bits )) & maxv );\n}\n} else if ( bits >= fromBits || ( acc << ( toBits - bits )) & maxv ) {\nthrow new Error ( 'Unable to convert bits' );\n}\nreturn result ;\n}\n// Define the prefix for the Bech32 address (e.g., \"sei\" for Sei network)\nconst chainPrefix = 'sei' ;\n// Public key JSON string (replace with actual data)\nconst pubkeyJson = '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"AiN+aFvHgjblWPaP9Er5p005JjPX3nj4I/+jA6W4BOho\"}' ;\n// Parse the JSON string to extract the public key in Base64 format\nconst pubkeyDict = JSON . parse ( pubkeyJson );\nconst pubkeyBase64 = pubkeyDict . key ;\nconsole . log ( 'Original public key JSON:' , pubkeyJson );\nconsole . log ( 'Parsed public key object:' , pubkeyDict );\nconsole . log ( 'Base64-encoded public key:' , pubkeyBase64 );\n// Decode the Base64-encoded public key to its compressed form\nconst publicKeyCompressed = fromBase64 ( pubkeyBase64 );\nconsole . log ( 'Compressed public key (bytes):' , publicKeyCompressed );\nconsole . log ( 'Compressed public key (hex):' , Buffer . from ( publicKeyCompressed ). toString ( 'hex' ));\n// Perform SHA-256 hashing on the compressed public key\nconst sha256Digest = sha256 ( publicKeyCompressed );\nconsole . log ( 'SHA-256 hash of public key (hex):' , Buffer . from ( sha256Digest ). toString ( 'hex' ));\n// Perform RIPEMD-160 hashing on the SHA-256 digest\nconst ripemd160Digest = ripemd160 ( sha256Digest );\nconsole . log ( 'RIPEMD-160 hash of SHA-256 hash (hex):' , Buffer . from ( ripemd160Digest ). toString ( 'hex' ));\n// Convert the RIPEMD-160 digest to a 5-bit array for Bech32 encoding\nconst fiveBitArray = convertBits ( ripemd160Digest , 8 , 5 , true );\n// Encode the 5-bit array into a Bech32 address with the specified prefix\nconst bech32Address = bech32 . encode ( chainPrefix , fiveBitArray );\nconsole . log ( `Bech32 Cosmos Address: ${ bech32Address } ` );\n// Decompress the public key to its uncompressed form (65 bytes) and exclude the first byte\nconst publicKeyUncompressed = secp256k1 . ProjectivePoint . fromHex ( publicKeyCompressed ). toRawBytes ( false ). slice ( 1 );\n// Perform Keccak-256 hashing on the uncompressed public key to derive the Ethereum address\nconst keccakHash = keccak_256 ( publicKeyUncompressed );\nconst ethAddress = '0x' + Buffer . from ( keccakHash . slice (- 20 )). toString ( 'hex' );\nconsole . log ( 'Uncompressed public key (hex):' , Buffer . from ( publicKeyUncompressed ). toString ( 'hex' ));\nconsole . log ( 'Keccak-256 hash of uncompressed public key (hex):' , Buffer . from ( keccakHash ). toString ( 'hex' ));\nconsole . log ( `Ethereum Address: ${ ethAddress } ` );\nTypeScript - full derivation from private key\nimport { sha256 } from '@noble/hashes/sha256' ;\nimport { ripemd160 } from '@noble/hashes/ripemd160' ;\nimport { keccak_256 } from '@noble/hashes/sha3' ;\nimport { secp256k1 } from '@noble/curves/secp256k1' ;\nimport { bech32 } from 'bech32' ;\n// Utility function to convert bits for Bech32 encoding\nfunction convertBits ( data : Uint8Array , fromBits : number , toBits : number , pad : boolean ): number [] {\nlet acc = 0 ;\nlet bits = 0 ;\nconst result : number [] = [];\nconst maxv = ( 1 << toBits ) - 1 ;\nfor ( const value of data ) {\nacc = ( acc << fromBits ) | value ;\nbits += fromBits ;\nwhile ( bits >= toBits ) {\nbits -= toBits ;\nresult . push (( acc >> bits ) & maxv );\n}\nif ( pad ) {\nif ( bits > 0 ) {\nresult . push (( acc << ( toBits - bits )) & maxv );\n}\n} else if ( bits >= fromBits || ( acc << ( toBits - bits )) & maxv ) {\nthrow new Error ( 'Unable to convert bits' );\n}\nreturn result ;\n}\n// Function to generate addresses from a private key\nfunction generateAddresses ( privateKeyHex : string ): {\nseiAddress : string ;\nethAddress : string ;\n} {\n// Ensure the private key is exactly 32 bytes long\nconst privateKey = Uint8Array . from ( Buffer . from ( privateKeyHex . padStart ( 64 , '0' ), 'hex' ));\nif ( privateKey . length !== 32 ) {\nthrow new Error ( 'Private key must be 32 bytes long.' );\n}\n// Derive the compressed public key from the private key\nconst publicKey = secp256k1 . getPublicKey ( privateKey , true );\nconst publicKeyBytes = publicKey ;\n// Perform SHA-256 hashing on the compressed public key\nconst sha256Digest = sha256 ( publicKeyBytes );\n// Perform RIPEMD-160 hashing on the SHA-256 digest\nconst ripemd160Digest = ripemd160 ( sha256Digest );\n// Convert the RIPEMD-160 digest to a 5-bit array for Bech32 encoding\nconst fiveBitArray = convertBits ( ripemd160Digest , 8 , 5 , true );\n// Bech32 address with \"sei\" prefix\nconst seiAddress = bech32 . encode ( 'sei' , fiveBitArray , 256 );\n// Derive the uncompressed public key from the private key and exclude the first byte\nconst publicKeyUncompressed = secp256k1 . getPublicKey ( privateKey , false ). slice ( 1 );\n// Perform Keccak-256 hashing on the uncompressed public key to derive the Ethereum address\nconst keccakHash = keccak_256 ( publicKeyUncompressed );\nconst ethAddress = `0x ${ Buffer . from ( keccakHash ). slice (- 20 ). toString ( 'hex' ) } ` ;\nreturn { seiAddress , ethAddress };\n}\n// Example usage of the generateAddresses function\nconst privateKeyHex = '907ab4bf7fc60cff' ;\nconst { seiAddress , ethAddress } = generateAddresses ( privateKeyHex );\nconsole . log ( `Sei Address: ${ seiAddress } ` );\nconsole . log ( `Ethereum Address: ${ ethAddress } ` );\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ens.domains/dao/foundation","domain":"docs.ens.domains","title":"The ENS Foundation | ENS Docs","hash":"224c4886bd101c52791b9642c655decec941e20d821ff48a9f2eee67db44f708","tokens":740,"chars":2959,"crawler":"crawler-v8wo","verified":"exact","ts":1791112139656,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\nThe ENS Foundation\nWhy have a legal entity?\nHaving a legal entity that represents the DAO in the \"real world\" is valuable for a number of reasons:\n- It provides limited liability to DAO participants for the actions of the DAO. Without a legal entity, participants may be individually held liable for anything the DAO as a whole does.\n- It is capable of complying with taxation requirements - without a legal entity, DAO participants may be held liable for a proportion of the DAO's income, even if they are not able to access these funds.\n- It is capable of entering into contracts with other \"real world\" entities, of holding assets (including IP rights), and so forth.\nFor a more detailed discussion of this topic, see this excellent blog post .\nWhat is The ENS Foundation?\nThe ENS Foundation is a Foundation Company Limited By Guarantee, incorporated in the Cayman Islands. Foundation companies are nonprofits; The ENS Foundation has no shareholders and cannot pay out dividends to its directors or members. For more details on how foundations work, see this article .\nThe ENS Foundation has three directors: Nick Johnson, Kevin Gaspar, and Alex Van de Sande. Directors are in charge of the day-to-day running of the foundation.\nThe ENS Foundation has one supervisor. The supervisor is an administrative role whose job is to make sure that the directors are doing their jobs in accordance with Cayman Islands law. The position of supervisor is filled by a Cayman Islands firm, DS Limited.\nThe ENS Foundation's Articles of Incorporation give significant powers to the ENS DAO (referred to as \"The Council\" in the Articles). The DAO may vote to:\n- Appoint or remove a director, member, or supervisor.\n- Prohibit admitting any members in future.\n- Instruct the directors to wind up the foundation, and specify what charity or other foundation should receive the foundation's assets.\nThough not specified directly in the Articles, the DAO may also instruct the directors to take action on behalf of the Foundation - such as signing a contract, engaging a company for a service the DAO requires, or delegating some of the directors' powers to a DAO working group.\nFoundation Expenses\nRunning a Foundation is not free, and comes with some real-world costs. An incomplete list of anticipated expenses includes:\n- Registered Office & Secretary Services: $10,000 USD p/a\n- Supervisory Services: $30,000 USD p/a\n- Agent for service of process: $1,200 USD p/a\n- Companies Register Fees: $850 USD p/a\nThe Directors may ask the DAO for reimbursement of these fees when they are incurred so that the Foundation can continue to operate.\nDocuments\nFor transparency, important documents relating to the Foundation can be found below. Meeting minutes, resolutions, accounts, and other documentation will be uploaded here as it is made available to the directors."}
{"url":"https://docs.celestia.org/build/private-blockspace/about/","domain":"docs.celestia.org","title":"Celestia Documentation","hash":"be3cb89a4c61b3b61f71c16d15accc5c8e691e4823cc49b634f7f9bd31e18478","tokens":1610,"chars":6438,"crawler":"hive-genesis","verified":"exact","ts":1791112140716,"text":"Skip to Content\nBuild Private blockspace About\nAbout Private Blockspace\nThe highest-stakes onchain marketsâincluding perpetual exchanges, order books, and institutional railsâdepend on information that cannot be public. Positions, balances, liquidations, and routing logic are inherently sensitive. Yet pushing that data offchain reintroduces trusted operators and weakens the core promise of being onchain: independent auditing, verifiability, and safe exits when it matters most.\nPrivate Blockspace is Celestiaâs approach to solving this problem: keep sensitive state confidential , while still making it publicly accountable .\nPrivate Blockspace enables networks to publish encrypted state to Celestia , allowing anyone to verify data availability and protocol commitments without revealing the underlying contents . The result is private systems with public verifiability guarantees âfault-resistant, auditable, and designed to support safe exit mechanisms.\nAt a high level, Private Blockspace adds an encryption + proof layer between your application and Celestiaâs data availability layer. This layer is implemented as the Private Blockspace Proxy : a lightweight service that encrypts, proves, and routes data without modifying existing Celestia integrations .\nSubmitting a blob\nThe Private Blockspace Proxy acts as an intermediary between your JSON-RPC client and the Celestia network.\nWhen you submit a blob:\n- The proxy encrypts the data.\n- The proxy generates a proof inside a zkVM attesting to correct encryption and any configured âanchorsâ about the plaintext.\n- The proxy stores the job result in a local database and returns an acknowledgement while processing continues.\n- Once the proof completes, the result is cached so identical submissions can return immediately.\n- The proxy submits the verifiably encrypted blob to Celestia via blob.Submit .\nFrom the clientâs perspective, posting encrypted data feels like a single RPC call, while the proxy handles encryption, verifiability, and coordination with Celestia behind the scenes.\nRetrieving a blob\nWhen retrieving a blob, the proxy behaves as a transparent relay:\n- The client calls blob.Get(height, namespace, commitment) .\n- The proxy forwards the request to a Celestia node.\n- The proxy receives the raw blob response.\n- The proxy attempts to deserialize and decrypt using the configured encryption key.\nIf the blob was encrypted through the proxy, decryption succeeds and the proxy returns the original plaintext bytes. If it was not, the proxy passes the response through unchanged.\nThis ensures compatibility with both encrypted and unencrypted blobs, so existing clients can adopt Private Blockspace incrementally.\nVerifiable Encryption (VE)\nWith normal encryption, ciphertext should be indistinguishable from random noise. That property is what keeps data privateâbut it also makes it difficult to prove anything about encrypted data without decrypting it.\nPrivate Blockspace uses Verifiable Encryption (VE) to bridge this gap.\nVE enables proofs of select properties of fully encrypted data without decryption . For example, a system can prove statements like:\n- âThis encrypted blob contains a Merkle proof whose root is 0xabc123⊠â\n- âThis ciphertext was produced using the expected algorithm, key format, and nonce rulesâ\n- âThe plaintext hashes to a specific commitmentâ\nThis is accomplished by running encryption inside a zkVM, producing a proof that encryption was executed correctly while also exposing application-defined âanchorsâ (such as hashes or commitment checks) that remain safe to reveal.\nOutcome: anyone can verify availability and correctness constraints, while only authorized parties can decrypt the underlying contents.\nKey exchange and management strategies\nA critical design question in Private Blockspace is key management:\nIf keys are withheld, then the data is effectively withheld.\nPrivate Blockspace is designed to support different key exchange and reconstruction strategies depending on your application requirements and threat model.\nAccount-centric model\nA proposed account-centric model enforces that all account state is published and available , while also being encrypted such that only the intended party (or parties) can decrypt.\nKey properties of this approach:\n- User-defined encryption keys: users define keys for encrypting their own account state, ensuring they can always decrypt their data and enabling forward secrecy.\n- Conditional selective disclosure: users can allow decryption by specific parties using standard public key cryptography, key exchange protocols, and/or threshold schemes.\n- User-initiated protocol progression: applications can allow users to progress the protocol themselves by proving correct state transitions onchain, enabling âforcedâ state updates such as withdrawals.\nThis model is designed to support systems that remain private during normal operation, while still enabling safe exits and recovery paths under application-defined conditions.\nUse cases\nPrivate Blockspace is designed for applications where privacy is required , but public accountability cannot be sacrificed .\nAccountable offchain exchanges\nOperators of offchain or hybrid exchanges can keep internal state private while still being required (by protocol design) to prove state availability and commitments publicly.\nThis improves fault tolerance and auditability without forcing users to trust an opaque operator for safe exits.\nIn production: Hibachi\nHibachi is the first independent deployment using Private Blockspace for a fast perps exchange. Hibachi publishes verifiably encrypted exchange state to Celestia, keeping balances and positions private while making data availability and correctness publicly verifiable.\nTrust-minimized data marketplaces\nPrivate Blockspace can also support trust-minimized private data markets:\n- sellers publish verifiably encrypted data to Celestia\n- buyers verify availability and integrity before paymentâwithout seeing the plaintext\n- payment is enforced only once availability is proven\nThis shifts trust away from intermediaries and toward verification, producing private exchange workflows that are auditable and fault-resistant by design.\nReferences and further reading\n- Private Blockspace Proxy repo on GitHub\n- Verifiable Encryption (VE) in depth\n- Forum post: Account-centric model\nFeel stuck? Go to our Discord!\nLast updated on October 1, 2026\nRust client Quickstart"}
{"url":"https://docs.ens.domains/web/subgraph","domain":"docs.ens.domains","title":"Subgraph | ENS Docs","hash":"ba171f376e4db665462ac29dda7e90997828feb2e745b79d558c59cf53f7d86e","tokens":771,"chars":3081,"crawler":"crawler-v8wo","verified":"exact","ts":1791112141327,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\nSubgraph\nThis is a page covering the graph's ENS subgraph. The ENS subgraph indexes onchain events of second-level .eth names, and DNS imported names.\nIt allows us to build a reasonable approximation of the ENS names an address owns.\nTo read more about why not all names (such as Offchain & Gasless Names) show up in the subgraph read the listing names page.\nThe Graph\nThe Graph is a protocol for indexing and querying data from blockchains. There are multiple subgraphs that you can use to query information about ENS names.\nThese subgraphs are available for mainnet , sepolia and holesky .\nGraphQL Schema\nThe schema for the ENS subgraph is defined in /schema.graphql .\nUse Cases\nThere are certain use cases where the graph is better for querying ENS specific information than through the resolution process.\nOne of such use-cases is querying which NFT names are owned by a specific address.\nTerminology\nWhen using the subgraph, you may encounter registrant and controller fields. These were the old terminology for Owner and Manager respectively.\nThe registrant address is the owner of a name. It's the same value that will be returned from calling ownerOf() on the Base Registrar Controller (registrar.ens.eth). A registrant/owner may transfer ownership and assign a controller/manager.\nThe controller address is the manager of a name. It's the same value that will be returned from calling owner() on the ENS Registry (registry.ens.eth). A controller/manager may change the resolver of a name and set its records.\nExample Queries\nYou can explore the following examples interactively via the Graph Explorer Playground\nGetting a list of names owned by an account\nEnsure the address is lowercase\nquery getDomainsForAccount {\ndomains ( where : { owner : \"0xa508c16666c5b8981fa46eb32784fccc01942a71\" }) {\nname\n}\nGetting the top domain for an account based on the longest registry\nquery getDomainForAccount {\naccount ( id : \"0xa508c16666c5b8981fa46eb32784fccc01942a71\" ) {\nregistrations ( first : 1 , orderBy : expiryDate , orderDirection : desc ) {\ndomain {\nname\n}\nid\n}\nreturns\n{\n\"data\" : {\n\"account\" : {\n\"registrations\" : [\n{\n\"domain\" : {\n\"name\" : \"datanexus.eth\"\n}\n],\n\"id\" : \"0xa508c16666c5b8981fa46eb32784fccc01942a71\"\n}\nSearching for a subdomain\nquery getSubDomains ( $Account : String = \"messari.eth\" ) {\ndomains ( where : { name : \"messari.eth\" }) {\nname\nid\nsubdomains ( first : 10 ) {\nname\n}\nsubdomainCount\n}\nreturns\n{\n\"data\" : {\n\"domains\" : [\n{\n\"name\" : \"messari.eth\" ,\n\"id\" : \"0x498ada62251a1227664ace8d97b0de2dcc6652ddf61e6fb5d3150f43ccf599e6\" ,\n\"subdomains\" : [\n{\n\"name\" : \"subgraphs.messari.eth\"\n},\n{\n\"name\" : \"bd.messari.eth\"\n}\n],\n\"subdomainCount\" : 2\n}\n]\n}\nGetting the expiry of an ENS domain\nquery getDomainExp ( $Account : String = \"paulieb.eth\" ) {\nregistrations (\nwhere : { domain_ : { name : $Account } }\nfirst : 1\norderBy : expiryDate\norderDirection : desc\n) {\nexpiryDate\n}\nreturns\n{\n\"data\" : {\n\"registrations\" : [\n{\n\"expiryDate\" : \"1714752524\"\n}\n]\n}"}
{"url":"https://docs.ens.domains/resolvers/interacting","domain":"docs.ens.domains","title":"Interacting with a Resolver | ENS Docs","hash":"09a49541b3eedcf4738f9e69dea3e2f04620a9f4eb3a91242738d417649463eb","tokens":722,"chars":2886,"crawler":"hive-genesis","verified":"exact","ts":1791112142311,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\nInteracting with a Resolver\nSet Addresses, Text Records, and more\nSome apps may want to allow for users to edit, update, or modify their name and its behaviour at a more advanced level.\nThis is possible by interacting with the resolver contract of a name directly.\nChecking Interface Support\nBefore you start sending transactions to users resolvers, you should check if they support the interface you want to use. This is done by calling the supportsInterface (see EIP-165 ) function on the resolver contract.\nfunction supportsInterface ( bytes4 interfaceID ) external pure returns ( bool )\nIn order to ensure that resolvers we interact with are compatible with specific standards you can call the above function on contracts with an interfaceID and then check the boolean it returns.\nInterface IDs are calculated according to solidity ABI and stored in a four-byte value.\nUpdating a User's Record\nIf you want to help a user set their avatar, specify a preferred color scheme, or set any other record on their ENS name you can do so in specific cases.\nFirst we need to check if the user's resolver supports the interface we want to use (see setText ).\nAfterwhich you can call the setText() function on the user's resolver contract.\nSolidity\ninterface Resolver {\nfunction setText ( bytes32 node , string calldata key , string calldata value ) external ;\n}\nNote that only the Manager of a name can set records on the resolver. For unwrapped names, the manager can be found by calling owner() on the ENS Registry. For wrapped names, the manager can be found by calling ownerOf() on the Name Wrapper. You can find the contract addresses here .\nUpdate a User's Resolver\nOverwriting a user's resolver involves overwriting the behaviour of their ENS name.\nTo change the resolver of a name, the Manager must call setResolver() on either the ENS Registry or the Name Wrapper, depending on whether the name is wrapped or not.\nTo figure out if a name is wrapped, call owner() on the ENS Registry. If this returns the address of the Name Wrapper, that indicates the name is wrapped and you should call ownerOf() on the Name Wrapper to get the effective owner of the name. You can find the contract addresses here .\nSolidity\n// Both the ENS Registry and the Name Wrapper implement this interface\ninterface ENS {\nfunction setResolver ( bytes32 node , address resolver ) external ;\n}\nPlease do not change the resolver for a user without their permission. Overwriting the resolver is a destructive action and will overwrite any existing resolution logic.\nLayer 2 & Offchain Resolvers\nAt the time of writing this the ecosystem around multichain and \"writing\" to layer 2 & offchain resolvers has yet to be standardized and is still under active development.\nPlease check back at a later date."}
{"url":"https://docs.berachain.com/general/proof-of-liquidity/reward-vaults","domain":"docs.berachain.com","title":"Reward Vaults - Berachain","hash":"499ab70a454c4e56616913a9f88fc3c9bd268f28a39003d20dead85cf5ccc83c","tokens":2144,"chars":8576,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112143459,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBerachain home page\nGeneral\nBEX\nBend\nBuild\nNodes\nProof of Liquidity\nReward Vaults\nWhere $WBERA emissions flow, how Reward Vault incentives work, and how vault rewards are claimed.\nReward Vaults are the PoL contracts where users stake eligible receipt tokens and earn allocated $WBERA rewards. Reward Vaults can receive emissions through validator allocation and, where applicable, Dedicated Emission Streams. Businesses and protocols attach incentive tokens to Reward Vaults to attract validator allocation. When a Reward Vault with active incentives receives emissions, those incentives are split between validator commission and the remaining incentives, which are converted through the Incentive Auction and accrued into $sWBERA.\nReward Vaults are key infrastructure for businesses and protocols to access PoL. A business or protocol can operate multiple vaults, each with its own PoL-eligible receipt asset â for example, separate BEX pools can each have their own Reward Vault.\nOnly governance-whitelisted Reward Vaults can receive PoL emissions. Depending on the route, emissions may be allocated through validator reward allocation or through Dedicated Emission Streams. See Reward Vault Requirements and Guidelines for whitelisting requirements. For staking on behalf of another address, see Delegation .\nStaking with a reward vault\nTo earn allocated $WBERA from a Reward Vault, a user stakes the PoL-eligible asset in that vault. The protocol that deployed the vault decides how users obtain the receipt token to stakeâtypically by providing liquidity.\n- The user takes an action that yields a PoL-eligible receipt token.\n- The user stakes that token in the corresponding Reward Vault.\n- The user earns a pro-rata share of $WBERA streamed to the vault, based on emission timing and vault rules.\nThe $WBERA amount a user earns from a Reward Vault depends on:\n- The userâs share of total assets staked in the vault.\n- The $WBERA emission rate and timing for that vault (see block rewards and emission modes below).\nAfter staking, users can claim rewards, add to their deposit, or withdraw subject to the vaultâs rules. Vault staking is designed to feel like familiar DeFi staking flows.\nReward Vault emissions pay $WBERA .\nThe RewardVaultHelper is an optional UX component\nthat converts $WBERA claims atomically into $sWBERA or native $BERA. Direct vault claims still\npay $WBERA.\nAt the protocol level (numbered to match the diagram above):\n- The user provides liquidity to the protocol or performs another PoL-eligible action.\n- The protocol issues the user a PoL-eligible receipt token.\n- The user stakes the receipt token in the corresponding Reward Vault.\n- The protocol funds the Reward Vault with incentive tokens to attract validator allocation.\n- An active validator produces a block and the Distributor receives the per-block emission.\n- The Distributor sends the $WBERA Reward Vault emission to the vault.\n- The user claims rewards as $sWBERA or native $BERA through RewardVaultHelper .\n- The Reward Vault pays validator commission out of the funded incentive tokens.\n- The Reward Vault redirects the remaining incentive tokens to the Incentive Auction , where they are converted into $BERA / $WBERA yield and accrued into $sWBERA.\nAfter staking, users can claim rewards, add stake, or withdraw based on vault rules.\nStaking on behalf of another address\nThe RewardVault supports delegation : one address (the delegate ) can stake on behalf of another (the account ). Common patterns include:\n- Custodial staking : exchanges or custodians staking on behalf of users.\n- Smart contract integration : protocols that stake user funds automatically.\n- Managed staking services : third parties operating staking on behalf of accounts.\nKey delegation concepts\n- Delegate : address that deposits and withdraws delegated stake ( msg.sender for those actions).\n- Account : address that owns the position and receives rewards.\n- Self-staked balance : stake deposited directly by the account.\n- Delegated balance : stake deposited by delegates for that account.\nOnly the account can withdraw self-staked balance. Delegates can withdraw only delegated stake they contributed.\nWBERA emission timing modes\nReward Vaults operate in one of two mutually exclusive modes for WBERA reward distribution timing (streamed rewards).\nDuration-based mode\nIn this mode, the rewardDurationManager sets a fixed rewardsDuration (typically 3â7 days). Each time $WBERA rewards are added to the vault via notifyRewardAmount , the $WBERA is distributed evenly over that period.\nDuration-based mode enforces the 3â7 day range: if you switch from target-rate mode where the computed duration exceeded 7 days, the duration is capped at 7 days.\nExample: If 100 $WBERA is added with a 5-day duration, the vault distributes 20 $WBERA per day to stakers.\nTarget rate mode\nWhen targetRewardsPerSecond is set to a non-zero value, the vault computes the distribution period for each $WBERA deposit. The vault keeps the effective emission rate from exceeding the target while respecting the minimum duration limit.\nperiod = max(minRewardDurationForTargetRate, totalReward / targetRate)\nThe duration is never shorter than the minimum (default 3 days), but can extend beyond 7 days if needed to maintain the target rate.\nSwitching between modes\nThe Reward Vault manager can switch between modes:\n- Set a positive target rate to keep WBERA streaming at that rate.\n- Set the target rate to zero to return to duration-based distribution.\nIncentive management\nReward Vaults support incentive tokens : additional tokens protocols attach so validators have a reason to allocate $WBERA emissions toward the vault.\nHow incentive tokens work\n- Whitelisting : incentive tokens are allowed through governance for the vault (see Incentive Marketplace ).\n- Rate setting : token managers set incentive rates per unit of allocated emission ( incentiveTokens = emissionAllocatedToVault * incentiveRate ).\n- Deposits : protocols fund incentive inventory into the vault system through the token manager flow.\n- Distribution : as $WBERA emissions are allocated to the vault, funded incentive tokens follow the PoL split: validator commission to the validator operator and redirected incentives to the incentive tokens collector for auction settlement .\nIncentives\nTo see why validators allocate $WBERA toward one vault over another, read Incentive Marketplace : protocols compete for validator reward allocation with funded incentives, validator commission, and auction-settled yield.\nVault creation\nNew Reward Vaults can be created permissionlessly at Berachain Hub .\nProtocols must still whitelist new vaults through governance for validator-allocated $WBERA emissions; see Reward Vault Guidelines .\nCalculating WBERA APR\nReward Vault APR depends on several observable inputs:\n- Vault rewardRate â $WBERA credited toward stakersâ claims per second (while active).\n- periodFinish â timestamp when the current vault reward period ends.\n- stakeToken â token staked into the Reward Vault.\n- totalSupply â total stakeToken amount staked in the vault.\n- Price of $WBERA (equivalent to $BERA) in USD.\n- Price of the stake token.\nIf periodFinish has passed, no rewards are being emitted for that period and vault APR from\nthat stream is 0% until new rewards are notified.\nUsing the normalized vault reward rate in $WBERA per second:\nA PR = ( t o t a lS u ppl y Ă p r i ce O f St ak e T o k e n ) ( v a u ltR e w a r d R a t e Ă seco n d s P er Y e a r Ă p r i ce O f W BER A )\nThis expresses the rate at which the vault credits depositors with $WBERA for the active reward period.\nExample\nParameter Value Normalized\nVault reward rate 272490527103681170793308992914391673 0.27249052710368116\nPrice of $WBERA $7.8 $7.8\nTotal supply 598626940947001140289 598.6269409470011\nPrice of stake token $223,845.58 $223,845.58\nSeconds per year 31,536,000 31,536,000\nUse normalized vault values from Hub or your indexer when calculating APR by hand.\nA PR = 598.6269409470011 Ă 223845.58 0.27249052710368116 Ă 31536000 Ă 7.8 â 0.5002 â 50.02%\nVault metrics on Hub Vaults refresh on a short cadence (roughly every few minutes).\nReward output\nReward Vaults accrue $WBERA by default. The RewardVaultHelper converts $WBERA atomically during claim, so stakers receive $sWBERA or native $BERA without a separate step.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.near.org/communities","domain":"docs.near.org","title":"Communities - NEAR Docs","hash":"513a4d8286eb6e60b71b2a39d42fac7302972a4a172751aaff0039808b4da4bc","tokens":632,"chars":2526,"crawler":"crawler-v8wo","verified":"exact","ts":1791112145063,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNEAR Docs home page\nHome\nProtocol\nSmart Contracts\nWeb3 Apps\nMulti-Chain\nTokens & Primitives\nData Infra\nRPC\nCommunities\nConnect with the NEAR community through various channels and join specialized communities.\nNEAR is a global community of Web3 enthusiasts and innovators. Connect with developers, builders, and founders across our social channels.\nTelegram\nDiscord\nGitHub\nX\nFrequently Asked Questions\nWhat is the expectation for a support resolution?\nUpon submitting a support ticket, you can expect to receive an initial response from our team within 72 hours during our business hours. Our business hours are on weekdays in the PST timezone, excluding US holidays.\nWhere can I find help to troubleshoot a development issue?\nSocial channels such as Telegram and Discord are a great resource to tap into for community support on development issues.\nWhere can I find funding for my project?\nYou can find information on grants and funding opportunities on the main NEAR portal .\nHow can I find out about the latest product developments?\nFollow NEAR on X for our latest product announcements or subscribe to NEAR Week to receive their weekly newsletter on ecosystem announcements.\nI found a bug â where can I flag this?\nFor any issues or concerns youâve encountered, please feel free to provide us with detailed information through our Bug Bounty Program . Your cooperation and additional details will assist us in addressing and resolving any potential vulnerabilities effectively. We appreciate your proactive approach in helping us maintain the security and integrity of the NEAR ecosystem.\nWhat happened to Near Wallet?\nAs we embrace a more decentralized future, wallet.near.org will be discontinued. This change invites you to discover a variety of new and secure wallet options within our ecosystem. Your funds are safe! Accounts exist on the blockchain, not in a wallet. Wallets are just an interface into using the blockchain with your account. Learn more\nQuestion about Transfer Exchange?\nFor issues relating to a third-party exchange, such as Binance or Coinbase, weâre unable to investigate issues on external platforms. To address your concern effectively, we recommend contacting the customer support team of the specific exchange where youâre experiencing issues. They are most equipped to assist you in resolving the matter.\nWas this page helpful?"}
{"url":"https://bitcoinops.org/en/topics/default-minimum-transaction-relay-feerates/","domain":"bitcoinops.org","title":"Default minimum transaction relay feerates | Bitcoin Optech","hash":"3fc2609cfc072d06b6b8f55e919ece64ded6bba1bef2451669ddc82f5de0c81d","tokens":312,"chars":1247,"crawler":"hive-genesis","verified":"unchecked","ts":1791112146052,"text":"/ home / topics /\nDefault minimum transaction relay feerates\nDefault minimum transaction relay feerates are the policy implemented by nodes for ignoring individual unconfirmed transactions whose feerate is below a certain amount. For Bitcoin Core, this threshold has for several years been 1 sat/vbyte.\nThis topic description is a stub. We would welcome a pull\nrequest\nproviding more background information about the topic.\nOptech newsletter and website mentions\n2025\n- Bitcoin Core #33106 lowers the default minimum relay fee from 1 sat/vbyte to 0.1 sat/vbyte\n- Continued discussion about lowering the default minimum transaction relay feerate\n- Renewed discussion about lowering the default minimum transaction relay feerate\n2022\n- Discussion about lowering the default minimum transaction relay feerate\n2019\n- Bitcoin Core #16507 fixes a rounding issue related to the minimum relay feerate\n2018\n- Bitcoin Core #13987 adds info about peersâ minimum feerates to getpeerinfo\n- Discussion about lowering the default minimum relay feerate\n- Accidentally creating transaction below the default min relay feerate\nSee also\n- Package relay\n-\nEphemeral anchors\nPrevious Topic:\nDandelion\nNext Topic:\nDifficulty adjustment algorithms\nEdit page\nReport Issue"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade/preparing","domain":"docs.pyth.network","title":"Completing the Pyth Core upgrade | Pyth Developer Hub","hash":"b4ed27cf2bee575f8ad76bc6d48424ec2ff2b94ec4eb16b507c735a870b24c7f","tokens":1362,"chars":5448,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112146880,"text":"Pyth Core upgrade completed successfully on August 26, 2026. Hermes now requires an API Key. Get yours â\nFeed updates\nCommodities.RSV6/USc removed Commodities.BRENTX6/USD removed Crypto.ORBIO/USD added Equity.CN.603416/CNY added Equity.CN.603906/CNY added Equity.CN.300376/CNY added Equity.CN.002683/CNY added Equity.TW.8046/TWD added Equity.TW.2408/TWD added Equity.CN.300308/CNY added Equity.TW.2451/TWD added Equity.TW.2344/TWD added Equity.US.IBB/USD added Crypto.Index.ZTPLUS/USD added\nView all\nDeveloper Hub\nCompleting the Pyth Core upgrade\nEverything 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- Your app calls hermes.pyth.network ?\nGet a Pyth API Key in Step 1.\n- You 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).\n- You only use a protocol that already integrates Pyth?\nNo action needed from your side.\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 manually\nThe \"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 .\nEarly upgrade (recommended) Automatic upgrade\nTiming You choose Happened on August 26, 2026 at 16:00 UTC\nDowntime Up to you Brief, during the switch\nHermes endpoint Switch to the new Hermes endpoint Keep using hermes.pyth.network , now with an API key\nContract address You swap to the upgraded Pyth Core Contract DAO upgraded the current Pyth Core Contract for you\nEarly upgrade\nThis is the recommended path: it moves your integration fully onto the upgraded endpoint and contracts.\nMove your Hermes calls to the new Hermes endpoint\nSwitch 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.\ncurl -H \"Authorization: Bearer $PYTH_API_KEY \" \\\n\"https://pyth.dourolabs.app/hermes/v2/updates/price/latest?ids[]=0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\"\nRoutes and response shapes are unchanged.\nThe upgraded endpoint is a drop-in replacement. See the new Hermes API reference for the full surface.\nPer-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.\nSwap your contract address\nSwap 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.\nView all upgraded Pyth Core Contract addresses .\nAfter the swap, your integration is fully on the upgraded stack.\nPer-chain guides\nEVM\nEVM-specific notes including ethers and viem usage.\nSui\nSui Move.toml change and package compatibility notes.\nSolana\nSolana Cargo feature flag and TS SDK configuration.\nWaiting for the Automatic Upgrade\nNot applicable to Sui\nThis 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.\nThe 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.\nIf 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\nGet help\nTechnical questions\nPublic dev Telegram channel.\nContact the team\nPlans, chain support, custom arrangements.\nDeveloper Forum Discussion\nDiscussion about the Pyth Core upgrade and how to prepare for it."}
{"url":"https://docs.optimism.io/node-operators/tutorials/node-from-docker","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"c9ac957fbf51f8216c827ab023d17ce70f1a3104b88e46ca7e293ba786dbe49e","tokens":2018,"chars":8072,"crawler":"hive-genesis","verified":"exact","ts":1791112147832,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOptimism Documentation home page\nGet Started\nChain Operators\nNode Operators\nApp Developers\nProtocol\nOP Mainnet\nGovernance\nNotices\nTutorials\nRunning a Node With Docker\nRun an OP Stack node (op-reth + op-node) using the official Docker images and docker-compose.\nop-geth has reached end-of-support (2026-05-31) and does not support the now-active Karst hardfork, so op-geth nodes can no longer follow the canonical chain. Migrate to op-reth, the primary supported execution client. See the op-geth deprecation notice for the full migration plan.\nLearn the OP Stack â stop 14 of 14.\nYouâve learned the stack from concepts to cross-layer flows. In this\ncapstone you run an OP Stack node on a live network with the official\nDocker images. When it syncs, youâve finished the track: head back to\nLearn the OP Stack for where to go next.\nThis tutorial runs an OP Stack node using the official op-reth and op-node Docker images in a single docker-compose.yml . No source build required.\nTo run the Rust consensus client instead of op-node, see the\nkona-node Docker guide , which ships\nits own docker-compose recipe for a kona-node + op-reth stack.\nOP Mainnet requires a one-time pre-Bedrock state import. OP Sepolia does not. If you point this tutorial at OP Mainnet on a fresh datadir, op-reth will fail at startup with Op-mainnet has been launched without importing the pre-Bedrock state . Before running OP Mainnet, follow the op-reth sync-op-mainnet guide to either restore from a pre-synced snapshot or run the minimal-bootstrap import. OP Sepolia bootstraps via snap sync with no extra steps â start there if youâre just testing the setup.\nDependencies\n- Docker\n- Docker Compose (v2)\n- An L1 execution RPC endpoint (Ethereum mainnet for OP Mainnet, or Ethereum Sepolia for OP Sepolia).\n- An L1 Beacon API endpoint for the same L1 chain. Needed by op-node to fetch blob data post-Ecotone.\nQuick start\n1\nCreate a working directory\nmkdir op-stack-node && cd op-stack-node\n2\nGenerate the JWT secret\nBoth containers share a JWT secret over a bind mount:\nopenssl rand -hex 32 > jwt.txt\n3\nCreate the .env file\nConfigure your network and L1 endpoints. Pick one network block (Sepolia or Mainnet) and fill in your L1 RPC + Beacon URLs:\ncat > .env << 'EOF'\n# --- Network: OP Sepolia (default) ---\nOP_RETH_CHAIN=optimism_sepolia\nOP_NODE_NETWORK=op-sepolia\nOP_RETH_SEQUENCER=https://sepolia-sequencer.optimism.io\n# --- Network: OP Mainnet (uncomment to use instead) ---\n# OP_RETH_CHAIN=optimism\n# OP_NODE_NETWORK=op-mainnet\n# OP_RETH_SEQUENCER=https://mainnet-sequencer.optimism.io\n# --- L1 endpoints (required) ---\nL1_RPC_URL=https://your-l1-rpc-endpoint\nL1_RPC_KIND=basic\nL1_BEACON_URL=https://your-l1-beacon-endpoint\nEOF\nL1_RPC_KIND valid values: alchemy , quicknode , infura , parity , nethermind , debug_geth , erigon , basic , any . Use basic if unsure.\nOP_RETH_CHAIN and OP_NODE_NETWORK accept any superchain-registry chain (e.g. unichain / unichain-mainnet , soneium / soneium-mainnet ). For each chain, point L1_RPC_URL / L1_BEACON_URL at the corresponding L1 (Ethereum Mainnet or Sepolia) and update OP_RETH_SEQUENCER to that chainâs sequencer endpoint.\n4\nCreate docker-compose.yml\nservices :\nop-reth :\nimage : us-docker.pkg.dev/oplabs-tools-artifacts/images/op-reth:v2.2.5\ncontainer_name : op-reth\nports :\n- \"8545:8545\" # JSON-RPC HTTP\n- \"8546:8546\" # JSON-RPC WebSocket\n- \"9001:9001\" # Prometheus metrics\n- \"30303:30303\" # P2P TCP\n- \"30303:30303/udp\" # P2P UDP\nvolumes :\n- ./reth-data:/data\n- ./jwt.txt:/jwt.txt:ro\ncommand :\n- node\n- --chain=${OP_RETH_CHAIN}\n- --datadir=/data\n- --http\n- --http.addr=0.0.0.0\n- --http.port=8545\n- --ws\n- --ws.addr=0.0.0.0\n- --ws.port=8546\n- --authrpc.addr=0.0.0.0\n- --authrpc.port=8551\n- --authrpc.jwtsecret=/jwt.txt\n- --rollup.sequencer=${OP_RETH_SEQUENCER}\n- --metrics=0.0.0.0:9001\nrestart : unless-stopped\nop-node :\nimage : us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.18.2\ncontainer_name : op-node\ndepends_on :\n- op-reth\nports :\n- \"9545:7000\" # JSON-RPC HTTP (host 9545 â container 7000; macOS uses 7000 for AirPlay)\n- \"7300:7300\" # Prometheus metrics\n- \"9222:9222\" # P2P TCP\n- \"9222:9222/udp\" # P2P UDP\nvolumes :\n- ./jwt.txt:/jwt.txt:ro\ncommand :\n- op-node\n- --l1=${L1_RPC_URL}\n- --l1.rpckind=${L1_RPC_KIND}\n- --l1.beacon=${L1_BEACON_URL}\n- --l2=ws://op-reth:8551\n- --l2.jwt-secret=/jwt.txt\n- --network=${OP_NODE_NETWORK}\n- --syncmode=execution-layer\n- --l2.enginekind=reth\n- --rpc.addr=0.0.0.0\n- --rpc.port=7000\n- --metrics.enabled\n- --metrics.addr=0.0.0.0\n- --metrics.port=7300\nrestart : unless-stopped\nThe op-reth datadir is bind-mounted from ./reth-data on the host so you can inspect / restore from a snapshot directly (see Bootstrap from a snapshot below). Image tags shown are the latest as of writing. For the current tags, see the op-reth releases and op-node releases .\n5\nStart the node\ndocker compose up -d\nFollow logs with:\ndocker compose logs -f\nVerification\nCheck the node is alive and advancing:\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n--data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":1}' \\\nhttp://localhost:8545\nExpected: {\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x...\"} with the current block in hex. Run again after a minute â the number should increase as sync progresses.\nFor op-node sync status (unsafe, safe, and finalized heads in one call):\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n--data '{\"jsonrpc\":\"2.0\",\"method\":\"optimism_syncStatus\",\"params\":[],\"id\":1}' \\\nhttp://localhost:9545 | jq .\nDuring the initial EL-driven sync ( --syncmode=execution-layer ), unsafe_l2 tracks the tip via libp2p gossip while safe_l2 and finalized_l2 stay at 0. This is expected â op-node defers L1 derivation until op-reth finishes its staged sync. Once the EL catches up, derivation begins and the safe/finalized heads start advancing.\nYou can also tail op-node logs directly:\ndocker compose logs op-node | grep -E \"Sync progress|Finished EL sync\"\nBootstrap from a snapshot\nSyncing from scratch is fine for OP Sepolia (~30â50 GB, hours) but slow for OP Mainnet (~700 GB, days). For Mainnet â or anytime youâd rather skip the initial sync â bootstrap op-reth from a pre-synced snapshot.\nFor OP Mainnet, a snapshot also handles the pre-Bedrock state requirement (see the warning at the top of this page) in one step.\n1\nStop the containers\ndocker compose down\nrm -rf reth-data # only if you previously synced and want to start clean\n2\nDownload a snapshot\nBrowse datadirs.optimism.io for the snapshot matching your network and pick a recent file. Then download and verify the SHA256:\ncurl -fLO https://datadirs.optimism.io/ < snapshot-fil e > .tar.zst\n# Verify checksum against the value on the index page\nsha256sum < snapshot-fil e > .tar.zst # Linux\nshasum -a 256 < snapshot-fil e > .tar.zst # macOS\n3\nExtract into the datadir\nThe bind-mounted directory is ./reth-data (relative to your docker-compose.yml ):\nmkdir -p reth-data\ntar -I zstd -xvf < snapshot-fil e > .tar.zst -C reth-data --strip-components=1\n--strip-components=1 removes the top-level wrapping directory inside the tarball. Run tar -tf .tar.zst | head -3 first to confirm â if files are already at the archive root, omit --strip-components .\n4\nStart the node\ndocker compose up -d\ndocker compose logs -f op-reth\nop-reth will recognize the existing datadir on startup and pick up from the snapshotâs tip â latest_block should be the snapshotâs height, not 0. It will then catch up from that tip to current (minutes for Sepolia, hours for Mainnet, depending on snapshot age).\nNext steps\n- Node Metrics and Monitoring Guide â wire up Prometheus/Grafana against the metrics port.\n- Node Troubleshooting Guide â if you run into problems.\n- Building and running an OP Stack node from source â if you need a custom build or want to inspect the source.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.filecoin.io/networks-and-tools/assets","domain":"docs.filecoin.io","title":"Assets | Filecoin Docs","hash":"07b5a78b073882707cfb85e8569091d71243730ef8f6012922d8655f30e62200","tokens":196,"chars":783,"crawler":"hive-genesis","verified":"exact","ts":1791112149711,"text":"Filecoin Docs\nâ Ctrl k\nBasics Storage providers Nodes Networks Smart contracts Reference\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nAssets\nManage FIL tokens, set up wallets, and transfer assets on the Filecoin network.\nThis section covers how to acquire, store, and transfer FIL tokens on the Filecoin network.\nTable of contents\n-\nThe FIL token â the native cryptocurrency that powers the Filecoin network\n-\nWallets â wallet options for securely holding and managing FIL\n-\nMetamask setup â configure MetaMask to work with Filecoin\n-\nGet FIL â how to purchase FIL through exchanges\n-\nTransfer FIL â send FIL between different address types\nWas this page helpful?\nPrevious Legacy networks\nNext The FIL token\nLast updated 3 months ago"}
{"url":"https://vitalik.eth.limo/general/2025/01/23/l1l2future.html","domain":"vitalik.eth.limo","title":"Scaling Ethereum L1 and L2s in 2025 and beyond","hash":"bb25194832bbd1d9875d8ad13e15c8093eb1fbc8230436a2afe8a9a5c77e9cce","tokens":4487,"chars":17945,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112149147,"text":"Dark Mode Toggle\nScaling Ethereum L1 and L2s in 2025 and beyond\n2025 Jan 23\nSee all posts\nScaling Ethereum L1 and L2s in 2025 and beyond\nSpecial thanks to Tim Beiko, Justin Drake, and developers from\nvarious L2 teams for feedback and review\nThe goal of Ethereum is the same as what it has been from day 1:\nbuilding a global, censorship-resistant permissionless\nblockchain . A free and open platform for decentralized\napplications, built upon the same principles (what we might call today\nthe regen\nand cypherpunk\nethos) as GNU + Linux, Mozilla, Tor, Wikipedia, and many other great\nfree and open source software projects that came before it.\nOver the past ten years, Ethereum has also evolved another property\nthat I have come to greatly appreciate: in addition to the innovation in\ncryptography and economics, Ethereum is also an innovation in\nsocial technology . Ethereum as an ecosystem is a working, live\ndemonstration of a new, more open and decentralized way of building\nthings together. Political philosopher Ahmed Gatnash describes his\nexperience at Devcon as\nfollows :\n... A glimpse of what an alternative world could look like - one mostly\nfree of gatekeeping, and with no attachment to legacy systems. In its\ninversion of society's standard status systems, the people who are held\nin highest social status here are the nerds who spend all their time\nhyper focused on independently solving a problem that they really deeply\ncare about, not playing a game to climb the hierarchies of legacy\ninstitutions and amass power. Almost all the power here was soft power.\nI found it beautiful and very inspiring - it makes you feel like\nanything would be possible in a world like this, and that a world like\nthis is actually within reach.\nThe technical project and the social project are inherently\nintertwined . If you have a decentralized technical system at\ntime T, but a centralized social process maintaining it, there is no\nguarantee that your technical system will still be decentralized at time\nT+1. Similarly, the social process is kept alive in many ways by the\ntechnology: the tech brings in users, the ecosystem made possible by the\ntech provides incentives for developers to come and stay, it keeps the\ncommunity grounded and focused on building rather than just socializing,\nand so on.\nWhere you can use Ethereum to pay for things around the\nworld, Oct 2024. Source .\nAs a result of ten years of hard work governed by this mix of\ntechnical and social properties, Ethereum has come to embody another\nimportant quality: Ethereum does useful things for people, at\nscale . Millions of people hold ETH or stablecoins as a form of\nsavings, and many more use these assets for payment: I'm one of them. It\nhas effective, working privacy\ntools that I use to pay for VPNs to protect my internet data. It has\nENS, a robust decentralized alternative to DNS and more generally public\nkey infrastructure. It has working and easy-to-use Twitter alternatives.\nIt has defi tools that offer millions of people higher-yielding low-risk\nassets than what they can access in tradfi.\nFive years ago, I was not comfortable talking about the latter use\ncase for one primary reason: the infrastructure and the code were not\nmature, we were only a few years removed from the massive and highly\ntraumatic smart contract hacks of 2016-17, and there is no point in\nhaving a 7% APY instead of a 5% APY if every year there is a 5% chance\nyou will\ninstead get\na -100%\nAPY . On top of this, transaction fees were too high to make these\nthings usable at scale. Today, these tools have shown their resilience\nover time , the quality of auditing tools has increased, and we are\nincreasingly confident in their security. We know what\nnot to do .\nL2 scaling is working .\nTransaction fees have been very\nlow for almost a year .\nWe need to continue building up the technical and social\nproperties, and the utility, of Ethereum . If we have the\nformer, but not the latter, then we devolve into a\nmore-and-more-ineffective \"decel\" community that can howl into the wind\nabout how various mainstream actors are immoral and bad, but has no\nposition to actually offer a better alternative. If wed have the latter,\nbut not the former, then we have exactly the Wall Street greed-is-good\nmentality that many of us came here\nprecisely to escape .\nThere are many implications of the duality that I have just\ndescribed. In this post, I want to focus on a specific one, which\nmatters greatly Ethereum's users in the short and medium term:\nEthereum's scaling strategy .\nThe rise of layer 2s\nToday, the path that we are taking to scale Ethereum is layer\n2 protocols (L2s) . The L2s of 2025 are a far cry from the early\nexperiments they were in 2019: they have reached key decentralization\nmilestones , they are securing billions of dollars of value, and they\nare currently scaling\nEthereum's transaction capacity by a factor of 17x , dropping fees by a\nsimilar amount.\nLeft: stage 1 and stage 2 rollups. On Jan 22, Ink has\njoined as the sixth stage 1+ rollup (and third full-EVM stage 1+\nrollup). Right, top rollups by TPS, with Base leading at roughly 40% of\nEthereum's capacity.\nThis is all happening just in time for a wave of successful\napplications: various defi platforms , social networks , prediction\nmarkets , exotic contraptions like Worldchain (now with 10\nmillion users ) and more. The \"enterprise blockchain\" movement,\nwidely viewed as a dead end after the failure of consortium blockchains\nin 2010s, is coming back to life with L2s, with Soneium providing a leading\nexample.\nThese successes are also a testament to the social\nside of Ethereum's decentralized and modular approach to scaling :\ninstead of the Ethereum Foundation having to seek out all of these users\nitself, there are dozens of independent entities who are motivated to do\nso. These entities have also made crucial contributions to the\ntechnology, without which Ethereum would not be anywhere close to as far\nas it is today. And as a result, we are finally approaching escape\nvelocity.\nChallenges:\nscale and dealing with heterogeneity\nThere are two primary challenges facing L2s today:\n- Scale : our blob space is barely\ncovering the L2s and the usecases of today, and we have far\nfrom enough\nfor the needs\nof tomorrow .\n- Challenges of heterogeneity. The early vision\nfor how Ethereum could scale involved creating a blockchain that contains\nmany shards , each shard being a copy of the EVM that gets processed\nby a small fraction of the nodes. L2s are, in theory, an\nimplementation of exactly this approach . In practice, however, there\nis a key difference: each shard (or set of shards) is created by a\ndifferent actor, is treated by infrastructure as being a different\nchain, and often follows different standards. Today, this translates\ninto composability and user experience problems for developers and\nusers.\nThe first problem is an easy-to-understand technical challenge, and\nhas an easy-to-describe (but hard-to-implement) technical solution: give\nEthereum more blobs . In addition to this, the L1 can also do moderate amount of scaling\nin the short term, as well as improvements to proof\nof stake , stateless\nand light verification , storage ,\nthe EVM and\ncryptography .\nThe second problem, which has received the bulk of public attention,\nis a coordination problem . Ethereum is no stranger to\nperforming complex technical tasks between multiple teams: after all, we\ndid the merge. Here, the coordination problem is more challenging,\nbecause of the greater number and diversity of actors and goals andt the\nfact that the process is starting much later in the game. But even\nstill, our ecosystem has solved difficult problems before, and we can do\nso again.\nOne possible shortcut for scaling is to give up on L2s, and\ndo everything through L1 with a much higher gas limit (either across\nmany shards, or on one shard). However, this approach compromises too\nmuch of the benefits of Ethereum's current social structure ,\nwhich has been so effective at getting the benefits of different forms\nof research, development and ecosystem-building culture at the same\ntime. Hence, instead we should stay the course, continue to\nscale primarily through L2s, but make sure that L2s actually fulfill the\npromise that they were meant to fulfill .\nThis means the following:\n- L1 needs to accelerate scaling blobs .\n- L1 also needs to do a moderate amount of scaling the EVM and\nincreasing the gas limit , to be able to handle the activity\nthat it will continue to have even in an L2-dominated world (eg. proofs,\nlarge-scale defi, deposits and withdrawals, exceptional mass exit\nscenarios, keystore\nwallets , asset issuance).\n- L2s need to continue improving security . The same\nsecurity guarantees that one would expect from sharding (including eg.\ncensorship resistance, light client verifiability, lack of enshrined\ntrusted parties) should be available on L2s.\n- L2s, and wallets need to accelerate improving and\nstandardizing interoperability . This includes chain-specific\naddresses , message-passing and bridge standards, efficient\ncross-chain payments, on-chain configs and more. Using Ethereum should\nfeel like using a single ecosystem, not 34 different blockchains.\n- L2 deposit and withdraw times need to become much\nfaster .\n- As long as basic interoperability needs are met, L2\nheterogeneity is good . Some L2s will be governance-minimized\nbased rollups that run exact copies of the L1 EVM. Others will\nexperiment with different VMs. Others will act more like servers that\nuse Ethereum to give users extra security guarantees. We need L2s at\neach part of that spectrum.\n- We should think explicitly about economics of ETH .\nWe need to make sure that ETH continues to accrue value even in an\nL2-heavy world, ideally solving for a variety of models of how value\naccrual happens.\nLet us now go through each of these topic areas in more detail.\nScaling: blobs, blobs, blobs\nWith EIP-4844, we now have 3 blobs per slot, or a data bandwidth of\n384 kB per slot. Quick napkin math suggests that this is 32 kB per\nsecond, and each transaction takes about 150\nbytes onchain, so we get ~210 tx/sec. L2beat data gives us almost exactly this\nnumber .\nWith Pectra, scheduled for release\nin March , we plan to double this to 6 blobs per slot .\nThe current goal\nof Fusaka is to focus primarily on PeerDAS ,\nideally having nothing other than PeerDAS and EOF . PeerDAS could increase the\nblob count immediately by another 2-4x, and then 8x or more over\ntime.\nAfter that point, the goal is to keep improving the technology to\nincrease the blob count further. When we get to 2D\nsampling , we can reach 128 blobs per slot, and then keep going\nfurther. With this, and improvements\nto data compression , we can reach 100,000 TPS onchain.\nSo far, the above is all a re-statement of the pre-2025 status quo\nroadmap. The key question is: what can we actually change to\nmake this go faster ? My answers are the following:\n- We should be more willing to explicitly deprioritize features that\nare not blobs.\n- We should be clearer that blobs are the goal, and make relevant p2p\nR&D a talent acquisition priority.\n- We can make the blob target adjusted directly by stakers, similar to\nthe gas limit. This would allow the blob target to increase more quickly\nin response to technology improvements, without waiting for a hard\nfork.\n- We can consider more radical\napproaches that get us more blobs faster with more trust assumptions\nfor lower-resourced stakers, though we should be careful about\nthis.\nImproving\nsecurity: proof systems and native rollups\nToday, there are three stage 1 rollups (Optimism, Arbitrum, Ink) and\nthree stage 2 rollups (DeGate, zk.money, Fuel). The majority of activity\nstill happens on stage 0 rollups (ie. multisigs). This needs to change.\nA big reason why this has not changed faster, is that building a\nproof system, and getting enough confidence in it to be willing to give\nup training wheels and rely fully on it for security, is\nhard.\nThere are two paths toward getting there:\n- Stage 2 + multi-provers + formal verification : use\nmultiple proving systems for redundancy, and use formal verification\n(see: the verified ZK-EVM\ninitiative ) to get confidence that they are secure.\n- Native rollups : make EVM state transition function\nverification part of the protocol itself, eg. through a precompile (see:\n[1] [2]\n[3]\nfor research)\nToday, we should work on both in parallel. For stage 2 +\nmulti-provers + formal verification, the roadmap is relatively\nwell-understood. The main practical place where we can accelerate is to\ncooperate more on software stacks, reducing the need for duplicate work\nwhile increasing interoperability as a by-product.\nNative rollups are still an early-stage idea. There is a lot\nof active thinking to be done , particularly on the topic of how\nto make a native rollup precompile maximally flexible. An ideal goal\nwould be for it to support not just exact clones of the EVM, but also\nEVMs with various arbitrary changes, in such a way that an L2 with a\nmodified EVM could still use the native rollup precompile, and \"bring\nits own prover\" only for the modifications. This could be done for\nprecompiles, opcodes, the state tree, and potentially other pieces.\nInteroperability and\nstandards\nThe goal is to make it so that moving assets between and using\napplications on different L2s has the same experience as you would have\nif they were different \"shards\" of the same blockchain. There has for a\nfew months been a pretty well-understood roadmap for how to do this:\n- Chain-specific\naddresses : the address should include both the account on the chain,\nand some kind of identifier for the chain itself. ERC-3770 is an early\nattempt at this, there are now more sophisticated ideas, which also move\nthe registry for L2s to the Ethereum L1 itself.\n- Standardized cross-chain bridges and cross-chain message\npassing: there should be standard ways to verify proofs and\npass messages between L2s, and these standards should not require\ntrusting anything except for the proof systems of the L2s themselves.\nAn ecosystem relying on multisig bridges is NOT\nacceptable . If it's a trust assumption that would not exist if\nwe had done 2016-style\nsharding , it's not acceptable today, full stop.\n- Speeding up deposit and withdraw times , so that\n\"native\" messages can take minutes (and eventually one slot) rather than\nweeks. This involves faster ZK-EVM provers, and proof aggregation.\n- Synchronous read of L1 from L2 . See: L1SLOAD ,\nREMOTESTATICCALL .\nThis makes cross-L2 interoperability significantly easier, and also\nhelps keystore\nwallets .\n- Shared sequencing , and other longer-term work.\nBased rollups are valuable in part because they may be\nable to do this more effectively.\nAs long as standards like these are satisfied, there is still a lot\nof room for L2s to have very different properties from each other:\nexperimenting with different virtual machines, different sequencing\nmodels, scale vs security tradeoffs, and other differences. However, it\nmust be clear to users and application developers what level of security\nthey are getting.\nTo make faster progress, a large share of the work can be done by\nentities that operate across the ecosystem: the Ethereum Foundation,\nclient development teams, major application teams, etc. This will reduce\ncoordination effort and make adopting standards more of a no-brainer,\nbecause the work that will be done by each individual L2 and wallet will\nbe reduced. However, L2s and wallets, as extensions of Ethereum, both\nstill need to step up work on the last mile of actually implementing\nthese features and bringing them to users.\nEconomics of ETH\nETH as\ntriple-point asset\nWe should pursue a multi-pronged strategy, to cover all major\npossible sources of the value of ETH as a\ntriple-point asset . Some key planks of that strategy could be the\nfollowing:\n- Agree broadly to cement ETH as the primary asset of the\ngreater (L1 + L2) Ethereum economy , support applications using\nETH as the primary collateral, etc\n- Encourage L2s supporting ETH with some percentage of\nfees . This could be done through burning a portion of fees,\npermanently staking them and donating proceeds to Ethereum ecosystem\npublic goods, or a number of other formulas.\n- Support based rollups in part as a path for L1 to capture\nvalue through MEV , but do not attempt to force all rollups to\nbe based (because it does not work for all applications), and do not\nassume that this alone will solve the problem.\n- Raise the blob count , consider a minimum blob\nprice, and keep blobs in mind as another possible revenue generator. As\nan example possible future, if you take the average blob fee of the last\n30 days, and suppose it stays the same (due to induced\ndemand ) while blob count increases to 128, then Ethereum would burn\n713,000 ETH per year. However, such a favorable demand curve is not\nguaranteed, so also do not assume that this alone will solve the\nproblem.\nConclusion: The Road Ahead\nEthereum has matured as a technology stack and a social ecosystem,\nbringing us closer to a more free and open future where hundreds of\nmillions of people can benefit from crypto assets and decentralized\napplications. However, there is a lot of work to be done, and now is the\ntime to double down.\nIf you're an L2 developer, contribute to the tooling to make blobs\nscale more safely, the code to scale the execution of your EVM, and the\nfeatures and standards to make the L2 interoperable. If you are a wallet\ndeveloper, be similarly engaged in contributing to and implementing\nstandards to make the ecosystem more seamless for users, and at the same\ntime as secure and decentralized as it was when Ethereum was just an L1.\nIf you are an ETH holder or community member, actively participate in\nthese discussions; there are many areas that still require active\nthought and brainstorming. The future of Ethereum depends on every one\nof us playing an active role."}
{"url":"https://docs.sui.io/operators","domain":"docs.sui.io","title":"Node Operators","hash":"bbe1a5df2f8649a9ddf113bc9642e977b672f911bd894f75840b51699b1457fc","tokens":748,"chars":2991,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112150559,"text":"# Node Operators\n*[Documentation index](/llms.txt) · [Full index](/llms-full.txt)*\nSui has several node types, each with a different role:\n- **Full node**: Stores the full chain state and serves read requests.\n- **Validator**: Participates in consensus and produces certified transaction effects. Validators must meet staking and hardware requirements.\n- **Bridge node**: Supports cross-chain asset transfers between Sui and other networks.\n## What does a node operator do?\nRunning Sui infrastructure involves more than launching a binary. Operators are responsible for:\n- Configuring and starting nodes on supported hardware\n- Keeping software up to date across network upgrades\n- Managing chain data, snapshots, and archival storage\n- Monitoring node health and setting up observability tooling\n- Handling key management and operational security\n## Frequently asked questions\n#### What is the difference between a full node and a validator?\nA full node stores chain state, answers queries, and submits transactions to validators. A validator participates in consensus to finalize transactions. Validators earn staking rewards and must meet additional operational and hardware requirements.\n#### How do I keep my node in sync after a restart?\nSui supports snapshots and archival data to help nodes catch up after downtime. The data management guides explain how to configure snapshot sources and restore from them.\n#### What monitoring should I set up for my node?\nThe observability guide covers metrics endpoints, log configuration, and recommended alerting for production nodes.\nFind guides for running and managing Sui network infrastructure, including full nodes, validators, bridge nodes, data management, and exchange integration.\n- [Sui Bridge Validator Node Configuration](bridge-node-configuration) â Correct configuration of your node ensures optimal performance and valid metrics data.\n- [Data Indexing and Archives](data-management/) â Overview of data indexing, archival storage, and remote store configuration for Sui network nodes, with links to detailed setup guides.\n- [Exchange Integration](exchange-integration) â Guidance for integrating SUI into a cryptocurrency exchange. Covers infrastructure, current APIs (gRPC and GraphQL), balance tracking, transactions, transfers, and staking.\n- [Full Nodes](full-node/) â Guides for setting up and operating Sui full nodes.\n- [Genesis](genesis) â Genesis refers to the initial state of the Sui blockchain at launch.\n- [Images](images/)\n- [Logging, Tracing, Metrics, and Observability](observability) â Set up and manage logging, tracing, metrics, and observability for Sui validators and full nodes using structured logging and Prometheus.\n- [Database Snapshots](snapshots) â Database snapshots of the Sui network enable full node operators a way to bootstrap a full node without having to execute all the transactions that occurred after genesis.\n- [Sui Validators](validator/) â Guides for validator nodes on the Sui network."}
{"url":"https://ethereum.org/learn/","domain":"ethereum.org","title":"Ethereum: A Comprehensive Learning Guide | âŠethereum.orgâ©","hash":"c7b22ebbeed3963df8b0952fb50a0525c93e952ba791b201788b3a9440ecb3f8","tokens":1189,"chars":4753,"crawler":"hive-genesis","verified":"unchecked","ts":1791112151359,"text":"Skip to main content\nLearn Hub\nLearn about Ethereum\nYour educational guide to the world of Ethereum. Learn how Ethereum works and how to connect to it. This page includes technical and non-technical articles, guides, and resources.\nUnderstand Ethereum\nCryptocurrencies, 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:\nWhat is Ethereum?\nUnderstand what makes Ethereum special and how it differs from other technologies.\nStart here\nWhat is ether (ETH)?\nUnderstand Ethereum's native currency ether (ETH) and how it powers the network.\nLearn about ETH\nEthereum vs Bitcoin\nUnderstand the differences between Ethereum and Bitcoin and what each is designed to do.\nCompare the two\nKeep learning\nWhat is the Ethereum network?\nUnderstand how the Ethereum network works: nodes, validators, and how transactions are processed.\nExplore the network\nWhat is Web3?\nAn alternative to centralized monopolies dictating the rules of the internet.\nDiscover Web3\nSmart contracts\nThe fundamental building blocks of the Ethereum ecosystem.\nHow they work\nMore on Ethereum basics\nWhy Ethereum exists: the principles it is built on\nGuides: step-by-step instructions on using Ethereum\nQuiz hub: test your knowledge\nMore on Ethereum: history, founder and ownership\nEthereum in 30 minutes by Vitalik Buterin\n(opens in a new tab)\nHow do I use Ethereum?\nUsing 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.\nEthereum wallets\nAn app to interact with your Ethereum account, manage funds, and connect to applications.\nLearn about wallets\nFind a wallet\nBrowse wallets based on the features that matter to you.\nList of wallets\nGet ETH\nBuy or earn ether (ETH) so you can use Ethereum applications and send transactions.\nHow to get ETH\nKeep learning\nStaking\nEarn rewards and help secure the network by staking your ETH.\nWays to stake\nLayer 2 networks\nNetworks built on Ethereum that make transactions faster and cheaper.\nWhat is layer 2?\nCommunity stories\nHow people around the world are using Ethereum in their daily lives.\nRead the stories\nMore on using Ethereum\nHow to create an Ethereum account\nHow to use a wallet\nStaying safe: security and scam prevention\nGas and transaction fees explained\nWhere to get help and support\nWhat is Ethereum used for?\nEthereum 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.\nHow Ethereum works\nExplore the technical side of the Ethereum protocol.\nEthereum roadmap\nEthereum's roadmap makes it more scalable, secure, and sustainable.\nExplore the roadmap\nEthereum Whitepaper\nThe original Ethereum proposal written by Vitalik Buterin in 2014.\nRead whitepaper\nPrivacy on Ethereum\nLearn about privacy tools and techniques for protecting your data on Ethereum.\nExplore privacy\nMore on the Ethereum protocol\nEnergy consumption\nEthereum for developers\nEthereum's proof-of-stake based consensus mechanism\nEthereum's embedded computer (The EVM)\nEthereum nodes and clients\nBooks, podcasts, and series about Ethereum\nBooks\n- The Cryptopians (opens in a new tab) - February 22, 2022 - Laura Shin\n- Out of the Ether (opens in a new tab) - September 29, 2020 - Matthew Leising\n- The Infinite Machine (opens in a new tab) - July 14, 2020 - Camila Russo\n- Mastering Ethereum (opens in a new tab) - December 23, 2018 - Andreas M. Antonopoulos, Gavin Wood Ph.D.\n- Proof of Stake (opens in a new tab) - September 13, 2022 - Vitalik Buterin, Nathan Schneider\nPodcasts\n- Green Pill (opens in a new tab) - Explores the crypto-economic systems that create positive externalities for the world\n- Zero Knowledge (opens in a new tab) - Goes deep into the tech that will power the emerging decentralized web and the community building this\n- Unchained (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 privacy\n- The Daily Gwei (opens in a new tab) - Ethereum news recaps, updates and analysis\n- Bankless (opens in a new tab) - A guide to Crypto finance\nVideo series\n- Ethereum Basics (opens in a new tab) - Learn the basics of Ethereum network architecture with an easy-to-understand video series."}
{"url":"https://docs.orca.so/liquidity/overview","domain":"docs.orca.so","title":"Providing Liquidity on Solana - Orca Documentation","hash":"645cd38a50aac7b0fcfaf718ecc6910b889cb3bc42b7ef91a23a9e04ecd7183c","tokens":1168,"chars":4669,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112152308,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nOverview\nProviding Liquidity on Solana\nLearn how liquidity provision works on Orca.\nProvide liquidity to Orcaâs concentrated liquidity pools, also known as CLMMs, by depositing tokens into selected price ranges.\nLiquidity providers may accrue trading fees when swaps use their active liquidity. Position outcomes depend on price movement, trading activity, liquidity, range selection, fees, rewards, slippage, transaction costs, and market conditions.\nOrcaâs concentrated liquidity pools allow users to create pools and provide liquidity within selected price ranges. Understand the mechanics and risks before providing liquidity.\nWhat is concentrated liquidity?\nA CLMM, or Concentrated Liquidity Market Maker, lets liquidity providers allocate liquidity to selected price ranges instead of spreading liquidity across the full supported price range.\nThis gives liquidity providers more control over where their liquidity is active, but also means positions may require more review and management.\nTraditional AMM / Full-range liquidity\nLiquidity is spread across the full supported price range. This can be simpler to manage, but liquidity is less concentrated around the current price.\nConcentrated Liquidity / CLMM\nLiquidity is allocated to selected price ranges. This can concentrate liquidity within a chosen range, but positions only accrue swap fees while in range and used by swaps.\nWhy provide liquidity on Orca?\nSelected price ranges\nCLMMs let liquidity providers choose where their liquidity is active by setting price ranges.\nFee accrual\nLiquidity providers may accrue trading fees when swaps use their active liquidity.\nPosition management\nLiquidity providers can review and adjust positions as price, liquidity, and market conditions change.\nDifferent position types\nOrca supports full-range positions, custom-range positions, and range-order-style positions.\nCLMM vs traditional AMM\nFeature Traditional AMM / Full-range liquidity Orca CLMM\nLiquidity distribution Spread across the full supported price range Allocated to selected price ranges\nLiquidity concentration Less concentrated around the current price More concentrated within the selected range\nFee accrual May accrue fees when swaps use the pool May accrue fees when swaps use your in-range liquidity\nManagement needed Usually less range management May require more range review and adjustment\nImpermanent loss risk Still applies Still applies and can be affected by range width\nConcentrated liquidity does not guarantee fee accrual, returns, or improved outcomes. Positions can move out of range, become one-sided, and experience impermanent loss or divergence loss.\nPosition types\nFull-Range Position\nSpreads liquidity across the full supported price range. This may be simpler to create and may require less range management.\nCustom-Range Position\nAllocates liquidity to a selected price range. This can concentrate liquidity but may require more monitoring and adjustment.\nGetting started\n1\nUnderstand the risks\nLearn about impermanent loss , range risk, token price risk, and how concentrated liquidity affects position outcomes.\n2\nReview position types\nCompare full-range and custom-range positions to understand how range width affects fee accrual, token composition, and monitoring needs.\n3\nCreate your position\nFollow the relevant guide to deposit liquidity into a supported pool.\n4\nReview and manage\nUse the Portfolio page to review position details, accrued fees and rewards, range status, and available actions.\nImportant considerations\n- Liquidity positions are exposed to token price movement.\n- Positions may experience impermanent loss or divergence loss.\n- Custom-range positions only accrue swap fees while in range and used by swaps.\n- Positions can become fully one-sided if price moves outside the selected range.\n- Fee and reward accrual are not guaranteed.\n- Adding, withdrawing, closing, or adjusting positions may involve slippage, transaction fees, priority fees, and changing pool conditions.\n- Review all wallet prompts before signing transactions.\nNext Steps\nBeginner's Guide\nLearn the basics of liquidity provision on Orca\nFull-Range Position\nLearn how full-range positions work\nCustom-Range Position\nLearn how selected price ranges work\nImpermanent Loss\nUnderstand price divergence and LP positions\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://eips.ethereum.org/EIPS/eip-2718","domain":"eips.ethereum.org","title":"EIP-2718: Typed Transaction Envelope","hash":"37ae8d8d0dc1d5e0a7434a8ca8dbd740ab8aeadb33f41a7a3c2e07a9684b9ddd","tokens":1780,"chars":7120,"crawler":"hive-genesis","verified":"unchecked","ts":1791112153064,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: Core\nEIP-2718: Typed Transaction Envelope\nDefines a new transaction type that is an envelope for future transaction types.\nAuthors\nMicah Zoltu ( @MicahZoltu )\nCreated\n2020-06-13\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- Definitions\n- Transactions\n- Receipts\n- Rationale\n- TransactionType only goes up to 0x7f\n- SHOULD instead of MUST for the TransactionType being first byte of signed data\n- TransactionType selection algorithm\n- Opaque byte array rather than an RLP array\n- ORIGIN and CALLER\n- Backwards Compatibility\n- Security Considerations\n- Copyright\nAbstract\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.\nMotivation\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.\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 TransactionType s.\nSpecification\nDefinitions\n- || is the byte/byte-array concatenation operator.\nTransactions\nAs of FORK_BLOCK_NUMBER , the transaction root in the block header MUST be the root hash of patriciaTrie(rlp(Index) => Transaction) where:\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])\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.\nReceipts\nAs of FORK_BLOCK_NUMBER , the receipt root in the block header MUST be the root hash of patriciaTrie(rlp(Index) => Receipt) where:\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])\nThe TransactionType of the receipt MUST match the TransactionType of the transaction with a matching Index .\nRationale\nTransactionType only goes up to 0x7f\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 .\nSHOULD instead of MUST for the TransactionType being first byte of signed data\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.\nTransactionType selection algorithm\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.\nOpaque byte array rather than an RLP array\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.\nORIGIN and CALLER\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.\nBackwards Compatibility\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.\nSecurity Considerations\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.\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nMicah Zoltu ( @MicahZoltu ), \"EIP-2718: Typed Transaction Envelope,\" Ethereum Improvement Proposals , no. 2718, June 2020. Available: https://eips.ethereum.org/EIPS/eip-2718."}
{"url":"https://eips.ethereum.org/EIPS/eip-6","domain":"eips.ethereum.org","title":"EIP-6: Renaming SUICIDE opcode","hash":"6db7778e59811f6525f72d7ba8b37a66b3c3191eab858617e0070439fde7e90d","tokens":523,"chars":2089,"crawler":"crawler-v8wo","verified":"exact","ts":1791112153970,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: Interface\nEIP-6: Renaming SUICIDE opcode\nAuthors\nHudson Jameson < hudson@hudsonjameson.com >\nCreated\n2015-11-22\nTable of Contents\n- Abstract\n- Motivation\n- Implementation\nAbstract\nThe solution proposed in this EIP is to change the name of the SUICIDE opcode in Ethereum programming languages with SELFDESTRUCT .\nMotivation\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.\nAn Ethereum security audit commissioned by DEVolution, GmbH and performed by Least Authority recommended the following:\nReplace 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.\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.\nImplementation\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\nCitation\nPlease cite this document as:\nHudson Jameson < hudson@hudsonjameson.com >, \"EIP-6: Renaming SUICIDE opcode,\" Ethereum Improvement Proposals , no. 6, November 2015. Available: https://eips.ethereum.org/EIPS/eip-6."}
{"url":"https://docs.monad.xyz/tooling-and-infra","domain":"docs.monad.xyz","title":"Tooling and Infrastructure - Monad Documentation","hash":"10856e87258a10803408773c31e6090eed08da6bc03099abc4d42d94ca09b291","tokens":425,"chars":1697,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112155862,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nMonad Documentation home page\nDocumentation\nLearn\nNode Operations\nTooling and Infrastructure\nThe most popular Ethereum tools and infrastructure providers support Monad. The enclosing pages survey each category of tools and attempt a feature comparison.\nSee also the protocols repo for a listing of contract addresses for each protocol.\nAnalytics\nTools for understanding app activity on Monad\nBlock Explorers\nView accounts and transactions; read and write contracts\nCard Issuing\nIssue debit, prepaid, and credit cards that spend on-chain stablecoins\nCross-Chain\nBridges and protocols for cross-chain communication\nCustody\nInstitutional-grade custody solutions for secure asset management\nDEX Aggregators\nRoute swaps across on-chain venues for the best available rate\nEarn/Yield Infrastructure\nVaults, strategies, and APIs for embedding onchain yield\nIndexers\nCommon transformations for blockchain data + custom calculators\nOnramps\nWays to convert between fiat and crypto\nOracles\nData feeds bringing off-chain information on-chain\nPayment Orchestrators\nUnified APIs that route stablecoin and fiat flows across providers and chains\nPrivacy\nPrivate balances and transfers using MPC and zero-knowledge proofs\nRPC Providers\nEndpoints for interacting with Monad\nToolkits\nDevelopment frameworks and tools for building on Monad\nWallets\nTools for storing private keys, signing transactions, and managing assets\nWallet Infrastructure\nEmbedded wallets and smart accounts\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://research.lido.fi/t/welcome-to-lido-dao/7","domain":"research.lido.fi","title":"Welcome to Lido DAO - General - Lido Governance","hash":"72674ade9f8debf9c7e1208404a67eefbd02075197d1286cda0cb8f1c5f77db1","tokens":2779,"chars":11115,"crawler":"hive-genesis","verified":"unchecked","ts":1791112155288,"text":"Lido Governance\nWelcome to Lido DAO\nGeneral\nsystem\nNovember 19, 2020, 6:50pm\n1\nThe governance platform for the Lido DAO.\nLido DAO is a community that builds liquid staking service for Ethereum. Lido allows users to earn staking rewards without locking assets or maintaining staking infrastructure, using a selection of carefully vetted validators.\nLido FAQ\n1. What is Lido\nLido is a liquid staking solution for ETH 2.0 backed by industry-leading staking providers. Lido lets users stake their ETH - without locking assets or maintaining infrastructure - whilst participating in on-chain activities, e.g. lending.\nOur goal is to solve the problems associated with initial ETH 2.0 staking - illiquidity, immovability and accessibility - making staked ETH liquid and allowing for participation with any amount of ETH to improve security of the Ethereum network.\nLearn more here .\n2. How does Lido work?\nWhen staking with Lido, users receive stETH tokens on a 1:1 basis representing their staked ETH. stETH balances can be used like regular ETH to earn yields and lending rewards, and are updated on a daily basis to reflect your ETH staking rewards. Note that there are no lock-ups or minimum deposits when staking with Lido.\nWhen using Lido, users receive secure staking rewards in real-time, allowing for participation in the securing of Ethereum without the associated risks and downside potential.\nLearn more here .\n3. What is liquid staking?\nLiquid staking protocols allow users to earn staking rewards without locking assets or maintaining staking infrastructure. Users can deposit tokens and receive tradable liquid tokens in return. The DAO-controlled smart contract stakes these tokens using elected staking providers. As users funds are controlled by the DAO, staking providers never have direct access to the usersâ assets.\n4. What is stETH?\nstETH is a token that represents staked ether in Lido, combining the value of initial deposit + staking rewards. stETH tokens are minted upon deposit and burned when redeemed. stETH token balances are pegged 1:1 to the ethers that are staked by Lido. stETH tokenâs balances are updated when the oracle reports change in total stake every day.\nstETH tokens can be used as one would use ether, allowing you to earn ETH 2.0 staking rewards whilst benefiting from e.g. yields across decentralised finance products.\n5. What is LDO?\nLDO is an Ethereum token granting governance rights in the Lido DAO. The Lido DAO governs a set of liquid staking protocols, decides on key parameters (e.g., fees) and executes protocol upgrades to ensure efficiency and stability. By holding the LDO token, one is granted voting rights within the Lido DAO. The more LDO locked in a userâs voting contract, the greater the decision-making power the voter gets.\n6. How is Lido secure?\nLido is a secure liquid staking solution for a number of reasons:\n- Use of DAO for governance decisions & to manage risk factors.\n- Open-sourcing & continuous auditing of all code.\n- Committee of elected, best-in-class validators to minimise staking risk.\n- Use of non-custodial staking service to eliminate counterparty risk.\nUsually when staking ETH you choose only one validator. This is too risky, because it can be slashed for a number of reasons. In the case of Lido you stake across many validators, minimising your risk.\n7. What is the difference between self staking and liquid staking?\nEthereum is soon to be the biggest staking economy in the space. However, ETH 2.0 is not well suited for self-staking. There are several reasons why - the main being the fact that slashing and offline penalties can get very severe if the staking is managed improperly. In addition to this, self-staking brings with it a minimum deposit of 32 ETH and a token lock-up which could last years.\nThrough the use of a liquid self-staking service such as Lido, users can eliminate these inconveniences and benefit from secure, non-custodial staking backed by industry leaders.\n8. What are the risks of staking with Lido?\nThere exist a number of potential risks when staking ETH using liquid staking protocols.\n- Smart contract security\nThere is an inherent risk that Lido could contain a smart contract vulnerability or bug. The Lido code is open-sourced, audited and covered by an extensive bug bounty program to minimise this risk.\n- ETH 2.0 - Technical risk\nLido is built atop experimental technology under active development, and there is no guarantee that ETH 2.0 has been developed error-free. Any vulnerabilities inherent to ETH 2.0 brings with it slashing risk, as well as stETH fluctuation risk.\n- ETH 2.0 - Adoption risk\nThe value of stETH is built around the staking rewards associated with the Ethereum beacon chain. If ETH 2.0 fails to reach required levels of adoption we could experience significant fluctuations in the value of ETH and stETH.\n- DAO key management risk\nEther staked via the Lido DAO is held across multiple accounts backed by a multi-signature threshold scheme to minimise custody risk. If signatories across a certain threshold lose their key shares, get hacked or go rogue, we risk funds becoming locked.\n- Slashing risk\nETH 2.0 validators risk staking penalties, with up to 100% of staked funds at risk if validators fail. To minimise this risk, Lido stakes across multiple professional and reputable node operators with heterogeneous setups, with additional mitigation in the form of insurance that is paid from Lido fees.\n- stETH price risk\nUsers risk an exchange price of stETH which is lower than inherent value due to withdrawal restrictions on Lido, making arbitrage and risk-free market-making impossible.\nThe Lido DAO is driven to mitigate above risks and eliminate them entirely to the extent possible. Despite this, they may still exist and, as such, it is our duty to communicate them.\n70 Likes\nLillian_Siefken\nDecember 2, 2022, 12:06am\n3\nPlease some help my Lido rewards stake assets in all levels has been attacked.\nI have not authorized any transactions started with Safe by Gnosis attack since 2019 and any ether or lido or rewards i get uses it on malicious pool slots bids stable coins with NFT hidden and ERC721 Contracts. What can i do to stop future attacks. Huge assets involve since 2017 i have invested in every tokens imaginable. Billions at this point is net worth rather see it go to something helpful for me and community.\nThanks Lilly\n19 Likes\nCryptman\nOctober 2, 2023, 2:11pm\n5\nInformative introduction. Thanks!\n18 Likes\nMicheal_Tosin_Victor\nNovember 15, 2023, 5:48am\n6\nPlease can I get a clear insight of Lido Operational Framework?\nThanks\n10 Likes\nJenya_K\nNovember 20, 2023, 1:38pm\n7\nYou can get more info on how the Lido DAO Governance process looks like here: The Lido Decentralised Autonomic Organisation Governance\nAlso, Lido DAO adopted Guided Open Objective Setting Exercise (âGOOSEâ) Framework . You can dive in on Snapshot proposal and if you have any more questions feel free to reach out here.\n14 Likes\nPaul_Vincente\nMarch 26, 2024, 5:43am\n14\nWhere do I go to report a phishing scamâŠCrazy no help what so ever?\n9 Likes\nMaize\nMay 17, 2024, 6:02am\n15\nHow many ETH can we stake in Lido ïŒ Are there any restrictions?\n7 Likes\nsatBalwyn\nMay 20, 2024, 8:09am\n16\nwhat kind of scam you have met so far?\nIf you recognise a scam on the forum, please click the flag icon to report any post or account.\n6 Likes\nsatBalwyn\nMay 20, 2024, 8:13am\n17\nno limit theoratically but there is a staking rate limit for every 24 hours (i.e. 150k). More details: Lido tokens integration guide | Lido Docs\n9 Likes\nTheDZhon\nMay 20, 2024, 8:28am\n18\nworth noting the limit has a moving window nature, i.e. getting replenished with every coming block by ~23.4 ether till reached the maximum of 150k\n9 Likes\ndanimim\nAugust 9, 2024, 1:06pm\n19\nInformative one, tysm!\n8 Likes\nJazzer9F\nAugust 30, 2024, 8:36pm\n21\nHi everyone, nice to meet you.\nIâm trying to create a proposal, but it seems Iâm not allowed to post links.\nIs that due to insufficient reputation or are links just generally not allowed?\nWithout links, itâs quite difficult to give context.\nThanks & Cheers!\n7 Likes\nJerod\nOctober 18, 2024, 1:39pm\n22\nThanks for the information! Iâm glad to be part of your project\n8 Likes\nDeuceeDeuce\nJanuary 21, 2025, 10:21pm\n23\nHello @Jenya_K\nme saw the post on X about the Delegate program. Is it too late to join, or can me onboard on the Delegate Platform channel.\nRespect,\nD.\n6 Likes\nJenya_K\nJanuary 27, 2025, 8:05am\n24\nThe list of delegates eligible for incentives this quarter has already been finalized, but that doesnât stop you from becoming a public delegate!\nYou can read more about the rules for public delegation in Lido DAO here: https://snapshot.org/#/s:lido-snapshot.eth/proposal/0xa502cf80451192672313911ce558e74799626da3b3b66130e21c6cd19707e584\nLet me know if you have any questions!\n12 Likes\nVahid_Ghorbani\nJuly 22, 2025, 9:30pm\n25\nLido dao is strong coin in the future\n5 Likes\nAnonimo_Anonimo\nJanuary 10, 2026, 2:33pm\n27\nLido addresses a real structural problem in Ethereum staking: illiquidity and the 32 ETH minimum required for self-staking. It does so by improving capital efficiency, but at the cost of introducing additional layers of risk that should not be understated.\nThe liquid staking model via stETH is not economically equivalent to holding native ETH. It entails smart contract risk, governance risk from the DAO, and market risk due to potential stETH price deviations. Using stETH across DeFi does not eliminate these risks; it redistributes and amplifies them through composability.\nValidator diversification reduces idiosyncratic slashing risk but does not remove systemic risks such as client bugs, consensus failures, or correlated operator errors. Likewise, multisig custody and DAO governance mitigate operational risk, but they do not fully eliminate coordination and key-management risks.\nIn short, Lido is not âstaking without trade-offs.â It is a deliberate exchange of protocol complexity and governance risk for liquidity and flexibility. For many users this is a rational choice; for othersâespecially those with low risk tolerance or large exposuresâself-staking or simpler alternatives may remain preferable.\n3 Likes\nfeltgood\nJanuary 14, 2026, 1:38pm\n28\nNew to Lido Dao. Very good intro here!\n3 Likes\nkhanhwizardpa\nJanuary 16, 2026, 2:35pm\n29\nya yaa, me too, I has been a Lido member community for a while but a newbie in this forum. And I happy to be a part with Lidoâs Journey\n2 Likes\nfight\nMay 12, 2026, 12:01pm\n31\nthat good\nI will stake ETH here.\n1 Like\nnext page â\nRelated topics\nTopic\nReplies\nViews\nActivity\nIs Lido good for Ethereum?\nCommunity Staking: Contributor Series\n12\n4528\nOctober 4, 2023\n[Hasu's GOOSE Submission] Proposed goals for Lido DAO to consider\nGeneral\n16\n10089\nOctober 21, 2024\n[Hasu's GOOSE-2 Submission] A Product Line Approach to Grow Lidoâs Staking Ecosystem\nGeneral\n54\n4277\nMarch 17, 2026\nReGOOSE: Updated goals for Lido in the light of MVI and restaking\nProposals\n27\n6333\nMay 25, 2024\nShould Lido on Ethereum be limited to some fixed % of stake?\nDepartment of Decentralisation\n76\n34093\nJuly 3, 2022"}
{"url":"https://forum.solana.com/t/simd-0326-proposal-for-the-new-alpenglow-consensus-protocol/4236","domain":"forum.solana.com","title":"SIMD-0326: Proposal for the New Alpenglow Consensus Protocol - Governance - Solana Developer Forums","hash":"40a19b447b7ab1ca326d37fb86b3fcecafa161f49a47cc2f108f65037176d0f6","tokens":6313,"chars":25252,"crawler":"hive-genesis","verified":"unchecked","ts":1791112156927,"text":"Solana Developer Forums\nSIMD-0326: Proposal for the New Alpenglow Consensus Protocol\nGovernance\ncore\nRoger\nAugust 14, 2025, 5:23pm\n1\nAuthors: Quentin Kniep, Kobi Sliwinski, Roger Wattenhofer\nSummary\nAlpenglow is a major overhaul of Solanaâs core consensus protocol, replacing the existing Proof-of-History and TowerBFT mechanisms with a modern architecture focused on performance, resilience, and whenever possible simplicity.\nAt the heart of this new design is Votor, a lightweight, direct-vote-based protocol that finalizes blocks using either a single or dual-round voting process, depending on network conditions. Alpenglow significantly reduces latency (from 12.8 seconds under TowerBFT to as low as 100-150 milliseconds) while also improving bandwidth efficiency by eliminating heavy gossip traffic. The protocol introduces a robust certification mechanism, with different certificate types corresponding to notarizating, skipping, or finalizing blocks based on validator votes. To support this, validators will exchange votes directly, using cryptographic aggregates to prove consensus. Rotor, Alpenglowâs new data dissemination protocol, will be introduced in a later update, the current rollout focuses on finalization and voting logic.\nThis forum post only outlines the most important aspects of Alpenglow. On all the topics below, there is much more detailed information available. In particular we recommend reading the actual Alpenglow white paper: https://github.com/rogerANZA/Alpenglow-White-Paper/blob/main/Alpenglow-v1.1.pdf .\nHowever, there is also a list of additional information available:\n-\nOriginal Alpenglow blog entry: https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana\n-\nAlpenglow SIMD with a special focus on rewards and incentives, and its discussion: https://github.com/solana-foundation/solana-improvement-documents/pull/326\n-\nVarious third party analyses, e.g., https://www.helius.dev/blog/alpenglow or https://blog.sei.io/solanas-alpenglow-a-faster-consensus-with-new-trade-offs/\n-\nDiscord discussion channel: https://discord.com/channels/428295358100013066/1377667311174946816\nMotivation\nThe move to Alpenglow is driven by the need to address both performance and security limitations in Solanaâs legacy consensus protocol TowerBFT. TowerBFT imposes long finality delays and lacks formal safety guarantees. Alpenglow is designed with insights from recent advances in distributed systems and blockchain research, enabling much lower latency, improved fault tolerance, and generally greater protocol efficiency. The introduction of direct voting, local signature aggregation, and off-chain vote messaging substantially cuts down on unnecessary computation and communication costs. Furthermore, Alpenglow addresses key incentive flaws in the previous systemâsuch as validators delaying votes for strategic gainâby rebalancing economic rewards and introducing mechanisms like the Validator Admission Ticket (VAT) to maintain fair participation without on-chain vote fees. Its â20+20â resilience model allows the protocol to remain live even if up to 20% of validators are adversarial and another 20% are unresponsive. In short, Alpenglow brings consensus latency to a level comparable with Web2 applications while strengthening the systemâs security posture, scalability, and economic fairness.\nProtocol Overview\nLet us outline Alpenglow from a broad perspective. The protocol operates across a large network of nodes which may number in the thousands. These nodes are part of a defined validator set that remains stable throughout a period known as an epoch. Each node can directly communicate with any other node in the network by sending messages.\nAlpenglow functions as a proof-of-stake blockchain, meaning that each node has an associated amount of stake, which reflects its level of participation and influence. Nodes with greater stake have proportionally higher responsibilities and rewards, including contributing more bandwidth and earning higher fees.\nTime is divided into discrete intervals called slots. Every slot is assigned a specific leader, chosen in advance using a randomized, verifiable process. Each leader is responsible for a sequence of consecutive slots, referred to as their leader window. During this window, the leader collects transactions from users and from other nodes and uses them to create a new block.\nBlocks are built in a pipelined fashion: they are split into intermediate units known as slices, which are further divided into smaller pieces called shreds. Initially, these shreds are dispersed across the network using Turbine. Later, we will replace Turbine with the more efficient Rotor. (Rotor will need to pass its own SIMD process.)\nOnce a block is constructed, the following leader begins producing the next block without delay. Meanwhile, all nodes receive the newly created block and store its data using a dedicated storage system. After receiving a block, nodes begin the voting process to signal whether they accept it. This involves a range of vote types and corresponding aggregated proofs, which are maintained in a local structure that tracks voting history and progress.\nThe core voting logic (Votor) decides whether a block should be finalized. If a node receives the block in a timely and valid form, it will cast a vote in favor. If the block is delayed or invalid, the node will vote to skip it. Finalization occurs when a sufficient portion of the stake affirms the block. If consensus isnât reached in the first round of voting, a fallback round may be used to determine whether the block should be skipped or accepted.\nIn cases where a node misses dataâsuch as shreds or entire blocksâthere is a âRepairâ recovery mechanism that allows it to request missing information from other nodes, ensuring data completeness and integrity even in the presence of faults or delays.\nTogether, these components form the foundation of Alpenglowâs consensus protocol, aiming for high performance, strong fault tolerance, and efficient operation at scale. Since a 50+ page document can only be summarized, we encourage reading the actual detailed documentation: https://github.com/rogerANZA/Alpenglow-White-Paper/blob/main/Alpenglow-v1.1.pdf .\nRewards and Incentives\nAlpenglow introduces a revamped rewards and incentive system that aligns with its new consensus design, aiming to preserve economic fairness, eliminate inefficiencies, and reinforce active participation. Under the previous protocol, validators submitted on-chain vote transactions for each slot, incurring significant overhead in bandwidth, transaction fees, and processing load. Alpenglow replaces this system with off-chain voting and efficient signature aggregation, dramatically reducing the cost and complexity of participation while maintaining reward fairness.\nEach validatorâs reward is proportional to their stake, as in traditional proof-of-stake systems. For every voting action a validator performs, they receive a portion of the protocolâs inflationary issuance. This issuance is calculated per slot and distributed based on stake weight. In each slot, a validator casts one of two possible votes (e.g., in favor of a block or to skip it), and these are collected and aggregated by the designated leader 8 slots in the future.\nTo ensure validators remain engaged and do not game the system, Alpenglow introduces stricter rules and more transparent accountability. Validators are required to cast exactly one valid vote per slot. Submitting conflicting votes is detectable. Validators that fail to participate are not eligible for rewards and risk being excluded from the active set of validators.\nA mechanism introduced alongside this new model is the Validator Admission Ticket (VAT). Since voting is no longer posted on-chain (and hence no longer requires direct transaction fees), the VAT serves as an upfront cost to maintain an equivalent economic barrier. Before each epoch, each validator must pay a fixed feeâinitially set to 1.6 SOL per epoch. This fee is non-refundable and burned, helping to offset inflation while preserving the economic dynamics of the current system. If a validator does not hold sufficient balance to cover the VAT, it is removed from the validator set.\nLeaders also receive compensation for their role in aggregating and submitting vote data. For each valid aggregate they submit (either notarization or skip votes), the leader earns a reward equal to that of all votes included in the aggregate. Additionally, leaders are rewarded with a flat bonus for including fast-finalization or finalization certificates, recognizing the higher computational cost of processing aggregate signatures. These rewards and incentives are described in more detail in the SIMD: https://github.com/solana-foundation/solana-improvement-documents/pull/326\nVoting Process\nThe voting process will proceed as follows:\n-\nDiscussion period: Validators are encouraged to participate in discussions to address any concerns.\n-\nStake weight collection period: Stake weights will be captured and published for voting. Validators will have the opportunity to verify these weights.\n-\nVote token distribution will require validators to utilize the adapted Jito Merkle Distributor tool (available at https://github.com/laine-sa/solgov-distributor ) to claim the vote tokens corresponding to their stake weights.\n-\nThree token destination accounts will be created for voting choices: Yes, No, and Abstain.\nValidators will have a designated period to vote by sending their tokens to the respective addresses.\n-\nAfter the voting period, if the sum of Yes votes is equal to or greater than 2/3 of the total sum of Yes + No votes, the proposal will pass.\n-\nThe proposal has a quorum threshold of 33%, abstentions count towards the quorum.\n-\nAll announcements regarding this process will be made in the Governance category of the Solana Developer Forums.\n-\nStake weights and a tally script will be available at https://github.com/laine-sa/solgov-distributor/tree/master/votes/simd0326\nTimeline\n-\nEpoch 833â838: Discussion period\n-\nEpoch 839: Stake weights captured and published, discussion/confirmation of stake weights\n-\nEpochs 840â842: Voting tokens available to claim, voting completes at the end of epoch 842\nDiscussion\nActive participation in discussions about this proposal is crucial. Discussions may also take place in the various forums and channels mentioned at the beginning.\n9 Likes\nripatel-jump\nAugust 14, 2025, 9:46pm\n2\nStrong support from Firedancer regarding replacement of the consensus algorithm. These simplifications save months of work getting TowerBFT edge cases right. Thank you to the Alpenglow team for this important contribution.\nI wonât comment on reward changes, but looking forward to hear from validator operators.\n7 Likes\nRugCity\nAugust 14, 2025, 9:57pm\n3\nBefore each epoch, each validator must pay a fixed feeâinitially set to 1.6 SOL per epoch. This fee is non-refundable and burned, helping to offset inflation while preserving the economic dynamics of the current system.\nI would like to know more about how this 1.6 number is chosen, thats only about a 25% decrease from todays voting costs. Do we not have an opportunity here to make it much more affordable to run a validator?\n6 Likes\nRoger\nAugust 15, 2025, 9:49am\n4\nThe 1.6 SOL was chosen to mimic the current economics. Now on-chain votes cost about 2 SOL per epoch, and the 1.6 SOL is simply 80% of that (so basically the same, but a little lower to make sure that nobody is worse off). After Alpenglow has launched and is stable, we discuss economics again. We do not want to disrupt the economics for the âAlpenSwitch.â We initially continue with roughly the same set of trustworthy validators as we have now.\n4 Likes\nvytick\nAugust 15, 2025, 10:17am\n5\nIf proof-of-history is replaced, how does it change transaction expiration policy? Currently txn is valid for 150 hashes after its blockhash was made. If this is removed in Alpenglow, does this mean, that there is no formal ttl? And user cant rely on the blockhash invalidation to know whether the txn is included in the block or no? Or is there any other mechanic, that replaces the old way of txn invalidation?\n4 Likes\nRoger\nAugust 15, 2025, 10:33am\n6\nCurrently, if I remember correctly a tx is valid for 150 slots. We can just keep that, we still have slots.\n(Since you mentioned it: This rule may be a problem going forward, some people in finance say that they need a longer validity â just including a sequence number might be better. All of this is independent of Alpenglow though.)\n4 Likes\nvytick\nAugust 15, 2025, 10:46am\n7\nIt causes problems not only to a finance (inspecting instructions for example takes a long time when txn is more complex), since ~60s is pretty short time window. On the other hands it makes sure you know the txn will get into final state in 60s without any other user action. Adding other validation or prolonging the time would make sense though.\n2 Likes\nrplust\nAugust 15, 2025, 10:55am\n8\nIf votes will now be offchain as opposed to being recorded onchain through vote transactions, what would be the best way to track a validatorâs voting performance (e.g. whether they voted for a slot or not, if they voted twice, if they voted in a timely manner)?\n4 Likes\nRoger\nAugust 15, 2025, 11:15am\n9\nWhether validators voted we will still see in the certificates and aggregates (which both go on chain). There is no more incentive to vote late, since there is no more punishment for voting wrongly (e.g. on the wrong branch). Everybody just votes truthfully, no speculation necessary. However, we will collect some metrics. If we eventually see bad behavior, we are going to design rules that punish that bad behavior.\n5 Likes\nRoger\nAugust 15, 2025, 11:22am\n10\nYes, this is something that is already discussed among the Solana people (independently from Alpenglow).\n3 Likes\nvytick\nAugust 15, 2025, 11:43am\n11\nIs there a place I can read more about this discussion?\n2 Likes\nRoger\nAugust 15, 2025, 12:44pm\n12\nNothing written so far, only oral discussions.\n4 Likes\npolar\nAugust 15, 2025, 1:11pm\n13\nMy concern is that while a new architecture is being designed for thousands of nodes, having a fixed VAT of 1.6 SOL per epoch still creates a high entry barrier for new validators. This effectively protects the current active set and discourages new participants from entering validation.\nIâve seen the response in replies that 1.6 SOL was chosen to mimic the current economics and that this figure will be revisited later.\nStill, I wanted to share the thoughts that came to mind while reading the proposal. Iâll revisit them once the 1.6 SOL rate is discussed separately.\nIâm not an engineer or an economic expert => just sharing ideas:\n1. Pro-rata VAT based on active stake\nIf we have 1000 validators, the total VAT for all would be 1600 SOL per epoch. That amount would be split among all active validators proportionally to their active stake.\n2. Segmentation by stake size\nValidators could be grouped by active stake (small/medium/large) with corresponding VAT rates â for example: 0.5 / 1 / 3 SOL per epoch.\nAlternatively, VAT could have a minimum and maximum (e.g., 0.5â5 SOL) with a curve to determine the exact cost based on active stake.\nBoth approaches still offset inflation.\n-\nThe first approach redistributes the cost proportionally and greatly lowers the economic barrier, but it could lead to an unlimited number of validators, so extra measures (like an active set limit or minimum stake) would likely be needed.\n-\nThe second approach is more balanced â a compromise between evenly sharing costs and maintaining an economic threshold.\n5 Likes\nRoger\nAugust 15, 2025, 1:34pm\n14\nThanks for your suggestions (to be considered in the future, so to speak). They are quite different from anything we ever considered. Your second proposal would be problematic since itâs a step function, so it can be profitable to cut a validator into two (which is something we want to prevent). In the first proposal, stake splitting is âfree,â so big validators could just split into many medium size validators and then drive out the small ones by taking all the slots.\nFrom a security point of view it would be best to have n independent validators, all with roughly the same stake, with n in the area of maybe 100. Rather than having more, we would like to have more (geographic) diversity. Having 5,000 validators in close geographic proximity does not make the system more secure.\n5 Likes\npolar\nAugust 15, 2025, 2:11pm\n15\nI also wanted to ask about rewards. Many validators currently operate with a 0% staking fee and 0% Jito fee, relying heavily on block rewards.\nHas there been any discussion on the economic implications of how the new design â especially with the introduction of new reward types â might impact the reward structure for validators?\n2 Likes\nRoger\nAugust 15, 2025, 3:33pm\n16\nSummarizing:\nRewards + MEV: No change\nCompute/Network Cost: Will be less\nCost for Votes: Replaced by VAT, but only 80%, so less\n2 Likes\nbluelotus\nAugust 16, 2025, 2:48am\n17\nSimplifying consensus and achieving sub-second finality is a big leap - looking forward to it.\n5 Likes\ncfl0ws\nAugust 16, 2025, 12:59pm\n18\nIntroduction\nThanks for putting up the proposal. To me, there are two primary topics of discussion, the Alpenglow governance process mechanics and the decision whether or not to adopt Alpenglowâs votor mechanism.\nGovernance process mechanics\nIt goes without saying that Alpenglow represents a major and significant change to all aspects of the Solana protocol, the validators who run the chain and the users who use it.\nBecause of the immensity of the proposed change, I would suggest the following sequence of steps -\n1 - Defining the SIMDs that will be presented to determine whether or not to adopt Alpenglow\nFrom what Iâve read in this proposal, SIMD-0326 is intended to to replace the current voting mechanism with the Alpenglow voting mechanism named Votor. I also infer from this SIMD that a second SIMD will be proposed that would determine to replace the current block dissemination mechanism with the Alpenglow block dissemination mechanism named Rotor.\nAm I interpreting this correctly? Are there other SIMDs related to the core Alpenglow protocol contemplated in addition to these?\nAssuming there are a sequence of SIMDs, what are the consequences and dependencies of one SIMD on another? For example, I assume if SIMD-0326 was to pass, it would not require the Rotor SIMD to pass, in order for Votor to operate, i.e. they are independent of each other.\n2 - Define the scope of each SIMD\nThe scope of the SIMDs should be clearly defined. For example, the title of SIMD-0326 is quite broad. I had to read and infer from the reading it that SIMD-0326 is focused on replacing the current voting mechanism with the Alpenglow Votor voting mechanism.\nThe title of each SIMD should clearly state the scope of the SIMD and the body of the SIMD should define that scope in detail. Iâd also suggest that potential benefits, risks and their mitigation are listed. Linking or referring to a specific part of the whitepaper, if available, would also be acceptable way to do this.\nClearly state what voters are being asked to vote on in each SIMD. For example, again, I infer that SIMD-0326 is asking voters on whether or not to replace the current voting mechanism with Votor. This should be stated explicitly within the SIMD to avoid confusion.\nWhether or not to adopt Alpenglowâs voting mechanism, Votor\nThis is a much larger discussion. It would be helpful to have it in a single place and here is probably the best place for that discussion. Others will likely share more detailed concerns than I do, however I do plan a second response focusing in a more detailed way on Votor.\nIn the meantime, at a more meta level, I think any SIMD asking voters to adopt a change to the core Solana protocol should include a testing, deployment and fallback plan. I donât see any plan listed in this SIMD and without it, would not be comfortable voting in favor of SIMD-0326 in its current form.\nConclusion\nI feel that more thought should be given to the SIMD process as it relates to Alpenglow adoption. This means listing which SIMDs will be presented to determine whether to adopt Alpenglow, defining the scope of each SIMD and clearly laying out the decision each SIMD is intended to facilitate.\nAlpenglow adoption SIMDs should include a discussion of benefits, risks and their potential mitigations, as well as a testing, deployment and fallback plan.\nAlpenglow adoption is a significant and potentially exciting change for the Solana network and its community. A thoughtful SIMD process will increase its chances for successful adoption.\nI see this first SIMD as a step in that direction and look forward to the authorsâ response and hopefully revisions. I look forward to staying engaged along the way.\n6 Likes\nsolostaker\nAugust 16, 2025, 11:33pm\n19\n- Could you expand on the future plans for the VAT? As I understand it SIMD-0257 proposed removing vote fees entirely, greatly reducing the fixed cost for validator operators. Is such a thing possible under the VAT scheme?\n- What is the replacement for blockhash now that PoH is gone? As an ecosystem observer this seems like the biggest double spend attack vector, do we still have the guarantee that transactions cannot be spoofed or resubmitted under the new schema?\n- Could you expand on Definition 17 from the paper, specifically what is Îtimeout? I see that is is 1Î + 2Î, what does this mean in ms? Does Timeout correspond to 400ms as in leader will have less time to build the block? Are there expected changes to Jito auction because of Îtimeout?\n- What happens to unstaked nodes under Alpenglow? I see in the SIMD you specified that all validators are staked - will unstaked validators still be able to participate to send txs and run RPC queries?\n- How does section 2.7 work for transactions? âIn this case, slices 1,âŠ,t - 1 are ignored for the purpose of executionâ - how should I alter my user workflow if this happens? If my user submits a tx and it ends up getting ignored will it be retried? Or should we ask them to resign the tx?\n- Finally my boomer question, what is the motivation? is it not possible to speed up TowerBFT? Or is there some fundamental flaw in Solana that requires us to switch? I welcome the speedup but this seems like a really risky upgrade that opens us up to a lot of FUD, could you provide some context on why this is necessary - especially now in a bull market with so many eyes on us.\n- To add on to the previous point, what steps are we taking to test this change? It seems on par with The Merge, will there be a parallel chain or will this take place all at once? Are there any auditors that have signed off on this change? Are there any eyes on loss of funds attacks?\n2 Likes\nUmberto\nAugust 18, 2025, 7:50am\n20\nWe tried to rise this topic multiple times, and we believe there are some points should be assessed more carefully. The main reason around VAT is\nhowever, the way it is presented drastically change the economics.\nIndeed, with current framework, each validator pays ~2 SOL per epoch for voting, and half of it is burned. This means that ~1 SOL per validator is paid back to block proposers. This is ~ 1k SOL (with 1k validators) per epoch redistributed to validators. If current proposal pass, we burn entirely the VAT, so we have 0 SOL redistributed to validators.\nIf, roughly speaking, we say that a 0.2% stake takes 0.2% of this 1k SOL, we have that a 0.2% stake is neutral regarding vote fees now (since per epoch it receives 2 SOL, i.e. what it pays). With this proposal, the economics is drastically changed since now all stake is in loss for voting.\nOne can argue that we now have freed CU we can use for normal transactions, but the relation is not straightforward (and needs a closer analysis). Further, there is some evidence of a lack of CU usage, which could be for lack of user demands (unlikely) or for an inefficiency of current Agave code (see e.g. here Timing Games on Solana: Validator Incentives, Network Impacts, and Agave's Hidden Inefficiencies ). Since this is not addressed here but highly correlated, we believe the change around VAT is more invasive than what discussed in the SIMD.\nWe believe that a VAT is mandatory to avoid some attack surfaces (we analysed them here Distilling Information from Alpenglow Consensus ) however we should assess if it makes sense to burn it. Here I donât see a proper assessment of this issue.\n4 Likes\nnext page â\nRelated topics\nTopic\nReplies\nViews\nActivity\nProposal For Introducing a Programmatic, Market-Based Emission Mechanism Based on Staking Participation Rate\nGovernance\nsimd\n63\n7452\nMarch 14, 2025\nProposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta\nGovernance\nfeature\n,\ncore\n76\n12928\nDecember 25, 2024\nWho votes - three proposals\nGovernance\n24\n2936\nApril 16, 2025\nProposal for an In-Protocol Distribution of Block Rewards to Stakers\nGovernance\n24\n3580\nMarch 14, 2025\nProposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet\nGovernance\nfeature\n,\ncore\n25\n5613\nOctober 4, 2025\nDiscourse Footer"}
{"url":"https://gov.optimism.io/t/builder-grant-proposal-op-security-proxy-local-pre-execution-revert-interception-for-the-superchain/10845","domain":"gov.optimism.io","title":"[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain - Governance Fu","hash":"0a47e922f187b6bdd32a5e3ccf251dc9955f7c4e977e7c62a83a5c04c78db24f","tokens":1860,"chars":7437,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112157896,"text":"Optimism Collective\n[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\nGrants đŽ\nGovernance Fund Missions\nCypherin\nSeptember 4, 2026, 11:02am\n1\nHi everyone. I am a solo systems developer building OP Security Proxy ( GitHub - Ishant5436/op-sec-proxy · GitHub ), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions before broadcasting to OP Stack nodes. On EVM rollups, end users and automated agents pay gas fees even when transactions revert on chain due to stale oracle states, localized slippage, or sandwich attacks. For retail users, burning gas on a failed execution creates frustration, and for wallet teams it leads to avoidable support tickets.\nThe proxy sits between standard wallets or clients and public Optimism RPC nodes. When a client issues an eth_sendRawTransaction request, the proxy intercepts the raw payload and simulates it in process using revm against current chain state. If the simulation executes successfully, the transaction is forwarded upstream to the sequencer over an existing hyper connection pool. If the simulation reverts, the proxy aborts the broadcast completely so zero gas is burned on chain, and immediately returns a standard JSON-RPC error containing decoded Solidity custom errors or panic codes along with an estimated gas saved metric.\nThe core implementation is open-source under the MIT license with 40 automated tests passing across the Rust core and TypeScript client SDK. In empirical benchmarks against mainnet.optimism.io , the proxy introduces a minimal 11.8 millisecond processing overhead on fair keep-alive connections with session reuse. For clients that make cold requests without connection reuse, the proxy internal connection pool eliminates repetitive TLS 1.3 handshakes to remote endpoints, amortizing roundtrip latency by roughly 97 milliseconds. The full reproduction methodology and raw telemetry logs are recorded in BENCHMARK_RESULTS.md ( https://github.com/Ishant5436/op-sec-proxy/blob/main/BENCHMARK_RESULTS.md ).\nUncached transaction simulation over public internet RPC currently averages approximately 2.7 seconds because the execution engine must fetch contract state slots across the network during execution. I am requesting 10,000 OP for an initial builder grant to fund three engineering milestones over the next three months. The initial phase tackles state caching, replacing network RPC state queries with a local in-memory LRU trie cache for warm contract bytecode and storage slots to drive simulation latency down toward a sub-65 millisecond target. Following that, work shifts to developer adoption with a TypeScript provider wrapper and standardized error decoding for wallet integrations. The final phase expands routing across OP Mainnet, Base, Mode, Zora, and Fraxtal alongside reproducible Docker containers and systemd service packaging for node operators.\nAs an individual engineer, I rely on Rust memory safety guarantees, cargo-audit automated dependency scanning, and reproducible GitHub Actions workflows rather than corporate support infrastructure. All code is public and modular. I previously shared an introductory post in the general discussion section of the governance forum under thread 10810 ( OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions ), and this grant application will allow me to build and package the middleware as a permanent, zero-cost public good for the Superchain ecosystem.\nOP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\nAnzus_GemWallet\nSeptember 4, 2026, 2:03pm\n2\nFrom a user-support perspective, how will the proxy handle cases where the local simulation is based on slightly stale state but the transaction might still succeed on-chain? It would be useful to understand whether the default behavior is to fail open, and how the wallet communicates simulation uncertainty versus a definite revert.\nCypherin\nSeptember 4, 2026, 4:56pm\n3\nRegarding stale state and transient boundaries, the proxy strictly defaults to fail-open whenever there is execution ambiguity or when a simulation fails due to state retrieval timeouts or RPC sync lags. If the proxy cannot deterministically prove a failure against the current block header, it logs the warning and forwards the raw transaction directly upstream to the sequencer so user submissions are never blocked by middleware latency or momentary node lag.\nFor transaction categorization, the proxy distinguishes between invariant contract panics and state-dependent reverts. Static reverts such as invalid signatures, nonce mismatches, unauthorized access, or insufficient balance are deterministic and will fail regardless of whether the head moved by a block. In those cases, the proxy returns a standard -32000 error with the decoded reason and flags the simulation as definite.\nState-dependent reverts, such as slippage limits on decentralized exchanges or time-sensitive oracle feeds, are where stale state matters most. When revm returns a revert from a condition that depends on volatile storage slots, the proxy includes an uncertainty flag in the JSON-RPC error payload under data.confidence set to uncertain alongside the block number used for simulation. In the TypeScript provider wrapper, wallets can inspect this field to decide how to treat the result. For instance, a wallet can show a clear distinction between a transaction that is guaranteed to revert versus one that failed due to potential slippage drift at the head, or choose to pass uncertain transactions upstream automatically with a warning notice in the user interface.\n1 Like\nCypherin\nSeptember 6, 2026, 6:57pm\n4\nA quick update for the review team following up on the discussion above. The simulation confidence classification and fail-open behavior discussed here are now fully implemented and passing in the public repository under commit 8376212.\nWhen revm encounters transient database or RPC connection timeouts, the proxy classifies the execution as uncertain and automatically forwards the raw transaction directly upstream to the sequencer when fail-open is enabled, ensuring zero user drop-offs. If a wallet wishes to inspect or handle the simulation result, the JSON-RPC error payload returns the confidence rating along with decoded contract reverts. The TypeScript client library at @op-sec /client has also been updated with these types, and all unit, integration, and linter checks pass with zero warnings across 32 tests.\n1 Like\nCypherin\nSeptember 8, 2026, 7:39pm\n5\nA quick procedural update for the review team: project metadata and repository ownership verification have now also been completed and published onchain via OP Atlas at https://atlas.optimism.io/project/0x6ab1a8cbf07a602a09c6e754b34361f336ba8e62c1a4792659d7b5ac4a27663b .\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nOP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\nâš General\n3\n103\nSeptember 4, 2026\nShutterized Optimism â An Encrypted Mempool for the OP Stack\nTechnical Proposals\n4\n7310\nJuly 5, 2023\nGrant Application: superchain-guard\nGrants Updates\nseason-8\n,\nseason-9\n6\n212\nMay 19, 2026\n[MISSION REQUEST] Open-source transaction simulator\nGovernance Fund Missions\n3\n522\nAugust 5, 2025\nUpgrade Proposal #13: OPCM and Incident Response improvements\nProtocol Upgrade\n19\n1374\nMarch 20, 2025"}
{"url":"https://docs.ens.domains/web/quickstart","domain":"docs.ens.domains","title":"Quickstart | ENS Docs","hash":"0fd36ce3ef8c6991b5104cfad896d5f4f643d472173dd802e0822f7f391e3be8","tokens":818,"chars":3269,"crawler":"hive-genesis","verified":"unchecked","ts":1791112158527,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\nQuickstart\nHey there đ, this is the quickstart guide. If you want to learn the process checkout everything about ENS in dApps .\nIf you would rather just clone an example repository checkout these:\nStarter Kits\nConnectKit\nby Family\n- Create React App\n- Vite + React\n- Next.js\n- Next.js + Siwe\nTry it!\nRainbowkit\nby Rainbow\n- Create React App\n- Vite + React\n- Next.js\n- Next.js App Router\n- Remix\nTry it!\nWeb3Modalv2\nby WalletConnect\n- React\n- Vue\n- Javascript\n- Flutter\n- Android\n- iOS\nTry it!\nAdd to your dApp\nThis quickstart guide assumes you have a basic understanding of React.\nInstallation\nTerminal\nnpm install wagmi viem @tanstack/react-query\nShowing the User Profile\nThe below codesnippet demonstrates how you can create a basic user profile section that shows the users ENS name and avatar.\nThe snippet leverages the useAccount , useEnsName , and useEnsAvatar hooks from wagmi.\nnick.eth 0x0000...0000\njefflau.eth 0x0000...0000\nvitalik.eth 0x0000...0000\nimport { useAccount, useEnsAvatar, useEnsName } from 'wagmi'\nexport const EnsProfile = () => {\nconst { address } = useAccount ()\nconst { data : name } = useEnsName ({ address, chainId: 1 })\nconst { data : avatar } = useEnsAvatar ({ name, chainId: 1 })\nreturn (\n< div className = \"flex items-center gap-2\" >\n< img src = { avatar } className = \"h-8 w-8 rounded-full\" />\n< div className = \"flex flex-col leading-none\" >\n< span className = \"font-semibold\" > { name } \n< span className = \"text-grey text-sm\" > { address } \n\n)\n}\nText Record Lookups\nnick.eth\nKey Value\nTextRecords.tsx\nimport { useEnsAvatar } from 'wagmi'\nimport { UseEnsTextsProps, useEnsTexts } from '../hooks/useEnsTexts'\nimport { Table } from './ui/Table'\nexport const TextRecords = ({ name , keys } : UseEnsTextsProps ) => {\nconst { data : avatar } = useEnsAvatar ({ name, chainId: 1 })\nconst { data : texts } = useEnsTexts ({ name, keys })\nreturn (\n<>\n< div className = \"mb-4 flex items-center gap-2\" >\n< img\nsrc = { avatar || '/img/fallback-avatar.svg' }\nclassName = \"h-8 w-8 rounded\"\n/>\n< span className = \"font-semibold font-semi-mono\" > { name } \n\n< Table\ncolumns = { [ 'Key' , 'Value' ] }\nrows = { texts?. map (({ key , value }) => [key, value]) || [] }\n/>\n\n)\n}\nAddress Record Lookups\nWhile ENS resolution always starts from Ethereum L1, you can store addresses for other chains in ENS records.\ngregskril.eth\nCoinType Address\nAddressRecords.tsx\nimport { useEnsAvatar } from 'wagmi'\nimport { UseEnsAddressesProps, useEnsAddresses } from '../hooks/useEnsAddresses'\nimport { Table } from './ui/Table'\nexport const AddressRecords = ({ name , coinTypes } : UseEnsAddressesProps ) => {\nconst { data : avatar } = useEnsAvatar ({ name, chainId: 1 })\nconst { data : addresses } = useEnsAddresses ({ name, coinTypes })\nreturn (\n<>\n< div className = \"mb-4 flex items-center gap-2\" >\n< img\nsrc = { avatar || '/img/fallback-avatar.svg' }\nclassName = \"h-8 w-8 rounded\"\n/>\n< span className = \"font-semibold font-semi-mono\" > { name } \n\n< Table\ncolumns = { [ 'CoinType' , 'Address' ] }\nrows = {\naddresses?. map (({ coinType , address }) => [coinType, address]) || []\n}\n/>\n\n)\n}"}
{"url":"https://forum.skyeco.com/c/grove-prime/103","domain":"forum.skyeco.com","title":"Latest Grove Prime topics - Sky Forum","hash":"a7300f5b054996e23fa121d93926c86d7aa4e84366d46ff62da162d45e861724","tokens":627,"chars":2507,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112159546,"text":"Sky Forum\nGrove Prime\nTopic\nReplies\nViews\nActivity\nAbout the Grove Prime category\n0\n125\nJuly 10, 2025\nGrove cBEAM Configuration\noea\n,\npas\n24\n381\nOctober 2, 2026\n[October 8, 2026] - Proposed Changes to Grove for Upcoming Spell\n8\n190\nOctober 2, 2026\nYvonPiPi's Grove Delegate Communications\n9\n220\nOctober 1, 2026\n[September 24, 2026] - Proposed Changes to Grove for Upcoming Spell\n9\n254\nSeptember 21, 2026\n[September 10, 2026] - Proposed Changes to Grove for Upcoming Spell\n9\n286\nSeptember 7, 2026\n[August 27, 2026] - Proposed Changes to Grove for Upcoming Spell\n9\n322\nAugust 24, 2026\nDocGriffin Grove Delegate Communications\n2\n70\nAugust 21, 2026\n[August 13, 2026] - Proposed Changes to Grove for Upcoming Spell\n7\n349\nAugust 14, 2026\nGrove Delegates: Bootstrapping Phase\n6\n211\nAugust 3, 2026\n[July 16, 2026] - Proposed Changes to Grove for Upcoming Spell\n4\n341\nJuly 10, 2026\n[August 21, 2025] Proposed Changes to Grove for Upcoming Spell\ncentrifuge\n,\ngrove\n,\navalanche\n,\ngrove-liquidity-layer\n9\n659\nJuly 8, 2026\n[February 26, 2026] Proposed Changes to Grove for Upcoming Spell\n3\n329\nJune 25, 2026\n[July 2, 2026] - Proposed Changes to Grove for Upcoming Spell\n2\n329\nJune 24, 2026\nGrove - Proposed Additions to Morpho Vaults\n9\n551\nJune 23, 2026\n[June 4, 2026] - Proposed Changes to Grove for Upcoming Spell\n3\n318\nMay 29, 2026\n[May 7, 2026] - Proposed Changes to Grove for Upcoming Spell\n1\n303\nApril 24, 2026\n[April 23, 2026] - Proposed Changes to Grove for Upcoming Spell\n2\n282\nApril 14, 2026\n[April 9th, 2026] Proposed Changes to Grove for Upcoming Spell\n1\n140\nMarch 30, 2026\n[March 26th, 2026] Proposed Changes to Grove for Upcoming Spell\n1\n228\nMarch 12, 2026\n[December 11th, 2025] Proposed Changes to Grove for Upcoming Spell\n9\n657\nFebruary 23, 2026\n[February 12, 2026] - Proposed Changes to Grove for Upcoming Spell\n1\n202\nJanuary 30, 2026\nGrove - Risk Assessment - Paxos USDG\n0\n83\nJanuary 26, 2026\nTechnical Scope of GROVE\n2\n345\nJanuary 22, 2026\n[January 29, 2026] Proposed Changes to Grove for Upcoming Spell\ngrove\n,\ngrove-liquidity-layer\n7\n511\nJanuary 21, 2026\n[January 15th, 2026] Proposed Changes to Grove for Upcoming Spell\ngrove\n,\ngrove-liquidity-layer\n2\n403\nJanuary 9, 2026\n[Jan 15, 2026] Parameter Changes - Grove Allocator Vault\ngrove\n2\n128\nJanuary 9, 2026\nGrove - Risk Assessment - Agora AUSD Liquidity\n3\n328\nNovember 29, 2025\nGrove - Risk Assessment - Galaxy CLO 2025-1\n1\n447\nNovember 24, 2025\n[November 27th, 2025] Proposed Changes to Grove for Upcoming Spell\n0\n133\nNovember 11, 2025\nnext page â"}
{"url":"https://docs.monad.xyz/llms.txt","domain":"docs.monad.xyz","title":"Monad Documentation","hash":"1e63fd88cd8e6094b6982f8f2459d519092a1b0cf0877ff08727a6b3bf3ed0f0","tokens":6168,"chars":24670,"crawler":"hive-genesis","verified":"unchecked","ts":1791112160326,"text":"# Monad Documentation\n## Documentation\n### Introduction\n- [Introduction](https://docs.monad.xyz/index.md): Monad is a Layer-1 blockchain delivering high performance, true decentralization, and EVM compatibility.\n- [Why Blockchain?](https://docs.monad.xyz/introduction/why-blockchain.md): A simple mental model for the 'what' and 'why'.\n- [Why Monad: Decentralization + Performance](https://docs.monad.xyz/introduction/why-monad.md): Monad addresses today's performance bottlenecks through optimization while preserving decentralization.\n- [Monad for Users](https://docs.monad.xyz/introduction/monad-for-users.md): One-pager on Monad for users\n- [Monad for Developers: Transactions, Consensus, Parallel Execution, and MonadDb](https://docs.monad.xyz/introduction/monad-for-developers.md): Technical overview of Monad for developers: transactions, smart contracts, consensus, parallel execution, MonadDb, and the differences from Ethereum.\n### Developer Essentials\n- [Developer Essentials](https://docs.monad.xyz/developer-essentials/index.md)\n- [Network Information - Testnet](https://docs.monad.xyz/developer-essentials/testnet.md)\n- [Deployment Summary for Developers](https://docs.monad.xyz/developer-essentials/summary.md): Deployment Summary for Developers\n- [Differences between Monad and Ethereum](https://docs.monad.xyz/developer-essentials/differences.md)\n- [Transactions](https://docs.monad.xyz/developer-essentials/transactions.md)\n- [Wallet Developer Integration Guide](https://docs.monad.xyz/developer-essentials/wallet-developers.md): Guidance and recipes for wallet teams improving Monad support\n- [Gas Pricing](https://docs.monad.xyz/developer-essentials/gas-pricing.md): An estimated USD cost for a typical Monad transaction, plus how gas fees are calculated.\n- [Opcode Pricing](https://docs.monad.xyz/developer-essentials/opcode-pricing.md)\n- [Precompiles](https://docs.monad.xyz/developer-essentials/precompiles.md): How to use Monad's precompiled contracts\n- [Reserve Balance](https://docs.monad.xyz/developer-essentials/reserve-balance.md)\n- [EIP-7702 on Monad: How EOA Delegation Works](https://docs.monad.xyz/developer-essentials/eip-7702.md): EIP-7702 is supported on Monad with the same workflow as Ethereum. Learn how EOA delegation works, the Monad-specific details, and answers to common questions.\n- [Historical Data](https://docs.monad.xyz/developer-essentials/historical-data.md)\n- [Best Practices for Building High Performance Apps](https://docs.monad.xyz/developer-essentials/best-practices.md): Learn best practices for building high performance apps on Monad\n#### Network Information - Mainnet\n- [Network Information - Mainnet](https://docs.monad.xyz/developer-essentials/network-information/index.md)\n- [Tokens and Bridges](https://docs.monad.xyz/developer-essentials/network-information/tokens-and-bridges.md)\n#### Changelog\n- [Changelog](https://docs.monad.xyz/developer-essentials/changelog/index.md)\n- [Releases](https://docs.monad.xyz/developer-essentials/changelog/releases.md)\n### Tooling and Infrastructure\n- [Tooling and Infrastructure](https://docs.monad.xyz/tooling-and-infra/index.md)\n- [Agentic Payments](https://docs.monad.xyz/tooling-and-infra/agentic-payments.md)\n- [Analytics](https://docs.monad.xyz/tooling-and-infra/analytics.md)\n- [Monad Block Explorers: MonadVision and Monadscan](https://docs.monad.xyz/tooling-and-infra/block-explorers.md): Block explorers for Monad mainnet and testnet: MonadVision (BlockVision), Monadscan (Etherscan), JiffyScan, Tenderly, and Phalcon.\n- [Card Issuing on Monad: Immersve and Rain Stablecoin Cards](https://docs.monad.xyz/tooling-and-infra/card-issuing.md): Card issuing on Monad: launch debit, prepaid, and credit card programs that spend stablecoins at Visa and Mastercard merchants with Immersve and Rain.\n- [Cross-Chain](https://docs.monad.xyz/tooling-and-infra/cross-chain.md)\n- [Custody](https://docs.monad.xyz/tooling-and-infra/custody.md)\n- [DEX Aggregators](https://docs.monad.xyz/tooling-and-infra/dex-aggregators.md)\n- [Earn/Yield Infrastructure](https://docs.monad.xyz/tooling-and-infra/earn-yield.md)\n- [Onramps](https://docs.monad.xyz/tooling-and-infra/onramps.md)\n- [Oracles](https://docs.monad.xyz/tooling-and-infra/oracles.md)\n- [Payment Orchestrators](https://docs.monad.xyz/tooling-and-infra/payment-orchestrators.md)\n- [Privacy](https://docs.monad.xyz/tooling-and-infra/privacy.md)\n- [RPC Providers](https://docs.monad.xyz/tooling-and-infra/rpc-providers.md)\n#### Indexers\n- [Indexers](https://docs.monad.xyz/tooling-and-infra/indexers/index.md)\n- [Common Data](https://docs.monad.xyz/tooling-and-infra/indexers/common-data.md)\n- [Indexing Frameworks](https://docs.monad.xyz/tooling-and-infra/indexers/indexing-frameworks.md)\n#### Toolkits\n- [Toolkits](https://docs.monad.xyz/tooling-and-infra/toolkits/index.md)\n- [Foundry](https://docs.monad.xyz/tooling-and-infra/toolkits/foundry.md): Use Foundry to build, test, deploy, and debug contracts with the Monad execution environment.\n- [Hardhat](https://docs.monad.xyz/tooling-and-infra/toolkits/hardhat.md): Start a Hardhat 3 project for Monad or add Monad to an existing project.\n- [Monad Solonet](https://docs.monad.xyz/tooling-and-infra/toolkits/monad-solonet.md)\n#### Wallets\n- [Wallets](https://docs.monad.xyz/tooling-and-infra/wallets/index.md)\n- [Software Wallets](https://docs.monad.xyz/tooling-and-infra/wallets/software-wallets.md)\n- [Hardware Wallets](https://docs.monad.xyz/tooling-and-infra/wallets/hardware-wallets.md)\n- [Institutional Wallets](https://docs.monad.xyz/tooling-and-infra/wallets/institutional-wallets.md)\n- [Multisig Wallets](https://docs.monad.xyz/tooling-and-infra/wallets/multisig-wallets.md)\n#### Wallet Infrastructure\n- [Wallet Infrastructure](https://docs.monad.xyz/tooling-and-infra/wallet-infra/index.md)\n- [Embedded Wallets](https://docs.monad.xyz/tooling-and-infra/wallet-infra/embedded-wallets.md)\n- [Account Abstraction Providers](https://docs.monad.xyz/tooling-and-infra/wallet-infra/account-abstraction.md)\n- [Smart Account Implementations](https://docs.monad.xyz/tooling-and-infra/wallet-infra/smart-accounts.md)\n### Reference\n#### JSON-RPC\n- [JSON-RPC Overview](https://docs.monad.xyz/reference/json-rpc/overview.md): JSON-RPC methods, differences from Ethereum, rate limits, and error codes\n- [JSON-RPC Playground](https://docs.monad.xyz/reference/json-rpc/playground.md): Interactive JSON-RPC request builder for all Monad RPC methods\n- [JSON-RPC API Reference](https://docs.monad.xyz/reference/json-rpc/api.md): Reference for Monad's JSON-RPC interface\n#### Execution Events\n- [Execution Events](https://docs.monad.xyz/execution-events/index.md)\n- [Release notes](https://docs.monad.xyz/execution-events/release-notes.md)\n- [Execution events overview](https://docs.monad.xyz/execution-events/overview.md)\n- [Event rings in detail](https://docs.monad.xyz/execution-events/event-ring.md)\n- [C API](https://docs.monad.xyz/execution-events/c-api.md)\n- [Rust API](https://docs.monad.xyz/execution-events/rust-api.md)\n- [Consensus events](https://docs.monad.xyz/execution-events/consensus-events.md)\n- [Advanced topics](https://docs.monad.xyz/execution-events/advanced.md)\n##### Getting Started\n- [Getting started](https://docs.monad.xyz/execution-events/getting-started/index.md)\n- [Building the C example program](https://docs.monad.xyz/execution-events/getting-started/c.md)\n- [Building the Rust example program](https://docs.monad.xyz/execution-events/getting-started/rust.md)\n- [Running the example program on snapshot data](https://docs.monad.xyz/execution-events/getting-started/snapshot.md)\n- [Setting up your Monad node](https://docs.monad.xyz/execution-events/getting-started/setup-node.md)\n- [Running the example program on live data, and next steps](https://docs.monad.xyz/execution-events/getting-started/final.md)\n#### Staking\n- [Staking Overview](https://docs.monad.xyz/reference/staking/overview.md): How to interact with Monad's staking system\n- [Staking API Reference](https://docs.monad.xyz/reference/staking/api.md): Reference for Monad's staking precompile\n#### Machine Payments Protocol\n- [MPP Overview](https://docs.monad.xyz/reference/mpp/overview.md): Send and accept payments on Monad using the Machine Payments Protocol\n- [MPP API Reference](https://docs.monad.xyz/reference/mpp/api.md): Reference for the @monad-crypto/mpp package\n### Guides\n- [Guides](https://docs.monad.xyz/guides/index.md)\n- [Build with NFTs](https://docs.monad.xyz/guides/build-with-nfts.md): How to build an NFT project on Monad: standards, a deploy quickstart, and the tooling for minting, marketplaces, indexing, wallets, and more.\n#### Add Monad to Wallet\n- [Add Monad to Wallet](https://docs.monad.xyz/guides/add-monad-to-wallet/index.md)\n- [Add Monad Mainnet to Wallet](https://docs.monad.xyz/guides/add-monad-to-wallet/mainnet.md)\n- [Add Monad Testnet to Wallet](https://docs.monad.xyz/guides/add-monad-to-wallet/testnet.md)\n#### Deploy a Contract\n- [Deploy a Contract](https://docs.monad.xyz/guides/deploy-smart-contract/index.md)\n- [Deploy a smart contract on Monad using Foundry](https://docs.monad.xyz/guides/deploy-smart-contract/foundry.md)\n- [Deploy a smart contract on Monad using Hardhat](https://docs.monad.xyz/guides/deploy-smart-contract/hardhat.md)\n- [Deploy a smart contract on Monad using Remix](https://docs.monad.xyz/guides/deploy-smart-contract/remix.md)\n#### Verify a Contract\n- [Verify a Contract](https://docs.monad.xyz/guides/verify-smart-contract/index.md)\n- [Verify a smart contract on Monad using Foundry](https://docs.monad.xyz/guides/verify-smart-contract/foundry.md)\n- [Verify a smart contract on Monad using Hardhat](https://docs.monad.xyz/guides/verify-smart-contract/hardhat.md)\n#### Use an Indexer\n- [Use an Indexer](https://docs.monad.xyz/guides/indexers/index.md)\n- [How to index token transfers with GhostGraph](https://docs.monad.xyz/guides/indexers/ghost.md)\n- [How to build a transfer notification bot with Envio HyperIndex](https://docs.monad.xyz/guides/indexers/tg-bot-using-envio.md)\n- [How to query token data with Envio HyperSync](https://docs.monad.xyz/guides/indexers/token-snapshot-hypersync.md)\n- [How to index every WMON transfer using QuickNode Streams](https://docs.monad.xyz/guides/indexers/quicknode-streams.md)\n#### Build with Uniswap v4 Hooks\n- [Build with Uniswap v4 Hooks](https://docs.monad.xyz/guides/uniswap-v4-hooks/index.md): Build, test, and deploy custom Uniswap v4 pool behavior on Monad with Foundry.\n- [Set up the hook project](https://docs.monad.xyz/guides/uniswap-v4-hooks/setup.md): On this page, you will install the pinned source, run local tests, and prepare a Monad Testnet account.\n- [Deploy the hook and test tokens](https://docs.monad.xyz/guides/uniswap-v4-hooks/deploy.md): On this page, you will deploy a Counter hook and two mock tokens on Monad Testnet.\n- [Exercise and verify the pool](https://docs.monad.xyz/guides/uniswap-v4-hooks/pool-lifecycle.md): On this page, you will initialize a testnet pool, mint an owned position, swap through Universal Router, remove liquidity, and revoke approvals.\n- [Customize and publish a hook](https://docs.monad.xyz/guides/uniswap-v4-hooks/customize-and-publish.md): On this page, you will customize Counter, find contract addresses, and prepare your hook for mainnet.\n#### Execution Events\n- [How to accelerate your app with Execution Events](https://docs.monad.xyz/guides/execution-events/index.md)\n- [Set up Execution Events](https://docs.monad.xyz/guides/execution-events/setup.md)\n- [How to Consume Execution Events in Rust](https://docs.monad.xyz/guides/execution-events/consume-rust.md)\n#### EVM Resources\n- [EVM Resources](https://docs.monad.xyz/guides/evm-resources/index.md)\n- [EVM Behavior](https://docs.monad.xyz/guides/evm-resources/evm-behavior.md)\n- [Solidity Resources](https://docs.monad.xyz/guides/evm-resources/solidity-resources.md)\n##### Other Languages\n- [Other Languages](https://docs.monad.xyz/guides/evm-resources/other-languages/index.md)\n- [Vyper](https://docs.monad.xyz/guides/evm-resources/other-languages/vyper.md)\n- [Yul](https://docs.monad.xyz/guides/evm-resources/other-languages/yul.md)\n#### More guides\n- [How to build a basic dApp with Scaffold-ETH](https://docs.monad.xyz/guides/scaffold-eth.md)\n- [Custom Stablecoins on Monad with Brale](https://docs.monad.xyz/guides/brale.md)\n- [How to connect a wallet to your app with Reown AppKit](https://docs.monad.xyz/guides/reown.md)\n- [How to build an MCP server that can interact with Monad Testnet](https://docs.monad.xyz/guides/monad-mcp.md)\n- [x402 on Monad: Set Up a Payable HTTP Endpoint](https://docs.monad.xyz/guides/x402.md): x402 on Monad: set up a payable HTTP endpoint on mainnet or testnet, build an app with the Monad x402 facilitator, and use the facilitator API.\n- [ERC-8004 on Monad: Register Trustless Agents](https://docs.monad.xyz/guides/erc-8004.md): ERC-8004 (Trustless Agents) on Monad: register an agent in the Identity Registry, add feedback in the Reputation Registry, and see use cases and best practices.\n- [How to build with ERC-6551 (Token-Bound Accounts) on Monad](https://docs.monad.xyz/guides/erc-6551.md): Give every NFT its own smart-contract wallet on Monad using the canonical Tokenbound ERC-6551 deployment.\n- [How to make your Monad contract clear-signable (ERC-7730)](https://docs.monad.xyz/guides/clear-signing.md)\n- [How to build a portfolio viewer using Moralis API](https://docs.monad.xyz/guides/moralis-api.md)\n- [How to add swaps to your app using Kuru Flow](https://docs.monad.xyz/guides/kuru-flow.md)\n- [How to build custom deep links in an Expo-based mobile app](https://docs.monad.xyz/guides/deeplinks-using-expo.md)\n##### Mera\n- [How to create passkey accounts with Mera](https://docs.monad.xyz/guides/mera.md): Create and recover Monad accounts from a passkey, with no seed phrase.\n- [How to use Mera with React Native](https://docs.monad.xyz/guides/mera/react-native.md): Create and reuse passkey-derived Monad accounts in a React Native app.\n#### Templates\n- [How to use the React Native Privy embedded wallet template](https://docs.monad.xyz/templates/react-native-privy-embedded-wallet.md)\n- [How to use the React Native sponsored transactions template](https://docs.monad.xyz/templates/react-native-privy-pimlico-sponsored-transactions.md)\n- [How to use the React Native Thirdweb embedded wallet template](https://docs.monad.xyz/templates/react-native-thirdweb-embedded-wallet.md)\n- [How to use the Next.js PWA Privy embedded wallet template](https://docs.monad.xyz/templates/next-serwist-privy-embedded-wallet.md)\n- [How to use the Next.js PWA sponsored transactions template](https://docs.monad.xyz/templates/next-serwist-privy-smart-wallet.md)\n- [How to use the Next.js Serwist 0x Privy embedded wallet template](https://docs.monad.xyz/templates/next-serwist-0x-privy-embedded-wallet.md)\n- [How to use the Next.js Serwist Thirdweb embedded wallet template](https://docs.monad.xyz/templates/next-serwist-thirdweb.md)\n##### Farcaster Mini Apps\n- [Farcaster Mini Apps](https://docs.monad.xyz/templates/farcaster-miniapp/index.md)\n- [How to build a Farcaster Mini App](https://docs.monad.xyz/templates/farcaster-miniapp/getting-started.md)\n- [How to send notifications to users of the Farcaster Mini App](https://docs.monad.xyz/templates/farcaster-miniapp/sending-notifications.md)\n- [How to publish a Farcaster Mini App](https://docs.monad.xyz/templates/farcaster-miniapp/publishing-miniapp.md)\n- [How to generate user specific images in the Farcaster Mini App](https://docs.monad.xyz/templates/farcaster-miniapp/generating-custom-og-images.md)\n- [How to add haptics to a Farcaster Mini App](https://docs.monad.xyz/templates/farcaster-miniapp/haptics.md)\n### Resources\n- [Frequently Asked Questions](https://docs.monad.xyz/faq.md)\n- [Official Monad Links: Website, Discord, X, and Telegram](https://docs.monad.xyz/official-links.md): Verified official Monad links: website, Discord, X, Telegram, and block explorers MonadVision and Monadscan. Check here before you click or connect a wallet.\n- [Security](https://docs.monad.xyz/security.md): Report security vulnerabilities in Monad through the Cantina bug bounty program.\n### For AI Agents\n- [Current Facts for AI Agents](https://docs.monad.xyz/ai/current-facts.md): Canonical Monad network facts and source-of-truth links for AI agents.\n- [Monad Developer Docs - AI Index](https://docs.monad.xyz/ai/developers.md): Focused links for AI agents helping developers build, deploy, verify, or integrate applications on Monad.\n- [Monad JSON-RPC Docs - AI Index](https://docs.monad.xyz/ai/rpc.md): Focused links for AI agents answering Monad JSON-RPC, provider, websocket, and RPC behavior questions.\n- [Monad Node Operations Docs - AI Index](https://docs.monad.xyz/ai/node-ops.md): Focused links for AI agents helping operators run, upgrade, recover, or monitor Monad nodes.\n- [Monad Architecture Docs - AI Index](https://docs.monad.xyz/ai/architecture.md): Focused links for AI agents explaining Monad consensus, execution, realtime data, and architecture concepts.\n## Learn\n### Monad Architecture\n- [Monad Architecture](https://docs.monad.xyz/monad-arch/index.md)\n- [Transaction Lifecycle in Monad](https://docs.monad.xyz/monad-arch/transaction-lifecycle.md)\n#### Concepts\n- [Concepts](https://docs.monad.xyz/monad-arch/concepts/index.md)\n- [Asynchronous I/O](https://docs.monad.xyz/monad-arch/concepts/asynchronous-io.md)\n- [Pipelining](https://docs.monad.xyz/monad-arch/concepts/pipelining.md)\n#### Consensus\n- [Consensus](https://docs.monad.xyz/monad-arch/consensus/index.md)\n- [MonadBFT](https://docs.monad.xyz/monad-arch/consensus/monad-bft.md): MonadBFT - Fast, Responsive, Fork-Resistant, Streamlined Consensus\n- [RaptorCast](https://docs.monad.xyz/monad-arch/consensus/raptorcast.md): Multicast message delivery protocol used for block propagation\n- [Asynchronous Execution](https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution.md): Pipelined consensus-execution staging\n- [Block States](https://docs.monad.xyz/monad-arch/consensus/block-states.md): Block lifecycle\n- [Local Mempool](https://docs.monad.xyz/monad-arch/consensus/local-mempool.md): Mempool local to each node\n- [Statesync](https://docs.monad.xyz/monad-arch/consensus/statesync.md): Mechanism for synchronizing MonadDb state\n- [Blocksync](https://docs.monad.xyz/monad-arch/consensus/blocksync.md): Mechanism for synchronizing missing blocks\n- [Forkpoint](https://docs.monad.xyz/monad-arch/consensus/forkpoint.md): How a node persists consensus state and resumes from it on startup\n- [Peer Discovery](https://docs.monad.xyz/monad-arch/consensus/peer-discovery.md)\n- [Message Authentication](https://docs.monad.xyz/monad-arch/consensus/authentication.md)\n- [Transport Protocol Usage](https://docs.monad.xyz/monad-arch/consensus/transport-protocols.md): Overview of transport protocol usage for node communication\n- [Staking](https://docs.monad.xyz/monad-arch/consensus/staking.md): How Monad's staking system works\n#### Execution\n- [Execution](https://docs.monad.xyz/monad-arch/execution/index.md)\n- [Parallel Execution](https://docs.monad.xyz/monad-arch/execution/parallel-execution.md)\n- [MonadDb](https://docs.monad.xyz/monad-arch/execution/monaddb.md): High-performance database for storing blockchain data.\n- [JIT Compilation](https://docs.monad.xyz/monad-arch/execution/native-compilation.md): High-performance execution of EVM bytecode by compiling to machine code.\n#### Real-Time Data\n- [Real-time Data](https://docs.monad.xyz/monad-arch/realtime-data/index.md)\n- [Real-Time Data Sources](https://docs.monad.xyz/monad-arch/realtime-data/data-sources.md)\n- [Speculative Real-Time Data](https://docs.monad.xyz/monad-arch/realtime-data/spec-realtime.md)\n## Node Operations\n### Getting Started\n- [Node Operations](https://docs.monad.xyz/node-ops/index.md)\n- [Hardware Requirements](https://docs.monad.xyz/node-ops/hardware-requirements.md)\n- [Full Node Installation](https://docs.monad.xyz/node-ops/full-node-installation.md)\n- [Validator Installation](https://docs.monad.xyz/node-ops/validator-installation.md)\n### Operations\n- [General Operations](https://docs.monad.xyz/node-ops/general-operations.md)\n- [Announcements](https://docs.monad.xyz/node-ops/announcements.md)\n#### Upgrade Instructions\n- [Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/index.md)\n- [MIP-8 Activation and Page Storage Migration](https://docs.monad.xyz/node-ops/upgrade-instructions/page-storage-mip-8-migration.md)\n- [v0.16.4 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.16.4.md)\n- [v0.16.3 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.16.3.md)\n- [v0.16.2 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.16.2.md)\n- [v0.16.1 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.16.1.md)\n- [v0.16.0 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.16.0.md)\n- [v0.15.2 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.15.2.md)\n- [v0.15.1 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.15.1.md)\n- [v0.15.0 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.15.0.md)\n- [v0.14.5 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.14.5.md)\n- [v0.14.4 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.14.4.md)\n- [v0.14.3 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.14.3.md)\n- [v0.14.2 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.14.2.md)\n- [v0.14.1 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.14.1.md)\n- [v0.14.0 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.14.0.md)\n- [v0.13.1 Upgrade Instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.13.1.md)\n- [v0.13.0 (MONAD_NINE)](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.13.0.md)\n- [v0.12.7](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.12.7.md)\n- [Authenticated UDP Migration](https://docs.monad.xyz/node-ops/upgrade-instructions/auth-udp.md)\n- [Authenticated UDP Checking](https://docs.monad.xyz/node-ops/upgrade-instructions/authenticated-udp-checking.md)\n- [v0.12.6](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.12.6.md)\n- [v0.12.5 - `testnet` re-genesis](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.12.5-testnet-regenesis.md)\n- [v0.12.3](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.12.3.md)\n#### Recovering a Node\n- [Recovering a Node](https://docs.monad.xyz/node-ops/node-recovery/index.md)\n- [Soft Reset Instructions](https://docs.monad.xyz/node-ops/node-recovery/soft-reset.md)\n- [Hard Reset Instructions](https://docs.monad.xyz/node-ops/node-recovery/hard-reset.md)\n- [Full Replay](https://docs.monad.xyz/node-ops/node-recovery/full-replay.md)\n- [Node Migration (Promoting a Full Node to Validator)](https://docs.monad.xyz/node-ops/node-recovery/node-migration.md)\n### Advanced\n- [How Full Nodes Receive Blocks](https://docs.monad.xyz/node-ops/full-node-block-delivery.md)\n- [Execution Events and WebSocket Setup](https://docs.monad.xyz/node-ops/events-and-websockets.md)\n#### Archive Data Setup\n- [Archive Data Setup](https://docs.monad.xyz/node-ops/archive-data/index.md)\n- [The Data Waterfall](https://docs.monad.xyz/node-ops/archive-data/data-waterfall.md)\n- [Running an Archive Server](https://docs.monad.xyz/node-ops/archive-data/running-an-archive-server.md)\n- [Configuring RPC to use archive data](https://docs.monad.xyz/node-ops/archive-data/configuring-rpc.md)\n- [Genesis Replay](https://docs.monad.xyz/node-ops/archive-data/genesis-replay.md): Re-execute historical blocks to reconstruct state\n### Validator Delegation Program\n- [Validator Delegation Program (VDP)](https://docs.monad.xyz/node-ops/validator-delegation-program/index.md)\n- [VDP Policy on MEV Systems](https://docs.monad.xyz/node-ops/validator-delegation-program/mev.md)\n### Solonet\n- [Solonet](https://docs.monad.xyz/node-ops/solonet.md): Run a complete Monad network locally in Docker for testing node operations and validator workflows.\n## OpenAPI Specs\n- [openapi](/api-reference/openapi.json)\n> The links below point to documentation indexes. Follow each `/_llms/` index recursively until you reach documentation pages.\n## Indexes\n- [Chinese (200 pages)](https://docs.monad.xyz/_llms/zh.md): Documentation for Chinese.\nThis documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform."}
{"url":"https://docs.jup.ag/user-docs/trade/predict","domain":"docs.jup.ag","title":"Prediction Markets - Jupiter Documentation","hash":"879690d0d3ea794f60d0a65b291416a747cbfb68273e10e8e42e583742ed2950","tokens":2596,"chars":10381,"crawler":"hive-genesis","verified":"exact","ts":1791112162256,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nJupiter Documentation home page\nPrediction Market\nPrediction Markets\nTrade on real-world events by buying YES or NO contracts on specific outcomes.\nWhat Is Jupiter Predict?\nJupiter Predict is a prediction market experience on Solana. It lets you trade on the outcome of real-world events by buying contracts for either side of a market: YES or NO .\nA winning contract is designed to pay $1 worth of the marketâs settlement asset . If the market resolves against your side, the contract expires worthless.\nJupiter brings prediction markets into the Jupiter trading experience. Markets may be sourced from external prediction market providers, Jupiter-supported market integrations, or short-duration crypto markets. Availability, liquidity, and settlement timing can differ by market.\nYou need a Solana wallet and a small amount of SOL for network fees. The order panel shows the supported funding token, expected contracts, fees, and settlement details before you sign.\nHow It Works\nMost markets on Jupiter Predict are binary. You pick a side, buy contracts at the current market price, and either hold until settlement or sell before trading closes.\nPrice Equals Implied Probability\nContract prices usually trade between $0.01 and $0.99 and reflect the marketâs view of how likely an outcome is. A YES contract priced at $0.70 means traders are currently paying about 70 cents for the YES side. The corresponding NO side is usually priced near $0.30. A persistent Price (Âą) / Decimal (x) selector on Browse, Event, and Degen pages can switch the display to a decimal odds-style multiplier instead of cents.\nThese prices are not guarantees. They move with supply, demand, liquidity, and new information.\nProfit and Loss\nYour profit depends on what you paid, whether your side wins, and any fees paid when entering or exiting.\nExample: Buying YES\nYou buy 10 YES contracts at $0.30 each. You spend $3 before fees.\n- If the market resolves to YES: each contract pays $1. You receive $10. Profit before fees: $7.\n- If the market resolves to NO: your contracts expire worthless. You lose the $3 you spent.\nExample: Buying NO\nYou buy 10 NO contracts at $0.40 each. You spend $4 before fees.\n- If the market resolves to NO: each contract pays $1. You receive $10. Profit before fees: $6.\n- If the market resolves to YES: your contracts expire worthless. You lose the $4 you spent.\nYou do not have to wait for settlement. If the market is still open and there is enough liquidity, you can sell your contracts at the current bid price. Some market types, such as special markets on sporting events, cannot be sold and must be held to resolution.\nBrowse, Degen, and Arcade\nJupiter Predict has three main trading surfaces.\nBrowse\nEvents across categories like sports, crypto, politics, economics, culture, finance, and more. Each market includes a rules summary that explains how the result is expected to be determined. While a clan competition is open, the Trending feed opens with a banner showing the weekly clan prize pool, split between cash and Gacha packs, with Find a clan and View leaderboard links (see Clans ).\nDegen\nShort-duration crypto markets where you predict whether a tokenâs price will move Up or Down over a fixed window. Available assets, windows, and limits can change. Use the filters in the app for the current set of live markets.\nArcade\nContinuous one-minute BTC and SOL Up or Down rounds, settled from a shared prize pool rather than an order book, with a fixed 1% fee on winnings.\nCategories\nBrowse markets are organised into categories. The available list can change as new markets are added or removed.\nCategory Examples\nSports Championship winners, match results, MVP awards, Formula 1 race winners\nCrypto Token price targets, network milestones\nPolitics Election outcomes, nominations, policy decisions\nEsports Tournament winners, match outcomes\nCulture Awards, entertainment, public figures\nEconomics Interest rate decisions, macro indicators\nTech Product launches, company milestones\nFinance Stock movements, commodity prices\nWeather Temperature, climate events\nMentions Predictions on what public figures or media will say\nYou can also filter by Live to see markets currently trading, or use search to find a specific event. Events can be sorted by volume, and seasonal filters (such as World Cup ) can appear during major events.\nOrder Types\nJupiter Predict currently uses market orders as the main live order type.\n- Market order : attempts to execute at the best available price when you place the trade. If the price or liquidity changes before execution, the order may fail or fill with fewer contracts than expected.\n- Limit order : lets you choose a target price and wait for a match. Available on Polymarket-sourced markets only, and only as limit buys (limit sells are disabled).\nA Limit tab may appear on markets that do not support limit orders (Jupiter Forecast and sports ticket markets); it is disabled there. See Order Behaviour by Market Source .\nFees\nFees are shown in the order quote before you sign. They are charged only on executed trades (buying or selling contracts), in whichever mint is used to purchase the contracts, and are always rounded up to the nearest cent. There are no fees when claiming payouts.\nFor Browse markets sourced from Polymarket, the trading fee has two components: where Polymarket charges a fee, Jupiter charges an additional fee equal to the Polymarket fee. The total trading fee is twice the Polymarket fee. The fee size depends on the contract price, the number of contracts, and how uncertain the outcome is. See Fee Structure for the full breakdown and examples.\nOther routes, such as Degen markets, may use a different route and fee structure. Arcade rounds charge a fixed 1% fee on winnings only. Solana network fees and account rent are separate on-chain costs paid in SOL.\nIf an order does not execute, trading fees are not charged. Any unused funds are returned automatically.\nSettlement and Payouts\nWhen a market closes, trading stops. The result is determined according to the marketâs rules. Some market routes record eligible results on-chain, while other integrations may settle through their own route and reflect the status in Profile.\nThe settlement flow usually works like this:\n- The market reaches its close time and trading stops.\n- The marketâs source or integration determines the result from the published rules.\n- The result is recorded on-chain or reflected through the relevant integration.\n- Profile updates with claimable, refundable, automatic, lost, or final status.\n- If Profile shows an action, follow the prompt. Some outcomes are processed automatically.\n- Losing positions expire worthless. No action is needed.\nA market can be resolved by its source before it appears as settled on Jupiter. This is expected while the result is being picked up, recorded, or reflected in Profile.\nSome markets can resolve to a refund or draw outcome depending on the rules. In those cases, eligible refunds are processed on-chain and reflected in Profile. Profile shows the refund status and any available action once settlement status is available.\nAdditional Features\nFor You\nA personalised feed of recommended events based on your activity.\nLeaderboard\nPublic ranking of traders by PnL, Volume, or Win Rate. Filterable by All Time, Weekly, or Monthly.\nProfile\nView your positions, open orders, trade history, claims, and refunds, with a period filter to narrow the view.\nBookmarks\nSave events with the bookmark icon on any event card, and revisit them in your bookmarked list.\nComments\nEach event page has a comment section where you can post, reply, like, and delete comments. External links are blocked in comments (only HTTPS links to jup.ag are accepted); still treat any instructions or offers in comments with caution.\nActivity\nA public live feed across all prediction markets, in the Browse and Degen side panels and at jup.ag/prediction/activity. The Trades tab shows the market, side, price, and amount of each trade. The Large bets tab lists the largest bets of $2,000 or more, newest first and anonymously (event, market, size, side, fill price, and age); Follow takes the same side at the current price, in one tap with Quick Buy on or through the buy form otherwise. Bets on markets that are no longer open show Closed instead.\nRisks\nPrediction markets carry real financial risk. Read the points below carefully before trading.\n- You can lose your entire position. If the outcome goes against your prediction, your contracts expire worthless.\n- Prices reflect current market demand, not certainty. Markets can be wrong, illiquid, or slow to react to new information.\n- Liquidity varies. Some markets may have wide spreads or low depth, which can make it hard to buy or sell at the displayed price.\n- Sells execute at the bid. Closing a position usually returns less than the displayed mid price because of the spread.\n- Settlement depends on market rules and integrations. Some market routes record results on-chain. Other integrations may settle through their own process.\n- Settlement is not instant. There can be a delay between market close, source resolution, final status updates, and claim or refund availability.\n- Token and stablecoin risks apply. Trades and payouts use dollar-pegged assets, which can carry issuer, liquidity, and depeg risk.\n- Regulatory restrictions apply. Prediction markets may be restricted or regulated in your jurisdiction. Trading is unavailable in some regions, including the United States, South Korea, and Australia, and the Jupiter Mobile app restricts additional regions (including parts of the EU).\nWhat You Need\nSolana wallet\nA wallet such as Phantom or Solflare, connected to Jupiter.\nSupported funds\nThe order panel shows which token can be used for the selected market and route.\nA bit of SOL\nFor Solana transaction fees and account rent. Rent is recovered automatically when eligible accounts are closed.\nRelated Pages\n- Using Predict â Browse markets, open positions, manage trades, and claim payouts step by step\n- Predict FAQ â Frequently asked questions about Jupiter Prediction Markets\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.anchor-lang.com/docs/quickstart/solpg","domain":"www.anchor-lang.com","title":"Solana Playground","hash":"013bc094c0fee909176234cec698682fb23524e8c6f30b89af467efbf97fca20","tokens":1740,"chars":6957,"crawler":"hive-genesis","verified":"exact","ts":1791112163877,"text":"Anchor Docs\nGithub Discord Stack Exchange\nQuickstart\nSolana Playground\nLearn how to build your first Solana program using the Anchor framework directly in your browser.\nIn this section, we'll build, deploy, and test a simple Solana program using the\nAnchor framework. By the end, you'll have deployed your first program to the\nSolana blockchain!\nSolana Playground (Solpg) is a browser-based development environment that allows\nyou to quickly develop, deploy, and test Solana programs!\nGetting Started\nOpen a new tab in your web browser and navigate to https://beta.solpg.io/ .\nCreate Playground Wallet\nIf you're new to Solana Playground, the first step is to create your Playground\nWallet. This wallet will allow you to interact with the Solana network right\nfrom your browser.\nStep 1. Connect to Playground\nClick the \"Not connected\" button at the bottom left of the screen.\nStep 2. Create Your Wallet\nYou'll see an option to save your wallet's keypair. Optionally, save your\nwallet's keypair for backup and then click \"Continue\".\nYou should now see your wallet's address, SOL balance, and connected cluster\n(devnet by default) at the bottom of the window.\nYour Playground Wallet will be saved in your browser's local storage. Clearing\nyour browser cache will remove your saved wallet.\nSome definitions you may find helpful:\n- wallet address : a public key that serves as your unique identity on the\nSolana blockchain. Just like an email address is used to receive emails, your\nwallet address is used to receive SOL.\n- connection cluster : a network of Solana nodes (computers running Solana\nvalidator client). Devnet is the cluster for developer testing.\nGet Devnet SOL\nBefore we start building, we first need some devnet SOL.\nFrom a developer's perspective, SOL is required for two main use cases:\n- To create accounts on the network where we store data or deploy programs\n- To pay for transaction fees when we interact with the network\nBelow are two methods to fund your wallet with devnet SOL:\nOption 1: Using the Playground Terminal\nTo fund your Playground wallet with devnet SOL. In the Playground terminal, run:\nsolana airdrop 5\nOption 2: Using the Devnet Faucet\nIf the airdrop command doesn't work (due to rate limits or errors), you can use\nthe Web Faucet .\n- Enter your wallet address (found at the bottom of the Playground screen) and\nselect an amount\n- Click \"Confirm Airdrop\" to receive your devnet SOL\nCreate Anchor Project\nFirst, open https://beta.solpg.io in a new browser tab.\n-\nClick the \"Create a new project\" button on the left-side panel.\n-\nEnter a project name, select Anchor as the framework, then click the \"Create\"\nbutton.\nYou'll see a new project created with the program code in the src/lib.rs file.\nuse anchor_lang :: prelude ::* ;\n// This is your program's public key and it will update\n// automatically when you build the project.\ndeclare_id! ( \"11111111111111111111111111111111\" );\n#[program]\nmod hello_anchor {\nuse super ::* ;\npub fn initialize (ctx : Context < Initialize >, data : u64 ) -> Result <()> {\nctx . accounts . new_account . data = data;\nmsg! ( \"Changed data to: {}!\" , data); // Message will show up in the tx logs\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\n// We must specify the space in order to initialize an account.\n// First 8 bytes are default account discriminator,\n// next 8 bytes come from NewAccount.data being type u64.\n// (u64 = 64 bits unsigned integer = 8 bytes)\n#[account(init, payer = signer, space = 8 + 8)]\npub new_account : Account <' info , NewAccount >,\n#[account( mut )]\npub signer : Signer <' info >,\npub system_program : Program <' info , System >,\n}\n#[account]\npub struct NewAccount {\ndata : u64\n}\nBuild and Deploy Program\nTo build the program, simply run build in the terminal.\nbuild\nNotice that the address in declare_id!() has been updated. This is your\nprogram's on-chain address.\nOnce the program is built, run deploy in the terminal to deploy the program to\nthe network (devnet by default). To deploy a program, SOL must be allocated to\nthe on-chain account that stores the program.\nBefore deployment, ensure you have enough SOL. You can get devnet SOL by either\nrunning solana airdrop 5 in the Playground terminal or using the\nWeb Faucet .\ndeploy\nAlternatively, you can also use the Build and Deploy buttons on the\nleft-side panel.\nOnce the program is deployed, you can now invoke its instructions.\nTest Program\nIncluded with the starter code is a test file found in tests/anchor.test.ts .\nThis file demonstrates how to invoke the initialize instruction on the starter\nprogram from the client.\n// No imports needed: web3, anchor, pg and more are globally available\ndescribe ( \"Test\" , () => {\nit ( \"initialize\" , async () => {\n// Generate keypair for the new account\nconst newAccountKp = new web3. Keypair ();\n// Send transaction\nconst data = new BN ( 42 );\nconst txHash = await pg.program.methods\n. initialize (data)\n. accounts ({\nnewAccount: newAccountKp.publicKey,\nsigner: pg.wallet.publicKey,\nsystemProgram: web3.SystemProgram.programId,\n})\n. signers ([newAccountKp])\n. rpc ();\nconsole. log ( `Use 'solana confirm -v ${ txHash }' to see the logs` );\n// Confirm transaction\nawait pg.connection. confirmTransaction (txHash);\n// Fetch the created account\nconst newAccount = await pg.program.account.newAccount. fetch (\nnewAccountKp.publicKey,\n);\nconsole. log ( \"On-chain data is:\" , newAccount.data. toString ());\n// Check whether the data on-chain is equal to local 'data'\nassert (data. eq (newAccount.data));\n});\nTo run the test file once the program is deployed, run test in the terminal.\ntest\nYou should see an output indicating that the test passed successfully.\nYou can also use the Test button on the left-side panel.\nYou can then view the transaction logs by running the solana confirm -v\ncommand and specifying the transaction hash (signature) from the test output:\nsolana confirm -v [TxHash]\nFor example:\nsolana confirm -v 3TewJtiUz1EgtT88pLJHvKFzqrzDNuHVi8CfD2mWmHEBAaMfC5NAaHdmr19qQYfTiBace6XUmADvR4Qrhe8gH5uc\nAlternatively, you can view the transaction details on\nSolanaFM or\nSolana Explorer by searching for\nthe transaction signature (hash).\nReminder to update the cluster (network) connection on the Explorer you are\nusing to match Solana Playground. Solana Playground's default cluster is\ndevnet.\nClose Program\nLastly, the SOL allocated to the on-chain program can be fully recovered by\nclosing the program.\nYou can close a program by running the following command and specifying the\nprogram address found in declare_id!() :\nsolana program close [ProgramID]\nFor example:\nsolana program close 2VvQ11q8xrn5tkPNyeraRsPaATdiPx8weLAD8aD4dn2r\nCongratulations! You've just built and deployed your first Solana program using\nthe Anchor framework!\nPrevious\nQuickstart\nNext\nLocal Development\nOn this page\nGetting Started Create Playground Wallet Get Devnet SOL Create Anchor Project Build and Deploy Program Test Program Close Program\nEdit on GitHub"}
{"url":"https://docs.orca.so/liquidity/concepts/liquidity-ranges","domain":"docs.orca.so","title":"Narrow vs Wide Liquidity Ranges - Orca Documentation","hash":"ab6186f8b379f1bf5b88a8e5ddb8e4d3c7959e20e03868d8db6f3bef571c4409","tokens":2336,"chars":9341,"crawler":"crawler-v8wo","verified":"exact","ts":1791112163066,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nConcepts\nNarrow vs Wide Liquidity Ranges\nUnderstand how liquidity range width affects concentrated liquidity positions.\nConcentrated liquidity pools, or CLMMs, let liquidity providers allocate liquidity within selected price ranges.\nRange width affects how often a position may remain active, how concentrated the liquidity is, how sensitive the position is to price movement, and how much monitoring may be required.\nThis guide explains the trade-offs between narrower and wider liquidity ranges.\nThis guide is informational only and does not provide financial advice. Liquidity position outcomes depend on price movement, trading activity, fees, rewards, liquidity, slippage, transaction costs, and market conditions.\nWhat a liquidity range does\nWhen providing liquidity on Orca, you select two prices:\n- A lower bound , or Min Price\n- An upper bound , or Max Price\nYour liquidity is active only between those two prices. Swaps that use your liquidity while it is in range may generate fees for your position.\nIf the market price moves outside your selected range, your liquidity is out of range and does not earn swap fees until price moves back into range or you adjust the position.\nConcentrated liquidity lets you choose where liquidity is active. A narrower range concentrates liquidity across fewer prices, while a wider range spreads liquidity across more prices.\nNarrow ranges\nWhen selecting a range, narrower ranges may show higher estimated yield because liquidity is concentrated into a smaller portion of the price curve.\nIf trading occurs within that narrower range, the position may represent a larger share of active liquidity for that price area. However, smaller price movements can also push the position out of range.\nEstimated yield assumes the modeled position remains in range for the selected period. If price moves out of range, swap fee accrual stops while the position is out of range. Creating or adjusting positions can also involve transaction costs and changes in token composition.\nNarrower ranges may require more frequent monitoring because:\n- Price can move out of range more quickly\n- The position may stop earning swap fees while out of range\n- Token composition can change more quickly\n- Repositioning may involve transaction costs and slippage\nWhat happens when price leaves your range\nWhen price moves outside your selected range:\n- The position stops participating in swaps while out of range and does not earn swap fees.\n- Your liquidity becomes fully converted into one of the two tokens.\nFor example, in a SOL/USDC position:\n- If price moves above your range, the position becomes 100% USDC.\n- If price moves below your range, the position becomes 100% SOL.\nThis token composition change is part of concentrated liquidity mechanics. Impermanent loss, also known as divergence loss, may also occur when the relative prices of the deposited tokens change.\nSee Impermanent Loss for more detail.\nWhen narrower ranges may be relevant\nNarrower ranges may be more relevant when the paired assets tend to move closely together in price, or when a liquidity provider plans to monitor and adjust positions frequently.\nStablecoin pairs\nExample: USDC/USDT, where relative price movement may be more limited\nLiquid staking tokens\nExample: mSOL/SOL, where price may track the underlying asset more closely\nWrapped tokens\nWrapped versions of the same asset may have lower relative price divergence\nEven for correlated assets, price movement, liquidity, fees, and market conditions can change. A position can still move out of range.\nWider ranges\nWider ranges spread liquidity across more prices.\nThis may reduce the frequency with which a position moves out of range, but it also means liquidity is less concentrated around any specific price area.\nWider ranges may be relevant when:\n- The token pair is more volatile\n- The user wants less frequent range adjustment\n- The user wants the position to cover a broader range of price movement\n- The user is still learning how concentrated liquidity positions behave\nWider ranges are not risk-free. Position value, token composition, and fee accrual can still change as price moves.\nVolatility\nVolatility can affect both trading activity and range management.\nDuring periods of higher price movement:\n- Price may move out of a selected range more quickly\n- Token composition may change more quickly\n- Estimated yield may change\n- Slippage and execution conditions may change\n- Repositioning may involve additional transaction costs\nSome users may choose to review or adjust ranges during periods of higher volatility. Others may choose to leave positions unchanged or withdraw liquidity. Each approach has trade-offs.\nUsing Orcaâs price-history range presets\nOrca provides price-history range presets. These presets show the minimum range that would have remained in range over a prior period.\nPreset What it shows\n1 hour Minimum range needed over the last hour\n4 hours Minimum range needed over the last 4 hours\n24 hours Minimum range needed over the last day\n7 days Minimum range needed over the last week\nThese presets can help you review how much the selected pair moved during prior timeframes.\nFor example, if the 7-day preset produces a much wider range than the 24-hour preset, the pair experienced more price movement during the 7-day period than during the 24-hour period.\nPast market behaviour does not guarantee future outcomes. Historical range presets are informational and do not predict whether a selected range will remain active in the future.\nThe âtoken I want to ownâ issue\nSome users provide liquidity using a token they expect to increase in price because they want exposure to that token while earning fees.\nConcentrated liquidity does not behave the same way as simply holding tokens. When the price of one asset in a pair rises, the position may gradually convert some of that asset into the other token as swaps move through the range.\nIf the price keeps moving in one direction, the position may become fully one-sided outside the selected range.\nProviding liquidity can result in a different outcome than holding the deposited tokens. If one token appreciates significantly relative to the other, the LP position may hold less of the appreciating token than a wallet that simply held the tokens.\nSee Impermanent Loss for a full breakdown.\nWhy projected yield can be misleading\nProjected yield is based on assumptions and available data. It may assume that the position remains active within its range for the modeled period.\nIf price leaves the range, swap fee accrual stops while the position is out of range. This means a narrow range can show a high estimated yield even though the position may not remain in range for long.\nReview projected yield alongside range width, historical price movement, current liquidity, token volatility, expected monitoring frequency, and the possibility that the position may move out of range.\nRange width comparison\nArea Narrower range Wider range\nLiquidity concentration Higher concentration across fewer prices Lower concentration across more prices\nEstimated yield display May appear higher if modeled in range May appear lower because liquidity is spread wider\nRisk of moving out of range Higher for the same price movement Lower for the same price movement\nMonitoring required May require more frequent review May require less frequent review\nCommon use cases Correlated pairs or actively managed positions Volatile pairs, broader coverage, or less active management\nActive vs passive management\nSome liquidity providers monitor and adjust ranges frequently as prices move. Others use wider or full-range positions to reduce the need for frequent changes.\nWhen choosing a range, consider:\n- How often you plan to review the position\n- How volatile the token pair has been\n- Whether the assets are price-correlated\n- Whether you are comfortable holding either token if the position becomes one-sided\n- Transaction costs and slippage from adjusting positions\n- Whether the displayed estimated yield depends on assumptions about time in range\nKey takeaways\nBefore selecting a very narrow range, review:\n- How volatile the token pair is\n- Whether the assets tend to move together\n- How often the range may remain active\n- How often you plan to monitor the position\n- What happens if the position becomes fully one-sided\n- Whether estimated fees and rewards depend on the position staying in range\nThere is no single range width that is appropriate for all users or market conditions. Range selection involves trade-offs between liquidity concentration, time in range, token composition, fee accrual, transaction costs, and monitoring.\nNext Steps\nImpermanent Loss\nLearn how price divergence affects liquidity positions\nPosition Simulator\nReview estimated outcomes across different price scenarios\nLiquidity Position Concepts\nReview key concepts for liquidity positions\nCreate a Position\nLearn how to create a liquidity position on Orca\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ens.domains/dao/proposals/6.25","domain":"docs.ens.domains","title":"EP 6.25 | ENS Docs","hash":"863e95068c110e2a257347f580e567213f6aec7b29fae01f0402dc18b6a2326e","tokens":767,"chars":3066,"crawler":"crawler-v8wo","verified":"exact","ts":1791112164938,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\n[EP 6.25] [Social] Replace the Working Groups with the ENS Admin Panel\nBy limes.eth\nStatus Rejected\nDiscussion Thread Forum\nVotes Snapshot\nSummary\nThis proposal calls for winding down the Meta-Governance, Ecosystem, and Public Goods Working Groups at the end of Term 6 (Dec 31, 2025) and the creation of the ENS Admin Panel on Jan 1, 2026.\nMotivation\nThe purpose of Working Groups at their creation was to \" promote stability and encourage long-term thinking and planning. \"\nA casual observation of working groups would suggest we are missing the mark and actually detracting from the north star goal of being a universal naming standard, often bringing attention to internal politics rather than external objectives.\nWorking Groups are subject to two main problems:\n1. No incentive for hard truths\nWhen future funding depends on relationships, your incentives are to not hurt feelings. \"I'll support your proposal if you support mine\" becomes the norm. This prioritizes psychological safety over truth seeking, and without truth seeking, you get stuck with bad results.\n2. Inability to fire contributors\nWorking Groups can't curate who participates. Traditional organizations select their team and fire when needed while WGs are open by default, accumulating contributors based on availability rather than ability. The reality is bad contributors make good contributors leave.\nAn Admin Panel is needed to eliminate the subjective decision-making that Working Groups currently hold and shift DAO operations to a lean, administrative model that removes the perverse incentives outlined above.\nDetails\nWinding Down DAO Operations\nIf the social proposal passes, all Working Groups must return remaining funds to the DAO and transfer ownership of multisigs to the elected Admin Panel by December 31, 2025.\nAdmin Panel\nThe Admin Panel will consist of 1 Administrator and 4 Signers.\nThe Administrator will:\n- Execute transactions when necessary on stream.mg.wg.ens.eth\n- Pay KPKâs performance fees using investment yield.\n- Ensure all service providers and ENS Labs adhere to objective reporting requirements and provide a consolidated report.\n- Can provide space for a quarterly town hall where Service Providers and Labs can present.\n- Perform reasonable admin roles when necessary.\nThe Administrator will not :\n- Have a grants program\n- Have weekly calls\n- Do anything beyond the 5 points above\nHaving one designated Administrator creates clear accountability and a direct point of responsibility. For security, this Administrator will be supported by 4 elected multisig Signers whose sole duty is to review and approve transactions within a reasonable time frame. If this proposal passes, the DAO would hold two separate social votes: one to elect the Administrator and one to elect the four Signers.\nCompensation (To be distributed via stream of USDC from DAO):\n- Administrator (1 spot): 120k USDC per year\n- Signer (4 spots): 12k USDC per year per signer"}
{"url":"https://aave.com/docs/aave-v4/liquidity/spokes","domain":"aave.com","title":"Aave Spokes | Aave Protocol Documentation","hash":"cec41a144d88efd7578fcc8ef61e75e35b3a4d1168156ac47a1400e0dd1efbfd","tokens":742,"chars":2967,"crawler":"hive-genesis","verified":"unchecked","ts":1791112165818,"text":"Docs\nSpokes # Copy\nLearn how to discover available spokes in Aave v4.\nSpoke Data Structure # Copy\nSpoke data provide information about individual borrowing modules, including:\n-\nIdentification: id, name, address, chain\n-\nConfiguration: active status and module settings\n-\nLiquidation parameters: target health factor, max-bonus threshold, and bonus factor ( liquidationConfig )\n-\nSummary metrics: supplied, borrowed, cap usage, connected hubs, and connected assets\n- TypeScript\n- GraphQL\n- Solidity\nThe following TypeScript interfaces illustrate the core Spoke type:\ninterface Spoke { __typename : \"Spoke\" ; id : SpokeId ; name : string ; address : EvmAddress ; chain : Chain ; liquidationConfig : SpokeLiquidationConfig | null ; summary : SpokeSummary ; connectedHubs : SpokeConnectedHub [ ] ; }\nListing Available Spokes # Copy\nDiscover all available Aave Spokes across supported networks.\n- React\n- TypeScript\n- GraphQL\n- Solidity\nUse the useSpokes hook to fetch a list of available spokes.\nimport { type SpokesRequest , useSpokes } from \"@aave/react\" ;\nfunction SpokesList ( { request } : { request : SpokesRequest } ) { const { data , loading , error } = useSpokes ( request ) ;\nif ( loading ) return < div > Loading⊠;\nif ( error ) return < div > Error: { error . message } ;\nreturn ( < div > { data . map ( ( spoke ) => ( < div key = { spoke . id } > < h3 > { spoke . name } < p > Chain: { spoke . chain . name } ) ) } ) ; }\nSee below for examples of SpokesRequest objects.\nimport { chainId } from \"@aave/react\" ;\nconst request : SpokesRequest = { query : { chainIds : [ chainId ( 1 ) ] , } , } ;\nFetching a Single Spoke # Copy\nFetch a specific spoke by its address and chain ID.\n- React\n- TypeScript\n- GraphQL\nUse the useSpoke hook to fetch a specific spoke.\nimport { type SpokeRequest , useSpoke } from \"@aave/react\" ;\nfunction SpokeDetails ( { request } : { request : SpokeRequest } ) { const { data , loading , error } = useSpoke ( request ) ;\nif ( loading ) return < div > Loading⊠;\nif ( error ) return < div > Error: { error . message } ;\nif ( ! data ) return < div > Spoke not found ;\nreturn ( < div > < h3 > { data . name } < p > Chain: { data . chain . name } ) ; }\nSee below for examples of SpokeRequest objects.\nimport { spokeId } from \"@aave/react\" ;\nconst request : SpokeRequest = { query : { spokeId : spokeId ( params . id ) , // SpokeId - typically from URL params } , } ;\nSpoke Summary History # Copy\nFetch historical deposits and borrows for a specific spoke over a chosen time window.\n- React\n- TypeScript\n- GraphQL\nUse the useSpokeSummaryHistory hook to fetch spoke-level history.\nimport { Currency , TimeWindow , useSpokeSummaryHistory } from \"@aave/react\" ;\nconst { data , loading , error } = useSpokeSummaryHistory ( { query : { spokeId } , currency : Currency . Usd , window : TimeWindow . LastWeek , } ) ;\nPrevious\nHubs\nNext\nReserves"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/account-abstraction","domain":"docs.openzeppelin.com","title":"Account Abstraction | OpenZeppelin Docs","hash":"948f76b79afc1c3838f387983fdac3a3fee3fd0e3e57abbc4f5b97f6937cd3e3","tokens":1519,"chars":6073,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112166705,"text":"Home Forum Website Impact\nOpenZeppelin Contracts\nAccount Abstraction\nOpen in Claude\nUnlike Externally Owned Accounts (EOAs), smart contracts may contain arbitrary verification logic based on authentication mechanisms different from Ethereumâs native ECDSA and have execution advantages such as batching or gas sponsorship. To leverage these properties of smart contracts, the community has widely adopted ERC-4337 , a standard to process user operations through an alternative mempool.\nThe library provides multiple contracts for Account Abstraction following this standard as it enables more flexible and user-friendly interactions with applications. Account Abstraction use cases include wallets in novel contexts (e.g. embedded wallets), more granular configuration of accounts, and recovery mechanisms.\nERC-4337 Overview\nThe ERC-4337 is a detailed specification of how to implement the necessary logic to handle operations without making changes to the protocol level (i.e. the rules of the blockchain itself). This specification defines the following components:\nUserOperation\nA UserOperation is a higher-layer pseudo-transaction object that represents the intent of the account. This shares some similarities with regular EVM transactions like the concept of gasFees or callData but includes fields that enable new capabilities.\nstruct PackedUserOperation {\naddress sender;\nuint256 nonce;\nbytes initCode; // concatenation of factory address and factoryData (or empty)\nbytes callData;\nbytes32 accountGasLimits; // concatenation of verificationGasLimit (16 bytes) and callGasLimit (16 bytes)\nuint256 preVerificationGas;\nbytes32 gasFees; // concatenation of maxPriorityFeePerGas (16 bytes) and maxFeePerGas (16 bytes)\nbytes paymasterAndData; // concatenation of paymaster fields (or empty)\nbytes signature;\n}\nThis process of bundling user operations involves several costs that the bundler must cover, including base transaction fees, calldata serialization, entrypoint execution, and paymaster context costs. To compensate for these expenses, bundlers use the preVerificationGas and gasFees fields to charge users appropriately.\nEstimating preVerificationGas is not standardized as it varies based on factors like calldata size, signature complexity, and bundler-specific serialization costs.\nUse ERC4337Utils to manipulate the UserOperation struct and other ERC-4337 related values.\nEntrypoint\nEach UserOperation is executed through a contract known as the EntryPoint . This contract is a singleton deployed across multiple networks at the same address although other custom implementations may be used.\nThe Entrypoint contract is considered a trusted entity by the account.\nBundlers\nThe bundler is a piece of offchain infrastructure that is in charge of processing an alternative mempool of user operations. Bundlers themselves call the Entrypoint contractâs handleOps function with an array of UserOperations that are executed and included in a block.\nDuring the process, the bundler pays for the gas of executing the transaction and gets refunded during the execution phase of the Entrypoint contract.\nfunction handleOps (\nPackedUserOperation [] calldata ops ,\naddress payable beneficiary\n) external { ... }\nAccount Contract\nThe Account Contract is a smart contract that implements the logic required to validate a UserOperation in the context of ERC-4337. Any smart contract account should conform with the IAccount interface to validate operations.\ninterface IAccount {\nfunction validateUserOp ( PackedUserOperation calldata , bytes32 , uint256 ) external returns ( uint256 validationData );\n}\nSimilarly, an Account should have a way to execute these operations by either handling arbitrary calldata on its fallback or implementing the IAccountExecute interface:\ninterface IAccountExecute {\nfunction executeUserOp ( PackedUserOperation calldata userOp , bytes32 userOpHash ) external ;\n}\nThe IAccountExecute interface is optional. Developers might want to use ERC-7821 for a minimal batched execution interface or rely on ERC-7579 or any other execution logic.\nTo build your own account, see accounts .\nFactory Contract\nThe smart contract accounts are created by a Factory contract defined by the Account developer. This factory receives arbitrary bytes as initData and returns an address where the logic of the account is deployed.\nTo build your own factory, see account factories .\nPaymaster Contract\nA Paymaster is an optional entity that can sponsor gas fees for Accounts, or allow them to pay for those fees in ERC-20 instead of native currency. This abstracts gas away from the user experience in the same way that computational costs of cloud servers are abstracted away from end-users.\nTo build your own paymaster, see paymasters .\nFurther notes\nERC-7562 Validation Rules\nTo process a bundle of UserOperations , bundlers call validateUserOp on each operation sender to check whether the operation can be executed. However, the bundler has no guarantee that the state of the blockchain will remain the same after the validation phase. To overcome this problem, ERC-7562 proposes a set of limitations to EVM code so that bundlers (or node operators) are protected from unexpected state changes.\nThese rules outline the requirements for operations to be processed by the canonical mempool.\nAccounts can access their own storage during the validation phase, they might easily violate ERC-7562 storage access rules in indirect ways. For example, most accounts access their public keys from storage when validating a signature, limiting the ability of having accounts that validate operations for other accounts (e.g. via ERC-1271 )\nAlthough any Account that breaks such rules may still be processed by a private bundler, developers should keep in mind the centralization tradeoffs of relying on private infrastructure instead of permissionless execution.\nAccess Control\nPrevious Page\nOverview\nNext Page\nOn this page\nERC-4337 Overview UserOperation Entrypoint Bundlers Account Contract Factory Contract Paymaster Contract Further notes ERC-7562 Validation Rules"}
{"url":"https://docs.jup.ag/user-docs/trade/spot/fees","domain":"docs.jup.ag","title":"Jupiter Spot Fees - Jupiter Documentation","hash":"abf554b31a94425c4df865a4a022a95031b0e2cd8c52d54606656fc147e657fa","tokens":1230,"chars":4920,"crawler":"hive-genesis","verified":"unchecked","ts":1791112167551,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nJupiter Documentation home page\nSpot\nJupiter Spot Fees\nFee structure for trading on Jupiter Spot â network fees, Jito tips, Jupiter commission, and gasless trading.\nWhen trading on Jupiter Spot you may pay up to three types of fees, depending on the product and execution mode. By default, Spot uses Jupiter Ultra to execute trades.\nFee structure\nSolana network fees\nSmall fees required to submit and process your transaction on the Solana blockchain. These are not charged by Jupiter and are paid regardless of whether your trade succeeds. In Ultra Mode, Jupiter dynamically sets this fee for you.\nJito tip\nA fee paid to validators when using MEV-protect or Jito-only transaction broadcasting. This applies in Manual Mode when Jito is selected as a broadcasting option. See Manual Mode for details.\nJupiter commission\nA fee charged by Jupiter on certain products. The rate depends on the product and, for Ultra Mode, on the token pair.\nProduct Fee Details\nUltra Mode 0â0.5% Varies by pair and volatility. More stable pairs tend toward the lower end; more volatile pairs (e.g. newly launched tokens) toward the higher end. See Ultra Mode â Fees .\nManual Mode (Market Swap) 0% No Jupiter commission on manual swaps.\nLimit Orders (V1) 0.1% flat See Limit Orders â Fees .\nLimit Orders (V2) 0.03â0.1% base + Ultra routing fee (0â0.5%) See Limit Orders â Fees .\nDCA orders (V1, formerly Recurring) 0.1% flat See DCA Orders â Fees .\nDCA orders (V2) 0.03â0.1% base + Ultra routing fee (0â0.5%) See DCA Orders â Fees .\nFees are included in the quote shown before you confirm. The swap form starts with a compact rate summary: expand it to see the fee breakdown, the network fee, and open the route dialog showing the full swap path and venue splits. Manual swaps do not incur any Jupiter commission â you only pay Solana network fees and, if applicable, Jito tips.\nSwaps placed natively in the Jupiter Mobile app follow a separate Mobile fee schedule. See Jupiter Mobile fees .\nGasless trading fees\nGasless trading is activated when your wallet does not have enough SOL to cover transaction fees (signature fees, priority fees, and rent). In this case, a relayer submits the transaction on your behalf and covers the SOL cost.\nThe swap fee is increased by the USD value of the SOL the relayer pays on your behalf, converted into an equivalent amount in the token you are trading. Gasless itself carries no additional fee.\nKey details:\n- The increase equals the gas paid; Jupiter does not add a margin for gasless.\n- The gas cost is a fixed amount , not proportional to trade size. This means the percentage impact is smaller on larger trades and larger on smaller trades.\n- Gasless is only available when the recovered gas stays within 10% of the trade . This sets a minimum trade size (about $10, adjusted with network fees); smaller trades are not eligible. Gasless also requires less than 0.01 SOL in the wallet and a verified sell-side token.\n- The gas recovery comes on top of the standard swap fee; both are included in the quote.\n- This does not apply to swaps routed through JupiterZ , where the market maker covers the gas at no additional cost to you.\nGasless trading is designed primarily for onboarding situations, for example when you create a new wallet and transfer USDC but donât yet hold SOL. For the best execution, using SOL for gas is recommended when possible.\nUltra mode vs manual mode\nSpot offers two execution modes:\nSetting Ultra mode (default) Manual mode (Trade Presets)\nSlippage Automatically optimized Set by user\nPriority fee Automatically optimized Set by user\nTip Automatically optimized Set by user\nMEV protection Enabled by default Depends on configuration\nWhat are priority fees and tips?\nPriority fee â An additional fee (in SOL) paid to Solana validators. Higher priority fees increase the likelihood that your transaction is included in the next block, which matters during periods of network congestion. Tip â An optional incentive (in SOL) paid to the transaction executor (a searcher or relayer) to prioritize your transactionâs execution. Tips are separate from priority fees and are used to compete for faster inclusion when multiple transactions target similar opportunities. In Ultra mode, both values are set automatically based on current network conditions. In manual mode, you control them directly.\nSetting slippage tolerance too high in manual mode can result in unfavorable execution prices. Setting it too low can cause transactions to fail. If you are unsure, use Ultra mode â it adjusts these parameters automatically.\nRisks and Limitations\nUnderstand the risks of trading on Spot.\nToken Page\nAll the data available when you open a token.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ens.domains/dao/proposals/6.51","domain":"docs.ens.domains","title":"undefined | ENS Docs","hash":"bbfbeabcd9f444742372bc88b4a3aef8dbbfea2d17f71db17972a6a6a795f74a","tokens":1786,"chars":7142,"crawler":"crawler-v8wo","verified":"exact","ts":1791112168456,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\n[EP 6.51] SPP3: Cohort Recommendation\nBy coltron.eth\nStatus Active\nDiscussion Thread Forum\nVotes Snapshot , Anticapture\nSummary\nThe committee recommends a four-provider SPP3 cohort totaling $1,690,000 of the ~$3.25M available under the ratified budget. The remaining is not allocated by this proposal.\nThe committee received 26 applications requesting a combined $12.2M. Each qualifying application was evaluated by every member unless recused, and a structured interview was conducted with each qualifying team.\nOne application was disqualified at the eligibility gate, the remaining 25 were scored against the published rubric. Five were initially selected with one (EthID) declining the offer\nThis proposal names the final four selected providers, states the rationale for each, publishes the committee's assessment, and explains in aggregate why the other applicants were not funded.\nPer the ratified proposal, this recommendation will be submitted as an on-chain executable. If this proposal passes, streams will begin in accordance with the Award Notices pending the selected providers pass the KYC checkpoint.\nCohort Scores\nProvider Category Award Application\nNamespace 1, 2 $500,000 Link\nGoldsky 1 $450,000 Link\nUnruggable 1, 2 $400,000 Link\nFluidkey 1, 2 $340,000 Link\nTotal $1,690,000\n*sovereignsignal.eth recused from the Namespace evaluation and vote under the program's conflict of interest rules.\nThe Cohort\nThe initial cohort presented included five selectees. The application from EthID was withdrawn. The remaining four will continue unaffected.\nNamespace: $500,000 ( Application )\nNamespace is a third-cycle provider and one of the ecosystem's primary subname infrastructure teams: SDKs, APIs, CCIP gateways, and custom deployments including Celo, Filecoin, and Rootstock. Their SPP2 subname issuance exceeded target by more than an order of magnitude, though the committee notes that figure is concentrated in a small number of large deployments. The SPP3 scope covers the ENSv2 migration of their onchain subname stack, continued maintenance of existing tooling, and business development. The award reflects the counterfactual: no comparable subname infrastructure exists at this scale, and the ENSv2 transition makes that infrastructure work time-critical. Key milestones depend on ENSv2 shipping to mainnet; the committee has accounted for this in the negotiated milestone structure.\n*sovereignsignal.eth recused from the Namespace evaluation and vote under the program's conflict of interest rules.\nGoldsky: $450,000 ( Application )\nGoldsky, with eRPC, is funded to operate ENS indexing as a dedicated public service. The award reflects the expanded scope presented as Option B in their application, which the team confirmed at the committee's request before selection. Indexing is a shared dependency consumed across the ecosystem, and it has previously been funded as one component inside larger provider scopes. The committee's judgment is that a dependency of this weight is best held as a standalone mandate: one accountable owner, priced on its own merits, and decoupled from any broader award. Goldsky is new to the SPP and was evaluated accordingly. The team operates production indexing infrastructure across the EVM ecosystem at scale, and selection was conditioned on their explicit commitment to the full scope.\nUnruggable: $400,000 ( Application )\nUnruggable is a returning SPP2 provider whose gateway infrastructure powers cross-chain resolution in production, including base.eth and ENSIP-19 reverse resolution. The SPP3 scope continues gateway operation and extends into developer tooling and interoperability R&D. The committee funded the full ask on the strength of shipped, verifiable protocol infrastructure that ENS depends on today, and a delivery record with no abandoned commitments.\nFluidkey: $340,000 ( Application )\nFluidkey is funded to build privacy-preserving ENS infrastructure: an ENSIP, wallet-agnostic contracts, and a resolver kit designed to be maintained independently of Fluidkey's own product. This is the smallest award in the cohort and the committee treats it as a deliberate position on an underdeveloped capability. The proposal cleanly separates the public-goods layer from the company's commercial product, budgets an audit, and self-funds its own reference integration. The registration upside is less proven than elsewhere in the cohort; the cost is priced accordingly.\nCommittee Assessment\nScores are the mean of individual Member scores against the published rubric. Weights: Prior Delivery 25%, Scope Clarity 15%, Milestone Structure 15%, Adoption/Revenue/Utility 40%. The 5% discretionary component is excluded from the weighted figure, which is therefore out of 4.75. The Chair scored every application independently but Chair scores enter the mean only in the case of Namespace which saw a recusal, noted below. Individual scoring records remain internal working documents, available to the accountability body or ENS Foundation on request per the ratified proposal.\nProvider C1 Prior Delivery C2 Scope Clarity C3 Milestones C4 Adoption/Revenue Weighted\nNamespace 4.1 3.4 3.3 3.5 3.43\nGoldsky 4.0 3.8 3.4 3.3 3.37\nUnruggable 4.5 3.4 3.1 3.0 3.30\nFluidkey 4.0 4.0 3.8 2.4 3.11\n*sovereignsignal.eth recused from the Namespace evaluation under the conflict of interest rules. The Chair's independent scores stand in for the recused seat on this row, keeping four scoring inputs.\nWhy Applications Were Not Funded\nThis section removed to fit character limit. See full post here .\nProcess\nThis section removed to fit character limit. See full post here .\nNext Steps\n- Award Notices have been issued to each selected provider for review; they will be finalized by the ENS Foundation\n- The executable proposal is scheduled for posting on Wednesday, July 8th.\n- Streams will turn on after successful completion of KYC and signing of Award Notices by both the selected providers and the Foundation.\nSpecification\nThe attached payload includes five transactions that facilitate the provider and committee streams, and four transactions to pay the committee as defined in [6.42] [Social] SPP3: Program Authorization and Committee Model . Source: Github .\nNine transactions, all run by the timelock:\n- USDC.approve(USDCx, 517,500e6) - lets the USDCx contract pull the USDC we are about to wrap.\n- USDCx.upgrade(517,500e18) - wrap it. 517,500 is one month of the stream ($267,500) plus the pod margin ($250,000).\n- USDCx.transfer(pod, 250,000e18) - send the margin to the pod. It carries the pod through the overlap until the switch.\n- CFAv1Forwarder.setFlowrate(USDCx, pod, 101720934415475068) - set the master stream to $3.21M/yr.\n- USDC.approve(autowrapper, 4,547,500e6) - refresh the autowrap allowance (~17 months, the ratio SPP2 used).\n- USDC.transfer(coltron) - committee chair 9k USDC\n- USDC.transfer(sovereignsignal) - committee member 7k USDC.\n- USDC.transfer(austingriffith) - committee member 7k USDC.\n- USDC.transfer(abdullah) - committee member 7k USDC."}
{"url":"https://bitcoinops.org/en/newsletters/2025/08/22/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #368 | Bitcoin Optech","hash":"23b115d4f14dc9fc41516ccafcc2b1e2dc042c41300abaf592cf91459fbe84b7","tokens":2359,"chars":9433,"crawler":"hive-genesis","verified":"exact","ts":1791112169492,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #368\nAug 22, 2025\nThis weekâs newsletter summarizes a draft BIP for block template sharing\nbetween full nodes and announces a library that allows trusted\ndelegation of script evaluation (including for features not available in\nBitcoinâs native scripting languages). Also included are our regular\nsections describing recent updates to services and client software,\nannouncing new releases and release candidates, and summarizing notable\nchanges to popular Bitcoin infrastructure software.\nNews\n-\nâ Draft BIP for block template sharing: Anthony Towns posted to the Bitcoin-Dev mailing list the draft\nof a BIP for how nodes can communicate to their peers the transactions\nthey would attempt to mine in their next block (see Newsletter\n#366 ). This allows the node to share\ntransactions it will accept via its mempool and mining policy that its\npeers might normally reject by their own policy, allowing those peers\nto cache those transactions in case they are mined (which improves\ncompact block relay effectiveness). The\ntransactions in a nodeâs block template are usually the most\nprofitable unconfirmed transactions known to that node, so peers that\npreviously rejected those transactions for policy reasons might also\nfind them worthy of additional consideration.\nThe protocol specified in the draft BIP is simple. Shortly after a\nconnection with a peer is initiated, the node sends a sendtemplate\nmessage indicating to the peer that it is willing to send block\ntemplates. At any later time, the peer can request a template with a\ngettemplate message. In response to the request, the node replies\nwith a template message that contains a list of short transaction\nidentifiers using the same format as a BIP152 compact block\nmessage. The peer can then request any transactions it wants by\nincluding the short identifier in a sendtransactions message (also\nas in BIP152). The draft BIP allows templates to be up to slightly\nmore than twice the size of the current maximum block weight limit.\nA Delving Bitcoin thread about template sharing saw\nadditional discussion this week about how to improve the bandwidth\nefficiency of the proposal. Ideas discussed included only sending\nonly the difference since the previous template (an\nestimated 90% bandwidth savings), using a set reconciliation protocol such as that enabled by minisketch (allowing much larger templates to be shared efficiently),\nand using Golomb-Rice encoding on the templates\nsimilar to compact block filters (an\nestimated 25% efficiency).\n-\nâ Trusted delegation of script evaluation: Josh Doman posted to Delving Bitcoin about a library heâs written that uses a\ntrusted execution environment ( TEE ) that will only sign a\ntaproot keypath spend if the transaction containing\nthat spend satisfies a script. The script can contain opcodes that\nare not currently active on Bitcoin today or a completely different\nform of script (e.g. Simplicity or bll ).\nThis approach requires those receiving funds to the script to trust\nthe TEEâboth that it will still be available to sign in the future\nand that it will only sign a spend that satisfies its encumbrance\nscriptâbut it allows rapid experimentation with proposed new\nfeatures for Bitcoin with actual monetary value. To reduce trust in\nthe TEE remaining available, a backup spend path can be included; for\nexample, a timelocked path that allows a participant\nto unilaterally spend their funds a year after entrusting them to the\nTEE.\nThe library is designed for use with the Amazon Web Services (AWS)\nNitro enclave.\nChanges to services and client software\nIn this monthly feature, we highlight interesting updates to Bitcoin\nwallets and services.\n-\nâ ZEUS v0.11.3 released:\nThe v0.11.3 release includes improvements to peer\nmanagement, BOLT12 , and submarine swap\nfeatures.\n-\nâ Rust Utreexo resources:\nAbdelhamid Bakhta posted Rust-based resources for\nUtreexo , including interactive educational\nmaterials and WASM bindings .\n-\nâ Peer-observer tooling and call to action:\n0xB10C posted about the motivation, architecture, code,\nsupporting libraries, and findings of his peer-observer project. He seeks to build âA loose, decentralized group of people who\nshare the interest of monitoring the Bitcoin Network. A collective to enable\nsharing of ideas, discussion, data, tools, insights, and more.â\n-\nâ Bitcoin Core Kernel-based node announced:\nBitcoin backbone was announced as a demonstration of using\nthe Bitcoin Core Kernel library as the foundation of a Bitcoin node.\n-\nâ SimplicityHL released:\nSimplicityHL is a Rust-like programming language that\ncompiles to the lower-level Simplicity language recently\nactivated on Liquid. For further reading, see the related\nDelving thread .\n-\nâ LSP plugin for BTCPay Server:\nThe LSP plugin implements client-side features of\nBLIP51 , the specification for inbound channels, into BTCPay Server.\n-\nâ Proto mining hardware and software announced:\nProto announced new Bitcoin mining hardware and open source\nmining software, built with previous community feedback .\n-\nâ Oracle resolution demo using CSFS:\nAbdelhamid Bakhta posted a demonstration of an oracle using\nCSFS , nostr, and MutinyNet to sign an\nattestation of an eventâs outcome.\n-\nâ Relai adds taproot support:\nRelai added support for sending to taproot addresses.\nReleases and release candidates\nNew releases and release candidates for popular Bitcoin infrastructure\nprojects. Please consider upgrading to new releases or helping to test\nrelease candidates.\n-\nâ LND v0.19.3-beta is a release for a maintenance\nversion for this popular LN node implementation containing âimportant\nbug fixesâ. Most notably, âan optional migration [âŠ] lowers disk\nand memory requirements for nodes significantly.â\n-\nâ Bitcoin Core 29.1rc1 is a release candidate for a maintenance\nversion of the predominant full node software.\n-\nâ Core Lightning v25.09rc2 is a release candidate for a new major\nversion of this popular LN node implementation.\nNotable code and documentation changes\nNotable recent changes in Bitcoin Core , Core\nLightning , Eclair , LDK ,\nLND , libsecp256k1 , Hardware Wallet\nInterface (HWI) , Rust Bitcoin , BTCPay\nServer , BDK , Bitcoin Improvement\nProposals (BIPs) , Lightning BOLTs ,\nLightning BLIPs , Bitcoin Inquisition , and BINANAs .\n-\nâ Bitcoin Core #32896 introduces support for creating and spending\nunconfirmed Topologically Restricted Until Confirmation ( TRUC ) transactions by adding a version parameter to the\nfollowing RPCs: createrawtransaction , createpsbt , send , sendall , and\nwalletcreatefundedpsbt . The wallet enforces the TRUC transaction\nrestrictions for weight limit, sibling conflict, and incompatibility between\nunconfirmed TRUC and non-TRUC transactions.\n-\nâ Bitcoin Core #33106 lowers the default blockmintxfee to 1 sat/kvB (the\nminimum possible), and the default minrelaytxfee and incrementalrelayfee to 100 sat/kvB (0.1\nsat/vB). While these values can be configured, users are advised to adjust the\nminrelaytxfee and incrementalrelayfee values together. Other minimum\nfeerates remain unchanged, but the default wallet minimum feerates are\nexpected to be lowered in a future version. The motivations for this change\nrange from considerable growth in the number of blocks mined with sub 1 sat/vB\ntransactions and the number of pools mining these transactions to an increase\nin the Bitcoin exchange rate.\n-\nâ Core Lightning #8467 extends xpay (see Newsletter #330 )\nby adding support for paying BIP353 Human Readable Names (HRN) (e.g.\nsatoshi@bitcoin.com) and enabling it to pay BOLT12 offers\ndirectly, removing the need to run the fetchinvoice command first. Under the\nhood, xpay fetches the payment instructions using the fetchbip353 RPC\ncommand from the cln-bip353 plugin introduced in Core Lightning #8362 .\n-\nâ Core Lightning #8354 starts publishing pay_part_start and pay_part_end\nevent notifications for the status of specific payment parts sent with\nMPP . The pay_part_end notification indicates the\nduration of the payment and whether it was successful or failed. If the\npayment fails, an error message is provided and, if the error onion isnât\ncorrupted, additional information on the failure is given, such as the source\nof the error and the failure code.\n-\nâ Eclair #3103 introduces support for simple taproot channels , leveraging MuSig2 scriptless\nmultisignature signing to reduce transaction weight\nconsumption by 15% and improve transaction privacy. Funding transactions and\ncooperative closures are indistinguishable from other P2TR\ntransactions. This PR also includes support for dual funding and splicing in simple taproot channels, and\nenables channel commitment upgrades to\nthe new taproot format during a splice transaction.\n-\nâ Eclair #3134 replaces the penalty weight multiplier for stuck\nHTLCs with the CLTV expiry delta when\nscoring HTLC endorsement peer reputation (see\nNewsletter #363 ), to better reflect how long a stuck\nHTLC will tie up liquidity. To mitigate the outsized penalty of stuck HTLCs\nwith a maximum CLTV expiry delta, this PR adjusts the reputation decay\nparameter ( half-life ) from 15 to 30 days and the stuck payment threshold\n( max-relay-duration ) from 12 seconds to 5 minutes.\n-\nâ LDK #3897 extends its peer storage implementation by\ndetecting lost channel state during backup retrieval, by deserializing the\npeerâs copy and comparing it to the local state."}
{"url":"https://wormhole.com/docs/products/token-transfers/native-token-transfers/guides/post-deployment/","domain":"wormhole.com","title":"Native Token Transfers Post Deployment | Wormhole Docs","hash":"6ee5b3502a369bc002363aab3a89e2e7dad2862cd476a9da53db34c17f881676","tokens":810,"chars":3238,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112170219,"text":"Skip to content\nInitializing search\n- Transfer Ownership\n- Configuration\n- Concepts\n- FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Portal Bridge\n- Connect\n- Guides\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Settlement\n- FAQs\n- Reference\n- Messaging\n- Interact with Core Contracts\n- Query NTT Data and Transfers\n- Concepts\n- Tutorials\n- Reference\n- Protocol\n- Infrastructure Guides\n- Developer Tools\n- Wormhole CLI\n- Wormholescan Explorer\n- Wormholescan API\n- Reference\n- AI Resources\nPage Actions\nEdit this page\nNTT Post-Deployment Steps ïŒ\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nTo offer the best user experience and ensure the most robust deployment, Wormhole contributors recommend the following after you have deployed Native Token Transfers (NTT):\n- Implement a robust testing plan for your multichain token before launching.\n- Ensure comprehensive, documented security measures are followed for custody of contract ownership, control of keys, and access control roles. Check the NTT configuration for more details on ownership and rate limits.\n- Use the NTT CLI to perform cross-chain token transfers against your deployed configuration for validation and operational testing.\n- Consider a streamlined, customizable frontend such as Connect for an optimized user experience.\n- Alternatively, the Wormhole TypeScript SDK allows for a direct integration into your infrastructure.\n- Ensure ecosystem actors such as block explorers, automated security tools (such as BlockAid and Blowfish), and wallets (such as MetaMask, Backpack, and Phantom) are aware of your multichain deployment and that it is labeled appropriately.\n- Monitor and maintain your multichain deployment.\nPost-Deployment Settings ïŒ\nThe following table outlines post-deployment settings available on the NTT Manager contract. These allow you to update roles, pause activity, and adjust transfer limitsâuseful for upgrades, incident response, or protocol tuning after initial deployment.\nSetting Effect\npause Pauses the manager.\nunpause Unpauses the manager.\nsetOwner Changes the manager owner.\nsetPauser Changes the pauser role.\nsetOutboundLimit Sets outbound transfer limit.\nsetInboundLimit Sets inbound transfer limit (per chain).\nsetTransceiverPauser Changes pauser for a transceiver.\nNext Steps ïŒ\n-\nTransfer Ownership\nLearn how to move ownership of your NTT deployment to a new owner address on EVM, Solana, and Sui with step-by-step instructions.\nFollow the Transfer Ownership guide\n-\nWormhole NTT Connect Demo\nTest a transfer or deployment quickly with a standalone Connect implementation with automatic NTT deployment configuration.\nExplore the NTT Connect demo\n-\nWormhole NTT TypeScript SDK Demo\nReference an example project that uses the Wormhole TypeScript SDK to facilitate token transfers between different blockchain networks after deploying the NTT framework.\nExplore the NTT TypeScript SDK demo\n-\nQuery NTT Token and Transfer Data\nLearn how to explore NTT by querying token metadata and transfer activity using the Wormholescan API in a TypeScript project.\nTry the NTT Token and Transfers Guide\nLast update: September 28, 2026\n| Created: September 28, 2026"}
{"url":"https://developers.skyeco.com/guides/sky/token-governance-upgrade/key-info/","domain":"developers.skyeco.com","title":"Key Information | Sky Protocol Docs","hash":"7da64e994613cc6932b511bf08d976cf9e57ffc139008ceaf964ebbc1ea3ec02","tokens":1011,"chars":4042,"crawler":"hive-genesis","verified":"unchecked","ts":1791112171046,"text":"Skip to content\nSky Protocol Docs\nGitHub\nSelect theme\nKey Information\nPortals\nSection titled âPortalsâ\nMakerDAO Voting Portal\nSection titled âMakerDAO Voting Portalâ\nvote.makerdao.com\nOnly available to withdraw MKR from your current delegate contract and Chief V2.\nSky Voting Portal\nSection titled âSky Voting Portalâ\nvote.sky.money\nLive for SKY holdersâ votes in Chief V3.\nSky Portal\nSection titled âSky Portalâ\nsky.money\nConvert MKR to SKY. Upgrade Seal Engine rewards and borrowing positions and earn rewards. Functionality of the portal may vary by jurisdiction.\nContract Addresses\nSection titled âContract Addressesâ\nTokens\nSection titled âTokensâ\nSKY Token\nSection titled âSKY Tokenâ\n- Address: 0x56072C95FAA701256059aa122697B133aDEd9279\n- Codebase: https://github.com/sky-ecosystem/sky\nMKR-SKY One Way Converter V2\nSection titled âMKR-SKY One Way Converter V2â\n- Address: 0xA1Ea1bA18E88C381C724a75F23a130420C403f9a\nChronicle SKY USD Price Feed\nSection titled âChronicle SKY USD Price Feedâ\n- Address: 0xc2ffbbDCCF1466Eb8968a846179191cb881eCdff\nSKY USD Price Feed with Delay\nSection titled âSKY USD Price Feed with Delayâ\n- Address: 0x511485bBd96e7e3a056a8D1b84C5071071C52D6F\nMKR Token\nSection titled âMKR Tokenâ\n- Address: 0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2\n- Codebase: https://github.com/sky-ecosystem/ds-token\nStaked SKY Token (lssky)\nSection titled âStaked SKY Token (lssky)â\n- Address: 0xf9A9cfD3229E985B91F99Bc866d42938044FFa1C\nGovernance Contracts\nSection titled âGovernance Contractsâ\nChief\nSection titled âChiefâ\nChief V3 (SKY)\nSection titled âChief V3 (SKY)â\n- Address: 0x929d9A1435662357F54AdcF64DcEE4d6b867a6f9\n- Codebase: https://github.com/sky-ecosystem/chief\nChief V2 (MKR)\nSection titled âChief V2 (MKR)â\n- Address: 0x0a3f6849f78076aefadf113f5bed87720274ddc0\n- Codebase: https://github.com/sky-ecosystem/ds-chief\nChief V1 (Single Collateral Dai & Multi Collateral Dai, 2017)\nSection titled âChief V1 (Single Collateral Dai & Multi Collateral Dai, 2017)â\n- Address: 0x8E2a84D6adE1E7ffFEe039A35EF5F19F13057152\n- Codebase: https://github.com/sky-ecosystem/ds-chief/tree/a06b5e426a30e1471b93093857760b85e2fcb93a\nVote Delegate\nSection titled âVote Delegateâ\nVote Delegate V3 (supports SKY + Chief V3)\nSection titled âVote Delegate V3 (supports SKY + Chief V3)â\n- Address: 0x4Cf3DaeFA2683Cd18df00f7AFF5169C00a9EccD5\n- Codebase: https://github.com/sky-ecosystem/vote-delegate/tree/v3\nVote Delegate V2 (supports MKR + Chief V2. Used by Seal Engine V1)\nSection titled âVote Delegate V2 (supports MKR + Chief V2. Used by Seal Engine V1)â\n- Address: 0xc3d809e87a2c9da4f6d98fecea9135d834d6f5a0\n- Codebase: https://github.com/sky-ecosystem/vote-delegate/tree/25b63b079ea6ef3ba875a983ddc4265971b867d3\nVote Delegate V1 (supports MKR + Chief V2)\nSection titled âVote Delegate V1 (supports MKR + Chief V2)â\n- Address: 0xd897f108670903d1d6070fcf818f9db3615af272\n- Codebase: https://github.com/sky-ecosystem/vote-delegate/tree/v1\nStaking Engine\nSection titled âStaking Engineâ\nStaking Engine (supports Chief V3 SKY )\nSection titled âStaking Engine (supports Chief V3 SKY )â\n- Address: 0xCe01C90dE7FD1bcFa39e237FE6D8D9F569e8A6a3\n- Codebase: https://github.com/sky-ecosystem/lockstake/tree/v2\nSKY USDS Rewards (Staking Engine)\nSection titled âSKY USDS Rewards (Staking Engine)â\n- Address: 0x38E4254bD82ED5Ee97CD1C4278FAae748d998865\nStaking Engine Debt Position Migrator\nSection titled âStaking Engine Debt Position Migratorâ\n- Address: 0x473d777f608C3C24B441AB6bD4bBcA6b7F9AF90B\nClipper\nSection titled âClipperâ\n- Address: 0x35526314F18FeB5b7F124e40D6A99d64F7D7e89a\nClipperCalc\nSection titled âClipperCalcâ\n- Address: 0xB8f8c7caabFa320717E3e848948450e120F0D9BB\nSeal Engine V1 (supports Chief V2 MKR)\nSection titled âSeal Engine V1 (supports Chief V2 MKR)â\n- Address: 0x2b16C07D5fD5cC701a0a871eae2aad6DA5fc8f12\n- Codebase: https://github.com/sky-ecosystem/lockstake/tree/602edbb682feb04af5fc1723ea427576286b8291\nReleased into the public domain (CC0 1.0 Universal) â trademarks remain with their owners; no warranty. See full license ."}
{"url":"https://docs.berachain.com/general/tokens/bera","domain":"docs.berachain.com","title":"BERA Token - Berachain","hash":"4cb5781ef52ac44b9d40c4741852b34ce37385ec57b756465c785eb1ee3b337f","tokens":778,"chars":3112,"crawler":"hive-genesis","verified":"unchecked","ts":1791112172882,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBerachain home page\nGeneral\nBEX\nBend\nBuild\nNodes\nTokens\nBERA Token\nGas token, staking, tokenomics, and how to get BERA.\nBERA serves as the native gas and staking token of Berachain, the first blockchain powered by Proof-of-Liquidity.\nRole of BERA\nBERA is both the gas token and the PoL emission token (as WBERA):\nTransaction fees\nBERA pays for transactions on Berachain. Fees are burned, reducing circulating supply. Explore the Berachain Ecosystem .\nPoL emissions\nBlock rewards are emitted as $WBERA (wrapped BERA, 1:1). Each block emits a base rate (0.4 WBERA) to the validator operator and a reward rate (1.305 WBERA) routed through BeraChef to Reward Vaults. WBERA is the single emission token for Proof of Liquidity.\nValidator staking\nValidators stake BERA to enter the active set (top 69 by stake). Block-production probability is proportional to staked BERA. Additional stakers can deposit BERA to a validator directly via BeaconDeposit.deposit() or through a Staking Pool via submit() .\nStake BERA for sWBERA\nDepositing BERA or WBERA into the Staking Vault yields $sWBERA, which earns yield from the Incentive Auction .\nSee Block Rewards for how BERA staking affects block production and emissions.\nTokenomics\nThe following documents the fixed supply, allocation, and release schedule for BERA.\nOverview\nProperty Value\nToken name BERA\nTotal supply at genesis 500,000,000 BERA\nInflation ~5% annually via PoL reward emissions (distributed as WBERA), subject to governance\nDecimals 18\nDistribution and allocation\nThe genesis supply of 500,000,000 BERA is allocated as follows:\nInitial core contributors â 84,000,000 (16.8%)\nAllocated to advisors and members of Big Bera Labs, the core contributors to the Berachain blockchain.\nInvestors â 171,500,000 (34.3%)\nAllocated to Seed, Series A, and Series B investors.\nCommunity allocations â 244,500,000 (48.9%)\nAirdrop â 79,000,000 (15.8%)\nDistributed to testnet users, Berachain and ecosystem NFT holders, social supporters, ecosystem dApps, and community builders. See the Blog airdrop overview for details.\nFuture community initiatives â 65,500,000 (13.1%)\nReserved for incentive programs, grants, and other initiatives, with community input via Snapshots, RFPs, and similar mechanisms.\nEcosystem & R&D â 100,000,000 (20%)\nUsed for ecosystem development, R&D, growth, and Berachain Foundation operations: developer programs ( Boyco ), node operator delegations, and Proof-of-Liquidity evolution. At launch, 9.5% of total BERA supply from this bucket is unlocked for ecosystem growth, developer tooling, liquidity provisioning, and related uses.\nToken release schedule\nAll allocated parties share the same vesting terms:\n- Cliff: 1 year; no tokens unlock before the cliff.\n- Initial unlock: After the cliff, 1/6 of the allocated amount unlocks.\n- Linear vesting: The remaining 5/6 vests linearly over the following 24 months.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://gov.optimism.io/c/88-category/88","domain":"gov.optimism.io","title":"Proposals đ - Optimism Collective","hash":"a1c4b1252ef01e8b63a953f301e5e0e6fb367bab58a2d7315e2879318f1f8542","tokens":811,"chars":3244,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112172240,"text":"Optimism Collective\nProposals đ\nProtocol Upgrade\nReflection Period Proposal\nFoundation Budgets\nTechnical Proposals\nDiscuss non-grant related structural, or technical, governance proposals.\nTopic\nReplies\nViews\nActivity\nAbout the Proposals đ category\nProposals đ\n0\n69\nJanuary 6, 2026\nRe-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\nProposals đ\n12\n1297\nSeptember 27, 2026\nUpgrade 20 - Super Root Dispute Games & OPCM v8.0.0\nProtocol Upgrade\n2\n277\nSeptember 16, 2026\nAn Optimism Governance / Ecosystem Grant Proposal\nProposals đ\n0\n51\nSeptember 6, 2026\nMaintenance Upgrade Proposal: Unichain ProxyAdmin Owner Transition to Standard Optimism Governance\nProposals đ\n0\n55\nSeptember 2, 2026\nMaintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit\nProposals đ\n0\n53\nSeptember 2, 2026\nMaintenance Upgrade Proposal: Update Soneium Fee Vaults Recipient\nProposals đ\n1\n117\nAugust 23, 2026\nCollective Year 4 Budget Update and Year 5 Budget Outlook\nFoundation Budgets\n2\n437\nAugust 7, 2026\nMaintenance Upgrade Proposal: Ink Mainnet Fee Vault Config Update and Proposer Rotation\nProposals đ\n0\n97\nJuly 22, 2026\nMaintenance Upgrade: Swell Ownership Transfer to AltLayer\nProposals đ\n1\n112\nJuly 21, 2026\nOptimism Security Council Operating Budget for Seasons 10 and 11\nProposals đ\n8\n227\nJuly 18, 2026\nSequencer ETH Management: 12-Month Renewal and Treasury Optimization\nProposals đ\n1\n238\nJuly 15, 2026\nOperating Manual Update Proposal\nProposals đ\n1\n128\nJuly 15, 2026\nCouncil Dissolution Proposal: Dissolve the Grants Council\nProposals đ\n5\n279\nJuly 15, 2026\nCouncil Dissolution Proposal: Dissolve the Developer Advisory Board\nProposals đ\n1\n132\nJuly 15, 2026\nCouncil Dissolution Proposal: Dissolve the Milestones and Metrics Council\nProposals đ\n1\n140\nJuly 15, 2026\nUpgrade 19b â Karst Hardfork\nTechnical Proposals\n3\n284\nJune 18, 2026\n[Research] Post-Quantum Cryptography (PQC) Latency Benchmarks on OP Stack Architecture\nTechnical Proposals\n6\n152\nJune 15, 2026\nUpgrade Proposal: Stake-Based Priority Ordering Experiment\nProtocol Upgrade\n1\n274\nApril 17, 2026\nMaintanance Upgrade Proposal 18a: Arena-Z Chain Servicer Migration\nTechnical Proposals\nseason-9\n0\n185\nMarch 13, 2026\nUpgrade 18 - Custom Gas Token v2 and Kona Proofs\nProposals đ\n2\n318\nJanuary 29, 2026\nProposal to Align the OP Token with Superchain Success\nProposals đ\nseason-9\n35\n4222\nJanuary 28, 2026\nProposal to integrate \"Quantum Optimism: Building the Clean Internet with Aurora, Atlas & 445 Qubits\"\nProposals đ\n0\n55\nJanuary 13, 2026\nUpgrade 17 - Jovian Hardfork and Fusaka Readiness\nTechnical Proposals\n3\n933\nJanuary 1, 2026\nIntegrating LUXBIN: Quantum-Classical Hybrid Cryptography for Optimism's Future\nTechnical Proposals\n0\n56\nDecember 18, 2025\nDisclosing two fault proof system vulnerabilities\nTechnical Proposals\n0\n222\nDecember 4, 2025\n[deprecated] Upgrade 17 Proposal: Jovian Hardfork\nTechnical Proposals\n2\n329\nNovember 7, 2025\nGovernor Upgrade Proposal: Onchain Controls MVP\nTechnical Proposals\n0\n202\nOctober 30, 2025\nAn update to OP Labs recommendation for signing OPCM upgrade transactions\nTechnical Proposals\n1\n129\nOctober 29, 2025\nProposal Preview: Operator Fee\nTechnical Proposals\n1\n322\nSeptember 28, 2025\nnext page â"}
{"url":"https://developer.bitcoin.org/glossary.html","domain":"developer.bitcoin.org","title":"Glossary â Bitcoin","hash":"39d8db63c77f227a73a109f06420f569f28cf265f7733f06ba710d34306165db","tokens":7893,"chars":31569,"crawler":"hive-genesis","verified":"exact","ts":1791112174729,"text":"-\nBitcoin\n- Glossary\n« P2P Network\nTable Of Contents\n- Developer Guides\n- Block Chain\n- Transactions\n- Contracts\n- Wallets\n- Payment Processing\n- Operating Modes\n- P2P Network\n- Mining\n- Reference\n- Introduction\n- Block Chain\n- Transactions\n- Wallets\n- P2P Network\n- RPC API Reference\n- Examples\n- Introduction\n- Testing Applications\n- Transactions\n- Payment Processing\n- P2P Network\n- Glossary\nPrevious topic\nP2P Network\nContribute\nEdit Page\nGlossary ¶\n51 percent attack\nMajority attack\nThe ability of someone controlling a majority of network hash rate to revise transaction history and prevent new transactions from confirming.\nAddress\nA 20-byte hash formatted using base58check to produce either a P2PKH or P2SH Bitcoin address. Currently the most common way users exchange payment information.\nNot to be confused with: IP address\nBase58check\nThe method used in Bitcoin for converting 160-bit hashes into P2PKH and P2SH addresses. Also used in other parts of Bitcoin, such as encoding private keys for backup in WIP format. Not the same as other base58 implementations.\nNot to be confused with: P2PKH address, P2SH address, IP address\nBlock\nOne or more transactions prefaced by a block header and protected by proof of work. Blocks are the data stored on the block chain.\nBlock chain\nBest block chain\nA chain of blocks with each block referencing the block that preceded it. The most-difficult-to-recreate chain is the best block chain.\nNot to be confused with: Header chain\nBlock header\nHeader\nAn 80-byte header belonging to a single block which is hashed repeatedly to create proof of work.\nHeight\nBlock height\nThe number of blocks preceding a particular block on a block chain. For example, the genesis block has a height of zero because zero block preceded it.\nBlock reward\nThe amount that miners may claim as a reward for creating a block. Equal to the sum of the block subsidy (newly available satoshis) plus the transactions fees paid by transactions included in the block.\nNot to be confused with: Block subsidy, Transaction fees\nMaximum Block Size\nThe maximum size of a block according to the consensus rules. The current block size limit is 4 million weight units (1 million vbytes).\nNot to be confused with: Block, Blockchain, Blockchain size\nBlocks-first sync\nSynchronizing the block chain by downloading each block from a peer and then validating it.\nNot to be confused with: Headers-first sync\nBloom filter\nA filter used primarily by SPV clients to request only matching transactions and merkle blocks from full nodes.\nNot to be confused with: Bloom filter (general computer science term, of which Bitcoinâs bloom filters are a specific implementation)\nChain code\nIn HD wallets, 256 bits of entropy added to the public and private keys to help them generate secure child keys; the master chain code is usually derived from a seed along with the master private key\nChange address\nChange output\nAn output in a transaction which returns satoshis to the spender, thus preventing too much of the input value from going to transaction fees.\nNot to be confused with: Address reuse\nChild key\nChild public key\nChild private key\nIn HD wallets, a key derived from a parent key. The key can be either a private key or a public key, and the key derivation may also require a chain code.\nNot to be confused with: Public key (derived from a private key, not a parent key)\nCoinbase\nA special field used as the sole input for coinbase transactions. The coinbase allows claiming the block reward and provides up to 100 bytes for arbitrary data.\nNot to be confused with: Coinbase transaction, Coinbase.com\nCoinbase transaction\nGeneration transaction\nThe first transaction in a block. Always created by a miner, it includes a single coinbase.\nNot to be confused with: Coinbase (the unique part of a coinbase transaction)\nCompactSize\nA type of variable-length integer commonly used in the Bitcoin P2P protocol and Bitcoin serialized data structures.\nNot to be confused with: VarInt (a data type Bitcoin Core uses for local data storage), Compact (the data type used for nBits in the block header)\nCompressed public key\nAn ECDSA public key that is 33 bytes long rather than the 65 bytes of an uncompressed public key.\nConfirmation score\nConfirmations\nConfirmed transaction\nUnconfirmed transaction\nA score indicating the number of blocks on the best block chain that would need to be modified to remove or modify a particular transaction. A confirmed transaction has a confirmation score of one or higher.\nConsensus\nWhen several nodes (usually most nodes on the network) all have the same blocks in their locally-validated best block chain.\nNot to be confused with: Social consensus (often used in discussion among developers to indicate that most people agree with a particular plan), Consensus rules (the rules that allow nodes to maintain consensus)\nConsensus rules\nThe block validation rules that full nodes follow to stay in consensus with other nodes.\nNot to be confused with: Consensus (what happens when nodes follow the same consensus rules)\nChild pays for parent\nCPFP\nAncestor mining\nSelecting transactions for mining not just based on their fees but also based on the fees of their ancestors (parents) and descendants (children).\nNot to be confused with: Replace by Fee, RBF\nDenomination\nBitcoins\nSatoshis\nDenominations of Bitcoin value, usually measured in fractions of a bitcoin but sometimes measured in multiples of a satoshi. One bitcoin equals 100,000,000 satoshis.\nNot to be confused with: Binary bits, a unit of data with two possible values\nDifficulty\nNetwork difficulty\nHow difficult it is to find a block relative to the difficulty of finding the easiest possible block. The easiest possible block has a proof-of-work difficulty of 1.\nNot to be confused with: Target threshold (the value from which difficulty is calculated)\nDNS seed\nA DNS server which returns IP addresses of full nodes on the Bitcoin network to assist in peer discovery.\nNot to be confused with: HD wallet seeds\nDouble spend\nA transaction that uses the same input as an already broadcast transaction. The attempt of duplication, deceit, or conversion, will be adjudicated when only one of the transactions is recorded in the blockchain.\nEscrow contract\nA transaction in which a spender and receiver place funds in a 2-of-2 (or other m-of-n) multisig output so that neither can spend the funds until theyâre both satisfied with some external outcome.\nExtended key\nPublic extended key\nPrivate extended key\nIn the context of HD wallets, a public key or private key extended with the chain code to allow them to derive child keys.\nFork\nWhen two or more blocks have the same block height, forking the block chain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack.\nNot to be confused with: Hard fork (a change in consensus rules that breaks security for nodes that donât upgrade), Soft fork (a change in consensus rules that weakens security for nodes that donât upgrade), Software fork (when one or more developers permanently develops a codebase separately from other developers), Git fork (when one or more developers temporarily develops a codebase separately from other developers)\nGenesis block\nBlock 0\nThe first block in the Bitcoin block chain.\nNot to be confused with: Generation transaction (the first transaction in a block)\nHard fork\nA permanent divergence in the block chain, commonly occurs when non-upgraded nodes canât validate blocks created by upgraded nodes that follow newer consensus rules.\nNot to be confused with: Fork (a regular fork where all nodes follow the same consensus rules, so the fork is resolved once one chain has more proof of work than another), Soft fork (a temporary divergence in the block chain caused by non-upgraded nodes not following new consensus rules), Software fork (when one or more developers permanently develops a codebase separately from other developers), Git fork (when one or more developers temporarily develops a codebase separately from other developers\nHardened extended key\nA variation on HD wallet extended keys where only the hardened extended private key can derive child keys. This prevents compromise of the chain code plus any private key from putting the whole wallet at risk.\nHD protocol\nHD wallet\nThe Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy. Wallets using the HD protocol are called HD wallets.\nHD wallet seed\nRoot seed\nA potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet.\nNot to be confused with: Mnemonic code / mnemonic seed (a binary root seed formatted as words to make it easier for humans to transcribe and possibly remember)\nHeader chain\nBest header chain\nA chain of block headers with each header linking to the header that preceded it; the most-difficult-to-recreate chain is the best header chain\nNot to be confused with: Block chain\nHeaders-first sync\nSynchronizing the block chain by downloading block headers before downloading the full blocks.\nNot to be confused with: Blocks-first sync (Downloading entire blocks immediately without first getting their headers)\nHigh-priority transaction\nFree transaction\nTransactions that donât have to pay a transaction fee because their inputs have been idle long enough to accumulated large amounts of priority. Note: miners choose whether to accept free transactions.\nInitial block download\nIBD\nThe process used by a new node (or long-offline node) to download a large number of blocks to catch up to the tip of the best block chain.\nNot to be confused with: Blocks-first sync (syncing includes getting any amount of blocks; IBD is only used for large numbers of blocks)\nInput\nTxIn\nAn input in a transaction which contains three fields: an outpoint, a signature script, and a sequence number. The outpoint references a previous output and the signature script allows spending it.\nInternal byte order\nThe standard order in which hash digests are displayed as stringsâthe same format used in serialized blocks and transactions.\nNot to be confused with: RPC byte order (where the byte order is reversed)\nInventory\nA data type identifier and a hash; used to identify transactions and blocks available for download through the Bitcoin P2P network.\nNot to be confused with: Inv message (one of the P2P messages that transmits inventories)\nLocktime\nnLockTime\nPart of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain.\nMainnet\nThe original and main network for Bitcoin transactions, where satoshis have real economic value.\nNot to be confused with: Testnet (an open network very similar to mainnet where satoshis have no value), Regtest (a private testing node similar to testnet)\nTransaction malleability\nTransaction mutability\nThe ability of someone to change (mutate) unconfirmed transactions without making them invalid, which changes the transactionâs txid, making child transactions invalid.\nNot to be confused with: BIP62 (a proposal for an optional new transaction version that reduces the set of known mutations for common transactions)\nMiner-activated soft fork\nMASF\nA Soft Fork activated by through miner signalling.\nNot to be confused with: User Activated Soft Fork (a soft fork activated by flag day or node enforcement instead of miner signalling.), Fork (a regular fork where all nodes follow the same consensus rules, so the fork is resolved once one chain has more proof of work than another), Hard fork (a permanent divergence in the block chain caused by non-upgraded nodes not following new consensus rules), Soft fork (a temporary divergence in the block chain caused by non-upgraded nodes not following new consensus rules), Software fork (when one or more developers permanently develops a codebase separately from other developers), Git fork (when one or more developers temporarily develops a codebase separately from other developers\nMaster chain code\nMaster private key\nIn HD wallets, the master chain code and master private key are the two pieces of data derived from the root seed.\nMerkle block\nA partial merkle tree connecting transactions matching a bloom filter to the merkle root of a block.\nNot to be confused with: MerkleBlock message (a P2P protocol message that transmits a merkle block)\nMerkle root\nThe root node of a merkle tree, a descendant of all the hashed pairs in the tree. Block headers must include a valid merkle root descended from all transactions in that block.\nNot to be confused with: Merkle tree (the tree of which the merkle root is the root node), Merkle block (a partial merkle branch connecting the root to one or more leaves [transactions])\nMerkle tree\nA tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root. In Bitcoin, the leaves are almost always transactions from a single block.\nNot to be confused with: Partial merkle branch (a branch connecting one or more leaves to the root), Merkle block (a partial merkle branch connecting one or more transactions from a single block to the block merkle root)\nMessage header\nThe four header fields prefixed to all messages on the Bitcoin P2P network.\nMinimum relay fee\nRelay fee\nThe minimum transaction fee a transaction must pay (if it isnât a high-priority transaction) for a full node to relay that transaction to other nodes. There is no one minimum relay feeâeach node chooses its own policy.\nNot to be confused with: Transaction fee (the minimum relay fee is a policy setting that filters out transactions with too-low transaction fees)\nMining\nMiner\nMining is the act of creating valid Bitcoin blocks, which requires demonstrating proof of work, and miners are devices that mine or people who own those devices.\nMultisig\nBare multisig\nA pubkey script that provides n number of pubkeys and requires the corresponding signature script provide m minimum number signatures corresponding to the provided pubkeys.\nNot to be confused with: P2SH multisig (a multisig script contained inside P2SH), Advanced scripts that require multiple signatures without using OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY\nnBits\nTarget\nThe target is the threshold below which a block header hash must be in order for the block to be valid, and nBits is the encoded form of the target threshold as it appears in the block header.\nNot to be confused with: Difficulty (a number measuring the difficulty of finding a header hash relative to the difficulty of finding a header hash with the easiest target)\nNode\nFull node\nArchival node\nPruned node\nPeer\nA computer that connects to the Bitcoin network.\nNot to be confused with: Lightweight node, SPV node\nNull data transaction\nOP_RETURN transaction\nData carrier transaction\nA transaction type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable pubkey script that full nodes donât have to store in their UTXO database.\nNot to be confused with: OP_RETURN (an opcode used in one of the outputs in an OP_RETURN transaction)\nOpcode\nData-pushing opcode\nNon-data-pushing opcode\nOperation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script.\nOrphan block\nBlocks whose parent block has not been processed by the local node, so they canât be fully validated yet.\nNot to be confused with: Stale block\nOutpoint\nThe data structure used to refer to a particular transaction output, consisting of a 32-byte TXID and a 4-byte output index number (vout).\nNot to be confused with: Output (an entire output from a transaction), TxOut (same as output)\nOutput\nTxOut\nAn output in a transaction which contains two fields: a value field for transferring zero or more satoshis and a pubkey script for indicating what conditions must be fulfilled for those satoshis to be further spent.\nNot to be confused with: Outpoint (a reference to a particular output)\nP2PKH address\nP2PKH output\nA Bitcoin payment address comprising a hashed public key, allowing the spender to create a standard pubkey script that Pays To PubKey Hash (P2PKH).\nNot to be confused with: P2PK output (an output paying a public key directly), P2SH address, P2SH output (an address comprising a hashed script, and its corresponding output)\nP2SH address\nP2SH output\nA Bitcoin payment address comprising a hashed script, allowing the spender to create a standard pubkey script that Pays To Script Hash (P2SH). The script can be almost any valid pubkey script.\nNot to be confused with: P2PK output (an output paying a public key directly), P2PKH address, P2PKH output (an address comprising a hashed pubkey, and its corresponding output), P2SH multisig (a particular instance of P2SH where the script uses a multisig opcode)\nP2SH multisig\nA P2SH output where the redeem script uses one of the multisig opcodes. Up until Bitcoin Core 0.10.0, P2SH multisig scripts were standard transactions, but most other P2SH scripts were not.\nNot to be confused with: Multisig pubkey scripts (also called âbare multisigâ, these multisig scripts donât use P2SH encapsulation), P2SH (general P2SH, of which P2SH multisig is a specific instance that was special cased up until Bitcoin Core 0.10.0)\nParent key\nParent public key\nParent private key\nIn HD wallets, a key used to derive child keys. The key can be either a private key or a public key, and the key derivation may also require a chain code.\nNot to be confused with: Public key (derived from a private key, not a parent key)\nPayment protocol\nPayment request\nThe deprecated protocol defined in BIP70 (and other BIPs) which lets spenders get signed payment details from receivers.\nNot to be confused with: IP-to-IP payment protocol (an insecure, discontinued protocol included in early versions of Bitcoin)\nPrivate key\nThe private portion of a keypair which can create signatures that other people can verify using the public key.\nNot to be confused with: Public key (data derived from the private key), Parent key (a key used to create child keys, not necessarily a private key)\nProof of work\nPOW\nA hash below a target value which can only be obtained, on average, by performing a certain amount of brute force workâtherefore demonstrating proof of work.\nPubkey script\nScriptPubKey\nA script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent. Data for fulfilling the conditions can be provided in a signature script. Pubkey Scripts are called a scriptPubKey in code.\nNot to be confused with: Pubkey (a public key, which can be used as part of a pubkey script but donât provide a programmable authentication mechanism), Signature script (a script that provides data to the pubkey script)\nPublic key\nThe public portion of a keypair which can be used to verify signatures made with the private portion of the keypair.\nNot to be confused with: Private key (data from which the public key is derived), Parent key (a key used to create child keys, not necessarily a public key)\nReplace by fee\nRBF\nOpt-in replace by fee\nReplacing one version of an unconfirmed transaction with a different version of the transaction that pays a higher transaction fee. May use BIP125 signaling.\nNot to be confused with: Child pays for parent, CPFP\nRedeem script\nRedeemScript\nA script similar in function to a pubkey script. One copy of it is hashed to create a P2SH address (used in an actual pubkey script) and another copy is placed in the spending signature script to enforce its conditions.\nNot to be confused with: Signature script (a script that provides data to the pubkey script, which includes the redeem script in a P2SH input)\nRegtest\nRegression test mode\nA local testing environment in which developers can almost instantly generate blocks on demand for testing events, and can create private satoshis with no real-world value.\nNot to be confused with: Testnet (a global testing environment which mostly mimics mainnet)\nRPC byte order\nA hash digest displayed with the byte order reversed; used in Bitcoin Core RPCs, many block explorers, and other software.\nNot to be confused with: Internal byte order (hash digests displayed in their typical order; used in serialized blocks and serialized transactions)\nSequence number\nPart of all transactions. A number intended to allow unconfirmed time-locked transactions to be updated before being finalized; not currently used except to disable locktime in a transaction\nNot to be confused with: Output index number / vout (this is the 0-indexed number of an output within a transaction used by a later transaction to refer to that specific output)\nSerialized block\nA complete block in its binary formatâthe same format used to calculate total block byte size; often represented using hexadecimal.\nSerialized transaction\nRaw transaction\nComplete transactions in their binary format; often represented using hexadecimal. Sometimes called raw format because of the various Bitcoin Core commands with ârawâ in their names.\nSIGHASH_ALL\nDefault signature hash type which signs the entire transaction except any signature scripts, preventing modification of the signed parts.\nSIGHASH_ANYONECANPAY\nA signature hash type which signs only the current input.\nNot to be confused with: SIGHASH_SINGLE (which signs this input, its corresponding output, and other inputs partially)\nSIGHASH_NONE\nSignature hash type which only signs the inputs, allowing anyone to change the outputs however theyâd like.\nSIGHASH_SINGLE\nSignature hash type that signs the output corresponding to this input (the one with the same index value), this input, and any other inputs partially. Allows modification of other outputs and the sequence number of other inputs.\nNot to be confused with: SIGHASH_ANYONECANPAY (a flag to signature hash types that only signs this single input)\nSignature\nA value related to a public key which could only have reasonably been created by someone who has the private key that created that public key. Used in Bitcoin to authorize spending satoshis previously sent to a public key.\nSignature hash\nSighash\nA flag to Bitcoin signatures that indicates what parts of the transaction the signature signs. (The default is SIGHASH_ALL.) The unsigned parts of the transaction may be modified.\nNot to be confused with: Signed hash (a hash of the data to be signed), Transaction malleability / transaction mutability (although non-default sighash flags do allow optional malleability, malleability comprises any way a transaction may be mutated)\nSignature script\nScriptSig\nData generated by a spender which is almost always used as variables to satisfy a pubkey script. Signature Scripts are called scriptSig in code.\nNot to be confused with: ECDSA signature (a signature, which can be used as part of a pubkey script in addition to other data)\nSPV\nSimplified Payment Verification\nLightweight client\nThin client\nA method for verifying if particular transactions are included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.\nSoft fork\nA softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.\nNot to be confused with: Fork (a regular fork where all nodes follow the same consensus rules, so the fork is resolved once one chain has more proof of work than another), Hard fork (a permanent divergence in the block chain caused by non-upgraded nodes not following new consensus rules), Software fork (when one or more developers permanently develops a codebase separately from other developers), Git fork (when one or more developers temporarily develops a codebase separately from other developers\nStale block\nBlocks which were successfully mined but which arenât included on the current best block chain, likely because some other block at the same height had its chain extended first.\nNot to be confused with: Orphan block (a block whose previous (parent) hash field points to an unknown block, meaning the orphan canât be validated)\nStandard Transaction\nA transaction that passes Bitcoin Coreâs IsStandard() and IsStandardTx() tests. Only standard transactions are mined or broadcast by peers running the default Bitcoin Core software.\nStart string\nNetwork magic\nFour defined bytes which start every message in the Bitcoin P2P protocol to allow seeking to the next message.\nTestnet\nA global testing environment in which developers can obtain and spend satoshis that have no real-world value on a network that is very similar to the Bitcoin mainnet.\nNot to be confused with: Regtest (a local testing environment where developers can control block generation)\nToken\nA token is a programmable digital asset with its own codebase that resides on an already existing block chain. Tokens are used to help facilitate the creation of decentralized applications.\nNot to be confused with: Bitcoins, Satoshis, Security token, Denominations\nTransaction fee\nMiners fee\nThe amount remaining when the value of all outputs in a transaction are subtracted from all inputs in a transaction; the fee is paid to the miner who includes that transaction in a block.\nNot to be confused with: Minimum relay fee (the lowest fee a transaction must pay to be accepted into the memory pool and relayed by Bitcoin Core nodes)\nTxid\nAn identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction.\nNot to be confused with: Outpoint (the combination of a txid with a vout used to identify a specific output)\nUser-activated soft fork\nUASF\nA Soft Fork activated by flag day or node enforcement instead of miner signalling.\nNot to be confused with: Miner Activated Soft Fork (a soft fork activated through miner signalling), Fork (a regular fork where all nodes follow the same consensus rules, so the fork is resolved once one chain has more proof of work than another), Hard fork (a permanent divergence in the block chain caused by non-upgraded nodes not following new consensus rules), Soft fork (a temporary divergence in the block chain caused by non-upgraded nodes not following new consensus rules), Software fork (when one or more developers permanently develops a codebase separately from other developers), Git fork (when one or more developers temporarily develops a codebase separately from other developers\nUTXO\nAn Unspent Transaction Output (UTXO) that can be spent as an input in a new transaction.\nNot to be confused with: Output (any output, whether spent or not. Outputs are a superset of UTXOs)\nWallet\nSoftware that stores private keys and monitors the block chain (sometimes as a client of a server that does the processing) to allow users to spend and receive satoshis.\nNot to be confused with: HD wallet (a protocol that allows all of a walletâs keys to be created from a single seed)\nWIF\nWallet Import Format\nA data interchange format designed to allow exporting and importing a single private key with a flag indicating whether or not it uses a compressed public key.\nNot to be confused with: Extended private keys (which allow importing a hierarchy of private keys)\nWatch-only address\nAn address or pubkey script stored in the wallet without the corresponding private key, allowing the wallet to watch for outputs but not spend them.\nBitcoin URI\nA URI which allows receivers to encode payment details so spenders donât have to manually enter addresses and other details.\nCertificate chain\nA chain of certificates connecting a individualâs leaf certificate to the certificate authorityâs root certificate.\nCoinbase block height\nThe current blockâs height encoded into the first bytes of the coinbase field.\nFiat\nNational currencies such as the dollar or euro.\nIntermediate certificate\nA intermediate certificate authority certificate which helps connect a leaf (receiver) certificate to a root certificate authority.\nKey index\nAn index number used in the HD wallet formula to generate child keys from a parent key.\nKey pair\nA private key and its derived public key.\nLabel\nThe label parameter of a bitcoin: URI which provides the spender with the receiverâs name (unauthenticated).\nLeaf certificate\nThe end-node in a certificate chain; in the payment protocol, it is the certificate belonging to the receiver of satoshis.\nMerge\nSpending, in the same transaction, multiple outputs which can be traced back to different previous spenders, leaking information about how many satoshis you control.\nMerge avoidance\nA strategy for selecting which outputs to spend that avoids merging outputs with different histories that could leak private information.\nMessage\nA parameter of bitcoin: URIs which allows the receiver to optionally specify a message to the spender.\nMicropayment channel\nterm-micropayment-channel (contracts-guide) ( original target )\nOP CHECKMULTISIG\nOpcode which returns true if one or more provided signatures (m) sign the correct parts of a transaction and match one or more provided public keys (n).\nOutput index\nThe sequentially-numbered index of outputs in a single transaction starting from 0.\nPKI\nPublic Key Infrastructure; usually meant to indicate the X.509 certificate system used for HTTP Secure (https).\nPoint function\nThe ECDSA function used to create a public key from a private key.\nPP amount\nPart of the Output part of the PaymentDetails part of a payment protocol where receivers can specify the amount of satoshis they want paid to a particular pubkey script.\nPP expires\nThe expires field of a PaymentDetails where the receiver tells the spender when the PaymentDetails expires.\nPP memo\nThe memo fields of PaymentDetails, Payment, and PaymentACK which allow spenders and receivers to send each other memos.\nPP merchant data\nThe merchant_data part of PaymentDetails and Payment which allows the receiver to send arbitrary data to the spender in PaymentDetails and receive it back in Payments.\nPP pki data\nThe pki_data field of a PaymentRequest which provides details such as certificates necessary to validate the request.\nPP pki type\nThe PKI field of a PaymentRequest which tells spenders how to validate this request as being from a specific recipient.\nPP script\nThe script field of a PaymentDetails where the receiver tells the spender what pubkey scripts to pay.\nPrevious block header hash\nA field in the block header which contains the SHA256(SHA256()) hash of the previous blockâs header.\nR parameter\nThe payment request parameter in a bitcoin: URI.\nReceipt\nA cryptographically-verifiable receipt created using parts of a payment request and a confirmed transaction.\nRoot certificate\nA certificate belonging to a certificate authority (CA).\nSSL signature\nSignatures created and recognized by major SSL implementations such as OpenSSL.\nStanndard block relay\nThe regular block relay method: announcing a block with an inv message and waiting for a response.\nTransaction version number\nA version number prefixed to transactions to allow upgrading.\nUnique Address\nAddress which are only used once to protect privacy and increase security.\nUnsolicited block push\nWhen a miner sends a block message without sending an inv message first.\nURI qr code\nA QR code containing a bitcoin: URI.\nV2 block\nThe current version of Bitcoin blocks.\nx509certificates\nterm-x509certificates (developer-examples) ( original target )\nĂ\nDonate to Bitcoin.org\nUse this QR code or address below\n3E8ociqZa9mZUSwGdSmAEMAoAxBK3FNDcd"}
{"url":"https://docs.ens.domains/dao/proposals/6.49","domain":"docs.ens.domains","title":"EP 6.49 | ENS Docs","hash":"a6245cdb6feceb1fff1396ef21c7599c3bbba6b6823948267f7e0d4432a67ed5","tokens":654,"chars":2614,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112175770,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\n[EP 6.49] [Executable] Renewal of the Security Council (Term 2)\nBy avsa.eth\nStatus Rejected\nDiscussion Thread Forum\nVotes Snapshot , Anticapture\nAbstract\nThe ENS DAO Security Council's veto authority expires on 24 July 2026, when renounceTimelockRoleByExpiration() becomes callable at Fri, Jul 24, 2026, 18:52:59 UTC. This proposal renews the council for a further two-year term. It deploys an updated SecurityCouncil contract that adds a extend() function callable only by the DAO timelock, so future renewals are a single governance vote rather than a fresh deployment and role re-grant. The new contract is audited before it is deployed, with the Meta-Governance Working Group funding the audit. The 4-of-8 multisig and the council's cancel-only emergency mandate are unchanged, with one signer rotation: lefteris.eth, who is no longer active in the DAO, is removed and coltron.eth, the largest active delegate not currently on the council, is added. This post has gone through the temperature check; and the Snapshot social vote, and now we are voting on the executable.\nSpecification\nBackground\nThe Security Council is a 4-of-8 Safe multisig with a single power: to cancel malicious proposals in the ENS timelock. It cannot propose, amend, or initiate any governance action. It was approved through EP 5.7 [Social] , EP 5.10 [Social] , and EP 5.13 [Executable] (passed 25 July 2024). The current contract is deployed at 0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0 and its authority is time-limited: two years plus a 7-day buffer after deployment, anyone may call renounceTimelockRoleByExpiration() to permanently disable the cancel power, which occurs on 24 July 2026. The threat that motivated the council, a large treasury relative to active voting power, has not changed, so the recommendation is to renew rather than let it lapse.\nNew contract\nThe current contract has no way to extend its own expiration, so renewing it requires deploying a new contract, passing an executable proposal to grant PROPOSER_ROLE, and letting the old role expire. We propose deploying an updated SecurityCouncil contract ( blockful/security-council-ens ) with the same cancel-only mandate and 4-of-8 ownership, plus an extend() function.\nThe key safety property is that only the timelock can call extend(), so only a passed ENS DAO proposal can extend the term and the multisig cannot extend its own power. After this renewal, each subsequent renewal is a single extend() proposal with no redeploy and no re-grant."}
{"url":"https://forum.solana.com/t/vote-first-governance-advisory-vote-by-validators/597","domain":"forum.solana.com","title":"VOTE! First Governance Advisory Vote by Validators - Governance - Solana Developer Forums","hash":"bee183a31cff0875bc86bf177d63240fb71be45e6b50135fcb0ffce04f73c8dd","tokens":2378,"chars":9512,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112177561,"text":"Solana Developer Forums\nVOTE! First Governance Advisory Vote by Validators\nGovernance\nvote\nlaine\nOctober 10, 2023, 10:50am\n1\nDear Community,\nfollowing discussions in community and validator calls, on this forum and on Discord, I am now initiating a first advisory vote by validators on a key question of governance:\nâWho should vote in a Solana Governance DAOâ\n(Further discussion here and here as well as on Discord here )\nPlease feel free to share how you voted and why in this thread\nOption 1: Validators vote, votes weighted by stake\nOption 2: Validators vote & Delegators can override, if a delegator votes it overrides that portion of the validatorâs stake\nOption 3: Validators, Delegators & Other Stakeholders (identity and weighting to be determined)\nVoting takes place through tokens deposited to each validatorâs identity account. The token has the address BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ and the supply is equivalent to the total active stake in epoch 515. Each validator identity account receives the number of tokens representing their amount of active stake.\nThe mint and distribution is done using the SPL Feature Proposal program.\nVOTING INSTRUCTIONS\n(You will need the spl-token cli tool to vote, it is included in the solana-cli install if you use the installer or install with cargo install spl-token-cli )\nTo cast your vote you must transfer your tokens to one of four public keys to vote for one of the three options or to abstain:\nOption 1: opt1AMNK6g6UxG4N3sFUtfwmM5dKXbJamKCkcr91jai\nOption 2: opt2i1BogY7cwfp23hTz92iQcZyqeX1m4fNZcEcMCSL\nOption 3: opt3T4MkCfJLFHcScTaNZpWSMDGZqNUZwLGCTHFEPzK\nAbstain: ABShtgkUD7UMB7SF9Ur9oLU4XxudnCezjSF8sqqae97c\nTo vote first verify your token balance matches your active stake (in epoch 515) (replace validator-keypair.json with your identity keypair):\nspl-token accounts --owner ~/validator-keypair.json BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ -v\nThen to cast your vote (replace OPTION_PUBKEY with the option pubkeys listed above):\nspl-token transfer --owner ~/validator-keypair.json BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ ALL \nVOTING PERIOD\nWe will look at the balances of these accounts on 20 October 2023 at 12:00 GMT to determine the result of the vote, please vote by then, this is in 10 days from now.\nTALLYING VOTES\nThis is an advisory vote, it does not form a binding decision and as such there is no particular threshold that should be met for any action to be taken. At the end time mentioned above the results will be tallied by myself (and anyone else may do so themselves of course) and published in this thread and on sg.laine.one.\nThe total supply of the voting token equivalent to active stake is 389,207,145.95. Therefore a simple majority would be 194,603,572.975.\nTo check votes cast for a particular option:\nspl-token balance --owner BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ\nADDITIONAL READING\nSummary of discussion on âWho votesâ Who - Solana Governance Think Tank\nVoting token and supply info: Solscan\nCSV File for token distribution by stake: Who - Solana Governance Think Tank\nFeature Proposal Program Docs: Feature Proposal Program | Solana Program Library Docs\n(we are using this program for its ability to automatically mint a token with the exact active stake and create a distribution to all validators based on stake weight, not to activate an actual on chain feature)\n18 Likes\nWho votes - three proposals\nFeedback on the SIMD-123 and SIMD-228 governance process\ncfl0ws\nOctober 18, 2023, 4:32pm\n2\nChainflowâs Vote - Option 3, Validators, Delegators & Other Stakeholders\nInclusivity is one of Chainflowâs four core values . From our perspective, Option 3 is the most inclusive of the three options. This is why we chose it.\nThe choice represents our well-intentioned and best effort to make a decision to move the Solana governance process forward. We recognize itâs based on incomplete information (as most, if not all decisions are) and made within an evolving process.\nWe recognize that Option 3 is also probably the most complicated of the three. We feel that these complications can be figured out and handled over time.\nSolana governance is in a very early developmental stage. It feels important to keep the process as open and inclusive as possible at this stage.\nThat said, we are open to supporting a more restrictive option, such as Option 2, in the future, if that trade-off is required to take an incremental step forward. We would weigh this decision against a number of factors if and when that time arrives.\nOur experience, however, having participated in governance on many chains over the years, has demonstrated that blockchain decision-making is generally led by engineers. As such, the tendency is to move toward efficiency and simplification. So for us to support Option 2, we would need to see a clear commitment to re-opening the voting process to a more inclusive set of stakeholders in the future.\n9 Likes\nProposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta\nProposal For Introducing a Programmatic, Market-Based Emission Mechanism Based on Staking Participation Rate\nProposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta\nzantetsu\nOctober 18, 2023, 10:33pm\n3\nI will be voting for the Validators Vote option.\nMy reasons are twofold:\n- Validator only voting is the most practical and efficient to implement voting system. A nascent governance system is likely to die outright if saddled with the burden of implementing a complex or impractical voting system. Validator only voting is simple, has been demonstrated already in practice, and has existing infrastructure to support it. In future, after time has passed and a validator only voting system has been used enough times that issues surrounding voting are better understood, other voting systems could be proposed as upgrades to the process. But I think that a staged approach where we take practical, implementable steps first, and then expand to more complex systems if they then appear advantageous later, is the right way.\n- Validators will always have an opportunity to engage their stakers and implement their own governance mechanisms within the body of their own stake. So some validators could implement a pre-governance vote method that allows their stakers to provide input, in a whole variety of ways, each validator choosing whatever works best for their stakers. Some may allow stakers complete control over how the validator votes; others may implement a validator choice with staker override method. Still others might have informal methods based on discussion forum feedback with the validator acting as final arbiter on the decision. This plurality of voting methods will allow validators to compete for stake by providing the best voting experience, and validators can individually move faster on finding better voting methods than the overall ecosystem as a whole making monolithic choices can. In addition, this plurality will allow stakers to choose the voting method that they like best by staking with a validator that provides that method. In short, there is no need for a mandatory ecosystem-wide staker-inclusive voting policy when individual validators can allow whatever policy they want to for their own stakers.\n7 Likes\nMCF\nOctober 19, 2023, 8:47am\n4\nMCF - OPT2 - Validators with Delegator override.\nOPT3 - has merit, but would be too complex to implement in reasonable timeframes.\nOPT1 - takes power away from the token holders, so thatâs a NO from us.\nhttps://twitter.com/MCFvalidator/status/1711830346751267244\n5 Likes\nProposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet\nlaine\nOctober 20, 2023, 12:17pm\n5\nTHE RESULTS ARE IN\nWith over 170 participants and around 14.3% of stake voting, over 70% has voted for option 1 with option 2 coming in second at 24%.\ngovvote 752Ă452 14.9 KB\nThe absolute number of votes cast (representative of SOL staked):\nValidators by stake-weight 39557413.31\nValidators & Delegators by stake-weight 13574516.82\nValidators, Delegators & Others 2552960.05\nAbstain 28300.55898\n5 Likes\nProposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta\nFaithful\nApril 16, 2025, 8:12pm\n6\nThanks for the reply â totally agree that posting the process on solana.org would boost trust. Makes sense on the tooling trade-offs, and the vote account changes sound like a solid step forward.\n1 Like\nMike233\nJuly 30, 2026, 7:59pm\n7\nThe real challenge isnât just who votes, but how incentives stay aligned. Validators secure the network, delegators provide the economic backing, and both have skin in the game. A governance model should reflect that balance. Option 2 feels like a reasonable first step because it introduces accountability without making governance prohibitively complex. Whatever model is chosen, the process should remain upgradeable as participation and governance tooling mature.\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nWho votes - three proposals\nGovernance\n24\n2936\nApril 16, 2025\nA Framework for Governance - Introduction\nGovernance\n3\n2612\nApril 16, 2025\nProposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet\nGovernance\nfeature\n,\ncore\n25\n5613\nOctober 4, 2025\nAbout the Governance category\nGovernance\n0\n608\nAugust 7, 2023\nProposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta\nGovernance\nfeature\n,\ncore\n76\n12928\nDecember 25, 2024\nDiscourse Footer"}
{"url":"https://docs.ethena.fi/protocol-overview/underlying-derivatives","domain":"docs.ethena.fi","title":"Underlying Derivatives | Ethena","hash":"07b5d1f8ee41d8f64b5806f6354f5f0bc31939b9c38e5ab8b25d0204770cbca1","tokens":416,"chars":1661,"crawler":"hive-genesis","verified":"unchecked","ts":1791112178567,"text":"â Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nUnderlying Derivatives\nContext\nEthena utilizes derivatives positions to buttress the synthetic USD value of the backing assets in most market conditions. This is achieved by being \"delta neutral\" through the use of an offsetting short derivatives position to the natural long spot position from backing assets.\nIn the subsections below, we go into what each term refers to and the key differences:\n-\nFutures vs Perpetuals\n-\nInverse vs Linear Contracts\n-\nBasis Spread\nOverview\nEthena trades derivatives across all major centralized exchanges that are supported by \"Off-Exchange Settlement\" providers.\nAt a high level, Ethena trades derivatives with a few motivations:\n-\nEthena opens a short position when a user mints USDe .\n-\nEthena closes a short position when a user redeems USDe .\n-\nEthena closes/opens positions across exchanges to realize unrealized PnL.\n-\nEthena algorithmically optimizes positions in the backing portfolio to account for risk.\n-\nEthena algorithmically optimizes positions in the backing portfolio to account for the differences between the exchanges' derivative contract specifications & the capital efficiency available from each exchange.\nIt is important to note that not all exchanges offer the same derivatives contracts and there are often key differences between each. Ethena is also sensitive to the exchange-assigned backing assets value when using liquid staking Ethereum assets, such as stETH, to margin ETHUSD or ETHUSDT Perpetual positions.\nLast updated 1 year ago\nWas this helpful?\n- Context\n- Overview\nWas this helpful?"}
{"url":"https://forum.skyeco.com/t/about-the-grove-prime-category/26786","domain":"forum.skyeco.com","title":"About the Grove Prime category - Grove Prime - Sky Forum","hash":"b8b74a7b20227e4655a79a3ef30ad9a8085c495993dd6fd92b4b7b0b6915d58f","tokens":78,"chars":310,"crawler":"crawler-v8wo","verified":"exact","ts":1791112179314,"text":"Sky Forum\nAbout the Grove Prime category\nGrove Prime\nvotewizard\nJuly 10, 2025, 7:00pm\n1\nEnter the world of Allocators with the Grove Prime. This category is dedicated to tokenized assets and institutional credit specialists who manage vaults and collateral operations at Sky. Learn more at grove.finance\n1 Like"}
{"url":"https://docs.orca.so/liquidity/concepts/impermanent-loss","domain":"docs.orca.so","title":"Impermanent Loss - Orca Documentation","hash":"b7cdff41a4cfbf8a925bc520483992bd6362ce888802de015596054f3c654c37","tokens":2026,"chars":8103,"crawler":"hive-genesis","verified":"unchecked","ts":1791112180207,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nConcepts\nImpermanent Loss\nUnderstand impermanent loss, also known as divergence loss, and how it affects liquidity providers.\nImpermanent loss (IL) describes the difference between providing liquidity and simply holding the deposited tokens.\nOrca also uses the term Divergence Loss , or DL, because it describes what causes the difference: the prices of the deposited assets diverge from their original ratio.\nImpermanent loss is a relative comparison against holding the deposited tokens. It is not always an absolute loss compared with the original deposit value.\nWhat this guide covers\n- Why the term âimpermanent lossâ can be misleading\n- How IL works in AMMs and concentrated liquidity pools\n- When IL may become realized\n- How position range, price movement, and fees can affect outcomes\nWhat is impermanent loss?\nSimple definition\nThe difference in value between providing liquidity and holding the deposited tokens in your wallet.\nKey concept\nIL is a relative comparison. It compares LP position value against the value of holding the same tokens.\nIn an AMM, IL can occur when the relative prices of your deposited assets change. If you withdraw at a different price ratio than when you deposited, your LP position value may be lower than the value of simply holding the same tokens.\nWhy the name can be confusing\nIt is not always impermanent\nThe term suggests the difference may reverse. In practice, IL only stops changing if prices return to the original ratio before withdrawal. If you withdraw while the price ratio is different, the difference is realized.\nIt is not always an absolute loss\nIL compares LPing to holding. A position can show IL compared with holding while still being worth more than the original deposit value.\nThink of IL as an opportunity cost compared with holding, not necessarily as a loss from the original deposit.\nExample scenarios\nFor these examples, assume:\n- 1 USDC = $1\n- Initial SOL price: $200\n- Selected range: $160-$250\n- Liquidity provided: 2.5 SOL ($500) + 500 USDC = $1,000 total\nThese examples are simplified and do not include trading fees, rewards, slippage, transaction fees, taxes, or price movement during withdrawal.\nScenario 1: Price moves down, then returns\n1\nPrice drops to $170\nIf you withdraw at this point, the position may contain approximately:\n- 4.50 SOL, worth about $765\n- 130 USDC\n- Total value: about $896\n2\nCompare with holding\nIf you had simply held the original tokens:\n- 2.5 SOL, worth about $425\n- 500 USDC\n- Total value: about $925\nEstimated IL at this selected price: about $29.\n3\nPrice returns to $200\nIf the price returns to the original deposit price before withdrawal, the estimated LP position value may return closer to the original value, excluding fees, rewards, and costs. This illustrates path independence in a simplified AMM model: withdrawing at the same price ratio as deposit can reduce or remove IL compared with holding.\nIL is realized when liquidity is withdrawn. If price does not return to the original ratio before withdrawal, the difference compared with holding may remain.\nScenario 2: Position value can increase while still showing IL\n1\nPrice rises to $250\nIf you withdraw at this point, the position may be worth approximately:\n- About $1,059 total\n2\nCompare with holding\nIf you had simply held the original tokens:\n- 2.5 SOL, worth about $625\n- 500 USDC\n- Total value: about $1,125\nEstimated IL compared with holding: about $66.\n3\nCompare with original deposit\nThe original deposit value was $1,000. In this simplified example, the LP position is worth about $1,059, while holding would be worth about $1,125. This means the LP position value increased relative to the original deposit, but underperformed holding.\nTrading fees and rewards, where applicable, can affect the final comparison. Fee and reward accrual are not guaranteed and depend on trading activity, liquidity range, reward availability, and market conditions.\nIL in concentrated liquidity pools\nConcentrated liquidity can increase exposure to price movement because liquidity is allocated within a selected price range.\nFactor Possible effect\nNarrower range Greater concentration within a selected price range; may increase sensitivity to price movement\nWider range Liquidity is spread across a broader price range; may reduce sensitivity to price movement\nFees and rewards May offset some or all IL, depending on trading activity and reward conditions\nTrading activity Affects fee accrual while the position is in range\nIn concentrated liquidity pools, price movement can have a larger effect on token composition and position value because liquidity is concentrated within a selected range. Review range settings carefully before depositing.\nKey takeaways\nIL is realized on withdrawal\nIL is a relative difference compared with holding. It becomes realized when liquidity is withdrawn at a different price ratio.\nIL is relative\nIL compares LPing to holding. It is not always an absolute loss from the original deposit value.\nFees can affect outcomes\nFees and rewards may offset IL, but they are not guaranteed and depend on pool activity and conditions.\nRange settings matter\nPrice range, time in range, and token composition all affect LP outcomes.\nWhy Orca uses âDivergence Lossâ\nMore precise terminology\n- Divergence describes the underlying cause: asset prices move apart from their original ratio.\n- Impermanent can imply the difference will reverse, which is not guaranteed.\n- Loss should be understood relative to holding, not necessarily as an absolute loss.\nFocuses on position mechanics\nDivergence Loss emphasizes that outcomes depend on price movement, withdrawal timing, token composition, fees, rewards, and position range.\nReviewing IL risk\nReview range width\n- Wider ranges spread liquidity across more prices and may reduce sensitivity to price movement.\n- Narrower ranges concentrate liquidity and may increase sensitivity to price movement.\n- Range choice affects capital concentration, time in range, and token composition.\nReview volume, fees, and rewards\nTrading volume, fee tier, reward availability, and time in range can affect whether fees and rewards offset IL. These values can change over time.\nMonitor token composition\nAs price moves, a concentrated liquidity position can shift toward one token. If price moves outside the selected range, the position may become fully one-sided.\nReview exit conditions\nBefore withdrawing or rebalancing, review current price, token composition, accrued fees, estimated IL, slippage, and transaction details.\nImportant considerations\n- IL calculations are estimates and can vary depending on pool mechanics, position range, and withdrawal conditions.\n- Trading fees and rewards may reduce or offset IL, but they are not guaranteed.\n- Positions only accrue swap fees while liquidity is in range.\n- If price moves outside your selected range, your position may become fully one-sided.\n- Slippage, priority fees, network fees, and market movement can affect final withdrawal amounts.\n- This guide is informational only and does not provide financial advice.\nConclusion\nImpermanent loss, or divergence loss, is an important concept for liquidity providers. It describes the difference between providing liquidity and holding the deposited tokens as prices move.\nWhen reviewing a liquidity position, consider price divergence, range width, token composition, time in range, fees, rewards, and withdrawal conditions together.\nNext Steps\nPosition Simulator\nReview estimated IL across different price scenarios\nLiquidity Position Concepts\nReview key concepts for liquidity positions\nCreate a Position\nLearn how to create a liquidity position\nUnderstanding Ticks and Fees\nLearn how ticks and fees work in CLMMs\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://bitcoinops.org/en/topics/silent-payments/","domain":"bitcoinops.org","title":"Silent payments | Bitcoin Optech","hash":"0b52fb62b847cf7da08a0a65e4638525584527588db306dc39fb903b1d424ef7","tokens":1014,"chars":4055,"crawler":"crawler-v8wo","verified":"exact","ts":1791112181173,"text":"/ home / topics /\nSilent payments\nSilent payments are a type of payment that can be made to a unique onchain address for every payment even though the receiver provided the spender with a reusable (offchain) address. This helps improve privacy.\nTraditionally, a user who receives payments should generate a new Bitcoin\naddress for every payment. This is because receiving multiple payments\nto the same address reveals that the same user received those payments,\neven if the outputs are later spent in separate transactions.\nThis is known as address reuse .\nUsing a new address often requires a secure interaction between sender\nand receiver so that the receiver can provide a fresh address every time.\nHowever, interaction is often infeasible and in many cases undesirable.\nWith silent payments, a receiver can generate and publish a single silent\npayment address, eliminating the need for interaction.\nThe sender then selects one or more of their chosen inputs and uses their\nsecret key(s) together with public key of the silent payment address to\nderive a shared secret which is used to generate the destination.\nThe intended recipient detects the payment by scanning transactions\nin the blockchain and performing an ECDH calculation with the summed\ninput public keys of the transaction and the scan key from their address.\nThe main downside is that it is more computationally expensive than\nsimply scanning the UTXO set for a scriptPubKey as in BIP32 -style wallets.\nAdditionally, using silent payments in a collaborative setting such as\ncoinjoining is left for future work, and it remains an open\nquestion whether such collaboration can be made provably secure.\nPrimary code and documentation\n- BIP352 silent payments\nOptech newsletter and website mentions\n2026\n- Bitcoin Core #35301 adds silent payment address encoding, output derivation, and scanning\n- Update on silent payments light clients with BlindBit Oracle benchmarks and a convergence draft\n- Using silent payments for miner payouts in the coinbase transaction\n- Silent payments sender plugin for Electrum\n- Libsecp256k1 0.8.0 released with silent payments module\n- libsecp256k1 #1765 adds an optional silentpayments module\n- Sparrow Wallet 2.5.0 adds silent payments receiving\n- BIPs #2142 adds a send/receive test vector to the BIP352 silent payments specification\n- BIPs #2089 publishes BIP376, defining new PSBTv2 fields for BIP352 tweak data\n- BIPs #2047 publishes BIP392, defining a descriptor format for silent payments\n- BIPs #2106 updates BIP352 to limit per-group recipients to 2323\n- Nunchuk adds silent payment support\n- Proposal to limit the number of per-group silent payment recipients\n- Electrum server for testing silent payments\n- Draft BIP for silent payment descriptors\n2025\n- BIPs #1687 merges BIP375 to specify sending silent payments using PSBTs\n2024\n- Draft BIP for DLEQ proofs to support multiple signing with silent payments\n- Draft BIP for sending silent payments with PSBTs\n- BitBox02 hardware signing device adds silent payment support\n- BIPs #1620 and #1622 make minor updates to the BIP352 specification of silent payments\n- Continued discussion about using PSBTs with silent payments\n- Discussion about using PSBTs with silent payments\n- BIPs #1458 adds BIP352 for silent payments\n- Notes from Bitcoin developer discussion about multiple aspects of silent payments\n- Human readable payment instructions proposed that are compatible with silent payment addresses\n2023\n- Proposal to add expiration metadata to silent payment addresses\n- Bitcoin Core PR Review Club summary of #28122 adding silent payments\n- Draft BIP for silent payments\n- Summaries of Bitcoin Core developers in-person meeting\n2022\n- 2022 year-in-review: silent payments\n- BIPs #1349 adds BIP351 for a payment protocol inspired by silent payments\n- Updated silent payments PR\n- Updated alternative to BIP47 reusable payment codes compared to silent payments\n- Silent payments proposed\nSee also\n-\nOutput linking\nPrevious Topic:\nSignet\nNext Topic:\nSimple taproot channels\nEdit page\nReport Issue"}
{"url":"https://docs.ethena.fi/technical-design/use-of-oracles","domain":"docs.ethena.fi","title":"Use of Oracles | Ethena","hash":"a27c4441e7a4f869ec91e13a355a8f61677a311f195973d8b0bdb559c12aa0dc","tokens":512,"chars":2045,"crawler":"hive-genesis","verified":"exact","ts":1791112181939,"text":"â Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nUse of Oracles\nOverview\n\"Oracles\" typically refer to price feeds a protocol utilizes to perform key business logic and functions. Ethena utilizes price feeds from various sources given the importance of real-time data to trading & risk workflows which exist offchain.\nThe system is split between onchain and offchain components.\nPrice Feeds & Ethena's Offchain Systems\nEthena relies on price feeds in order to price the mint and redeem USDe requests per the available derivatives market liquidity as well as manage the risk of derivatives positions. Real-time data feeds indicate not only where the system delegates protocol assets, but the various risk profiles between the exchanges.\nWith this in mind, it's critically important that Ethena has access to & is constantly consuming real-time price feeds, especially from where it matters most; the exchanges where the system holds derivatives positions due to their margin requirements.\nEthena consumes real-time pricing information from three primary sources:\n-\nCeFi Exchanges such as Binance, Bybit, Okx, Deribit, Bitmex and Bitget.\n-\nPyth .\n-\nRedstone\nThis real-time data is used extensively throughout the system to apply business logic, but to also ensure the integrity of all actions.\nIn that way, the system relies heavily upon CeFi Exchange price feeds, given the volume-weighted importance of their traded instruments, and also upon Pyth and Redstone to validate internal pricing throughout the system and before every single mint and redeem USDe request is accepted by Ethena. This ensures thorough checks for any inconsistency and protect the protocol from manipulation that might be occurring from one/multiple sources.\nEthena is constantly working to provide the resilience and integrity of price sources and evaluating other low latency offchain pricing services.\nLast updated 1 year ago\nWas this helpful?\n- Overview\n- Price Feeds & Ethena's Offchain Systems\nWas this helpful?"}
{"url":"https://docs.ens.domains/dao/constitution","domain":"docs.ens.domains","title":"ENS DAO Constitution | ENS Docs","hash":"e917f7c18f859f736809b7585d0c8bf052cec4c1d4a15ee8ef890946f4348586","tokens":892,"chars":3567,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112182896,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\nENS DAO Constitution\nThe ENS constitution is a set of binding rules that determine what governance actions are legitimate for the DAO to take.\nEach article has examples of permissible and non permissible actions. These examples are illustrative and should not be considered a binding part of the text of the constitution itself.\nI. Name ownership shall not be infringed\nENS governance will not enact any change that infringes on the rights of ENS users to retain names they own, or unfairly discriminate against name owners' ability to extend, transfer, or otherwise use their names.\nExamples\nPermissible : ENS governance may enact a change affecting the registration or extension costs of all names based on transparent criteria such as length, as long as it pursues a goal outlined in this constitution.\nNot Permissible : ENS governance must not enact a change increasing or reducing the extension costs of a list of existing ENS names, as this would unfairly benefit or penalise a handpicked group.\nII. Fees are primarily an incentive mechanism\nThe primary purpose of registration fees is as an incentive mechanism to prevent the namespace becoming overwhelmed with speculatively registered names. A secondary purpose is to provide enough revenue to the DAO to fund ongoing development and improvement of ENS. ENS governance will not enact any fee other than for these purposes.\nExamples\nPermissible : ENS governance may increase the price of name registrations in order to address excessive speculative registrations induced by a price that is set too low, or because the current price is insufficient to fund ongoing ENS operations at a reasonable level.\nNot Permissible : ENS governance must not enact a change imposing a fee for claiming DNS domains inside ENS, because such a fee would be purely an income generating measure and not an incentive mechanism.\nIII. Income funds ENS and other public goods\nAny income generated to the ENS treasury is to be used first of all to ensure the long-term viability of ENS, and to fund continuing development and improvement of the ENS system. Funds that are not reasonably required to achieve this goal may be used to fund other public goods within web3 as ENS governance sees fit.\nENS governance will not allocate funds to a team or individual who does not commit to uphold the same principles outlined in this constitution in their use of the allocated funds.\nExamples\nPermissible : ENS governance may offer grant funding for a public good unrelated to ENS or Ethereum, so long as doing so does not affect the long-term viability of ENS.\nNot Permissible : ENS governance must not use the funds to support projects that conflict with the goals of ENS.\nIV. ENS Integrates with the global namespace\nIn order to facilitate making the most widely usable naming system, ENS aims to integrate with the legacy DNS naming system to the greatest extent possible without sacrificing decentralization of ENS. ENS governance will not enact changes that compromise ENS's ability to do this.\nExamples\nPermissible : ENS governance should grant control of a top-level domain to its owner in the DNS system on request.\nNot permissible : ENS governance must not create new top-level domains unless those domains have been granted to ENS by a DNS authority.\nV. Amendments to this constitution by majority vote\nAny change may be made to this constitution only by two-thirds majority and at least 1% of all tokens participating."}
{"url":"https://docs.openzeppelin.com/tools/uikit","domain":"docs.openzeppelin.com","title":"OpenZeppelin UIKit | OpenZeppelin Docs","hash":"5b24786275ab589d499508b9aa1d0de64dc9e61abf9684e06e74e765d20789f7","tokens":915,"chars":3660,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112184806,"text":"Home Forum Website Impact\nOpenZeppelin UIKit\nOpen in Claude\nA modular React component library for building blockchain transaction interfaces. It is chain-agnostic, capability-driven, and designed for multi-ecosystem applications.\nSource code : OpenZeppelin UIKit is open-source. Browse the implementation, open issues, and contribute at github.com/OpenZeppelin/openzeppelin-ui .\nLive example : Explore a hosted demo of UIKit with ecosystem adapters at openzeppelin-ui.netlify.app .\nGetting Started\nInstall packages, set up Tailwind, and render your first transaction form.\nArchitecture\nUnderstand the layered package system, capability model, and runtime lifecycle.\nComponents\nBrowse UI primitives, blockchain-aware form fields, and renderer widgets.\nReact Integration\nWire up providers, hooks, and wallet state management.\nTheming & Styling\nConfigure Tailwind v4 tokens, dark mode, and design customization.\nStorage\nPersist address aliases and app data with IndexedDB via the storage plugin system.\nWhat is OpenZeppelin UIKit?\nOpenZeppelin UIKit is a set of modular npm packages that provide everything needed to build rich blockchain UIs in React. Instead of a monolithic library, it ships as a layered stack from low-level types and utilities up to high-level form renderers and wallet integration.\nEach layer is independently installable. Use only the pieces you need: the type system for a headless integration, the component library for a design system, or the full renderer for turnkey transaction forms.\nPackages\nPackage Description Layer\n@openzeppelin/ui-types Shared TypeScript type definitions: capabilities, schemas, form models 1\n@openzeppelin/ui-utils Framework-agnostic utilities: config, logging, validation, routing 2\n@openzeppelin/ui-styles Centralized Tailwind CSS 4 theme with OKLCH tokens and dark mode 3\n@openzeppelin/ui-components React UI primitives and blockchain-aware form fields (shadcn/ui based) 4\n@openzeppelin/ui-react React context providers, runtime management, and wallet hooks 5\n@openzeppelin/ui-renderer Transaction form rendering engine and contract state widgets 6\n@openzeppelin/ui-storage IndexedDB storage abstraction with Dexie.js and address book plugin 7\nKey Design Principles\nChain-agnostic core. UIKit packages never import chain-specific logic. Blockchain details are handled entirely by ecosystem adapter packages.\nCapability-driven, not monolithic. Instead of one large adapter interface, the system defines small, focused capabilities (addressing, query, execution, wallet, etc.) organized into tiers. Components request only the capabilities they need.\nPay for what you use. Install only the layers your app requires. A simple form builder can use just ui-types + ui-components . A full transaction dashboard can add ui-renderer + ui-react + ui-storage .\nMulti-ecosystem ready. A single app can support EVM, Stellar, Polkadot, and more simultaneously. The runtime system manages per-network adapter instances with proper lifecycle and disposal.\nEcosystem Adapter Integration\nUIKit connects to blockchains through ecosystem adapter packages, standalone packages that translate chain-specific operations into the shared capability model.\nRequirements\n- Node.js >= 20.19.0\n- React 19\n- Tailwind CSS 4\nNext Steps\n- Getting Started : Install, configure, and render your first form\n- Architecture : Deep dive into the capability model and runtime lifecycle\n- Building an adapter : How chain-specific logic is decoupled from the UI\nBuilding an Adapter\nPrevious Page\nGetting Started\nNext Page\nOn this page\nWhat is OpenZeppelin UIKit? Packages Key Design Principles Ecosystem Adapter Integration Requirements Next Steps"}
{"url":"https://docs.base.org/get-started/sdks-and-apis","domain":"docs.base.org","title":"SDKs & APIs - Base Documentation","hash":"56a9ca4aff27f4944a525c86ddd6dc6fd6aa9778022b5f2fc000d8ac59de76d3","tokens":372,"chars":1485,"crawler":"hive-genesis","verified":"unchecked","ts":1791112185509,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBase Documentation home page\nGet Started\nBuild on Base\nSpecifications\nSDKs & APIs\nUpgrades\nReferences\nSDKs & APIs\nChoose the Base SDK, API, or CLI that matches what you are building.\nUse these references when you know which interface your application needs. Start with the SDKs & APIs overview to compare Base-maintained surfaces, or jump directly to local development and chain RPC methods.\nChoose an Integration Surface\nSDKs & APIs Overview\nCompare the Base Chain API, identity verification, and command-line tooling.\nMigrated Documentation\nFind wallet SDK and Wallet MCP documentation on Coinbase Developer Platform.\nbase-anvil CLI\nBuild and test Base-native contracts locally with Baseâs Foundry toolchain.\nCall the Chain\nBase RPC Overview\nChoose between standard block data and 200 ms Flashblock preconfirmations.\nEthereum JSON-RPC\nRead chain state, estimate gas, send transactions, query logs, and subscribe to events.\nFlashblocks API\nUse preconfirmation-aware methods and streams for sub-second application feedback.\nDebug API\nTrace transactions and replay blocks when debugging contract execution.\nBuilder Stack\nFind RPC, data, security, and other service providers that support Base builders.\nWas this page helpful?\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.polygon.technology/payments/core-concepts/quote-system","domain":"docs.polygon.technology","title":"Quote system - Polygon Developer Docs","hash":"360e3d5d1a09d1314c0555b8ddf3cfecf65fd4e9ad6df4c8f0e3ce6ee93905fb","tokens":835,"chars":3337,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112186544,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPolygon Developer Docs home page\nPlatform\nPayments\nWallets\nCross-chain\nAPI Reference\nInfrastructure\nPolygon Chain\nPolygon CDK\nAgglayer\nAgentic\nFundamentals\nQuote system\nHow OMS locks pricing, structures fees, and calculates exchange rates.\nEvery transaction that involves a currency conversion or a fiat rail requires a quote. A quote locks the exchange rate and fee structure for a short window, giving you a guaranteed price before committing to execution.\nQuote lifecycle\nPOST /quotes â open\nâââ POST /transactions â accepted\nâââ (time passes) â expired\nStatus Meaning\nopen Rate locked. Awaiting transaction creation.\naccepted A transaction has been created from this quote.\nexpired Pricing window closed. Create a new quote.\nWhat a quote contains\nA quote response includes:\n- source : the source instrument (a typed side identifying the wallet, bank account, or card being pulled from)\n- destination : the destination instrument (typed the same way, identifying where funds are delivered)\n- pricing : consolidated economics for both sides, the rate pair, and gas sponsorship (see below)\n- sourceToDestination : a composite corridor tag such as cryptoToCrypto , cryptoToCash , cryptoToFiatAccount , cashToCrypto , or fiatAccountToCrypto\n- expiresAt : when the rate lock expires\nFee structure\nEconomics live in a single top-level pricing object. Each side under pricing.source and pricing.destination carries the same shape:\n{\n\"pricing\" : {\n\"source\" : {\n\"asset\" : \"usd\" ,\n\"amountGross\" : \"100.00\" ,\n\"amountNet\" : \"99.42\" ,\n\"feesDeducted\" : {\n\"total\" : \"0.58\" ,\n\"developer\" : \"0.20\" ,\n\"oms\" : \"0.35\" ,\n\"gas\" : \"0.03\"\n}\n},\n\"destination\" : { \"asset\" : \"usdc\" },\n\"pair\" : \"usd/usdc\" ,\n\"exchangeRate\" : \"1.0\" ,\n\"effectiveRate\" : \"0.9942\" ,\n\"fixedAmountSide\" : \"source\" ,\n\"sponsorGas\" : false ,\n\"sponsorGasCost\" : \"0\"\n}\nThe core equation: pricing.source.amountNet Ă pricing.exchangeRate = pricing.destination.amountGross .\nDeveloper fees are configurable per integration. Set them on your OMS account or pass them in the quote request. OMS never shows your fee margin to the end user.\nGas sponsorship\nSet sponsorGas: true on the quote request to cover network gas for your users. Gas costs move out of the transaction fee breakdown and into pricing.sponsorGasCost on your account, a separate, out-of-band developer cost. This is the standard pattern for custodial wallets where users should not be aware of blockchain mechanics.\nFixed-amount quoting\nYou can fix either side via pricing.fixedAmountSide :\n- pricing.fixedAmountSide: \"source\" : user sends an exact amount, destination is calculated\n- pricing.fixedAmountSide: \"destination\" : user receives an exact amount, source is calculated\nThis maps cleanly to common UX patterns: âI want to send $100â vs. âI want my recipient to receive exactly $100.â\nWhen quotes are not required\nAuto-created transactions from deposit addresses, virtual accounts, and cash-ins skip the quote step. OMS uses live pricing at the moment funds arrive. The same fee structure applies, but pricing is not locked in advance.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes.\nSuggestions\nContact support"}
{"url":"https://research.lido.fi/t/hasus-goose-2-submission-a-product-line-approach-to-grow-lido-s-staking-ecosystem/8841","domain":"research.lido.fi","title":"[Hasu's GOOSE-2 Submission] A Product Line Approach to Grow Lidoâs Staking Ecosystem - General - Lido Governance","hash":"f93d7bb6c8bdb9505f3aa7b70f68bb7b092203bdddc1be9ee6823c04e7a7f3c9","tokens":8974,"chars":35894,"crawler":"hive-genesis","verified":"unchecked","ts":1791112187586,"text":"Lido Governance\n[Hasu's GOOSE-2 Submission] A Product Line Approach to Grow Lidoâs Staking Ecosystem\nGeneral\nHasu\nNovember 14, 2024, 6:30pm\n1\nThis post is in response to the second GOOSE cycle (hereafter called GOOSE-2). The process allows the Lido DAO to agree on the next periodâs top 1-3 goals. These goals should cover the âwhat,â while the âhowâ is for contributor teams to determine.\nTLDR:\n1600Ă789 75 KB\n- Expand stETHâs Ecosystem with a Diverse Product Line to meet the diverse needs of Ethereum stakers and reignite growth.\n- Establish an open market for validators to align validator rewards with contributions against Lidoâs mission.\n- Strengthen LDOâs role in governance by aligning incentives with Lidoâs long-term success, promoting stability and sustainability for the protocol.\nContents\n- Recap\n1.1 GOOSE-1 and ReGOOSE\n1.2 Achievements\n- Key Challenges\n2.1 Saturation of the LST category\n2.2. Centralization Risk of Institutional Inflows and Staking ETFs\n2.3 Risk of Ethereum Issuance Reduction\n- The path forward\n3.1 From Product to Product Line\n3.2 A Market for Validators\n3.3 LDO: More than Governance\n- Closing Words\nRecap\nGOOSE-1 and ReGOOSE\nIn the original GOOSE (10/2023) , we set out to position Lido as the safest returns in the Ethereum ecosystem by focusing on decentralized governance, a diverse node operator (NO) set, and deep integrations to grow stETHâs network effect. We believed that liquid staking would become dominant over time.\nIn 05/2024, the ReGOOSE updated these goals in response to the evolving environment, particularly regarding restaking and the Ethereum issuance debate.\nThe vote reaffirmed that stETH should remain an LST and continue to offer the safest returns rather than pivoting to an LRT. Instead, stETH should become the top collateral in the restaking market, allowing stakers to opt into restaking opportunities selectively. Research showed that preconfirmations could eventually be integrated by NOs, providing another avenue for growth.\nAchievements\nSince ReGOOSE, significant progress has been made across all three major swim lanes:\nEffective, decentralized governance\n-\nSimple Delegation led to 30m LDO delegated, with 11M new LDO activated for governance and no missed quorums since. Vote participation increased to 65m on average in Q3 (up from 51m in Q2).\n-\nDual Governance to launch on testnet soon.\nBest validator set in the market\n-\nValidator set expanded from 37 to over 400 node operators, with half being solo stakers enabled by CSM & SDVT modules.\n-\nPermissionless validation introduced.\nstETH most used token in the ecosystem\n-\nProgress toward becoming #1 collateral in staking, including launching Aave isolated instance for looping LRTs with wstETH and positioning for preconfirmations when they launch\n-\n0 security incidents, maintaining trust.\nKey challenges\nSaturation of the LST Category\nOver the last year, the share of ETH staked using Lidoâs middleware has gradually declined from 32% to 27.8% of all staked ETH, reflecting the growing saturation of the LST sector. During this period, over 1M new ETH (TVL) was staked through Lidoâs smart contracts, but its percentage share declined nonetheless, as the sector overall grew by 8M ETH simultaneously.\nThe rise of the LRT category in this story has been discussed in reGOOSE , and its growth has likely peaked.\nLidoâs usage within the LST category remains dominant and strong at around 90%, but its share of the broader category has declined from a peak of 37% to 31%. Even when considering both LST and LRT (âall liquidâ), the category size is roughly unchanged compared to 2.5 years ago.\n1600Ă777 80.9 KB\nstETHâs liquidity moat has declined since Beacon Chain withdrawals became possible, and the collapse of FTX has further limited major CEX support for stETH, impacting its liquidity. Bybit, OKX, and Deribit have since added stETH with small collateral ratios, but Coinbase and Binance have yet to list stETH, likely to prioritize their own staking offerings.\nMoreover, one year ago, every staking solution offered the same Ethereum rewards + MEV. Today, bespoke forms of reward, such as inorganic points, have taken over. Staking has become âchasing the hot ball of rewards,â leading more users to manage their stake more actively.\nFinally, the influx of more institutional users such as HNWIs, ETP/ETF providers, or neo banks has brought customers with yet different and often more bespoke demands of their staking provider currently underserved by vanilla stETH.\nIn summary, the thesis that one LST would dominate has not materialized due to increasingly varied user needs. Lido must evolve to address this shifting environment.\nCentralization Risk of Institutional Inflows and Staking ETFs\nInstitutional inflows, such as the ones through Staking ETFs, are equally risk and opportunity.\nCentralized providers, especially with a custodian business line, are well positioned to try and capture this inflow early , even at the expense of increased counterparty risk for the issuer and significantly curtailed validator decentralization at the network level.\nstETH is well positioned to become the solution of choice for ETF issuers, given its liquidity and diversified exposure to node operators. As an asset, it passes many of the same tests that ETH cleared when being considered as part of an ETF product and trades in deep markets with high correlation to ETH and ETH futures at CME.\nHowever, ensuring broad adoption of stETH will require focused advocacy and collaboration to overcome potential headwinds from other staking providers.\nWe must ensure that institutional capital inflows contribute to Ethereum validator decentralization.\nRisk of Ethereum Issuance Reduction\nSome community members believe Ethereum already has more stakers than needed and that the marginal utility of adding more stakers has become negative. The argument is that excessive staking creates network overhead, reduces Ethereumâs monetary premium, and potentially introduces security risks.\nThe debate has two sides: (1) reduce staking by altering issuance incentives or (2) embrace staking and make delegated staking as trustless as possible.\nIf issuance is reduced, competition on price would intensify, particularly impacting higher-cost producers like solo stakers and decentralized staking pools. This would necessitate an even more efficient staking model for stETH to remain the token of choice.\nThe path forward\n1600Ă789 75 KB\nFrom Product to Product Line\nOver the last year, Lido contributors have made significant strides in improving security and decentralization, delivering the software for DVT and CSM modules, Simple Delegation, Dual Governance, and more. With these foundations in place, the Lido protocol must evolve to stay relevant in the maturing and diversifying field of staking.\nItâs time to pivot from a single-product focus to a product line strategy, driving stETH adoption through innovative, differentiated staking products.\nThe LST category is becoming saturated. To regain share, Lido must transition from offering stETH as a singular product to developing a broader product line within the staking ecosystem. This involves creating a suite of interconnected products that cater to diverse needs and preferences within a cohesive framework.\nWhile more analysis is needed to identify the optimal beachhead markets, there are at least three promising categories currently underserved by stETH:\n- Institutional stakers: Require tailored solutions to meet specific technical, legal, compliance, and insurance requirements.\n- Restakers : Seek greater risk/reward opportunities by restaking their ETH and/or engaging in points farming.\n- Leverage-seekers : Desire the cheapest possible leverage while minimizing liquidation risk.\nThe success of this transition to a product line strategy depends on leveraging shared infrastructure across different products. By building a suite of staking products with stETH as a foundation, we can create a versatile ecosystem that meets diverse market segments without compromising liquidity or brand identity.\nA Market for Validators\nI propose creating an open market for validators within Lido , allowing for differentiated offerings and a more flexible fee structure reflecting each validatorâs risk and decentralization contribution.\nWith the addition of SDVT and CSM, Lido has evolved from a single curated module to having three modules connected by the Staking Router. This expansion not only enhances decentralization but also introduces different fee structures for node operators (6% for CSM and 8% for SDVT), offering more flexibility.\nThis approach is based on two key insights: (1) not every node operator has the same marginal cost of production, and (2) not every node operator provides the same value to Lido stakers and Ethereum. For instance, NOs with more decentralized setups may be more costly to operate but provide greater value to the network.\nIf Lido protocol is upgraded to add a product line around staking, a third insight may be added: (3) since staking risk within Lido is socialized, some modules inherently carry higher risk than others.\nThese three insights lead to a clear conclusion: Lido should programmatically reward node operators differently based on their specific contributions and classification. This concept was already mentioned in the 3-year goals as ârisk mitigation by designâ and a âfree market for validation.â\nA well-designed staking market would drive efficiency, fairness, and resilience within the ecosystem by achieving the following:\n-\nAligning risk/reward between more and less risky modules\n-\nAligning node operator rewards more effectively with their contributions\n-\nIncreasing Lido treasuryâs ability to provide operational grants, especially if issuance is reduced\nA flexible validation market allows Lido to reward node operators based on risk, cost efficiency, and their value to Ethereumâs decentralization, thus aligning operator incentives with Lidoâs mission.\nLDO: More than Governance\nSince its inception, Lidoâs smart contracts and treasury have been entirely controlled by LDO holders. While this makes Lido DAO one of the most decentralized DAOs, it also makes governance attacks a significant threat.\nWith Simple Delegation assigning 30M LDO to delegates and increasing average vote participation by 15M, and with Dual Governance soon giving veto-like powers to stakers, Lido has taken substantial steps to mitigate governance risks. Despite these efforts, LDO will continue to play a central role in the Lido ecosystem.\nLDO secures and directs the Lido protocol and its key resources. Therefore, it is crucial to (1) attract the right individuals to become LDO holders and (2) ensure that these holders are strongly aligned with the long-term mission and success of the Lido protocol.\nStarting this discussion is timely for two reasons: (1) the regulatory environment may be improving, reducing the risk of token-related changes (subject to further analysis), and (2) a rising ETH price could make the Lido protocol profitable for the first time.\nWhile activating a âfee switchâ isnât immediately necessary, establishing a framework now would improve the predictability of future cash flows and strengthen governance alignment.\nBy tying LDO more directly to protocol revenue, we can attract committed, long-term holders who are invested in Lidoâs growth and success.\nClosing words\nLido contributors have always prided themselves on having a clear mission and staying committed to long-term plans, even in a distracting and often hype-driven environment. Our mission is to make staking simple, secure, and decentralized .\nGOOSE-2 proposes an ambitious new path forward, but many core values will remain unchanged:\n-\nA deeply embedded culture of security and alignment with Ethereum\n-\nContinued investment in decentralization, especially by completing key projects like DG and expanding CSM + DVT, while staying flexible to adjust budgets if issuance is cut\n-\nMaximizing the network effect and liquidity of stETH\n-\nFocusing on the institutional market as a major opportunity\nWhat has evolved is our understanding that a single, uniform staking product is no longer sufficient to meet the needs of a diverse user base.\nWe, the Lido community and contributors, must embrace this transition to solidify Lidoâs place as the leading staking provider. Letâs develop products that serve a broad spectrum of stakers, build a validator marketplace, and align LDO holders with Lidoâs long-term mission. Together, we can make 2025 a transformative year for both Lido and Ethereum.\n36 Likes\nThe Guided Open Objective Setting Exercise (âGOOSEâ) proposal; A genesis step to jump-start a DAO-wide goal setting exercise and cadence\n[EGG] Lido Alliance Grant Funding\nPol Lanski Delegate Thread\nIntroducing ETHGas and Realtime Proposer Commitments to the Lido Community\n[EGG] Multi-EGG Continuity Grant Funding\nGovernance Grove Delegate Thread\nPragmatically Institutionalizing Lido DAO\nEstablishment of Lido Labs BORG Foundation as a Lido-DAO-Adjacent Foundation\n[Lido Labs] GOOSE-3: Lidoâs Next Chapter\nGOOSE-2025 & EGGs-2025 Final Report\n[Lido Labs] GOOSE-3: Lidoâs Next Chapter\nHigh Signal Lido Community Lifeguard Grant Proposal\nEstablishment of Lido Ecosystem BORG Foundation as a Lido-DAO-Adjacent Foundation\n[EGG] Lido Alliance Grant Funding\n[EGG] Multi-EGG Continuity Grant Funding\nzk1t\nNovember 14, 2024, 7:21pm\n2\nThanks for making this proposal, itâs a great step in the right direction.\nWith regard to new product lines, is there any possibility of Lido stepping outside the comfort zone of focusing specifically on stETH?\nFor example:\n- Ecosystem expansion and targeting LST products on other chains?\n- Moving upstream to capture value by implementing Lidoâs own version of something like an EigenLayer or a Pendle - e.g. products that heavily rely on stETH where Lido could capture additional value rather than leaking it to other protocols?\n7 Likes\nTotally2\nNovember 15, 2024, 12:56am\n3\nThanks Hasu, great proposal: Understanding that both the regulatory landscape is evolving and institutional obligations are not uniform, do you have any insights into what meeting these institutional needs looks like in practice? Is there an implementation that maintains the liquidity/fungibility properties of stETH while meetings these needs?\n6 Likes\n18519865qwe\nNovember 15, 2024, 6:06am\n4\nThe team lives too comfortably. They have a lot of cash in their hands and receive high salaries every month without any sense of crisis. sol.matic.dot.atom. The pledge of these chains failed in advance. Shouldnât the team reflect on this?\nLDO\nTokens should also be empowered long ago. They should pay dividends like stocks, or be destroyed like BNB. Otherwise, what will a governance token do to you? It is enough to have STETH as the governance token. The team might as well not issue coins?\n4 Likes\nHasu\nNovember 15, 2024, 3:34pm\n5\nWhen I say, âNew products should use stETH as the foundation,â it has less to do with staying in our comfort zone and more with building on our âunfair advantage.â\nGoing to other ecosystems\nThatâs why I would not go to any other ecosystems. Not only are the conditions usually not optimal to make an LST successful, and the waters are swimming with competition, but Lido has very little of this unfair advantage against them. You could even argue that Lido would be disadvantaged because new projects start with a bloated valuation and outspend Lido on token-based incentives.\nScaling vertically\nAs to horizontal vs vertical scaling, itâs becoming increasingly clear to me that the LST category is becoming saturated, and hence, Lido has little room to grow.\nMoving upstream in our vertical is possible, but I am convinced that scaling horizontally to other verticals is better. With going upstream, what would convince me is a) Lido can produce something with much better UX that increases downstream demand for stETH, and b) Lido can reduce a key dependency and/or capture much additional value.\nI donât see it for a) at all, and b) it is truer but debatable. Restaking has likely peaked now, and with Symbiotic, a new player is launching soon to reduce the power of Eigenlayer in that layer. Aave is the big gorilla in the credit layer, but our protocols have a good relationship, and the Lido isolated market on Aave is shaping to be a great collaboration. No one seems to be extracting excessive rent from Lido stakers right now.\nThese things might change, and then we should change our minds, and itâs good to think through what that might look like in advance. So, I appreciate the question.\nScaling horizontally\nHorizontal scaling, on the other hand, looks like a better option to me. There are clear user segments in staking that are not currently served well by stETH because they want better access to leverage, better access to restaking/points, or more customization around their node operator setup.\nWhat matters here for this to be a good strategy is whether Lido contributors/researchers can find a way to offer these products while reusing as much as possible from Lidoâs existing infrastructure and stETHâs network effect and liquidity moat. Some early thinking on how that could look in my other response.\nFinally, when a horizontal scaling strategy can work, it usually leads to better financial outcomes for the DAO because the same fixed-cost infrastructure can be reused across a larger base of users.\n11 Likes\nHasu\nNovember 15, 2024, 3:45pm\n6\nI may not be the best person to answer this, but in the original GOOSE-1 , bring-your-own-validator (BYOV) modules were already mentioned as a promising path. The idea is to make modules a lot more granular than they are today. At the limit, you may have one module per BYOV staker, and this staker can decide who that moduleâs node operator is.\nHaving a non-Lido node operator raises new challenges around MEV stealing, performance, risk management, and more. Still, these challenges are not too dissimilar from those Lido contributors face in permissionless CSM modules. It is a theory that such a design can be further generalized to cover verticals like restaking as well.\n6 Likes\nHasu\nNovember 15, 2024, 3:57pm\n7\nThis discussion has been had many times in the forum, so I would encourage you to dig into some older threads. But the gist is that LDO is needed to secure Lido governance, which itself votes on key parameters and the upgradeability of the smart contracts.\nI agree that an economic link between LDO and protocol success must be established at some point. If the token becomes unattractive for rational community members to hold, the governance can become insecure, putting the whole protocol at risk. My proposal directly addresses this, and 2025 would be a good time to further explore this subject as a community.\n7 Likes\nzk1t\nNovember 16, 2024, 12:44am\n8\nI see your points but I respectfully disagree, yes we should probably spend a lot of time and effort scaling horizontally but we should also think about ecosystem expansion and vertical scaling. I am of the belief that verticalization will ultimately be how you actually extract fees because at any point in time, whoever captures the end user will be able to create their own versions of lending, dexes, staking, etc. - just look at exchanges and how much money they are making. They donât just offer trading, they started with that but now itâs pretty much go to them and get whatever you want - trading, staking, yield strategies, launchpads, wallets, they even have their own chains now.\n-\nEcosystem expansion: Yes there is more competition and yes other protocols can use tokens as a way to attract TVL. However, if Lido becomes profitable we can use real profit to attract TVL and compete with other ecosystem competitors. This is a win win because a) users generally prefer real yield and more importantly b) real yield is significantly more sustainable than emitting tokens. If competitors are forced to emit tokens as a way to maintain TVL then they risk flooding the market with too many tokens and thus crashing their token price, which optically would be bad and could also destroy moral of their community. So if Lido can use profits to subsidize growth in other areas, Iâm actually not worried about competition at all, similar to how Amazon uses their profits from cloud to subsidize their marketplace product to outcompete their competitors.\n-\nstETH product: I also disagree, there may not seem like a big demand today but thereâs evidence that for a product like Pendle there are literally billions of dollars worth of these types of products in traditional finance that are based off of treasuries, and I donât see why if Ethereum succeeds, the same wonât happen with staked ETH and why lido should preclude itself from being a part of creating those products. Also since lido owns the smart contracts to stETH there are likely ways to create the product that make it safer for users vs. another protocol building on top of stETH. Plus, a lot of the code is already out there and open sourced for building this so itâs not like you need to invest the same amount of money/effort to do it, you just need to be a follower and wait for the leaders to pave the way - e.g. most dexes and uniswap strategy, with the main difference here being that lido and stETH are actually the market leader and own most of the stETH liquid market\n2 Likes\nThe Guided Open Objective Setting Exercise (âGOOSEâ) proposal; A genesis step to jump-start a DAO-wide goal setting exercise and cadence\n18519865qwe\nNovember 16, 2024, 2:48am\n9\n1731725116235 1394Ă1178 243 KB\nBitwise, the issuer of Ethereum ETF, acquired Attestant, a specialized ETH staking service company. It is most likely preparing for the upcoming ETH ETF staking in advance. Currently, ETH There is almost no doubt that ETFs that allow staking will continue to be implemented after Trumpâs new policy. The 350 million U.S. dollars of ETH currently managed by Bitwise will earn an annual staking income of 12 million U.S. dollars at an APR of 3.7%, while its current fund management is 0.2%. The fee rate can only earn US$700,000, so these ETH ETF issuers will definitely work hard to promote staking.\n1 Like\n18519865qwe\nNovember 16, 2024, 3:01am\n10\nMost importantly, you are too slow to expand staking to other chains. If you had heavily subsidized sol staking back then, you would definitely see good performance now. Therefore, if you want traditional ETF pledgers to accept lido, you must sell part of lido shares as soon as possible and empower lido tokens! If I were a part of your team, I believe I could do better because you never pay attention to the community and donât know what the community wants.\n4 Likes\nzk1t\nNovember 16, 2024, 3:02am\n11\nyeah Iâm pretty sure itâs going to be incredibly difficult to get someone like a blackrock to stake their ETF with Lido and stETH (I could be wrong) but it feels like why wouldnât they just use Coinbaseâs staking service or the staking service of whoever they are custodied with?\nIs lido even talking to these large ETF providers about staking ETH through stETH? Because if we arenât, we probably should have started these conversations last year.\n2 Likes\npolar\nNovember 16, 2024, 5:40pm\n12\nThis is the most intriguing line. It looks like the issue is stalled at Uniswap (discussion here and here ) but perhaps someone closer to the story knows more.\n6 Likes\nLeuts\nNovember 18, 2024, 7:37am\n13\nGm! Thanks for the extensive proposal on GOOSE-2.\nFirstly, congrats on the Goose-1 achievements. Wins across the board and a testament to the teams ability to execute.\nRegarding Goose-2: I agree that Lido could and should begin to start producing value beyond a uniform staking product while maintaining the same core values and mission. There is undoubtedly space to do so and preparing to do so now makes sense both in relation to the market, regulatory environment, and Lidoâs PMF in a potentially stalling segment. Lido might be one of the few teams in the industry that is ready for this kind of move.\nI believe that both horizontal and vertical scalability both provide advantages and disadvantages.\nHorizontal â larger market opportunity, decreases risk of getting stuck long-term\nVertical â Easier to build and execute with existing team knowledge/experience, decreases forkability, easier to monetize\nHowever, if you fundamentally believe that the LST category is saturated and future growth will be negligible than horizontal scalability might make more sense as you are casting your safety lines outwards. I think the short-term risk is higher, but the potential ROI is much greater.\nRegarding the optimal beachheads to horizontally scale:\n- Institutional Stakers: no brainer â easy to use Lidoâs trusted brand\n- Restakers: Arguably the most overhyped market in the industry. We have yet to see organic traction and estimated organic APY is extremely low. I donât see any rush for Lido to move into this vertical until the froth has settled and an intelligent path found forward.\n- Leverage-seekers: Has existed in some form forever and isnât going anywhere. Seems like low-hanging fruit.\nI think careful consideration of HOW you plan to monetize a new horizontol strategy would be important before beginning the endeavour, as I do believe vertical alignment is one of the only ways to monetize in our open source industry.\nLDO Fee Switch: Although you arenât advocating for the fee switch to be turned on immediately. I do find it interesting to be included in this proposal. Wouldnât directing revenue directly to token holders while simultaneously pivoting to a product line approach be counterproductive? My assumption would be that you would want the maximum resources during the pivot to attack a new vertical?\nAlthough it could attract committed, long-term holders, decreasing some governance risk, there may be other methodologies to do this as well in the short-term that could be explored. I am not against planning however, and do think one day that this would be advantageous.\nLooking forward to participating and seeing how this unfolds! This could be a next huge chapter for the Lido DAO and be a transformative year to prepare it for a long and diverse future.\n13 Likes\nIgnas\nNovember 18, 2024, 12:59pm\n14\nThanks for laying out such a detailed roadmap for Lidoâs growth next year. Iâd like to share a few thoughts:\n- You mentioned that:\n- Plus, you said that:\nA big catalyst for growth are upcoming staked ETH ETFs.\n@18519865qwe in the comments mentioned the Bitwise getting staked ETH ETF via acquired Attested to prepare for the launch.\nWhy canât that provider for staked ETH be Lido?\nLido has the battle tested technology that could be used for ETFs.\nPerhaps the DAO can fund hiring BD team that manages to attract Blackrock and other ETF issuers to collaborate with us?\n- On:\nAnother major area for growth. Symbiotic + Mellow was a big success.\nThese initiatives that provide better yields opportunities for stETH holders will help grow the TVL.\nI would be as brave as to suggest a Lido native stablecoin that competes with Ethena. The Ethena protocol now controls a large supply of stETH but we could work on a more decentralized solution.\nAny brave ideas are welcome.\n-\nOpen market for validators: As I mentioned in my thread, Ignas Delegate Thread . Iâm all for decisions that enhance the decentralization of the protocol. But, if most rewards end up with large validators or those offering lower fees, it could lead to centralization risks in the system.\n-\nStrengthening LDOâs role in governance: I support this because it will increase the long-term value of LDO and attract more holders. Overall, I agree that we need to add more details on âhowâ to assess the proposals, not just the âwhatâ :). Looking forward to hearing othersâ thoughts!\n2 Likes\nIgnas Delegate Thread\nfiddyresearch\nNovember 18, 2024, 2:59pm\n15\nHey @Hasu ! Very honest and insightful proposal. I have a few observations and comments that Iâd like to share.\n- The stETH product line is quite dependent on the liquidity moat as you so aptly mention. There seems to be scope to develop sustainable liquidity incentivisation strategies to support active (rational) and passive (rational and irrational) liquidity providers. Do you think strategies like the DAO owning a liquid-governance token to direct incentives at a low cost over time makes sense?\n- You mention that Ethereum staking has reached a level of saturation, and its now up to the whims of broader market to raise the tide that lifts all boats. I posit that it users are very comfortable holding WETH or ETH over stETH, principally because it âfeelsâ safer than stETH, which means thereâs quite some more market-share to grab if and only if Lido works towards making stETH a no-brainer to hold over ETH. This is probably the cheapest growth strategy over the longer term since it costs nothing to the Protocol if users cannot discern stETH from ETH. So, if the problem statement is stETH does not feel like ETH, one proposed solution could be working towards wallet integrations where ETH is staked on Lido natively, or working on wallets natively as well (perhaps in collaboration with a wallet service provider).\n- Finally, I feel like there is a significant userbase that is being ignored: fixed-income seekers. The points meta has caused a lot of trouble for stETH, but thereâs definitely a silver lining in the there somewhere. Pendle was proliferated and we have the likes of Spectra who are also feverishly working towards making yields predictable and tradeable. Thereâs definitely scope to make a stETH zero-coupon bond via Principal Tokens, and working towards making PTs collateral-worthy, and onboarding it into Aave Lido instances as well. Would that be a strategy to consider.\nI speak only on the asset standpoint, since thatâs where most of my experience lies. Iâll leave the evaluation of the rest to the others.\n3 Likes\nkadmil\nNovember 18, 2024, 5:09pm\n16\nNote that âgoal settingâ is not about âhowâ though, and GOOSE is a goal-setting exercise. âHowsâ are getting tackled and handled on project-by-project basis mostly: thatâs the reason behind âlandscapeâ proposals (for instance, Community Staking Module: Community Staking Module , Dual Governance: Lido dual governance explainer (research distillation) ) and the like.\n6 Likes\nkadmil\nNovember 18, 2024, 5:17pm\n17\nLido DAO & reWARDS/LOL committees have long-stopped providing incentives in LDO, focusing on using DAOâs part of stETH rewards fee as the main source (= âstETH is used as incentivesâ). Managing âprotocol-owned liquidityâ 1) requires significant effort; 2) carries quite high operational risk. Those are the main reasons why the Treasury Management Committee basically has a policy against such kind of activity.\n1 Like\nkadmil\nNovember 18, 2024, 5:27pm\n18\nWhile Iâd say those directions look interesting, without the numbers (market size / âmedian cost of liquidityâ / you name it) itâs not actionable. Thereâs a stream of work towards making StETH the most used LST âwhere the users areâ, which will be continuing =)\nkadmil\nNovember 18, 2024, 5:34pm\n19\nPlease, check out the Lido on Polygon discussion here: Reevaluation of Lido on Polygon state . Long story short â building the successful LST is tough and there isnât a cookie cutter solution; even while some thinking and know-how can be re-applied, the actual networksâ ecosystems vary far greater than one can expect from the outside.\n3 Likes\nCortina\nNovember 18, 2024, 7:13pm\n20\nI am happy to see @Hasu recognizing the need for additional product lines if Lido is to grow over the next few years and I have some suggestions for how new product lines could be added below.\nFirst, our focus on DVT and CSM modules were important and not celebrated nearly enough by the broader Ethereum community for their contribution to Ethereumâs mission/values. With that said, LDO holders should be concerned going forward given the growth opportunities weâve missed over the last couple of years. Here are a few examples where an optimistic LDO holder from 2021 might have assumed Lido would win market share:\n- Competing L1 LST markets\n- LRT market\n- Native Yield L2 (lido chain)\nNone of those have come to pass and over the last year or so, it seemed LDOâs inevitable future was similar to an energy utility where the criticality of our role within Ethereum would prevent expansion to new ecosystems and/or the exploration of new verticals. Meanwhile, margin expansion in our existing business would inevitably be constrained both by political pressure and by rights endowed to stETH holders through dual governance. These constraints are real as far as I can tell. The Ethereum community should want LDO holders to be as Ethereum aligned as possible and stETH holders should want the lowest take rate that allows Lido to be sustainable and secure. Without growth prospects, a LDO investor must ask, âwhy am I holding a token for a project that has no growth prospects and, net operating expenses, earns significantly less ETH per dollar invested compared to simply owning stETH?â And that is without any mention of the uncertainty about whether or not those earnings might ever be distributed to LDO holders. Eventually, as Hasu mentions, this becomes a security risk.\nNew product lines through 1) internal incubation, 2) venture incubation and 3) acquisition:\n-\nIt is difficult for me to assess whether internal Lido resources previously allocated to other initiatives might be freed up and whether or not those resources are well suited to build new product lines. But it seems unlikely especially considering original founders have moved on.\n-\nThe last few years have offered plenty of learnings about how not to use treasury assets to incentivize product/protocol development within an ecosystem. I strongly discourage using treasury LDO as a direct incentive for entrepreneurs to build new Lido product lines. Fundamentally, new projects are in need of cash to build and have plenty of upside if they are successful. They should be focused exclusively on winning through their own token. In other words, new projects have a very high liquidity preference making them a bad match for token grants, locked or liquid. Instead, if we want to use LDO from our treasury, we should allocate locked tokens to investors that fund new product line projects with cash. Imagine a âLido Incubated Projectsâ category on Echo where an investor can contribute USDC and receive an allocation of New Project Token as well as long-term locked Lido. The new project gets cash to build, Lido gets new product lines, and long-term investors get LDO along with their high upside venture bet tokens.\n-\nWe should also consider M&A opportunities where Lidoâs brand and treasury assets might help useful but neglected tech overcome the cold start problem. As an example, perhaps we think a useful new product line for Lido is a cross-chain borrow/lend marketplace. Personally, I like the idea of holding my stETH on L1 while borrowing against it on L2âs and alt L1âs for my more speculative activities. It seems other bridging solutions like Across will be disadvantaged by tax implications of their model in most juristictions. Would it make sense to acquire Synonym Finance (current FDV 3M) instead of building it ourselves?\n7 Likes\nnext page â\nRelated topics\nTopic\nReplies\nViews\nActivity\n[Lido Labs] GOOSE-3: Lidoâs Next Chapter\nProposals\n25\n3403\nDecember 22, 2025\n[Hasu's GOOSE Submission] Proposed goals for Lido DAO to consider\nGeneral\n16\n10089\nOctober 21, 2024\nBlockworks Research Delegate Thread\nDelegate Platform\n11\n468\nJuly 21, 2025\nReGOOSE: Updated goals for Lido in the light of MVI and restaking\nProposals\n27\n6333\nMay 25, 2024\nGOOSE-2 & EGGs-2025 Progress Report\nGeneral\n1\n639\nOctober 27, 2025"}
{"url":"https://bitcoinops.org/en/newsletters/2024/09/20/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #321 | Bitcoin Optech","hash":"15305fc8b89128e55466438cd06dd47a5f3dd5d516895fe8dc4ecbc0606f9cb5","tokens":2513,"chars":10050,"crawler":"crawler-v8wo","verified":"unchecked","ts":1791112188309,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #321\nSep 20, 2024\nThis weekâs newsletter links to a proof-of-concept implementation for\nproving in zero-knowledge that an output is part of the UTXO set,\ndescribes one new and two previous proposals for allowing offline LN\npayments, and summarizes research about DNS seeding for non-IP network\naddresses. Also included are our regular sections describing changes to\nclients and services, announcing new releases and release candidates,\nand summarizing notable changes to popular Bitcoin infrastructure\nsoftware.\nNews\n-\nâ Proving UTXO set inclusion in zero knowledge: Johan Halseth\nposted to Delving Bitcoin to announce a\nproof-of-concept tool that allows someone to prove that they control\none of the outputs in the current UTXO set without revealing which\noutput. The eventual goal is to allow the co-owners of an LN funding\noutput to prove they control a channel without revealing any specific\ninformation about their onchain transactions. That proof can be\nattached to next-generation channel announcement messages that are used to build decentralized routing\ninformation for LN.\nThe method used differs from the aut-ct method described in\nNewsletter #303 , and some of the discussion focused\non clarifying the differences. Additional research is needed, with\nHalseth describing several open problems.\n-\nâ LN offline payments: Andy Schroder posted to\nDelving Bitcoin to sketch a communication process an LN wallet could\nuse to generate tokens that could be provided to an internet-connected\nwallet in order to pay it. For example, Aliceâs wallet would normally\nbe connected to an always-online LN node she controls or that is\ncontrolled by a Lightning service provider (LSP). While online,\nAlice will pregenerate authentication tokens.\nLater, when Aliceâs node is offline and she wants to pay Bob, she\ngives Bob an authentication token that allows him to connect to her\nalways-online node or LSP and withdraw an amount indicated by Alice.\nShe can provide the authentication token to Bob using NFC or\nanother widely available data transfer protocol that doesnât require\nAlice to access the internet, keeping the protocol simple and making\nit easy to implement on devices with limited computing resources (such as\nsmart cards).\nDeveloper ZmnSCPxj mentioned an alternative approach he\nhad previously described and Bastien Teinurier referenced a method for node remote control he designed for this type of\nsituation (see Newsletter #271 ).\n-\nâ DNS seeding for non-IP addresses: developer Virtu posted\nto Delving Bitcoin a survey of the availability of seed nodes on\nanonymity networks and discussed methods\nfor allowing new nodes that exclusively use those networks to learn\nabout peers through DNS seeders.\nAs background, a Bitcoin node or P2P client needs to learn the\nnetwork addresses of peers that it can download data from. Newly\ninstalled software, or software that has been offline for a long time,\nmay not know the network address of any active peers. Normally,\nBitcoin Core nodes solve this by querying a DNS seed that returns the\nIPv4 or IPv6 addresses of several peers that are likely to be\navailable. If DNS seeding fails, or if itâs unavailable (such as for\nanonymity networks that donât use IPv4 or IPv6 addresses), Bitcoin\nCore includes the network addresses of peers that were available when\nthe software release was made; those peers are used as seed nodes ,\nwhere the node requests additional peer addresses from the seed node\nand uses them as potential peers. DNS seeds are preferred over seed nodes\nas their information is usually more current and the global DNS\ncaching infrastructure can prevent a DNS seed from learning the\nnetwork address of each querying node.\nVirtu examined the seed nodes listed in the last four major\nreleases of Bitcoin Core and found that a satisfactory number of them\nwere still available, indicating that users of anonymity networks\nshould be able to find peers. They and other discussion participants\nalso examined the possibility of modifying Bitcoin Core to allow it to\nuse DNS seeding for anonymity networks via either DNS NULL records\nor encoding alternative network addresses into pseudo-IPv6 addresses.\nChanges to services and client software\nIn this monthly feature, we highlight interesting updates to Bitcoin\nwallets and services.\n-\nâ Strike adds BOLT12 support:\nStrike announced support for BOLT12 offers ,\nincluding using offers with BIP353 DNS payment instructions.\n-\nâ BitBox02 adds silent payment support:\nBitBox02 announced support for silent payments and an implementation of payment requests .\n-\nâ The Mempool Open Source Project v3.0.0 released:\nThe v3.0.0 release includes new CPFP\nfee calculations, additional RBF features including fullrbf\nsupport, P2PK support, and new mempool and blockchain analysis features, among\nother changes.\n-\nâ ZEUS v0.9.0 released:\nThe v0.9.0 post outlines additional LSP features,\nwatch-only wallets, hardware signing device support, support for transaction\nbatching including channel open transactions, and other features.\n-\nâ Live Wallet adds consolidation support:\nThe Live Wallet application analyzes the cost to spend a set of UTXOs at\ndifferent feerates including determining when outputs would be\nuneconomical to spend. The 0.7.0 release includes features to simulate consolidation transactions and generate consolidation PSBTs .\n-\nâ Bisq adds Lightning support:\nBisq v2.1.0 adds the ability for users to settle trades using the Lightning Network.\nReleases and release candidates\nNew releases and release candidates for popular Bitcoin infrastructure\nprojects. Please consider upgrading to new releases or helping to test\nrelease candidates.\n-\nâ HWI 3.1.0 is a release of the next version of this package\nproviding a common interface to multiple different hardware signing\ndevices. This release adds support for the Trezor Safe 5 and makes\nseveral other improvements and bug fixes.\n-\nâ Core Lightning 24.08.1 is a maintenance release that fixes crashes\nand other bugs discovered in the recent 24.08 release.\n-\nâ BDK 1.0.0-beta.4 is a release candidate for this library for\nbuilding wallets and other Bitcoin-enabled applications. The original\nbdk Rust crate has been renamed to bdk_wallet and lower layer\nmodules have been extracted into their own crates, including\nbdk_chain , bdk_electrum , bdk_esplora , and bdk_bitcoind_rpc .\nThe bdk_wallet crate âis the first version to offer a stable 1.0.0 API.â\n-\nâ Bitcoin Core 28.0rc2 is a release candidate for the next major\nversion of the predominant full node implementation. A testing\nguide is available.\nNotable code and documentation changes\nNotable recent changes in Bitcoin Core , Core\nLightning , Eclair , LDK ,\nLND , libsecp256k1 , Hardware Wallet\nInterface (HWI) , Rust Bitcoin , BTCPay\nServer , BDK , Bitcoin Improvement\nProposals (BIPs) , Lightning BOLTs ,\nLightning BLIPs , Bitcoin Inquisition , and BINANAs .\nNote: the commits to Bitcoin Core mentioned below apply to its master\ndevelopment branch, so those changes will likely not be released until\nabout six months after the release of the upcoming version 28.\n-\nâ Bitcoin Core #28358 drops the dbcache limit because the previous 16 GB\nlimit was no longer sufficient to complete an Initial Block Download (IBD)\nwithout flushing the UTXO set from RAM to disk, which can\nprovide about a 25% speed up. It was decided to remove the\nlimit rather than raise it because there was no optimal value\nthat would be future-proof and to give users complete flexibility.\n-\nâ Bitcoin Core #30286 optimizes the candidate search algorithm used in\ncluster linearizations, based on the framework laid out in Section 2 of\nthis Delving Bitcoin post , but with some modifications.\nThese optimizations minimize iterations to improve linearization performance,\nbut may increase startup and per-iteration costs. This is part of the cluster\nmempool project. See Newsletter #315 .\n-\nâ Bitcoin Core #30807 changes the signaling of an assumeUTXO node that is syncing the background chain from NODE_NETWORK to\nNODE_NETWORK_LIMITED so that peer nodes donât request blocks older than about a week from it. This\nfixes a bug where a peer would request a historical block and get no response,\ncausing it to disconnect from the assumeUTXO node.\n-\nâ LND #8981 refactors the paymentDescriptor type to only use it within\nthe lnwallet package. This is to later replace paymentDescriptor with a\nnew structure called LogUpdate to simplify how updates are logged and\nhandled, as part of a series of PRs implementing dynamic commitments, a type\nof channel commitment upgrade .\n-\nâ LDK #3140 adds support for paying static BOLT12 invoices\nto send async payments as an always online sender as\ndefined in BOLTs #1149 , but without including the invoice request in the\npayment onion message . Sending as an often offline\nsender or receiving async payments is not yet possible, so the flow cannot yet\nbe tested end-to-end.\n-\nâ LDK #3163 updates the offers message flow by introducing a\nreply_path in BOLT12 invoices. This allows the payer to send the error\nmessage back to the payee in case of an invoice error.\n-\nâ LDK #3010 adds functionality for a node to retry sending an invoice\nrequest to an offer reply path if it hasnât yet received the\ncorresponding invoice. Previously, if an invoice request message on a single\nreply path offer failed due to network disconnection, it wasnât retried.\n-\nâ BDK #1581 introduces changes to the coin selection\nalgorithm by allowing for a customizable fallback algorithm in the\nBranchAndBoundCoinSelection strategy. The signature of the coin_select\nmethod is updated to allow a random number generator to be passed directly to\nthe coin selection algorithm. This PR also includes additional refactorings,\ninternal fallback handling, and simplification of error handling.\n-\nâ BDK #1561 removes the bdk_hwi crate from the project, to simplify\ndependencies and CI. The bdk_hwi crate contained HWISigner , which has now\nbeen moved to the rust_hwi project."}
{"url":"https://docs.getmonero.org/interacting/mining/guides/solo/","domain":"docs.getmonero.org","title":"Mining Monero - Monero Docs","hash":"87cae4ea74b887d0c00cf7876e87d326c703542a00a88cf913fba28620563049","tokens":161,"chars":644,"crawler":"hive-genesis","verified":"unchecked","ts":1791112189383,"text":"Skip to content\nInitializing search\nmonero-project/monero-docs\n- Download & Verify\n-\nMining\n- Pool\n- P2Pool\n- Help\n-\nMonerod\n- Sample Configs\n- Wallets\n- Blockchain Tools\n- External\n- RPC Library\n-\nR&D\n-\nCryptography\n- Base58\n- Keccak-256\n- PRNG\n-\nMnemonics\n-\nProof of Work\n- Wallet Files\nSolo Mining Monero ¶\nThere are multiple ways to solo mine Monero.\n- Monero GUI / CLI\n- XMRig\nMonero GUI and Monero CLI both use the monerod's (node) built in miner and is generally easier to use. GUI/CLI has no fees.\nXMRig is an external miner. It is open source and mines with greater efficiency than monerod's built-in miner. XMRig has a fee of 1%."}
{"url":"https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739","domain":"gov.optimism.io","title":"Upgrade Proposal #13: OPCM and Incident Response improvements - Protocol Upgrade - Optimism Collective","hash":"1d0b4cfee3ced4336644ef4df9fb1007ee094a9de96e731813c075721e4b49d8","tokens":5988,"chars":23951,"crawler":"crawler-v8wo","verified":"exact","ts":1791112190419,"text":"Optimism Collective\nUpgrade Proposal #13: OPCM and Incident Response improvements\nProposals đ\nProtocol Upgrade\nmaurelian\nMarch 7, 2025, 9:49pm\n1\nExecutive Summary\nHi Iâm Maurelian, a Security Engineer at OP Labs. This proposal was written in collaboration with Lewej ( @0xEscanor ) and @Kelvin from the OP Labs Team.\nThis proposal is intended to be voted on in cycle 34.\nNeither OP Labs nor I represent or speak on behalf of the Optimism Foundation.\nThis proposal:\n- outlines the implementation of a new system for upgrading L1 contracts across the Superchain (OP Contracts Manager),\n- introduces technical improvements to several key contracts to enable more flexible and less disruptive ways to respond to any potential incidents in the OP Stack fault proof system (Fault Proofs Incident Response Improvements), and\n- introduces a new Safe Module called the DeputyPauseModule to be installed into the Optimism Foundation Safe to simplify the process of quickly responding to security incidents via the Superchain-wide pause mechanism (Superchain Pause Improvements).\nImpacted Stakeholders & Expected Outcomes\n- Optimism Foundation : Simplified process for triggering Superchain-wide pause quickly in case of an emergency.\n- Security Council: introduces a method to perform âbatchedâ upgrades to multiple chains at once\nMotivation\nThe goal of this upgrade is to implement the above changes to 1) make contract upgrades more scalable, less prone to error, and easier to test the fully upgrade system with OP Contracts Manager, 2) simplify the process of responding to fault proofs related incidents, and 3) improve the process of triggering the Superchain-wide âpauseâ functionality without changing any existing security properties.\nSpecifications\nThe major features in this upgrade were previewed in mini-posts to encourage earlier community discussion. Links to each discussion are attached in the relevant section.\nBlockspace Charter\n- Current Blockspace Charter proposed to be upgraded under this proposal\n- OPerating-manual/Standard Rollup Charter.md at e1b305a96a0b60515cc1111a26e73e1973d9c34e · ethereum-optimism/OPerating-manual · GitHub\n- PR specifying the upgraded Blockspace Charter\n- Update standard rollup charter for Upgrade 13 by mslipper · Pull Request #46 · ethereum-optimism/OPerating-manual · GitHub\nTechnical Details\nOP Contracts Manager and Maintenance Changes\nThis proposal was previewed here .\n-\nThe specific protocol changes included in this proposal are:\n- OP Contracts Manager (OPCM): Each release will have its own OPCM that can deploy new proxies and upgrade existing OP Chains. It is important to note that the OP Contracts Manager is not considered to be part of the protocol; it has no special role, and no contracts reference it. It is more like an on-chain script for orchestrating deployments and upgrades.\n- In-protocol Contract Modifications : The changes to the L1 contracts covered by this proposal are relatively minor. They help to improve our engineering process, but do not affect governance approved features and functionality:\n- Stack too deep fixes in three PRs: 1 , 2 , 3 . These changes enable us to generate code coverage measurements.\n- Contracts have been updated to call interfaces for external interactions rather than implementations ( example PR ). This greatly reduces the compilation time and speeds up our development process.\n- Removal of CustomGasToken logic in two PRs: 1, 2 . The CustomGasToken functionality had not been governance approved nor deployed, but was included in the contracts in the monorepo before the decision was made to remove it.\n- Changes to deposit transaction aliasing ( PR ): This change ensures that addresses which are currently aliased in a deposit will still be aliased after the L1 Pectra upgradeâs introduction of EIP-7702.\nAll of the changes above have been audited.\nMinor fixes resulting from that audit are finalized and reflected in the report .\nFault Proofs Incident Response Improvements\nThis proposal was previewed here .\nDelayedWETH\n- DelayedWETH.hold(...) (callable only by the Phase 0 Security Council Account ) now executes an approval and transfer from the target account to the owner account instead of simply executing an approval.\n- We provide a version of DelayedWETH.hold(...) that does not require the owner to specify the targetâs balance. These changes significantly reduce the complexity of the runbook for executing a DelayedWETH.hold(...) action.\nOptimismPortal\n- OptimsimPortal.setRespectedGameType(...) (callable only by the Guardian ) no longer sets the respected game type and the retirement timestamp at the same time. We provide a special reserved input value ( type(uint32).max ) that can be used to set the retirement timestamp.\n- OptimismPortal.checkWithdrawal(...) now asserts that a FaultDisputeGame was the respected game type at the time of creation rather than asserting that the game is currently the respected game type.\n- Combined, these two changes mean that changing the respected game type no longer automatically invalidates all existing withdrawals while maintaining the option to invalidate withdrawals if necessary.\nAnchorStateRegistry\n- AnchorStateRegistry.tryUpdateAnchorState(...) is removed and the AnchorStateRegistry.setAnchorState(...) function is repurposed as the primary way for FaultDisputeGame contracts to attempt to update the anchor state.\n- The AnchorStateRegistry âs internal anchor state is now unified across all game types instead of storing a different state per game type. AnchorStateRegistry.setAnchorState(...) now verifies that the game is fully finalized and only allows the respected game type (as defined in the OptimismPortal ) to update the anchor state.\n- Changes to the AnchorStateRegistry in total mean that the anchor state cannot become âpoisonedâ in a way that the state recognized by the AnchorStateRegistry is not recognized by the OptimismPortal .\n- Additionally, the AnchorStateRegistry is updated so that all OP Stack chains can share a common AnchorStateRegistry implementation.\nFaultDisputeGame\n- The FaultDisputeGame is modified to support the concept of âbond refundingâ whereby bonds are automatically distributed back to their original depositors if the game is invalidated either by the retirement timestamp or the blacklisting mechanism. This reduces the need to actively step in to redistribute bonds if necessary.\nSupporting Documentation\n- Specification: Common anchor state for all dispute game types\n- Specification: AnchorStateRegistry incident response changes\n- Specification: OptimismPortal incident response changes\n- Specification: FaultDisputeGame incident response changes\n- Specification: DelayedWETH incident response changes\nAudit Reports and Findings\nOffbeat Labs\nOffbeat Labs completed an audit of this code and found 1 Low Severity issue which has been addressed.\nSpearbit\nSpearbit completed an audit of this code, but the report is not finalized as of the publication of this post. Spearbit found 1 Medium Severity and 2 Low Severity issue.\nThe Medium Severity issue did not represent any safety risk - a deliberate design decision was found to conflict with the updated L2Beat Stage 1 requirements that were published at the end of January 2025, after the component was designed. We are updating our design process going forward to take these new L2Beat Stage 1 requirements into account. We have since modified the design of the component to satisfy the updated L2Beat requirements.\nDeputyPauseModule (Superchain Pause Improvements)\nThis proposal was previewed here .\nDeputyPauseModule\n- The DeputyPauseModule is a new Safe Module that we are proposing to install into the Optimism Foundation Safe. The DeputyPauseModule allows the Optimism Foundation to assign a âPause Deputyâ private key that can be used to create signatures that authorize the use of the Superchain-wide pause.\n- The DeputyPauseModule allows the Pause Deputy private key to cause the Optimism Foundation Safe to execute a call to the DeputyGuardianModule account ONLY for the purpose of executing the pause function. The Pause Deputy has no other capabilities.\nSupporting Documentation\n- Specification: DeputyPauseModule\nAudit Reports and Findings\nRadiant Labs\n- Report\n- Low/informational findings only, all addressed\nMiloTruck (independent)\n- Report\n- Low/informational findings only, all addressed\nImpact Summaries\nOP Contracts Manager\nThe adoption of this proposal will improve the safety and reliability of upgrades. This should in-turn enable smaller and more frequent upgrade to occur, thus increasing the speed of iteration and improvement.\nFault Proofs Incident Response Improvements\nIMPORTANT: If adopted and deployed, this proposal will cause a one-time invalidation of all pending withdrawal proofs created on L1. Users would be notified ahead of time to complete any pending withdrawals before the upgrade is executed and to avoid creating new withdrawal proofs that would not become executable in time. This aspect of the proposal does not place any ETH or ERC-20 tokens at risk and would simply require the user to submit a second withdrawal proof transaction on L1 in the worst case. This type of invalidation has already occurred in previous upgrades (e.g., when fault proofs were first introduced).\nDeputyPauseModule (Superchain Pause Improvements)\n- Adopting this proposal will significantly improve the Optimism Foundationâs ability to quickly respond to incidents while simultaneously eliminating a major source of overhead during the upgrade process (re-signing many pre-signed pause transactions).\n- The Optimism Foundation Safe is expected to rotate the Pause Deputy private key on a regular basis (approximately every 3 months).\n- Usage of a private key in place of the existing âpre-signedâ pause transactions does not change the existing security model. In either case, the Optimism Foundation retains access to secret material that can quickly trigger the Superchain-wide pause in case of an emergency.\nCorresponding to this change, PR#46 adds a new Governing Policy for the Deputy Pause Module to the Standard Rollup Charter.\nPrecommitment Impact Review\nThis Upgrade Proposal does not impact any of the precommitments in the Standard Rollup Charter.\n- Collective Fee Take: no modification or onchain implementation introduced.\n- Governor/Servicer Role Separation: no change to role structures or authorization patterns.\n- Ossified GasLimits: no changes to ossified gasLimits\n- Direct Fee Margin Controls: no change to the relevant configuration structure and authorization. Some helper methods for get/set logic are added to the SystemConfig, but do not fulfill the overall intent of this precommittment.\nAction Plan\nIf this proposal is accepted, the upgrade is expected to take place on April 7, 2025. In that case, mulitisig ceremonies will be coordinate such that the following transactions will be executed.\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, Soneium and Ink\n0x82ad56cb000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000026b2f158255beac46c1e7c6b8bbf29a4b6a7b76000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000164ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000003000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb290000000000000000000000000543ba4aadbab8f9025686bd03993043599c6fb04039facea52b20c605c05efb0a33560a92de7074218998f75bcdf61e8989cb5d90000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000089889b569c3a505f3640ee1bd0ac1d557f436d2a039facea52b20c605c05efb0a33560a92de7074218998f75bcdf61e8989cb5d900000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e8364000000000000000000000000d56045e68956fce2576e680c95a4750cf8241f79039facea52b20c605c05efb0a33560a92de7074218998f75bcdf61e8989cb5d900000000000000000000000000000000000000000000000000000000\n-\nTo upgrade Base\n0x82ad56cb000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000026b2f158255beac46c1e7c6b8bbf29a4b6a7b760000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a10000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000073a79fab69143498ed3712e519a88a918e1f40720000000000000000000000000475cbcaebd9ce8afa5025828d5b98dfb67e059e039facea52b20c605c05efb0a33560a92de7074218998f75bcdf61e8989cb5d900000000000000000000000000000000000000000000000000000000\n-\nTo upgrade Unichain\n0x82ad56cb000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000026b2f158255beac46c1e7c6b8bbf29a4b6a7b760000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda60000000000000000000000003b73fa8d82f511a3cae17b5a26e4e1a2d5e2f2a4039facea52b20c605c05efb0a33560a92de7074218998f75bcdf61e8989cb5d900000000000000000000000000000000000000000000000000000000\nAs this is a L1 contracts-only upgrade, no action is required by node operators.\nTo prepare infra and the community for withdrawal flow changes, we will be rolling out mainnet messaging starting next week.\nCommunication will include:\n- Comms : At least two rounds of public messaging on OP social channels notifying users of the changes to withdrawal flow, and of the impact on withdrawals during the upgrade window.\n- Contributors: Coordinate with bridge infra contributors, including maintainers of popular frontends to the standard bridge, to post banners notifying users of the changes.\n- Support : Prep developer support team for inbound support tickets about transactions that need to be reproven due to not finishing the first proof in time before the changes.\n- Bridges: Notify bridges and other infra contributors whose operations might be impacted due to the withdrawal flow changes.\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.\nEmergency Cancellation\nThe optimistic mainnet releases will be activated on the above mentioned date. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation.\nConclusion\nThis proposal outlines more robust incident response processes and technical improvements to contracts and their management. This network upgrade provides simplified processes, allows smaller and more frequent upgrades to occur, and enables more flexible and less disruptive ways to respond to potential incidents in the OP Stack fault proof system. We hope to gain your support for the implementation of these changes.\n13 Likes\nJoint House Community Calls Summaries - Season 7\nVoting Cycle Guide #34\nJoint House Community Calls Summaries - Season 7\nVoting Cycle Roundup #34\nToken House Call [March 11th 19:00 UTC]\nVoting Cycle Guide #35\nAlexSotoDigital.eth - Delegate Communication Thread\nMegalod Delegate Communication Thread\nVoting Cycle Roundup #34\nShe256 - Delegate Communication Thread\nSEEDGov - Delegate Communication Thread\nAn update to OP Labs recommendation for signing OPCM upgrade transactions\nGonna.eth\nMarch 10, 2025, 2:47pm\n2\nItâs clear that OP Labs and the Security Council will collaborate on emergency cancellation if needed, but it would be good to explicitly define who makes the final decision (Optimism Foundation, Security Council, or both?).\nWhile the proposal clarifies most of the technical side, some governance-related question on this (probably not for you maurelian):\n- Process :\n- Will there be public confirmation/logging of key rotations?\n- Is there a designated team within the Foundation responsible for managing this process?\n- External delegation :\n- If OP Labs or another entity gets access to the Pause Deputy key, how will responsibilities be defined?\n- Will the Security Council have visibility over these decisions?\nHow much time users have to react before the upgrade?\nThese are all minor questions and Iâm fully supportive of this proposal.\n6 Likes\nSEEDGov\nMarch 10, 2025, 8:59pm\n3\nThe SEEDGov delegation, as we have communicated here , being an Optimism delegation with sufficient voting power, we believe this proposal is ready to move towards a vote.\n2 Likes\nmastermojo\nMarch 11, 2025, 2:02am\n4\nI am an Optimism Top 100 delegate [ Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote\n1 Like\nMarcus01\nMarch 11, 2025, 6:32am\n5\nI am an optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.\n1 Like\nbrichis\nMarch 11, 2025, 4:54pm\n7\nGM @maurelian ! This link seems broken:\nScreenshot 2025-03-11 at 10.53.31 a.m. 1654Ă564 38 KB\nWorld_Foundation\nMarch 11, 2025, 5:27pm\n8\nThe World Foundation delegation, in its capacity as an Optimism delegate with sufficient voting power, believes this proposal is ready to move to a vote.\nnanobro\nMarch 11, 2025, 5:32pm\n9\nI am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.\nkelvin\nMarch 11, 2025, 11:57pm\n10\nCorrected link is here: optimism/docs/security-reviews/2024_12-DPM-RadiantLabs.pdf at develop · ethereum-optimism/optimism · GitHub\nSorry about that!\n1 Like\njengajojo\nMarch 12, 2025, 2:50pm\n11\nI am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.\nMoneyManDoug\nMarch 12, 2025, 5:56pm\n12\nI am an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.\nben-chain\nMarch 12, 2025, 6:19pm\n13\nEmergency Cancellation\nThe optimistic mainnet releases will be activated on the above mentioned date. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation.\nItâs clear that OP Labs and the Security Council will collaborate on emergency cancellation if needed, but it would be good to explicitly define who makes the final decision (Optimism Foundation, Security Council, or both?).\nThe Optimism Foundation and Security Council together are the final decision-makers, as they are both blocking signers on the 2/2 L1ProxyAdminOwner.\nProcess :\nWill there be public confirmation/logging of key rotations?\nBecause key rotations are an onchain action, they are naturally logged.\nIs there a designated team within the Foundation responsible for managing this process?\nIf OP Labs or another entity gets access to the Pause Deputy key, how will responsibilities be defined?\nWill the Security Council have visibility over these decisions?\nThe Optimism Foundationâs leadership team is responsible for managing this process, with specific incidence response playbooks delegated to the OP Labs security team. The Security Council will be informed of these decisions, though the current playbooks prioritize taking immediate action to favor safety over liveness, so this information/decision will not come in real time.\n2 Likes\nwildmolasses\nMarch 14, 2025, 6:52pm\n14\nThe DAB assessed this proposal and happily recommends its approval.\n3 Likes\nSEEDGov\nMarch 17, 2025, 1:35pm\n15\nCould someone from OP Labs confirm if this is the correct report mentioned as made by Offbeat Labs? Thanks\nGoBOB\nMarch 17, 2025, 3:16pm\n16\nHi, BOB team here, we are one of the top 100 delegators.\nIn response to this proposal we are happy with the OPCM + Fault proof response improvement, however can you shed some light on the âDeputyPauseModuleâ?\nSpecifically,\n- Definition of the âpauseâ mean in the Superchain context? Does it halt all rollups or just pausing withdrawals?\n- What criteria trigger a pause (e.g., % of funds lost)?\n- How is it unpaused, and how does the Security Council work with chains to restore state?\nThank you\n2 Likes\nmaurelian\nMarch 17, 2025, 4:30pm\n17\nYes, that is correct.\n1 Like\nmaurelian\nMarch 17, 2025, 4:36pm\n18\nIt currently pauses withdrawals for all chains in the superchain, although there exist plans to make this more granular so that subsets of chains can be paused.\nThe pause will be preemptively, when a bug is identified which puts user funds at risk necessitating an upgrade.\nIt is unpaused by the security council can call the unpause() function on the SuperchainConfig contract.\nIâm not sure about the meaning of ârestore stateâ, but my understanding is that the Security Council would work with affected chains to ensure that it is safe to reactivate withdrawals prior to unpausing.\n1 Like\nGoBOB\nMarch 18, 2025, 9:04am\n19\nAppreciate the feedback Maurelian, We have some followup questions:\n-\nDo you have more granular guidelines or criteria of when they will pause all withdrawals?\nSo for example, is a $1k or a $1mm hack? Or is the pause only triggered when they identify a bug in the OP stack code? To me, itâs not entirely clear what class of bugs in terms of likelihood of exploitation, impact and scope would warrant a pause.\n-\nOn restoring state: this would come into play if the security council pauses withdrawals due to an issue at with an oracle provider. Letâs say an oracle provider and a DeFi protocol loose tons of user funds due to a hack or misconfiguration. The chain in question wants to hard fork and roll back their state to before the hack. How would the security council act?\nThank you\n4 Likes\nBOB - Delegate Communication Thread\nSinkas\nMarch 19, 2025, 3:57pm\n20\nThe following reflects the views of L2BEATâs governance team, composed of @kaereste and @Sinkas . Itâs based on their combined research, fact-checking, and ideation.\nWe voted FOR the proposal.\nThe new emergency procedure outlined in the proposal aligns with our Stage 1 requirements, so we donât see a reason to be against it. Our research team reviewed the OP Contracts Manager to make sure the contracts were set up as intended and found no issues.\n3 Likes\nL2BEAT - Delegate Communication Thread\nLobbyFi\nMarch 20, 2025, 7:44pm\n21\nLobbyFi voted FOR since there was one lobbyist who bid for FOR option. His bid exceeded the threshold, which is at 10% of the instant buy which has been chosen for this proposal.\nRelated topics\nTopic\nReplies\nViews\nActivity\nUpgrade Proposal #4\nProtocol Upgrade\nseason-5\n,\ncycle-18\n24\n4217\nFebruary 14, 2024\n[FINAL] Protocol Upgrade #7: Fault Proofs\nProtocol Upgrade\n44\n6239\nJune 5, 2024\n[FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization\nProtocol Upgrade\n26\n2497\nMay 29, 2024\nUpgrade Proposal #10: Granite Network Upgrade\nProtocol Upgrade\n30\n5315\nAugust 31, 2024\n[FINAL] Upgrade #1: Bedrock Protocol Upgrade - v2\nProtocol Upgrade\n20\n14257\nApril 4, 2023"}
{"url":"https://forum.skyeco.com/c/spark-prime/84","domain":"forum.skyeco.com","title":"Latest Spark Prime topics - Sky Forum","hash":"d72b1ef0e0af4cb87f86f6274eca7a6b34a93a81cc109b6ab679288a4f5c3eb8","tokens":878,"chars":3510,"crawler":"hive-genesis","verified":"exact","ts":1791112190962,"text":"Sky Forum\nSpark Prime\nSpark Tokenization Grand Prix\nThis subforum will be dedicated to the Spark Tokenization Grand Prix. All information and updates regarding the competition will be posted here.\nTopic\nReplies\nViews\nActivity\nAbout the Spark Prime category\nSpark Prime\n0\n1630\nApril 28, 2023\n[October 8, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\narbitrum\n,\ncctp\n,\nspark-savings\n,\nx-layer\n6\n198\nOctober 3, 2026\nConfirming interest rate mechanism scope across SparkLend Ethereum reserves\nSpark Prime\n0\n18\nOctober 2, 2026\nRemi's Spark Delegate Communications\nSpark Prime\ngovernance\n26\n596\nOctober 1, 2026\nOutdated Social Media Links\nSpark Prime\n1\n45\nSeptember 23, 2026\nNeoNodeâs Spark Delegate Communications\nSpark Prime\ngovernance\n53\n773\nSeptember 16, 2026\nSAEP-22: Update Risk Curation Framework\nSpark Prime\nmorpho\n3\n103\nSeptember 14, 2026\nTechnical Scope: Sentora x Spark RLUSD Force-Deallocate Penalty Update\nSpark Prime\nrlusd\n,\nmorpho\n,\nsentora\n3\n121\nSeptember 14, 2026\nSAEP-23: Update SubDAO Proxy Management Artifact Section\nSpark Prime\n3\n98\nSeptember 14, 2026\nSAEP-21: Update Delegate Compensation\nSpark Prime\nspk-delegates\n3\n91\nSeptember 14, 2026\n[September 24, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\n1\n110\nSeptember 14, 2026\n[September 10, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\nsparklend\n,\nrlusd\n,\ngnosis\n,\nlbtc\n,\nmorpho\n8\n433\nSeptember 7, 2026\nSAEP-20: Update Risk Curation Framework Artifact Section\nSpark Prime\nmorpho\n2\n71\nSeptember 7, 2026\nSpark, August 2026: Deposits up 10.9%, Net Revenue down 26.0%, Liquidity Layer spread at 6 bps\nSpark Prime\n0\n54\nSeptember 2, 2026\nNotice of Planned Deprecation: Avalanche Spark Savings USDC (spUSDC)\nSpark Prime\navalanche\n,\ndeprecation\n,\nspusdc\n0\n59\nAugust 31, 2026\n[August 27, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\nsparklend\n,\nrlusd\n,\nusdg\n,\nspark-liquidity-layer\n7\n268\nAugust 21, 2026\nNotice of Planned Deprecation: SparkLend on Gnosis Chain\nSpark Prime\nsparklend\n,\ngnosis\n,\ncollateral-offboard\n,\ndeprecation\n0\n71\nAugust 18, 2026\nSAEP-19: Remove the Spark Risk Council\nSpark Prime\nspark-risk-council\n3\n218\nAugust 17, 2026\n[August 13, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\nusdg\n,\nuniswap\n,\ncurve\n,\nuniswap-v4\n,\nrlusd\n8\n316\nAugust 5, 2026\nDiscussion: Add UNI as collateral on SparkLend?\nSpark Prime\n1\n99\nAugust 3, 2026\nSpark SubDAO Proxy Management Updates\nSpark Prime\n5\n574\nAugust 3, 2026\nSAEP-18: Update SLL Freezer Multisig\nSpark Prime\nspark-liquidity-layer\n3\n114\nJuly 20, 2026\nSAEP-17: Update Spark Savings Artifact Section\nSpark Prime\nspark-savings\n3\n112\nJuly 20, 2026\n[July 16, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\n6\n386\nJuly 14, 2026\n[June 19, 2026] Spark USDT Morpho V2 Vault Allocator Updates\nSpark Prime\nmorpho\n4\n150\nJuly 6, 2026\n[July 2, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\nsparklend\n,\navalanche\n,\noptimism\n,\narbitrum\n,\nunichain\n,\nspark-savings\n,\nbase\n,\nlayer-zero\n5\n285\nJuly 6, 2026\nTechnical Scope: Spark Savings USDG (spUSDG) Deployment on Robinhood Chain\nSpark Prime\nspark-liquidity-layer\n,\nmorpho\n,\nspark-savings\n,\npaxos\n,\nusdg\n,\nrobinhood-chain\n0\n94\nJuly 6, 2026\nSpark Delegate Re-Approval - Term Beginning July 1, 2026\nSpark Prime\n0\n56\nJune 29, 2026\nSAEP-16: Confidential Strategic Integrations and Deployments\nSpark Prime\nmorpho\n,\nspark-savings\n4\n122\nJune 22, 2026\n[June 18, 2026] Proposed Changes to Spark for Upcoming Spell\nSpark Prime\n5\n247\nJune 18, 2026\nnext page â"}
{"url":"https://docs.getmonero.org/cryptography/base58/","domain":"docs.getmonero.org","title":"Base58 - Monero Docs","hash":"2b458d4da01a64b1677507bbd3a41ab73784b83bd2f87aaa95190fa0d6caa6a3","tokens":369,"chars":1474,"crawler":"hive-genesis","verified":"exact","ts":1791112252927,"text":"Skip to content\nInitializing search\nmonero-project/monero-docs\n- Download & Verify\n-\nMining\n- Pool\n- P2Pool\n- Help\n-\nMonerod\n- Sample Configs\n- Wallets\n- Blockchain Tools\n- External\n- RPC Library\n-\nR&D\n-\nCryptography\n- Base58 Base58\n- Keccak-256\n- PRNG\n-\nMnemonics\n-\nProof of Work\n- Wallet Files\nBase58 ¶\nBase58 is a binary-to-text encoding scheme. It is similar to Base64 but has been modified to avoid both non-alphanumeric characters and letters which might look ambiguous when printed. The characters excluded in relation to Base64 are: IOl0+/\nBase58 does not strictly specify the format. This results in some implementations being incompatible with others, for example with regard to alphabet order.\nFor details, see Wikipedia .\nBase58 in Monero ¶\nMonero has its own variant of Base58.\nIn Monero the Base58 encoding is performed in 8-byte blocks, except the last block which is the remaining (8 or less) bytes.\nThe 8-byte block converts to 11 or less Base58 characters. If the block converted to less than 11 characters, the output is padded with \"1\"s (0 in Base58). The final block is padded as well to whatever would be the maximum size of this number of bytes encoded in Base58.\nThe advantage of Monero implementation is that output is of a fixed size which is not the case with plain Base58. The disadvantage is that default libraries won't work.\nFor details, see the reference C++ Base58 implementation and the unofficial Python and Rust implementations."}
{"url":"https://docs.ton.org/tolk/idioms-conventions","domain":"docs.ton.org","title":"Idioms and conventions","hash":"43877831b863193396642a45322c95bf710e1922769fc361b30886b28b654dd7","tokens":3660,"chars":14638,"crawler":"crawler-tpoe","verified":"exact","ts":1791112254304,"text":"Onboarding Nodes Applications APIs Contracts Smart contracts Tolk Tolk language TVM TON Virtual Machine Foundations Blockchain foundations\nIdioms and conventions\nAfter learning of basic syntax , study the common patterns, conventions, and best practices to write idiomatic Tolk code.\nDeclare each contract with a contract directive\nPlace a contract declaration at the top of every entrypoint file. It names the contract and lists its public shapes â at minimum, the storage struct and the union of accepted incoming messages. The compiler uses this information to emit a machine-readable ABI, which in turn powers TypeScript wrappers, explorers, the step-by-step debugger, and other client-side tooling.\ncontract JettonWallet {\nstorage: WalletStorage\nincomingMessages: WalletMessages\n}\nUse the contract's PascalCase name as the file name: JettonWallet.tolk , JettonMinter.tolk . All get fun and entrypoints must live in the same file as the contract declaration.\nPrefer automatic serialization to manual one\nManual work with slices and builders is error-prone and tedious. By comparison, auto-serialization with structures helps express data with types and prevents many related bugs.\nstruct Holder {\nowner: address\nlastUpdated: uint32\nextra: Cell < ExtraInfo >\n}\nfun demo (data: Holder ) {\n// make a cell with 299 bits and 1 ref\nval c = data. toCell ();\n// unpack it back\nval holder = Holder . fromCell (c);\n}\nPrefer typed cells with Cell\nAll data in TON is stored in cells. To express data relation clearly and to aid in serialization , use cells with well-typed contents: Cell .\nstruct Holder {\n// ...\nextra: Cell < ExtraInfo >\n}\nstruct ExtraInfo {\nsomeField: int8\n// ...\n}\nfun getDeepData (value: Holder ) {\n// `value.extra` is a reference\n// use `load()` to access its contents\nval data = value.extra. load ();\nreturn data.someField;\n}\nUse lazy data loading\nWhen reading data from cells, add the lazy keyword :\n- lazy SomeStruct.fromCell(c) over SomeStruct.fromCell(c)\n- lazy typedCell.load() over typedCell.load()\nWith lazy , the compiler loads only the requested fields, skipping the rest. This reduces gas consumption and bytecode size:\nget fun publicKey () {\nval st = lazy Storage . load ();\n// <-- here, \"skip 65 bits, preload uint256\" is inserted\nreturn st.publicKey\n}\nUse type aliases to express custom serialization logic\nSerialization may require custom rules which are not covered by existing types. Tolk allows defining custom serialization rules for type aliases :\n// The custom type alias over a regular, untyped slice\ntype MyString = slice\n// The function that is called when composing a new cell with a builder\nfun MyString . packToBuilder ( self , mutate b: builder ) {\n// ...custom logic for MyString serialization\n}\n// The function that is called when loading data from the cell with a slice\nfun MyString . unpackFromSlice ( mutate s: slice ) {\n// ...custom logic for MyString deserialization\n}\n// With those two functions implemented, MyString becomes\n// a type with clear serialization rules and can be used anywhere\nstruct Everywhere {\ntokenName: MyString\nfullDomain: Cell < MyString >\n}\nConsider a structure that holds a signature hash of the data in its tail:\nstruct SignedRequest {\nsignature: uint256\n// hash of all data below is signed\nfield1: int32\nfield2: address ?\n// ...\n}\nThe task is to parse the structure and check the signature of the fields below signature against it. A manual approach would be to read uint256 , calculate the hash of the remaining slice, then read other fields and compare the signatures.\nHowever, a better solution is to continue using auto-serialization by introducing a synthetic field populated only when loading a slice and never when composing a cell with a builder:\ntype HashOfRemainder = uint256\nstruct SignedRequest {\nsignature: uint256\nrestHash: HashOfRemainder // populated on load\nfield1: int32\nfield2: address ?\n// ...\n}\nfun HashOfRemainder . unpackFromSlice ( mutate s: slice ) {\n// In this case, `s` is a slice remainder after loading `signature`,\n// while the `restHash` field has to contain the hash of that remainder:\nreturn s. hash ()\n}\n// Now, assert that signatures match\nfun demo (input: slice ) {\nval req = SignedRequest . fromSlice (input);\nassert (req.signature == req.restHash) throw XXX ;\n}\nUse contract storage as a structure\nContract storage is a regular struct , serialized into persistent on-chain data.\nAdd load and store methods for convenience:\nstruct Storage {\ncounterValue: int64\n}\nfun Storage . load () {\nreturn Storage . fromCell (contract. getData ())\n}\nfun Storage . save ( self ) {\ncontract. setData ( self . toCell ())\n}\nExpress messages as structs with 32-bit prefixes\nBy convention, every message in TON has an opcode : a unique 32-bit number. In Tolk, every struct can have a serialization prefix of arbitrary length. Use 32-bit prefixes to express message opcodes.\nstruct ( 0x12345678 ) CounterIncrement {\n// ...message body fields...\n}\nWhen implementing Jettons , NFTs , or other standard contracts, use predefined opcodes according to the specification. Otherwise, opcodes are ad hoc.\nUse unions to handle incoming messages\nThe suggested pattern:\n- Each incoming message is made a struct with an opcode.\n- Structs are combined into a union type.\n- Union is used to lazily load data from the message body slice.\n- Finally, result is pattern matched over union variants.\nstruct ( 0x12345678 ) CounterIncrement {\nincBy: uint32\n}\nstruct ( 0x23456789 ) CounterReset {\ninitialValue: int64\n}\ntype AllowedMessage = CounterIncrement | CounterReset\ncontract Counter {\nstorage: Storage\nincomingMessages: AllowedMessage\n}\nfun onInternalMessage (in: InMessage ) {\nval msg = lazy AllowedMessage . fromSlice (in.body);\nmatch (msg) {\nCounterIncrement => {\n// use `msg.incBy`\n}\nCounterReset => {\n// use `msg.initialValue`\n}\nelse => {\n// invalid input; a typical reaction is:\n// ignore empty messages, \"wrong opcode\" if not\nassert (in.body. isEmpty ()) throw 0xFFFF\n}\nThe lazy keyword works with unions and performs a lazy match by the slice prefix: a message opcode. This approach is more efficient than manual opcode parsing and branching via a series of if (op == TRANSFER_OP) statements.\nUse structs to send messages\nTo send a message from contract A to contract B:\n- Declare a struct with an opcode and fields expected by the receiver.\n- Use the createMessage() function to compose a message, and the send() method to send it.\nstruct ( 0x98765432 ) RequestedInfo {\n// ...\n}\nfun respond ( /* ... */ ) {\nval reply = createMessage ({\nbounce: BounceMode . NoBounce ,\nvalue: grams ( \"0.05\" ),\ndest: addressOfB,\nbody: RequestedInfo {\n// ... initialize fields\n}\n});\nreply. send ( SEND_MODE_REGULAR );\n}\nWhen both contracts share the same codebase, a struct serves as an outgoing message for A and an incoming message for B.\nAttach initial code and data to a message to deploy another contract\nContract deployment is performed by attaching the code and data of the future contract to a message sent to its soon-to-be-initialized address. That address is deterministically calculated from the attached code and data.\nA common case is when the jetton minter contract deploys a jetton wallet contract per user, knowing the future wallet's initial state: code and data.\nval msgThatDeploys = createMessage ({\n// address auto-calculated, code+data auto-attached\ndest: {\n// initial state\nstateInit: {\ncode: jettonWalletCode,\ndata: emptyWalletStorage. toCell (),\n}\n});\nSince one cannot synchronously check whether a contract is already deployed, the standard approach is always to attach the initial state needed for deployment whenever the contract's logic requires it.\nTo calculate or validate resulting addresses in addition to sending messages to them, always extract the StateInit generation to a separate function:\nfun calcDeployedJettonWallet ( /* ... */ ): AutoDeployAddress {\nval emptyWalletStorage: WalletStorage = {\n// ... initialize fields from parameters\n};\nreturn {\nstateInit: {\ncode: jettonWalletCode,\ndata: emptyWalletStorage. toCell ()\n}\nfun demoDeploy () {\nval deployMsg = createMessage ({\n// address auto-calculated, code+data auto-attached\ndest: calcDeployedJettonWallet (...),\n// ...\n});\ndeployMsg. send (mode);\n}\nSee the Tolk contract examples page for selected contracts from the tolk-bench .\nTarget certain shards when deploying sibling contracts\nSpecify the prefix length and the contract address to aim for the same shard . For example, sharded jetton wallet must be deployed to the same shard as the owner's wallet.\nval deployMsg = createMessage ({\ndest: {\nstateInit: { code, data },\ntoShard: {\ncloseTo: ownerAddress,\nfixedPrefixLength: 8\n}\n});\nEmit events and logs to off-chain world during development\nExternal messages with a special address none are used to emit events and logs to the outer world. Indexers catch such messages and provide a picture of on-chain activity.\nExternal messages cost less gas than internal ones and help track events during contract development. They provide a simple way to emit structured logs that indexers and debugging tools can consume.\nTo send an external log message:\n- Create a struct to represent the message body.\n- Use createExternalLogMessage() to compose a message and the send() method to send it.\nstruct DepositEvent {\n// ...fields...\n}\nfun demo () {\nval emitMsg = createExternalLogMessage ({\ndest: createAddressNone (),\nbody: DepositEvent {\n// ...field values...\n}\n});\nemitMsg. send ( SEND_MODE_REGULAR );\n}\nReturn several state values as a structure from a get method\nWhen a contract getter needs to return several values, introduce a structure. Avoid returning unnamed tensors like (int, int, int) . Field names provide clear metadata for client wrappers and human readers.\nstruct JettonWalletDataReply {\njettonBalance: coins\nownerAddress: address\nminterAddress: address\njettonWalletCode: cell\n}\nget fun get_wallet_data (): JettonWalletDataReply {\nreturn {\njettonBalance: ...,\nownerAddress: ...,\nminterAddress: ...,\njettonWalletCode: ..,\n}\nValidate user input with assertions\nAfter parsing an incoming message, validate required fields with assert :\nassert (msg.seqno == storage.seqno) throw E_INVALID_SEQNO ;\nassert (msg.validUntil > blockchain. now ()) throw E_EXPIRED ;\nIf a condition is violated, execution terminates with the specified error code. Otherwise, a contract remains ready to serve the next request. This is the standard mechanism for reacting to invalid input.\nOrganize a project into several files\nConsistent file structure across projects simplifies navigation:\n- Supply errors.tolk with constants or enums.\n- Supply storage.tolk with storage and helper methods.\n- Supply messages.tolk with incoming and outgoing messages.\n- Have MyContract.tolk as an entrypoint, named after the contract in PascalCase. Place a contract declaration at the top of the file and keep all get fun and entrypoint functions within it; use imports to bring in shared code.\nWhen developing several related contracts simultaneously, keep them in the same codebase. A contract file can import another contract â its types are exposed to the importer, while its onInternalMessage and get fun stay private to the original contract. For instance, struct SomeMessage outgoing for contract A can be incoming for contract B; or contract A may need to know B's storage to compute the deploy address.\nPrefer methods to functions\nAll symbols across different files share the same namespace and must have unique names project-wide. There are no modules or exports.\nUse methods to avoid name collisions:\nfun Struct1 . validate ( self ) { /* ... */ }\nfun Struct2 . validate ( self ) { /* ... */ }\nMethods are also more convenient: obj.someMethod() reads better than someFunction(obj) .\nstruct AuctionConfig {\n// ...fields...\n}\n// Prefer this:\nfun AuctionConfig . isInvalid ( self ) {\n// ...\n}\n// Over this:\n// fun isAuctionConfigInvalid(config: AuctionConfig) {}\nStatic methods follow the same pattern: Auction.createFrom(...) reads better than createAuctionFrom(...) .\nA method without a self parameter is static:\nfun Auction . createFrom (config: cell , minBid: coins ) {\n// ...\n}\nStatic methods also group utility functions. For example, standard functions like blockchain.now() are static methods on an empty struct. This technique emulates namespaces:\nstruct blockchain\nfun blockchain. now (): int /* ... */ ;\nfun blockchain. logicalTime (): int /* ... */ ;\nUse optional addresses to have address defaults\nA nullable address address? is a pattern for an optional address, sometimes called \"maybe address\" :\n- null represents the address none .\n- address represents an internal address.\nCalculate CRC32 or SHA256 at compile-time\nSeveral compile-time methods operate on constant strings :\n// Calculates CRC32 of a string\nconst crc32 = \"some_str\" . crc32 ()\n// Calculates SHA256 of a string as a 256-bit integer\nconst hash = \"some_crypto_key\" . sha256 ()\nWork with strings\nTolk provides a dedicated string type backed by snake-encoded cells. Use the StringBuilder for concatenation:\nimport \"@stdlib/strings\"\nvar str = StringBuilder . create ()\n. append ( \"hello \" )\n. append ( \"world\" )\n. build ();\nFor fixed-size binary data, use bitsN types , for example bits256 or bits512 .\nAvoid micro-optimization\nThe compiler applies many optimizations : it automatically inlines functions, reduces stack allocations, and handles the underlying work. Attempts to outsmart the compiler yield negligible effects, either positive or negative.\nPrefer readability over manual optimizations:\n- Use one-line methods freely as they are auto-inlined.\n- Use flat structures: they are as efficient as raw stack values.\n- Extract standalone values into constants and variables.\n- Avoid assembler functions unless necessary.\nBasic syntax\nPrevious Page\nExamples\nNext Page\nOn this page\nDeclare each contract with a contract directive Prefer automatic serialization to manual one Prefer typed cells with Cell Use lazy data loading Use type aliases to express custom serialization logic Use contract storage as a structure Express messages as structs with 32-bit prefixes Use unions to handle incoming messages Use structs to send messages Attach initial code and data to a message to deploy another contract Target certain shards when deploying sibling contracts Emit events and logs to off-chain world during development Return several state values as a structure from a get method Validate user input with assertions Organize a project into several files Prefer methods to functions Use optional addresses to have address defaults Calculate CRC32 or SHA256 at compile-time Work with strings Avoid micro-optimization"}
{"url":"https://forum.solana.com/t/i-lost-a-significant-ammout-of-solona-by-mistake-to-offcurve-account/4944","domain":"forum.solana.com","title":"I lost a significant ammout of solona by mistake to offcurve account - RFP - Solana Developer Forums","hash":"f45c52d6f6cdb13d9bae00fa5965804fe9ef5f8a4d8b2ad90726640530bf2de5","tokens":304,"chars":1214,"crawler":"hive-genesis","verified":"exact","ts":1791112254898,"text":"Solana Developer Forums\nI lost a significant ammout of solona by mistake to offcurve account\nRFP\naccount-resolution\nYoussefo\nJuly 4, 2026, 5:15pm\n1\nI accidentally sent 3.178179538 SOL to the address HK24enuksj4kpH5wzdTTVfonpYjFjKcaSofZbzNtLH9 instead of my intended address (I omitted the last character). Solscan shows:\n- Owner: System Program\n- isOnCurve: false\n- Balance: 3.178179538 SOL\n- Transaction signature: 3CJR9VvwCpuRCUowBZAb4XCK6vdKxwLJJKJ94dax4zVuQ9cBDCdH9PurmEM6xpKSenqZKYcXY1TvwYVCMj3uEzkz\nIs there any technical method to recover funds from this off-curve System Program account, or are they permanently inaccessible?\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nsRFC 00003: On-chain interface account resolution\nsRFC\naccount-resolution\n,\ninterfaces\n1\n1837\nApril 4, 2023\nsRFC 00002: Off-Chain Instruction Account Resolution\nsRFC\naccount-resolution\n,\ninterfaces\n,\nspl\n,\nanchor\n4\n1057\nApril 16, 2025\nsRFC 21 - Nested Account Resolution\nsRFC\naccount-resolution\n,\ninterfaces\n,\nprogram-interface\n,\ncpi\n0\n749\nJanuary 15, 2024\nSteak Proposal - A Solana Proposal For Memecoins\nResearch\n0\n388\nJuly 2, 2026\nsRFC-35 - Address/Domain Association Specification\nsRFC\n19\n1236\nApril 16, 2025\nDiscourse Footer"}
{"url":"https://www.helius.dev/docs/rpc/historical-data","domain":"www.helius.dev","title":"Solana Historical Data Overview & Tutorials - Helius Docs","hash":"da227c49c812b761e91ce6589e744c85f0a753199df8eb93d41d3b1815a5b8f2","tokens":1280,"chars":5118,"crawler":"crawler-tpoe","verified":"exact","ts":1791112256003,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNew: Try Gatekeeper (Beta) for significantly lower latency. Learn More\nHelius Docs home page\n- Support\n-\nGet started\nHelius Docs home page\nTransactions\nSolana Historical Data Overview & Tutorials\nQuery Solana historical data with Helius â enhanced transaction history via getTransactionsForAddress, transfer history, and archival RPC methods like getBlock.\nWhat is Solana historical data?\nSolanaâs ledger is an append-only chain of blocks stretching back to genesis. Historical data means querying that ledger after the fact: a walletâs past transactions, the transfers a token has seen, the contents of a block, or the signatures that touched an address.\nHelius gives you two ways to read it. Standard archival RPC methods ( getBlock , getSignaturesForAddress , getTransaction , and more) mirror the native Solana JSON-RPC surface. On top of those, Helius adds enhanced methods that standard RPC canât match: getTransactionsForAddress returns full filtered transaction history in a single call, and getTransfersByAddress returns parsed, reconciliation-ready transfer records.\nWhy Helius for historical data?\nUnlike providers relying on shared BigTable infrastructure, Helius maintains dedicated archival nodes optimized for fast historical data retrieval. Data spans Solana genesis to present, is continuously updated, and fully supports versioned transactions and all program types.\nIndependent infrastructure\nHelius runs its own archival system, not shared BigTable like other providers.\nFaster queries\nDirect access to optimized storage means faster response times for historical queries.\nHigher reliability\nNo shared infrastructure bottlenecks. Consistent performance even during network peaks.\nWhich method should I use?\nStart with getTransactionsForAddress for any address-based history work. Reach for the standard methods when you need raw block data or are wiring up existing Solana RPC tooling.\nWhat you need Use this Returns\nComplete transaction history for an address (backfill, indexing, analytics) getTransactionsForAddress Full or signatures-only transactions, filtered and paginated\nToken + native SOL transfer history for a wallet getTransfersByAddress Parsed, human-readable transfer records\nOne transaction by signature getTransaction Full transaction details\nConfirmed signatures for an address getSignaturesForAddress Signature list (no associated token accounts)\nA specific blockâs full contents getBlock All transactions and metadata for a slot\nInflation/staking rewards for an epoch getInflationReward Reward amounts per address\nRecommended path: getTransactionsForAddress\ngetTransactionsForAddress\nHelius-exclusive transaction history that goes beyond standard Solana RPC. Query with time-based and slot-based filtering, bidirectional sorting, token-account history, efficient keyset pagination, and full transaction data in a single request. Ideal for token launch analysis, complete wallet and token history, MEV research, compliance reporting, and portfolio tracking.\nKey methods\nThe enhanced, Helius-exclusive transaction-history methods. Each card links to its guide.\nTransaction history\ngetTransactionsForAddress\nEnhanced, Helius-exclusive transaction history with filtering, bidirectional sorting, token-account support, and efficient pagination.\ngetTransfersByAddress\nParsed token and native SOL transfer history for a wallet, with mint, time, amount, and counterparty filters. Developer+ only; 10 credits per request. See the API reference .\ngetTransaction\nFull transaction details for a single signature. For verification, detailed analysis, and debugging.\ngetSignaturesForAddress\nConfirmed signatures for an address. For basic history and signature collection. Does not include associated token accounts â use getTransactionsForAddress for complete token history.\nCommon use cases\nToken launch analysis\nTrack mint creation and early holder activity. Identify project origins and initial distribution patterns.\nWallet forensics\nBuild complete transaction timelines. Discover funding sources and transaction patterns over time.\nMEV research\nAnalyze historical arbitrage and sandwich attacks. Study MEV opportunities with precise timing data.\nCompliance & auditing\nGenerate comprehensive transaction reports. Support regulatory compliance with complete historical records.\nPortfolio tracking\nAccess complete DeFi transaction history. Build accurate portfolio analytics and performance tracking.\nBlock explorers\nDisplay complete blockchain history. Provide users with detailed block and transaction information.\nNext steps\ngetTransactionsForAddress\nFull guide to the enhanced transaction history method.\ngetTransfersByAddress\nParsed transfer history for payments and reconciliation.\nIndexing guide\nBuild, backfill, and sync a Solana index.\nDiscord community\nJoin thousands of developers building on Solana with Helius.\nWas this page helpful?\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.marinade.finance/marinade-dao","domain":"docs.marinade.finance","title":"Marinade DAO | Marinade Documentation","hash":"47d1f4f30d5d00ca1be299c301585f7244d25b7bb2c12df8d99e808f330716c9","tokens":513,"chars":2050,"crawler":"hive-genesis","verified":"exact","ts":1791112257554,"text":"Marinade Documentation\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nđ ïž Marinade DAO\nMarinade.finance is governed and built by the community. Owning MNDE tokens or actively engaging in the community makes you a member of Marinade DAO. Let's see what this means.\nWhat is a DAO?\nA Decentralized Autonomous Organization (DAO) is an on-chain system designed to give the governance of a protocol back to its users. By owning the governance token, you have the right to vote on decisions taken for the future of the protocol. These governance rules are applied on-chain, by smart contracts, where all information is freely accessible.\nMarinade has established governance on Realms using SPL-governance. To stay up-to-date with the latest announcements, join Marinade's Discord.\nMarinade DAO\nMarinade DAO (mDAO) is constituted of MNDE holders that lock their MNDE in governance. Locking MNDE in Marinade's governance gives voting power in the Marinade DAO and access to MNDE's utilities.\nValues\nWhen doing what we're doing, we come back to the following set of values:\nADAPTABLE\nThe ecosystem of Solana is innovative and fast. So are we. Curiosity is our favorite starting point. We nurture agility. Solid principles and processes allow us to react quickly . We are building the future .\nAPPROACHABLE & HONEST\nWe are approachable . We value team collaboration over competition. Supportive and friendly is our default mindset. Honesty guides our communication. We always listen to ideas.\nRESPONSIBLE\nEvery one of us is accountable for our individual contribution , no matter the scope. We own our commitments as if no one is watching. We are all value creators . We stand up for the outcomes of our work. We learn from failures , and we analyze and celebrate success . We only accept short-term wins compatible with our long-term vision .\nContributors\nPrevious Welcome to Marinade\nNext Contributors\nLast updated 1 year ago\nWas this helpful?\n- What is a DAO?\n- Marinade DAO\n- Values\nWas this helpful?"}
{"url":"https://wormhole.com/docs/products/token-transfers/native-token-transfers/faqs/","domain":"wormhole.com","title":"Native Token Transfers FAQs | Wormhole Docs","hash":"46b7678635645cde18da7339fc04cef8e54a7227f11233695013c2282d14b149","tokens":3537,"chars":14145,"crawler":"crawler-tpoe","verified":"exact","ts":1791112258061,"text":"Skip to content\nInitializing search\n- Configuration\n- Concepts\n- FAQs FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Portal Bridge\n- Connect\n- Guides\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Settlement\n- FAQs\n- Reference\n- Messaging\n- Interact with Core Contracts\n- Query NTT Data and Transfers\n- Concepts\n- Tutorials\n- Reference\n- Protocol\n- Infrastructure Guides\n- Developer Tools\n- Wormhole CLI\n- Wormholescan Explorer\n- Wormholescan API\n- Reference\n- AI Resources\nPage Actions\nEdit this page\nNTT FAQs ïŒ\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nWhat is NTT? ïŒ\nNative Token Transfers (NTT) is a framework for moving your own token across multiple chains without wrapping. It preserves your token's native contract design on every chain and keeps control in your hands for metadata, ownership, upgrades, and custom features.\nNTT includes configurable controls like rate limiting and access control, and supports deployment modes that fit either new or existing tokens. For a quick video summary, watch the NTT speed round .\nDoes NTT support a âlock-and-lockâ transfer model? ïŒ\nNo. NTT does not support a lock-and-lock transfer model.\nIn locking mode, the NTT Manager completes inbound transfers by transferring tokens from its own balance on that chain. This means the NTT Manager can only release tokens that it already holds locally.\nA lock-and-lock setup would require both the source and destination chains to use locking mode. In that case, the destination NTT Manager would need to have already enough tokens available to release for every inbound transfer. Without those tokens, the transfer cannot be redeemed on the destination chain.\nBecause this model depends on maintaining sufficient token balances on each destination chain, NTT does not support lock-and-lock transfers. Instead, NTT relies on minting on chains that do not require pre-funded balances, avoiding destination-side liquidity constraints.\nDo you have an example of how cross-chain lending can be implemented using Wormhole? ïŒ\nYes, we have an example of cross-chain lending that leverages Wormholeâs Wrapped Token Transfers (WTT) . In this example, collateral deposits (such as ETH on Ethereum) are bridged to a hub chain. Once the collateral is deposited, the borrowed assets, like wrapped BNB, are bridged to Binance Smart Chain. You can explore the full implementation in the Wormhole Lending Examples repository on GitHub.\nAlternatively, you can also implement cross-chain lending using Wormholeâs core messaging instead of WTT, which avoids the limitations imposed by governor limits. ETH would be custodied on Ethereum, and BNB on the Binance spoke during this setup. When a user deposits ETH on Ethereum, a core bridge message is sent to the hub for accounting purposes. The hub then emits a message that can be redeemed on Binance to release the BNB. This approach allows for more direct asset control across chains while reducing reliance on WTT limits.\nWhat causes the \"No protocols registered for Evm\" error in Wormhole SDK? ïŒ\nThis error typically occurs when the Wormhole SDK cannot recognize or register the necessary EVM protocols, which are required for interacting with Ethereum-based networks. The most common reason for this error is that the relevant EVM package for Wormhole's NTT has not been imported correctly.\nTo resolve this issue, ensure you have imported the appropriate Wormhole SDK package for EVM environments. The necessary package for handling NTT on EVM chains is @wormhole-foundation/sdk-evm-ntt . Here's the correct import statement:\nimport '@ wormhole - foundation / sdk - evm - ntt ' ;\nBy importing this package, the Wormhole SDK can register and utilize the required protocols for EVM chains, enabling cross-chain token transfers using the NTT framework. Ensure to include this import at the start of your code, especially before attempting any interactions with EVM chains in your project.\nHow can I mint tokens after moving the treasury object to the NTT manager on Sui? ïŒ\nTo mint tokens after moving the treasury object to the NTT manager on Sui, you need to use the take_treasury_cap function from the NTT contract . This function allows the admin to temporarily take the treasury cap to mint assets.\nThe flow works as follows:\n- Take the treasury cap : Use state.take_treasury_cap(admin_cap) to extract the treasury cap.\n- Mint assets : Perform your minting operations with the treasury cap.\n- Return the treasury cap : Use state.return_treasury_cap(treasury_cap) to return it to the state.\nImportant\nReturn the Treasury Cap! If the treasury cap is not returned in the same transaction, the NTT deployment will stop working. The contract will break and become non-functional.\nIt is recommended to use Programmable Transaction Blocks (PTBs) for this operation. PTBs allow you to execute multiple operations atomically in a single transaction, ensuring that both the minting operation and returning the treasury cap happen together, preventing any risk of the contract breaking.\nHow can I specify a custom RPC for NTT? ïŒ\nTo specify a custom RPC for Wormhole's NTT, create an overrides.json file in the root of your deployment directory. This file allows you to define custom RPC endpoints, which can be helpful when you need to connect to specific nodes or networks for better performance, security, or control over the RPC connection.\nBelow is an example of how the overrides.json file should be structured:\noverrides.json\n{\n\"chains\" : {\n\"Bsc\" : {\n\"rpc\" : \"http://127.0.0.1:8545\"\n},\n\"Sepolia\" : {\n\"rpc\" : \"http://127.0.0.1:8546\"\n},\n\"Solana\" : {\n\"rpc\" : \"http://127.0.0.1:8899\"\n}\nCan I set outbound rate limits on a per-chain basis like inbound limits? ïŒ\nNo. Outbound rate limits are a single global value per chainâthey cannot be configured for individual destination chains. This means if you set an outbound limit of 1000 tokens, that limit applies to all transfers leaving the chain, regardless of destination.\nInbound rate limits, however, can be configured on a per-chain basis. For example, you can allow 100 tokens to be received from Ethereum but only 50 tokens from Arbitrum.\nHere's what a properly configured deployment.json limits section looks like:\n\"limits\" : {\n\"outbound\" : \"1000.000000000000000000\" ,\n\"inbound\" : {\n\"Ethereum\" : \"100.000000000000000000\" ,\n\"Arbitrum\" : \"50.000000000000000000\"\n}\nFor detailed information on rate limiting behavior, queuing mechanisms, and cancel flows, see the Rate Limiting documentation.\nHow can I redeem tokens if NTT rate limits block them on the target chain? ïŒ\nIf the rate limits on Wormhole's NTT block tokens from being received on the target chain, the transaction will typically be paused until the rate limits are adjusted. Rate limits are implemented to manage congestion and prevent chain abuse, but they can occasionally delay token redemptions.\nTo resolve this:\n- Adjust rate limits : The rate limits must be modified by an administrator or through the appropriate configuration tools to allow the blocked transaction to proceed.\n- Resume transaction flow : Once the rate limits are adjusted, you can resume the flow, which should be visible in the UI. The tokens will then be redeemable on the target chain.\nIn most cases, the transaction will resume automatically once the rate limits are adjusted, and the UI will guide you through the redemption process.\nWhat are the challenges of deploying NTT to non-EVM chains? ïŒ\nNTT requires the same transceiver for all routes, limiting flexibility when deploying across EVM and non-EVM chains. For example, if you're deploying to Ethereum, Arbitrum, and Solana, you can't use Wormhole and Axelar as transceivers because Axelar doesn't support Solana. This constraint forces integrators to use a single transceiver (e.g., Wormhole) for all chains, reducing flexibility in optimizing cross-chain transfers.\nDoes the NTT manager function as an escrow account for a hub chain? ïŒ\nYes, the NTT manager acts like an escrow account for non-transferable tokens on a hub chain. To manage non-transferable tokens, you would add the NTT manager to the allowlist, ensuring that only the NTT manager can hold and control the tokens as they are transferred across chains.\nWhich functions or events does Connect rely on for NTT integration? ïŒ\nConnect relies on the NTT SDK for integration, with platform-specific implementations for both SVM and EVM . The key methods involved include:\n- Initiate and redeem functions : These functions are essential for initiating token transfers and redeeming them on the destination chain.\n- Rate capacity methods : Methods for fetching inbound and outbound rate limits are also critical for controlling the flow of tokens and preventing congestion.\nThese functions ensure Connect can handle token transfers and manage chain-rate limits.\nHow does the relayer contract determine which transceiver to call? ïŒ\nThe source chain's transceiver includes the destination chain's transceiver in the message via the relayer contract. The admin configures each transceiver's mapping of its peers on other chains. This mapping allows the destination transceiver to verify that the message came from a trusted source.\nHow do I create a verifier or transceiver? ïŒ\nTo run your verifier, you need to implement a transceiver. This involves approximately 200 lines of code, leveraging the base functionality provided by the abstract transceiver contract .\nFor reference, you can review the Axelar transceiver implementation .\nCan I use Hetzner for the NTT deployment? ïŒ\nNo, using Hetzner servers for Solana deployments is not recommended. Hetzner has blocked Solana network activity on its servers, leading to connection issues. Hetzner nodes will return a ConnectionRefused: Unable to connect error for Solana deployments. Therefore, choosing alternative hosting providers that support Solana deployments is advisable to ensure seamless operation.\nHow can I transfer tokens with NTT with an additional payload? ïŒ\nYou can include an extra payload in NTT messages by overriding specific methods in the NttManager contract .\n- On the source chain, override the _handleMsg function to query any additional data you need for the transfer. The extra payload can then be added to the message.\n- On the destination chain override the _handleAdditionalPayload function to process and utilize the extra payload sent in the message.\nImportant\nYou cannot pass the additional data as part of the entry point directly. Instead, the data must be queried on-chain via the _handleMsg method, ensuring the payload is properly included and processed.\nWhy use NTT over xERC20? ïŒ\nShortcomings of xERC20:\n- Single point of failure : xERC20 relies on multiple bridges, but a compromise in any single bridge can jeopardize the token. It enforces a 1-of-n design rather than a more robust m-of-n approach.\n- No pausing : xERC20 lacks mechanisms to pause operations during emergencies.\n- No access control : There are no built-in access controls for managing token transfers securely.\n- Limited rate limiting : Rate limits are bridge-specific and cannot be set per chain, reducing flexibility and security.\n- No integration with relaying systems : xERC20 does not natively support relayer systems, limiting its usability in automated or dynamic setups.\nWhile xERC20 is an extension of the ERC20 standard, NTT is designed as a framework rather than a rigid standard. It is compatible with any token that supports burn and mint functions and allows the NTT manager to act as a minter.\nHow can I start transferring tokens to a chain that is in burning mode, if no tokens are locked yet? ïŒ\nTo begin transferring tokens to a chain in burning mode when no tokens are locked, you must first send tokens to the NTT manager to back the supply. The address of the NTT manager can be found in the deployment.json file.\nIs there a way to use NTT tokens with chains that don't currently support NTT? ïŒ\nYes. NTT tokens can be used with chains that do not support NTT by leveraging the Wrapped Token Transfers (WTT) . For example:\n- Wrapped token scenario : A token, such as the W token, can be bridged to non-NTT networks using WTT. When the token is bridged to a chain like Sui, a wrapped version of the token is created (e.g., Wrapped W token).\n- Unwrapping requirement : Tokens bridged using WTT cannot be directly transferred to NTT-supported chains. To transfer them, they must first be unwrapped on the non-NTT chain and then transferred via the appropriate mechanism.\n- Messaging consistency : WTT exclusively uses Wormhole messaging, ensuring consistent communication across all chains, whether or not they support NTT.\nThis approach ensures interoperability while maintaining the integrity of the token's cross-chain movement.\nCan I bridge native ETH or other gas tokens with NTT? ïŒ\nYes. On EVM chains, you can use the wethUnwrap manager variant to bridge native gas tokens like ETH. This works in hub-and-spoke mode, where WETH is used as the locked token on the hub chain. When tokens are transferred back to the hub, the NTT Manager automatically unwraps WETH to native ETH and sends it to the recipient.\nTo deploy with this variant, pass --manager-variant wethUnwrap when adding the hub chain. For full setup instructions, see the WethUnwrap variant section in the EVM deployment guide.\nHow can I update my NTT CLI version? ïŒ\nTo update an existing NTT CLI installation, run the following command in your terminal:\nntt update\nNTT CLI installations and updates will always pick up the latest tag with name vX.Y.Z+cli and verify that the underlying commit is included in main.\nFor local development, you can update your CLI version from a specific branch or install from a local path.\nTo install from a specific branch, run:\nntt update --branch foo\nTo install locally, run:\nntt update --path path/to/ntt/repo\nGit branch and local installations enable a fast iteration loop as changes to the CLI code will immediately be reflected in the running binary without having to run any build steps.\nLast update: September 28, 2026\n| Created: September 28, 2026"}
{"url":"https://docs.jup.ag/user-docs/trade/predict/how-it-works","domain":"docs.jup.ag","title":"How Predict Works - Jupiter Documentation","hash":"144817205e58cc28ff7eceedc07f3124519c082d54f087cf14b54ec2c484152a","tokens":7828,"chars":31310,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112259829,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nJupiter Documentation home page\nPrediction Market\nHow Predict Works\nDetailed mechanics of Jupiter Prediction Markets: events, contracts, orders, fees, settlement, and the Degen mode.\nThis page covers the detailed mechanics of Jupiter Predict. For a high-level introduction, see the Overview .\nEvents and Markets\nAn event is a real-world occurrence with a determinable outcome. For example: âRepublican Presidential Nominee 2028â or âUEFA Champions League Winner.â\nEach event contains one or more markets . Each market represents a specific outcome within the event and is usually binary: YES or NO.\nFor example, an election event can contain separate markets for several candidates. Each candidate market trades independently. You can buy YES on one candidate without taking a position on any other candidate.\nMulti-Outcome Events\nEvents with many possible outcomes are displayed with the top outcomes visible by default. Click Show More to drill down and see additional sub-markets.\nThe probabilities across all sub-markets within a multi-outcome event do not always sum to exactly 100%. Each sub-market can have its own liquidity, spread, and price history.\nSports Match Markets\nA single sports match can carry several market types, grouped on one event page. A match with only a few market groups lists them one under the other (Moneyline, Spreads, Totals); when a match carries more, they are split into tabs, with Gamelines holding the main markets and, on football matches, dedicated tabs such as Exact Score , Goalscorers , Halves (result, goals, spread, total, team totals, both teams to score and exact score for the first or second half, settled on that half alone) and Corners (total corners, per half, per team, odd / even, and first corner). On a football match, for example:\n- To Advance : which team goes through to the next round. Runs to the full result, including extra time, penalties, or an official ruling, as set out in the market rules.\n- Moneyline : the three-way regulation-time result (either team or the draw), each side tradeable YES or NO. The order buttons show the payout per contract (e.g. â$1 pays 2.46â).\n- Both Teams to Score : yes or no.\n- First Team to Score : which team scores first, or Neither .\n- Double Chance : cover two of the three regulation-time outcomes in a single position.\n- Spreads : back a team at a goal handicap, with a selectable line (e.g. 0, 0.5, 1).\n- Totals : over or under on total goals, with a selectable line (e.g. 2, 2.5, 3).\n- Team Totals : over or under on one teamâs goals, in a section per team.\n- Odd / Even and Total Goals ranges (e.g. 0-1, 2-3, 4-6, 7+).\n- Exact Score : see Special Markets .\n- Goalscorers : anytime goalscorer markets, in their own tab, settled on regulation time.\nReading these markets:\n- REG TIME vs FULL TIME badges : REG TIME markets settle on the first 90 minutes plus stoppage time. FULL TIME markets settle on the final outcome, including extra time and penalties (To Advance is a FULL TIME market). The exact treatment is always in the marketâs rules summary.\n- Push rules are displayed on the market : on integer Spreads and Totals lines, a push (the spread-adjusted score is level, or the final total equals the line) resolves as a refund of the stake. The applicable rule is shown on each market group (e.g. âDraw = refundâ, âExactly 2 = refundâ). Other market types (Double Chance, Odd / Even, Exact Score) do not use lines and have no push outcome.\n- No fees label : the sportsbook-style groups (Double Chance, Spreads, Totals, Odd / Even, Total Goals ranges, Exact Score) currently charge no trading fees. These are ticket markets : market orders only, held to settlement with no early sell.\nEsports events can also carry several market types per match, grouped by game within a series (e.g. Game 3 of a best-of-3), with live scores shown on the event card.\nTennis matches carry match, set, and game markets, with dedicated Total Sets and Total Games sections.\nComments\nEach event page includes a comments section: you can post comments on an event, like other tradersâ comments, and delete your own. External links are blocked in the composer: only HTTPS links to jup.ag are accepted, validated before the comment is published. A link to a Jupiter prediction event or profile is shown as a card rather than a bare URL: an event card carries the market image, title, volume and live indicators, with the Yes / No or team buttons when the market is open; a profile card shows the avatar, username, prediction count, win rate and realised PnL. One card is shown per comment, and the same applies in clan chat.\nMarket States\nA market moves through several states from creation to settlement:\nUpcoming\nThe market is visible but trading has not started yet. The UI may show a countdown.\nOpen (Live)\nThe market is actively trading. Buy and sell actions are available when liquidity and routing support them. Live timed markets show a compact countdown on their card, with an urgency state in the final 30 seconds.\nClosed\nTrading has stopped. The market is waiting for the result to be determined and recorded.\nSettled\nThe result is final. Profile shows claim, refund, automatic, lost, or final status.\nContracts\nA contract is a financial claim tied to one side of one market.\n- A winning contract pays $1 worth of the marketâs settlement asset .\n- A losing contract pays $0 and expires worthless.\n- Some markets can resolve to a refund or draw outcome if the market rules require it.\nContract prices usually range from $0.01 to $0.99 . The price reflects the current market-implied probability for that side. A YES contract at $0.65 means traders are currently paying about 65 cents for the YES side.\nPrices can be displayed in two formats, switched with the persistent Price (Âą) / Decimal (x) selector available on Browse, Event, and Degen pages: cents (the default) or a decimal odds-style multiplier. Spread warnings are always expressed in cents, and charts keep the canonical price format.\nFunding and Settlement Assets\nPredict uses dollar-pegged assets for trading and settlement. The exact funding token can depend on the market and route. In some flows, Jupiter may route your input into the marketâs settlement asset before the order is placed.\nThe order panel shows the token you pay with and, once you enter an amount, the quote details: size, number of contracts, expected payout, and any estimated refund. Trading fees are included in the quote rather than shown as a separate line; see Fee Structure for how they are calculated.\nSpread\nEach market has a bid price and an ask price :\n- The ask is what you pay when buying.\n- The bid is what you receive when selling.\nThe difference is the spread. Entering and exiting a position can cost money even if the market price has not moved.\nOrder Types\n-\nMarket Orders\n-\nLimit Orders\nMarket orders are the main live order type on Predict. A market order attempts to execute at the best available price for the selected side.\n- The order quote is based on current price and liquidity.\n- If price or liquidity changes before execution, the order may fail or partially fill.\n- If less than the full amount executes, unused funds are returned automatically.\n- Fees are charged only on the executed portion.\nLimit orders let you set a target price and wait for a match.\n- Available on Polymarket-sourced markets only , and only as limit buys . Limit sells are disabled.\n- You can cancel an open limit order before it is matched.\n- Jupiter Forecast markets and sports ticket markets are market-order only. A Limit tab may still appear on the order form there, but it is disabled.\nExecution Flow\nPredict abstracts away most of the execution machinery. In normal use, you only sign the transaction shown in your wallet.\n1\nQuote\nThe app checks the selected market route and estimates price, contracts, fees, and payout.\n2\nSign\nYou review the quote and sign the transaction in your wallet.\n3\nExecute\nJupiter validates the trade and attempts to execute it through the selected route or market integration.\n4\nUpdate position\nIf the trade executes, your position appears in Profile. If it cannot execute, or only partially executes, unused funds are returned automatically.\nThis process can involve on-chain accounts, route execution, keepers, and market integrations behind the scenes. You do not need to manage those pieces manually.\nPosition Management\nA position represents your holdings in a specific market side.\nPosition Data\nYour Profile can show the following for each position:\nField Description\nEvent The event and market name\nSize Number of contracts held\nValue Current estimated market value\nAvg. Price Average price paid per contract\nMark Price Current reference price per contract\nPnL Unrealised profit or loss, with fee display controls where available\nPayout if right Estimated payout if your side wins\nSettlement status Whether the market is open, closed, claimable, refunded, or settled\nClosing a Position\nYou can try to close a position before settlement by clicking Close , or Close All to exit all eligible positions.\n- Closes execute at the current bid, so the spread matters.\n- You can close a position partially or in full : the Close panel offers percentage presets ( 25%, 50%, 75%, or Max ) or a custom dollar amount. Choosing Max sells the entire position regardless of price moves.\n- A close can fail if the market is closed, liquidity is too low, or the route is temporarily unavailable.\nWhen You Can Close a Position\nWhether you can close depends on the marketâs current state:\nMarket state Can you close? Notes\nOpen (Live) Usually Close attempts sell at the current bid if liquidity is available\nClosed No Trading has stopped. Wait for settlement\nSettled (you won) No Claim the payout instead\nSettled (refund) No Refund is processed on-chain and reflected in Profile\nSettled (you lost) No The position is final and no action is needed\nLow liquidity can make a position difficult or impossible to close even while the market is open. If a position looks stuck for an unusually long time, raise a ticket via Discord . Some market types, such as special markets , cannot be closed at all and must be held to resolution.\nProfile Tabs\nYour Profile page has three main tabs:\n- Positions : active positions and claimable or refundable outcomes.\n- Open Orders : pending orders when that flow is available.\n- History : completed trades, settlements, claims, and refunds.\nA period filter lets you narrow Positions, Open Orders, History, and the portfolio summary to a chosen time window. The portfolio summary also includes a PnL chart showing your profit and loss over time.\nMarket Sources and Integrations\nJupiter Predict can surface markets from external prediction market providers and Jupiter-supported market integrations. Browse markets are currently sourced from Polymarket, alongside short-duration crypto markets and other Jupiter-supported integrations. When an external provider has trading problems, a warning banner appears on the affected feeds and event pages; orders on those markets can fail or stay pending until the provider recovers.\nWhat This Means for Users\n- Market availability : not every market from every source is available on Jupiter.\n- Action availability : some markets may be view-only, closed, unavailable in your region, or temporarily unavailable for buys or sells.\n- Resolution rules : each market follows its own published rules. Read the rules summary before trading.\n- Disputes : if a source market has a dispute or delayed resolution process, Jupiter follows the final result from that source or integration.\n- Settlement : some market routes record eligible results on-chain. Other integrations may settle through their own process and reflect status in Profile.\nOrder Behaviour by Market Source\nMarket source Orders Early sell Limits and fees\nPolymarket-sourced markets Market orders + limit buys (limit sells disabled) Yes, at the current bid $5 minimum order; standard trading fees\nJupiter Forecast markets (stocks) Market orders only Yes, via Close No trading fees; tradable during US market hours only; terms acknowledgement required\nSports ticket markets Market orders only No, held to settlement $4 minimum, $3,000 maximum per ticket; currently no trading fees\nSpecial Markets\nDuring major sporting events, Predict lists sportsbook-style ticket markets on individual matches: Double Chance, Spreads, Totals, Odd / Even, Total Goals ranges, and Exact Score (see Sports Match Markets ).\nTicket markets work differently from standard Browse markets:\n- No early sell. Once you buy a ticket, you hold it until the market resolves and pays out at settlement. There is no orderbook and no early exit.\n- Market orders only. A Limit tab may appear on the form but is disabled on these markets.\n- Each purchase is a separate ticket. Buying the same market more than once creates multiple independent positions rather than adding to one.\n- A separate sportsbook provider sets the odds , so they can differ from similar markets elsewhere.\n- Stake limits : minimum $4 and maximum $3,000 per ticket. The $5 minimum order applies to the normal order path (Polymarket and Jupiter Forecast markets), not to tickets.\n- Currently no trading fees on ticket markets.\nBecause ticket positions cannot be sold, your funds stay committed until the market resolves, regardless of how the odds move in the meantime.\nDegen Mode\nDegen is a section within Jupiter Predict focused on short-duration Up or Down price markets. It has two tabs: Crypto and Stocks .\nThe Crypto tab currently lists 5-minute and 15-minute Up or Down markets on BTC, SOL, ETH, XRP, BNB, DOGE, and HYPE , each grouped under a live price chart; the Stocks tab hosts SPCX (SpaceX). Filter chips narrow the list by window ( All | 5m | 15m ) or by asset, and a Live filter shows the markets currently running.\nHow It Works\nEach Degen market asks whether a tokenâs price will move Up or Down from a reference price over a defined window.\n- The available assets and windows can change.\n- The reference price is shown on the market card.\n- The current price updates while the market is live.\n- If the final price is above the reference, Up wins.\n- If the final price is below the reference, Down wins.\n- The market rules determine any edge cases, such as ties or unavailable price data.\nEach marketâs rules summary , at the bottom of its page, names its exact resolution source. The crypto markets resolve from Chainlink data streams (for example the SOL/USD TWAP stream), not from spot markets or other price sources.\nDegen markets may use a different route from standard Browse markets, but the basic wallet flow is the same: review the quote, sign, and monitor the position. Settlement actions can vary by route: Profile shows whether the outcome is automatic, claimable, refundable, or final.\nJupiter Forecast Markets\nSome Degen markets carry a Jupiter Forecast label. These are custom short-duration markets operated through a Jupiter market integration, over 5-minute and 15-minute windows, bought with USDC. They currently cover SPCX (SpaceX) Up or Down in the Stocks tab. The BTC Up or Down markets in the Crypto tab are Polymarket-sourced Degen markets since 30 September 2026 and no longer carry the Forecast label.\nForecast markets behave like other Degen markets, with two specifics set out in each marketâs rules summary:\n- Resolution source : the outcome is determined from the price feed named in the rules â Pyth Pro signed snapshots (Equity.US.SPCX/USD) for SPCX â not from other price sources or spot markets. If the final price is greater than or equal to the starting price, the market resolves to Up ; otherwise it resolves to Down .\n- Near-instant settlement : winnings are credited to your wallet automatically shortly after the window closes. There is nothing to claim.\n- Market orders only : the trade panel shows a Limit tab, but limit orders are not supported on these markets.\n- Order limits : minimum $5 and maximum $1,000 per order.\n- Windows open as they go live : upcoming windows are shown but are not tradable until the window is live. A short daily maintenance period, shown in the interface, makes these markets briefly unavailable each day.\n- Stock markets follow US market hours : SPCX markets (currently badged No fees ) are tradable during the US market session only. Outside those hours, the nearest past or upcoming event is still displayed but cannot be traded. You must acknowledge the terms and conditions before trading a stock market for the first time.\nArcade: One-Minute Markets\nThe Arcade, in its own tab of the Predict navigation, runs continuous one-minute\nBTC and SOL Up or Down rounds. It is a parimutuel game: instead of trading\ncontracts against an order book, everyone bets into a shared prize pool and\nwinners split the losing side.\nRounds run as a continuous carousel: Ended , Live (locked), Next\n(open for entry), and Later . You always bet on the Next round; a countdown\nshows when entry closes, and once the round goes live no more bets are accepted.\nHow a round works:\n- Pick BTC or SOL, then bet Up or Down on the Next round with USDC\n(minimum 1 USDC).\n- Each side displays a live payout multiplier (for example Up 2.46x) computed\nfrom the current pool split. It moves as bets come in, until entry closes.\n- The price captured when the round locks is the reference. Up wins if the\nroundâs closing price is above it; Down wins if it is below.\n- Winners share the losing pool in proportion to their stake, after a fixed\n1% fee on winnings . If only one side has bets, or the closing price equals\nthe reference, the round is VOID and every stake is refunded in full.\n- Settlement is automatic and takes a few seconds. Payouts and refunds are sent\nstraight to your wallet; there is nothing to claim.\n- You can bet both sides of the same round; the round still settles normally.\nAround the game, the page shows your last five results with any streak, a\nChart toggle, a Sound toggle (countdown and settlement effects), and a\nQuick Bet mode to place bets in one tap with a preset amount. With your\nwallet connected, Your stats (record, rounds played, realized PnL) and\nYour history , a preview of your last five rounds, sit on the Arcade page\nitself, next to a live feed of everyoneâs bets. The full History page, reached from that preview, is a\ndedicated, paginated page listing every past round with its asset, your\nentries, the outcome, the payout, your realized PnL, and explorer links to\nthe settlement transactions.\nIdentifying a round\nArcade rounds have no event page or event URL. Each round is its own on-chain\naccount, and the Arcade shows it in two places: the round time on a round card\n(for example 11:01 ) is a link to the roundâs account on the explorer, and\nthe History view lists each past round with its shortened address (first\nand last four characters) as an explorer link, next to the date and time. When\nyou contact support about an Arcade bet, give this round address, or the\nexplorer link, together with your wallet address; the settlement transaction\nlinks in History help too.\nEntry limits and errors\nEach entry must stay between a minimum and a maximum amount in USDC (the\nminimum is currently 1 USDC); both come from the Arcade configuration and the\nbet button shows Below minimum ⊠USDC or Above maximum ⊠USDC when your\namount is outside the range, and Insufficient USDC when your balance does not\ncover it. Quick Bet shows the same messages under the amount. The Up and\nDown buttons are disabled once the countdown reaches zero and the round\nlocks, and while a previous bet is still being sent. If the button reads\nCouldnât load limits , the configuration did not load: reload the page. A bet\ngoes through Preparing Bet , a signature request in your wallet, and\nPlacing Bet ; on success the toast Bet placed links to the transaction,\nand on failure the toast explains the error.\nArcade rounds are fast, repeated bets on one-minute price moves. The displayed\nmultiplier is not fixed: your final payout depends on how the pool is split\nwhen the round locks. Only bet what you can afford to lose.\nFee Structure\nFees are charged only on executed trades: buying or selling contracts. Fees are included in the quoted amounts shown before you sign, rather than displayed as a separate line.\n- Fees are charged in whichever mint is used to purchase the contracts.\n- Fees are always rounded up to the nearest cent.\n- There are no fees when claiming payouts.\n- Orders that do not fill pay no trading fee until they execute.\nArcade Fees\nArcade rounds charge a fixed 1% fee on winnings only . Refunded stakes from\nVOID rounds pay no fee. This schedule is specific to the Arcade\nand differs from Browse and Degen market fees.\nBrowse Market Fees\nFor Browse markets sourced from Polymarket, the trading fee has two components: where Polymarket charges a fee on a market, Jupiter charges an additional fee equal to the Polymarket fee. The total trading fee you pay is twice the Polymarket fee.\nThe fee size depends on three factors:\n- Contract price : the price you pay per contract.\n- Number of contracts : fees scale with the size of the trade.\n- Outcome uncertainty : trades priced closer to $0.50 are more uncertain, so fees are slightly higher. Trades priced closer to $0.00 or $1.00 are more certain, so fees are lower.\nFee examples\nThe amounts below are the total trading fee you pay, with the Jupiter fee already included.\nPrice per Contract Fee (1 Contract) Fee (100 Contracts)\n$0.01 $0.01 $0.07\n$0.05 $0.01 $0.34\n$0.10 $0.01 $0.63\n$0.15 $0.01 $0.90\n$0.20 $0.02 $1.12\n$0.25 $0.02 $1.32\n$0.30 $0.02 $1.47\n$0.35 $0.02 $1.60\n$0.40 $0.02 $1.68\nFor example, buying 100 contracts at $0.25 costs $25.00 in total, with a trading fee of $1.32.\nThis structure keeps fees low for high-confidence outcomes, scales fairly with trade size, and encourages liquidity by not charging orders that are waiting to fill.\nOther Routes and Costs\nMarkets that use other routes can include additional or different fees:\nFee type What it covers\nRoute fee Fees from swap or liquidity routes used by a specific market\nSolana network cost Transaction fees and account rent paid in SOL\nDegen markets may use a different route from standard Browse markets, so the Polymarket fee table above does not necessarily apply to them. The order quote always shows the fees for the specific market and route before you sign.\nWhen Fees Are Not Charged\n- If an order does not execute, trading fees are not charged.\n- If an order partially executes, fees apply only to the executed portion.\n- Claims and refunds do not charge Predict trading fees, though Solana network fees may still apply.\nSettlement Process\nSettlement turns a closed market into a final result. Some market routes record an on-chain result, while other routes may settle through their own integration. Most markets settle to YES or NO, but refund and draw outcomes are possible when the rules require them.\n1\nMarket closes\nTrading stops at the marketâs scheduled close time or when the source market stops accepting trades.\n2\nResult is determined\nThe market source or integration determines the result according to the market rules.\n3\nRecord or reflect the result\nFor some market routes, Jupiter records eligible results on-chain. Other integrations may settle through their own route and update Profile status.\n4\nProfile updates\nYour position is marked as claimable, refundable, automatically settled, lost, or otherwise final.\n5\nYou take action if needed\nIf Profile shows Claim or a refund action, follow the prompt. When you have claimable positions, a Claim All button appears in the Positions tab and claims them all at once. Some outcomes are processed automatically. Losing positions need no action.\nResolved vs. Claimed\nThese are separate states:\n- Resolved means the market result has been finalized and Profile has settlement status. For some market routes, this includes an on-chain result.\n- Claimed means a winning payout has been credited to your wallet.\n- Refunded means an eligible refund has been credited to your wallet.\nPending vs. Resolved\nA market can be resolved by its source before it appears settled on Jupiter. This is expected during the relay and settlement update process. Your Profile updates once final status is available.\nWhen a Market Does Not Resolve as Expected\nMost markets settle after their source result is available, but timing is not guaranteed.\nPossible reasons for a delay:\n- The real-world event has not produced a clear outcome.\n- The market source is waiting for an authoritative result.\n- A provider, route, or settlement issue needs investigation.\nWhile a market is closed and waiting for settlement, you cannot close the position. If a market remains unresolved for an unusually long time, raise a ticket via Discord .\nCancelled, Voided, or Refunded Markets\nIf a market is cancelled, voided, or resolved as refundable, eligible positions can receive a refund after final settlement status is available.\nEligible refunds are processed on-chain and reflected in Profile. Profile shows the refund status and any available action. If the status does not update after the market has clearly resolved as refundable, contact support via Discord .\nWhat to Give Support\nWhen you raise a ticket via Discord , include enough detail for the team to find your trade. The most useful items:\n- Your wallet address â the full address you traded with, not the truncated form shown in the app.\n- The event page URL â every event has its own address, for example jup.ag/prediction/... . Open the event and copy the URL from the browser address bar: its last segment is the marketâs identifier.\n- For an Arcade round , which has no event URL: the roundâs address, shown as a shortened explorer link in the Arcade History view (or by clicking the round time on the round card), and the settlement transaction link from the same row. See Identifying a round .\n- What happened and when â the action you took, the result you expected, and the approximate time with your timezone.\n- The transaction signature , if the issue concerns a specific order. You can find it in your walletâs activity history.\n- The position details as shown in the Positions tab: event, side, size, and average price.\nThe event URL and your wallet address together identify a position, so include both even when the issue seems obvious.\nLeaderboard\nThe Leaderboard is a public ranking of traders on Jupiter Predict.\n- Metrics : PnL, Volume, and Win Rate\n- Time filters : All Time, Weekly, and Monthly\n- Global stats : total platform volume and total number of predictions\nTraders are identified by their chosen username , or by truncated wallet address when none is set. Predict users can pick a username (set once via a signed request, from their profile); it is displayed on profiles, leaderboards, and clan surfaces. The Leaderboard is informational and does not affect trading.\nClans\nClans are trader groups on Jupiter Predict that compete in a weekly PnL race : every trade a member makes counts toward their clanâs weekly total. The competition has its own clan leaderboard with a qualification rule: a clan qualifies for the week by reaching a weekly volume threshold with a positive net PnL. Clans that have not yet qualified are ranked by volume; qualified clans are ranked by PnL. The clan directory lives under the Clans tab ( jup.ag/prediction/clans ), where each clan shows its name, handle, and member count (the optional description is not shown on directory cards). The directory has a live search by clan name or handle and loads more clans as you scroll. Joinable clans are listed by member count, with full clans at the end. Each clanâs detail page shows the clanâs PnL for the selected competition in the header, and lets you navigate by date between the current competition and past ones.\n- Creating a clan : any connected user can create a clan and lead it, choosing a name, a handle (3-64 lowercase letters, numbers, and hyphens), and an optional description. Members are invited after creation. Clans cannot be deleted once created.\n- Joining a clan : join with a direct invitation or an invite link from the clan leader, or send a Request to join from the directory and wait for the leaderâs approval (the request is a wallet message signature, not a transaction). Pending invitations appear in the directoryâs Pending invitations view.\n- Member limit : a clan holds at most 50 members . Once full, new invitations, join requests, and acceptances are blocked until a spot frees up.\n- Leaving and removal : the clan leader can remove members.\n- Member metrics : the clan detail page lists each member with their realized PnL and trading volume for the selected competition period (the current one by default), plus a Rewards column once the week is finalised; join requests and invitations also show the candidateâs PnL, number of predictions, and win rate, so leaders can screen who they let in.\n- Clan chat : each clan detail page has a chat reserved for the clanâs active members. Messages are signed with your wallet.\nClans are a social and competitive layer: they do not change how orders execute, settle, or what fees you pay.\nClan rewards\nEach week, members of the three best qualified clans earn rewards, paid as cash and Gacha packs. A competition runs from Monday 00:00 UTC to the next Monday 00:00 UTC, and rewards are assigned once the week is finalised, shortly after it ends. If no clan qualifies, there is no winner and no rewards for that week.\n- Who earns : in each of the three rewarded clans ( Champion , Runner-up , Third place ), members are ranked by their own PnL for the week, and the reward tiers cover ranks #1 to #10. Each memberâs actual reward appears on the clan page once the week is finalised.\n- What they earn : with the current tiers, the top 3 members of the Champion clan receive cash on top of a Gacha pack. Every other rewarded member receives a Gacha pack, whose value depends on the clanâs place and on the memberâs rank band (#1, #2, #3, #4-10).\n- Where to see the amounts : the standings card on the clan leaderboard shows the current tiers, with a total per clan shown as âUp toâ and the reward for each rank band. The Clans page banner and the Trending feed banner show the weekly prize pool. Amounts can change, and the leaderboard always shows the current ones.\n- After the week : while a week is open, the clan page reads âRewards are assigned after the week endsâ. Once the week is finalised, each member row shows its reward (for example â$600 Cashâ or â$420 Gachaâ), and the clan page states âRanked #N · X members earned rewardsâ, or that the clan did not qualify that week.\nOn-Chain Costs\nJupiter Predict runs on Solana. Using it requires a small SOL balance for:\n- Transaction fees : paid when you sign transactions.\n- Account rent : temporary deposits required for some on-chain accounts.\nRent is recovered automatically when eligible accounts are closed. These are standard Solana network costs and are separate from Predict trading fees.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ens.domains/dao/proposals/6.39","domain":"docs.ens.domains","title":"EP 6.39 | ENS Docs","hash":"3764dcfb3c34608801577c69b05a5819103553c41f0d300b2eb492b568bbbedd","tokens":1631,"chars":6524,"crawler":"hive-genesis","verified":"unchecked","ts":1791112259034,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\n[EP 6.39] [Executable] Treasury Flow Automation\nBy coltron.eth\nStatus Passed\nDiscussion Thread Forum\nVotes Snapshot , Anticapture\nAbstract\nENS protocol revenue currently requires three separate steps to move from registrar controllers to productive use in the endowment and fund operations. This proposal introduces a Registrar Manager contract that takes ownership of all registrar controllers and enables permissionless withdrawals directly to the endowment. It also configures a Zodiac module permission on the endowment to allow the treasury manager to send ETH and USDC to the timelock without a proposal, following a two-year stablecoin runway policy consistent with the current Investment Policy Statement.\nThe result is zero proposals for routine treasury operations, faster yield on collected revenue, permissionless withdrawals, and increased income for the DAO. A conservative estimate suggests that since January 2024, approximately $1 million in yield was missed due to idle capital in registrar controllers and the timelock.\nSpecification\nProblem\nENS protocol revenue requires three steps to move from collection to productive use.\nRegistrar controllers collect ETH from .eth registrations and renewals, and the current controller (controller.ens.eth) already sends withdrawn ETH to the timelock. However, the old registrar controller at 0x283Af0B28c62C092C9727F1Ee09c02CA627eb7F5 holds roughly 772 ETH that requires a dedicated proposal just to withdraw.\nOnce ETH reaches the timelock, sending it to the endowment (endowment.ensdao.eth) for investment requires another proposal. Capital can sit idle in the timelock for several months before it starts earning yield.\nWhen the DAO needs to fund operational expenses like ENS Labs, the Service Provider Program, or Working Groups, yet another proposal is needed to transfer from the endowment back to the timelock or to execute operations with twap.ensdao.eth . For context, EP 6.32 proposed a $2.5M USDC transfer from the endowment to the timelock just to cover Working Group budgets that had already been approved.\nOn top of that, there is currently roughly 4,148 ETH sitting in the timelock that could be earning yield in the endowment. The operational funding process today is reactive and not smooth. Each transfer requires a full governance cycle, and capital that could be generating yield sits idle throughout.\nKey Addresses\nâą Timelock: 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 (wallet.ensdao.eth)\nâą Current Registrar Controller: 0x253553366Da8546fC250F225fE3d25d0C782303b (controller.ens.eth)\nâą Old Registrar Controller (~772 ETH): 0x283Af0B28c62C092C9727F1Ee09c02CA627eb7F5\nâą Endowment: 0x4F2083f5fBede34C2714aFfb3105539775f7FE64 (endowment.ensdao.eth)\nâą Governor: 0x323A76393544d5ecca80cd6ef2A560C6a395b7E3 (governor.ensdao.eth)\nâą TWAP safe: 0x02D61347e5c6EA5604f3f814C5b5498421cEBdEB (twap.ensdao.eth)\nSolution\nThis proposal introduces two components that eliminate all three bottlenecks: a Registrar Manager and an Endowment Zodiac Module permission.\nRegistrar Manager\nThe Registrar Manager is a contract that becomes the owner of all registrar controllers. Its key properties:\na) Exposes a permissionless withdraw() function that anyone can call. When called, it pulls ETH from each controller and routes it directly to the endowment.\nb) The destination address is configurable by the DAO through the timelock, so governance can redirect the flow at any time.\nc) Acts as a pass-through for governance calls, meaning the DAO retains full control over controller parameters.\nd) New controllers can be added over time.\ne) Never holds funds.\nSource code of Registrar Manager contract.\nEndowment Zodiac Module\nThe Zodiac module is already part of how the endowment is managed. This proposal adds a scoped permission that allows the treasury manager (Karpatkey) to send ETH and USDC to wallet.ensdao.eth without a proposal. It cannot send to any other address or use any other token. All other endowment operations remain unchanged.\nFunding Policy\nThis is the current suggestion for the funding policy.\nThe timelock maintains a 6 months runway in USDC (~$8M at current spending). Each quarter, Karpatkey calculates the current runway on the timelock. If it falls below 6 months, the endowment sends the shortfall. If it exceeds 6 months, no transfer is needed and the excess stays invested in the endowment. If an additional governance proposal requiring capital is approved, this may trigger an earlier runway evaluation and transfer, consistent with this policy.\nThe initial policy is included in this executable proposal, so no separate vote is needed to get started.\nAny future changes to the funding policy require a social vote. This establishes clear expectations about responsibilities and decision-making: the treasury manager handles routine rebalancing within the policy, and the community sets the policy itself.\nThis proposal remains aligned with the IPS. The required three-year stablecoin runway is calculated at the Endowment level, including stablecoins held and deployed there, as is currently done. The expansion guidelines reference transferring 33% of protocol revenue to the Endowment. This proposal modifies that mechanism by routing revenue directly to the Endowment to improve operational efficiency and capital deployment.\nImpact\nThe operational funding process is reactive, requiring a full governance cycle for each transfer. Meanwhile, capital that could be earning yield sits idle in controllers and the timelock for several months at a time.\nWith this proposal, capital flows from registrars to the endowment as soon as anyone calls withdraw(). The endowment begins generating yield immediately rather than after several months of governance overhead. Operational funding follows a clear quarterly process based on the two-year runway target, removing the need for ad-hoc proposals.\nTo put this in perspective: looking at the period from January 2024 until now, and considering ETH staking yields if this capital had been allocated to the endowment, a conservative estimate of $1 million in yield was left on the table. This is based on the balances held in the timelock , the current registrar controller , and the old registrar controller (which still have a relevant number of registrations). Going forward, every ETH collected will begin earning yield within days, compounding the DAO's income over time."}
{"url":"https://www.anchor-lang.com/docs/references/no-dna","domain":"www.anchor-lang.com","title":"NO_DNA","hash":"860d30389dd7cdede8f83dcd7ca70bfd32da80b4ec1acec2ab05dd40c9574b6a","tokens":318,"chars":1269,"crawler":"hive-genesis","verified":"unchecked","ts":1791112260801,"text":"Anchor Docs\nGithub Discord Stack Exchange\nProgram Development\nNO_DNA\nReference documentation for Anchor's NO_DNA support\nAnchor supports the NO_DNA convention for non-human CLI usage. See\nno-dna.org . Set NO_DNA to a non-empty value when\ninvoking Anchor from an agent, automation, or another non-interactive workflow\nthat should not block on supported interactive waits or confirmation prompts.\nNO_DNA=1 is the standard example.\nUsage\nPrefix the command:\nNO_DNA = 1 anchor test --detach\nNO_DNA = 1 anchor localnet\nNO_DNA = 1 anchor program close < ACCOUN T > --bypass-warning\nNO_DNA = 1 anchor legacy-idl erase-authority --program-id < PROGRAM_I D > --bypass-warning\nOr export it for a session:\nexport NO_DNA = 1\nanchor test --detach\nDestructive commands stay explicit\nNO_DNA does not auto-confirm destructive actions. For commands such as\nanchor program close and anchor legacy-idl erase-authority , pass the\nexisting explicit bypass flag yourself.\nChecking support from the CLI\nThe CLI help text documents NO_DNA where it applies:\nanchor --help\nanchor test --help\nanchor localnet --help\nanchor program close --help\nanchor legacy-idl erase-authority --help\nPrevious\nAnchor CLI\nNext\nAnchor Version Manager\nOn this page\nUsage Checking support from the CLI\nEdit on GitHub"}
{"url":"https://www.helius.dev/docs/gatekeeper/overview","domain":"www.helius.dev","title":"Gatekeeper (Beta) - Helius Docs","hash":"203c46da322e99e8136f1612d46e9165411e077122070a7349cb2739d1e094fd","tokens":1968,"chars":7870,"crawler":"crawler-tpoe","verified":"exact","ts":1791112261556,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNew: Try Gatekeeper (Beta) for significantly lower latency. Learn More\nHelius Docs home page\n- Support\n-\nGet started\nHelius Docs home page\nGatekeeper (Beta)\nHeliusâs high-performance edge gateway purpose-built for Solana\nGatekeeper is Heliusâs new edge gateway, now in public beta, that removes Cloudflare from the critical path. Eliminating our edge latency unlocks the true speed of our core APIs and servicesâresponse time improvements range from tens to hundreds of milliseconds.\nGatekeeper acts as a single, unified entry-point for all requests (e.g., JSON-RPC, WebSockets, and Helius APIs): it terminates connections at geographically distributed edge locations, and intelligently routes requests to our backend infrastructure.\nFor latency-critical workloads, Gatekeeper provides the shortest network path, reducing hops and shaving off milliseconds.\nQuickstart\nTo use Gatekeeper, replace your existing endpoint with the Gatekeeper (Beta) endpoint:\nconst url = \"https://mainnet.helius-rpc.com?api-key=YOUR_API_KEY\" ;\nconst url = \"https://beta.helius-rpc.com?api-key=YOUR_API_KEY\" ;\nThatâs it!\nYour existing API key works without any additional changes.\nSupported Methods\nGatekeeper currently supports:\n- All standard Solana RPC endpoints\n- All Helius-specific RPC endpoints (e.g., gTFA)\n- All Helius WebSocket endpoints (standard Solana methods plus the Helius extensions like transactionSubscribe )\n- Parsed Streams ( parsedTransactionSubscribe )\n- All DAS API endpoints\n- All Photon API endpoints (i.e., ZK Compression)\n- The Helius Priority Fee API\n- The Enhanced Transactions API\nCurrently not supported : LaserStream is not yet available on Gatekeeper. Continue using the dedicated LaserStream endpoints for gRPC connections.\nUsage Examples\nconst url = `https://beta.helius-rpc.com?api-key= ${ YOUR_API_KEY } ` ;\nconst response = await fetch ( url , {\nmethod: 'POST' ,\nheaders: { 'Content-Type' : 'application/json' },\nbody: JSON . stringify ({\njsonrpc: '2.0' ,\nid: 1 ,\nmethod: 'getLatestBlockhash' ,\nparams: []\n})\n});\nconst data = await response . json ();\nconsole . log ( data );\nimport requests\nurl = f \"https://beta.helius-rpc.com?api-key= { YOUR_API_KEY } \"\nresponse = requests.post(url, json = {\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"getLatestBlockhash\" ,\n\"params\" : []\n})\nprint (response.json())\nuse reqwest;\nuse serde_json :: json;\n#[tokio :: main]\nasync fn main () -> Result <(), Box < dyn std :: error :: Error >> {\nlet url = format! ( \"https://beta.helius-rpc.com?api-key={}\" , YOUR_API_KEY );\nlet client = reqwest :: Client :: new ();\nlet response = client\n. post ( & url )\n. json ( & json! ({\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"getLatestBlockhash\" ,\n\"params\" : []\n}))\n. send ()\n. await ? ;\nlet data = response . json :: < serde_json :: Value >() . await ? ;\nprintln! ( \"{:?}\" , data );\nOk (())\n}\ncurl https://beta.helius-rpc.com?api-key=YOUR_API_KEY \\\n-X POST \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"jsonrpc\": \"2.0\",\n\"id\": 1,\n\"method\": \"getLatestBlockhash\",\n\"params\": []\n}'\nWebSocket Support\nGatekeeper supports Helius WebSockets â both the standard Solana subscription methods and the Helius extensions ( transactionSubscribe , enhanced accountSubscribe ) â with the same performance improvements.\nconst ws = new WebSocket ( `wss://beta.helius-rpc.com?api-key= ${ YOUR_API_KEY } ` );\nws . on ( 'open' , () => {\nws . send ( JSON . stringify ({\njsonrpc: '2.0' ,\nid: 1 ,\nmethod: 'transactionSubscribe' ,\nparams: [\n{\naccountInclude: [ 'YOUR_ACCOUNT_ADDRESS' ]\n},\n{\ncommitment: 'confirmed' ,\nencoding: 'jsonParsed' ,\ntransactionDetails: 'full' ,\nshowRewards: true ,\nmaxSupportedTransactionVersion: 1\n}\n]\n}));\n});\nws . on ( 'message' , ( data ) => {\nconsole . log ( 'Transaction:' , JSON . parse ( data ));\n});\nWhat to Expect\nDuring the beta period:\n- Lower Latency - Significantly faster response times across the board\n- Better Performance Under Load - Improved reliability during high-traffic periods\n- More Consistent Response Times - Reduced variance in latency\n- Improved WebSocket Stability - More reliable real-time connections\n- Full API Compatibility - All existing RPC methods work identically\n- Same Pricing - No additional cost for beta access\n- Global Distribution - Edge nodes across multiple continents\nWho should use Gatekeeper?\nGatekeeper is ideal for applications where performance matters:\n- High-Frequency Applications - Any app where latency matters\n- Trading Bots - Maximum speed for arbitrage opportunities\n- DeFi Protocols - Real-time price feeds and fast transaction submission\n- Gaming Applications - Low response times for smooth UX\n- NFT Marketplaces - Instant minting and low-latency queries\nMigration Checklist\n1\nUpdate Your Endpoint\nChange mainnet.helius-rpc.com to beta.helius-rpc.com in your code\n2\nTest in Development\nRun your test suite to verify everything works as expected\n3\nMonitor Performance\nCheck your metricsâyou should see improved latency and more consistent response times\n4\nDeploy to Production\nOnce verified, deploy your changes to production\nRollback\nIf you need to rollback for any reason, simply switch back to the standard endpoint:\nconst url = \"https://mainnet.helius-rpc.com?api-key=YOUR_API_KEY\" ;\nLimitations & Known Issues\nBeta Status : Gatekeeper is production-ready but still being optimized. We recommend testing in development before switching production traffic.\nNot yet supported:\n- LaserStream : Use the dedicated LaserStream endpoints for gRPC connections\nCurrent status:\n- Some advanced features are still being rolled out\n- Weâre continuously optimizing routing algorithms\n- Performance improvements are ongoing\nRollout Plan\nGatekeeper is currently opt-in while we optimize performance and gather feedback.\nTimeline:\n- Now : Public beta available to all users\n- Coming Weeks : Additional optimizations and performance improvements\n- Coming Months : Gradual migration of all traffic to Gatekeeper as the default\nFeedback & Support\nWeâre actively monitoring Gatekeeperâs performance and would love your feedback:\n- Issues or questions? Contact support@helius.dev\n- Join our Discord for real-time discussion: https://discord.com/invite/6GXdee3gBj\n- Report bugs through your developer dashboard\nFAQs\nDo I need a new API key?\nNo. Your existing API key works with Gatekeeper without any changes.\nWill Gatekeeper cost extra?\nNo. Gatekeeper is available at no additional cost. Your existing pricing plan applies.\nWhat endpoints are supported on Gatekeeper?\nAll JSON-RPC endpoints are fully supported, including standard Solana RPC methods, Helius-specific RPC endpoints (e.g., gTFA), DAS, Photon, Priority Fee API, and the Enhanced Transactions API. WebSockets â both the standard Solana subscription methods and the Helius extensions like transactionSubscribe â are also supported, as is Parsed Streams .\nWhat endpoints are not yet supported on Gatekeeper?\nLaserStream is not yet available on Gatekeeper. For gRPC connections, use the dedicated LaserStream endpoints .\nWhat if I encounter issues using Gatekeeper?\nYou can easily rollback by switching back to mainnet.helius-rpc.com . Contact support if you need help.\nWhen will Gatekeeper become the default?\nWeâre planning a gradual rollout over the coming months. Weâll notify all users before making any changes to the default Helius endpoints.\nCan I use Gatekeeper on Solana Devnet or Testnet?\nNo, Gatekeeper is currently only available on Solana Mainnet. Solana Devnet and Testnet support is coming soon.\nGet Started\nTry Gatekeeper\nMigrate to Gatekeeper in less than 5 minutes\nLearn About Gatekeeper\nRead our blog to understand how Gatekeeper works\nWas this page helpful?\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.helius.dev/docs/rpc/accounts","domain":"www.helius.dev","title":"How to Get Solana Account Data - Helius Docs","hash":"74c0d8c0554feb3e7039a84941510c89e66cf0ef0a1719dd54a5ae740e7cb1e0","tokens":818,"chars":3270,"crawler":"hive-genesis","verified":"unchecked","ts":1791112262647,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNew: Try Gatekeeper (Beta) for significantly lower latency. Learn More\nHelius Docs home page\n- Support\n-\nGet started\nHelius Docs home page\nData APIs & RPCs\nHow to Get Solana Account Data\nRead Solana account state with standard RPC methods â getAccountInfo, getMultipleAccounts, getProgramAccounts, and getBalance.\nWhat is account data?\nEvery piece of state on Solana lives in an account â wallets, token accounts, and program (smart-contract) state. Account methods read that state directly by address: the raw or parsed data, the owning program, the lamport (SOL) balance, and rent metadata.\nFor higher-level token and NFT data, use the Tokens & NFTs APIs instead of raw account reads. For transaction history, see Transactions .\nWhich method should I use?\nWhat you need Use this\nThe full contents of one account getAccountInfo\nSeveral accounts in a single request (up to 100) getMultipleAccounts\nEvery account owned by a program, with filters getProgramAccounts\nJust the SOL balance of an account getBalance\nKey methods\ngetAccountInfo\nFull account state for a single address â data, owner, lamports, and rent epoch.\ngetMultipleAccounts\nFetch up to 100 accounts in one call â the efficient way to read many accounts at once.\ngetProgramAccounts\nEvery account owned by a program, with memcmp and dataSize filters for targeted queries.\ngetBalance\nThe lamport (SOL) balance of a single account.\nQuickstart\nRead a single account with getAccountInfo . Every Solana RPC call goes to the same endpoint with your API key from dashboard.helius.dev .\nconst response = await fetch ( `https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY` , {\nmethod: 'POST' ,\nheaders: { 'Content-Type' : 'application/json' },\nbody: JSON . stringify ({\njsonrpc: '2.0' ,\nid: '1' ,\nmethod: 'getAccountInfo' ,\nparams: [ '86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY' , { encoding: 'jsonParsed' }],\n}),\n});\nconst { result } = await response . json ();\nconsole . log ( result . value );\nimport requests\nurl = \"https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY\"\npayload = {\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : \"1\" ,\n\"method\" : \"getAccountInfo\" ,\n\"params\" : [ \"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\" , { \"encoding\" : \"jsonParsed\" }],\n}\nprint (requests.post(url, json = payload).json()[ \"result\" ][ \"value\" ])\ncurl https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY \\\n-X POST \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"jsonrpc\": \"2.0\",\n\"id\": \"1\",\n\"method\": \"getAccountInfo\",\n\"params\": [\"86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY\", { \"encoding\": \"jsonParsed\" }]\n}'\nReading many accounts? Use getMultipleAccounts with an array of addresses instead of looping getAccountInfo â one request returns up to 100 accounts.\nNext steps\ngetAccountInfo reference\nFull parameters, encodings, and response schema.\nTokens & NFTs\nFor token balances and NFT data, the DAS API is higher-level than raw account reads.\nTransactions\nQuery transaction and transfer history for an address.\nAll RPC methods\nBrowse the complete Solana RPC method reference.\nWas this page helpful?\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.base.org/get-started/creators","domain":"docs.base.org","title":"Creators - Base Documentation","hash":"8b8fa73e59e9ab1557a13aaee195d18f20ade1cc6e79cfc8ca1c95d39c25d76d","tokens":223,"chars":892,"crawler":"crawler-tpoe","verified":"exact","ts":1791112263175,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBase Documentation home page\nGet Started\nBuild on Base\nSpecifications\nSDKs & APIs\nUpgrades\nResources\nCreators\nGrant support from Base for independent creators making content about Base.\nCreator Grant Program\nWeâre backing independent creators with up to $4,000 who are already making great content around Base across:\n- Writers covering Base (deep dives, memes, analysis, threads)\n- Streamers and live-show hosts\n- Creators running a recurring podcast or show\n- Independent video creators\n- Educators covering Base in their own language\nFill out the application below to be included in our next cohort.\nApply\nWas this page helpful?\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.polkadot.com/apps/build/deploy-a-smart-contract/","domain":"docs.polkadot.com","title":"Add a Smart Contract to Your Product | Polkadot Developer Docs","hash":"79530ba93b2115313dddfa1c4470e2dffc1f56a508b2858bd09d23353f5a03b6","tokens":4039,"chars":16153,"crawler":"hive-genesis","verified":"unchecked","ts":1791112264409,"text":"Skip to content\nInitializing search\n- Concepts\n- Build\n- Deploy Your App\n- Register a .dot Domain\n- List Your App\n- Product SDK\n- Tutorials\n- Troubleshooting\n- Smart Contracts\n- Cookbook\n- Deploy an ERC-20\n- Deploy an NFT\n- Create a DApp\n- Port Ethereum DApps\n- Uniswap V3\n- Precompiles\n- Development Environments\n- Libraries\n- Integrations\n- Parachains\n- Customize Your Runtime\n- Test Your Runtime\n- Maintain and Upgrade Your Parachain\n- Enable Interoperability\n- Integrations\n- Chain Interactions\n- Send Transactions\n- Manage Tokens\n- Store Data\n- Manage Accounts\n- Node Infrastructure\n- Parachain RPC Node\n- Run a Validator\n- Operational Tasks\n- Staking Mechanics\n- Run a Collator\n- Tech Reference\n- Asset Management\n- Bridging\n- People and Identity\n- Collectives and DAOs\n- Data Storage\n- Parachains\n- Accounts\n- Blocks, Transactions, and Fees\n- Node and Runtime\n- Interoperability\n- Randomness\n- Cryptography\n- Data Encoding\n- Chain Data\n- Networks\n- On-Chain Governance\n- App Development\n- Polkadot Desktop\n- Polkadot Web\n- Protocol\n- Infrastructure\n- Statement Store\n- dotNS\n- Proof of Personhood\n- HOP\n- Skills\n- Glossary\n- Tools\n- AI Resources\n- Support\n- Policies\nPage actions\nEdit this page Report an issue\nAdd a Smart Contract to Your Product ¶\nAdvanced\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nIntroduction ¶\nSome Products need on-chain logic and shared state that no single user owns: a leaderboard, a registry, an escrow, a game whose rules must be enforced for everyone. That is what a smart contract gives you. This guide adds a PolkaVM contract to a Product , deploys it to Asset Hub , and calls it from your frontend with the @parity/product-sdk-contracts package.\nContracts on Polkadot run as PolkaVM bytecode through the pallet-revive runtime on Asset Hub . You author them in Rust or Solidity, and the Contract Dependency Manager ( cdm ) builds, deploys, and registers them, the same tool the playground CLI runs for you when it deploys a Product that has contracts. cdm fills the role npm fills for libraries, but for on-chain contracts: it publishes each contract under a global name ( @scope/name ) in an on-chain registry, so your frontend resolves it by name instead of hardcoding an address.\nContracts are optional\nMany Products never need a contract. If all you need is durable content or real-time state between users, Store Data on Chain and Publish and Subscribe to Off-Chain Data cover those without any contract at all. Reach for a contract when you need enforced, shared on-chain logic.\nPrerequisites ¶\nBefore starting, ensure you have:\n- A Polkadot Product project running locally. See Set Up Your Project .\n- PAS funds and a Bulletin Chain authorization for the account cdm will sign with. See Get TestNet Tokens . Deploying a contract writes to Asset Hub (fees) and publishes metadata to the Bulletin Chain (authorization). The next two sections cover installing cdm and creating that account.\n- A workstation rather than a browser alone. Contracts compile to PolkaVM, so unlike the frontend capabilities this step needs a local toolchain.\nInstall cdm ¶\nInstall the cdm binary. The installer also pulls the Rust nightly toolchain with rust-src and the cargo-pvm-contract build tool:\ncurl -fsSL https://raw.githubusercontent.com/paritytech/contract-dependency-manager/main/install.sh | bash\nUpdate an existing install with cdm update .\ncdm and playground are separate installs\nInstalling the playground CLI does not give you cdm , and vice versa. playground deploy shells out to its own bundled CDM pipeline for the contract step, but running cdm directly, as this guide does, needs the binary on your PATH .\nSet Up a Signing Account ¶\ncdm signs from the CLI with its own keypair, separate from the account your phone holds. Generate one for the network, then map it for pallet-revive :\ncdm init -n paseo\ncdm account map -n paseo\nThe mapping step is required before your first deploy: pallet-revive needs each signing account bound to its H160 address, and without it the deploy fails. Two related subcommands are useful while you work:\n- cdm account bal -n paseo : Prints the account's balance and its Bulletin allowances, and links to a top-up when they run low.\n- cdm account set -n paseo --mnemonic \"âŠ\" : Imports an existing account instead of generating one.\ncdm 's paseo preset is Paseo Next, not the Paseo TestNet\ncdm -n paseo targets the Paseo Asset Hub preview network (para 1500), the same network the playground CLI deploys to. cdm -n devnet targets the Paseo TestNet Asset Hub (para 1000) with a registry operated by the Polkadot Community Foundation. They are different chains with different registries, so a contract deployed under one preset is not resolvable under the other. Fund the account on the network you actually target â the faucet needs ?parachain=1500 for Paseo Next.\nHow Contracts Fit Together ¶\nFour things happen when you publish a contract, and cdm handles all of them in one flow:\n- Build : Your Rust or Solidity contract compiles to PolkaVM bytecode targeting pallet-revive (Solidity via resolc ).\n- Deploy : The bytecode is instantiated on Asset Hub at a deterministic address.\n- Publish metadata : The contract's ABI and docs are uploaded to the Bulletin Chain, addressed by CID.\n- Register : The contract's global name ( @scope/name ) is recorded in the on-chain ContractRegistry , mapping the name to its address and metadata CID.\nYour frontend then reads a project-local manifest, cdm.json , which holds the deployed address and ABI for each contract your Product depends on. The @parity/product-sdk-contracts package turns that manifest into typed contract objects.\nThe registry is append-only\nRegistration is permanent: the first account to publish a name owns it, versions only ever increment, and nothing can be overwritten or deleted. Do not publish a name you are only testing with as your real account, and never register anything you want to keep from a shared dev account such as //Alice .\nScaffold a Contract ¶\ncdm ships example templates. Scaffold the shared-counter template, which defines a minimal counter contract you can adapt:\ncdm template shared-counter\nThat writes a Cargo workspace and a cdm.json manifest into ./shared-counter . Pass a target directory to override the location, or . to scaffold into the current directory. The template ships three crates under contracts/ that demonstrate a dependency graph: counter holds the shared count, counter-writer calls counter.increment() through a CDM reference, and counter-reader queries counter.get_count() .\nA fuller example\ncdm template instagram scaffolds a complete browser app rather than bare contracts, combining Product Account signing, Bulletin uploads, and ContractManager resolution from cdm.json . Reach for it when you want to read a working end-to-end Product instead of assembling one.\nEach crate declares its CDM package name in its own Cargo.toml :\ncontracts/counter/Cargo.toml\n[package.metadata.cdm]\npackage = \"@example/counter\"\nThe contract itself is a module holding a storage struct and an impl block, annotated with the PolkaVM contract SDK macros:\ncontracts/counter/lib.rs\n#![cfg_attr(not(feature = \"abi-gen\" ), no_main, no_std)]\n#[pvm_contract_sdk::contract(allocator = \"pico\" , allocator_size = 1024)]\nmod counter {\nuse pvm_contract_sdk :: Lazy ;\npub struct Counter {\n// Storage slots are auto-numbered in declaration order (`count` gets slot 0).\ncount : Lazy < u32 > ,\n}\nimpl Counter {\n#[pvm_contract_sdk::constructor]\npub fn new ( & mut self ) {\nself . count . set ( & 0 );\n}\n#[pvm_contract_sdk::method]\npub fn increment ( & mut self ) {\nlet current = self . count . get ();\nself . count . set ( & ( current + 1 ));\n}\n#[pvm_contract_sdk::method]\npub fn get_count ( & self ) -> u32 {\nself . count . get ()\n}\nNote that the constructor takes &mut self and initializes storage in place; it does not return Self . Storage fields are wrapped in Lazy so each is read and written on demand rather than loaded wholesale.\nBefore deploying, change every [package.metadata.cdm] package = \"@example/âŠ\" entry in the workspace to a scope you control, for example @my-app/counter . Package names are global per registry, the scaffolded @example scope is a placeholder, and registration is first-writer-owns, so you want your own scope on all three crates.\nPrefer Solidity?\ncdm also ships Solidity templates ( foundry-counter and hardhat-counter ) that compile to PolkaVM via resolc . Scaffold one the same way, for example cdm template foundry-counter . The deploy and frontend steps below are identical regardless of the contract language.\nVerify the Toolchain ¶\nThe cdm installer already set up the Rust nightly, rust-src , and cargo-pvm-contract that the contract compiler needs. Confirm they are in place before your first build:\ncdm setup --check\nIf anything is missing or was broken by an unrelated Rust change, cdm setup installs or repairs it:\ncdm setup\nBuild and Deploy ¶\nDeploy with cdm deploy , selecting the target network with -n . This builds the bytecode, deploys it to Asset Hub , uploads the ABI to the Bulletin Chain , and registers the name, all in one flow:\ncdm deploy -n paseo --suri \"INSERT_ACCOUNT_SECRET_URI\"\ncdm signs from the CLI with the account you pass as --suri , or with the keypair cdm init generated for the network. It does not sign through the Polkadot App or a phone. The -n preset also selects the registry for the network, so you do not set a registry address by hand.\nAlways pass a signer you control\nWith no --suri and no cdm init account, cdm falls back to the shared //Alice development key. Because registration is first-writer-owns, deploying that way parks your contract name on a public key anyone can use. Pass --suri (or run cdm init first) so the name and contract belong to you.\nDeploying alongside your Product\nWhen you deploy the whole Product with playground deploy , the CLI runs this contract step for you. At the did you change your smart contracts? prompt, choose yes and the CLI redeploys the contracts and rebuilds the site to match. Use cdm deploy directly when you want to iterate on the contract on its own, without redeploying the frontend.\nAdd the Contract to Your Manifest ¶\nYour frontend resolves contracts from cdm.json , and cdm deploy does not write that file â cdm install does. After deploying, install your contract to write its address and ABI into the manifest. Installing works the same for a contract someone else published, so pass whichever @scope/name you need:\ncdm install @my-app/counter -n paseo\ncdm install resolves the name against the on-chain registry, fetches the ABI from the Bulletin Chain , and writes the entry into cdm.json :\ncdm.json\n{\n\"dependencies\" : {\n\"@my-app/counter\" : \"latest\"\n},\n\"contracts\" : {\n\"@my-app/counter\" : {\n\"version\" : 1 ,\n\"address\" : \"0xâŠ\" ,\n\"abi\" : [ /* ⊠*/ ],\n\"metadataCid\" : \"bafyâŠ\"\n}\nThe shared-counter template ships its cdm.json already populated for the example contracts, so you only run cdm install when you deploy your own contract or add someone else's.\nCall the Contract From Your Frontend ¶\nInstall the contracts package (or use the umbrella @parity/product-sdk ):\nnpm install @parity/product-sdk-contracts @parity/product-sdk-chain-client @parity/product-sdk-descriptors @parity/product-sdk-signer\nBuild a ContractManager from the manifest and the host-routed chain client, map your signing account once (every contract write fails with AccountNotMapped until you do), then get a typed handle by name. Reads use query (a dry run â check .success ), and writes use tx (which signs through the Host â check .ok ):\nimport { SignerManager } from '@parity/product-sdk-signer' ;\nimport { createChainClient } from '@parity/product-sdk-chain-client' ;\nimport { paseo_asset_hub } from '@parity/product-sdk-descriptors/paseo-asset-hub' ;\nimport {\nContractManager ,\nensureContractAccountMapped ,\n} from '@parity/product-sdk-contracts' ;\nimport cdmJson from './cdm.json' ;\nasync function useCounter () {\n// The same SignerManager setup as Sign and Submit Transactions.\nconst signerManager = new SignerManager ({ ss58Prefix : 0 , dappName : 'my-app.dot' });\nconst connected = await signerManager . connect ();\nif ( ! connected . ok ) return ;\nconst productAccount = await signerManager . getProductAccount ( 'my-app.dot' , 0 );\nif ( ! productAccount . ok ) return ;\nconst account = productAccount . value ;\nconst signer = account . getSigner ();\nconst client = await createChainClient ({ chains : { assetHub : paseo_asset_hub } });\nconst manager = ContractManager . fromClient (\ncdmJson ,\nclient . raw . assetHub ,\npaseo_asset_hub ,\n{ signerManager },\n);\n// pallet-revive requires each signing account to be mapped once.\nawait ensureContractAccountMapped ( manager . getRuntime (), account . address , signer );\nconst counter = manager . getContract ( '@my-app/counter' );\n// Read: a dry run. Check .success before reading .value.\nconst count = await counter . getCount . query ();\nif ( count . success ) {\nconsole . log ( count . value );\n}\n// Write: signs through the Host. Returns a Result â check .ok.\nconst result = await counter . increment . tx ({ signer });\nif ( ! result . ok ) {\nconsole . error ( result . error . message );\n}\nPassing signerManager to fromClient lets the manager resolve the current account at call time, so an account switch is picked up without rebuilding it. See Sign and Submit Transactions for the signing setup in depth. Contract writes are signed by your Product-scoped account, so they route to the user's phone for approval like any other transaction. For the full frontend surface, see Contracts .\nquery returns a status, tx returns a Result\nquery is a dry run that does not throw on a revert; branch on .success , because on failure .value holds the dispatch-error payload, not your data. tx returns a Result ; check .ok before assuming the write landed.\nRedeploy After a Contract Change ¶\nContracts are immutable once deployed. Changing contract code means deploying a new version: run cdm deploy -n paseo --suri ... again (or choose yes at the contract prompt in playground deploy ). The registry appends a new version under the same name; run cdm install @my-app/counter -n paseo afterward to refresh the address and ABI in cdm.json so your frontend picks up the new deployment.\nBecause a redeploy gives your contract a new on-chain address, existing users pointed at the old address keep using the old contract until they load the new bundle. Storage does not move with it: the new instance starts empty, and the old one keeps serving whoever has not reloaded.\nFor a contract with live users and stored state, that makes a redeploy a migration rather than an update. What it takes:\n- Snapshot the old state before you redeploy. Read it out through the old contract's query methods while its address is still the one in cdm.json , since afterward you need the previous address to reach it.\n- Seed the new instance from that snapshot, or give the contract a method that accepts it, before pointing users at the new address.\n- Keep reading from the old address until the new one is populated , so users who reload mid-migration do not see an empty contract.\n- Expect a window where both are live. Users on the old bundle keep writing to the old address until they reload, so either accept losing those writes or drain them after the fact.\nNone of that is automated. If your contract will hold state you cannot afford to lose, design for it up front â an explicit initializer that accepts prior state costs far less than reconstructing one later.\nWhere to Go Next ¶\n-\nGuide Deploy Your App\nDeploy the whole Product, contracts and frontend together, and register a .dot name with the playground CLI.\nDeploy Your App\n-\nExternal Product SDK API Reference\nThe full @parity/product-sdk-contracts surface: ContractManager , contract handles, and the query , tx , and prepare methods.\nVisit Site\n-\nExternal Contract Dependency Manager\nThe cdm toolchain in depth: templates, the registry model, versioning, and installing published contracts.\nVisit Repo\nLast update: September 2, 2026\n| Created: September 2, 2026"}
{"url":"https://forum.skyeco.com/t/about-the-spark-prime-category/20681","domain":"forum.skyeco.com","title":"About the Spark Prime category - Spark Prime - Sky Forum","hash":"004d5b5cc1f17f574c1c1efb5dc95fec44f23f8745a83636f798adeade6273e0","tokens":76,"chars":303,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112265147,"text":"Sky Forum\nAbout the Spark Prime category\nSpark Prime\necosystem-team\nApril 28, 2023, 2:33pm\n1\nEnter the world of Allocators with the Spark Prime. This category is dedicated to business and finance specialists who manage vaults and collateral operations at Sky. Join the Spark Prime Discord here .\n4 Likes"}
{"url":"https://discuss.ens.domains/t/ens-advisor-buy-an-expiring-eth-name-at-your-budget-without-handing-anyone-your-eth-plus-a-weekly-eth-sales-report/22450","domain":"discuss.ens.domains","title":"ENS Advisor: buy an expiring .eth name at your budget without handing anyone your ETH, plus a weekly .eth sales report -","hash":"c8cbc234cd204c5ce2154064266c703e302bea2030457fc8a135dfb56784163a","tokens":763,"chars":3051,"crawler":"hive-genesis","verified":"unchecked","ts":1791112266268,"text":"ENS DAO Governance Forum\nENS Advisor: buy an expiring .eth name at your budget without handing anyone your ETH, plus a weekly .eth sales report\nđ± ENS Ecosystem\nCommunity\nSaylool\nOctober 1, 2026, 12:43pm\n1\nHi everyone. Iâm Samet, a solo builder from TĂŒrkiye. Over the past months I built ENS Advisor ( https://ensdesk.com ), a research desk for .eth names, and Iâd like to share whatâs live and hear what youâd want changed.\nWhat it does today\n- Public data pages, no sign-in:\n- This weekâs opportunities : names leaving grace or in the premium auction this week, verified on chain and scored, with category views ( premium , 3â4 characters , numbers , words and brandables ). For premium names it shows the day the price falls under $1,000 and $100.\n- Weekly sales report : the highest .eth sales of the week and month from OpenSea, volume, median and price by name length. Every sale is checked against the Ethereum transaction; doubtful records are left out.\n- A page per name, e.g. vitalik.eth : status, price, a score with its reasons, comparable sales and the ownerâs public contact records.\n- Register or renew from your own wallet: âRegister nowâ sends the commit and register transactions from your wallet straight to the ENS controller; renewals go through NameHashâs referrer-aware renewal contract. The site never holds funds.\n- âRegister it for me when it reaches my budgetâ: set a budget for a premium name and grant a MetaMask spending permission (ERC-7715) that is limited to one contract, one amount and an expiry. The moment the premium decays to your budget, the bot registers the name to your wallet , charges only the actual price plus the gas it used, and refunds the rest in the same transaction. Failed attempts cost nothing; the permission canât move ETH anywhere else; you can revoke it in MetaMask any time. The contract (0x0c1029192A16264cDE932d7bdcC19fc5963602c4) is verified on Sourcify with an exact match, so you can read the source: 0x0c1029192A16264cDE932d7bdcC19fc5963602c4 on Ethereum Mainnet (1)\n- Watchlists, Telegram and e-mail alerts, portfolio with renewal reminders, CSV export, an API and an MCP server for agents.\nWhy I built it this way\nThe .com world learned that âbackorder, pay only on successâ is the durable business, and that services which hold customer money end badly (we saw ENS Vision leave names locked when it shut down). So the design rule here is: money goes from your wallet to ENS, never through us. The bot spends a scoped permission, not a deposit.\nWhatâs next / questions for you\n- ENSv2: both registration paths will be rebuilt for the new registrar and stablecoin pricing when it reaches mainnet.\n- The weekly sales report is meant to become the NameBio of .eth: which venues and data would you want included?\n- Pricing is $10/month for the research features; the bot is part of it. A larger âInvestorâ tier is coming.\nFeedback, bug reports and âthis is wrong becauseâŠâ are all welcome here or at sametgoc81tr@gmail.com . Thanks for reading.\n1 Like\nENS DAO Newsletter #121 â 10/1/2026"}
{"url":"https://docs.lightning.engineering/the-lightning-network/l402/l402","domain":"docs.lightning.engineering","title":"L402 | Builder's Guide","hash":"6c4f0f7eb67bc79b1dc95881e87b0619f707802cd3957a2716c8cdd574e255c9","tokens":1257,"chars":5028,"crawler":"crawler-tpoe","verified":"exact","ts":1791112267114,"text":"Builder's Guide\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nL402\nLightning API keys (L402) are Macaroons that include a payment hash. For the L402 to be valid, it must be presented together with the preimage corresponding to the payment hash.\nLightning API keys (L402) leverage the capabilities of Macaroons and the programmatic characteristics of the Lightning Network to create a mechanism that allows distributed systems to authenticate a user and payment receipt. This authentication occurs without requiring access to a central database of users or invoices.\nL402 are a cornerstone to building metered APIs for the machine-to-machine economy, without logins, e-mail addresses or passwords.\nAn L402 is a Macaroon together with the preimage of a Lightning Network payment. The Macaroon is transmitted to the user over HTTP together with a Lightning invoice and contains the payment hash of the invoice as a caveat.\nTo be a valid L402, the user needs to present two pieces of information:\n-\nThe partial L402, being the Macaroon including the payment hash\n-\nThe preimage, which can be obtained by paying the Lightning invoice\nAs the payment hash is a hash of the preimage, and as the preimage can only be obtained through paying the Lightning invoice in full, it is easy for anyone with the root key to verify:\n-\nThat the L402 was issued by the appropriate authority\n-\nThat the L402 carries the relevant capabilities\n-\nThat the Lightning invoice has been paid\nsecret,id12345678id,api.domain.com,your macaroon\npayment_hash=1107feb30b42fd1a1648c9862006452a8092baa3b62fc474cb43bf42066a0b06\nHMAC(secret,4c4ab7a4f7a9,api.domain.com,your macaroon)\npreimage=79852a0791225dee00be0a6cf31a1619782c21d35995e118bfc74ad812174035\nL402 specification\nTo make for a valid L402, a Macaroon must adhere to the following characteristics:\nVersion - A version allows for an iterative macaroon design.\nidentifier:\nversion = 0\nUser Identifier - A unique user identifier allows services to track users across distinct macaroons serving useful in the context of service level metering. A user identifier of 32 random bytes is used instead of the macaroonâs identifier because the latter can be revoked, e.g., in the case of a service tier upgrade.\nidentifier:\nuser_id = fed74b3ef24820f440601eff5bfb42bef4d615c4948cec8aca3cb15bd23f1013\nPayment Hash - A payment hash links an invoiceâs payment request to the macaroon. Once the payment request is fulfilled, the payer receives its corresponding preimage as proof of payment. This proof can then be provided along with the macaroon to ensure an L402 has been paid for without checking whether the invoice has been fulfilled.\nidentifier:\npayment_hash = 163102a9c88fa4ec9ac9937b6f070bc3e27249a81ad7a05f398ac5d7d16f7bea\nCaveats\nThere is no limit to what caveats you may define for your service. For Lightning Labs services, three types of caveats are used, which are covered below. Each caveat consists of a key and value pair, separated by an equal (=) sign.\nTarget Services\nThe caveat âservicesâ lists which services a L402 is authorized to access. This can be a comma separated list of multiple services, as well as their tier. Tiers allow for separate levels of access, with the basic tier being 0.\nIn this example the L402 is authorized to access Lightning Loop at tier 0:\ncaveats:\nservices = lightning_loop:0\nService Capabilities\nEach service can be restricted in its capabilities. These caveats have â _capabilities â amended to the service name, followed by a comma separated list of capabilities that the holder of the L402 is allowed to access. If this caveat is not present, the holder has full access to the service. If multiple caveats of this service capability exist in the same L402, each caveat must be more restrictive than the previous one.\nIn this example the bearer of the L402 is authorized to access both Loop Out and Loop In:\ncaveats:\nlightning_loop_capabilities = loop_out,loop_in\nService Constraints\nEach service capability can be further constrained. This is recorded as a separate caveat beginning with the service capability. Similar to capabilities, multiple constraints may be present in a L402, but each constraint needs to be more restrictive than the previous.\nIn the following example the user is allowed to Loop out two million satoshis per month only:\ncaveats:\nloop_out_monthly_volume_sats = 2000000\nL402 Verification\nIn verifying the L402, the server requires the root key with which the original Macaroon was created. This allows the server to verify, line by line, caveat by caveat, that the Macaroon was issued by the appropriate authority and that each caveat was properly amended.\nFinally, the preimage is verified against the payment hash to ensure that all outstanding invoices have been paid.\nLearn how the L402 is obtained in Pool\nGet Aperture\nPrevious Macaroons\nNext Protocol Specification\nLast updated 3 years ago\nWas this helpful?\n- L402 specification\n- Caveats\n- L402 Verification\nWas this helpful?"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/tokens","domain":"docs.openzeppelin.com","title":"Tokens | OpenZeppelin Docs","hash":"2b64ccf728dbe40aa10903b0662ced83a24a7375d9d4c1a6beb7580713048b50","tokens":723,"chars":2891,"crawler":"crawler-tpoe","verified":"exact","ts":1791112268601,"text":"Home Forum Website Impact\nOpenZeppelin Contracts\nTokens\nOpen in Claude\nAh, 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- ERC-20 : the most widespread token standard for fungible assets, albeit somewhat limited by its simplicity.\n- ERC-721 : the de-facto solution for non-fungible tokens, often used for collectibles and games.\n- ERC-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.\nMultisig\nPrevious Page\nOverview\nNext Page\nOn this page\nBut First, Coffee a Primer on Token Contracts Different Kinds of Tokens Standards"}
{"url":"https://ethresear.ch/","domain":"ethresear.ch","title":"Ethereum Research","hash":"aeac2153ff99f0013b362fa9297ddac53a99550ae38d7351145948aeb0b525ce","tokens":819,"chars":3275,"crawler":"hive-genesis","verified":"unchecked","ts":1791112268444,"text":"Ethereum Research\nCivilized discussion furthering Ethereum research\nTopic\nReplies\nViews\nActivity\nRead this before posting\nAdministrivia\n13\n61454\nAugust 20, 2026\nProposal for a minimal compute-anchored purchasing power signal\nEconomics\n0\n41\nOctober 2, 2026\nSix defects in one signature verification tool, found from outside in six rounds\nSecurity\n0\n37\nOctober 2, 2026\nThe Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\nExecution Layer Research\nstateless\n10\n776\nOctober 2, 2026\nMempool Account Transaction Capacity from Historical Activity (MATCHA)\nExecution Layer Research\naccount-abstraction\n,\ntransaction-privacy\n10\n513\nOctober 2, 2026\nStaking rewards as venture capital, governed by futarchy\nEconomics\nfutarchy\n,\ndao\n2\n207\nOctober 1, 2026\nTrust minimized transaction simulation using state proofs\nSecurity\n7\n627\nOctober 1, 2026\nPQ anonymity for Stealth Address Protocol\nPrivacy\n4\n195\nOctober 1, 2026\nLetting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559\nEconomics\neip-1559\n,\nfee-market\n,\nmev\n,\nproposer-builder-separation\n1\n145\nSeptember 30, 2026\nTowards Encrypted Mempools from Threshold IBE without Batching\nCryptography\n4\n230\nSeptember 29, 2026\nEthereum's TCB, Part 1: The client\nSecurity\nsecurity\n3\n335\nSeptember 29, 2026\nPQ spending for Stealth Address Protocol\n0\n61\nSeptember 28, 2026\nEthereum lessons from a live end-to-end PQ proof-native protocol\nArchitecture\npost-quantum\n,\nzero-knowledge\n6\n400\nSeptember 27, 2026\nFormal Verification of Execution and Consensus Clients\nSecurity\nsecurity\n13\n591\nSeptember 25, 2026\nSnappy with a memory: ~40% less gossip traffic\nNetworking\nsingle-slot-finality\n1\n149\nSeptember 25, 2026\nCapacity oracles\nEconomics\n4\n403\nSeptember 25, 2026\nDesigns for EVM gas accounting in EIP-7999\nExecution Layer Research\nfee-market\n7\n457\nSeptember 24, 2026\nProprietary AMMs and Ethereum\nExecution Layer Research\nmev\n13\n1314\nSeptember 24, 2026\nCHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\nExecution Layer Research\nnetworking\n,\np2p\n1\n104\nSeptember 24, 2026\nLattice-based signature aggregation\nCryptography\npost-quantum\n9\n2776\nSeptember 24, 2026\nPost-Poseidon: Hash Function Variants for Ethereum\nCryptography\n0\n301\nSeptember 23, 2026\nEIP-8411 payload segmentation under the Shadow simulator\nNetworking\nscaling\n,\np2p\n1\n79\nSeptember 23, 2026\nEIP-8411: what segmented payload diffusion is made of\nNetworking\nscaling\n,\np2p\n1\n218\nSeptember 23, 2026\nPost-Quantum Lattice or Hash-Based: One Question, Two Right Answers\nCryptography\npost-quantum\n2\n177\nSeptember 22, 2026\nPost-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\nEconomics\n1\n143\nSeptember 22, 2026\nEtheorem update: the complete executable consensus specs written in Lean 4\nConsensus\n0\n189\nSeptember 21, 2026\nEIL: Trust minimized cross-L2 interop\nLayer 2\n19\n4087\nSeptember 20, 2026\nStrict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)\nPrivacy\n0\n52\nSeptember 19, 2026\nEvidence Review Framework for Project Applications in Decentralized Guilds/Agent Systems\nApplications\ndao\n,\ngovernance\n0\n53\nSeptember 19, 2026\nCryptographic canaries and backups\nCryptography\n8\n7554\nSeptember 18, 2026\nnext page â"}
{"url":"https://docs.ens.domains/terminology","domain":"docs.ens.domains","title":"Terminology | ENS Docs","hash":"ecb654c407a4b9686ee1de271d24086684a9229677ba90a5425a5dae02f07bc2","tokens":1691,"chars":6762,"crawler":"hive-genesis","verified":"exact","ts":1791112269753,"text":"Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.\nSkip to content\nTerminology\nThis page contains a glossary of terms used in the ENS documentation.\nName\nAn ENS identifier such as 'alice.eth'. Names may consist of multiple parts, called labels, separated by dots. This also includes DNS names like name.xyz , or subnames like sub.name.eth .\n2LD\nSecond-level domain.\nThis refers to a subname/subdomain of a top-level domain.\nFor example, name.eth and name.com are both second-level names.\nA subname of a 2LD is a third-level domain or 3LD.\nSubname / Subdomain\nA child name like sub.name.eth , whose parent is name.eth . Also referred to as a \"subdomain\". Every name (except for the root node) has a parent. For example, name.eth is a subname of eth .\nsub.name.eth\nTLD\nTop-level domain. This refers to names like eth , com , xyz which lie at the \"top\" of the naming hierarchy.\n.eth .com .xyz\nManager\nThe account that may edit the records of a name. The Manager may be changed by the Owner.\nLabel\nAn individual component of a name, such as 'alice'.\nLabelhash\nThe keccak256 hash of an individual label.\nNamehash\nThe algorithm used to process an ENS name and return a cryptographic hash uniquely identifying that name. Namehash takes a name as input and produces a node .\nNode\nA cryptographic hash uniquely identifying a name.\nOwner\nThe owner of a name is the entity referenced in the ENS registry's owner field. An owner may transfer ownership, set a resolver, and create or reassign subdomains.\nRecord\nA piece of information that an ENS name \"resolves\" to (points to). The most common record is the ETH Address record, which determines what ETH 0x address an ENS name points to.\nRegistration\nA registration is a registrar's record of a user's ownership of a name. This is distinct from the owner field in the Registry; registrations are maintained in the registrar contract and additionally store information on expiry date, fees paid, etc.\nRegistrar\nA registrar is a contract responsible for allocating subdomains. Registrars can be configured at any level of ENS, and are pointed to by the owner field of the registry.\nRegistry\nThe core contract of ENS, the registry maintains a mapping from domain name (at any level - x, y.x, z.y.x etc) to owner, resolver, and time-to-live. All lookups start with the Registry.\nExpiry\nThe date and time at which an ENS name expires.\nThe implications of expiration depend on the type of name it is.\nWhen a .eth 2LD expires (and its grace period elapses), then you lose ownership of the name.\nWhen a wrapped subname expires, you may or may not lose ownership, depending on whether the name was emancipated.\nGrace Period\nThis is a short window of time after an ENS .eth name expires, in which the owner can still renew and retain the name. Currently this window is 90 days.\nTTL\nStands for \"Time To Live\". This is a field in the core registry that can be set alongside the resolver. It can be used as a hint for clients to decide how long to cache resolved data.\nDNS\nThis is the Domain Name Service used by the internet to resolve addresses and other records from human-readable names. ENS aims to be fully complementary and compatible with DNS, and supports easy importing of DNS names via a special DNSSEC registrar.\nDNSSEC\nStands for Domain Name System Security Extensions. When a particular DNS TLD supports DNSSEC, then the owners of names can cryptographically sign records. This allows ENS to support easy importing of DNS names into the ENS registry, as the owner of the DNS name can prove ownership with those signed records.\nResolver\nA resolver is a contract that maps from name to the resource (e.g., cryptocurrency addresses, content hash, etc). Resolvers are pointed to by the resolver field of the registry.\nWildcard Resolver\nThis refers to a resolver that supports ENSIP-10 . This scheme allows clients to resolve data for subnames that either don't have a resolver of their own, or subnames that may not even exist onchain at all. For offchain names, this is typically used in conjunction with CCIP Read .\nPublic Resolver\nThis is a standard resolver contract implementation written by ENS Labs. It supports all record types and anyone can use it. This is the default resolver used when registering a new name via the official manager app.\nOffchain\nThis term is typically used with respect to the Ethereum Mainnet blockchain. If data is not posted to the chain via an actual Ethereum Mainnet transaction, then it is \"offchain\". ENS names can also be offchain. For example names can use a special resolver to resolve records for subnames that don't exist onchain in the Registry. This is also typically done with CCIP Read .\nCCIP Read\nThe \"Cross Chain Interoperability Protocol Read\" specification, also known as EIP-3668 , authored by Nick Johnson, is a specification that allows for secure and trustless offchain data retrieval.\nIt allows for an Ethereum call to defer to an offchain gateway and then securely verify the resulting data onchain.\nWith respect to ENS, this is typically used for offchain subnames that don't exist in the core Registry.\nOffchain Resolution Read more about offchain resolution and CCIP Read here\nPrimary Name\nThe ENS name that you want a particular ETH account to be associated with. When set, it will be displayed instead of your 0x address on integrating websites/apps. This is also often referred to as the \"reverse record\".\nReverse Node\nA node in the Registry that can be claimed for any Ethereum account. The name this node represents is [addr].addr.reverse , where [addr] is the Ethereum public address (lowercase, without the \"0x\"). These reverse nodes are typically used to set a Primary Name for an account.\nReverse Record\nUsually, this is referring to the Primary Name . Technically speaking, a Reverse Node can have multiple records set on it, the same as any node.\nNameWrapper\nWrapped Name\nThe ENS Name Wrapper is a contract for ENS that allows you to \"wrap\" any ENS name into a ERC-1155 NFT. This includes not only .eth 2LDs like name.eth , but also DNS names like name.xyz , or subnames like sub.name.eth .\nFuse\nThe technical term for a specific \"permission\" bit for a wrapped name. As the name implies, once that bit is flipped on, the fuse is burnt and cannot be unburnt (unless the name expires).\nEmancipated\nA name is considered emancipated if it's parent is unable to replace/delete it. This is typically used to describe trustless subnames.\nSubgraph\nAn indexed collection of data using TheGraph protocol.\nIn this documentation portal, \"the subgraph\" usually refers to the official ENS subgraph maintained by ENS Labs.\nThis is a useful offchain service that allows clients to query for information about names or accounts."}
{"url":"https://docs.sui.io/develop/cryptography/","domain":"docs.sui.io","title":"Cryptography","hash":"0fa7600db72aa12ade806298961cc3907ffe48c3c0dc84655e6fe0007d283762","tokens":874,"chars":3495,"crawler":"crawler-tpoe","verified":"exact","ts":1791112270347,"text":"# Cryptography\n*[Documentation index](/llms.txt) · [Full index](/llms-full.txt)*\nCryptographic agility is core to Sui. The system supports multiple cryptography algorithms and primitives and can switch between them rapidly. This flexibility means applications can adopt new cryptographic standards without protocol-level changes.\n## Available primitives\nSui provides the following cryptographic capabilities for smart contracts and applications:\n- **[Signing](/develop/cryptography/signing):** Sui supports multiple signature schemes. User transactions authenticate with Ed25519, ECDSA (secp256k1 and secp256r1), or [passkeys](/develop/cryptography/passkeys), and [multisig](/develop/transactions/transaction-auth/multisig) addresses can combine different schemes in a single address. BLS12-381 signatures are available for validator operations and onchain verification in Move but are not used for user transaction authentication.\n- **[Hashing](/develop/cryptography/hashing):** Move modules can compute SHA2-256, SHA3-256, Keccak-256, and Blake2b-256 hashes onchain for data integrity verification, commitment schemes, and cross-chain interoperability.\n- **[Groth16 verification](/develop/cryptography/groth16):** Verify zero-knowledge proofs onchain using the Groth16 proof system over BN254 and BLS12-381 curves. This enables privacy-preserving applications that verify computations without revealing inputs.\n- **[ECVRF](/develop/cryptography/ecvrf):** Verify Elliptic Curve Verifiable Random Function outputs onchain for applications that need provably fair randomness from an external source.\n- **[Passkeys](/develop/cryptography/passkeys):** Authenticate transactions using WebAuthn passkeys (FIDO2), enabling hardware-backed authentication through biometrics or security keys without managing private keys.\nFor transaction-level authentication including multisig and offline signing, see [Transaction Authentication](/develop/transactions/transaction-auth).\nSui's cryptographic capabilities extend beyond smart contract primitives. For Bitcoin integration through threshold cryptography, see [Hashi](/sui-stack/hashi) (the Sui native Bitcoin orchestrator). For passwordless authentication using device-native key pairs, see [Passkeys](/develop/cryptography/passkeys). For zero-knowledge authentication with OAuth providers, see [zkLogin](/sui-stack/zklogin-integration).\n- [Elliptic Curve Verifiable Random Function](ecvrf) â Elliptic curve verifiable random function is a cryptographic algorithm that enables you to generate a random number and provide proof that the number used a secret key for generation.\n- [Groth16](groth16) â Use the Sui Move API to verify Groth16 zk-SNARK proofs over BN254 or BLS12-381 curves, with examples using the Circom circuit language and Arkworks Rust library.\n- [Hashing](hashing) â Sui supports SHA2-256, SHA3-256, Keccak256, and Blake2b-256 cryptographic hash functions.\n- [Images](images/)\n- [Passkey](passkeys) â Sui supports the passkey signature scheme built on the WebAuthn standard, enabling phishing-resistant transaction signing via hardware security keys, platform authenticators like Face ID, and multisig wallet setups without managing seed phrases.\n- [Signature Verification in Move](signing) â Sui supports verification within Move smart contracts through several signature schemes. Signature schemes include Ed25519, Secp256k1 recoverable, Secp256k1 non-recoverable, Secp256r1 non-recoverable, Secp256r1 recoverable, BLS G1, and BLS G2."}
{"url":"https://docs.berachain.com/general/help/reward-vault-guidelines","domain":"docs.berachain.com","title":"Reward Vault Requirements and Guidelines - Berachain","hash":"d9e42712ed2dd4041be224fce51ba463e2a2067f8019c8f9e54978a9c9478795","tokens":1843,"chars":7370,"crawler":"hive-genesis","verified":"exact","ts":1791112271469,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBerachain home page\nGeneral\nBEX\nBend\nBuild\nNodes\nHelp\nReward Vault Requirements and Guidelines\nEcosystem value, technical requirements, and governance rules for Reward Vault whitelisting and WBERA emissions.\nReward Vaults drive meaningful economic activity on Berachain. To qualify for validator-allocated WBERA emissions , your vault must show that it supports ecosystem goals and creates real user value.\nThis guide captures all essential requirements. For submission forms and the request process, see Reward Vault Governance .\nEcosystem value requirements\nAdds ecosystem utility\n- The vault must boost use or value of BERA or other major assets.\n- For example: enhancing yield across âMajorâ assets (as defined below) to encourage looping activity, or utilization of yield-bearing collateral across more exotic trading pairs, or other revenue-generating use cases.\n- This can happen through:\n- Liquidity pools (e.g., paired with BERA or majors)\n- Vault structures that carry out more complex multi-step operations\n- Proposals should clearly explain how the Reward Vault will help scale your existing product. How does this vault become more than a simple farm?\n- The best barometer for ecosystem utility is often correlation to some tangible, empirical metric of interest. PoL does not work if it solely subsidizes idle capital. PoL works when it encourages economic activity, which often shows up as application revenue, volume, fee generation, or user growth.\n- The above guidelines require some nuance. There is value in experiments, whether in memecoins, token launchers, RWAs, consumer applications, and more. For established DeFi applications or adjacent vault products, there should be a path toward sustainable economic activity and growth.\nReasonable emission fees\n- Fees taken on yield must not be excessive and must not be used mainly to recycle incentives.\nYield stacking restrictions\n- If a vault (e.g., ERC-4626) generates yield from PoL reward farming, the majority of that yield must be passed through to stakers, not recycled.\n- Yield from non-PoL sources can be recycled into incentives.\n- This prevents circular reward extraction without adding utility.\nTechnical requirements\nAll Reward Vaults must meet these expectations:\nOpen access\n- The staking token must be accessible to everyone , with no special permissions or barriers.\n- Special exceptions may apply for certain real-world asset (RWA) protocols that require permissioned or compliance-specific applications.\nStandard ERC20 token\n- The staking token must be a standard ERC20 token .\nRebasing tokens\n- Rebasing staking tokens must use a wrapper .\n- This does not apply if the rebasing rate is 0% (e.g., OHM).\nVerified contract\n- The tokenâs smart contract must be verified on-chain and publicly viewable on tools such as Berascan .\nAudits\n- The protocol must have at least one audit and no recent exploits .\n- If an exploit occurred, the proposer must provide clear evidence that the issue has been resolved.\nStaking and incentive token liquidity requirements\nThe tokens must have sufficient liquidity to support sustainable participation:\n- The token should have at least $100,000 in Total Value Locked (TVL).\n- If the token represents a decentralized exchange (DEX) liquidity pool , it must meet the following criteria:\n- At least $50,000 in TVL paired with a âMajorâ asset , defined as:\n- BERA, BUSD, BYUSD, USDC, wETH, wBTC, stablecoins\n- Or other widely recognized, large-cap tokens (e.g., SOL, or comparable assets reasonably within the top 10 by market capitalization; only established tokens are eligibleâpurely speculative or memecoin assets do not qualify)\n- An asset that is a wrapper of a major asset listed above\n- An asset that is minted using a major asset as collateral\n- The token must be deployed and verified on-chain.\nWhy focus on majors?\n- Boosts fee generation: major-token pairs attract higher trading volumes, increasing fees for liquidity providers and making Berachain a home for desirable assets.\n- Reduces volatility risk: major tokens are more stable, lowering impermanent loss for liquidity providers.\n- Democratized access: requiring a major token in every liquidity pair lowers barriers to entry so new users can participate without acquiring obscure or illiquid tokens.\nWhy enforce a minimum TVL requirement?\n- Serves as a filter for teams that might look to extract from the system, and demonstrates some degree of capital at risk and ideally multiple participants from the community, indicating broader interest and trading potential for the pair.\nContracts must be live\n- All contracts being incentivized must be already deployed and fully live on-chain.\n- No rewards for theoretical, unlaunched, or coming-soon contracts.\nProtocol must be live\n- The protocol itself must be live on-chain and actively operating before applying for a Reward Vault.\nGas efficiency\n- Transfers must not exceed 500,000 gas units per transaction to keep fees reasonable.\nMinimum program viability\nSufficient duration\n- Incentives must run at least 2 months to sustain engagement.\nSustainable incentives\n- Must target $10,000+ per month in incentives.\n- Incentive levels must be reasonably priced relative to market conditions. Resources such as Furthermore are recommended for understanding current market incentive rates.\nGovernance and compliance\nProposal requirements\n- Submission: Complete the relevant form and post on the BeraHub governance forum for community awareness and discussion. See Reward Vault Governance for the current BEX Pool and General RFRV forms and submission steps.\nThree-week maximum rollover policy\n- All unapproved applications will automatically roll over and remain in the review pipeline for up to three weeks.\n- After the three-week period , your team must comment under your forum post or submit a new application if you want the proposal reactivated and put up for consideration again.\nPoL use clarity\n- When applying, be specific about exactly how PoL emissions and incentive flows will be used.\nDeployment\n- Reward Vaults must be deployed at time of submission.\n- Any changes require a new proposal and vote.\nTo protect the system from value-extractive incentives, systemic risk, and abuse, the following measures may be exercised at any time:\nTime-limited whitelisting\n- All whitelisted vaults are subject to periodic reevaluation and must continue to meet eligibility criteria to maintain active status.\nEmergency veto\n- In the event of security vulnerabilities, critical protocol risks, or evidence of abuse, an emergency veto may be activated to suspend or revoke Reward Vault emissions immediately.\nPost-approval disqualification\n- Any vault that no longer meets the required standards may be disqualified or have emissions removed, even after prior approval.\nTeams at risk of being delisted will be directly contacted.\nSubmission deadlines\nProposals for each new batch must be submitted by Wednesday 11:59 PM EST every week. Proposals received after this deadline will be reviewed in the next batch.\nReferences\n- Governance Phase One Details\n- Reward Vault Governance (forms and request process)\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.metaplex.com/docs/agents/nori/delegate-to-nori","domain":"www.metaplex.com","title":"Delegate to Nori - One-Time Onboarding to Delegate-Pay Billing | Metaplex","hash":"410bfe509098ca46f263523dcd81bbbdbd31ee98ac34061312266f2fa63ffcfe","tokens":3355,"chars":13419,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112272287,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nNori\nDelegate to Nori\nLast updated September 1, 2026\nDelegating to Nori is a one-time onchain setup that registers Nori as an execution delegate on your agent's asset. After it, every LLM, image, and RPC call your agent makes against Nori settles automatically from the agent's PDA wallet â no payment round-trips, no wallet prompts, no provider API keys. Onboarding is free: Nori pays the transaction fee and provides the blockhash, so your agent needs neither SOL on its keypair nor its own RPC.\nSummary\nGranting Nori execution delegation switches your agent from the two-trip x402 fallback to the in-line delegate-pay rail.\n- One-time setup â a single delegateExecutionV1 instruction pointing at Nori's executive profile, co-signed and submitted by Nori for free\n- Per-call settlement â Nori charges your agent's Asset Signer PDA via an MPL Core Execute transaction with a Memo receipt, only on successful calls\n- Bearer-token auth â a signed challenge/handshake mints a 15-minute bearer token that routes your calls to the delegate-pay rail\n- Revocable at any time â the asset owner can revoke the delegation, which hard-stops auto-charging immediately\nDelegation grants billing authority\nAn execution delegate can sign transfers out of your agent's PDA wallet. Treat the PDA as a spending account: keep a working balance, not your treasury, and audit the Memo receipt attached to every charge. See the single-point-of-failure caveat before making Nori your agent's only service provider.\nQuick Start\n- Fetch Nori's agent card and read serviceExecutiveAddress\n- Build the delegation transaction with your executive keypair as authority and Nori as fee payer, then submit it to POST /v1/delegate/submit\n- Fund your agent's PDA wallet with a working SOL balance\n- Mint a bearer token via /auth/challenge + /auth/handshake\n- Make a paid call with Authorization: Bearer \nPrerequisites\nDelegation requires an existing onchain agent identity; the delegation transaction references the asset and its identity PDA.\n- A registered agent â an MPL Core asset with an AgentIdentity record\n- Your agent's executive keypair (the keypair your agent runs with, set up via Run an Agent ) â it signs the delegation as authority\n- @metaplex-foundation/mpl-agent-registry and @metaplex-foundation/umi installed\n- No SOL and no RPC endpoint are required for the delegation itself â Nori provides both\nStep 1: Discover Nori's Executive Address\nNori's agent card advertises the address you delegate to. Fetch /.well-known/agent-card.json and read two fields:\n- serviceExecutiveAddress â Nori's executive keypair public key. Its executive profile PDA is what you register as a delegate on your asset.\n- serviceAssetAddress â Nori's own agent asset. Its PDA is where your charges are paid to; you can verify every charge onchain against it.\nfetch-nori-card.ts\nconst NORI_URL = process . env . NORI_URL ; // Nori's base URL\nconst card = await fetch ( ` ${ NORI_URL } /.well-known/agent-card.json ` ) . then ( ( r ) =>\nr . json ( ) ,\n) ;\nconst noriExecutive = card . serviceExecutiveAddress ; // delegate to this\nconst noriServiceAsset = card . serviceAssetAddress ; // charges are paid here\nTreat the base URL as trusted configuration\nThe agent card determines which executive profile you grant billing authority to. Fetch it only from a NORI_URL whose configuration you control, and verify serviceExecutiveAddress out-of-band â for example against Nori's published agent registration â before signing the delegation.\nStep 2: Build and Submit the Delegation Transaction\nThe delegation transaction contains exactly one delegateExecutionV1 instruction: your executive keypair signs as authority, Nori's executive profile is the delegate, and Nori's keypair is the fee payer. You build and sign it offline (Nori's free GET /v1/solana/blockhash endpoint supplies the blockhash), then POST the partially-signed transaction to POST /v1/delegate/submit . Nori validates it, co-signs as fee payer, and submits it.\ndelegate-to-nori.ts\nimport { createNoopSigner , publicKey } from '@metaplex-foundation/umi' ;\nimport {\ndelegateExecutionV1 ,\nfindAgentIdentityV1Pda ,\nfindExecutiveProfileV1Pda ,\n} from '@metaplex-foundation/mpl-agent-registry' ;\n// `umi` is configured with your agent's executive keypair as identity.\nconst agentAsset = publicKey ( process . env . AGENT_ASSET_ADDRESS ) ;\n// Nori's executive profile PDA, derived from the agent card address.\nconst noriProfile = findExecutiveProfileV1Pda ( umi , {\nauthority : publicKey ( noriExecutive ) ,\n} ) ;\nconst agentIdentity = findAgentIdentityV1Pda ( umi , { asset : agentAsset } ) ;\n// Free blockhash â no RPC of your own needed.\nconst { blockhash } = await fetch ( ` ${ NORI_URL } /v1/solana/blockhash ` ) . then ( ( r ) =>\nr . json ( ) ,\n) ;\n// Build with Nori as fee payer (a noop signer â Nori co-signs server-side),\n// sign with your executive keypair.\nconst tx = await delegateExecutionV1 ( umi , {\nagentAsset ,\nagentIdentity ,\nexecutiveProfile : noriProfile ,\n} )\n. setFeePayer ( createNoopSigner ( publicKey ( noriExecutive ) ) )\n. setBlockhash ( blockhash )\n. buildAndSign ( umi ) ;\n// Nori validates, co-signs, and submits â free of charge.\nconst result = await fetch ( ` ${ NORI_URL } /v1/delegate/submit ` , {\nmethod : 'POST' ,\nheaders : { 'Content-Type' : 'application/json' } ,\nbody : JSON . stringify ( {\ntransaction : Buffer . from ( umi . transactions . serialize ( tx ) ) . toString ( 'base64' ) ,\n} ) ,\n} ) . then ( ( r ) => r . json ( ) ) ;\nconsole . log ( result ) ;\n// { success: true, signature: '...', agentAsset: '...', authority: '...' }\nStrict transaction validation\nPOST /v1/delegate/submit rejects anything that is not exactly one delegateExecutionV1 instruction (discriminator 1 on the mpl-agent-tools program) pointing at Nori's own executive profile, with Nori as fee payer. The strict shape prevents the free endpoint from being abused as a transaction-submission service.\nIf you build agents from the Metaplex agent template, this entire step is packaged as the delegate-to-nori tool â one call, no manual transaction construction.\nStep 3: Authenticate with a Bearer Token\nPaid calls route to the delegate-pay rail when they carry a bearer token minted through a Sign-In-With-Solana-style handshake. The token proves you control the executive keypair that is a registered delegate on the agent asset; it is valid for 15 minutes, so re-run the handshake on expiry.\nnori-handshake.ts\nimport { base58 } from '@metaplex-foundation/umi/serializers' ;\n// 1. Get a fresh nonce.\nconst { nonce } = await fetch ( ` ${ NORI_URL } /auth/challenge ` ) . then ( ( r ) => r . json ( ) ) ;\n// 2. Sign the handshake envelope with your executive keypair.\nconst now = Date . now ( ) ;\nconst handshake = {\npubkey : umi . identity . publicKey . toString ( ) ,\nagentAsset : agentAsset . toString ( ) ,\naudience : NORI_URL ,\nnonce ,\nissuedAt : new Date ( now ) . toISOString ( ) ,\nexpiresAt : new Date ( now + 60_000 ) . toISOString ( ) ,\n} ;\nconst signature = base58 . deserialize (\nawait umi . identity . signMessage (\nnew TextEncoder ( ) . encode ( JSON . stringify ( handshake ) ) ,\n) ,\n) [ 0 ] ;\n// 3. Exchange for a bearer token (valid 15 minutes).\nconst { token } = await fetch ( ` ${ NORI_URL } /auth/handshake ` , {\nmethod : 'POST' ,\nheaders : { 'Content-Type' : 'application/json' } ,\nbody : JSON . stringify ( { handshake , signature } ) ,\n} ) . then ( ( r ) => r . json ( ) ) ;\nStep 4: Make a Paid Call\nWith the bearer token attached, Nori runs the upstream call, then charges your agent's PDA in one Execute transaction â the response comes back in a single round-trip with no 402 challenge. The same header works on all /v1/* endpoints and on /a2a .\npaid-call.ts\nconst completion = await fetch ( ` ${ NORI_URL } /v1/chat/completions ` , {\nmethod : 'POST' ,\nheaders : {\n'Content-Type' : 'application/json' ,\nAuthorization : ` Bearer ${ token } ` ,\n} ,\nbody : JSON . stringify ( {\nmodel : 'anthropic/claude-sonnet-4-6' ,\nmessages : [ { role : 'user' , content : 'Hello from a delegated agent.' } ] ,\n} ) ,\n} ) . then ( ( r ) => r . json ( ) ) ;\nOn the first paid call for an asset, Nori checks onchain that it is still a registered delegate; the result is cached for 5 minutes, so subsequent calls skip the chain lookup. See Example Agents for full agents consuming each service, including pointing an OpenAI-compatible SDK client at Nori.\nFunding the Agent PDA Wallet\nCharges draw from your agent's Asset Signer PDA, so it needs a SOL balance before the first paid call. The PDA must also stay above the system rent-exempt minimum (890,880 lamports for a 0-byte account) â the Metaplex agent template seeds it with 0.002 SOL at delegation time so small sub-rent charges never fail. Transfer SOL to the PDA from any wallet; if the balance runs dry, calls fall back to HTTP 402 challenges until you top up (see hard-stop semantics ). Send SOL to the Asset Signer PDA address only, never to the agent's asset address.\nRevoking Delegation from Nori\nRevoking the execution delegation is the kill switch, and it takes effect as a hard stop. When the asset owner revokes the ExecutionDelegateRecordV1 for Nori's executive profile, the next charge attempt fails onchain, Nori invalidates its cached delegate status for your asset, and the delegate-pay rail stops â from then on your calls receive x402 payment challenges instead of being auto-charged. Because of the 5-minute delegate-status cache, a call made immediately after revocation may still attempt (and fail) a delegate charge; no charge lands after revocation because the chain rejects it.\nRevocation does not deregister your agent or touch its PDA balance â it only removes Nori's authority to charge it. You can re-delegate later by repeating Step 2 .\nCommon Errors\nError Cause Fix\nexpected { transaction: } (400) Wrong body field on /v1/delegate/submit Send { \"transaction\": \"\" }\nDelegation submit rejected with an errorReason Transaction shape failed strict validation â extra instructions, wrong program, wrong executive profile, or wrong fee payer Build exactly one delegateExecutionV1 instruction pointing at Nori's executive profile with Nori as fee payer\n401 on paid calls Missing or expired bearer token (15-minute lifetime) Re-run the challenge/handshake flow\n402 on paid calls despite delegation Delegation revoked, or charge failed (usually an empty PDA wallet) Verify the delegation record exists and the PDA balance covers the call\nNeither the asset or any plugins have approved this operation Charge attempted after the delegation was revoked Expected hard-stop behavior â re-delegate to resume delegate-pay\ninsufficient funds for rent on a charge PDA balance below the rent-exempt minimum Top up the PDA (keep it above 890,880 lamports plus a working balance)\nNotes\n- Onboarding endpoints ( GET /v1/solana/blockhash , POST /v1/delegate/submit ) are free and unauthenticated; everything else that does work is paid\n- Bearer tokens are minted per executive keypair + agent asset pair and expire after 15 minutes â build re-handshaking into your client\n- The delegate-status cache means delegation state changes (grant or revoke) can take up to 5 minutes to be reflected on the payment rail; onchain enforcement is immediate\n- Delegation is per-asset: an agent operator running multiple agents delegates each asset separately\n- Applies to mpl-agent-tools execution delegation ( ExecutionDelegateRecordV1 ), program TLREGni9ZEyGC3vnPZtqUh95xQ8oPqJSvNjvB7FGK8S\nMaintained by Metaplex Foundation. Last verified: 2026-07-08. View source on GitHub .\nFAQ\nCommon questions about delegating to Nori.\nDoes delegating to Nori cost anything?\nNo. Nori pays the network fee on the delegation transaction (it co-signs as fee payer), and the onboarding endpoints are free and unauthenticated. You will want a working SOL balance on your agent's PDA wallet afterwards, because that is the account per-call charges draw from.\nWhat authority does delegation give Nori?\nDelegation registers Nori's executive profile as an execution delegate on your agent asset, which lets Nori sign MPL Core Execute transactions that move SOL out of your agent's PDA wallet. Nori uses this to settle per-call charges, each with an onchain Memo receipt. Keep only a working balance on the PDA and audit the receipts.\nHow do I stop Nori from charging my agent?\nRevoke the execution delegation on your agent asset. The next charge attempt fails onchain, Nori's cached delegate status is invalidated, and the delegate-pay rail hard-stops â subsequent calls receive HTTP 402 x402 challenges instead of being auto-charged.\nWhy do my calls return HTTP 402 even though I delegated?\nA 402 means the delegate-pay rail was unavailable for that call â the bearer token is missing or expired (tokens last 15 minutes), the delegation was revoked, or the charge itself failed (usually an empty PDA wallet). Re-run the handshake, verify the delegation record exists, and check the PDA balance.\nCan I use Nori without delegating at all?\nYes. Non-delegated callers use the x402 fallback rail â the first request returns HTTP 402 with payment requirements, you pay in SOL or USDC, then retry. It costs the same but adds a payment round-trip to every call, whereas delegate-pay settles in-line.\nPrevious\nâ Nori Overview\nNext\nPricing and Billing â"}
{"url":"https://www.metaplex.com/docs/smart-contracts/core","domain":"www.metaplex.com","title":"Metaplex Core | Next-Gen NFT Standard for Solana","hash":"fa956b239a57addaec96b6ed6aac5c7b9afa21c55ca1a76bf8e53db4494108dd","tokens":1784,"chars":7134,"crawler":"hive-genesis","verified":"unchecked","ts":1791112273348,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nIntroduction\nOverview\nLast updated September 3, 2026\nMetaplex 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.\nWhat You'll Learn\nThis overview covers:\n- What Metaplex Core is and why it exists\n- Key advantages over Token Metadata and other standards\n- Core concepts: Assets, Collections, and Plugins\n- How to get started building with Core\nSummary\nMetaplex 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.\n- Single-account design: ~0.003 SOL per mint (vs 0.022 SOL for Token Metadata)\n- Enforced royalties by default with allowlist/denylist controls\n- Plugin system for staking, attributes, delegates, and custom behaviors\n- Collection-level operations: freeze, update royalties, or modify all assets at once\nOut of Scope\nThis overview does not cover: fungible tokens (use SPL Token), Token Metadata migration paths, or detailed plugin implementation. See specific pages for those topics.\nQuick Start\nJump to: Getting Started · Key Advantages · FAQ · Glossary\n- Install the SDK: npm install @metaplex-foundation/mpl-core\n- Create an Asset: Creating Assets guide\n- Add plugins: Plugins overview\n- Query with DAS: Fetching Assets\nGetting Started\nFind the language or library of your choice and get started with digital assets on Solana.\nAPI Reference\nLooking for something specific? Check our API References.\nDifferences from Token Metadata\nComing from Token Metadata? See what's changed and what's new.\nTry Core in a UI\nMint a Core Asset yourself using our web interface.\nIntroduction\nMetaplex Core is the recommended NFT standard for new projects on Solana. Compared to Token Metadata and other standards, Core provides:\nCost Efficiency\nStandard Mint Cost Compute Units\nMetaplex Core ~0.003 SOL ~17,000 CU\nToken Metadata ~0.022 SOL ~205,000 CU\nToken Extensions ~0.0046 SOL ~85,000 CU\nKey Advantages\n- Single Account Design : Core uses one account per asset instead of multiple (mint + metadata + token account). This reduces costs and simplifies development.\n- Enforced Royalties : The Royalties plugin enforces creator royalties by default with allowlist/denylist controls.\n- Collection-Level Operations : Update royalties, freeze assets, or modify metadata for an entire collection in a single transaction.\n- Plugin Architecture : Add custom behaviors to assets via plugins:\n- Freeze Delegate - Allow others to freeze/unfreeze\n- Burn Delegate - Allow others to burn\n- Attributes - On-chain key/value data (auto-indexed by DAS)\n- Transfer Delegate - Allow others to transfer\n- And many more in the Plugins section\n- DAS Indexing : All major RPC providers supporting DAS already index Core assets.\nCore Concepts\nAssets\nAn 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?\nCollections\nA 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.\nGroups ( 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: Collections\nPlugins\nPlugins 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 Overview\nQuick Reference\nProgram IDs\nProgram Address\nMPL Core CoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7d\nMPL Core (Devnet) CoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7d\nSDK Packages\nLanguage Package\nJavaScript/TypeScript @metaplex-foundation/mpl-core\nRust mpl-core\nNext Steps\n- Choose your SDK : Visit Getting Started to install the JavaScript or Rust SDK\n- Create your first Asset : Follow the Creating Assets guide\n- Explore plugins : See available behaviors in Plugins\n- Migrate from Token Metadata : Review Differences from Token Metadata\nPlease note that certain Core instructions require protocol fees. Review the Protocol Fees page for current information.\nFAQ\nWhat is Metaplex Core?\nMetaplex 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.\nHow is Core different from Token Metadata?\nCore 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.\nCan I migrate from Token Metadata to Core?\nCore 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.\nDoes Core support royalties?\nYes. Core has a Royalties plugin that enforces royalties by default. You can set basis points, creator splits, and allowlist/denylist rules for marketplaces.\nWhat are plugins?\nPlugins 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).\nHow much does it cost to mint a Core Asset?\nApproximately 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.\nWhich RPC providers support Core?\nAll major RPC providers supporting DAS (Digital Asset Standard) index Core assets. See RPC Providers for a current list.\nCan I use Core for gaming assets?\nYes. 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.\nGlossary\nTerm Definition\nAsset A single Core on-chain account representing an NFT with ownership, metadata, and plugins\nCollection A Core account that groups related Assets and can apply collection-wide plugins\nPlugin A modular extension that adds behavior to Assets or Collections (royalties, freeze, attributes)\nDAS Digital Asset Standard - the API specification for querying indexed NFT data\nBasis Points Royalty percentage in hundredths of a percent (500 = 5%)\nDelegate An account authorized to perform specific actions on an Asset without owning it\nCPI Cross-Program Invocation - calling the Core program from another Solana program\nURI The off-chain metadata URL pointing to a JSON file with name, image, and attributes\nAsset Signer PDA A separate address derived from an Asset that acts as the Asset's wallet\nNext\nWhat is an Asset? â"}
{"url":"https://bitcoinops.org/en/topics/ark/","domain":"bitcoinops.org","title":"Ark protocol | Bitcoin Optech","hash":"0b5ee6eb0229de31828097a07b41004b97b68b03e1c3d30f0153302f6b3552c7","tokens":848,"chars":3390,"crawler":"crawler-tpoe","verified":"exact","ts":1791112274040,"text":"/ home / topics /\nArk protocol\nIn the Ark protocol , a large number of users trustlessly share onchain UTXOs using trees of pre-signed, offchain transactions. By sharing UTXOs and transacting offchain, Ark users can spread the cost of onchain fees across multiple participants, minimizing individual transaction costs while maintaining self-custody of their bitcoin.\nArk transaction trees are constructed periodically through an interactive\nprocess known as âroundsâ. Each round involves multiple users and a counterparty\n(an Ark operator), who together construct and sign the transaction tree, then\nbroadcast the root transaction onchain. Users securely store their branch and\nleaf transactions offchain. This package of offchain transactions is known as a\nVTXO (virtual UTXO), which serves as the core unit of value on Ark.\nTo unilaterally withdraw bitcoin from Ark, a user broadcasts their branch and\nleaf transactions in sequence, ultimately releasing their portion of the shared\nUTXO to an onchain output under their sole control. However, under normal\noperations, users will typically prefer cooperative exits, where they spend\ntheir VTXO to receive an onchain UTXO from the Ark operator.\nVTXOs âexpireâ according to an absolute timelock. After this timelock expires,\nboth the Ark operator and users can unilaterally spend the bitcoin. To maintain\ntrustlessness, users must ensure their VTXOs are spent into a new transaction\ntree before expiry. This expiry mechanism allows the Ark operator to efficiently\nrecover liquidity that has been allocated to previous rounds and external\nspending operations.\nPayments between Ark users are handled as offchain, pre-signed extensions of the\ntransaction tree. Each payment transaction requires co-signatures from both the\nsender and the Ark operator, meaning receivers must trust that the sender will\nnot collude with the operator to double-spend.\nUsers can chain these payments by spending a received VTXO before itâs included\nin a new round. In payment chains, any sender in the chain could collude with\nthe operator to double-spend the entire chain.\nUpon receiving a VTXO, users can either roll it into a new round to regain\ntrustlessness, or spend it to another user before the expiry deadline.\nArk can be implemented on Bitcoin without requiring consensus changes, but would\nsupport significantly more usersâand achieve greater fee efficiencyâif covenant\nfeatures like OP_CHECKTEMPLATEVERIFY were added\nto Bitcoin.\nPrimary code and documentation\n- Arkade implementation\n- Arkade technical documentation\n- Second implementation\n- Second technical documentation\nOptech newsletter and website mentions\n2026\n- Bark 0.5.0 released\n- Wavelength alpha released with an Ark-like settlement layer\n- Bark implementation of Ark is now live on Bitcoin mainnet\n- V-PACK, a standard for stateless VTXO verification\n- Hash-lock based Ark protocol, hArk, software released\n- Using Ark as a channel factory\n2025\n- Ark Labs launches Arkade\n- Summary and criticism of CTV + CSFS benefits for Ark\n- Bark implementation of Ark is now available on signet\n- Ark Wallet SDK released\n2024\n- Implementation of Ark demonstrated on mainnet\n2023\n- Improving LN scalability with covenants in a similar way to Ark\n- Proposal for a managed joinpool protocol\nSee also\n- Joinpools\n-\nCovenants\nPrevious Topic:\nAnonymity networks\nNext Topic:\nASICBoost\nEdit page\nReport Issue"}
{"url":"https://forum.skyeco.com/t/saep-22-update-risk-curation-framework/28232","domain":"forum.skyeco.com","title":"SAEP-22: Update Risk Curation Framework - Spark Prime - Sky Forum","hash":"a95eeec0df7f19e6def7213f6842eff27db7fe34bd51c1996bd94bbe8eb02ea0","tokens":4992,"chars":19965,"crawler":"hive-genesis","verified":"unchecked","ts":1791112275284,"text":"Sky Forum\nSAEP-22: Update Risk Curation Framework\nSpark Prime\nmorpho\nPhoenixLabs\nSeptember 11, 2026, 6:09pm\n1\nSummary\nThis proposal is submitted by Phoenix Labs in its role as a nested contributor, as defined in section A.6.1.1.1.2.2.2.2.1.2.1.1.1 of the Spark Artifact. The proposal recommends that Spark governance update the Risk Curation Framework section of the Spark Artifact ( A.6.1.1.1.3.9 ) to make two changes:\n- Exempt Sky-designated cancellation actors, including the Operational GovOps of an Operational Executor Agent, from curator/cancellation-authority independence requirements.\n- Permit Curators to queue changes before polling closes when the timelock expires at least twenty-four (24) hours after the pollâs expected close, with responsibility for cancelling unapproved changes before they become executable.\nVault appointments, contract permissions, configured timelock delays and risk parameters remain unchanged.\nBackground\nExisting independence rule\nCancellation Authority Independence ( A.6.1.1.1.3.9.6.3.1 ) currently states:\nâThe cancellation authority holder controlled by the Operational Executor Agent must use a signer set separate from the signer set of the Curator multisig for the same smart contract instance, and at least one cancellation authority holder must be fully independent of every entity serving in the Curator role. Compromise or misalignment of the Curator role must not in itself remove the ability of the cancellation authority to cancel pending changes.â\nThe framework uses cancellation authority for the guardian role in Morpho Vaults v1 and the sentinel role in v2 ( A.6.1.1.1.3.9.6.3 ). A review of the consolidated Atlas and the changes introduced by SAEP-20 identifies this document as the only explicit Spark curator/cancellation independence rule. The review includes the surrounding cancellation permissions, reasons and reporting, the five framework instance records, and Curator/Guardian address fields in the Allocation System. Those records describe role arrangements; the proposed exemption does not amend their recorded appointments.\nSAEP-13 ( forum thread ), submitted on 23 March 2026, introduced the framework. Its SAEP-13: Risk Curation Framework poll ran from 23 to 26 March 2026 and closed with 346,949,018.3334322 For / 0 Against, and Atlas PR #209 merged on 27 April 2026. Atlas PR #302 , implementing SAEP-19, merged on 27 August 2026 and removed the Spark Risk Council reference from the cancellation reasons.\nSky-designated participation\nSkyâs operational criteria, as communicated to the proposer, require OEA participation in both curation and cancellation. The externally curated arrangement uses joint OEA and external-curator control; the nonexternally curated arrangement uses sole OEA curation. The supplied criteria also specify separate OEA cancellation signers. This proposal removes Sparkâs independence condition for the designated actors; Skyâs own operational requirements continue to apply.\nSky Governance designates transitional Executor Agents under A.1.14.4.7.1 . Sparkâs Executor Accord identifies Amatsu, whose Operational GovOps is recorded in A.6.1.2.1.2 . The exemption includes that role and other actors expressly designated by Sky Governance for the relevant cancellation function.\nSAEP-20 ( forum thread ) established the separate OEA signer and independent-holder requirements quoted above and updated the frameworkâs cancellation-authority terminology. Atlas PR #329 , implementing that proposal, merged on 10 September 2026. This proposal builds on that framework by adding an exemption for Sky-designated actors.\nQueueing before polling closes\nThe Polling Requirement ( A.6.1.1.1.3.9.4.1 ) currently states: âAll curator-executed changes must be approved in advance by Spark governance through a polling process.â Execution Authority ( A.6.1.1.1.3.9.4.2 ) then authorizes transaction submission following successful approval. Scope of Authority ( A.6.1.1.1.3.9.3.2 ) also limits actions to those approved through polling, and Reporting of Curator Actions ( A.6.1.1.1.3.9.3.3 ) assumes the linked poll has already provided approval.\nThe proposed rule allows the timelock to run before the related poll is created or approved, provided that the pending change cannot become executable until at least twenty-four (24) hours after the expected poll close. Once the pollâs actual closing time is known, cancellation on timing grounds is required only if less than twenty (20) hours remain between that close and the pending change becoming executable. Implementation still requires approval of the exact queued change. The existing minimum three (3) day timelock ( A.6.1.1.1.3.9.5.1 ) and public visibility requirement ( A.6.1.1.1.3.9.5.2 ) continue to apply.\nThe amendment aligns the scope, reporting and approval provisions with early queueing, and adds a cancellation duty to Cancellation Reasons ( A.6.1.1.1.3.9.6.2 ). If the poll does not approve the change, the Curator and cancellation authority holders must ensure cancellation before it becomes executable. The twenty (20) hour threshold allows up to four (4) hours of delay in poll posting when a change was queued with exactly the initial twenty-four (24) hour margin.\nThe standard governance cycle runs from Monday at 16:00 UTC to Thursday at 16:00 UTC. With a three (3) day timelock, queueing can begin on Tuesday at 16:00 UTC; with a seven (7) day timelock, it can begin on the preceding Friday at 16:00 UTC. In both examples, the timelock expires on Friday at 16:00 UTC, twenty-four (24) hours after the expected poll close.\nProposal Details\nWe propose that Spark governance approve the following changes to the Risk Curation Framework section of the Spark Artifact:\n- Amend A.6.1.1.1.3.9.6.3.1 to exempt the Operational GovOps of an Operational Executor Agent and other actors expressly designated by Sky Governance for the relevant cancellation function from the sectionâs independence requirements, including separate signers and any requirement for an additional independent cancellation authority holder.\n- Amend A.6.1.1.1.3.9.3.2, A.6.1.1.1.3.9.4, A.6.1.1.1.3.9.4.1 and A.6.1.1.1.3.9.4.2 to permit queueing before polling closes under the twenty-four (24) hour condition while retaining approval before implementation.\n- Amend A.6.1.1.1.3.9.3.3 to identify the related poll, its approval status at queueing and expected closing time when reporting an early queued change.\n- Amend A.6.1.1.1.3.9.6.2 to make the Curator and cancellation authority holders responsible for ensuring cancellation before execution eligibility when the poll does not approve the change or its actual closing time leaves less than twenty (20) hours before the change becomes executable.\nSpecification\n- Option 1: Yea\n- Accept the proposal\n- Adjust the Spark Artifact as follows:\nArtifact Edits\n(each amended or added document below is restated in its entirety as it will read after the change; document removals are stated as instructions)\nChange 1:\nReplace A.6.1.1.1.3.9.6.3.1 with the following text (adding an exemption for Sky-designated cancellation actors while retaining the general independence rule):\nA.6.1.1.1.3.9.6.3.1 - Cancellation Authority Independence\nThe cancellation authority holder controlled by the Operational Executor Agent must use a signer set separate from the signer set of the Curator multisig for the same smart contract instance, and at least one cancellation authority holder must be fully independent of every entity serving in the Curator role. Compromise or misalignment of the Curator role must not in itself remove the ability of the cancellation authority to cancel pending changes.\nThe requirements of this section do not apply to the independence of the Curator from a cancellation authority holder controlled by the Operational GovOps of an Operational Executor Agent or by another actor expressly designated by Sky Governance to exercise cancellation authority for the relevant smart contract instance. This section does not require such a holder to use a signer set separate from the Curatorâs, and does not require an additional independent cancellation authority holder for an instance with such a holder.\nChange 2:\nReplace A.6.1.1.1.3.9.3.2 with the following text (distinguishing implementation from permitted queueing and cancellation):\nA.6.1.1.1.3.9.3.2 - Scope of Authority\nCurators may only implement changes that have been explicitly approved by Spark governance via polling. Curators may queue changes before approval in accordance with A.6.1.1.1.3.9.4.1 - Polling Requirement , and may cancel pending changes in accordance with A.6.1.1.1.3.9.6.2 - Cancellation Reasons .\nChange 3:\nReplace A.6.1.1.1.3.9.3.3 with the following text (allowing reports to identify a poll whose outcome is pending):\nA.6.1.1.1.3.9.3.3 - Reporting of Curator Actions\nAll actions taken under a Curator role must be reported by the Curator in the Spark-Prime subsection of the Sky forum within 24 hours of submission. The report should include a transaction hash of the action, the UTC time at which the timelock period for the action elapses, a description of the action being implemented, and a link to the related proposal and governance poll, if the poll is available. For a change queued before approval, the report must state that governance approval had not been obtained when the change was queued and include the expected poll closing time in UTC used when queueing.\nChange 4:\nReplace A.6.1.1.1.3.9.4 with the following text (distinguishing approval for implementation from permission to queue):\nA.6.1.1.1.3.9.4 - Governance Approval Process\nThe documents herein describe the requirements for governance approval before implementation of Curator changes and the conditions for queueing changes before approval.\nChange 5:\nReplace A.6.1.1.1.3.9.4.1 with the following text (permitting queueing before poll approval with a minimum period for cancellation after polling closes):\nA.6.1.1.1.3.9.4.1 - Polling Requirement\nAll curator-executed changes must be approved by Spark governance through a polling process before they are implemented.\nA Curator may queue a proposed change before the related governance poll is created or approved, provided that the onchain timelock for the pending change will expire no earlier than twenty-four (24) hours after the expected closing time of that poll. Queueing means submitting a change to the onchain timelock without implementing it. All applicable timelock delays continue to apply.\nThe twenty-four (24) hour condition applies when the change is queued. Once the related poll is created, its actual closing time, including any subsequent change to that time, must be used to assess the remaining period before the pending change becomes executable. Cancellation on timing grounds is required only if that period is less than twenty (20) hours.\nThe pending change must match the change submitted for approval. If the poll does not approve that change, or the actual poll closing time leaves less than twenty (20) hours before the pending change becomes executable, the pending change must be cancelled in accordance with A.6.1.1.1.3.9.6.2 - Cancellation Reasons .\nChange 6:\nReplace A.6.1.1.1.3.9.4.2 with the following text (authorizing early queueing while retaining approval and timelock expiry as conditions for implementation):\nA.6.1.1.1.3.9.4.2 - Execution Authority\nThe Curator is authorized to submit the onchain transactions needed to queue a change before governance approval only under the conditions in A.6.1.1.1.3.9.4.1 - Polling Requirement . Following successful governance approval, the approved change or changes may be implemented only after the applicable timelock has expired. Queueing a change does not authorize its implementation.\nChange 7:\nReplace A.6.1.1.1.3.9.6.2 with the following text (requiring cancellation of unapproved changes and changes that no longer meet the polling buffer):\nA.6.1.1.1.3.9.6.2 - Cancellation Reasons\nPending changes may be cancelled for the following reasons: misalignment or conflict with the Sky Atlas or Spark Artifact; excessive or unacceptable risk, as identified by the Sky Core Council; emergency situations, as defined in the Sky Atlas in A.1.9 - Emergency Response System ; or cancellation requested by the Curator.\nFor a change queued before governance approval, the Curator and the cancellation authority holders for the relevant smart contract instance are responsible for ensuring that the pending change is cancelled before it becomes executable if the related poll does not approve the exact pending change, including where the poll is not held, is withdrawn or cancelled, or closes without a valid approval result. The same responsibility applies on timing grounds only if the actual poll closing time, including any subsequent change to that time, leaves less than twenty (20) hours before the pending change becomes executable. A period of twenty (20) hours or more does not require cancellation on timing grounds; the other cancellation reasons and the duty to cancel unapproved changes remain applicable. Any actor authorized under A.6.1.1.1.3.9.6.1 - Authorized Cancellers may fulfil this responsibility by cancelling the pending change; once it has been cancelled, no duplicate cancellation is required.\nNo changes required: A.6.1.1.1.3.9, .9.1, .9.1.1, .9.2, .9.3, .9.3.1, .9.5, .9.5.1, .9.5.2, .9.6, .9.6.1, .9.6.3, .9.6.3.2, .9.7, .9.7.1, .9.7.1.1, .9.7.1.2, .9.7.1.3, .9.7.1.4, .9.7.1.5, .9.7.1.6, .9.7.2, .9.7.2.1, .9.7.2.2, .9.7.2.3, .9.7.2.4, .9.7.2.5. No document is added, removed or renumbered.\n- Option 2: Nay\n- Reject the above proposal\n- Make no changes to the Spark Artifact\nJustification\nThe exemption avoids making Spark policy depend on enforcement of OEA signer arrangements. Sky requires OEA participation in curation and cancellation. Spark does not have a clean mechanism to enforce the OEAâs internal signer arrangements on Skyâs behalf. Waiving this Spark condition accommodates the designated actor without adding a signer attestation, audit or enforcement procedure. The exemption leaves Skyâs own requirements and the actorâs underlying mandate in place.\nTimelocks and owner intervention retain a route to cancel harmful pending changes. The framework retains governance approval before implementation, public visibility, cancellation reasons and reporting. In the documented Morpho v1 and v1.1 implementations, the owner can cancel relevant pending actions directly. In v2, the owner can add a sentinel without a vault timelock, after which that sentinel can revoke the pending action. Appointing a role alone does not cancel the action. These capabilities are documented in the official v1 implementation , v1.1 implementation and v2 implementation .\nThe exemption accepts greater reliance on timely owner intervention. The exempt arrangement can share signing control and institutional direction between curation and cancellation. Timelocks provide a response window, but detection, authorization and transaction execution must complete before the harmful action executes. The owner must remain available and uncompromised. These safeguards do not reproduce an independent veto or eliminate the risk of correlated compromise.\nThe general rule remains in place outside the exemption. An external Curatorâs participation alongside OEA does not independently qualify that external Curator for an exemption in another arrangement. Qualification follows the specified OEA GovOps role or an express Sky Governance designation for the cancellation role in the relevant instance. The amendment retains the existing document identity and requires no renumbering.\nOverlapping polling and the timelock can reduce the wait after approval. Queueing becomes permissible as soon as the configured timelock can expire at least twenty-four (24) hours after the expected poll close. This retains the full applicable timelock. Cancellation on timing grounds is required only if the actual poll close leaves less than twenty (20) hours before execution eligibility, allowing up to four (4) hours of posting delay at the initial boundary. The new permission applies to Curators generally, independently of the Sky-designated-actor exemption.\nUnapproved pending changes require active cancellation. The Curator and cancellation authority holders must monitor the poll outcome and ensure that an unapproved change is cancelled before it becomes executable. One authorized actor can complete the cancellation for all of them. Reporting identifies the poll and relevant UTC times. If these actors fail to cancel in time, the unapproved change may become executable despite the policy prohibition; a timelock does not itself evaluate the poll result.\nGovernance Process\nThis proposal will be subject to the review process applicable to Spark Artifact Edit Proposals at the time of submission. If approved to proceed, the proposal will be included in Sparkâs next available weekly governance cycle.\nThis proposal will use simple majority voting to approve or reject the proposal over a 3 day voting period.\nPhoenix Labs submits this proposal as a nested contributor, as specified in the Spark Artifact at section ( A.6.1.1.1.2.2.2.2.1.2.1.1.1 ).\nConflicts\nNo material conflicts.\nRemi's Spark Delegate Communications\nCivicSage\nSeptember 14, 2026, 2:45pm\n2\nEndgame Edge, on behalf of Sparkâs Executor Agent, Amatsu, and acting as its Operational Facilitator, approves the proposal and confirms its alignment with the Sky Core Atlas and Sparkâs Agent Artifact. The proposal is also feasible for Operational GovOps to implement.\nAny changes to the Agent Artifact that this proposal implicitly requires will be shared by Endgame Edge in this post.\nBALabs\nSeptember 14, 2026, 3:54pm\n3\nIn its capacity as Core Council Risk Advisor, BA Labs provides the following comments on the two proposed changes.\nOn the exemption from the cancellation authority independence requirements, BA Labs notes that this amendment does not alter the requirements that govern vaults receiving Liquidity Layer allocations. Under the Core Councilâs Morpho Vaults v2 Eligibility Criteria, and their forthcoming codification at the Atlas level, the sentinel controlled by the Operational Executor Agent must use a signer set separate from the signer set of the Curator multisig, and allocations into a vault that does not adhere to the criteria receive a 100% CRR until it does. For instances holding Sky-allocated funds, the exemption therefore has no practical effect on the required arrangement. For a future vault holding user funds outside the Allocator System, the arrangement is outside the scope of the Liquidity Layer risk framework; we note, as the proposal itself does, that the exempt arrangement does not reproduce an independent veto and places greater reliance on timely owner intervention.\nOn queueing before polling closes, BA Labs has no objection from a financial risk perspective. The fully configured timelock, the exact-match requirement between the queued change and the polled change, the minimum 24 hour margin at queuing with the 20 hour cancellation threshold, and the public visibility requirement together preserve a defined review and cancellation window. We note that the change converts a hard sequencing control into a procedural duty: an unapproved queued change becomes executable unless it is actively cancelled, so the arrangementâs safety rests on monitoring and on the reliability of the cancellation authority. Where both changes in this proposal apply to the same instance, that reliability is what makes early queueing sound, and for vaults receiving Liquidity Layer allocations it is preserved by the independence requirement of the Eligibility Criteria noted above.\n1 Like\nRisk Month in Review: September 2026\nCivicSage\nSeptember 14, 2026, 4:05pm\n4\nThe proposal has now been posted to Snapshot and is available for voting:\n- Snapshot Poll\n- Pull Request"}
{"url":"https://vitalik.eth.limo/general/2024/05/23/l2exec.html","domain":"vitalik.eth.limo","title":"How do layer 2s really differ from execution sharding?","hash":"1e2f7b00ad281561deffe60977000e9e2f1b20111347c364c933e38aa4b81cf3","tokens":3729,"chars":14914,"crawler":"hive-genesis","verified":"unchecked","ts":1791112276893,"text":"Dark Mode Toggle\nHow do layer 2s really differ from execution sharding?\n2024 May 23\nSee all posts\nHow do layer 2s really differ from execution sharding?\nOne of the points that I made in my post two and half years ago on \"the Endgame\"\nis that the different future development paths for a blockchain, at\nleast technologically, look surprisingly similar. In both cases, you\nhave a very large number of transactions onchain, and processing them\nrequires (i) a large amount of computation, and (ii) a large amount of\ndata bandwidth. Regular Ethereum nodes, such as the 2 TB reth archive node running\non the laptop I'm using to write this article, are not powerful enough\nto verify such a huge amount of data and computation directly, even with\nheroic software engineering work and Verkle trees . Instead, in both \"L1\nsharding\" and a rollup-centric\nworld, ZK-SNARKs\nare used to verify computation, and DAS\nto verify data availability. The DAS in both cases is the same. The\nZK-SNARKs in both cases are the same tech, except in one case they are\nsmart contract code and in the other case they are an enshrined feature\nof the protocol. In a very real technical sense, Ethereum is\ndoing sharding, and rollups are shards .\nThis raises a natural question: what is the difference\nbetween these two worlds? One answer is that the consequences of code\nbugs are different: in a rollup world, coins get lost, and in a shard\nchain world, you have consensus failures. But I expect that as protocol\nsolidify, and as formal verification technology improves, the importance\nof bugs will decrease. So what are the differences between the\ntwo visions that we can expect will stick into the long term?\nDiversity of execution\nenvironments\nOne of the ideas that we briefly played around with in Ethereum in\n2019 was execution\nenvironments . Essentially, Ethereum would have different\n\"zones\" that could have different rules for how accounts work (including\ntotally different approaches like UTXOs), how the virtual machine works,\nand other features. This would enable a diversity of approaches in parts\nof the stack where it would be difficult to achieve if Ethereum were to\ntry to do everything by itself.\nIn the end, we ended up abandoning some of the more ambitious plans,\nand simply kept the EVM. However, Ethereum L2s (including rollups,\nvaldiums and Plasmas) arguably ended up serving the role of execution\nenvironments. Today, we generally focus on EVM-equivalent L2s, but this\nignores the diversity of many alternative approaches:\n- Arbitrum\nStylus , which adds a second virtual machine based on WASM alongside the EVM.\n- Fuel ,\nwhich uses a Bitcoin-like (but more feature-complete) UTXO-based\narchitecture.\n- Aztec , which introduces a new\nlanguage and programming paradigm designed around ZK-SNARK-based\nprivacy-preserving smart contracts.\nUTXO-based architecture. Source: Fuel\ndocumentation.\nWe could try to make the EVM into a super-VM that covers all\npossible paradigms, but that would have led to much less effective\nimplementations of each of these concepts than allowing platforms like\nthese to specialize.\nSecurity tradeoffs: scale\nand speed\nEthereum L1 provides a really strong security guarantee. If some\npiece of data is inside a block that is finalized on L1, the entire\nconsensus (including, in extreme situations, social consensus) works to\nensure that the data will not be edited in a way that goes against the\nrules of the application that put that data there, that any execution\ntriggered by the data will not be reverted, and that the data will\nremain accessible. To achieve these guarantees, Ethereum L1 is willing\nto accept high costs. At the time of this writing, the transaction fees\nare relatively low: layer\n2s charge less than a cent per transaction, and even the L1 is under\n$1 for a basic ETH transfer. These costs may remain low in the future if\ntechnology improves fast enough that available block space grows to keep\nup with demand - but they may not. And even $0.01 per transaction is too\nhigh for many non-financial applications, eg. social media or\ngaming.\nBut social media and gaming do not require the same security model as\nL1. It's ok if someone can pay a million dollars to revert a record of\nthem losing a chess game, or make one of your twitter posts look like it\nwas published three days after it actually was. And so these\napplications should not have to pay for the same security costs. An\nL2-centric approach enables this, by supporting a spectrum of data\navailability approaches from rollups\nto plasma\nto validiums .\nDifferent L2 types for different use cases. Read more here .\nAnother security tradeoff arises around the issue of passing\nassets from L2 to L2 . In the limit (5-10 years into the\nfuture), I expect that all rollups will be ZK rollups, and\nhyper-efficient proof systems like Binius and Circle STARKs with lookups , plus proof aggregation\nlayers , will make it possible for L2s to provide finalized state\nroots in each slot. For now, however, we have a complicated mix of\noptimistic rollups and ZK rollups with various proof time windows. If we\nhad implemented execution sharding in 2021, the security model to keep\nshards honest would have been optimistic rollups, not ZK - and so L1\nwould have had to manage the systemically-complex\nfraud proof logic on-chain and have a week-long withdrawal period for\nmoving assets from shard to shard. But like code bugs, I think this\nissue is ultimately temporary.\nA third, and once again more lasting, dimension of security tradeoff\nis transaction speed . Ethereum has blocks every 12\nseconds, and is unwilling to go much faster because that would overly\ncentralize the network. Many L2s, however, are exploring block times of\na few hundred milliseconds. 12 seconds is already not that bad: on\naverage, a user who submits a transaction needs to wait ~6-7 seconds to\nget included into a block (not just 6 because of the possibility that\nthe next block will not include them). This is comparable to what I have\nto wait when making a payment on my credit card. But many applications\ndemand much higher speed, and L2s provide it.\nTo provide this higher speed, L2s rely on\npreconfirmation mechanisms: the L2's own validators\ndigitally sign a promise to include the transaction at a particular\ntime, and if the transaction does not get included, they can be\npenalized. A mechanism called StakeSure generalizes this\nfurther.\nL2 preconfirmations.\nNow, we could try to do all of this on layer 1. Layer 1\ncould incorporate a \"fast pre-confirmation\" and \"slow final\nconfirmation\" system. It could incorporate different shards with\ndifferent levels of security. However, this would add a lot of\ncomplexity to the protocol. Furthermore, doing it all on layer 1\nwould risk overloading the\nconsensus , because a lot of the higher-scale or\nfaster-throughput approaches have higher centralization risks or require\nstronger forms of \"governance\", and if done at L1, the effects of those\nstronger demands would spill over to the rest of the protocol. By\noffering these tradeoffs through layer 2s, Ethereum can mostly avoid\nthese risks.\nThe\nbenefits of layer 2s on organization and culture\nImagine that a country gets split in half, and one half becomes\ncapitalist and the other becomes highly government-driven (unlike when\nthis\nhappens in reality ,\nassume that in this thought experiment it's not the result of any kind\nof traumatic war; rather, one day a border magically goes up and that's\nit). In the capitalist part, the restaurants are all run by various\ncombinations of decentralized ownership, chains and franchises. In the\ngovernment-driven part, they are all branches of the government, like\npolice stations. On the first day, not much would change. People largely\nfollow their existing habits, and what works and what doesn't work\ndepends on technical realities like labor skill and infrastructure. A\nyear later, however, you would expect to see large changes, because the\ndiffering structures of incentives and control lead to large changes in\nbehavior, which affect who comes, who stays and who goes, what gets\nbuilt, what gets maintained, and what gets left to rot.\nIndustrial\norganization theory covers a lot of these distinctions: it talks\nabout the differences not just between a government-run economy and a\ncapitalist economy, but also between an economy dominated by large\nfranchises and an economy where eg. each supermarket is run by an\nindependent entrepreneur. I would argue that the difference between a\nlayer-1-centric ecosystem and a layer-2-centric ecosystem falls along\nsimilar lines.\nA \"core devs run everything\" architecture gone very\nwrong.\nI would phrase the key benefit to Ethereum of being a layer-2-centric\necosystem as follows:\nBecause Ethereum is a layer-2-centric ecosystem, you are free\nto go independently build a sub-ecosystem that is yours with your unique\nfeatures, and is at the same time a part of a greater\nEthereum .\nIf you're just building an Ethereum client, you're part of a greater\nEthereum, and while you have some room for creativity, it's far less\nthan what's available to L2s. And if you're building a completely\nindependent chain, you have maximal room for creativity, but you lose\nthe benefits like shared security and shared network effects. Layer 2s\nform a happy medium.\nLayer 2s do not just create a technical opportunity to\nexperiment with new execution environments and security tradeoffs to\nachieve scale, flexibility and speed: they also create an\nincentive to: both for the developers to build and maintain it,\nand for the community to form around and support it.\nThe fact that each L2 is isolated also means that deploying new\napproaches is permissionless : there's no need to convince all\nthe core devs that your new approach is \"safe\" for the rest of the\nchain. If your L2 fails, that's on you. Anyone can work on totally weird\nideas (eg. Intmax's approach\nto Plasma ), and even if they get completely ignored by the Ethereum\ncore devs, they can keep building and eventually deploy. L1 features and\nprecompiles are not like this, and even in Ethereum, what succeeds and\nwhat fails in L1 development often ends up depending on politics to a\nhigher degree than we would like. Regardless of what theoretically\ncould get built , the distinct incentives created by an\nL1-centric ecosystem and an L2-centric ecosystem end up heavily\ninfluencing what does get built in practice, with what level of\nquality and in what order.\nWhat\nchallenges does Ethereum's layer-2-centric ecosystem have?\nA layer 1 + layer 2 architecture gone very wrong. Source .\nThere is a key challenge to this kind of layer-2-centric approach,\nand it's a problem that layer 1-centric ecosystems do not have to face\nto nearly the same extent: coordination . In other\nwords, while Ethereum branches out, the challenge is in preserving the\nfundamental property that it still all feels like \"Ethereum\", and has\nthe network effects of being Ethereum rather than being N separate\nchains. Today, the situation is suboptimal in many ways:\n- Moving tokens from one layer 2 to another requires\noften centralized bridge platforms, and is complicated for the average\nuser. If you have coins on Optimism, you can't just paste someone's\nArbitrum address into your wallet, and send them funds.\n- Cross-chain smart contract wallet support is not\ngreat - both for personal smart contract wallets and for organizational\nwallets (including DAOs). If you change your key on one L2, you also\nneed to go change your key on every other L2.\n- Decentralized validation infrastructure is often\nlacking. Ethereum is finally starting to have decent light clients, such\nas Helios . However, there\nis no point in this if activity is all happening on layer 2s that all\nrequire their own centralized RPCs. In principle, once you have the\nEthereum header chain, making light clients for L2s is not hard; in\npractice, there's far too little emphasis on it.\nThere are efforts working to improve all three. For cross-chain token\nexchange, the ERC-7683 standard\nis an emerging option, and unlike existing \"centralized bridges\" it does\nnot have any enshrined central operator, token or governance. For\ncross-chain accounts, the approach most wallets are taking is to use\ncross-chain replayable messages to update keys in the short term, and keystore\nrollups in the longer term. Light clients for L2s are starting to\nemerge, eg. Beerus for\nStarknet. Additionally, recent improvements in user experience through\nnext-generation wallets have already solved much more basic problems\nlike removing the need for users to manually switch to the right network\nto access a dapp.\nRabby showing an integrated view of asset balances across\nmultiple chains. In the not-so-long-ago dark old days, wallets did not\ndo this!\nBut it is important to recognize that layer-2-centric ecosystems do\nswim against the current to some extent when trying to coordinate.\nIndividual layer 2s don't have a natural economic incentive to build the\ninfrastructure to coordinate: small ones don't, because they would only\nsee a small share of the benefit of their contributions, and large ones\ndon't, because they would benefit as much or more from strengthening\ntheir own local network effects. If each layer 2 is separately\noptimizing its individual piece, and no one is thinking about how each\npiece fits into the broader whole, we get failures like the urbanism\ndystopia in the picture a few paragraphs above.\nI do not claim to have magical perfect solutions to this problem. The\nbest I can say is that the ecosystem needs to more fully recognize that\ncross-L2 infrastructure is a type of Ethereum infrastructure,\nalongside L1 clients, dev tools and programming languages, and should be\nvalorized and funded as such. We have Protocol\nGuild ; maybe we need Basic Infrastructure Guild.\nConclusions\n\"Layer 2s\" and \"sharding\" often get described in public discourse as\nbeing two opposite strategies for how to scale a blockchain. But when\nyou look at the underlying technology, there is a puzzle: the actual\nunderlying approaches to scaling are exactly the same . You have\nsome kind of data sharding. You have fraud provers or ZK-SNARK provers.\nYou have solutions for cross-{rollup, shard} communication. The main\ndifference is: who is responsible for building and updating\nthose pieces, and how much autonomy do they have?\nA layer-2-centric ecosystem is sharding in a very real\ntechnical sense, but it's sharding where you can go create your own\nshard with your own rules. This is powerful, and enables a lot of\ncreativity and independent innovation. But it also has key challenges,\nparticularly around coordination. For a layer-2-centric ecosystem like\nEthereum to succeed, it needs to understand those challenges, and\naddress them head-on, in order to get as many of the benefits of\nlayer-1-centric ecosystems as possible, and come as close as possible to\nhaving the best of both worlds."}
{"url":"https://vitalik.eth.limo/general/2023/09/30/enshrinement.html","domain":"vitalik.eth.limo","title":"Should Ethereum be okay with enshrining more things in the protocol?","hash":"2411d4d9dcb1f062427ea8a8c42997fcdac8f23b4c34e40a3f3e76a6250e4cb0","tokens":9593,"chars":38369,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112276283,"text":"Dark Mode Toggle\nShould Ethereum be okay with enshrining more things in the protocol?\n2023 Sep 30\nSee all posts\nShould Ethereum be okay with enshrining more things in the protocol?\nSpecial thanks to Justin Drake, Tina Zhen and Yoav Weiss for\nfeedback and review.\nFrom the start of the Ethereum project, there was a strong philosophy\nof trying to make the core Ethereum as simple as possible, and do as\nmuch as possible by building protocols on top. In the blockchain space,\nthe \"do it on L1\" vs \"focus on L2s\" debate is typically thought of as being primarily about\nscaling , but in reality, similar issues exist for serving many kinds\nof Ethereum users' needs: digital asset exchange, privacy, usernames,\nadvanced cryptography, account safety, censorship resistance,\nfrontrunning protection, and the list goes on. More recently, however,\nthere has been some cautious interest in being willing to enshrine more\nof these features into the core Ethereum protocol.\nThis post will go into some of the philosophical reasoning behind the\noriginal minimal-enshrinement philosophy, as well as some more recent\nways of thinking about some of these ideas. The goal will be to start to\nbuild toward a framework for better identifying possible targets where\nenshrining certain features in the protocol might be worth\nconsidering.\nEarly philosophy on\nprotocol minimalism\nEarly on in the history of what was then called \"Ethereum 2.0\", there\nwas a strong desire to create a clean, simple and beautiful protocol\nthat tried to do as little as possible itself, and left almost\neverything up to users to build on top. Ideally, the protocol would\njust be a virtual machine, and verifying a block would\njust be a single virtual machine call.\nA very approximate reconstruction-from-memory of a whiteboard\ndrawing Gavin Wood and I made back in early 2015, talking about what\nEthereum 2.0 would look like.\nThe \"state transition function\" (the function that processes a block)\nwould just be a single VM call, and all other logic would happen through\ncontracts: a few system-level contracts, but mostly contracts provided\nby users. One really nice feature of this model is that even an entire\nhard fork could be described as a single transaction to the block\nprocessor contract, which would be approved through either offchain or\nonchain governance and then run with escalated permissions.\nThese discussions back in 2015 particularly applied to two areas that\nwere on our minds: account abstraction and\nscaling . In the case of scaling, the idea was to try to\ncreate a maximally abstracted form of scaling that would feel like a\nnatural extension of the diagram above. A contract could make a call to\na piece of data that was not stored by most Ethereum nodes, and the\nprotocol would detect that, and resolve the call through some kind of\nvery generic scaled-computation functionality. From the virtual\nmachine's point of view, the call would go off into some separate\nsub-system, and then some time later magically come back with the\ncorrect answer.\nThis line of thinking was explored briefly, but soon abandoned,\nbecause we were too preoccupied with verifying that any kind of\nblockchain scaling was possible at\nall . Though as we will see later, the combination of data availability\nsampling and ZK-EVMs means that one\npossible future for Ethereum scaling might actually look surprisingly\nclose to that vision! For account abstraction, on the other hand, we\nknew from the start that some kind of implementation was\npossible, and so research immediately began to try to make something as\nclose as possible to the purist starting point of \"a transaction is just\na call\" into reality.\nThere is a lot of boilerplate code that occurs in between\nprocessing a transaction and making the actual underlying EVM call out\nof the sender address, and a lot more boilerplate that comes after. How\ndo we reduce this code to as close to nothing as possible?\nOne of the major pieces of code in here is\nvalidate_transaction(state, tx) , which does things like\nchecking that the nonce and signature of the transaction are correct.\nThe practical goal of account abstraction was, from the start,\nto allow the user to replace basic nonce-incrementing and ECDSA\nvalidation with their own validation logic, so that users could more\neasily use things like social recovery and multisig\nwallets . Hence, finding a way to rearchitect\napply_transaction into just being a simple EVM call was not\nsimply a \"make the code clean for the sake of making the code clean\"\ntask; rather, it was about moving the logic into the user's account\ncode, to give users that needed flexibility.\nHowever, the insistence on trying to make\napply_transaction contain as little enshrined logic as\npossible ended up introducing a lot of challenges. To see why, let us\nzoom in on one of the earliest account abstraction proposals, EIP 86 :\nSpecification\nIf block.number >= METROPOLIS_FORK_BLKNUM , then: 1.\nIf the signature of a transaction is (0, 0, 0) (ie.\nv = r = s = 0 ), then treat it as valid and set the sender\naddress to 2**160 - 1 2. Set the address of any contract\ncreated through a creation transaction to equal\nsha3(0 + init code) % 2**160 , where +\nrepresents concatenation, replacing the earlier address formula of\nsha3(rlp.encode([sender, nonce])) 3. Create a new opcode at\n0xfb , CREATE_P2SH , which sets the creation\naddress to sha3(sender + init code) % 2**160 . If a contract\nat that address already exists, fails and returns 0 as if the init code\nhad run out of gas.\nBasically, if the signature is set to (0, 0, 0), then a transaction\nreally does become \"just a call\". The account itself would be\nresponsible for having code that parses the transaction, extracts and\nverifies the signature and nonce, and pays fees; see here\nfor an early example version of that code, and see here\nfor the very similar validate_transaction code that this\naccount code would be replacing.\nIn exchange for this simplicity at protocol layer, miners (or, today,\nblock proposers) gain the additional responsibility of running extra\nlogic for only accepting and forwarding transactions that go to accounts\nwhose code is set up to actually pay fees. What is that logic? Well,\nhonestly EIP-86 did not think too hard about it:\nNote that miners would need to have a strategy for accepting these\ntransactions. This strategy would need to be very discriminating,\nbecause otherwise they run the risk of accepting transactions ) for the\nvalidate_transaction code that this pre-account code would\nbe replacingthat do not pay them any fees, and possibly even\ntransactions that have no effect (eg. because the transaction was\nalready included and so the nonce is no longer current). One simple\napproach is to have a whitelist for the codehash of accounts that they\naccept transactions being sent to; approved code would include logic\nthat pays miners transaction fees. However, this is arguably too\nrestrictive; a looser but still effective strategy would be to accept\nany code that fits the same general format as the above, consuming only\na limited amount of gas to perform nonce and signature checks and having\na guarantee that transaction fees will be paid to the miner. Another\nstrategy is to, alongside other approaches, try to process any\ntransaction that asks for less than 250,000 gas, and include it only if\nthe miner's balance is appropriately higher after executing the\ntransaction than before it.\nIf EIP-86 had been included as-is, it would have reduced the complexity\nof the EVM, at the cost of massively increasing the complexity of other\nparts of the Ethereum stack, requiring essentially the exact same code\nto be written in other places, in addition to introducing entirely new\nclasses of weirdness such as the possibility that the same transaction\nwith the same hash might appear multiple times in the chain, not to\nmention the multi-invalidation problem.\nThe multi-invalidation problem in account abstraction. One\ntransaction getting included on chain could invalidate thousands of\nother transactions in the mempool, making the mempool easy to cheaply\nflood.\nAcccount abstraction evolved in stages from there. EIP-86 became EIP-208 , which\nlater became this ethresear.ch\npost on \"tradeoffs in account abstraction proposals\" , which then\nbecame this\nethresear.ch post half a year later. Eventually, out of all this,\ncame the actually somewhat-workable EIP-2938 .\nEIP-2938, however, was not minimalistic at all . The EIP\nincludes:\n- A new transaction type\n- Three new transaction-wide global variables\n- Two new opcodes, including the highly unwieldy PAYGAS\nopcode that handles gas price and gas limit checking, being an EVM\nexecution breakpoint, and temporarily storing ETH for fee payments all\nat once.\n- A set of complex mining and rebroadcasting strategies, including a\nlist of banned opcodes for the validation phase of a transaction\nIn order to get account abstraction off the ground without involving\nEthereum core developers who were busy on heroic efforts optimizing the\nEthereum clients and implementing the merge, EIP-2938 eventually was\nrearchitected into the entirely extra-protocol\nERC-4337 .\nERC-4337. It really does rely entirely on EVM calls for\neverything!\nBecause it's an ERC, it does not require a hard fork, and technically\nlives \"outside of the Ethereum protocol\". So.... problem solved? Well, as\nit turns out, not quite. The current medium-term\nroadmap for ERC-4337 actually does involve eventually turning large\nparts of ERC-4337 into a series of protocol features, and it's a useful\ninstructive example to see the reasons why this path is being\nconsidered.\nEnshrining ERC-4337\nThere have been a few key reasons discussed for eventually bringing\nERC-4337 back into the protocol:\n- Gas efficiency : Anything done inside the EVM incurs\nsome level of virtual machine overhead, including inefficiency in how it\nuses gas-expensive features like storage slots. Currently, these extra\ninefficiencies add up to at least ~20,000 gas, and often more. Pushing\nthese components into the protocol is the easiest way to remove these\nissues.\n- Code bug risk : if the ERC-4337 \"entry point\ncontract\" has a sufficiently terrible bug, all\nERC-4337-compatible wallets could see all of their funds drained.\nReplacing the contract with an in-protocol functionality creates an\nimplied responsibility to fix code bugs with a hard fork, which removes\nfunds-draining risk for users.\n- Support for EVM opcodes like\ntx.origin . ERC-4337, by itself, makes\ntx.origin return the address of the \"bundler\" that packaged\nup a set of user operations into a transaction. Native account\nabstraction could fix this, by making tx.origin point to\nthe actual account sending the transaction, making it work the same way\nas for EOAs.\n- Censorship resistance : one of the challenges\nwith proposer/builder separation is that it becomes easier to censor\nindividual transactions. In a world where individual\ntransactions are legible to the Ethereum protocol, this problem\ncan be greatly mitigated with inclusion\nlists , which allow proposers to specify a list of transactions that\nmust be included within the next two slots in almost all cases.\nBut the extra-protocol ERC-4337 wraps \"user operations\" inside a single\ntransaction, making user operations opaque to the Ethereum protocol;\nhence, Ethereum-protocol-provided inclusion lists would not be able to\nprovide censorship resistance to ERC-4337 user operations. Enshrining\nERC-4337, and making user operations a \"proper\" transaction type, would\nsolve this problem.\nIt's worth zooming into the gas efficiency issue further. In its\ncurrent form, ERC-4337 is significantly more expensive than a \"basic\"\nEthereum transaction: the transaction costs 21,000 gas, whereas ERC-4337\ncosts ~42,000 gas. This\ndoc lists some of the reasons why:\n- Need to pay lots of individual storage read/write costs, which in\nthe case of EOAs get bundled into a single 21000 gas payment:\n- Editing the storage slot that contains pubkey+nonce (~5000)\n- UserOperation calldata costs (~4500, reducible to ~2500 with\ncompression)\n- ECRECOVER (~3000)\n- Warming the wallet itself (~2600)\n- Warming the recipient account (~2600)\n- Transferring ETH to the recipient account (~9000)\n- Editing storage to pay fees (~5000)\n- Access the storage slot containing the proxy (~2100) and then the\nproxy itself (~2600)\n- On top of the above storage read/write costs, the contract needs to\ndo \"business logic\" (unpacking the UserOperation, hashing it, shuffling\nvariables, etc) that EOA transactions have handled \"for free\" by the\nEthereum protocol\n- Need to expend gas to pay for logs (EOAs don't issue logs)\n- One-time contract creation costs (~32000 base, plus 200 gas per code\nbyte in the proxy, plus 20000 to set the proxy address)\nTheoretically, it should be possible to massage the EVM gas cost\nsystem until the in-protocol costs and the extra-protocol costs for\naccessing storage match; there is no reason why transferring ETH needs\nto cost 9000 gas when other kinds of storage-editing operations are much\ncheaper. And indeed, two EIPs ( [1] [2] )\nrelated to the upcoming Verkle\ntree transition actually try to do that. But even if we do that,\nthere is one huge reason why enshrined protocol features are going to\ninevitably be significantly cheaper than EVM code, no matter how\nefficient the EVM becomes: enshrined code does not need to pay\ngas for being pre-loaded .\nFully functional ERC-4337 wallets are big . This\nimplementation , compiled and put on chain, takes\nup ~12,800 bytes . Of course, you can deploy that big piece of code\nonce, and use DELEGATECALL to allow each individual wallet\nto call into it, but that code still needs to be accessed in each block\nthat uses it. Under the Verkle tree\ngas costs EIP , 12,800 bytes would make up 413 chunks, and accessing\nthose chunks would require paying 2x WITNESS_BRANCH_COST\n(3,800 gas total) and 413x WITNESS_CHUNK_COST (82,600 gas\ntotal). And this does not even begin to mention the ERC-4337 entry-point\nitself, with 23,689\nbytes onchain in version 0.6.0 (under the Verkle tree EIP rules,\n~158,700 gas to load).\nThis leads to a problem: the gas costs of actually accessing this\ncode would have to be split among transactions somehow. The current\napproach that ERC-4337 uses is not great: the first transaction in a\nbundle eats up one-time storage/code reading costs, making it much more\nexpensive than the rest of the transactions. Enshrinement in-protocol\nwould allow these commonly-shared libraries to simply be part of the\nprotocol, accessible to all with no fees.\nWhat\ncan we learn from this example about when to enshrine things more\ngenerally?\nIn this example, we saw a few different rationales for enshrining\naspects of account abstraction in the protocol.\n- \"Move complexity to the edges\" market-based approaches break\ndown the most when there are high fixed costs . And indeed, the\nlong term account abstraction roadmap looks like it's going to have\nlots of fixed costs per block. 244,100 gas for loading\nstandardized wallet code is one thing; but aggregation\n(see my\npresentation from this summer for more details) potentially adds\nhundreds of thousands more gas for ZK-SNARK validation plus onchain\ncosts for proof verification. There isn't a way to charge users for\nthese costs without introducing lots of market inefficiencies, whereas\nmaking some of these functionalities into protocol features accessible\nto all with no fees cleanly solves that problem.\n- Community-wide response to code bugs . If some set\nof pieces of code are used by all users, or a very wide class of users,\nthen it often makes more sense for the blockchain community to take on\nitself the responsibility to hard-fork to fix any bugs that arise.\nERC-4337 introduced a large amount of globally shared code, and in the\nlong term it makes more sense for bugs in that code to be fixed by hard\nforks than to lead to users losing a large amount of ETH.\n- Sometimes, a stronger form of a feature can be implemented\nby directly taking advantage of the powers of the protocol . The\nkey example here is in-protocol censorship resistance features like\ninclusion lists: in-protocol inclusion lists can do a better job of\nguaranteeing censorship resistance than extra-protocol approaches, in\norder for user-level operations to actually benefit from in-protocol\ninclusion lists, individual user-level operations need to be \"legible\"\nto the protocol. Another lesser-known example is that 2017-era Ethereum\nproof of stake designs had account\nabstraction for staking keys , and this was abandoned in favor of\nenshrining BLS because BLS\nsupported an \"aggregation\" mechanism , which would have to be\nimplemented at protocol and network level, that could make handling a\nvery large number of signatures much more efficient.\nBut it is important to remember that even enshrined\nin-protocol account abstraction is still a massive \"de-enshrinement\"\ncompared to the status quo. Today, top-level Ethereum\ntransactions can only be initiated from externally\nowned accounts (EOAs) which use a single secp256k1 elliptic curve\nsignature for verification. Account abstraction de-enshrines this, and\nleaves verification conditions open for users to define. And so, in this\nstory about account abstraction, we also saw the biggest argument\nagainst enshrinement: being flexible to diverse users'\nneeds .\nLet us try to fill in the story further, by looking at a few other\nexamples of features that have recently been considered for\nenshrinement. We'll particularly focus on: ZK-EVMs ,\nproposer-builder separation , private\nmempools , liquid staking and new\nprecompiles .\nEnshrining ZK-EVMs\nLet us switch focus to another potential target for enshrining into\nthe Ethereum protocol: ZK-EVMs. Currently, we have a large number of ZK-rollups that all have to\nwrite fairly similar code to verify execution of Ethereum-like\nblocks inside a ZK-SNARK . There is a pretty diverse ecosystem of\nindependent implementations: the\nPSE ZK-EVM , Kakarot , the Polygon ZK-EVM ,\nLinea , Zeth , and the list\ngoes on.\nOne of the recent controversies in the EVM ZK-rollup space has to do\nwith how to deal with the possibility of bugs in the ZK-code. Currently,\nall of these systems that are live have some form of \"security council\"\nmechanism that can override the proving system in case of a bug. In this\npost last year , I tried to create a standardized framework to\nencourage projects to be clear about what level of trust they put in the\nproving system and what level in the security council, and move toward\ngiving less and less powers to the security council over time.\nIn the medium term, rollups could rely on multiple proving\nsystems , and the security council would only have any power at all\nin the extreme case where two different proving systems disagree with\neach other.\nHowever, there is a sense in which some of this work feels\nsuperfluous . We already have the Ethereum base layer, which has an\nEVM, and we already have a working mechanism for dealing with bugs in\nimplementations: if there's a bug, the clients that have the bug update\nto fix the bug, and the chain goes on. Blocks that appeared finalized\nfrom the perspective of a buggy client would end up no-longer-finalized,\nbut at least we would not see users losing funds. Similarly, if a rollup\njust wants to be and remain EVM-equivalent, it feels wrong that they\nneed to implement their own governance to keep changing their internal\nZK-EVM rules to match upgrades to the Ethereum base layer, when\nultimately they're building on top of the Ethereum base layer itself,\nwhich knows when it's being upgraded and to what new rules.\nSince these L2 ZK-EVMs are basically using the exact same EVM as\nEthereum, can't we somehow make \"verify EVM execution in ZK\" into a\nprotocol feature, and deal with exceptional situations like bugs and\nupgrades by just applying Ethereum's social consensus, the same way we\nalready do for base-layer EVM execution itself?\nThis is an important and challenging topic. There are a few\nnuances:\n- We want to be compatible with Ethereum's\nmulti-client philosophy . This means that we want to allow\ndifferent clients to use different proving systems. This in turn implies\nthat for any EVM execution that gets proven with one ZK-SNARK system, we\nwant a guarantee that the underlying data is available ,\nso that proofs can be generated for other ZK-SNARK systems.\n- While the tech is immature, we probably want\nauditability. In practice, this means the exact same thing: if\nany execution gets proven, we want the underlying data to be available,\nso that if anything goes wrong, users and developers can inspect\nit.\n- We need much faster proving times , so that if one\ntype of proof is made, other types of proof can be generated quickly\nenough that other clients can validate them. One could get\naround this by making a precompile that has an asynchronous response\nafter some time window longer than a slot (eg. 3 hours), but this adds\ncomplexity.\n- We want to support not just copies of the EVM, but also\n\"almost-EVMs\". Part of the attraction of L2s is the ability to\ninnovate on the execution layer, and make extensions to the EVM. If a\ngiven L2's VM differs from the EVM only a little bit, it would be nice\nif the L2 could still use a native in-protocol ZK-EVM for the parts that\nare identical to the EVM, and only rely on their own code for the parts\nthat are different. This could be done by designing the ZK-EVM\nprecompile in such a way that it allows the caller to specify a bitfield\nor list of opcodes or addresses that get handled by an externally\nsupplied table instead of the EVM itself. We could also make gas costs\nopen to customization to a limited extent.\nOne likely topic of contention with data availability in a native\nZK-EVM is statefulness . ZK-EVMs are much more\ndata-efficient if they do not have to carry \"witness\" data. That is, if\na particular piece of data was already read or written in some previous\nblock, we can simply assume that provers have access to it, and we don't\nhave to make it available again. This goes beyond not re-loading storage\nand code; it turns out that if a rollup properly compresses\ndata, the compression being stateful allows for up to 3x data\nsavings compared to the compression being stateless.\nThis means that for a ZK-EVM precompile, we have two options:\n- The precompile requires all data to be available in the same\nblock . This means that provers can be stateless, but it also\nmeans that ZK-rollups using such a precompile become much more expensive\nthan rollups using custom code.\n- The precompile allows pointers to data used or generated by\nprevious executions. This allows ZK-rollups to be\nnear-optimal, but it's more complicated and introduces a new kind of\nstate that has to be stored by provers.\nWhat lessons can we take away from this? There is a pretty good\nargument to enshrine ZK-EVM validation somehow: rollups are already\nbuilding their own custom versions of it, and it feels wrong\nthat Ethereum is willing to put the weight of its multiple\nimplementations and off-chain social consensus behind EVM execution on\nL1, but L2s doing the exact same work have to instead implement\ncomplicated gadgets involving security councils. But on the other hand,\nthere is a big devil in the details: there are different versions of an\nenshrined ZK-EVM that have different costs and benefits. The stateful vs\nstateless divide only scratches the surface; attempting to support\n\"almost-EVMs\" that have custom code proven by other systems will likely\nreveal an even larger design space. Hence, enshrining ZK-EVMs\npresents both promise and challenges .\nEnshrining\nproposer-builder separation (ePBS)\nThe rise of MEV has made\nblock production into an economies-of-scale-heavy activity, with\nsophisticated actors being able to produce blocks that generate much\nmore revenue than default algorithms that simply watch the mempool for\ntransactions and include them. The Ethereum community has so far\nattempted to deal with this by using extra-protocol proposer-builder\nseparation schemes like MEV-Boost , which allow regular\nvalidators (\"proposers\") to outsource block building to specialized\nactors (\"builders\").\nHowever, MEV-Boost carries a trust assumption in a new category of\nactor, called a relay . For the past two years, there have been\nmany\nproposals to create \"enshrined PBS\" . What is the benefit of this? In\nthis case, the answer is pretty simple: the PBS that can be built by\ndirectly using the powers of the protocol is simply stronger (in the\nsense of having weaker trust assumptions) than the PBS that can be built\nwithout them. It's a similar case to the case for enshrining\nin-protocol price oracles - though, in that situation,\nthere is also a strong\ncounterargument .\nEnshrining private mempools\nWhen a user sends a transaction, that transaction becomes immediately\npublic and visible to all, even before it gets included on chain. This\nmakes users of many applications vulnerable to economic attacks such as\nfrontrunning: if a user makes a large trade on eg. Uniswap, an attacker\ncould put in a transaction right before them, increasing the price at\nwhich they buy, and collecting an arbitrage profit.\nRecently, there has been a number of projects specializing in\ncreating \"private mempools\" (or \"encrypted mempools\"), which keep users'\ntransactions encrypted until the moment they get irreversibly accepted\ninto a block.\nThe problem is, however, that schemes like this require a particular\nkind of encryption: to prevent users from flooding the system and\nfrontrunning the decryption process itself , the encryption must\nauto-decrypt once the transaction actually does get irreversibly\naccepted.\nTo implement such a form of encryption, there are various different\ntechnologies with different tradeoffs, described well in this\npost by Jon Charbonneau (and this video and slides ):\n- Encryption to a centralized operator , eg. Flashbots\nProtect .\n- Time-lock\nencryption , a form of encryption which can be decrypted by\nanyone after a certain number of sequential computational\nsteps, which cannot be parallelized.\n- Threshold\nencryption , trusting an honest majority committee to\ndecrypt the data. See the shutterized\nbeacon chain concept for a concrete proposal.\n- Trusted\nhardware such as SGX .\nUnfortunately, each of these have varying weaknesses. A centralized\noperator is not acceptable for inclusion in-protocol for obvious\nreasons. Traditional time lock encryption is too expensive to run across\nthousands of transactions in a public mempool. A more powerful primitive\ncalled delay encryption allows efficient decryption of\nan unlimited number of messages, but it's hard to construct in practice,\nand attacks\non existing constructions still sometimes get discovered. Much like\nwith hash\nfunctions , we'll likely need a period of more years of research and\nanalysis before delay encryption becomes sufficiently mature. Threshold\nencryption requires trusting a majority to not collude, in a setting\nwhere they can collude undetectably (unlike 51% attacks, where\nit's immediately obvious who participated). SGX creates a dependency on\na single trusted manufacturer.\nWhile for each solution, there is some subset of users that\nis comfortable trusting it, there is no single solution that is trusted\nenough that it can practically be accepted into layer 1. Hence,\nenshrining anti-frontrunning at layer 1 seems like a difficult\nproposition at least until delay encrypted is perfected or there is some\nother technological breakthrough, even while it's a valuable enough\nfunctionality that lots of application solutions will already\nemerge.\nEnshrining liquid staking\nA common demand among Ethereum defi users is the ability to use their\nETH for staking and as collateral in other applications at the same\ntime. Another common demand is simply for convenience: users want to be\nable to stake without the complexity of running a node and keeping it\nonline all the time (and protecting their now-online staking keys).\nBy far the simplest possible \"interface\" for staking, which satisfies\nboth of these needs, is just an ERC20 token: convert your ETH into\n\"staked ETH\", hold it, and then later convert back. And indeed, liquid\nstaking providers such as Lido and Rocketpool have emerged to do just\nthat. However, liquid staking has some natural centralizing mechanics at\nplay: people naturally go into the biggest version of staked ETH because\nit's most familiar and most liquid (and most well-supported by\napplications, who in turn support it because it's more familiar and\nbecause it's the one the most users will have heard of).\nEach version of staked ETH needs to have some mechanism determining\nwho can be the underlying node operators. It can't be unrestricted,\nbecause then attackers would join and amplify their attacks with users'\nfunds. Currently, the top two are Lido, which has a DAO whitelisting\nnode operators, and Rocket Pool, which allows anyone to run a node if\nthey put down 8\nETH (ie. 1/4 of the capital) as a deposit. These two approaches have\ndifferent risks: the Rocket Pool approach allows attackers to 51% attack\nthe network, and force users to pay most of the costs. With the DAO\napproach, if a single such staking token dominates, that leads to a\nsingle, potentially attackable governance gadget\ncontrolling a very large portion of all Ethereum validators. To the\ncredit of protocols like Lido, they have implemented safeguards against\nthis , but one layer of defense may not be enough.\nIn the short term, one option is to socially encourage ecosystem\nparticipants to use a diversity of liquid staking providers, to reduce\nthe chance that any single one becomes too large to be a systemic risk.\nIn the longer term, however, this is an unstable equilibrium, and there\nis peril in relying too much on moralistic pressure to solve problems.\nOne natural question arises: might it make sense to enshrine\nsome kind of in-protocol functionality to make liquid staking less\ncentralizing ?\nHere, the key question is: what kind of in-protocol\nfunctionality ? Simply creating an in-protocol fungible \"staked ETH\"\ntoken has the problem that it would have to either have an enshrined\nEthereum-wide governance to choose who runs the nodes, or be open-entry,\nturning it into a vehicle for attackers.\nOne interesting idea is Dankrad Feist's\nwritings on liquid staking maximalism . First, we bite the bullet\nthat if Ethereum gets 51% attacked, only perhaps 5% of the attacking ETH\ngets slashed. This is a reasonable tradeoff; right now there is over 26 million ETH being staked , and a\ncost of attack of 1/3 of that (~8 million ETH) is way overkill,\nespecially considering how many kinds of \"outside-the-model\" attacks can\nbe pulled off for much less. Indeed, a similar tradeoff has already been\nexplored in the \"super-committee\"\nproposal for implementing single-slot finality.\nIf we accept that only 5% of attacking ETH gets slashed, then over\n90% of staked ETH would be invulnerable to slashing, and so 90% of\nstaked ETH could be put into an in-protocol fungible liquid staking\ntoken that can then be used by other applications.\nThis path is interesting. But it still leaves open the question:\nwhat is the specific thing that would get enshrined ? RocketPool already works in a way\nvery similar to this: each node operator puts up some capital, and\nliquid stakers put up the rest. We could simply tweak a few constants,\nbounding the maximum slashing penalty to eg. 2 ETH, and Rocket Pool's\nexisting rETH would become risk-free.\nThere are other clever things that we can do with simple protocol\ntweaks. For example, imagine that we want a system where there are two \"tiers\" of\nstaking : node operators (high collateral requirement) and depositors\n(no minimum, can join and leave any time), but we still want to guard\nagainst node operator centralization by giving a randomly-sampled\ncommittee of depositors powers like suggesting lists of transactions\nthat have to be included (for anti-censorship reasons), controlling the\nfork choice during an inactivity leak, or needing to sign off on blocks.\nThis could be done in a mostly-out-of-protocol way, by tweaking the\nprotocol to require each validator to provide (i) a regular\nstaking key, and (ii) an ETH address that can be called to output a\nsecondary staking key during each slot. The protocol would give powers\nto these two keys, but the mechanism for choosing the second key in each\nslot could be left to staking pool protocols. It may still be better to\nenshrine some things outright, but it's valuable to note that this\n\"enshrine some things, leave other things to users\" design space\nexists.\nEnshrining more precompiles\nPrecompiles\n(or \"precompiled contracts\") are Ethereum contracts that implement\ncomplex cryptographic operations, whose logic is natively implemented in\nclient code, instead of EVM smart contract code. Precompiles were a\ncompromise adopted at the beginning of Ethereum's development: because\nthe overhead of a VM is too much for certain kinds of very complex and\nhighly specialized code, we can implement a few key operations valuable\nto important kinds of applications in native code to make them faster.\nToday, this basically includes a few specific hash functions\nand elliptic curve operations .\nThere is currently a push to add a precompile for\nsecp256r1 , an elliptic curve slightly different from the secp256k1\nused for basic Ethereum accounts, because it is well-supported by\ntrusted hardware modules and thus widespread use of it could improve\nwallet security. In recent years, there have also been pushes to add\nprecompiles for BLS-12-377 , BW6-761 , generalized pairings\nand other features.\nThe counterargument to these requests for more precompiles is that\nmany of the precompiles that have been added before (eg. RIPEMD\nand BLAKE ) have\nended up gotten used\nmuch less than anticipated , and we should learn from that. Instead\nof adding more precompiles for specific operations, we should perhaps\nfocus on a more moderate approach based on ideas like EVM-MAX\nand the dormant-but-always-revivable SIMD proposal , which\nwould allow EVM implementations to execute wide classes of code less\nexpensively. Perhaps even existing little-used precompiles\ncould be removed and replaced with (unavoidably less efficient) EVM code\nimplementations of the same function. That said, it is still possible\nthat there are specific cryptographic operations that are valuable\nenough to accelerate that it makes sense to add them as precompiles.\nWhat do we learn from all\nthis?\nThe desire to enshrine as little as possible is understandable and\ngood; it hails from the Unix philosophy\ntradition of creating software that is minimalist and can be easily\nadapted to different needs by its users, avoiding the curses of software\nbloat. However, blockchains are not personal-computing operating\nsystems; they are social systems . This means that there are\nrationales for enshrining certain features in the protocol that go\nbeyond the rationales that exist in a purely personal-computing\ncontext.\nIn many cases, these other examples re-capped similar lessons to what\nwe saw in account abstraction. But there are also a few new lessons that\nhave been learned as well:\n- Enshrining features can help avoid centralization risks in\nother areas of the stack . Often, keeping the base protocol\nminimal and simple pushes the complexity to some outside-the-protocol\necosystem. From a Unix philosophy perspective, this is good. Sometimes,\nhowever, there are risks that that outside-the-protocol ecosystem will\ncentralize, often (but not just) because of high fixed costs. Enshrining\ncan sometimes decrease de-facto centralization.\n- Enshrining too much can over-extend the trust and governance\nload of the protocol . This is the topic of this earlier post\nabout not overloading Ethereum's consensus: if enshrining a particular\nfeature weakens the trust model, and makes Ethereum as a whole much more\n\"subjective\", that weakens Ethereum's credible neutrality. In those\ncases, it's better to leave that particular feature as a mechanism on\ntop of Ethereum, and not try to bring it inside Ethereum itself. Here,\nencrypted mempools are the best example of something that may be a bit\ntoo difficult to enshrine, at least until/unless delay encryption\ntechnology improves.\n- Enshrining too much can over-complicate the\nprotocol . Protocol complexity is a systemic risk, and adding\ntoo many features in-protocol increases that risk. Precompiles are the\nbest example of this.\n- Enshrining can backfire in the long term, as users' needs\nare unpredictable . A feature that many people think is\nimportant and will be used by many users may well turn out not to be\nused much in practice.\nAdditionally, the liquid staking, ZK-EVM and precompile cases show\nthe possibility of a middle road: minimal viable\nenshrinement . Rather than enshrining an entire functionality,\nthe protocol could enshrine a specific piece that solves the key\nchallenges with making that functionality easy to implement, without\nbeing too opinionated or narrowly focused. Examples of this\ninclude:\n- Rather than enshrining a full liquid staking system, changing\nstaking penalty rules to make trustless liquid staking more viable\n- Rather than enshrining more precompiles, enshrine EVM-MAX\nand/or SIMD to make\na wider class of operations simpler to implement efficiently\n- Rather than enshrining the whole concept of rollups , we\ncould simply enshrine EVM verification .\nWe can extend our diagram from earlier in the post as follows:\nSometimes, it may even make sense to de-enshrine a few\nthings. De-enshrining little-used precompiles is one example. Account\nabstraction as a whole, as mentioned earlier, is also a significant form\nof de-enshrinement. If we want to support backwards-compatibility for\nexisting users, then the mechanism may actually be surprisingly similar\nto that for de-enshrining precompiles: one of the proposals is EIP-5003 , which would\nallow EOAs to convert their account in-place into a contract that has\nthe same (or better) functionality.\nWhat features should be brought into the protocol and what features\nshould be left to other layers of the ecosystem is a complicated\ntradeoff, and we should expect the tradeoff to continue to evolve over\ntime as our understanding of users' needs and our suite of available\nideas and technologies continues to improve."}
{"url":"https://discuss.ens.domains/t/governor-nexus-implementation-report/22363","domain":"discuss.ens.domains","title":"Governor Nexus - Implementation report - DAO-Governance - ENS DAO Governance Forum","hash":"1e3034c9b2475c9c67896e72faaea0b1b86b130085f3f7d7bffd403a5705cfba","tokens":5201,"chars":20801,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112277679,"text":"ENS DAO Governance Forum\nGovernor Nexus - Implementation report\nđłïž Meta-Governance\nDAO-Governance\nblockful\nAugust 19, 2026, 6:54pm\n1\nTL;DR: The Governor Nexus RFC we posted five months ago is now fully implemented, built on stock OpenZeppelin plus the mechanisms the RFC proposed, and the code is public at blockful/nexus . This post explains what we shipped and opens a two-week feedback window before we move to the external audit.\nWhat we built\nGovernor Nexus is built on OpenZeppelin v5.6.1. The core is composed from the standard audited Governor modules. We wrote only what the RFC proposed and OZ does not provide:\n- the proposal-type registry , governed by vote\n- the three initially suggested rulesets : Standard, Optimistic, and Bond\n- the security mechanisms on the core: mutable votes, the late-vote extension, the per-proposer spam limit, the proposal cancellation policy, and batch voting\nThe existing timelock is untouched, as the RFC committed.\n+------------------------------+ +-----------+\nUsers ----------> | Governor Nexus Core | -----> | Timelock |\n| (proposal lifecycle, type | | (kept |\n| registry, timelock admin) | | as-is) |\n+------------------------------+ +-----------+\n^\n| counting, quorum and success, per type\n+--------------------+--------------------+\n| | |\n+------------------+ +--------------------+ +------------------+\n| Standard Ruleset | | Optimistic Ruleset | | Bond Ruleset |\n| same as live ENS | | pass unless opposed| | lock-to-propose |\n+------------------+ +--------------------+ +------------------+\nEvery proposal gets exactly one type at creation and keeps it forever. A typeâs registry entry (ruleset, voting delay, voting period, proposal threshold) never changes after registration, and rulesets themselves are immutable contracts with no setters. The only things a vote can change are which types are active and which one is the default. The DAO evolves governance by registering new types, never by changing live ones, so what the DAO audited is what runs.\nHow we addressed each risk\nThe RFC was built on our Governance Security Assessment , which placed ENS at Stage 0 under the Anticapture framework . Each risk from that assessment now has a shipped mechanism:\nRisk\nSeverity\nImplemented fix\nStatus\nInsufficient voting delay\nCritical\nVoting delay is a per-type registry parameter. The migration proposal sets it to 2 days by vote, and tuning it later needs no code change\nNo active proposal limits\nCritical\nEach proposer can have at most 2 live proposals ( Pending or Active ), adjustable by vote between 1 and 10\nNo continuous threshold enforcement\nHigh\nA proposal whose proposer drops below the threshold becomes cancellable by anyone, while voting continues\nInterface security unverified\nMedium\nWith mutable votes, a voter can recast and replace their vote, so a vote cast through a compromised interface can be corrected before the deadline\nNo late vote extension\nMedium\nA proposal that flips from failing to passing in the final 24h extends voting by 48h from the original deadline\nVote immutability\nMedium\nAddressed by the same mutable votes mechanism as interface security above\nNo optimistic path for routine ops\nLow\nWith OptimisticRuleset , a proposal passes unless 500k ENS oppose it. Only allowlisted proposers and actions can use it, and the allowlists start empty\nUniform approval thresholds\nLow\nEvery type has its own delay, period, threshold, and quorum in the registry\nNo batch voting\nLow\nA single call casts votes on several proposals ( castVoteWithReasonAndParamsBatch , votes only, all-or-nothing)\nSubsidy coverage for contract wallets\nLow\nVoting by signature now accepts ERC-1271 contract signatures (from OpenZeppelin v5), so Safes and multisigs can sign votes for a relayer to submit\nWith these mechanisms deployed and the migration parameters ratified, ENS moves from Stage 0 to Stage 1 , as the RFC set out to do.\nDesign decisions\nWe made many design decisions during implementation. These are the ones the community should weigh in on:\n#\nDecision\nWhat shipped\nTrade-off accepted\n1\nA re-vote replaces the old vote\nA re-vote removes the old weight and adds the new one in the same call, so a vote is never counted twice and never briefly missing\nQuorum and success can flip both ways while voting is open\n2\nLate-vote extension evaluates only at the deadline\nFires only if the proposal was observed failing at some point in the final 24h and would pass at the deadline, with the 48h extension counted from that original deadline\nWe gave up OZâs audited PreventLateQuorum and wrote our own extension logic\n3\nBatch voting is an explicit function\nA dedicated function that batches votes only, applying all of them or none\nOnly votes can be batched, and it is all-or-nothing, so one failing vote reverts the whole batch\n4\nCancellation narrower than Bravoâs\nProposers can cancel their own proposals, and anyone can cancel one whose proposer dropped below the threshold, only while it is Pending or Active\nOnce a proposal passes, nobody can cancel it through the governor. A harmful proposal discovered after the vote can only be stopped by the timelock or the Security Council\n5\nOptimistic path starts empty\nProposer and action allowlists start empty. Calls into the governor or the registry can never be allowlisted\nThe optimistic path does nothing at launch, and adding each proposer or action requires a full governance vote\n6\nBond slash rule is EP 5.15 , verbatim\nThe bond is forfeited only if the combined against votes strictly beat the for votes, and the votes asking to slash strictly beat those against without slashing. Any tie refunds the bond\nBond parameters are fixed at deployment. Changing them means deploying a new ruleset through governance\n7\nBonds refund once the proposal survives the vote\nAnyone can call resolveBond once the proposal reaches Succeeded\nA timelock veto forfeits the bond only if still unsettled when it lands (see note below)\nTwo of these deserve a longer note:\nThe crossing rule (decisions 1â2). The RFC discussion rightly flagged the game-theoretic complexity mutable votes add. We kept mutability because it is the only recovery path when a voting interface is compromised. This is not locked in either. Vote counting lives in the ruleset layer, so a future ruleset can implement immutable votes without changing the governor. We turned the concern into a hard design rule for the whole system. Nothing may be permanently triggered by a tally crossing a threshold. An attacker could cross a threshold early, re-vote back below it, and waste the trigger before the crossing that matters. So everything that needs finality evaluates at the deadline instead of reacting to crossings.\nThe bond softening (decision 7). We implemented the EP 5.15 slash rule exactly as ratified. But bonds refund from Succeeded onward, and anyone can settle a passed proposalâs bond. So if the Security Council vetoes the proposal while it sits in the timelock, the bond is only forfeited if nobody settled it first. We accept this because the bond is an anti-spam instrument, and surviving the vote fulfills its purpose. Still, this is the one place where we consciously softened what was originally discussed, and we flag it here for exactly that reason.\nRisks we accepted\nA registered ruleset is trusted. The registry chooses how votes are counted, not what a type is allowed to do. Every active type can execute any action through the timelock, and a buggy or malicious ruleset decides which of its own typeâs proposals pass. We mitigate this with process rather than code, because registering a type is a full governance action, and the quorum and threshold chosen at registration are security parameters for the whole DAO.\nPer-address limits donât resist address-splitting. The spam cap and proposal threshold are per-address, like every production governorâs. The bond changes the economics instead, since each sybil identity locks a full bond and spam cost scales linearly with proposal count no matter how it is split.\nA single-block dip below the threshold counts. A proposer whose power dips below threshold for one block leaves their proposal cancellable at the next. This is only a griefing vector, the proposer controls it, and it matches how Bravo already behaves. We added no grace period.\nThe extension fires only once. A flip at the end of the extended window gets no second extension, per the RFC. The defense here is delegates watching the vote, not a code change.\nEach of these risks is documented in depth in the repo.\nHow we tested it\nWe tested at every level. Each mechanism has its own unit suite. Beyond units, adversarial suites prove a misbehaving ruleset cannot affect proposals of other types, and fuzz and invariant suites check system-wide properties, like bond custody staying solvent ( locked = refunded + slashed ) across randomized lifecycles.\nWe also ran fork and differential tests against the current mainnet governor. Each difference we introduced on purpose (mutable votes, the late-vote extension, the new functions and events) has its own dedicated test, so CI fails if the two ever diverge in a way we didnât intend. The fork tests also gave us the gas numbers. Proposing costs about 24k more gas, voting 29k more, queueing 20k more, and executing gets 18k cheaper, with the full breakdown in the repo README.\nFinally, every mechanism went through an internal security review before we moved to the next. All high-severity findings were addressed, and the risks we accepted are the ones listed above. These reviews complement but do not replace an external audit (see the open questions and timeline below).\nIntegration notes\nIf you build on top of the governor (indexers, voting interfaces, gasless relayers), these are the changes that affect you:\n- Indexers: when someone re-votes, the governor emits another standard VoteCast event for the same proposal and voter, and the latest event in log order is the one that counts. If youâd rather not track events, voteReceipt(proposalId, voter) returns the standing vote directly.\n- Gasless relayers: build ballots from voteNonce(proposalId, account) , not the account-global nonces(address) , because ballot nonces are per-proposal. When a voter votes directly, that spends the proposalâs nonce and invalidates any outstanding signed ballot for it, while signatures held for other proposals stay valid.\n- Deadlines: always trust proposalDeadline() . The deadline only grows when an extension actually fires, so you will never see a tentative extension mid-window. The ProposalExtended event uses OZâs ABI verbatim.\n- Counting modes: if your indexer already supports Optimismâs optimistic governor, it supports ours, since the optimistic type advertises the same COUNTING_MODE string.\nOpen questions for the DAO\n- Audit firm. Which firms should we request quotes from? Our recommendation: firms with deep OpenZeppelin Governor experience. OpenZeppelin themselves (they wrote the code Nexus builds on) and Trail of Bits are the first firms we would ask, alongside other reputable firms suggested in this thread. We will collect suggestions during the feedback window and publish the quotes alongside the audit proposal.\n- Optimistic allowlist curation. Which proposers and which actions should the first curation vote allow, or should the path stay empty at launch? Our recommendation: migrate with the allowlists empty and run the first curation vote only once the system is live, starting with recurring, bounded operations (service-provider stream management is the natural first candidate) and never treasury token approvals.\n- Migration parameters. The migration proposal will set the concrete values: a 2-day voting delay, per-type voting periods and thresholds, a 1,000 ENS bond, and a 500k ENS opposition threshold for optimistic proposals. Do these look right to you? Our recommendation: keep them as proposed. The 2-day delay is what our assessment recommended, the 1,000 ENS bond is what the DAO already ratified in EP 5.15 , and the 500k opposition threshold comes from the RFC.\nTimeline and next steps\nThis post opens a two-week community feedback window on the questions and recommendations above. During the window we will walk through the implementation in a blockful office hours session, and we encourage technical readers to review the repo and point out risks we didnât map.\nStep\nWindow\nStatus\nRFC posted for discussion\nMar 2026\nDone\nCommunity feedback incorporated\nMar â Jun 2026\nDone\nImplementation (mechanism by mechanism, each with spec, tests, and internal review)\nJul 2026\nDone\nImplementation report (this post) and two-week feedback window\nAug 2026\nWe are here\nExternal audit proposal: scope, firm, and price\nOnce quotes are in\nNext\nExternal audit and fixes\nPost-approval\nPending\nMigration proposal: deployment, parameter ratification, Timelock-admin transfer\nPost-audit\nPending\nAfter the window closes:\n- We incorporate the threadâs feedback, finalize the audit scope, and request quotes from the shortlisted firms.\n- Once the quotes are in, we post the external audit proposal (final scope, firm, and price) for the DAOâs approval.\n- Post-audit, we publish the migration plan (deployment, parameter ratification, and the Timelock-admin transfer we deliberately left out of this phase) and take it to a vote.\nblockfulâs work on this project is covered under its Service Provider proposal.\n1 Like\nMeta-Gov Working Group Term 7 Meetings: Thursday, 4pm UTC. Bi-weekly\nBlockful - service provider reports and updates\nENS DAO Newsletter #119 â 09/01/2026\nBlockful - service provider reports and updates\ngregskril\nAugust 19, 2026, 8:32pm\n2\nSome thoughts/questions regarding the âHow we addressed each riskâ section:\n- My understanding is âNo active proposal limitsâ and âNo continuous threshold enforcementâ need to happen together, otherwise someone can submit 2 proposals then delegate tokens to another account, repeating this infinite times. Is a simpler solution just a global rate limit of 3-5 active proposals at a time?\n- I agree that mutable votes would be good.\n- I donât necessarily see the need for late vote extension. Itâs very common for people to vote at the end, so I could see this just adding a day to ~every proposalâs lifecycle. I was going to raise the concern of DOS attacks, but see that it can only be extended once so thatâs a non-issue.\n- Optimistic voting scares me, and I think delegate burden should reduce overtime as routine ops move to the Foundation. Are there any specific examples of things youâd want to support with Optimistic voting in the short-medium term?\n- I donât think the current lack of batch voting is an issue, and think most voting UX leads people to do 1 at a time anyways. Plus I see this as more of a wallet issue over time with things like EIP-5792. But ultimately I donât have a reason to be against this, so would consider it neutral.\n2 Likes\nblockful\nAugust 24, 2026, 8:47pm\n3\nThanks for the close read @gregskril . Answering the three points that have questions in them.\n1. Proposal limits and threshold enforcement. That is correct, the per-proposer cap and the below-threshold cancellation were designed to work as a pair.\nWe prefer the pair over a global cap. A cap of 3 to 5 would be simpler, but it creates a worse problem than the one it solves. An attacker keeps 5 spam proposals live and blocks governance forever, since nobody else can propose while the slots are full.\nA per-address cap alone has the hole you found. An attacker with enough voting power proposes 2, moves the tokens to a fresh address, proposes 2 more, and keeps doing it. The below-threshold cancellation handles that problem because, the moment the tokens leave an address, its proposals drop below the threshold and anyone can cancel them.\n3. Late-vote extension. People voting at the end is not the problem and does not trigger the extension. The problem is a proposal that was failing and flips to passing at the last minute. That is a snipe. Someone with enough power to change the outcome votes right before the deadline, and delegates have no time to react or rally votes against it.\nThe extension exists only for that case. It fires only if the proposal was failing at some point in the final 24 hours and would pass at the deadline. A proposal whose outcome direction is stable gets zero delay no matter how many people vote late. And it fires once per proposal, so voting can never be extended forever.\n4. Optimistic voting. We share the caution, and the design reflects it in two ways.\nFirst, Nexus is composable, so the optimistic path is optional. Our recommendation is to migrate with the allowlists empty, which means the path does nothing at launch. If the DAO decides it never wants optimistic proposals, that blocks nothing else in the upgrade.\nSecond, if the DAO does want it, it controls exactly who and what. Both the proposer and the action need to be allowlisted by a full governance vote, and proposals can carry no ETH value. The setter refuses calls into the governor, the registry, and the timelock, so the path can never expand its own permissions. And 500k ENS in opposition kills any optimistic proposal.\nThe example we gave in the report still stands. We would start with recurring, bounded operations like service-provider stream management, and never treasury token approvals. Your point about the Foundation absorbing routine ops fits this fine. If that happens, the allowlists just stay empty and cost nothing.\n1 Like\nnick.eth\nAugust 25, 2026, 12:45am\n4\nHow do you determine that it was âobserved failingâ?\nBonds are per-proposal, not per-sybil-identity, right? So a per-account proposal limit doesnât increase cost for spammers compared to the default.\nOZ would definitely be my top choice here, by a fair margin.\nI would go further- leave this empty until we identify an active need for it. As Greg observes, there should be less call for this with the foundation managing the treasury.\n1 Like\nblockful\nAugust 25, 2026, 8:53pm\n5\nThanks @nick.eth .\nObserved failing. The observation happens at vote time. Every time someone votes, the contract evaluates _quorumReached && _voteSucceeded right before and right after counting that vote. That tells us two things:\n- Whether the proposal was failing before the vote, or is failing after it.\n- And when a proposal that was failing is now passing.\nThose checks update a per-proposal status we call LateFlipStage . If a check runs inside the final 24 hours and the proposal is failing, meaning it would not pass if voting closed right there, the status moves from None to FailingObserved . The passing half is checked at the original deadline, so a FailingObserved proposal that would pass there gets the extension.\nThis observation is what makes the extension possible when a late flip happens. The implementation is in GovernorPreventLateFlip.sol .\nBonds and the per-account cap. You are right, bonds are per-proposal, and the cap alone adds no cost for a spammer, since splitting across addresses is free. The cap only bounds how many live proposals one address can hold at once. The economic cost comes from what each proposal path charges:\n- On the bond path, every proposal locks a full bond and a slash vote forfeits it. Ten spam proposals put ten bonds at risk no matter how many addresses they came from.\n- On the standard path, each address needs the full proposal threshold and keeps needing it, because dropping below leaves its proposals cancellable by anyone. So with the cap at two, holding ten live proposals takes five addresses at the full threshold each, all at the same time.\n1 Like\nblockful\nSeptember 24, 2026, 2:33pm\n6\nQuick update on where the audit stands. The feedback window closed on Sep 2, we requested quotes from the firms named in this thread and from one more, and all three came back. We are now working with the MetaGov stewards on the firm selection and the audit proposal that follows it.\nOn the feedback itself, the questions raised here were answered in the thread and none of them called for a change to the code, so the firms scoped the code exactly as reported in August. We noted the preferences on the audit firm, and they are part of the selection.\nThe next step is the audit proposal, which we bring to the community with the firm, the scope and the price for the DAOâs approval. The audit is planned for the quarter starting in October, and we are working to have it running early in that quarter.\nENS DAO Newsletter #121 â 10/1/2026\nJames\nSeptember 28, 2026, 6:19am\n8\nSad to see such a small amount of community engagement around such an important proposal. Sad to see whats become of the forum. FireEyes supported this proposal and wish there had been more support from key ENS leaders\nLong live Ethereumâs many naming services.\n1 Like"}
{"url":"https://docs.berachain.com/bend/learn/overview","domain":"docs.berachain.com","title":"Introduction - Berachain","hash":"1d04386e460f862ddd14b9fe5f5dc59dd817f6d7d97bad084d105e7cf75b01e7","tokens":224,"chars":896,"crawler":"hive-genesis","verified":"exact","ts":1791112278639,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nBerachain home page\nGeneral\nBEX\nBend\nBuild\nNodes\nOverview\nIntroduction\nDecentralized lending on Berachain. Get started with guides and concepts.\nBend is the native lending protocol on BerachainâMorpho-based vaults and markets with Proof-of-Liquidity. Lend, borrow, and earn.\nGet started\nWhat is Bend?\nHow Bend works, key features, use cases, and getting started.\nDeposit & Withdraw\nSupply assets to a vault and optionally stake for PoL rewards.\nBorrow & Repay\nSupply collateral and borrow; monitor LTV to avoid liquidation.\nMarket & Vault\nHow lending markets and vaults work on Bend.\nBuild with Bend\nDeveloper resources: contracts, markets, and onchain tooling.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.skyeco.com/t/grove-cbeam-configuration/28216","domain":"forum.skyeco.com","title":"Grove cBEAM Configuration - Grove Prime - Sky Forum","hash":"be1b168c84f390df8c1ac2323d42d92e952fff4d9b110a793aab82755ce49e5b","tokens":7462,"chars":29848,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112279511,"text":"Sky Forum\nGrove cBEAM Configuration\nGrove Prime\noea ,\npas\nSoterLabs\nSeptember 3, 2026, 5:06pm\n1\nGrove cBEAM Configuration\nIntroduction\nThis forum thread is for communicating activity for the Grove Configurator Bounded External Access Module (cBEAM), maintained as required by A.2.2.10.1.1.1.2.4.4.2 â Public Communication .\nA cBEAM is a whitelisted Operator of a Diamond Parallelized Allocation Unit (Diamond PAU). It can use the Configurator to adjust that unitâs rate limits within the ceilings BeamState sets, without requiring a spell, or waiting for the GSM Pause Delay, as specified in A.1.10.3.2.10.5 â cBEAM Exception and A.2.2.10.1.1.1.2.4.4.1 â Operator Execution . The Operator for the Grove Diamond PAU is specified in A.2.2.10.1.1.1.2.4.4.3.1 â Operator For The Grove Diamond PAU .\nSky Governance maintains full control over cBeam actions via an Executive Vote or CoreCouncil actions. The CoreCouncil can immediately unpair a misbehaving cBEAM from its RateLimits contract or Controller, or remove its registration entirely, as specified in A.2.2.10.1.1.1.2.4.3.4 â Immediate Function Calls , and Configurator operations can be halted for all cBEAMs at once through the PASMom contract, as specified in A.2.2.10.1.1.1.2.4.3.6 â PASMom .\nParameter Configurations\nThe bounds applying to the Grove Diamond PAU are specified in A.2.2.10.1.1.1.2.4.2.1 â Grove Diamond PAU .\nAll parameters are set by Sky Governance in BeamState and can be changed through Executive Votes. They bound increases only; a decrease, including a decrease to zero, takes effect immediately and is not bounded.\n- hop defines the minimum time that must pass before the same rate limit may be increased again â A.2.2.10.1.1.1.2.4.1.1.1 â Hop Definition , current value in A.2.2.10.1.1.1.2.4.1.1.2 â Hop Default Value\n- maxChange defines the maximum increase which can occur within hop , as a multiple of the rate limitâs current value â A.2.2.10.1.1.1.2.4.1.2.1 â Max Change Definition , current value in A.2.2.10.1.1.1.2.4.1.2.2 â Max Change Default Value\n- a rate limit locked as unlimited can be neither raised nor lowered â A.2.2.10.1.1.1.2.4.1.3 â Locked Unlimited Rate Limit Definition\nMethodology for Changing Rate Limits\nThe target maxAmount and slope are specified in the Atlas â controller-wide in A.6.1.1.2.2.6.1.2.1.1.3.3 â Diamond PAU Rate Limits and per venue in each Instance Configuration Document â and the cBEAMâs role is to adjust the on-chain value to them incrementally, at the rate bounds permit. Each execution action will have a corresponding reply in this thread listing every RateLimitID (see A.6.1.1.2.2.6.1.2.1.1.3.2 â Diamond PAU Rate Limit IDs ), its value before, its value after, and the transaction hash.\n1 Like\nSoterLabs\nSeptember 3, 2026, 9:48pm\n2\nTarget #1 â New RateLimit Targets Approved\nToday, Grove Governance has approved Diamond PAU Rate Limits â Update the Recorded Values, Applied via the cBEAM , approving new RateLimit values for maxAmount and slope parameters under A.6.1.1.2.2.6.1.2.1.1.3.3 - Diamond PAU Rate Limits in the Grove Artifact.\n-\nTokenized Treasury JTRSY inflow RateLimitID 0x44ad4f925dffddd260f6ba5813208bf35b11b254e79611cbc8443c1504f68e68\n- maxAmount : 5 million â 15 million USDS\n- slope : 5 million â 15 million USDS per day\n-\nUSDS mint RateLimitID 0xcb0537d5e5dba65a8edbac12555995860e5b8e1b70996011edb1ca8173e56d3c\n- maxAmount : 5 million â 15 million USDS\n- slope : 5 million â 30 million USDS per day\n-\nUSDS burn RateLimitID 0x844d35ae585cfdeed0a77b7724286a1d4b5718bf8663d85e55396062b1cbe38c\n- maxAmount : 5 million â 15 million USDS\n- slope : 5 million â 30 million USDS per day\n-\nUSDS-to-USDC swap RateLimitID 0x00d4cb8ac2838f11d95b0136a919a13b994f920024aba35eee16dc433c65851c\n- maxAmount : 5 million â 15 million USDC\n- slope : 5 million â 30 million USDC per day\n-\nUSDC-to-USDS swap RateLimitID 0x87835797fec2ad9575bc1a7035e3c27b8a8b7db2c3d7118513baf081b3af06b3\n- maxAmount : 5 million â 15 million USDC\n- slope : 5 million â 30 million USDC per day\n-\nUniswap V3 AUSD/USDC deposits aggregate(Pool) RateLimitID\n0xd3384d5424cd179640223010fed859f38b86b26e5e0b9ee88b87321b98882f57\n- slope : 350,000 â 5 million per day\n-\nUniswap V3 AUSD/USDC deposits AUSD RateLimitID\n0x89c0cb8c17898781d7c1776eafcf73fd0b570659ad5c3791ddcbefe66b001541\n- slope : 350,000 â 5 million per day\n-\nUniswap V3 AUSD/USDC deposits USDC RateLimitID\n0x71efb11b03476e40dcc1ade629d360114fcbf838d70a3211270f69414ba9a187\n- slope : 350,000 â 5 million per day\n-\nUniswap V3 AUSD/USDC swaps AUSD RateLimitID\n0x7dd93dac252469b97c259284118454a6a09efd0e5f781dec59acc240f8f88402\n- maxAmount : 1 million â 5 million\n-\nUniswap V3 AUSD/USDC swaps USDC RateLimitIDs\n0x6e850dcb18bea10055c82d1e3753f551b1228d04b81350ba117235de19f9a0da\n- maxAmount : 1 million â 5 million\n15 new target amounts on 10 ten RateLimitIDs will require 145 parameter adjustments.\n1 Like\nSoterLabs\nSeptember 3, 2026, 10:04pm\n3\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed first transaction for Target #1 .\nTransaction: 0xf9403128217a69d7c076d0ee7b070903a9a1aa1220dbf9c0e42ae3d342133bcc\n-\nTokenized Treasury JTRSY inflow\n- maxAmount : 6 million USDS (previously 5 million)\n- slope : 6 million USDS per day (previously 5 million)\n-\nUSDS mint\n- maxAmount : 6 million USDS (previously 5 million)\n- slope : 6 million USDS per day (previously 5 million)\n-\nUSDS burn\n- maxAmount : 6 million USDS (previously 5 million)\n- slope : 6 million USDS per day (previously 5 million)\n-\nUSDS-to-USDC swap\n- maxAmount : 6 million USDC (previously 5 million)\n- slope : 6 million USDC per day (previously 5 million)\n-\nUSDC-to-USDS swap\n- maxAmount : 6 million USDC (previously 5 million)\n- slope : 6 million USDC per day (previously 5 million)\n-\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 420,000 per day (previously 350,000)\n-\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 420,000 per day (previously 350,000)\n-\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 420,000 per day (previously 350,000)\n-\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 1.2 million (previously 1 million)\n-\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 1.2 million (previously 1 million)\n1 Like\nLex\nSeptember 4, 2026, 1:48pm\n4\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0x4ad44461760d17ce15a676e4a8970f45e09db25ddb0423eecf139c33a77c86dc\nTokenized Treasury JTRSY inflow\n- maxAmount : 7.2 million USDS (previously 6 million)\n- slope : 7.2 million USDS per day (previously 6 million)\nUSDS mint\n- maxAmount : 7.2 million USDS (previously 6 million)\n- slope : 7.2 million USDS per day (previously 6 million)\nUSDS burn\n- maxAmount : 7.2 million USDS (previously 6 million)\n- slope : 7.2 million USDS per day (previously 6 million)\nUSDS-to-USDC swap\n- maxAmount : 7.2 million USDC (previously 6 million)\n- slope : 7.2 million USDC per day (previously 6 million)\nUSDC-to-USDS swap\n- maxAmount : 7.2 million USDC (previously 6 million)\n- slope : 7.2 million USDC per day (previously 6 million)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 504,000 per day (previously 420,000)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 504,000 per day (previously 420,000)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 504,000 per day (previously 420,000)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 1.44 million (previously 1.2 million)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 1.44 million (previously 1.2 million)\nLex\nSeptember 7, 2026, 8:27am\n5\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0x62a4b007fce5f815e373fffa1780e2b5bdadbef41b6f0ab30873b5a63a8eeabf\nTokenized Treasury JTRSY inflow\n- maxAmount : 8.64 million USDS (previously 7.2 million)\n- slope : 8.64 million USDS per day (previously 7.2 million)\nUSDS mint\n- maxAmount : 8.64 million USDS (previously 7.2 million)\n- slope : 8.64 million USDS per day (previously 7.2 million)\nUSDS burn\n- maxAmount : 8.64 million USDS (previously 7.2 million)\n- slope : 8.64 million USDS per day (previously 7.2 million)\nUSDS-to-USDC swap\n- maxAmount : 8.64 million USDC (previously 7.2 million)\n- slope : 8.64 million USDC per day (previously 7.2 million)\nUSDC-to-USDS swap\n- maxAmount : 8.64 million USDC (previously 7.2 million)\n- slope : 8.64 million USDC per day (previously 7.2 million)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 604,800 per day (previously 504,000)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 604,800 per day (previously 504,000)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 604,800 per day (previously 504,000)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 1.728 million (previously 1.44 million)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 1.728 million (previously 1.44 million)\nLex\nSeptember 8, 2026, 10:14am\n6\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0x07e4f6291fa54debfb5ad8afc676f93368f44e81171f130f8067a5f1c5401513\nTokenized Treasury JTRSY inflow\n- maxAmount : 10.368 million USDS (previously 8.64 million)\n- slope : 10.368 million USDS per day (previously 8.64 million)\nUSDS mint\n- maxAmount : 10.368 million USDS (previously 8.64 million)\n- slope : 10.368 million USDS per day (previously 8.64 million)\nUSDS burn\n- maxAmount : 10.368 million USDS (previously 8.64 million)\n- slope : 10.368 million USDS per day (previously 8.64 million)\nUSDS-to-USDC swap\n- maxAmount : 10.368 million USDC (previously 8.64 million)\n- slope : 10.368 million USDC per day (previously 8.64 million)\nUSDC-to-USDS swap\n- maxAmount : 10.368 million USDC (previously 8.64 million)\n- slope : 10.368 million USDC per day (previously 8.64 million)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 725,760 per day (previously 604,800)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 725,760 per day (previously 604,800)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 725,760 per day (previously 604,800)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 2.0736 million (previously 1.728 million)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 2.0736 million (previously 1.728 million)\nLex\nSeptember 9, 2026, 11:47am\n7\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0xf25736e3b3c7d8e4865f20d21090a02aa83b869f74b83daa0a8a609bc45924c2\nTokenized Treasury JTRSY inflow\n- maxAmount : 12,441,600 USDS (previously 10,368,000)\n- slope : 12,441,600 USDS per day (previously 10,368,000)\nUSDS mint\n- maxAmount : 12,441,600 USDS (previously 10,368,000)\n- slope : 12,441,600 USDS per day (previously 10,368,000)\nUSDS burn\n- maxAmount : 12,441,600 USDS (previously 10,368,000)\n- slope : 12,441,600 USDS per day (previously 10,368,000)\nUSDS-to-USDC swap\n- maxAmount : 12,441,600 USDC (previously 10,368,000)\n- slope : 12,441,600 USDC per day (previously 10,368,000)\nUSDC-to-USDS swap\n- maxAmount : 12,441,600 USDC (previously 10,368,000)\n- slope : 12,441,600 USDC per day (previously 10,368,000)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 870,912 per day (previously 725,760)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 870,912 per day (previously 725,760)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 870,912 per day (previously 725,760)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 2,488,320 (previously 2,073,600)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 2,488,320 (previously 2,073,600)\nLex\nSeptember 10, 2026, 9:44am\n8\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0x0577178e34b5891ae0751f09630afaa8a4a802593f17b804f1c14afc5f2b2803\nTokenized Treasury JTRSY inflow\n- maxAmount : 14,929,920 USDS (previously 12,441,600)\n- slope : 14,929,920 USDS per day (previously 12,441,600)\nUSDS mint\n- maxAmount : 14,929,920 USDS (previously 12,441,600)\n- slope : 14,929,920 USDS per day (previously 12,441,600)\nUSDS burn\n- maxAmount : 14,929,920 USDS (previously 12,441,600)\n- slope : 14,929,920 USDS per day (previously 12,441,600)\nUSDS-to-USDC swap\n- maxAmount : 14,929,920 USDC (previously 12,441,600)\n- slope : 14,929,920 USDC per day (previously 12,441,600)\nUSDC-to-USDS swap\n- maxAmount : 14,929,920 USDC (previously 12,441,600)\n- slope : 14,929,920 USDC per day (previously 12,441,600)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 1,045,094 per day (previously 870,912)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 1,045,094 per day (previously 870,912)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 1,045,094 per day (previously 870,912)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 2,985,984 (previously 2,488,320)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 2,985,984 (previously 2,488,320)\nLex\nSeptember 11, 2026, 11:47am\n9\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0xd71194cc2c4821bbf5bd64e033026345191f317ea7f8e05d12b76c7c828918f1\nTokenized Treasury JTRSY inflow\n- maxAmount : 15,000,000 USDS (previously 14,929,920)\n- slope : 15,000,000 USDS per day (previously 14,929,920)\nUSDS mint\n- maxAmount : 15,000,000 USDS (previously 14,929,920)\n- slope : 17,915,904 USDS per day (previously 14,929,920)\nUSDS burn\n- maxAmount : 15,000,000 USDS (previously 14,929,920)\n- slope : 17,915,904 USDS per day (previously 14,929,920)\nUSDS-to-USDC swap\n- maxAmount : 15,000,000 USDC (previously 14,929,920)\n- slope : 17,915,903 USDC per day (previously 14,929,920)\nUSDC-to-USDS swap\n- maxAmount : 15,000,000 USDC (previously 14,929,920)\n- slope : 17,915,903 USDC per day (previously 14,929,920)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 1,254,113 per day (previously 1,045,094)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 1,254,113 per day (previously 1,045,094)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 1,254,113 per day (previously 1,045,094)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 3,583,180.8 (previously 2,985,984)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 3,583,180.8 (previously 2,985,984)\nLex\nSeptember 14, 2026, 11:11am\n10\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0x9ac4fcd0925ebd55621cb8a4246d18f8605bc4cb20331ada003362dc4b606b96\nUSDS mint\n- slope : 21,499,085 USDS per day (previously 17,915,904)\nUSDS burn\n- slope : 21,499,085 USDS per day (previously 17,915,904)\nUSDS-to-USDC swap\n- slope : 21,499,084 USDC per day (previously 17,915,903)\nUSDC-to-USDS swap\n- slope : 21,499,084 USDC per day (previously 17,915,903)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 1,504,936 per day (previously 1,254,113)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 1,504,935 per day (previously 1,254,113)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 1,504,935 per day (previously 1,254,113)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 4,299,816.96 (previously 3,583,180.8)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 4,299,816.96 (previously 3,583,180.8)\npyramid\nSeptember 15, 2026, 7:26pm\n12\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0x707b3d29175d65f01430f90dc92cb71c06e59e1766840b6ff0fa44f3b04a18c4\nUSDS mint\n- slope : 25,798,902 USDS per day (previously 21,499,085)\nUSDS burn\n- slope : 25,798,902 USDS per day (previously 21,499,085)\nUSDS-to-USDC swap\n- slope : 25,798,901 USDC per day (previously 21,499,084)\nUSDC-to-USDS swap\n- slope : 25,798,901 USDC per day (previously 21,499,084)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 1,805,923 per day (previously 1,504,936)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 1,805,922 per day (previously 1,504,935)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 1,805,922 per day (previously 1,504,935)\nUniswap V3 AUSD/USDC swaps â AUSD\n- maxAmount : 5,000,000 (previously 4,299,816.96)\nUniswap V3 AUSD/USDC swaps â USDC\n- maxAmount : 5,000,000 (previously 4,299,816.96)\npyramid\nSeptember 16, 2026, 12:43pm\n13\nExecuted - Txn for Target #1\nOperational GovOps Soter Labs , acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #1 .\nTransaction: https://etherscan.io/tx/0xbe64c43d547a49d5fd20086174a9a4f6ee0c6bdd2e793f148a51d55c0b494364\nUSDS mint\n- slope : 30,000,000 USDS per day (previously 25,798,902)\nUSDS burn\n- slope : 30,000,000 USDS per day (previously 25,798,902)\nUSDS-to-USDC swap\n- slope : 30,000,000 USDC per day (previously 25,798,901)\nUSDC-to-USDS swap\n- slope : 30,000,000 USDC per day (previously 25,798,901)\nUniswap V3 AUSD/USDC deposits â aggregate (Pool)\n- slope : 2,167,108 per day (previously 1,805,923)\nUniswap V3 AUSD/USDC deposits â AUSD\n- slope : 2,167,107 per day (previously 1,805,922)\nUniswap V3 AUSD/USDC deposits â USDC\n- slope : 2,167,107 per day (previously 1,805,922)\nLex\nSeptember 17, 2026, 5:15pm\n14\nTarget #2 â New RateLimit Targets Approved\nToday, Grove Governance has approved Diamond PAU Rate Limits â Update the Recorded Values, Applied via the cBEAM , approving new RateLimit values for maxAmount and slope parameters under A.6.1.1.2.2.6.1.2.1.1.3.3 - Diamond PAU Rate Limits in the Grove Artifact.\nTokenized Treasury JTRSY inflow RateLimitID 0x44ad4f925dffddd260f6ba5813208bf35b11b254e79611cbc8443c1504f68e68\n- maxAmount : 15 million â 50 million USDS\n- slope : 15 million â 50 million USDS per day\nUSDS mint RateLimitID 0xcb0537d5e5dba65a8edbac12555995860e5b8e1b70996011edb1ca8173e56d3c\n- maxAmount : 15 million â 50 million USDS\n- slope : 30 million â 50 million USDS per day\nUSDS-to-USDC swap RateLimitID 0x00d4cb8ac2838f11d95b0136a919a13b994f920024aba35eee16dc433c65851c\n- maxAmount : 15 million â 50 million USDC\n- slope : 30 million â 50 million USDC per day\nUniswap V3 AUSD/USDC deposits aggregate (Pool) RateLimitID 0xd3384d5424cd179640223010fed859f38b86b26e5e0b9ee88b87321b98882f57\n- maxAmount : 5 million â 25 million\n- slope : 5 million â 25 million per day\nUniswap V3 AUSD/USDC deposits AUSD RateLimitID 0x89c0cb8c17898781d7c1776eafcf73fd0b570659ad5c3791ddcbefe66b001541\n- maxAmount : 5 million â 25 million AUSD\n- slope : 5 million â 25 million AUSD per day\nUniswap V3 AUSD/USDC deposits USDC RateLimitID 0x71efb11b03476e40dcc1ade629d360114fcbf838d70a3211270f69414ba9a187\n- maxAmount : 5 million â 25 million USDC\n- slope : 5 million â 25 million USDC per day\nUniswap V3 AUSD/USDC swaps AUSD RateLimitID 0x7dd93dac252469b97c259284118454a6a09efd0e5f781dec59acc240f8f88402\n- slope : 5 million â 25 million AUSD per day\nUniswap V3 AUSD/USDC swaps USDC RateLimitID 0x6e850dcb18bea10055c82d1e3753f551b1228d04b81350ba117235de19f9a0da\n- slope : 5 million â 25 million USDC per day\nerwe\nSeptember 18, 2026, 6:59am\n15\n-\nExecuted - Txn for Targets #1 & #2\nOperational GovOps Soter Labs, acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction. This is the first transaction under Target #2 (approved earlier the same day); it also continues the remaining Target #1 ramp for the Uniswap V3 deposit limits.\nTransaction: https://etherscan.io/tx/0xad09d73e47a67837eb2072f721cc7fa75072851c4187610a23a4cc4bda3c5170\nTarget #1\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- slope : 2,600,529 per day (previously 2,167,108)\nUniswap V3 AUSD/USDC deposits - AUSD\n- slope : 2,600,528 per day (previously 2,167,107)\nUniswap V3 AUSD/USDC deposits - USDC\n- slope : 2,600,528 per day (previously 2,167,107)\nTarget #2\nTokenized Treasury JTRSY inflow\n- maxAmount : 18,000,000 USDS (previously 15,000,000)\n- slope : 18,000,000 USDS per day (previously 15,000,000)\nUSDS mint\n- maxAmount : 18,000,000 USDS (previously 15,000,000)\n- slope : 36,000,000 USDS per day (previously 30,000,000)\nUSDS-to-USDC swap\n- maxAmount : 18,000,000 USDC (previously 15,000,000)\n- slope : 36,000,000 USDC per day (previously 30,000,000)\nUniswap V3 AUSD/USDC swaps - AUSD\n- slope : 6,000,000 per day (previously 5,000,000)\nUniswap V3 AUSD/USDC swaps - USDC\n- slope : 6,000,000 per day (previously 5,000,000)\n1 Like\npyramid\nSeptember 18, 2026, 5:50pm\n16\nExecuted - Txn for Targets #1 & #2\nOperational GovOps Soter Labs, acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction, continuing the Target #1 ramp for the Uniswap V3 deposit limits and the Target #2 ramp for the remaining limits.\nTransaction: https://etherscan.io/tx/0x39e1603efe1923a7ed5c2ecca5a19535a050e8d3984ace06db868069ef6fed38\nTarget #1\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- slope : 3,120,635 per day (previously 2,600,529)\nUniswap V3 AUSD/USDC deposits - AUSD\n- slope : 3,120,633 per day (previously 2,600,528)\nUniswap V3 AUSD/USDC deposits - USDC\n- slope : 3,120,633 per day (previously 2,600,528)\nTarget #2\nTokenized Treasury JTRSY inflow\n- maxAmount : 21,600,000 USDS (previously 18,000,000)\n- slope : 21,600,000 USDS per day (previously 18,000,000)\nUSDS mint\n- maxAmount : 21,600,000 USDS (previously 18,000,000)\n- slope : 43,200,000 USDS per day (previously 36,000,000)\nUSDS-to-USDC swap\n- maxAmount : 21,600,000 USDC (previously 18,000,000)\n- slope : 43,200,000 USDC per day (previously 36,000,000)\nUniswap V3 AUSD/USDC swaps - AUSD\n- slope : 7,200,000 per day (previously 6,000,000)\nUniswap V3 AUSD/USDC swaps - USDC\n- slope : 7,200,000 per day (previously 6,000,000)\n1 Like\npyramid\nSeptember 21, 2026, 6:57pm\n17\nExecuted - Txn for Targets #1 & #2\nOperational GovOps Soter Labs, acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction, continuing the ramp toward the approved targets. The Uniswap V3 deposit maxAmounts take their first Target #2 step with this transaction, and the USDS mint and USDS-to-USDC slopes reach their approved Target #2 ceiling of 50,000,000 per day.\nTransaction: https://etherscan.io/tx/TX_HASH_HERE\nTarget #1\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- slope : 3,744,762 per day (previously 3,120,635)\nUniswap V3 AUSD/USDC deposits - AUSD\n- slope : 3,744,760 per day (previously 3,120,633)\nUniswap V3 AUSD/USDC deposits - USDC\n- slope : 3,744,760 per day (previously 3,120,633)\nTarget #2\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- maxAmount : 6,000,000 (previously 5,000,000)\nUniswap V3 AUSD/USDC deposits - AUSD\n- maxAmount : 6,000,000 AUSD (previously 5,000,000)\nUniswap V3 AUSD/USDC deposits - USDC\n- maxAmount : 6,000,000 USDC (previously 5,000,000)\nTokenized Treasury JTRSY inflow\n- maxAmount : 25,920,000 USDS (previously 21,600,000)\n- slope : 25,920,000 USDS per day (previously 21,600,000)\nUSDS mint\n- maxAmount : 25,920,000 USDS (previously 21,600,000)\n- slope : 50,000,000 USDS per day (previously 43,200,000)\nUSDS-to-USDC swap\n- maxAmount : 25,920,000 USDC (previously 21,600,000)\n- slope : 50,000,000 USDC per day (previously 43,200,000)\nUniswap V3 AUSD/USDC swaps - AUSD\n- slope : 8,640,000 per day (previously 7,200,000)\nUniswap V3 AUSD/USDC swaps - USDC\n- slope : 8,640,000 per day (previously 7,200,000)\n1 Like\npyramid\nSeptember 22, 2026, 8:08pm\n18\nExecuted - Txn for Targets #1 & #2\nOperational GovOps Soter Labs, acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction, continuing the ramp toward the approved targets. The USDS mint and USDS-to-USDC slopes remain at their approved ceiling of 50,000,000 per day.\nTransaction: https://etherscan.io/tx/0x51ee8fb61e741a1af828ab1c76893308f9e219e8a0728e114fd1d44fec01a7f3\nTarget #1\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- slope : 4,493,715 per day (previously 3,744,762)\nUniswap V3 AUSD/USDC deposits - AUSD\n- slope : 4,493,712 per day (previously 3,744,760)\nUniswap V3 AUSD/USDC deposits - USDC\n- slope : 4,493,712 per day (previously 3,744,760)\nTarget #2\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- maxAmount : 7,200,000 (previously 6,000,000)\nUniswap V3 AUSD/USDC deposits - AUSD\n- maxAmount : 7,200,000 AUSD (previously 6,000,000)\nUniswap V3 AUSD/USDC deposits - USDC\n- maxAmount : 7,200,000 USDC (previously 6,000,000)\nTokenized Treasury JTRSY inflow\n- maxAmount : 31,104,000 USDS (previously 25,920,000)\n- slope : 31,104,000 USDS per day (previously 25,920,000)\nUSDS mint\n- maxAmount : 31,104,000 USDS (previously 25,920,000)\nUSDS-to-USDC swap\n- maxAmount : 31,104,000 USDC (previously 25,920,000)\nUniswap V3 AUSD/USDC swaps - AUSD\n- slope : 10,368,000 per day (previously 8,640,000)\nUniswap V3 AUSD/USDC swaps - USDC\n- slope : 10,368,000 per day (previously 8,640,000)\n1 Like\npyramid\nSeptember 23, 2026, 7:42pm\n19\nExecuted - Txn for Targets #1 & #2\nOperational GovOps Soter Labs, acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction, continuing the ramp toward the approved targets. The USDS mint and USDS-to-USDC slopes remain at their approved ceiling of 50,000,000 per day.\nTransaction: https://etherscan.io/tx/0x755549520c6d985927fcccd33cbcb77961ae4e1e55665392cc8489384db47089\nTarget #1\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- slope : 5,392,458 per day (previously 4,493,715)\nUniswap V3 AUSD/USDC deposits - AUSD\n- slope : 5,392,455 AUSD per day (previously 4,493,712)\nUniswap V3 AUSD/USDC deposits - USDC\n- slope : 5,392,455 USDC per day (previously 4,493,712)\nTarget #2\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- maxAmount : 8,640,000 (previously 7,200,000)\nUniswap V3 AUSD/USDC deposits - AUSD\n- maxAmount : 8,640,000 AUSD (previously 7,200,000)\nUniswap V3 AUSD/USDC deposits - USDC\n- maxAmount : 8,640,000 USDC (previously 7,200,000)\nTokenized Treasury JTRSY inflow\n-\nmaxAmount : 37,324,800 USDS (previously 31,104,000)\n-\nslope : 37,324,800 USDS per day (previously 31,104,000)\nUSDS mint\n- maxAmount : 37,324,800 USDS (previously 31,104,000)\nUSDS-to-USDC swap\n- maxAmount : 37,324,800 USDC (previously 31,104,000)\nUniswap V3 AUSD/USDC swaps - AUSD\n- slope : 12,441,600 AUSD per day (previously 10,368,000)\nUniswap V3 AUSD/USDC swaps - USDC\n- slope : 12,441,600 USDC per day (previously 10,368,000)\n1 Like\npyramid\nSeptember 24, 2026, 6:48pm\n20\nExecuted - Txn for Target #2\nOperational GovOps Soter Labs, acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #2 . The Uniswap V3 AUSD/USDC deposit slopes pass the Target #1 value of 5,000,000 per day with this transaction, so all changes now count toward Target #2 . The USDS mint and USDS-to-USDC slopes remain at their approved ceiling of 50,000,000 per day.\nTransaction: https://etherscan.io/tx/0xcf1d801f3fd11d3b5a65cc6ae399747ab26a3053632357990b53b76a0fed471d\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- maxAmount : 10,368,000 (previously 8,640,000)\n- slope : 6,470,949 per day (previously 5,392,458)\nUniswap V3 AUSD/USDC deposits - AUSD\n- maxAmount : 10,368,000 AUSD (previously 8,640,000)\n- slope : 6,470,945 per day (previously 5,392,455)\nUniswap V3 AUSD/USDC deposits - USDC\n- maxAmount : 10,368,000 USDC (previously 8,640,000)\n- slope : 6,470,945 per day (previously 5,392,455)\nTokenized Treasury JTRSY inflow\n- maxAmount : 44,789,760 USDS (previously 37,324,800)\n- slope : 44,789,760 USDS per day (previously 37,324,800)\nUSDS mint\n- maxAmount : 44,789,760 USDS (previously 37,324,800)\nUSDS-to-USDC swap\n- maxAmount : 44,789,760 USDC (previously 37,324,800)\nUniswap V3 AUSD/USDC swaps - AUSD\n- slope : 14,929,920 per day (previously 12,441,600)\nUniswap V3 AUSD/USDC swaps - USDC\n- slope : 14,929,920 per day (previously 12,441,600)\n1 Like\npyramid\nSeptember 25, 2026, 5:51pm\n21\nExecuted - Txn for Target #2\nOperational GovOps Soter Labs, acting through the Grove Operator Multisig as the registered cBEAM Operator, has completed the next transaction for Target #2 . With this transaction the Tokenized Treasury JTRSY inflow, USDS mint and USDS-to-USDC swap limits reach their approved Target #2 values of 50,000,000 / 50,000,000 per day.\nTransaction: https://etherscan.io/tx/0xef32fabb7edeec1b060e3ed688c4d5e1f9e2e1be9285c8bed772c18f999f9b20\nUniswap V3 AUSD/USDC deposits - aggregate (Pool)\n- maxAmount : 12,441,600 (previously 10,368,000)\n- slope : 7,765,139 per day (previously 6,470,949)\nUniswap V3 AUSD/USDC deposits - AUSD\n- maxAmount : 12,441,600 AUSD (previously 10,368,000)\n- slope : 7,765,134 per day (previously 6,470,945)\nUniswap V3 AUSD/USDC deposits - USDC\n- maxAmount : 12,441,600 USDC (previously 10,368,000)\n- slope : 7,765,134 per day (previously 6,470,945)\nTokenized Treasury JTRSY inflow\n- maxAmount : 50,000,000 USDS (previously 44,789,760)\n- slope : 50,000,000 USDS per day (previously 44,789,760)\nUSDS mint\n- maxAmount : 50,000,000 USDS (previously 44,789,760)\nUSDS-to-USDC swap\n- maxAmount : 50,000,000 USDC (previously 44,789,760)\nUniswap V3 AUSD/USDC swaps - AUSD\n- slope : 17,915,903 per day (previously 14,929,920)\nUniswap V3 AUSD/USDC swaps - USDC\n- slope : 17,915,903 per day (previously 14,929,920)\n1 Like\nnext page â"}
{"url":"https://docs.lightning.engineering/lightning-network-tools/aperture","domain":"docs.lightning.engineering","title":"Aperture | Builder's Guide","hash":"272adcee0af99a51cc491e8458f39edcf398c37772e4a77309bb8e78a8231a45","tokens":270,"chars":1078,"crawler":"crawler-tpoe","verified":"exact","ts":1791112281331,"text":"Builder's Guide\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nAperture\nAperture is an implementation of L402s as a reverse HTTP proxy.\nAperture is a reverse proxy that acts as a payment and authentication gateway for Lightning Network powered APIs. It can handle gRPC requests over HTTP/2 as well as REST over HTTP/1 and 2.\nAperture implements both the L402 as well as the MPP specifications.\nAperture receives incoming connections, verifies the validity of the L402 and either forwards the request to the appropriate end point, or obtains a Macaroon and sends it together with a Lightning invoice and the HTTP status code 402 Payment Required.\nAperture is currently used in production in Lightning Loop and Pool .\nAperture includes a Model Context Protocol (MCP) server that makes it convenient for agents to control Aperture natively.\nGet Aperture Step by Step Admin Services Machine Payments Protocol LNC Backend LNC Mailbox Pricing\nPrevious Unilateral Exit\nNext Get Aperture\nLast updated 9 days ago\nWas this helpful?"}
{"url":"https://docs.velocity.exchange/protocol/market-makers","domain":"docs.velocity.exchange","title":"Market makers | Velocity Protocol","hash":"8d258824f16a4ec8a2c43b5323df349a9cffe4c2499a1a2a381ab2a38254b561","tokens":1406,"chars":5621,"crawler":"hive-genesis","verified":"exact","ts":1791112280653,"text":"Velocity Protocol Developers\nView as Markdown\nMarket makers\nThe two ways to quote on Velocity, what each one costs and earns, and where to go next.\nEvery taker order on Velocity is a Dutch auction whose price starts favorable to the taker and walks toward their limit. With nobody competing for it, the only counterparty is the AMM, whose spread is wide enough to survive being the sole liquidity in the market. A maker willing to price that flow tighter takes the fill earlier and the taker pays less. That is what the rebate is paying for.\nThe mechanics of matching live on How fills work and the fee schedule on Trading fees .\nThis applies to perpetual markets. Spot markets exist on Velocity for collateral and borrow/lend, but spot orderbook trading, and therefore spot maker quoting, is not enabled.\nThe two routes\nJust-in-Time liquidity means reacting to individual taker auctions as they open. A maker watches for new taker orders and, when one is worth filling, submits a single transaction that places a post-only immediate-or-cancel order, fills the taker with it, and cancels the rest. Because the placement and the fill are one transaction, a JIT order never rests on the orderbook. Capital is committed only at the moment of the fill.\nResting post-only orders mean quoting the decentralized orderbook (DLOB) and letting fillers come to the quote. A limit order carrying the post-only flag, priced either as an absolute number or as an offset from the oracle, sits until a taker crosses it. An oracle-offset order can track price for hours without another transaction.\nThe trade between them is latency against attention. JIT sees flow that never reaches the book, but it needs fast infrastructure and a partially filled JIT order cannot be pulled. Resting orders need almost none, but they are visible and can be picked off in a fast move.\nThe JIT window is wall-clock time, not slots\nThe window for responding to a taker's auction is that order's auction duration, which is wall-clock time rather than a slot count. As Solana's slot time falls, what changes is how many slots fit in the window, not how long it is.\nWide auctions come with long windows and narrow ones do not: per 1% of auction price spread, a tier A or B market grants 40 seconds and every tier below grants 24 seconds, with an exchange-wide minimum of 4 seconds. See Auctions .\nWhat each route costs and earns\nBoth routes earn the same thing. The maker rebate is 0.25 bps of the fill's notional, flat at every volume tier , paid out of the taker's fee to whoever was the maker on the fill. Volume tiers move the taker fee and nothing else, so a maker's revenue per unit of notional does not improve with size. The only thing that scales the rebate is the market's own fee adjustment, which scales it in both directions. See Trading fees .\nWhat decides whether the rebate is paid is the post-only flag, not the maker's intent. A resting order without that flag can still be matched as the taker, in which case it pays the taker fee and earns nothing. That is the most common way a quoting strategy loses its rebate. JIT orders cannot make this mistake: the JIT path accepts only post-only orders.\nThe other costs are operational. Both routes pay Solana transaction fees and, in practice, priority fees, which fall entirely on the maker. Resting orders occupy order slots on the subaccount, of which there are 32, so one subaccount can hold at most 32 distinct quotes.\nWhether the AMM competes with JIT makers is governed by the market's just-in-time intensity, an admin-set per-market dial. At zero the match step is the orderbook maker alone; above zero the AMM is added as a second quoter beside that maker. Read the live market parameters for the value.\nA worked example\nA desk that fills $5,000,000 of notional as maker over a day earns $125 in rebates at 0.25 bps, before inventory P&L and transaction costs. The number to model is the spread captured net of the moves the quote is picked off in, with the rebate on top.\nQuoting from the app\nA post-only limit order placed in the Velocity app is a maker order: it sits in the orderbook until a taker at that price arrives, rather than executing against the AMM or going through a JIT auction. The flag is a toggle on the order form.\nThat is the whole of the manual route, and it is enough to earn the rebate.\nWhere the developer material lives\nEverything a maker needs to build against is in the developer market-maker section : the quickstart for two-sided oracle-offset quoting, the DLOB and JIT strategy pages, signed-message order delivery, indicative quotes, and the production concerns of running a bot.\nVelocity also runs reference bots: a floating maker bot that quotes bids and asks around the oracle price and updates them as the oracle moves, and a JIT maker bot that participates in auctions. Velocity runs its own version of the floating maker with additional risk parameters. These bots are not open source today. They live in a monorepo that is not public, and their source will be published alongside the rest of it; the JIT maker bot tutorial describes the strategy in the meantime.\nEdit on GitHub\nInsurance Fund staking\nWhat a stake earns, what it risks, and the rules that decide the payout on unstaking.\nRisks\nEvery mechanism that protects an account has a point past which it stops. This is the list of those points, and every parameter named is admin-settable unless stated otherwise.\nOn this page\nThe two routes\nThe JIT window is wall-clock time, not slots\nWhat each route costs and earns\nA worked example\nQuoting from the app\nWhere the developer material lives"}
{"url":"https://docs.lightning.engineering/lightning-network-tools/taproot-assets","domain":"docs.lightning.engineering","title":"Taproot Assets | Builder's Guide","hash":"442170d8003ef05384065c81f4d304cd5890268c4a17f43fe014f11eb962c055","tokens":209,"chars":836,"crawler":"hive-genesis","verified":"exact","ts":1791112282389,"text":"Builder's Guide\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nTaproot Assets\nLearn how to install Taproot Assets, mint and transfer assets.\nThe Taproot Assets Daemon tapd implements the Taproot Assets protocol (formerly Taro) for issuing assets on the Bitcoin blockchain. Taproot Assets leverages Taproot transactions to commit to newly created assets and their transfers in an efficient and scalable manner. Multiple assets can be created and transferred in a single bitcoin UTXO, while witness data is transacted and kept off-chain.\nGet Started First Steps Taproot Assets Channels Asset Decimal Display RFQ Collectibles Universes Asset Loop Debugging Tapd Lightning Polar Operational Safety Guidelines\nPrevious FAQs\nNext Get Started\nLast updated 6 months ago\nWas this helpful?"}
{"url":"https://wormhole.com/docs/products/token-transfers/wrapped-token-transfers/guides/transfer-wrapped-assets/","domain":"wormhole.com","title":"Transfer Wrapped Assets | Wormhole Docs","hash":"971c2cf68102a8380c4c139513317c38deba9b26c39b02ff278aa45c3528803d","tokens":5441,"chars":21761,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112283195,"text":"Skip to content\nInitializing search\n- Configuration\n- Concepts\n- FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\n- Transfer Assets with Solidity\n- Attest Tokens\n- Fetch a Signed VAA\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Portal Bridge\n- Connect\n- Guides\n- Tutorials\n- Concepts\n- FAQs\n- Reference\n- Settlement\n- FAQs\n- Reference\n- Messaging\n- Interact with Core Contracts\n- Query NTT Data and Transfers\n- Concepts\n- Tutorials\n- Reference\n- Protocol\n- Infrastructure Guides\n- Developer Tools\n- Wormhole CLI\n- Wormholescan Explorer\n- Wormholescan API\n- Reference\n- AI Resources\nPage Actions\nEdit this page\nTransfer Wrapped Assets ïŒ\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nThis guide demonstrates how to implement Wrapped Token Transfers (WTT) protocol via the TypeScript SDK . This example will transfer an arbitrary ERC-20 token from Moonbase Alpha to Solana, but can be adapted for any supported chains .\nCompleting this guide will help you accomplish the following:\n- Verify if a wrapped version of a token exists on a destination chain.\n- Create a token attestation to register a wrapped version of a token on a destination chain.\n- Transfer wrapped assets using WTT's automatic or manual transfers.\n- Fetch a signed Verified Action Approval (VAA) .\n- Manually redeem a signed VAA to claim tokens on a destination chain.\nTerminology\nThe SDK and smart contracts use the name Token Bridge. In documentation, this product is referred to as Wrapped Token Transfers (WTT). Both terms describe the same protocol.\nPrerequisites ïŒ\nBefore you begin, ensure you have the following:\n- Node.js and npm installed on your machine.\n- TypeScript installed globally.\n- The Wormhole TypeScript SDK version 3.0 or above.\n- The contract address for the ERC-20 token you wish to transfer.\n- A wallet setup with the following:\n- Private keys for your source and destination chains.\n- A small amount of gas tokens on your source and destination chains.\n- A balance on your source chain of the ERC-20 token you want to transfer.\nSet Up Your Token Transfer Environment ïŒ\nFollow these steps to initialize your project, install dependencies, and prepare your developer environment for multichain token transfers.\n-\nCreate a new directory and initialize a Node.js project using the following commands:\nmkdir wtt-demo\ncd wtt-demo\nnpm init -y\n-\nInstall dependencies, including the Wormhole TypeScript SDK. This example uses the SDK version 4.14.1 :\nnpm install @wormhole-foundation/sdk@4.14.1 -D tsx typescript\n-\nSet up secure access to your wallets. This guide assumes you are loading your private key values from a secure keystore of your choice, such as a secrets manager or a CLI-based tool like cast wallet .\nWarning\nIf you use a .env file during development, add it to your .gitignore to exclude it from version control. Never commit private keys or mnemonics to your repository.\n-\nCreate a new file named helpers.ts to hold signer and decimal functions:\ntouch helpers.ts\n-\nOpen helpers.ts and add the following code:\nhelpers.ts\nimport {\nChain ,\nChainAddress ,\nChainContext ,\nisTokenId ,\nWormhole ,\nNetwork ,\nSigner ,\nTokenId ,\n} from '@wormhole-foundation/sdk' ;\nimport type { SignAndSendSigner } from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport sui from '@wormhole-foundation/sdk/sui' ;\n/**\n* Returns a signer for the given chain using locally scoped credentials.\n* The required values (EVM_PRIVATE_KEY, SOL_PRIVATE_KEY, SUI_MNEMONIC) must\n* be loaded securely beforehand, for example via a keystore, secrets\n* manager, or environment variables (not recommended).\n*/\nexport async function getSigner < N extends Network , C extends Chain > (\nchain : ChainContext < N , C > ,\ngasLimit? : bigint\n) : Promise < {\nchain : ChainContext < N , C > ;\nsigner : SignAndSendSigner < N , C > ;\naddress : ChainAddress < C > ;\n} > {\nlet signer : Signer < any , any > ;\nconst platform = chain . platform . utils (). _platform ;\n// Customize the signer by adding or removing platforms as needed\n// Be sure to import the necessary packages for the platforms you want to support\nswitch ( platform ) {\ncase 'Evm' :\nconst evmSignerOptions = gasLimit ? { gasLimit } : {};\n( signer = await (\nawait evm ()\n). getSigner ( await chain . getRpc (), EVM_PRIVATE_KEY ! )),\nevmSignerOptions ;\nbreak ;\ncase 'Solana' :\nsigner = await (\nawait solana ()\n). getSigner ( await chain . getRpc (), SOL_PRIVATE_KEY ! );\nbreak ;\ncase 'Sui' :\nsigner = await (\nawait sui ()\n). getSigner ( await chain . getRpc (), SUI_MNEMONIC ! );\nbreak ;\ndefault :\nthrow new Error ( `Unsupported platform: ${ platform } ` );\n}\nconst typedSigner = signer as SignAndSendSigner < N , C > ;\nreturn {\nchain ,\nsigner : typedSigner ,\naddress : Wormhole.chainAddress ( chain . chain , signer . address ()),\n};\n}\n/**\n* Get the number of decimals for the token on the source chain.\n* This helps convert a user-friendly amount (e.g., '1') into raw units.\n*/\nexport async function getTokenDecimals < N extends Network > (\nwh : Wormhole < N > ,\ntoken : TokenId ,\nchain : ChainContext < N , any >\n) : Promise < number > {\nreturn isTokenId ( token )\n? Number ( await wh . getDecimals ( token . chain , token . address ))\n: chain . config . nativeTokenDecimals ;\n}\nYou can view the constants for platform names in the GitHub repo for a list of supported platforms\nVerify Token Registration (Attestation) ïŒ\nTokens must be registered on the destination chain before they can be bridged. This process involves submitting an attestation with the native token metadata to the destination chain, which enables the destination chain's WTT contract to create a corresponding wrapped version with the same attributes as the native token.\nRegistration via attestation is only required the first time a given token is sent to that specific destination chain. Follow these steps to check the registration status of a token:\n-\nCreate a new file named transfer.ts :\ntouch transfer.ts\n-\nOpen your transfer.ts file and add the following code:\ntransfer.ts\nimport { wormhole , Wormhole , TokenId } from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport { getSigner , getTokenDecimals } from './helpers' ;\nasync function transferTokens () {\n// Initialize wh instance\nconst wh = await wormhole ( 'Testnet' , [ evm , solana ]);\n// Define sourceChain and destinationChain, get chain contexts\nconst sourceChain = wh . getChain ( 'Moonbeam' );\nconst destinationChain = wh . getChain ( 'Solana' );\n// Load signers for both chains\nconst sourceSigner = await getSigner ( sourceChain );\nconst destinationSigner = await getSigner ( destinationChain );\n// Define token and amount to transfer\nconst tokenId : TokenId = Wormhole . tokenId (\nsourceChain . chain ,\n'INSERT_TOKEN_CONTRACT_ADDRESS'\n);\n// Replace with amount you want to transfer\n// This is a human-readable number, e.g., 0.2 for 0.2 tokens\nconst amount = INSERT_AMOUNT ;\n// Convert to raw units based on token decimals\nconst decimals = await getTokenDecimals ( wh , tokenId , sourceChain );\nconst transferAmount = BigInt ( Math . floor ( amount * 10 ** decimals ));\n// Check if the token is registered with destinationChain WTT (Token Bridge) contract\n// Registered = returns the wrapped token ID, continues with transfer\n// Not registered = runs the attestation flow to register the token\nlet wrappedToken : TokenId ;\ntry {\nwrappedToken = await wh . getWrappedAsset ( destinationChain . chain , tokenId );\nconsole . log (\n'â
Token already registered on destination:' ,\nwrappedToken . address\n);\n} catch ( e ) {\nconsole . log (\n'â ïž Token is NOT registered on destination. Attestation required before transfer can proceed...'\n);\n}\n// Insert Initiate Transfer on Source Chain code\n}\ntransferTokens (). catch (( e ) => {\nconsole . error ( 'â Error in transferTokens' , e );\nprocess . exit ( 1 );\n});\nThis code does the following:\n- Initializes a wormhole instance and defines the source and destination chains.\n- Imports the signer and decimal functions from helpers.ts .\n- Identifies the token and amount to transfer.\n- Checks to see if a wrapped version of the ERC-20 token to transfer exists on the destination chain.\n-\nRun the script using the following command:\nnpx tsx transfer.ts\nIf the token is registered on the destination chain, the address of the existing wrapped asset is returned, and you can continue to initiate the transfer on the source chain. If the token is not registered, you will see a message similar to the following advising the attestation flow will run:\nnpx tsx transfer.ts â ïž Token is NOT registered on destination. Running attestation flow...\nIf you see this message, follow the steps under \"Need to register a token?\" before continuing with the rest of the transfer flow code.\nNeed to register a token?\nToken attestation is a one-time process to register a token on a destination chain. You should only follow these steps if your token registration check indicates a wrapped version does not exist on the destination chain.\n-\nCreate a new file called attestToken.ts :\ntouch attestToken.ts\n-\nOpen attestToken.ts and add the following code to create the attestation for token registration:\nattestToken.ts\nimport {\nwormhole ,\nWormhole ,\nTokenId ,\nTokenAddress ,\n} from '@wormhole-foundation/sdk' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport { signSendWait , toNative } from '@wormhole-foundation/sdk-connect' ;\nimport { getSigner } from './helpers' ;\nasync function attestToken () {\n// Initialize wh instance\nconst wh = await wormhole ( 'Testnet' , [ evm , solana ]);\n// Define sourceChain and destinationChain, get chain contexts\nconst sourceChain = wh . getChain ( 'Moonbeam' );\nconst destinationChain = wh . getChain ( 'Solana' );\n// Define gas limit for EVM chains (optional)\nconst gasLimit = BigInt ( 2 _500_000 );\n// Load signers for both chains\nconst sourceSigner = await getSigner ( sourceChain );\nconst destinationSigner = await getSigner ( destinationChain , gasLimit );\n// Retrieve the WTT (Token Bridge) context for the source chain\n// This is where you will send the transaction to attest the token\nconst tb = await sourceChain . getTokenBridge ();\n// Define the token to attest\nconst tokenId : TokenId = Wormhole . tokenId (\nsourceChain . chain ,\n'INSERT_TOKEN_CONTRACT_ADDRESS'\n);\n// Define the token to attest and a payer address\nconst token : TokenAddress < typeof sourceChain . chain > = toNative (\nsourceChain . chain ,\ntokenId . address . toString ()\n);\nconst payer = toNative ( sourceChain . chain , sourceSigner . signer . address ());\n// Call the `createAttestation` method to create a new attestation\n// and sign and send the transaction\nfor await ( const tx of tb . createAttestation ( token , payer )) {\nconst txids = await signSendWait (\nsourceChain ,\ntb . createAttestation ( token ),\nsourceSigner . signer\n);\nconsole . log ( 'â
Attestation transaction sent:' , txids );\n// Parse the transaction to get Wormhole message ID\nconst messages = await sourceChain . parseTransaction ( txids [ 0 ]. txid );\nconsole . log ( 'â
Attestation messages:' , messages );\n// Set a timeout for fetching the VAA, this can take several minutes\n// depending on the source chain network and finality\nconst timeout = 25 * 60 * 1000 ;\n// Fetch the VAA for the attestation message\nconst vaa = await wh . getVaa (\nmessages [ 0 ] ! ,\n'TokenBridge:AttestMeta' ,\ntimeout\n);\nif ( ! vaa ) throw new Error ( 'â VAA not found before timeout.' );\n// Get the WTT (Token Bridge) context for the source chaindestination chain\n// and submit the attestation VAA\nconst destTb = await destinationChain . getTokenBridge ();\nconst payer = toNative (\ndestinationChain . chain ,\ndestinationSigner . signer . address ()\n);\nconst destTxids = await signSendWait (\ndestinationChain ,\ndestTb . submitAttestation ( vaa , payer ),\ndestinationSigner . signer\n);\nconsole . log ( 'â
Attestation submitted on destination:' , destTxids );\n}\n// Poll for the wrapped token to appear on the destination chain\n// before proceeding with the transfer\nconst maxAttempts = 50 ; // ~5 minutes with 6s interval\nconst interval = 6000 ;\nlet attempt = 0 ;\nlet registered = false ;\nwhile ( attempt < maxAttempts && ! registered ) {\nattempt ++ ;\ntry {\nconst wrapped = await wh . getWrappedAsset ( destinationChain . chain , tokenId );\nconsole . log (\n`â
Wrapped token is now available on ${ destinationChain . chain } :` ,\nwrapped . address\n);\nregistered = true ;\n} catch {\nconsole . log (\n`âł Waiting for wrapped token to register on ${ destinationChain . chain } ...`\n);\nawait new Promise (( res ) => setTimeout ( res , interval ));\n}\nif ( ! registered ) {\nthrow new Error (\n`â Token attestation did not complete in time on ${ destinationChain . chain } `\n);\n}\nconsole . log ( 'đ Token attestation complete! Proceed with transfer...' );\n}\nThis code does the following:\n- Gets the WTT protocol for the source chain.\n- Defines the token to attest for registration on the destination chain and the payer to sign for the transaction.\n- Calls createAttestation , signs, and then sends the transaction.\n- Waits for the signed VAA confirming the attestation creation.\n- Sends the VAA to the destination chain to complete registration.\n- Polls for the wrapped token to be available on the destination chain before continuing the transfer process.\n-\nRun the script with the following command:\nnpx tsx attestToken.ts\nWhen the attestation and registration are complete, you will see terminal output similar to the following:\nnpx tsx transfer.ts â ïž Token is NOT registered on destination. Running attestation flow... â
Attestation transaction sent: [ { chain: 'Moonbeam', txid: '0x2b9878e6d8e92d8ecc96d663904312c18a827ccf0b02380074fdbc0fba7e6b68' } ] â
Attestation messages: [ { chain: 'Moonbeam', emitter: UniversalAddress { address: [Uint8Array] }, sequence: 1505n } ] Retrying Wormholescan:GetVaaBytes, attempt 0/750 Retrying Wormholescan:GetVaaBytes, attempt 1/750 .... Retrying Wormholescan:GetVaaBytes, attempt 10/750 â
Attestation submitted on destination: [ { chain: 'Solana', txid: '3R4oF5P85jK3wKgkRs5jmE8BBLoM4wo2hWSgXXL6kA8efbj2Vj9vfuFSb53xALqYZuv3FnXDwJNuJfiKKDwpDH1r' } ] â
Wrapped token is now available on Solana: SolanaAddress { type: 'Native', address: PublicKey [PublicKey(2qjSAGrpT2eTb673KuGAR5s6AJfQ1X5Sg177Qzuqt7yB)] { _bn: } } đ Token attestation complete! Proceeding with transfer...\nYou can now go on to initiate the transfer on the source chain.\nInitiate Transfer on Source Chain ïŒ\nBefore initializing the token transfer, decide whether to use an automatic or manual transaction. Refer to the Automatic vs. Manual Transfers section for a comparison of both options.\nFollow these steps to add the remaining logic to initiate the token transfer on the source chain. Add the below code where the comment says // Insert Initiate Transfer on Source Chain code in your transfer.ts file:\n-\nOpen your transfer.ts file and add the following code:\nManual Transfer Automatic Transfer\ntransfer.ts\n// Build the token transfer object\nconst xfer = await wh . tokenTransfer (\ntokenId ,\ntransferAmount ,\nsourceSigner . address ,\ndestinationSigner . address ,\n'TokenBridge' ,\nundefined // no payload\n);\nconsole . log ( 'đ Built transfer object:' , xfer . transfer );\n// Initiate, sign, and send the token transfer\nconst srcTxs = await xfer . initiateTransfer ( sourceSigner . signer );\nconsole . log ( 'đ Source chain tx sent:' , srcTxs );\n// For manual transfers, wait for VAA\nconsole . log ( 'âł Waiting for attestation (VAA) for manual transfer...' );\nconst timeout = 10 * 60 * 1000 ; // 10 minutes timeout\nconst attIds = await xfer . fetchAttestation ( timeout );\nconsole . log ( 'â
Got attestation ID(s):' , attIds );\n// Complete the manual transfer on the destination chain\nconsole . log ( 'âȘïž Redeeming transfer on destination...' );\nconst destTxs = await xfer . completeTransfer ( destinationSigner . signer );\nconsole . log ( 'đ Destination tx(s) submitted:' , destTxs );\ntransfer.ts\n// Optional native gas amount for automatic transfers only\nconst nativeGasAmount = '0.001' ; // 0.001 of native gas in human-readable format\n// Get the decimals for the source chain\nconst nativeGasDecimals = destinationChain . config . nativeTokenDecimals ;\n// Convert to raw units, otherwise set to 0n\nconst nativeGas = BigInt ( Number ( nativeGasAmount ) * 10 ** nativeGasDecimals );\n// Build the token transfer object\nconst xfer = await wh . tokenTransfer (\ntokenId ,\ntransferAmount ,\nsourceSigner . address ,\ndestinationSigner . address ,\n'AutomaticTokenBridge' ,\nnativeGas\n);\nconsole . log ( 'đ Built transfer object:' , xfer . transfer );\n// Initiate, sign, and send the token transfer\nconst srcTxs = await xfer . initiateTransfer ( sourceSigner . signer );\nconsole . log ( 'đ Source chain tx sent:' , srcTxs );\n// If automatic, no further action is required. The relayer completes the transfer.\nconsole . log ( 'â
Automatic transfer: relayer is handling redemption.' );\nprocess . exit ( 0 );\nThis code does the following:\n- Defines the transfer as automatic or manual. For automatic transfers, both the source and destination chain must have an existing TokenBridgeRelayer contract, which listens for and completes transfers on your behalf. You can check the list of deployed TokenBridgeRelayer contracts in the Wormhole SDK repo to see if your desired chains are supported.\n- Sets an optional amount for native gas drop-off . This option allows you to send a small amount of the destination chain's native token to cover gas fees. Native gas drop-off is currently only supported for automatic transfers.\n- Builds the transfer object, initiates the transfer, signs the transaction, and sends it.\n- If the transfer is automatic, the flow ends. Otherwise, the script waits for the signed VAA confirming the transaction on the source chain. The signed VAA is then submitted to the destination chain to claim the tokens and complete the manual transfer.\n-\nRun the script with the following command:\nnpx tsx transfer.ts\n-\nYou will see terminal output similar to the following:\nManual Transfer Automatic Transfer\nnpx tsx transfer.ts â
Token already registered on destination: SolanaAddress { type: 'Native', address: PublicKey [PublicKey(2qjSAGrpT2eTb673KuGAR5s6AJfQ1X5Sg177Qzuqt7yB)] { _bn: } } đ Built transfer object: { token: { chain: 'Moonbeam', address: EvmAddress { type: 'Native', address: '0x39F2f26f247CcC223393396755bfde5ecaeb0648' } }, amount: 200000000000000000n, from: { chain: 'Moonbeam', address: EvmAddress { type: 'Native', address: '0xCD8Bcd9A793a7381b3C66C763c3f463f70De4e12' } }, to: { chain: 'Solana', address: SolanaAddress { type: 'Native', address: [PublicKey [PublicKey(21dmEFTFGBEVoUNjmrxumN6A2xFxNBQXTkK7AmMqNmqD)]] } }, protocol: 'TokenBridge', payload: undefined } đ Source chain tx sent: [ '0xf318a1098a81063ac8acc9ca117eeb41ae9abfd9cb550a976721d2fa978f313a' ] âł Waiting for attestation (VAA) for manual transfer... Retrying Wormholescan:GetVaaBytes, attempt 0/30 Retrying Wormholescan:GetVaaBytes, attempt 1/30 ..... Retrying Wormholescan:GetVaaBytes, attempt 15/30 â
Got attestation ID(s): [ { chain: 'Moonbeam', emitter: UniversalAddress { address: [Uint8Array] }, sequence: 1506n } ] âȘïž Redeeming transfer on destination... đ Destination tx(s) submitted: [ '23NRfFZyKJTDLppJF4GovdegxYAuW2HeXTEFSKKNeA7V82aqTVYTkKeM8sCHCDWe7gWooLAPHARjbAheXoxbbwPk' ]\nnpx tsx transfer.ts â
Token already registered on destination: SolanaAddress { type: 'Native', address: PublicKey [PublicKey(2qjSAGrpT2eTb673KuGAR5s6AJfQ1X5Sg177Qzuqt7yB)] { _bn: } } đ Built transfer object: { token: { chain: 'Moonbeam', address: EvmAddress { type: 'Native', address: '0x39F2f26f247CcC223393396755bfde5ecaeb0648' } }, amount: 200000000000000000n, from: { chain: 'Moonbeam', address: EvmAddress { type: 'Native', address: '0xCD8Bcd9A793a7381b3C66C763c3f463f70De4e12' } }, to: { chain: 'Solana', address: SolanaAddress { type: 'Native', address: [PublicKey [PublicKey(21dmEFTFGBEVoUNjmrxumN6A2xFxNBQXTkK7AmMqNmqD)]] } }, protocol: 'AutomaticTokenBridge', nativeGas: 10000000000000000n } đ Source chain tx sent: [ '0xf318a1098a81063ac8acc9ca117eeb41ae9abfd9cb550a976721d2fa978f313a' ] â
Automatic transfer: relayer is handling redemption.\nCongratulations! You've now used WTT to transfer wrapped assets using the Wormhole TypeScript SDK. Consider the following options to build upon what you've achieved.\nNext Steps ïŒ\n-\nPortal Bridge\nVisit this site to interact with Wormhole's Portal Bridge, featuring a working WTT integration.\nCheck out the Portal Bridge\n-\nInteract with WTT Contracts\nThis guide explores the Solidity functions used in WTT contracts.\nGet Started\n-\nReference Interfaces\nView the source code defining the TokenBridge and AutomaticTokenBridge interfaces and their associated namespaces.\nSee Interfaces\nRecovering Stuck Transfers ïŒ\nIf your transfer appears stuck or failed to complete automatically, you can recover it manually using the transaction hash from the source chain.\nUsing the Recovery Script ïŒ\n-\nGet your source transaction hash : This is the transaction ID from when you initiated the transfer\n-\nClone the recovery script :\ngit clone https://github.com/wormhole-foundation/demo-basic-ts-sdk\ncd demo-basic-ts-sdk\n-\nRun the recovery :\n# Edit src/tx-recover.ts and set recoverTxid to your transaction hash\nnpm run transfer:recover\nWhen Recovery Might Not Work ïŒ\n- Wrong destination address : If tokens were sent to a contract that can't release them\n- Finality not reached : Wait up to 20 minutes for Ethereum finality before attempting recovery\nLast update: September 28, 2026\n| Created: September 28, 2026"}
{"url":"https://www.anchor-lang.com/docs/updates/changelog","domain":"www.anchor-lang.com","title":"Changelog","hash":"8828ab224dd8d90063e8203cf29dc2dfbb1fa0249e92aca20c4f9a79779103b6","tokens":9998,"chars":39992,"crawler":"hive-genesis","verified":"unchecked","ts":1791112284265,"text":"Anchor Docs\nGithub Discord Stack Exchange\nAnchor Project Updates\nChangelog\nAnchor Changelog\nVersion 0 of Semantic Versioning is handled differently from version 1 and\nabove. The minor version will be incremented upon a breaking change and the\npatch version will be incremented for features.\n[1.2.0]\nFeatures\n- avm: Allow resolving Solana/platform-tools versions from an explicit Anchor\nversion\n( #4799 ).\n- cli: Add --arch and --tools-version flags to select the SBPF\narchitecture and platform-tools version used by anchor build\n( #4684 ).\n- cli: Generate a TypeScript error constants file from the IDL during\nanchor build\n( #3827 ).\n- lang: Always derive Clone and Debug for generated types in\ndeclare_program!\n( #4723 ).\n- spl: Add pausable mint extension support\n( #4092 ).\n- spl: Add create_native_mint and initialize_non_transferable_mint helpers\n( #3512 ).\n- spl: Add reallocate and withdraw_excess_lamports helpers\n( #3516 ).\n- spl: Added token_metadata_remove_key to support removing keys from token\nmetadata extension\n( #3717 ).\n- lang: Add AccountLoader::new_unchecked for constructing an AccountLoader\nwithout performing owner or discriminator checks\n( #4162 ).\n- lang: Provide better error messages for token constraints\n( #4698 ).\n- ts: Improve account resolution error of self-referencing PDAs\n( #4711 ).\n- cli: Warn unused Anchor.toml fields\n( #4749 ).\nFixes\n- spl: Fix anchor-spl failing to build with only the metadata feature\n( #4742 ).\n- lang: Honor is_signer in generated client and CPI account metas, enabling\nPDA signer usage\n( #3322 ).\n- lang: Report invalid instruction arguments instead of silently omitting\ntheir instructions during parsing\n( #4008 ).\n- syn: Correct bytemuck serialization detection to avoid false positives\nfrom unrelated derives\n( #4215 ).\n- lang: Return an error instead of panicking when zero-copy account data is\nundersized\n( #4555 ).\n- lang: Handle numeric instruction suffixes in declare_program! generated\naccount-module re-exports\n( #4568 ).\n- lang: Reject all-zero account discriminators\n( #4645 ).\n- lang: Preserve IDL namespace boundaries in declare_program! to prevent\nforeign-IDL name collisions with Anchor prelude items\n( #4776 ).\n- lang: Re-run ownership and discriminator checks when unloading LazyAccount\nafter a CPI\n( #4784 ).\n- client: Fix ignored commitment level\n( #4666 ).\n- lang: Remove cloning AccountInfo to read lamports in init_if_needed\ncodegen\n( #4675 ).\n- lang: Guard AccountLoader::exit against zero-copy buffer truncation and\nbail with AccountDidNotDeserialize instead of rewriting the discriminator\nover an undersized buffer\n( #4633 ).\n- lang: Shorten invariant lifetimes during Context creation\n( #4363 ).\n- lang: Qualify bare error! calls in require macros so they don't depend on\nglobal prelude imports\n( #4639 ).\n- ts: Guard recursive IDL layouts against stack overflows while preserving\nsupported recursive types\n( #4604 ).\n- lang: Fix missing error messages of the generated errors in\ndeclare_program!\n( #4652 ).\n- spl: Fix wrong owner pubkey in CPI Guard enable/disable\n( #4322 ).\n- spl: Add missing auth account to group_pointer_update\n( #4324 ).\n- spl: Deprecate broken cpi_guard_enable/disable functions\n( #4465 ).\n- lang: Reduce cloning in realloc constraint when shrinking\n( #4642 ).\n- syn: Remove anyhow\n( #4640 ).\n- lang: Sync type derives and simplify internal args creation in\ndeclare_program!\n( #4667 ).\n- lang: Improve std hygiene inside macros\n( #4700 ).\n- cli: Honor the SIMD-0431 minimum extend program size when extending program\ndata\n( #4785 ).\n- client: Do not panic in parse_logs_response when logs continue after a\ntop-level instruction returns, e.g. the runtime's trailing \"Log truncated\"\nmarker\n( #4967 ).\n[1.1.2]\nFixes\n- deps: Tighten dependencies between anchor-* crates to reduce breakage\n( #4726 ).\n[1.1.1]\nFeatures\n- ts: Re-implement verifiedBuild using the OtterSec registry\n( verify.osec.io ), replacing the defunct apr.dev API\n( #4522 ).\n- ts: Add decodeIdlAccountRaw\n( #4375 ).\n- cli: Add --stdout flag to the expand command\n( #4400 ).\n- client: Add versioned tx support\n( #4207 ).\n- cli: Add edition and rust-version to template\n( #4048 ).\n- lang: Add program_id verification to CPI return values\n( #4411 ).\n- cli: Resolve the target directory via cargo metadata so custom target\nlocations (e.g. CARGO_TARGET_DIR , workspace-level overrides) work across\nbuild, test, deploy and IDL paths\n( #3817 ).\n- cli: Allow configuring IDL JSON location in workspace config\n( #4483 ).\n- lang: Derive Clone , Debug , Copy , and Default on generated client /\nCPI account structs and instruction args where the field types allow it\n( #4085 ).\n- cli: Support multiple named scripts in Anchor.toml and run them via\nanchor test --script / anchor run \n( #3999 ).\n- cli/idl: Add fetch-historical support to recover historical IDLs with the\nAnchor CLI\n( #3992 ).\n- cli: anchor init refuses to create a new Anchor workspace inside an\nexisting Cargo workspace to avoid broken nested layouts\n( #4576 ).\n- cli: Add r as an alias to the run command\n( #4643 ).\nFixes\n- cli: Warn instead of aborting anchor build when a program keypair and\ndeclare_id! do not match\n( #4705 ).\n- lang: Snapshot CPI return data before Return::get() validates the source\nprogram\n( #4624 ).\n- lang/syn: Remove remaining fallible IDL generation paths from clippy-denied\ncode\n( #4631 ).\n- lang: Validate max_len arguments more strictly during space derivation\n( #4707 ).\n- ts: Remove cross-fetch dependency\n( #4671 ).\n- lang: Set anchor-lang Minimum Supported Rust Version to 1.89\n( #4638 ).\n- lang: Migrate anchor-syn from syn 1.x to syn 2.0, allowing use of modern\nRust syntax\n( #4523 ).\n- idl: Bump version to 0.1.3\n( #4453 ).\n- lang: Avoid fatal errors in IDL building when modern Rust syntax is in use\n( #4520 ).\n- lang: Return InvalidProgramId when Migration::exit cannot persist\nmigrated state because To::owner() does not match program_id\n( #4706 ).\n- client: Avoid panic in parse_logs_response when a program-emitted log line\nends with invoke [1]\n( #4461 ).\n- cli: Correctly honor --skip-seed-phrase-validation in keygen recover\n( #4417 ).\n- ts: Fix sha256.hash() returning corrupted output by using hex encoding\n( #4404 ).\n- lang: Support module constants in max_len attribute\n( #3879 ).\n- cli: Bump cargo_toml to allow parsing resolver = \"3\"\n( #4515 ).\n- ts: Validate instruction args in BorshInstructionCoder.encode to reject\ntypo'd or missing fields instead of silently ignoring them\n( #4560 ).\n- ts: Align TS camelCase conversion with Rust heck for digit-letter\nidentifiers so generated client names match Rust identifiers\n( #4571 ).\n- cli: Warn if event-cpi instruction is unreachable with custom\ndiscriminators\n( #4614 ).\n- ts: Update engines.node to >= 20.18\n( #4647 ).\n[1.0.3]\nFixes\n- deps: Tighten dependencies between anchor-* crates to reduce breakage\n( #4726 ).\n[1.0.2]\nFixes\n- client: Replace solana-program with solana-hash\n( #4468 ).\n- lang: Make idl build time way faster by caching CrateContext\n( #4325 ).\n- cli: Bind localnet to 127.0.0.1 by default to fix a panic in\nsolana-test-validator version 3.1.10\n( #4397 ).\n- cli: Fallback to a priority fee of 0 on localnet\n( #4259 ).\n- lang/syn: Fix compile error with init and a runtime seeds expression\n( #4495 ).\n[1.0.1]\nFixes\n- lang: Handle user-provided borsh attributes in derives\n( #4380 ).\n[1.0.0]\nFeatures\n- lang: Add Migration<'info, From, To> account type for schema migrations\nbetween account types\n( #4060 ).\n- cli: Added a check_program_id_mismatch in build time to check if the\nprogram ID in the source code matches the program ID in the keypair file.\nThis check will be skipped during anchor test\n( #4018 ).\n- lang: Add instruction parser to declare_program!\n( #4118 ).\n- ts: Export all IDL types from the root. Users can now update dist/cjs/idl\nimports to import directly from @anchor-lang/core\n( #3948 ).\n- lang: Add declare_program! support with just anchor_client and not\nanchor_lang\n( #4157 ).\n- lang: Export Owners from prelude\n( #4189 ).\n- cli: Use surfpool by default for anchor test and anchor localnet commands\n( #4106 ).\n- lang: Optimize enums with all unit variants and empty arrays with Lazy\n( #4237 ).\n- lang: Include init_if_needed accounts in duplicate mutable account checks\n( #4239 ).\n- client: Accept FnMut for events closure\n( #4024 ).\n- client: Export all types used by the public API\n( #4211 ).\n- lang: Make common::close accept references\n( #4178 ).\n- cli/idl: Add --allow-localnet option for IDL commands; fix panic when run\noutside a workspace\n( #4252 ).\n- lang: Check owner on account reload\n( #3837 ).\n- lang/ts: Upgrade borsh to 1.5.7\n( #4012 ).\n- syn: Relax seeds syntax to allow more flexible PDA seed expressions\n( #3813 ).\n- lang: Deprecate AccountInfo usage in Accounts macro with a compile-time\nwarning\n( #3854 ).\n- cli: Update anchor init to use the multiple program template by default\n( #3958 ).\n- cli: Add hooks section to Anchor.toml for\n{pre,post}-{build,test,deploy} lifecycle hooks\n( #3862 ).\n- lang: Add generic program validation support to Program type allowing\nProgram<'info> for executable-only validation\n( #3878 ).\n- cli: Added litesvm test template and made it the default option on\nanchor init\n( #4316 )\n- cli: Added --install-agent-skills to automatically install Solana agent\nskills during anchor init\n( #4307 )\n- avm: Added flags and version labels to explicitly handle pre-releases\n( avm list --pre-release , avm update --pre-release and\navm install latest-pre-release )\n( #4335 )\n- avm: Added avm self-update command and passive version check warning for\nout of date avm\n( #4338 )\n- lang, cli, client: Updated solana dependencies to the latest compatible\nversions. Bumping CI and docker builds to use Solana CLI version 3.1.10\n( #4317 )\nFixes\n- lang: Add missing Lazy bound on generics\n( #4240 ).\n- lang: Fix wrong generated error code in declare_program!\n( #4129 ).\n- idl: Fix defined types with unsupported fields not producing an error\n( #4088 ).\n- lang: Fix using non-instruction composite accounts multiple times with\ndeclare_program!\n( #4113 ).\n- lang: Fix declare_program! messing up IDL errors generation\n( #4126 ).\n- idl: Fix address constraint not resolving constants that have numbers in\ntheir identifiers\n( #4144 ).\n- lang: Fix constant nested string generation in declare_program!\n( #4158 ).\n- idl: Fix local_file method not found for proc_macro2::Span error\n( #4187 ).\n- lang: Relax duplicate mutable account constraint to only check types that\nserialize on exit ( Account , LazyAccount , InterfaceAccount , Migration )\n( #4202 ).\n- idl: Make serde_json optional\n( #4296 ).\n- lang: Fix declare_program! instruction parser with optional accounts\n( #4180 ).\n- lang: Use original borsh derives\n( #4205 ).\n- lang: Fix unexpected account substitution in InterfaceAccount\n( #4139 ).\n- idl: Respect offset = ... in IDL generation for custom errors\n( #4040 ).\n- cli: Relax separate dependency check for solana-program\n( #4166 ).\n- lang: Enforce type and count matching between instruction handler and\n#[instruction(..)] args\n( #4000 ).\n- lang: Handle invalid camelCase identifiers more gracefully\n( #4021 ).\n- cli: Fix i128 / u128 deserialization\n( #3938 ).\n- ts: Fix incorrect Anchor dependency version requirements\n( #4138 ).\n- lang: Omit parsers module of declare_program! during on-chain (Solana)\nbuilds\n( #4109 ).\n- docs: Fixed broken links and replaced coral-xyz github references to\nsolana-foundation\n( #4320 )\n- avm: Fixed handling of new Cargo.toml version location. Fixed handling of\npre-release version parsing\n( #4335 )\n- client: Fix deadlock when having multiple websocket listeners\n( #4250 ).\n- lang: Fix incorrect deserialization for dynamically sized types when using\nlazy-account\n( #4319 )\n- avm: Using a temporary installation dir on cargo install calls to prevent\ncargo erroring out due to existing anchor symlink in .avm/bin\n( #4343 )\nBreaking\n- cli: Remove program arch options\n( #4295 ).\n- lang: Disallow duplicate mutable accounts by default. But allows duplicate\nmutable accounts in instruction contexts using dup constraint\n( #3946 ).\n- cli: Remove program id arguments of idl init and idl upgrade commands\n( #4130 ).\n- lang: Rename utils module of declare_program! to parsers\n( #4151 ).\n- lang: Remove the interface-instructions feature and the #[interface]\nattribute\n( #4156 ).\n- cli: Remove the login command\n( #4182 ).\n- idl: Exclude external accounts\n( #4197 ).\n- idl: Remove the conflicting account names check\n( #4294 ).\n- deps: Update to Solana 3.0\n( #4031 ).\n- idl: Remove legacy IDL instructions and integrate Program Metadata for IDL\nmanagement\n( #3798 ).\n- ts: Rename TypeScript packages from @coral-xyz/anchor to\n@anchor-lang/core\n( #4141 ).\n- lang: Remove program account info from CPI context\n( #2762 ).\n- cli: Remove dependency on the external solana CLI; native implementations\nprovided for balance, airdrop, address, deploy, and other commands\n( #4099 ).\n- idl: Disallow multiple #[error_code] definitions in a single program\n( #4300 ).\n- cli: Remove the [registry] section from Anchor.toml\n( #4299 ).\n- client: Make sending a tx not panic and instead return an Error when signing\nfails\n( #3865 ).\n- lang: Rename errors and ProgramError of declare_program!\n( #4347 ).\n- client: Remove the solana-account-decoder crate export\n( #4373 ).\n[0.32.1] - 2025-10-09\nFixes\n- lang: Fix deprecation warnings on alloc and add solana-program to prelude\n( #3975 ).\n- cli: Fix race condition that could happen when deploying a program\n( #3976 ).\n[0.32.0] - 2025-10-08\nFeatures\n- lang: Add #[error] attribute to declare_program!\n( #3757 ).\n- cli: Replace anchor verify to use solana-verify under the hood, adding\nautomatic installation via AVM, local path support, and future-proof argument\npassing ( #3768 ).\n- lang: Replace solana-program crate with smaller crates\n( #3819 ).\n- cli: Make anchor deploy to upload the IDL to the cluster by default unless\n--no-idl is passed\n( #3863 ).\n- lang: Use solana-invoke instead of solana_cpi::invoke\n( #3900 ).\n- client: remove solana-client from anchor-client and cli\n( #3877 ).\n- idl: Build IDL on stable Rustc\n( #3842 ).\n- lang: Add custom error when using init on SystemAccount\n( #3828 ).\n- lang: Add errors to declare_program\n( #3757 ).\n- ts: Add support for Bun as a package manager\n( #3586 ).\n- lang: Add support for tuple types in space calculation\n( #3744 ).\n- lang: Add missing pubkey const generation\n( #3677 ).\n- cli: Add the Minimum Supported Rust Version (MSRV) to the Rust template,\nsince an arbitrary compiler version isn't supported\n( #3873 ).\nFixes\n- docker: Upgrade node to 20.18.0 LTS\n( #3687 ).\n- cli: Fix using deprecated commitment recent in migration scripts\n( #3725 ).\n- cli: Fix not respecting provider.cluster in keys sync command\n( #3761 ).\n- lang: Fix deprecated realloc , store_current_index and clippy warnings\n( #3819 ).\n- avm: fix AVM instability with solana-verify\n( #3867 ).\n- avm: update AVM to only use non-draft\nreleases( #3931 ).\n- lang: update bytemuck\n( #3858 ).\n- idl: disable Locale in camelCase\n( #3845 ).\n- ts: Remove event parsing panic\n( #3657 ).\nBreaking\n- spl: Update SPL dependencies to latest compatible versions\n( #3860 ).\n- cli: Replace anchor verify to use solana-verify under the hood, adding\nautomatic installation via AVM, local path support, and future-proof argument\npassing ( #3768 ).\n- cli: Upload IDL by default with an option to skip\n((#3863)[ https://github.com/solana-foundation/anchor/pull/3863 ]).\n- lang: remove Solang\n( #3824 ).\n- cli: remove anchor publish command\n( #3795 ).\n[0.31.1] - 2025-04-19\nFeatures\n- cli, docker: Replace backpackapp/build Docker image with\nsolanafoundation/anchor\n( #3619 ).\n- ts: Make Provider require publicKey instead of wallet in accounts resolver\n( #3613 )\nFixes\n- idl: Update proc-macro2 usage for latest nightly\n( #3663 )\n- ts: Fix parsing IDL with multiple const generics\n( #3665 )\nBreaking\n[0.31.0] - 2025-03-08\nFeatures\n- client: Make solana_account_decoder dep public in anchor client\n( #3455 ).\n- ts: Add optional options.blockhash to Provider.sendAndConfirm\n( #3070 ).\n- ts: Add optional commitment parameter to Program.addEventListener\n( #3052 ).\n- cli, idl: Pass cargo args to IDL generation when building program or IDL\n( #3059 ).\n- cli: Add checks for incorrect usage of idl-build feature\n( #3061 ).\n- lang: Export Discriminator trait from prelude\n( #3075 ).\n- lang: Add Account utility type to get accounts from bytes\n( #3091 ).\n- client: Add option to pass in mock rpc client when using anchor_client\n( #3053 ).\n- lang: Get discriminator length dynamically\n( #3101 ).\n- lang: Add non-8-byte discriminator support in declare_program!\n( #3103 ).\n- client: Make ThreadSafeSigner trait public\n( #3107 ).\n- lang: Update dispatch function to support dynamic discriminators\n( #3104 ).\n- lang: Remove the fallback function shortcut in try_entry function\n( #3109 ).\n- ts: Get discriminator lengths dynamically\n( #3120 ).\n- client: Support non-8-byte discriminators\n( #3125 ).\n- spl: Add withdraw_withheld_tokens_from_accounts instruction\n( #3128 ).\n- ts: Add optional wallet property to the Provider interface\n( #3130 ).\n- cli: Warn if anchor-spl/idl-build is missing\n( #3133 ).\n- client: Add internal_rpc method for mock feature\n( #3135 ).\n- lang: Add #[instruction] attribute proc-macro to override default\ninstruction discriminators\n( #3137 ).\n- lang: Use associated discriminator constants instead of hardcoding in\n#[account] ( #3144 ).\n- lang: Add discriminator argument to #[account] attribute\n( #3149 ).\n- lang: Add discriminator argument to #[event] attribute\n( #3152 ).\n- idl: Check ambiguous discriminators\n( #3157 ).\n- idl: Disallow all zero account discriminators\n( #3159 ).\n- cli: Support non-8-byte discriminators\n( #3165 ).\n- idl: Disallow empty discriminators\n( #3166 ).\n- cli: Add --no-idl option to the test command\n( #3175 ).\n- spl: Add burn_checked , mint_to_checked and approve_checked instructions\n( #3186 ).\n- cli: Migrate to agave-install when solana_version is >= 1.18.19\n( #3185 ).\n- idl: Add IdlBuilder\n( #3188 ).\n- cli: Make clean command also remove the .anchor directory\n( #3192 ).\n- lang: Deprecate #[interface] attribute\n( #3195 ).\n- ts: Include unresolved accounts in the resolution error message\n( #3207 ).\n- lang: Add LazyAccount\n( #3194 ).\n- avm: Ask whether to install if the version is not installed with the use\ncommand ( #3230 ).\n- cli: Warn if a manifest has solana-program dependency\n( #3250 ).\n- cli: Add completions command to generate shell completions via the\nclap_complete crate ( #3251 ).\n- cli: Always convert IDLs\n( #3265 ).\n- cli: Check whether the idl-build feature exists when using the idl build\ncommand ( #3273 ).\n- cli: Build IDL if there is only one program when using the idl build command\n( #3275 ).\n- cli: Add short alias for the idl build command\n( #3283 ).\n- cli: Add --program-id option to idl convert command\n( #3309 ).\n- lang: Generate documentation of constants in declare_program!\n( #3311 ).\n- cli: Add support for fetching legacy IDLs\n( #3324 ).\n- avm: Add short alias for install and list commands\n( #3326 ).\n- avm: Add Windows support for renaming anchor binary\n( #3325 ).\n- cli: Add optional package-manager flag in init command to set package\nmanager field in Anchor.toml\n( #3328 ).\n- cli: Add test template for Mollusk\n( #3352 ).\n- idl: Disallow account discriminators that can conflict with the zero\nconstraint ( #3365 ).\n- cli: Include recommended solana args by default and add new --max-retries\noption to the deploy command\n( #3354 ).\n- avm: Make installation download binaries by default\n( #3445 ).\n- idl: Support PDA resolution of call expressions that don't have any arguments\n( #3485 ).\n- spl: Add anchor-debug feature\n( #3511 ).\nFixes\n- idl: Make safety comment checks fail silently when program path env is not set\n( #3045 ).\n- idl: Avoid interference from rust tests during IDL generation\n( #3058 ).\n- lang: Fix align repr support in declare-program!\n( #3056 ).\n- lang: Make stack frames slimmer on ATA creation\n( #3065 ).\n- lang: Remove getrandom dependency\n( #3072 ).\n- lang: Make InitSpace support unnamed & unit structs\n( #3084 ).\n- lang: Fix using owner constraint with Box ed accounts\n( #3087 ).\n- lang: Add a sanity check for unimplemented token extensions\n( #3090 ).\n- cli: Skip IDL checks if --no-idl option is passed\n( #3093 ).\n- lang: Remove unnecessary clone in account exit routine\n( #3139 ).\n- cli: Fix installation with --locked argument using Rust v1.80 due to time\ncrate issue ( #3143 ).\n- lang: Fix compilation warnings due to unused deprecated program id macros\n( #3170 ).\n- ts: Remove crypto-hash dependency\n( #3171 ).\n- ts: Improve error message of unsupported view method\n( #3177 ).\n- idl: Fix panicking on tests\n( #3197 ).\n- lang: Remove arrayref dependency\n( #3201 ).\n- cli: Fix template code shouldn't escape\n( #3210 ).\n- idl: Fix using address constraint with non-const expressions\n( #3216 ).\n- idl: Fix using full path types with Program\n( #3228 ).\n- lang: Use closures for init constraints to reduce the stack usage of\ntry_accounts ( #2939 ).\n- lang: Allow the cfg attribute above the instructions\n( #2339 ).\n- idl: Log output with ANCHOR_LOG on failure and improve build error message\n( #3284 ).\n- lang: Fix constant bytes declarations when using declare_program!\n( #3287 ).\n- lang: Fix using non-instruction composite accounts with declare_program!\n( #3290 ).\n- idl: Fix instructions with tuple parameters not producing an\nerror( #3294 ).\n- ts: Update engines.node to >= 17\n( #3301 ).\n- cli: Use OS-agnostic paths\n( #3307 ).\n- avm: Use rustc 1.79.0 when installing versions older than v0.31\n( #3315 ).\n- cli: Fix priority fee calculation causing panic on localnet\n( #3318 ).\n- cli: Fix shell command failing due to outdated program initialization\n( #3351 ).\n- idl: Fix detecting false-positives from doc comments during module path\nconversion ( #3359 ).\n- cli: Remove passing the rent sysvar account to IDL instructions\n( #3372 ).\n- lang: Fix cpi feature instructions not accounting for discriminator\noverrides ( #3376 ).\n- idl: Ignore compiler warnings during builds\n( #3396 ).\n- cli: Avoid extra IDL generation during verify\n( #3398 ).\n- lang: Require zero accounts to be unique\n( #3409 ).\n- lang: Deduplicate zero accounts against init accounts\n( #3422 ).\n- cli: Fix custom provider.cluster\n( #3428 ).\n- cli: Ignore non semver solana/agave releases to avoid panic\n( #3432 ).\n- ts: Fix loading programs with numbers in their names using workspace\n( #3450 ).\n- lang: Remove a potential panic while getting the IDL in declare_program!\n( #3458 ).\n- cli: Fix altering user-provided lib names\n( #3467 ).\n- idl: Fix missing program::seed resolution\n( #3474 ).\n- lang: Fix adding derive s and repr s to type alias definitions in\ndeclare_program! ( #3504 ).\n- idl: Fix using constant identifiers as generic arguments\n( #3522 ).\n- client: Remove std::process::exit usage\n( #3544 ).\n- idl: Fix using Pubkey constants with seeds::program\n( #3559 ).\n- lang: Fix instructions with no accounts causing compilation errors when using\ndeclare_program! ( #3567 ).\n- idl: Fix using account or arg values for seeds::program\n( #3570 ).\n- lang: Fix using data as an instruction parameter name in declare_program!\n( #3574 ).\n- cli: Use camelCase for program name in anchor.workspace templates\n( #3581 ).\nBreaking\n- syn: Remove bpf target support in hash feature\n( #3078 ).\n- client: Add tokio support to RequestBuilder with async feature\n( #3057 ).\n- lang: Remove EventData trait\n( #3083 ).\n- client: Remove async_rpc method\n( #3053 ).\n- lang: Make discriminator type unsized\n( #3098 ).\n- lang: Require Discriminator trait impl when using the zero constraint\n( #3118 ).\n- ts: Remove DISCRIMINATOR_SIZE constant\n( #3120 ).\n- lang: #[account] attribute arguments no longer parses identifiers as\nnamespaces ( #3140 ).\n- spl: Rename metadata interface instruction fields from token_program_id to\nprogram_id ( #3076 ).\n- lang, ts: Remove \"8 byte\" requirement from discriminator error messages\n( #3161 ).\n- lang: Remove discriminator method from Discriminator trait\n( #3163 ).\n- docker: Upgrade node to 20.16.0 LTS\n( #3179 ).\n- ts: Change the Program constructor's idl parameter type to any\n( #3181 ).\n- lang, spl: Remove borsh 0.9 support\n( #3199 ).\n- ts: Upgrade typescript to 5.5.4 and remove the generic parameters of\nSimulateResponse ( #3221 ).\n- ts: Remove\nStateCoder ( #3224 ).\n- cli: Accept integers for warp_slot\n( #3235 ).\n- lang: Remove EventIndex\n( #3244 ).\n- spl: Remove dex feature\n( #3257 ).\n- client, lang, spl: Upgrade Solana to v2 and SPL to the latest\n( #3219 ).\n- cli: Install Solana from anza.xyz domain in Docker verifiable builds\n( #3271 ).\n- spl: Upgrade SPL deps to latest\n( #3346 ).\n- cli: Upgrade typescript version of templates to v5\n( #3480 ).\n- ts: Remove snake-case dependency\n( #3507 ).\n[0.30.1] - 2024-06-20\nFeatures\n- idl: Allow overriding the idl build toolchain with the RUSTUP_TOOLCHAIN\nenvironment variable\n( #2941 ).\n- avm: Support customizing the installation location using AVM_HOME\nenvironment variable ( #2917 ).\n- avm: Optimize avm list when GitHub API rate limits are reached\n( #2962 )\n- idl, ts: Add accounts resolution for associated token accounts\n( #2927 ).\n- cli: Add --no-install option to the init command\n( #2945 ).\n- lang: Implement TryFromIntError for Error to be able to propagate integer\nconversion errors ( #2950 ).\n- idl: Add ability to convert legacy IDLs\n( #2986 ).\n- ts: Extract Anchor error codes into their own package\n( #2983 ).\n- cli: Add additional solana arguments to the upgrade command\n( #2998 ).\n- spl: Export spl-associated-token-account crate\n( #2999 ).\n- lang: Support legacy IDLs with declare_program!\n( #2997 ).\n- cli: Add idl convert command\n( #3009 ).\n- cli: Add idl type command\n( #3017 ).\n- lang: Add anchor_lang::pubkey macro for declaring Pubkey const values\n( #3021 ).\n- cli: Sync program ids on the initial build\n( #3023 ).\n- idl: Remove anchor-syn dependency\n( #3030 ).\n- lang: Add const of program ID to declare_id! and declare_program!\n( #3019 ).\n- idl: Add separate spec crate\n( #3036 ).\nFixes\n- lang: Eliminate variable allocations that build up stack space for token\nextension code generation\n( #2913 ).\n- ts: Fix incorrect maxSupportedTransactionVersion in AnchorProvider.send*()\nmethods ( #2922 ).\n- cli: Use npm's configured default license for new projects made with\nanchor init ( #2929 ).\n- cli: add filename to 'Unable to read keypair file' errors\n( #2932 ).\n- idl: Fix path resolution of the Cargo.lock of the project when generating\nidls for external types\n( #2946 ).\n- idl: Fix potential panic on external type resolution\n( #2954 ).\n- lang: Fix using defined types in instruction parameters with\ndeclare_program! ( #2959 ).\n- lang: Fix using const generics with declare_program!\n( #2965 ).\n- lang: Fix using Vec type with declare_program!\n( #2966 ).\n- lang: Fix ProgramError::ArithmeticOverflow not found error\n( #2975 ).\n- lang: Fix using optional accounts with declare_program!\n( #2967 ).\n- lang: Fix instruction return type generation with declare_program!\n( #2977 ).\n- cli: Fix IDL write getting corrupted from retries\n( #2964 ).\n- idl: Fix unexpected_cfgs build warning\n( #2992 ).\n- lang: Make tuple struct fields public in declare_program!\n( #2994 ).\n- Remove rust-version from crate manifests\n( #3000 ).\n- cli: Fix upgradeable program clones\n( #3010 ).\n- ts: Fix using IDLs that have defined types as generic arguments\n( #3016 ).\n- idl: Fix generation with unsupported expressions\n( #3033 ).\n- idl: Fix using address constraint with field expressions\n( #3034 ).\n- lang: Fix using bytemuckunsafe account serialization with declare_program!\n( #3037 ).\nBreaking\n[0.30.0] - 2024-04-15\nFeatures\n- cli: Allow force init and new\n( #2698 ).\n- cli: Add verifiable option when deploy\n( #2705 ).\n- cli: Add support for passing arguments to the underlying\nsolana program deploy command with anchor deploy\n( #2709 ).\n- lang: Add InstructionData::write_to implementation\n( #2733 ).\n- lang: Add #[interface(..)] attribute for instruction discriminator overrides\n( #2728 ).\n- ts: Add .interface(..) method for instruction discriminator overrides\n( #2728 ).\n- cli: Check anchor-lang and CLI version compatibility\n( #2753 ).\n- ts: Add missing IDL PDA seed types\n( #2752 ).\n- cli: idl close accepts optional --idl-address parameter\n( #2760 ).\n- cli: Add support for simple wildcard patterns in Anchor.toml's\nworkspace.members and workspace.exclude .\n( #2785 ).\n- cli: Add --test-template option for init command\n( #2805 ).\n- cli: anchor test is able to run multiple commands\n( #2799 ).\n- cli: Check @coral-xyz/anchor package and CLI version compatibility\n( #2813 ).\n- cli: Accept package name as program name\n( #2816 ).\n- cli: Add ability to build and test only a specified program\n( #2823 ).\n- idl: Add new IDL spec\n( #2824 ).\n- idl: Add support for repr s\n( #2824 ).\n- idl: Add support for expression evaluation\n( #2824 ).\n- idl: Add support for using external types when generating the IDL\n( #2824 ).\n- idl, ts: Add unit and tuple struct support\n( #2824 ).\n- idl, ts: Add generics support\n( #2824 ).\n- ts: Add accountsPartial method to keep the old accounts method behavior\n( #2824 ).\n- ts: Make opts parameter of AnchorProvider constructor optional\n( #2843 ).\n- cli: Add --no-idl flag to the build command\n( #2847 ).\n- cli: Add priority fees to idl commands\n( #2845 ).\n- ts: Add prepend option to MethodBuilder preInstructions method\n( #2863 ).\n- lang: Add declare_program! macro\n( #2857 ).\n- cli: Add deactivate_feature flag to solana-test-validator config in\nAnchor.toml ( #2872 ).\n- idl: Add docs field for constants\n( #2887 ).\n- idl: Store deployment addresses for other clusters\n( #2892 ).\n- lang: Add Event utility type to get events from bytes\n( #2897 ).\n- lang, spl: Add support for\ntoken extensions\n( #2789 ).\n- lang: Return overflow error from Lamports trait operations\n( #2907 ).\nFixes\n- syn: Add missing new_from_array method to Hash\n( #2682 ).\n- cli: Switch to Cargo feature resolver( resolver = \"2\" )\n( #2676 ).\n- cli: Fix using user specific path for provider.wallet in Anchor.toml\n( #2696 ).\n- syn: Fix IDL constant seeds parsing\n( #2699 ).\n- cli: Display errors if toolchain override restoration fails\n( #2700 ).\n- cli: Fix commit based anchor_version override\n( #2704 ).\n- spl: Fix compilation with shmem feature enabled\n( #2722 ).\n- cli: Localhost default test validator address changes from localhost to\n127.0.0.1 , NodeJS 17 IP resolution changes for IPv6\n( #2725 ).\n- lang: Eliminate temporary Vec allocations when serializing data with\ndiscriminant and set the default capacity to 256 bytes\n( #2691 ).\n- lang: Allow custom lifetime in Accounts structure\n( #2741 ).\n- lang: Remove try_to_vec usage while setting the return data in order to\nreduce heap memory usage\n( #2744 )\n- cli: Show installation progress if Solana tools are not installed when using\ntoolchain overrides ( #2757 ).\n- ts: Fix formatting enums\n( #2763 ).\n- cli: Fix migrate command not working without global ts-node installation\n( #2767 ).\n- client, lang, spl, syn: Enable all features for docs.rs build\n( #2774 ).\n- ts: Fix construction of field layouts for type aliased instruction arguments\n( #2821 )\n- idl: Fix IDL ( #2824 ).\n- idl, ts: Make casing consistent\n( #2824 ).\n- ts: Fix not being able to use numbers in instruction, account, or event names\nin some cases due to case conversion\n( #2824 ).\n- cli: Fix excessive test validator requests\n( #2828 ).\n- client: Fix parse_logs_response to prevent panics when more than 1 outer\ninstruction exists in logs\n( #2856 ).\n- avm, cli: Fix stdsimd feature compilation error from ahash when installing\nthe CLI using newer Rust versions\n( #2867 ).\n- spl: Fix not being able to deserialize newer token 2022 extensions\n( #2876 ).\n- spl: Remove solana-program dependency\n( #2900 ).\n- spl: Make TokenAccount and Mint Copy\n( #2904 ).\n- ts: Add missing errors\n( #2906 ).\nBreaking\n- cli: Make cargo build-sbf the default build command\n( #2694 ).\n- cli: Require explicit overflow-checks flag\n( #2716 ).\n- ts: Remove anchor-deprecated-state feature\n( #2717 ).\n- lang: Remove CLOSED_ACCOUNT_DISCRIMINATOR\n( #2726 ).\n- lang: Make bumps of optional accounts Option rather than u8\n( #2730 ).\n- spl: Remove shared-memory program\n( #2747 ).\n- ts: Remove associated , account.associated and account.associatedAddress\nmethods ( #2749 ).\n- cli: idl upgrade command closes the IDL buffer account\n( #2760 ).\n- cli: Remove --jest option from the init command\n( #2805 ).\n- cli: Require idl-build feature in program Cargo.toml\n( #2824 ).\n- cli: Rename seeds feature to resolution and make it enabled by default\n( #2824 ).\n- cli: Remove idl parse command\n( #2824 ).\n- idl: Change IDL spec ( #2824 ).\n- syn: Remove idl-parse and seeds features\n( #2824 ).\n- ts: Change accounts method to no longer accept resolvable accounts\n( #2824 ).\n- ts: Program instances use camelCase for everything\n( #2824 ).\n- ts: Remove discriminator functions\n( #2824 ).\n- ts: Remove programId parameter of the Program constructor\n( #2864 ).\n- idl, syn: Move IDL types from the anchor-syn crate to the new IDL crate\n( #2882 ).\n- idl: Add #[non_exhaustive] to IDL enums\n( #2890 ).\n[0.29.0] - 2023-10-16\nFeatures\n- lang: Change all accounts to have a reference to AccountInfo\n( #2656 ).\n- lang: Add get_lamports , add_lamports and sub_lamports methods for all\naccount types ( #2552 ).\n- client: Add a helper struct DynSigner to simplify use of\nClient where > with Solana clap\nCLI utils that loads Signer as Box\n( #2550 ).\n- lang: Allow CPI calls matching an interface without pinning program ID\n( #2559 ).\n- cli, lang: Add IDL generation through compilation. anchor build still uses\nparsing method to generate IDLs, use anchor idl build to generate IDLs with\nthe build method ( #2011 ).\n- avm: Add support for the .anchorversion file to facilitate switching between\ndifferent versions of the anchor-cli\n( #2553 ).\n- ts: Add ability to access workspace programs independent of the casing used,\ne.g. anchor.workspace.myProgram , anchor.workspace.MyProgram ...\n( #2579 ).\n- bench: Add benchmarking for program binary size\n( #2591 ).\n- spl: Export mpl-token-metadata crate\n( #2583 ).\n- spl: Add TokenRecordAccount for pNFTs\n( #2597 ).\n- ts: Add support for unnamed(tuple) enum in accounts\n( #2601 ).\n- cli: Add program template with multiple files for instructions, state...\n( #2602 ).\n- bench: Add benchmarking for stack memory usage\n( #2617 ).\n- lang: Box the inner enums of anchor_lang::error::Error to optimize\nanchor_lang::Result\n( #2600 ).\n- ts: Add strong type support for Program.addEventListener method\n( #2627 ).\n- syn: Add IdlBuild trait to implement IDL support for custom types\n( #2629 ).\n- spl: Add idl-build feature. IDL build method will not work without enabling\nthis feature when using anchor-spl\n( #2629 ).\n- lang: Add support for type aliases in IDLs\n( #2637 ).\n- cli: Add test.upgradeable , test.genesis.upgradeable setting in\nAnchor.toml to support testing upgradeable programs\n( #2642 ).\n- cli, client, lang, spl: Update Solana toolchain and dependencies to 1.17.0 ,\n1.16 remains supported\n( #2645 ).\n- spl: Add support for memo program\n( #2661 ).\n- avm: Add anchor-cli installation from commit\n( #2659 ).\n- cli: Add toolchain property in Anchor.toml to override Anchor and Solana\nversions ( #2649 ).\nFixes\n- ts: Packages no longer depend on assert\n( #2535 ).\n- lang: Support for const in the InitSpace macro\n( #2555 ).\n- cli: Support workspace inheritance\n( #2570 ).\n- client: Compile with Solana 1.14\n( #2572 ).\n- cli: Fix anchor build --no-docs adding docs to the IDL\n( #2575 ).\n- ts: Load workspace programs on-demand rather than loading all of them at once\n( #2579 ).\n- lang: Fix associated_token::token_program constraint\n( #2603 ).\n- cli: Fix anchor account command panicking outside of workspace\n( #2620 ).\n- lang: IDL named enum variant fields are now camelCase as opposed to\nsnake_case, consistent with the other IDL types\n( #2633 ).\n- avm: Remove excessive panics and handle the errors gracefully\n( #2671 ).\nBreaking\n- lang: Switch to type safe bumps in context\n( #2542 ).\n- syn: idl feature has been replaced with idl-build , idl-parse and\nidl-types features ( #2011 ).\n- syn: IDL parse method now returns Result instead of\nResult>\n( #2582 ).\n- spl: Update mpl-token-metadata dependency to use the client SDK instead of\nthe program crate ( #2632 ).\n- ts: Remove base64-js dependency\n( #2635 ).\n- syn: IdlTypeDefinitionTy enum has a new variant Alias\n( #2637 ).\n- cli, client, lang, spl: Solana 1.14 is no longer supported, minimum required\nSolana version is 1.16.0\n( #2645 ).\n- cli: anchor_version and solana_version property in Anchor.toml that was\nbeing used in verifiable builds are moved inside toolchain . They are now\nbeing used for all commands in the workspace, not just verifiable builds\n( #2649 ).\n[0.28.0] - 2023-06-09\nFeatures\n- client: Add async feature flag to use an asynchronous anchor-client\n( #2488 ).\n- spl: Add metadata wrappers approve_collection_authority ,\nbubblegum_set_collection_size , burn_edition_nft , burn_nft ,\nrevoke_collection_authority , set_token_standard , utilize ,\nunverify_sized_collection_item , unverify_collection\n( #2430 )\n- spl: Add token_program constraint to Token , Mint , and AssociatedToken\naccounts in order to override required token_program fields and use\ndifferent token interface implementations in the same instruction\n( #2460 )\n- cli: Add support for Solidity programs. anchor init and anchor new take an\noption --solidity which creates solidity code rather than rust.\nanchor build and anchor test work accordingly\n( #2421 )\n- bench: Add benchmarking for compute units usage\n( #2466 )\n- cli: idl set-buffer , idl set-authority and idl close take an option\n--print-only . which prints transaction in a base64 Borsh compatible format\nbut not sent to the cluster. It's helpful when managing authority under a\nmultisig, e.g., a user can create a proposal for a Custom Instruction in SPL\nGovernance ( #2486 ).\n- lang: Add emit_cpi! and #[event_cpi] macros(behind event-cpi feature\nflag) to store event logs in transaction metadata\n( #2438 ).\n- cli: Add keys sync command to sync program id declarations\n( #2505 ).\n- cli: Create new programs with correct program ids\n( #2509 ).\n- cli, client, lang, spl: Update Solana toolchain and dependencies to 1.16.0\nand specify maximum version of <1.17.0\n( #2512 ).\n- cli: anchor deploy command's --program-name argument accepts program lib\nnames ( #2519 ).\nFixes\n- ts: Narrowed AccountClient type to it's appropriate account type\n( #2440 )\n- lang: Fix inability to use identifiers program_id , accounts , ix_data ,\nremaining_accounts in instruction arguments\n( #2464 )\n- cli: Fix incorrect metadata.address generation in IDL after deploying with a\ncustom keypair ( #2485 )\n- cli: IDL commands no longer hang when the payer doesn't have funds to pay for\nthe transaction fee ( #2492 )\n- cli: Fix anchor new not updating Anchor.toml\n( #2516 ).\n- client, lang, spl: Allow wider range of dependency versions to reduce\ndependency issues ( #2524 ).\nBreaking\n- lang: Identifiers that are intended for internal usage( program_id ,\naccounts , ix_data , remaining_accounts ) have been renamed with __\nprefix ( #2464 )\n- spl: Remove the metadata::create_metadata_account_v2 deprecated wrapper\nsince it was removed from token metadata program\n( #2480 )\n[0.27.0] - 2023-03-08\nFeatures\n- spl: Add MasterEditionAccount account deserialization to spl metadata\n( #2393 ).\n- lang: Add the InitSpace derive macro to automatically calculate the space at\nthe initialization of an account\n( #2346 ).\n- cli: Add env option to verifiable builds\n( #2325 ).\n- cli: Add idl close command to close a program's IDL account\n( #2329 ).\n- cli: idl init now supports very large IDL files\n( #2329 ).\n- spl: Add transfer_checked function\n( #2353 ).\n- spl: Add approve_checked function\n( #2401 ).\n- cli: Add --skip-build option to the verify command\n( #2387 )."}
{"url":"https://docs.squads.so/main/navigating-your-squad/payments","domain":"docs.squads.so","title":"Payments | Squads Docs","hash":"c91366243d43a14c3fc50db70205eb715ac6e04749f70d3064895cda195d00bb","tokens":890,"chars":3557,"crawler":"crawler-tpoe","verified":"exact","ts":1791112285083,"text":"Squads Docs\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nPayments\nStreamline your onchain payments\nSquads Payments is the next step in streamlining onchain payments.\nThe first iteration of Squads Payments introduces a âRecipientsâ feature to create, track, and manage recurring paymentsâeliminating manual entry and saving teams valuable time. Users only need to input recipient details, amounts, and payout schedules once. The system generates reminders and pre-filled payments at scheduled intervals, reducing administrative overhead and manual errors.\nThe âSendâ feature on the âDashboardâ tab remains ideal for one-time transfers, while the âRecipientsâ feature is optimized for recurring transactions like payroll\nSquads Payments is available to all Squads App subscribers, including Business and Enterprise plans .\nAccessing the Payments tab requires sign-in authentication for public and private Squads, ensuring that sensitive payment data stays private.\nHow to create a recurring payment:\n-\nHead to the Payments tab, select âAdd Recipientâ and enter their details (name, address, email, position, tags).\n-\nSpecify details about the payment schedule by entering:\n-\nToken and amount;\n-\nDate of first payment\n-\nEnd (specific date or after a particular number of payments)\n-\nFrequency (weekly, biweekly, or monthly on a specific date)\nThe account you choose to make the payment from can be changed later.\n-\nReview the details and click âAddâ to create the payment.\nTracking Recurring Payments\nEverything you need to manage your recurring payments is available in the Payments tab. A new recipient is added to the âRecipientsâ overview five days before the first recurring payment. Each Recipient entry can have one of three statuses related to the recurring payment:\n-\nDue: the status updates to Due five days before payment is due.\n-\nOverdue: the status updates from Due to Overdue if a transaction has not been initiated, approved, and executed for a scheduled payment.\n-\nPaid: the status updates from Due or Overdue to Paid once the payment transaction has been initiated, approved, and executed.\nEach recipient entry has all the important details like name, position, amount, periodicity, payment status, and tags for filtering with ease. Users can click on any Recipient entry to view more or edit that Recipientâs details and view the related payment history.\nManaging recurring payments\nInitiate and approve payments by selecting recipients with a âDueâ status from the âRecipientsâ overview. After initiation, the related transaction will appear in the âTransactionsâ tab for final approval and execution based on your Squad's threshold.\nUse the âSkipâ function to bypass specific payments while maintaining the Recipient's regular payment schedule, and view finalized payments (meaning the recurring payment period is over) in the âArchiveâ folder for future reference.\nHow to pay an invoice:\n-\nSelect all the Recipients you want to pay in the Payments tab.\nYou can only select recipients (up to 15 at once) who are paid from the same subaccount.\n-\nClick âReviewâ to continue and review the payments before executing.\n-\nOnce reviewed, click the âApproveâ button to initiate the transaction. After initiation, the transaction can be approved and executed from the Transactions tab once the minimum confirmation threshold is met.\nPrevious Airdrop Checker\nNext Trade\nLast updated 1 year ago\n- How to create a recurring payment:\n- Tracking Recurring Payments\n- Managing recurring payments"}
{"url":"https://forum.solana.com/t/who-votes-three-proposals/485/15","domain":"forum.solana.com","title":"Who votes - three proposals - #15 by laine - Governance - Solana Developer Forums","hash":"82dd1921df3ea3942fb472d376757a5855629c03516931934a99880a88539289","tokens":211,"chars":843,"crawler":"hive-genesis","verified":"exact","ts":1791112285996,"text":"Solana Developer Forums\nWho votes - three proposals\nGovernance\nlaine\nOctober 10, 2023, 11:19am\n15\nHi All,\nI have created an advisory vote to sample validatorsâ stake-weighted opinions: VOTE! First Governance Advisory Vote by Validators\n1 Like\nshow post in topic\nRelated topics\nTopic\nReplies\nViews\nActivity\nProposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta\nGovernance\nfeature\n,\ncore\n76\n12928\nDecember 25, 2024\nVOTE! First Governance Advisory Vote by Validators\nGovernance\nvote\n6\n2810\nJuly 30, 2026\nProposal for an In-Protocol Distribution of Block Rewards to Stakers\nGovernance\n24\n3580\nMarch 14, 2025\nSIMD-0326: Proposal for the New Alpenglow Consensus Protocol\nGovernance\ncore\n117\n11680\nJune 13, 2026\nFeedback on the SIMD-123 and SIMD-228 governance process\nGovernance\n2\n983\nApril 16, 2025\nDiscourse Footer"}
{"url":"https://bitcoin.org/fees/","domain":"bitcoin.org","title":"Bitcoin Transaction Fees Today - Live Fee Rates | Bitcoin.org","hash":"cb4a6374b08f9c93e665725514c205878e79dcee9da487409fc391a8339b141a","tokens":1072,"chars":4288,"crawler":"crawler-tpoe","verified":"exact","ts":1791112286578,"text":"Keep Bitcoin.org independent and available worldwide.\nCommunity support helps maintain and improve this open resource.\nSupport Bitcoin.org\nScan the QR code or open your Bitcoin wallet. You can optionally prefill an amount below.\nSend with Bitcoin\nBitcoin only · On-chain\nOpen in wallet\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nPrefill an amount (optional)\nBTC amount\nUSD amount\nAdd an optional wallet note\nOptional note for your wallet\n- Introduction\n- Individuals\n- Businesses\n- Developers\n- Getting started\n- How it works\n- You need to know\n- White paper\n- Resources\n- Exchanges\n- Community\n- BIPs list\n- Halving\n- Documentation\n- Vocabulary\n- Bitcoin Core\n- Innovation\n- Participate\n- Support Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Running a full node\n- Development\n- Price\n- Fees\n- FAQ\nBitcoin network data\nBitcoin transaction fees\nWhat it costs to send a transaction right now â and how fees work.\nFastest\nnext block\nâ sat/vB\nFast\nabout 30 minutes\nâ sat/vB\nStandard\nabout an hour\nâ sat/vB\nEconomy\nno hurry\nâ sat/vB\nConnecting to network dataâŠ\nApproximate cost for a typical transaction of about 140 vB. Your wallet shows the exact fee before you send.\nWhat is a transaction fee?\nEvery Bitcoin transaction includes a small fee. The fee does not go to any company or to this website: it is collected by the miner who includes your transaction in a block. Fees reward miners for securing the network, and they act as the price of space in the next block, which is limited.\nWhy fees change\nBlock space is roughly constant, but the number of people trying to transact is not. When many transactions compete at once, fees rise; when the network is quiet, fees fall. The same transaction can cost noticeably more on a busy day than on a calm one. Nothing is wrong in either case â the fee market is simply doing its job of deciding whose transactions go first.\nHow fees are measured: sat/vB\nFees are quoted in satoshis per virtual byte (sat/vB). You pay for the size of your transaction in the block, not for the amount of bitcoin you send: moving a small payment and moving a fortune can cost the same fee if the transactions are the same size. A satoshi is the smallest unit of bitcoin (100,000,000 satoshis = 1 BTC). A simple payment â one input, two outputs â takes up around 140 virtual bytes; transactions with more inputs and outputs are larger.\nChoosing a fee\nMost wallets estimate fees for you and let you choose between speed and economy: a higher rate aims for the next block, a lower rate waits until the network is quieter. Different wallets can suggest different numbers for the same moment â fee estimation is a prediction, not an exact science. If your payment is not urgent, choosing a lower fee and waiting is a perfectly good strategy.\nIf your transaction seems stuck\nA transaction with a low fee during a busy period is not lost â it is waiting in a queue (the mempool) until space is available. It may confirm once demand for block space falls. Many wallets can also speed up a waiting transaction by increasing its fee (a feature called Replace-by-Fee), or you can simply wait: an unconfirmed transaction either confirms or is eventually dropped by the network â and in that case the funds simply remain spendable in your wallet, because they never actually left it.\nSmall and everyday payments\nFor small or frequent payments, the Lightning Network offers near-instant transfers with fees that are typically a tiny fraction of a cent. It works on top of Bitcoin and is supported by a growing number of wallets and merchants â see Spend Bitcoin for places that accept it.\nLive estimates from mempool.space, with blockstream.info as a fallback, fetched directly in your browser. This page never handles your funds.\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroduction:\n-\nIndividuals\n-\nBusinesses\n-\nDevelopers\n-\nGetting started\n-\nHow it works\n-\nYou need to know\n-\nWhite paper\nResources:\n-\nResources\n-\nExchanges\n-\nCommunity\n-\nBIPs list\n-\nHalving\n-\nDocumentation\n-\nVocabulary\n-\nBitcoin Core\nParticipate:\n-\nSupport Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nRunning a full node\n-\nDevelopment\nOther:\nPrice\nFees\nAvoid Scams\nLegal\nPrivacy Policy\nPress\nAbout bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Released under the MIT license\nNetwork Status"}
{"url":"https://bitcoinops.org/en/newsletters/2026/04/24/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #402 | Bitcoin Optech","hash":"b838d614cda34c0a0b9749b26a4113b3916c7817a3265346f7a47ec1ae55d9fe","tokens":2759,"chars":11035,"crawler":"hive-genesis","verified":"unchecked","ts":1791112287886,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #402\nApr 24, 2026\nThis weekâs newsletter describes Hornet Nodeâs work on a declarative executable\nspecification of consensus rules and summarizes a discussion about onion message\njamming in the Lightning Network. Also included are our regular sections with\nselected questions and answers from the Bitcoin Stack Exchange, announcements of\nnew releases and release candidates, and descriptions of notable changes to\npopular Bitcoin infrastructure software.\nNews\n-\nâ Hornet Nodeâs declarative executable specification of Bitcoin consensus rules :\nToby Sharp posted to Delving Bitcoin and the Bitcoin-Dev mailing\nlist an update on the Hornet node project. Sharp had\npreviously described a new node implementation Hornet that\nreduced initial block download times from 167 minutes down to 15 minutes. In\nthis update, he reports completing a declarative specification of non-script\nblock validation rules, consisting of 34 semantic invariants composed using a\nsimple algebra.\nSharp also outlines future work, including extending the specification to\nscript validation, and discusses potential comparisons with other\nimplementations such as libbitcoin in response to feedback from Eric Voskuil.\n-\nâ Onion message jamming in the Lightning Network : Erick Cestari posted to\nDelving Bitcoin about the onion message jamming problem affecting\nthe Lightning Network. BOLT4 acknowledges onion messages to be unreliable, recommending\nto apply rate limiting techniques. According to Cestari, these techniques are what makes message jamming possible. Attackers\nmay spin up malicious nodes and flood the network with spam messages triggering rate limits\nof peers, forcing them to drop legitimate messages. Moreover, BOLT4 does not enforce a\nmaximum message length, allowing attackers to maximize the reach of a single message.\nCestari reviewed several mitigations to onion message jamming and provided a\ncomprehensive overview of the techniques he deemed more suitable:\n-\nâ Upfront fees : This technique was first proposed by Carla Kirk-Cohen in BOLTs #1052\nas a solution for channel jamming, but can be easily extended. Nodes would advertise a per-message\nflat fee, to be included in the onion payload and deducted at each hop. In case the fee is not\npaid, the message would be just dropped by the node. This method presents some limitations, such\nas being able to only forward messages to channel peers and increased p2p overhead.\n-\nâ Hop limit and proof-of-stake based on channel balances : This technique was proposed\nby Bashiri and Khabbazian at the University of Alberta and has two different components:\n-\nLeashing hop count: Either setting a hard-cap on the maximum number of hops that a message could do\n(e.g. 3 hops), or having the sender solve a proof-of-work puzzle, whose difficulty increases\nexponentially with the number of hops.\n-\nProof-of-stake forwarding rule: Each node sets per-peer rate limits according to the peerâs aggregate\nchannel balance, granting well-funded nodes more forwarding power.\nThe trade-offs of this approach are related to centralization pressure, due to larger nodes being at\nan advantage, while the 3-hops hard-cap could reduce anonymity set.\n-\nâ Bandwidth metered payment : Proposed by Olaoluwa Osuntokun, this technique is\nsimilar in scope as upfront fees, but adds per-session state and settles through\nAMP payments . A sender would first send the AMP payment, dropping fees\nat each intermediate step and delivering an ID for the session. The sender would then include the\nID in the onion message. Known limitations of the approach are related to the ability to only forward\nmessages to channel peers and the possibility to link all the messages belonging to the same session.\n-\nâ Backpropagation-based rate limiting : This approach, proposed by Bastien Teinturier,\nuses a backpressure mechanism that is statistically able to trace back spam to its source.\nWhen the per-peer rate limiting is hit, the node sends a drop message back to the sender, which in turn\nrelays it to the last peer that forwarded the original message halving its rate limit. While the correct\nsender is statistically identified, the wrong peer could be penalized. Moreover, an attacker could fake\nthe drop message, lowering rate limits of honest nodes.\nFinally, Cestari invited LN developers to join the discussion, stating that a window is still available to\nmitigate the issue before prolonged DDoS attacks hit the network, as happened to Tor recently.\nSelected Q&A from Bitcoin Stack Exchange\nBitcoin Stack Exchange is one of the first places Optech\ncontributors look for answers to their questionsâor when we have a\nfew spare moments to help curious or confused users. In\nthis monthly feature, we highlight some of the top-voted questions and\nanswers posted since our last update.\n-\nâ Why did BIP342 replace CHECKMULTISIG with a new opcode, instead of just removing FindAndDelete from it?\nPieter Wuille explains that the replacement of OP_CHECKMULTISIG with\nOP_CHECKSIGADD in tapscript was necessary to enable batch\nverification of schnorr signatures (see\nNewsletter #46 ) in a potential future protocol change.\n-\nâ Does SIGHASH_ANYPREVOUT commit to the tapleaf hash or the full taproot merkle path?\nAntoine Poinsot confirms that SIGHASH_ANYPREVOUT\nsignatures currently commit only to the tapleaf hash, not the full merkle path\nin the taproot tree. However, this design is under discussion\nas one BIP co-author has suggested committing to the full merkle path instead.\n-\nâ What does the BIP86 tweak guarantee in a MuSig2 Lightning channel, beyond address format?\nAva Chow points out that the tweak prevents the use of hidden script paths\nbecause MuSig2âs signing protocol requires all participants to\napply the same BIP86 tweak for signature aggregation to succeed. If one\nparty attempts to use a different tweak, such as one derived from a hidden\nscript tree, their partial signature wonât aggregate into a valid final\nsignature.\nReleases and release candidates\nNew releases and release candidates for popular Bitcoin infrastructure\nprojects. Please consider upgrading to new releases or helping to test\nrelease candidates.\n-\nâ Bitcoin Core 31.0 is the latest major version release of the networkâs\npredominant full node implementation. The release notes describe\nseveral significant improvements, including the implementation of the cluster\nmempool design, a new -privatebroadcast option for\nsendrawtransaction (see Newsletter #388 ), asmap data\noptionally embedded into the binary for eclipse attack protection, and an increase in the default -dbcache to 1024 MiB on\nsystems with at least 4096 MiB of RAM, among many other updates.\n-\nâ Core Lightning 26.04 is a major release of this popular LN node\nimplementation. It enables splicing by default, adds new\nsplicein and spliceout commands including a cross-splice mode that\ntargets a second channel as the destination of a splice-out, redesigns\nbkpr-report for income summaries, adds parallel pathfinding and multiple bug\nfixes in askrene , adds a fronting_nodes option on the offer RPC and a\npayment-fronting-node config, and removes support for the legacy onion\nformat. See the release notes for additional details.\n-\nâ LND 0.21.0-beta.rc1 is the first release candidate for the next major\nversion of this popular LN node. Users running nodes with the\n--db.use-native-sql flag against an SQLite or PostgreSQL backend should note that\nthis version migrates the payment store from the key-value (KV) format to\nnative SQL, with an opt-out via --db.skip-native-sql-migration . See the\nrelease notes .\nNotable code and documentation changes\nNotable recent changes in Bitcoin Core , Core\nLightning , Eclair , LDK ,\nLND , libsecp256k1 , Hardware Wallet\nInterface (HWI) , Rust Bitcoin , BTCPay\nServer , BDK , Bitcoin Improvement\nProposals (BIPs) , Lightning BOLTs ,\nLightning BLIPs , Bitcoin Inquisition , and BINANAs .\n-\nâ Bitcoin Core #33477 updates how the dumptxoutset RPCâs rollback mode\n(see Newsletter #72 ) builds historical UTXO set dumps used for\nassumeUTXO snapshots. Instead of rolling back the main\nchainstate by invalidating blocks, Bitcoin Core creates a temporary UTXO\ndatabase, rolls it back to the requested height, and writes the snapshot from\nthe temporary database. This preserves the main chainstate, eliminating the\nneed to suspend network activity and the risk of fork-related interference\nwith the rollback, at the cost of additional temporary disk space and slower\ndumps. A new in_memory option keeps the temporary UTXO database entirely in\nRAM, enabling faster rollbacks but requiring over 10 GB of free memory on\nmainnet. For deep rollbacks, it is recommended to use no RPC timeout ( bitcoin-cli\n-rpcclienttimeout=0 ) as it may take several minutes.\n-\nâ Bitcoin Core #35006 adds a -rpcid option to bitcoin-cli to set a\ncustom string as the JSON-RPC request id instead of the default hardcoded\nvalue of 1 . This allows requests and responses to be correlated when\nmultiple clients make concurrent calls. The identifier is also included in the\nserver-side RPC debug log.\n-\nâ BIPs #1895 publishes BIP361 , an abstract proposal for\npost-quantum migration and legacy signature\nsunset. Assuming a separate post-quantum (PQ) signature scheme is standardized\nand deployed, it outlines a phased migration away from ECDSA/ schnorr signature schemes. The current version of the proposal is\ndivided into two phases. Phase A prohibits sending funds to quantum-vulnerable\naddresses, thereby accelerating the adoption of PQ address types. Phase B\nrestricts ECDSA/schnorr spending and includes a quantum-safe rescue protocol\nto prevent theft of quantum-vulnerable UTXOs.\n-\nâ BIPs #2142 updates BIP352 , the silent payments BIP proposal, by adding a send/receive test vector for an edge case\nwhere the running sum of input keys hits zero after two inputs but the final\nsum over all inputs is non-zero. This catches implementations that reject\nearly during incremental summation instead of summing all inputs first.\n-\nâ LDK #4555 fixes how forwarding nodes enforce max_cltv_expiry for blinded payment paths . The field is\nmeant to ensure an expired blinded route is rejected at the introduction hop\nrather than being forwarded through the blinded segment and failing closer to\nthe receiver. Previously, LDK compared the constraint against the hopâs\noutgoing CLTV value; it now checks the inbound CLTV expiry as intended.\n-\nâ LND #10713 adds per-peer and global token-bucket rate limits for incoming\nonion messages , dropping excess traffic at ingress\nbefore it reaches the onion handler. This hardens LNDâs recently added onion\nmessage forwarding support (see Newsletter #396 ) against\nhigh-volume abuse from fast peers. The per-peer and global split mirrors LNDâs\nearlier gossip bandwidth limits (see Newsletter #370 ).\n-\nâ LND #10754 stops forwarding an onion message when\nthe chosen next hop is the same peer that delivered it, avoiding an immediate\nbounce on the same connection."}
{"url":"https://docs.phantom.com/cash","domain":"docs.phantom.com","title":"CASH - Phantom developer documentation","hash":"294f556fa9a66a6a35379aaba3214f58c15e06783053e0ea526dffc3b51b9506","tokens":483,"chars":1931,"crawler":"crawler-tpoe","verified":"exact","ts":1791112288322,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPhantom developer documentation home page\nGet started\nPhantom MCP server\nPhantom CLI\nPhantom Portal\nPhantom Connect SDKs\nRecipes\nDeveloper tools and resources\nOverview\nCASH\nCASH is a stablecoin on Solana. Learn about the token mint, integration details, and how to accept CASH payments in your app.\nThis 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 .\nToken details\nField Value\nChain Solana\nMint CASHx9KJUStyftLFWGvEVf59SGeG9sh5FfcnZMVPCASH\nDecimals 6\nStandard SPL Token\n1 CASH = 1,000,000 base units. Use base units when constructing on-chain transactions.\nIntegrating 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.\nAccepting 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.\nDevnet\nDevnet CASH tokens are available for testing. Contact developer support with your use case to get a devnet mint address and test tokens.\nNext steps\n- Learn more about SPL tokens in the Solana token docs .\n- Browse Developer tools and resources for Phantom guides, provider integration, and mobile deep links.\n- Integrate wallets in your app with Phantom Connect .\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.cardano.org/pioneer-programs/education","domain":"docs.cardano.org","title":"Input | Output education | Cardano Docs","hash":"89eed1b6ac1b96c9615ba781da790ef09957bdaa40b71eccf5b39ae8ef73465a","tokens":896,"chars":3584,"crawler":"hive-genesis","verified":"unchecked","ts":1791112289562,"text":"Skip to main content\nInput | Output education\nIO educational resources\nEducation has been a cornerstone of building a knowledgeable and engaged global community. Over the years, IO has shared its expertise and helped developers, academics, and business professionals build the skills needed to contribute to the Cardano ecosystem.\nThis work drew on deep experience in curriculum design, project management, and the technical intricacies of Cardano, Haskell, and smart contracts, resulting in a library of courses and resources that remain available today.\nUniversity collaborations\nIO has collaborated with universities and educational institutions worldwide to deliver this content, including:\n- University of Edinburgh , home to a blockchain laboratory run by IOGâs chief scientist, Prof Aggelos Kiayias, and his research team\n- University of Athens\n- University of West Indies\n- University of Wyoming\n- Carnegie Mellon University\n- European Business University of Luxembourg\n- University of Malta\n- University of Cantabria\nIO has also worked on curriculum design for blockchain programs with Yeovil College in the United Kingdom and Consilium Academy in South Africa.\nCourse offerings\nMission-based education\n- Cardano Days : interactive events providing a deep dive into the Cardano platform, covering its unique features and applications. Events were held at ITESO University (Guadalajara, Mexico), University of Celaya (Guanajuato, Mexico), University of Malta (Valletta), University of Wyoming (Laramie), and University of Cantabria (Santander). These events covered the basics of blockchain technology, Cardano, and smart contracts, and were very well received, with a typical Net Promoter Score of ninety-two.\n- Mastering Cardano : a comprehensive book providing an in-depth understanding of the Cardano blockchain.\nDeveloper education\n- Cardano Developer course : trains developers to build smart contracts and decentralized applications on the Cardano platform.\n- Plutus Pioneer program : focuses on Plutus, Cardano's smart contract platform, offering hands-on experience writing and deploying smart contracts.\n- DRep Pioneer program : prepares participants to become delegate representatives, playing a crucial role in Cardano's governance.\n- Haskell Bootcamp : an immersive, self-paced Haskell course combining videos and interactive lessons, serving as a stepping stone into the Plutus Pioneer program.\n- Hackathons : supported at universities and blockchain events, including in Mongolia, the United States, and Argentina.\nInternal training\n- Plutus internal training : based on the Plutus Pioneer program, offering insight into core smart contract functionality.\n- IO Maths Academy : a basic category theory course teaching the functional approach to mathematics for building stronger code with mathematical precision.\nAcademic and business collaborations\nIO has engaged in academic and business collaborations, offering specialized lectures and workshops on blockchain and Cardano, bridging theoretical knowledge and practical application. Examples include:\n- Smart contract lectures (virtual and in-person) at the University of Malta\n- Cardano Developer course with the National Technological University in Buenos Aires.\nResources\nFor more education content, visit the IOG Academy YouTube channel , where past lectures and educational content remain available.\nOn this page\n- IO educational resources\n- University collaborations\n- Course offerings\n- Mission-based education\n- Developer education\n- Internal training\n- Academic and business collaborations\n- Resources"}
{"url":"https://bitcoinops.org/en/newsletters/2024/10/18/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #325 | Bitcoin Optech","hash":"6ec29f57a6d4fda05c14b8ba1375519a4b5effa7252f874ab9bbf31a99149ebc","tokens":2217,"chars":8865,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112290164,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #325\nOct 18, 2024\nThis weekâs newsletter looks at summaries of some of the topics\ndiscussed at a recent LN developer meeting. Also include are our\nregular sections with descriptions of changes to popular clients and\nservices, announcements of new releases and release candidates, and\nsummaries of notable changes to popular Bitcoin infrastructure software.\nNews\n-\nâ LN Summit 2024 notes: Olaoluwa Osuntokun posted to Delving Bitcoin a summary of his notes (with additional commentary) from a recent LN developer\nconference. Some of the topics discussed included:\n-\nâ Version 3 commitment transactions: developers discussed how to use\nnew P2P features , including TRUC\ntransactions and P2A outputs, to improve\nthe security of LN commitment transactions that can be used to\nunilaterally close a channel. Discussion focused on various design\ntradeoffs.\n-\nâ PTLCs: although long proposed as a privacy upgrade to LN, as well\nas possibly useful for other purposes such as stuckless\ntransactions , recent research\ninto the tradeoffs of various possible PTLC\nimplementations was discussed (see Newsletter #268 ).\nA particular focus was the construction of the signature\nadaptor (e.g. using scripted multisig\nversus scriptless MuSig2 ) and its effect on the\ncommitment protocol (see next item).\n-\nâ State update protocol: a proposal was discussed to convert LNâs\ncurrent state update protocol from allowing either side to propose an\nupdate at any time to only allowing one party at a time to propose\nupdates (see Newsletters #120 and\n#261 ). Allowing either side to propose updates can\nresult in both sides proposing updates simultaneously, which is\ndifficult to reason about and can lead to accidental channel force\nclosures. The alternative is for only one party to be in\ncharge at a time, e.g. Alice is initially the only one allowed to\npropose state updates; if she has none to propose, she can tell Bob\nthat heâs in charge. When Bobâs finished proposing updates, he can\ntransfer control back to Alice. This simplifies reasoning about the\nprotocol, eliminates problems with simultaneous proposals, and\nfurther makes it easy for the non-controlling party to reject any\nunwanted proposals. The new round-based protocol would also work\nwell with MuSig2-based signature adaptors.\n-\nâ SuperScalar: the developer of a proposed channel factory construction for end-users gave a presentation on\nthe proposal and solicited feedback. Optech will publish a more\ndetailed description of SuperScalar in a\nfuture newsletter.\n-\nâ Gossip upgrade: developers discussed upgrades to the LN gossip\nprotocol . These are most urgently\nneeded for supporting new types of\nfunding transactions, such as for simple taproot channels , but may also add support for other\nfeatures. One new feature discussed was having channel announcement\nmessages include an SPV proof (or a commitment to an SPV proof) to\nallow lightweight clients to verify that a funding transaction (or\nsponsoring transaction) was included in a block at some point.\n-\nâ Research on fundamental delivery limits: research was presented on\npayment flows that cannot result in success given limitations of the\nnetwork (e.g., channels with insufficient capacity); see Newsletter\n#309 . If an LN payment is infeasible, the\nspender and receiver can always use an onchain payment. However,\nthe rate of onchain payments is limited by the maximum block weight,\nso itâs possible to calculate the maximum throughput (payments per\nsecond) of the combined Bitcoin and LN system by dividing the\nmaximum onchain rate by the rate of infeasible LN payments. Using\nthis rough metric, to achieve a maximum of about 47,000 payments per\nsecond, the infeasible rate must be below 0.29%. Two techniques\nwere discussed for reducing the infeasible rate: (1) virtual or real\nchannels that involve more than two parties, as more parties implies\nmore funds for forwarding and more forwarding funds increases the\nrate of feasibility; and (2) credit channels where parties who\ntrust each other can forward payments between themselves without the\nability to enforce those payments onchainâwith all other users\nstill receiving trustless payments.\nOsuntokun encouraged other participants to post corrections or\nexpansions to the thread.\nChanges to services and client software\nIn this monthly feature, we highlight interesting updates to Bitcoin\nwallets and services.\n-\nâ Coinbase adds taproot send support:\nCoinbase exchange now supports user withdrawals (send) to taproot\nbech32m addresses.\n-\nâ Dana wallet released:\nDana wallet is a silent payment wallet focused on the\ndonation use case. The developers recommend using signet and\nalso run a signet faucet .\n-\nâ Kyoto BIP157/158 light client released:\nKyoto is a Rust light client using compact block\nfilters for use by wallet developers.\n-\nâ DLC Markets launches on mainnet:\nThe DLC -based platform announced mainnet\navailability for its non-custodial trading service.\n-\nâ Ashigaru wallet announced:\nAshigaru is a fork of the Samourai Wallet project and the\nannouncement listed improvements to batching , RBF support, and fee estimation .\n-\nâ DATUM protocol announced:\nThe DATUM mining protocol allows miners to build candidate blocks as part\nof a pooled mining setup, similar to the Stratum v2 protocol.\n-\nâ Bark Ark implementation announced:\nThe Second team announced the Bark\nimplementation of the Ark protocol and demonstrated\nlive Ark transactions on mainnet.\n-\nâ Phoenix v2.4.0 and phoenixd v0.4.0 released:\nThe Phoenix v2.4.0 and phoenixd v0.4.0 releases add\nsupport for the BLIP36 on-the-fly funding proposal and other\nliquidity features (see Podcast #323 ).\nReleases and release candidates\nNew releases and release candidates for popular Bitcoin infrastructure\nprojects. Please consider upgrading to new releases or helping to test\nrelease candidates.\n- â BDK 1.0.0-beta.5 is a release candidate (RC) of this library for\nbuilding wallets and other Bitcoin-enabled applications. This latest\nRC âenables RBF by default and updates the bdk_esplora client to retry\nserver requests that fail due to rate limiting. The bdk_electrum\ncrate now also offers a use-openssl feature.â\nNotable code and documentation changes\nNotable recent changes in Bitcoin Core , Core\nLightning , Eclair , LDK ,\nLND , libsecp256k1 , Hardware Wallet\nInterface (HWI) , Rust Bitcoin , BTCPay\nServer , BDK , Bitcoin Improvement\nProposals (BIPs) , Lightning BOLTs ,\nLightning BLIPs , Bitcoin Inquisition , and BINANAs .\n-\nâ Bitcoin Core #30955 introduces two new methods to the Mining interface\n(see Newsletter #310 ), in line with the requirements for\nStratum V2 . The submitSolution() method allows miners\nto submit a block solution more efficiently by only requiring the nonce,\ntimestamp, version fields, and coinbase transaction, instead of the entire\nblock. Additionally, getCoinbaseMerklePath() is introduced to construct the\nmerkle path field required in the NewTemplate message. This PR also\nreinstates BlockMerkleBranch , which was previously removed in Bitcoin Core\n#13191 .\n-\nâ Eclair #2927 adds enforcement of recommended feerates (see Newsletter\n#323 ) for on-the-fly funding (see Newsletter #323 ), by rejecting open_channel2 and splice_init messages that use a\nfeerate lower than the recommended value.\n-\nâ Eclair #2922 removes support for splicing without\nchannel quiescence (see Newsletter #309 ), to conform to\nthe latest splicing protocol as proposed in BOLTs #1160 , which requires\nnodes to use the quiescence protocol during splicing. Previously, splicing was\nallowed under a less formal mechanism, where splice messages were permitted if\nthe commitments were already quiescent, acting as a âpoor manâsâ version of\nchannel quiescence.\n-\nâ LDK #3235 adds a last_local_balance_msats field to the\nChannelForceClosed event, which gives the local balance of a node in\nmillisatoshis (msats) just before the channel was force-closed, allowing users\nto know how many msats they lost due to rounding.\n-\nâ LND #8183 adds the optional CloseTxInputs field to the\nchanbackup.Single structure in the static channel backup (SCB) file, to store the inputs required to generate force-close\ntransactions. This allows users to manually retrieve funds when a peer\nis offline using the chantools scbforceclose command as a last-resort\nrecovery option. However, users should exercise extreme caution as this\nfeature could result in the loss of funds if the channel has been updated\nsince the backup was created. In addition, the PR introduces the\nManualUpdate method, which will update channel backups whenever LND shuts\ndown.\n-\nâ Rust Bitcoin #3450 adds v3 as a new variant of the transaction version,\nfollowing Bitcoin Coreâs acceptance of Topologically Restricted Until\nConfirmation (TRUC) transactions as standard (see\nNewsletter #307 )."}
{"url":"https://docs.polkadot.com/node-infrastructure/","domain":"docs.polkadot.com","title":"Node Infrastructure | Polkadot Developer Docs","hash":"7c701cdcfb1b2dea13cb753c61c9d007c8a116ea19c709480813cedf2693ce03","tokens":1169,"chars":4676,"crawler":"hive-genesis","verified":"exact","ts":1791112291229,"text":"Skip to content\nInitializing search\n- Concepts\n- Build\n- Deploy Your App\n- Register a .dot Domain\n- List Your App\n- Product SDK\n- Tutorials\n- Troubleshooting\n- Smart Contracts\n- Cookbook\n- Deploy an ERC-20\n- Deploy an NFT\n- Create a DApp\n- Port Ethereum DApps\n- Uniswap V3\n- Precompiles\n- Development Environments\n- Libraries\n- Integrations\n- Parachains\n- Customize Your Runtime\n- Test Your Runtime\n- Maintain and Upgrade Your Parachain\n- Enable Interoperability\n- Integrations\n- Chain Interactions\n- Send Transactions\n- Manage Tokens\n- Store Data\n- Manage Accounts\n- Node Infrastructure\n- Next Steps\n- Run a Node\n- Parachain RPC Node\n- Run a Validator\n- Operational Tasks\n- Staking Mechanics\n- Run a Collator\n- Tech Reference\n- Asset Management\n- Bridging\n- People and Identity\n- Collectives and DAOs\n- Data Storage\n- Parachains\n- Accounts\n- Blocks, Transactions, and Fees\n- Node and Runtime\n- Interoperability\n- Randomness\n- Cryptography\n- Data Encoding\n- Chain Data\n- Networks\n- On-Chain Governance\n- App Development\n- Polkadot Desktop\n- Polkadot Web\n- Protocol\n- Infrastructure\n- Statement Store\n- dotNS\n- Proof of Personhood\n- HOP\n- Skills\n- Glossary\n- Tools\n- AI Resources\n- Support\n- Policies\n- Next Steps\nPage actions\nEdit this page Report an issue\nNode Infrastructure Overview ¶\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nIntroduction ¶\nThe Polkadot network relies on various types of nodes to maintain security, provide data access, and produce blocks. This section covers everything you need to know about running infrastructure for the Polkadot ecosystem.\nWhether you want to provide RPC endpoints for applications, produce blocks for a parachain, or secure the relay chain as a validator, this guide will help you understand your options and get started.\nNode Types ¶\nRPC Nodes ¶\nRPC nodes provide API access to blockchain data without participating in consensus. They are essential infrastructure for:\n- Applications and dApps : Query blockchain state and submit transactions.\n- Block explorers : Index and display blockchain data.\n- Wallets : Check balances and broadcast transactions.\n- Development : Test and debug applications.\nRPC nodes can be run for both the relay chain and parachains, with varying levels of data retention:\n- Pruned nodes : Keep recent state and a limited number of finalized blocks. Suitable for most applications that only need the current state and recent history. More efficient in terms of storage and sync time.\n- Archive nodes : Maintain complete historical state and all blocks since genesis. Required for block explorers, analytics platforms, or applications that need to query historical data at any point in time.\nTransaction Broadcasting : RPC nodes play a crucial role in transaction submission and propagation. When a client submits a transaction via RPC methods like author_submitExtrinsic , the node validates the transaction format, adds it to its local transaction pool, and broadcasts it across the P2P network. Block producers (collators or validators) then pick up these transactions from their pools for inclusion in blocks. This makes RPC nodes the primary gateway for users and applications to interact with the blockchain.\nCollators ¶\nCollators are block producers for parachains. They perform critical functions:\n- Collect transactions : Aggregate user transactions into blocks.\n- Produce blocks : Create parachain block candidates.\n- Generate and package PoV : Generate the Proof-of-Validity containing the state transition proof and necessary witness data for validation.\n- Submit to validators : Send block candidates and PoVs to relay chain validators.\nUnlike validators, collators do not provide security guaranteesâthat responsibility lies with the relay chain validators. However, collators are essential for parachain liveness and censorship resistance.\nValidators ¶\nValidators secure the Polkadot relay chain through Nominated Proof of Stake (NPoS) . They:\n- Validate blocks : Verify parachain blocks and relay chain transactions.\n- Participate in consensus : Run BABE and GRANDPA protocols.\n- Earn rewards : Receive staking rewards for honest behavior.\n- Risk slashing : Face penalties for misbehavior or downtime.\nRunning a validator requires significant technical expertise, reliable infrastructure, and a stake of DOT tokens.\nNext Steps ¶\n-\nRun RPC Nodes\nProvide API access for applications, explorers, and wallets.\nRun a Node\n-\nRun a Collator\nProduce blocks for system parachains or your own parachain.\nRun a Collator\n-\nRun a Validator\nSecure the relay chain and earn staking rewards.\nRun a Validator\nLast update: September 23, 2026\n| Created: January 14, 2026"}
{"url":"https://bitcoinops.org/","domain":"bitcoinops.org","title":"Bitcoin Optech | Helping Bitcoin-based businesses integrate scaling technology.","hash":"f6814b44c9674708fb3f9f58e2b88c2f0e3de97f0d8ff4cd5586da4bc2b423ec","tokens":591,"chars":2361,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112291904,"text":"Bitcoin Optech helps Bitcoin users and businesses integrate scaling\ntechnologies.\nWe provide weekly newsletters , a podcast , case studies and\nannouncements , analyses of Bitcoin software and\nservices , workshops and help to facilitate improved relations between\nbusinesses\nand the open source community.\nLearn more about us .\nRecent newsletters, blog posts, and podcasts\n- Oct 2, 2026\nBitcoin Optech Newsletter #425\nThis weekâs newsletter summarizes the responsible disclosure of two\ndenial-of-service vulnerabilities affecting older versions of Eclair and\ndescribes a proposal for synchronizing wallet labels between devices\nthrough an untrusted store. Also included are our regular sections summarizing\nproposals and discussion about changing Bitcoinâs consensus rules, announcing\nnew releases and release candidates, and describing notable changes to popular\nBitcoin infrastructure software.\n- Sep 29, 2026\nBitcoin Optech Newsletter #424 Recap Podcast\nGustavo Flores Echaiz and Mike Schmidt are joined by Ahmet Kurt and Jan B to\ndiscuss Newsletter #424 .\n- Sep 25, 2026\nBitcoin Optech Newsletter #424\nThis weekâs newsletter describes a proposal for upgrading the offchain\nprotocols of the Lightning Network to post-quantum security. Also included are\nour regular sections with selected questions and answers from the Bitcoin\nStack Exchange, announcements of new releases and release candidates, and\ndescriptions of notable changes to popular Bitcoin infrastructure software.\n- Sep 22, 2026\nBitcoin Optech Newsletter #423 Recap Podcast\nMark âMurchâ Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by\nDavidson Souza, Eric Price, and PortlandHODL to discuss\nNewsletter #423 .\n- Sep 18, 2026\nBitcoin Optech Newsletter #423\nThis weekâs newsletter summarizes an analysis of mining pool difficulty\ncontrollers stranding slowed miners, describes a proposed improvement to\nUtreexoâs initial block download, and links to a draft BIP for specifying\nunspendable taproot internal keys. Also included are our regular sections\ndescribing recent changes to services and client software, announcing new\nreleases and release candidates, and describing notable changes to popular\nBitcoin infrastructure software.\nView more newsletters or blog posts . Learn about new content by subscribing via email or RSS .\nSupporters\nBitcoin Optech is generously supported by:\n-"}
{"url":"https://bitcoinops.org/cs/newsletters/2024/09/20/","domain":"bitcoinops.org","title":"Zpravodaj âBitcoin Optechâ Ä. 321 | Bitcoin Optech","hash":"ec4be45eb8a5b5a9be6982943c10cffba8d8cc9de00307f657bb88a1936af7d3","tokens":2329,"chars":9313,"crawler":"hive-genesis","verified":"unchecked","ts":1791112293388,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nZpravodaj âBitcoin Optechâ Ä. 321\nSep 20, 2024\nZpravodaj tento tĂœden odkazuje na implementaci ovÄĆenĂ konceptu generovĂĄnĂ\ndokladu s nulovou znalostĂ o pĆĂtomnosti vĂœstupu v mnoĆŸinÄ UTXO, popisuje\njeden novĂœ a dva pĆedchozĂ nĂĄvrhy na offline LN platby a shrnuje vĂœzkum\nDNS seedĆŻ pro ne-IP sĂĆ„ovĂ© adresy. TĂ©ĆŸ nechybĂ naĆĄe pravidelnĂ© rubriky\nsâŻpopisem zmÄn klientĆŻ a sluĆŸeb, oznĂĄmenĂmi novĂœch vydĂĄnĂ a souhrnem\nvĂœznamnĂœch zmÄn vâŻpopulĂĄrnĂm bitcoinovĂ©m pĂĄteĆnĂm software.\nNovinky\n-\nâ Doklad s nulovou znalostĂ o pĆĂtomnosti v mnoĆŸinÄ UTXO: Johan Halseth\nzaslal do fĂłra Delving Bitcoin pĆĂspÄvek ohlaĆĄujĂcĂ\nnĂĄstroj slouĆŸĂcĂ jako ovÄĆenĂ konceptu poskytovĂĄnĂ dokladu o kontrole\nnad nÄkterĂœm vĂœstupem v aktuĂĄlnĂ mnoĆŸinÄ UTXO, aniĆŸ by doklad identifikoval\nkonkrĂ©tnĂ vĂœstup. KoneÄnĂœm cĂlem je umoĆŸnit spoluvlastnĂkĆŻm vĂœstupu\nfinancujĂcĂho LN kanĂĄl prokĂĄzat jeho vlastnictvĂ bez odhalenĂ jakĂœchkoliv\ndalĆĄĂch informacĂ o jejich onchain transakcĂch. TakovĂœ doklad mĆŻĆŸe\nbĂœt pĆipojen ke zprĂĄvĂĄm oznamujĂcĂm kanĂĄly\nnovĂ© generace, kterĂ© jsou pouĆŸĂvĂĄny ke sbÄru informacĂ o LN pro\ndecentralizovanĂ© hledĂĄnĂ cest.\nMetoda je odliĆĄnĂĄ od aut-ct popsanĂ©m ve zpravodaji Ä. 303 ,\ndiskuze se mimo jinĂ© soustĆedĂ na objasnÄnĂ rozdĂlĆŻ mezi nimi. DalĆĄĂ vĂœzkum\nje nezbytnĂœ, sĂĄm Halseth popisuje nÄkolik nevyĆeĆĄenĂœch problĂ©mĆŻ.\n-\nâ LightningovĂ© offline platby: Andy Schroder zaslal do fĂłra Delving Bitcoin\npĆĂspÄvek s nĂĄÄrtem procesu, kterĂœm by mohla LN penÄĆŸenka\nvygenerovat tokeny, jeĆŸ by umoĆŸnily jinĂ© penÄĆŸence pĆipojenĂ© k internetu\nna ni provĂ©st platbu. NechĆ„ je v naĆĄem pĆĂkladu Alicina penÄĆŸenka\nbÄĆŸnÄ pĆipojena k jejĂmu online LN uzlu nebo k poskytovateli lightningovĂœch\nsluĆŸeb (LSP). ZatĂmco je Alice online, vygeneruje autentizaÄnĂ tokeny.\nPozdÄji, kdyĆŸ chce Alice zaplatit Bobovi, ale jejĂ uzel je offline,\nposkytne Bobovi autentizaÄnĂ token, kterĂœ mu umoĆŸnĂ pĆipojit se k jejĂmu\nonline uzlu Äi LSP a vybrat ÄĂĄstku urÄenou AlicĂ. Tento token mĆŻĆŸe Bobovi\npĆedat pĆes NFC Äi jinĂœ dostupnĂœ pĆenosovĂœ protokol, kterĂœ\npo Alici nevyĆŸaduje pĆipojenĂ k internetu. DĂky tomu mĆŻĆŸe tento protokol\nzĆŻstat jednoduchĂœ a dostupnĂœ i na zaĆĂzenĂch sâŻomezenĂœmi vĂœpoÄetnĂmi\nprostĆedky (napĆ. smart card).\nVĂœvojĂĄĆ ZmnSCPxj zmĂnil alternativnĂ pĆĂstup, kterĂœ jiĆŸ dĆĂve\npopsal, a Bastien Teinurier odkĂĄzal na svou metodu vzdĂĄlenĂ©ho\npĆĂstupu k uzlu pro podobnĂ© situace (viz zpravodaj Ä. 271 ).\n-\nâ DNS seedy pro ne-IP adresy: vĂœvojĂĄĆ Virtu zaslal do fĂłra\nDelving Bitcoin vĂœsledky prĆŻzkumu dostupnosti seedovĂœch uzlĆŻ v anonymizaÄnĂch\nsĂtĂch . TĂ©ĆŸ zapoÄal diskuzi o metodĂĄch, kterĂ©\numoĆŸĆujĂ uzlĆŻm pouĆŸĂvajĂcĂm vĂœhradnÄ tyto sĂtÄ objevit dalĆĄĂ uzly pomocĂ\nDNS seedĆŻ.\nBitcoinovĂœ uzel nebo P2P klient potĆebujĂ zjistit sĂĆ„ovĂ© adresy jinĂœch uzlĆŻ,\nod kterĂœch by mohly stahovat data. MĆŻĆŸe se stĂĄt, ĆŸe novÄ nainstalovanĂœ software\nnebo software, kterĂœ byl po dlouhou dobu offline, neznĂĄ sĂĆ„ovĂ© adresy ĆŸĂĄdnĂœch\naktivnĂch uzlĆŻ. Bitcoin Core bÄĆŸnÄ ĆeĆĄĂ tento problĂ©m dotazem na DNS seed,\nkterĂœ vrĂĄtĂ IPv4 nebo IPv6 adresy nÄkolika uzlĆŻ, kterĂ© zĆejmÄ budou dostupnĂ©.\nSelĆŸe-li pouĆŸitĂ DNS nebo je-li nedostupnĂ© (napĆ. u anonymizaÄnĂch sĂtĂ, kterĂ©\nIPv4 ani IPv6 nepouĆŸĂvajĂ), obsahuje Bitcoin Core sĂĆ„ovĂ© adresy uzlĆŻ,\nkterĂ© byly dostupnĂ© v dobÄ vydĂĄnĂ. Tyto uzly jsou pouĆŸity jako seedovĂ©\nuzly , od kterĂœch uzel zĂskĂĄ dalĆĄĂ adresy. DNS seedy majĂ pĆed seedovĂœmi\nuzly pĆednost, neboĆ„ jejich data jsou obvykle ÄerstvÄjĆĄĂ a cachovacĂ\ninfrastruktura globĂĄlnĂho DNS umĂ zabrĂĄnit, aby se DNS seeder dozvÄdÄl sĂĆ„ovĂ©\nadresy dotazujĂcĂch se uzlĆŻ.\nVirtu prozkoumal seedovĂ© uzly obsaĆŸenĂ© v poslednĂch ÄtyĆech hlavnĂch vydĂĄnĂch\nBitcoin Core a zjistil, ĆŸe jich je stĂĄle dostupnĂ© vyhovujĂcĂ mnoĆŸstvĂ.\nUĆŸivatelĂ© anonymizaÄnĂch sĂtĂ by tak mÄli bĂœt schopni dalĆĄĂ uzly nalĂ©zt.\nSpolu s dalĆĄĂmi ĂșÄastnĂky diskuze dĂĄle prozkoumali moĆŸnost takovĂ© Ășpravy Bitcoin\nCore, kterĂĄ by mu umoĆŸnila pouĆŸĂt DNS seedy pro anonymizaÄnĂ sĂtÄ buÄ s pouĆŸitĂm\nDNS NULL zĂĄznamĆŻ nebo zakĂłdovĂĄnĂm alternativnĂch sĂĆ„ovĂœch adres do rĂĄdoby IPv6\nadres.\nZmÄny ve sluĆŸbĂĄch a klientech\nV tĂ©to mÄsĂÄnĂ rubrice upozorĆujeme na zajĂmavĂ© aktualizace bitcoinovĂœch\npenÄĆŸenek a sluĆŸeb.\n-\nâ Strike pĆidĂĄvĂĄ podporu pro BOLT12:\nStrike ohlĂĄsil podporu BOLT12 nabĂdek\nvÄetnÄ pouĆŸĂvĂĄnĂ nabĂdek s DNS platebnĂmi instrukcemi dle BIP353 .\n-\nâ BitBox02 pĆidĂĄvĂĄ podporu tichĂœch plateb:\nBitBox02 ohlĂĄsil podporu tichĂœch plateb a implementaci ĆŸĂĄdostĂ o platbu .\n-\nâ VydĂĄn The Mempool Open Source Project v3.0.0:\nVydĂĄnĂ v3.0.0 obsahuje mimo jinĂ© novĂœ zpĆŻsob vĂœpoÄtu\nCPFP poplatkĆŻ, novĂ© funkce kolem RBF vÄetnÄ podpory\nfullrbf, podporu pro P2PK a novĂ© moĆŸnosti analĂœzy mempoolu a blockchainu.\n-\nâ VydĂĄn ZEUS v0.9.0:\nBlogovĂœ pĆĂspÄvek o v0.9.0 hovoĆĂ o novĂœch LSP funkcĂch,\npenÄĆŸenkĂĄch umoĆŸĆujĂcĂ pouze sledovĂĄnĂ, podpoĆe hardwarovĂœch podpisovĂœch zaĆĂzenĂ,\npodpoĆe pro dĂĄvkovĂĄnĂ transakcĂ vÄetnÄ transakcĂ pro\notevĂrĂĄnĂ kanĂĄlĆŻ a dalĆĄĂch novinkĂĄch.\n-\nâ Live Wallet pĆidĂĄvĂĄ podporu konsolidacĂ:\nAplikace Live Wallet analyzuje nĂĄklady na Ăștratu skupiny UTXO s rĆŻznĂœmi poplatky\nvÄetnÄ zjiĆĄtÄnĂ, kterĂ© vĂœstupy by byly neekonomickĂ© .\nVydĂĄnĂ 0.7.0 pĆinĂĄĆĄĂ funkce pro simulaci\nkonsolidaÄnĂch transakcĂ a generovĂĄnĂ konsolidaÄnĂch PSBT .\n-\nâ Bisq pĆidĂĄvĂĄ podporu Lightningu:\nBisq v2.1.0 dĂĄvĂĄ uĆŸivatelĆŻm moĆŸnost vyrovnat obchody pĆes Lightning\nNetwork.\nVydĂĄnĂ novĂœch verzĂ\nVydĂĄnĂ novĂœch verzĂ oblĂbenĂœch pĂĄteĆnĂch bitcoinovĂœch projektĆŻ. ProsĂme,\nzvaĆŸte upgrade Äi pomoc s testovĂĄnĂm.\n-\nâ HWI 3.1.0 je vydĂĄnĂm novĂ© verze tohoto balĂÄku poskytujĂcĂho jednotnĂ©\nrozhranĂ pro pĆĂstup kâŻrozliÄnĂœm hardwarovĂœm podpisovĂœm zaĆĂzenĂm.\nToto vydĂĄnĂ pĆinĂĄĆĄĂ podporu Trezor Safe 5 a nÄkolik dalĆĄĂch vylepĆĄenĂ a\noprav chyb.\n-\nâ Core Lightning 24.08.1 je ĂșdrĆŸbovĂœm vydĂĄnĂm, kterĂ© opravuje pĂĄdy a dalĆĄĂ chyby\nobjevenĂ© vâŻnedĂĄvnĂ©m vydĂĄnĂ 24.08.\n-\nâ BDK 1.0.0-beta.4 je kandidĂĄtem na vydĂĄnĂ tĂ©to knihovny pro budovĂĄnĂ penÄĆŸenek\na jinĂœch bitcoinovĂœch aplikacĂ. PĆŻvodnĂ rustovĂœ balĂÄek bdk byl pĆejmenovĂĄn\nna bdk_wallet a moduly niĆŸĆĄĂ ĂșrovnÄ byly extrahovĂĄny do samostatnĂœch balĂÄkĆŻ:\nbdk_chain , bdk_electrum , bdk_esplora a bdk_bitcoind_rpc . BalĂÄek\nbdk_wallet âje prvnĂ verzĂ nabĂzejĂcĂ stabilnĂ 1.0.0 API.â\n-\nâ Bitcoin Core 28.0rc2 je kandidĂĄtem na vydĂĄnĂ pĆĂĆĄtĂ hlavnĂ verze tĂ©to pĆevlĂĄdajĂcĂ\nimplementace plnĂ©ho uzlu. K dispozici je prĆŻvodce testovĂĄnĂ .\nVĂœznamnĂ© zmÄny kĂłdu a dokumentace\nVĂœznamnĂ© zmÄny z tohoto tĂœdne v Bitcoin Core , Core\nLightning , Eclair , LDK ,\nLND , libsecp256k1 , Hardware Wallet\nInterface (HWI) , Rust Bitcoin , BTCPay\nServer , BDK , Bitcoin Improvement\nProposals (BIPs) , Lightning BOLTs ,\nBitcoin Inquisition a repozitĂĄĆi BINANA .\nPoznĂĄmka: commity do Bitcoin Core zmĂnÄnĂ© nĂĆŸe se vztahujĂ na jeho master vĂœvojovou\nvÄtev. Tyto zmÄny pravdÄpodobnÄ nebudou vydĂĄny do doby kolem ĆĄesti mÄsĂcĆŻ od vydĂĄnĂ\npĆipravovanĂ© verze 28.\n-\nâ Bitcoin Core #28358 odstraĆuje dbcache limit, protoĆŸe stĂĄvajĂcĂ hodnota\n16âŻGB jiĆŸ nedostaÄuje na dokonÄenĂ prvotnĂho staĆŸenĂ blokĆŻ (Initial Block Download,\nIBD) bez potĆeby zapsat mnoĆŸinu UTXO zâŻpamÄti na disk (coĆŸ mĆŻĆŸe proces urychlit o zhruba 25âŻ%). OdstranÄnĂ bylo upĆednostnÄno pĆed navĂœĆĄenĂm hodnoty,\nprotoĆŸe neexistuje optimĂĄlnĂ hodnota, kterĂĄ by byla spolehlivÄ pouĆŸitelnĂĄ\ni vâŻbudoucnosti a poskytla uĆŸivatelĆŻm maximĂĄlnĂ flexibilitu.\n-\nâ Bitcoin Core #30286 optimalizuje algoritmus hledĂĄnĂ kandidĂĄtĆŻ bÄhem linearizace\nclusterĆŻ, kterĂœ je zaloĆŸen na popisu zâŻdruhĂ© ÄĂĄsti pĆĂspÄvku\nna fĂłru Delving Bitcoin. Tato vylepĆĄenĂ dosahujĂ lepĆĄĂho vĂœkonu dĂky snĂĆŸenĂ poÄtu\niteracĂ, avĆĄak za cenu navĂœĆĄenĂ doby spuĆĄtÄnĂ a nĂĄkladĆŻ na jednu iteraci.\nJednĂĄ se o souÄĂĄst projektu cluster mempoolu . Viz tĂ©ĆŸ\nzpravodaj Ä. 315 .\n-\nâ Bitcoin Core #30807 mÄnĂ zpĆŻsob signalizace uzlu, kterĂœ na pozadĂ prĂĄvÄ provĂĄdĂ\nsynchronizaci blockchainu v rĂĄmci assumeUTXO . NamĂsto pĆŻvodnĂ\nhodnoty NODE_NETWORK bude novÄ pouĆŸito NODE_NETWORK_LIMITED , aby spojenĂ nepoĆŸadovala\nbloky starĆĄĂ neĆŸ zhruba jeden tĂœden. TĂm se opravuje chyba, kterĂĄ zpĆŻsobovala odpojenĂ\nassumeUTXO uzlu potĂ©, co od nÄj na ĆŸĂĄdost o historickĂœ blok nepĆiĆĄla ĆŸĂĄdnĂĄ odpovÄÄ.\n-\nâ LND #8981 zuĆŸuje pouĆŸitĂ paymentDescriptor pouze na modul lnwallet . PozdÄji\nbude paymentDescriptor nahrazen novou strukturou LogUpdate , ÄĂmĆŸ se zjednoduĆĄĂ\nzpracovĂĄnĂ a logovĂĄnĂ zmÄn. PR je souÄĂĄstĂ snahy o implementaci dynamickĂœch\ncommitmentĆŻ jako typu upgradu commitmentĆŻ kanĂĄlu .\n-\nâ LDK #3140 pĆidĂĄvĂĄ podporu placenĂ statickĂœch BOLT12 faktur\npro posĂlĂĄnĂ asynchronnĂch plateb uzly, kterĂ© jsou vĆŸdy online,\ndle definice v BOLTs #1149 . ĆœĂĄdost o fakturu nenĂ v onion zprĂĄvÄ obsaĆŸena. PĆijĂmĂĄnĂ asynchronnĂ plateb ani jejich posĂlĂĄnĂ uzly,\nkterĂ© jsou Äasto offline, nenĂ zatĂm podporovĂĄno.\n-\nâ LDK #3163 pĆidĂĄvĂĄ do zaslanĂ© BOLT12 faktury reply_path , coĆŸ plĂĄtci umoĆŸnĂ\nv pĆĂpadÄ potĆeby poslat pĆĂjemci chybovou zprĂĄvu.\n-\nâ LDK #3010 dĂĄvĂĄ uzlu novÄ moĆŸnost opakovat zaslĂĄnĂ ĆŸĂĄdosti o fakturu jako odpovÄdi\nna nabĂdku , pokud jeĆĄtÄ odpovĂdajĂcĂ fakturu neobdrĆŸel.\n-\nâ BDK #1581 upravuje algoritmus vĂœbÄru mincĂ moĆŸnostĂ\nnastavit zĂĄloĆŸnĂ algoritmus u strategie BranchAndBoundCoinSelection (metoda vÄtvĂ\na mezĂ). Signatura metody coin_select novÄ umoĆŸĆuje pĆedat generĂĄtor nĂĄhodnĂœch\nÄĂsel. DĂĄle PR pĆinĂĄĆĄĂ nÄkolik dalĆĄĂch zmÄn a zjednoduĆĄenĂ naklĂĄdĂĄnĂ sâŻchybami.\n-\nâ BDK #1561 odstraĆuje z projektu balĂÄek bdk_hwi za ĂșÄelem zjednoduĆĄenĂ\nzĂĄvislostĂ a CI. bdk_hwi obsahoval HWISigner , kterĂœ byl pĆemĂstÄn do projektu\nrust_hwi ."}
{"url":"https://docs.lightning.engineering/the-lightning-network/l402/l402.md","domain":"docs.lightning.engineering","title":"L402","hash":"1c87c1d78cc5e04f40c12f7cc36d5e1804a097423aacc86edfda07e51c03b46e","tokens":1699,"chars":6793,"crawler":"hive-genesis","verified":"unchecked","ts":1791112294972,"text":"> For the complete documentation index, see [llms.txt](https://docs.lightning.engineering/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lightning.engineering/the-lightning-network/l402/l402.md).\n# L402\nLightning API keys (L402) are Macaroons that include a payment hash. For the L402 to be valid, it must be presented together with the preimage corresponding to the payment hash.\nLightning API keys (L402) leverage the capabilities of Macaroons and the programmatic characteristics of the Lightning Network to create a mechanism that allows distributed systems to authenticate a user and payment receipt. This authentication occurs without requiring access to a central database of users or invoices.\nL402 are a cornerstone to building metered APIs for the machine-to-machine economy, without logins, e-mail addresses or passwords.\nAn L402 is a Macaroon together with the preimage of a Lightning Network payment. The Macaroon is transmitted to the user over HTTP together with a Lightning invoice and contains the payment hash of the invoice as a caveat.\nTo be a valid L402, the user needs to present two pieces of information:\n* The partial L402, being the Macaroon including the payment hash\n* The preimage, which can be obtained by paying the Lightning invoice\nAs the payment hash is a hash of the preimage, and as the preimage can only be obtained through paying the Lightning invoice in full, it is easy for anyone with the root key to verify:\n* That the L402 was issued by the appropriate authority\n* That the L402 carries the relevant capabilities\n* That the Lightning invoice has been paid\n| secret,id12345678id,api.domain.com,your macaroon |\n| ------------------------------------------------------------------------------ |\n| payment\\_hash=1107feb30b42fd1a1648c9862006452a8092baa3b62fc474cb43bf42066a0b06 |\n| HMAC(secret,4c4ab7a4f7a9,api.domain.com,your macaroon) |\n| preimage=79852a0791225dee00be0a6cf31a1619782c21d35995e118bfc74ad812174035 |\n## L402 specification\nTo make for a valid L402, a Macaroon must adhere to the following characteristics:\nVersion - A version allows for an iterative macaroon design.\n`identifier:`\\\n`version = 0`\nUser Identifier - A unique user identifier allows services to track users across distinct macaroons serving useful in the context of service level metering. A user identifier of 32 random bytes is used instead of the macaroonâs identifier because the latter can be revoked, e.g., in the case of a service tier upgrade.\n`identifier:`\\\n`user_id = fed74b3ef24820f440601eff5bfb42bef4d615c4948cec8aca3cb15bd23f1013`\nPayment Hash - A payment hash links an invoiceâs payment request to the macaroon. Once the payment request is fulfilled, the payer receives its corresponding preimage as proof of payment. This proof can then be provided along with the macaroon to ensure an L402 has been paid for without checking whether the invoice has been fulfilled.\n`identifier:`\\\n`payment_hash = 163102a9c88fa4ec9ac9937b6f070bc3e27249a81ad7a05f398ac5d7d16f7bea`\n### Caveats\nThere is no limit to what caveats you may define for your service. For Lightning Labs services, three types of caveats are used, which are covered below. Each caveat consists of a key and value pair, separated by an equal (=) sign.\n#### Target Services\nThe caveat âservicesâ lists which services a L402 is authorized to access. This can be a comma separated list of multiple services, as well as their tier. Tiers allow for separate levels of access, with the basic tier being 0.\nIn this example the L402 is authorized to access Lightning Loop at tier 0:\n`caveats:`\\\n`services = lightning_loop:0`\n#### Service Capabilities\nEach service can be restricted in its capabilities. These caveats have â`_capabilities`â amended to the service name, followed by a comma separated list of capabilities that the holder of the L402 is allowed to access. If this caveat is not present, the holder has full access to the service. If multiple caveats of this service capability exist in the same L402, each caveat must be more restrictive than the previous one.\nIn this example the bearer of the L402 is authorized to access both Loop Out and Loop In:\n`caveats:`\\\n`lightning_loop_capabilities = loop_out,loop_in`\n#### Service Constraints\nEach service capability can be further constrained. This is recorded as a separate caveat beginning with the service capability. Similar to capabilities, multiple constraints may be present in a L402, but each constraint needs to be more restrictive than the previous.\nIn the following example the user is allowed to Loop out two million satoshis per month only:\n`caveats:`\\\n`loop_out_monthly_volume_sats = 2000000`\n## L402 Verification \nIn verifying the L402, the server requires the root key with which the original Macaroon was created. This allows the server to verify, line by line, caveat by caveat, that the Macaroon was issued by the appropriate authority and that each caveat was properly amended.\nFinally, the preimage is verified against the payment hash to ensure that all outstanding invoices have been paid.\n[Learn how the L402 is obtained in Pool](https://github.com/lightninglabs/pool/blob/master/server.go#L504)\n{% content-ref url=\"/pages/QRE4vENcmsPMaDM9WAfi\" %}\n[Get Aperture](/lightning-network-tools/aperture/get-aperture.md)\n{% endcontent-ref %}\n---\n# Agent Instructions\nThis documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.\n## Querying This Documentation\nIf you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.\nPerform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:\n```\nGET https://docs.lightning.engineering/the-lightning-network/l402/l402.md?ask=&goal=\n```\n`ask` is the immediate question: it should be specific, self-contained, and written in natural language.\n`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.\nThe response will contain a direct answer to the question and relevant excerpts and sources from the documentation.\nUse this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections."}
{"url":"https://research.lido.fi/t/lido-dao-vibe-alignment-purpose-mission-vision/4380","domain":"research.lido.fi","title":"Lido DAO: Vibe alignment (Purpose, Mission, Vision) - General - Lido Governance","hash":"c7df91fe3b438c86d2b6527d7c7cd888305dc119898663c8f13b757e2f418f71","tokens":6521,"chars":26084,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112294209,"text":"Lido Governance\nLido DAO: Vibe alignment (Purpose, Mission, Vision)\nGeneral\nsacha\nApril 12, 2023, 11:47am\n1\nBuilding blocks: Mission, Vision, Purpose, Guiding principles\nThese building blocks should be collectively defined by all Lidoâs stakeholders. It is not for me, or any single individual, to determine what should or shouldnât go into it. The best I can do is to humbly offer my suggestions and recommendations, and in doing so hopefully pave the way for a more fruitful discussion.\nI know we all have our jobs, but that has to come from a deeper sense of purpose. You have to be driven by something. Leadership is not just about giving energy; itâs unleashing other peopleâs energy, which comes from buying into that sense of purpose.\nâ Paul Polman\nCall to action\nFollowing multiple discussions with long-time Lido DAO contributors and my own understanding of the landscape, these are the purpose, mission, and vision statements (see here for definitions) that I feel we have the most consensus on so far:\nPurpose (why): Keep Ethereum decentralized, accessible to all, and resistant to censorship.\nMission (how): Make staking simple, secure, and decentralized.\nVision (where): A world in which Ethereum is the co-ordination and value layer of the internet.\nSome questions that I think we should continue debating as part of this forum discussion:\n- Do these statements ring true to all of us?\n- Does it make sense to focus so tightly on Ethereum?\n- Are we willing to do the hard work to internalise this purpose and make everything we do feel true to this core?\nAs I mention below , purpose can be reflexive, in the sense that it can push us, as a DAO, to be better. But thereâs no free lunch. Doing so takes time. It requires a lot of hard and consistent work (an aspirational purpose needs to be embedded into the culture through consistent and frequent communication). If we arenât prepared to do this, then it will feel shallow and inauthentic.\nSo the main question in my mind here is not whether or not the DAOâs current purpose is bigger than staking, but whether thereâs an appetite for it to be bigger. And if so, whether weâre willing to do the hard work to manifest it. To me it feels like the appetite is there, but this is something that needs group commitment.\nHow did we get here?\nMotivation\nGovernance arc\nThe substance of a DAOâs constitution (its raison-dâetre) should ideally come before the governance framework/design (the next port of call).\nThis is because the right governance framework (e.g. process and tools) is fundamentally dependent on what we plan to govern (and setting bounds on this is essentially the role of a constitution).\nPut another way, governance happens primarily within the boundaries that the substance of a constitution gives shape to. But what exactly does the substance mean?\nThe substance, for the purposes of this document, is the animating purpose coupled with the mission / vision / values / guiding principles that make Lido what it is. You can think of it as a pre-formal social contract of sorts.\nOnce we have consensus over this foundation, we can start working out a functional architecture for a general governance framework, followed by the process and tools required to fulfil all the required functions in the functional architecture.\nCommunications / product arc\nToday, there is an increasing acknowledgement that purpose defines both the direction of the organisation and its course, rather than simply messaging.\nGoing forward, we can expect purpose to only increase in importance as people look for greater meaning, greater understanding, and greater clarity on the organisation they work for, the organisations they engage with, and the brands and services they use.\nRather than fitting a brand around a product, the strongest brands of tomorrow are building capabilities around a brand truth â the overarching promise or positive ideology that the brand has the credibility to enact (a credibility derived from the authentic expression of the organizationâs purpose).\nUnder such an approach, the brand effectively acts as a central organizational principle â the truth which brings everything together (therein lies the link between purpose, brand, and organisational design).\nIn sum, without a deep understanding of the DAOâs purpose, as well as how to authentically express it (mission / vision / guiding principles), it is impossible to effectively communicate our brand truth; this in turn compromises our ability to build the most authentic product.\nThe next port of call on the internal communications front is to build out a brand platform and strategy around the truths contained in this document.\nDefinitions\nPurpose is sometimes used interchangeably with Vision and Mission, which is wrong and can be very confusing. This was perhaps understandable a decade or two ago, as the language reflected an emerging set of thinking, but this should no longer be the case.\nThe interpretation and inter-relation between these three definitions is now accepted, even though many organisations do not yet fully appreciate it.\nPurpose: WHY the business exists, contributing something positive to people, and/or the planet. This should be short, memorable and aspirational.\nVision: WHERE the business is heading, with a view of the world envisaged as being created by being successful in its purpose. This can be both a vision of the world and a vision of where the business is within that world.\nMission: WHAT the business will do to achieve its purpose over a specified period of time. This can be seen as the specific strategy, the actions and operations which the business will conduct over a set period of time.\nPurpose\nWHY Lido exists (what is our animating purpose?)\n:::\nSynthesis: Keep Ethereum decentralized, accessible to all, and resistant to censorship.\n:::\nThe above purpose is intimately tied to our vision of Ethereum as the economic and co-ordination layer of the internet. It focuses on the properties that are necessary to bring this vision to life.\nSince culture necessarily emanates from initial visionaries (for better or worse), the first challenge here was coming up with a synthesis between Konstantin and Vasiliyâs views of the world. Something which would feel meaningful to both of them.\nHere are some relevant notes from those discussions:\nKâs Why\nA world of equal opportunity, freer and fairer systems, an incorruptible currency for all humans.\nCurrent state of things is not fair.\nVâs Why\nCo-ordination without violence, credible neutrality, a global mechanism for credible pre-commitments.\nCurrent state of things means no good way of enforcing agreements without violence. Need the digital equivalent of laws of nature.\nFor the first time we can have regulation by technology which enables software to be a protector and democratizer\nLido as protector\nThis beautiful line came out of a discussion with V:\nLido has a duty to keep the lights on for everyone.\nV views Lido functionality as very much a protector/guardian of credible neutrality. A credibly neutral co-ordination layer is important because it gives birth to the digital equivalent of natural laws. This is such a fragile and difficult thing to achieve, that we have a duty to protect it.\nIn a sense this at the heart of Lidoâs story so far, starting with protecting Ethereum against CEX capture (while counterfactuals are always difficult, in the absence of Lido launching when it did itâs not hard to imagine a present in which Ethereumâs security layer has been captured by centralized exchanges).\nLido as democratizer\nWhile this notion of democratization (âaccessible to allâ) felt like an emergent property to some, an important number of people didnât feel that way. So it was important to make this property explicit.\nMission\nWHAT Lido will do to achieve its purpose over a specified period of time (specific strategy)\n:::\nSynthesis: Make staking simple, secure, and decentralized.\n:::\nSome relevant notes:\n-\nLido DAO is committed to liquid staking first and foremost; this is the current focus and where the main strength lies.\n-\nThere was a long discussion on whether or not to include the word âsecureâ. The rationale for including it is explained here .\n-\nThere is a tradeoff between repetitiveness and simplicity. Both the Purpose and Mission statements have the word decentralized in them. Thatâs ok.\n-\nItâs definitely ok for a mission statement to be more specific than a purpose statement. For comparison, Telsaâs mission statement last decade was : Bring compelling mass market electric cars to market as soon as possible.\n-\nIf we dig down, our current mission actually has three parts: Make staking simple, deliver the best validator set, and reduce protocol governance risk.\nImportantly, mission statements are not necessarily set in stone. They are expected to evolve as an organisation grows (note that this is in contrast to Purpose). For example, Patagonia recently updated itâs mission statement\nfrom:\nBuild the best product, cause no unnecessary harm, use business to inspire and implement solutions to the environmental crisis.\nto:\nWeâre in business to save our home planet.\nAfter having been led by the original statement for over 45 years, it made sense for them to do this in order to reflect the fact that the company had grown into a more integrated firm with a larger vision (a world in which nature prospers).\nInspiration:\nGoogle:\nto organize the worldâs information and make it universally accessible and useful\nPatagonia (see above)\nApple:\nTo bring the best user experience to its customers through its innovative hardware, software, and services.\nVision\nWHERE Lido DAO? is heading (can be both a vision of the world and a vision of where Lido sits within that world)\n:::\nSynthesis: A world in which Ethereum is the co-ordination and value layer of the internet.\n:::\nThe words co-ordination and value surfaced as particularly important. As summarised by these complementary comments from two long-time contributors:\nContributor: value is the source from which everything else springs; without co-ordination there is no value.\nContributor: we choose to co-ordinate around things that are valuable.\nOne question that has come up after settling on this synthesis is whether the vision should be augmented to describe what such a world looks like. In other words, what has improved concretely if this vision comes to fruition? One angle could be greater economic freedom (âraising economic freedom everywhereâ). My concern is that it might prove impossible to get consensus on a concise statement here, since Ethereum means a slightly different thing to each one of us.\nAnother question thatâs come up is whether or not we should include a vision of where Lido DAO sits within this world.\nInspiration:\nApple:\nTo make the best products on earth and to leave the world better than we found it.\nGoogle:\nTo provide access to the worldâs information in one click.\nGuiding questions\nThe first discussion with contributors brought to the surface the following questions:\n- Is it ok for a Purpose statement to be general?\n- Is our Purpose statement meaningful enough?\n- Is it ok for the Purpose to be larger than whatâs been driving us so far?\n- Should we express our commitment to security in the mission statement?\nIs it ok for a Purpose statement to be general?\nThe short answer here is, yes.\nA great example of a âgeneral purposeâ company is Microsoft. Their purpose after the arrival of CEO Satya Nadella was defined as follows:\nTo empower every person and organization on this planet to achieve more\nSome more examples:\nIkea: To create a better everyday life for the many people\nBlackRock: To help more and more people experience financial well-being\nTelsa: We exist to accelerate the planetâs transition to sustainable energy\nLego: To inspire and develop the builders of tomorrow\nAirbnb: We help people to belong anywhere\nThe most important thing here is that it feels authentic. Do the words resonate? Does it allow room for an organization to grow?\nA good purpose statement needs to feel at the same time lofty but meaningful. Itâs a very hard balance to strike.\nA good purpose statement needs to be aspirational but not vague. It needs to be precise but not limiting, allowing room for a company to grow.\nIs the Purpose statement meaningful enough?\nSome contributors felt that there was something missing from the statement. Something thatâs specific to the DAOâs soul.\nSome relevant comments from contributors:\nâOne thing I love about the Lido protocol is that it enables ANYONE regardless of economic status to participate in securing the Ethereum network. That in and of itself is very democratic, fair and a reason I sense many small Eth holders really appreciate the protocol.â\nâItâs really about democratising access and participation in the system of Ethereum, which is a system that is meant to be decentralized and censorship-resistant.â\nâYeah I dig the democatizing angle. Itâs emergent for me personally (itâs democratic because it has to be to work). But it can be core.â\nInterestingly, this concern was also mirrored in the discussion on Mission.\nSummary of comments:\nDemocratisation is an important property of what we are doing.\nSimple is not enough because it doesnât necessarily imply open.\nSimple does not necessarily mean itâs accessible.\nDemocratisation = Simplicity + Accessibility\nItâs clear there was something missing here.\nTaking all the above into account, my recommendation was that we update our Purpose to reflect this commitment to democracy and accessibility, while keeping mission the same.\nCan the Purpose be larger than the activities to date?\nThe short answer is yes. Itâs not necessary, but itâs ok.\nOne of the most remarkable examples of completely transforming around a higher purpose is the story of Microsoft.\nUpon becoming CEO, Satya spent the better part of the first five months with his direct reports asking some pretty fundamental questions about what the purpose of the company should be. They landed on these words :\nTo empower every person and organization on this planet to achieve more\nIn the words of Chris Capossela (Microsoftâs CMO):\nI think that was the starting gun for a lot of change at the company. Over the past five years, we havenât changed the words. All weâve done is to try to dig deeper into an understanding of what the words mean and how to bring it to life for our employees and for our customers.\nThe next phase involved embedding it into the culture through consistent communication, reflecting the time it takes to become a living, breathing part of the organization.\nWeâve repeated it at every speech Satya has given, you hear people talk about it all the time in the halls. I donât think that gets done in a week. I think it takes a long time to really own every word, and Iâm glad we took the time to make that.\nWhat this shows is that purpose can be reflexive, in the sense that it can push you, as an organisation, to be better.\nBut this doesnât happen without considerable work.\nManifestation of Purpose takes time.\nTo ground this back to our reality, the first discussion with long-time contributors brought up a disagreement as to whether or not Lidoâs purpose is bigger than staking.\nContributor: Itâs too premature to say itâs bigger. Staking is at the core of Lido, because that is the way it wants to democratise participation to this ecosystem⊠if we want to morph into an org that has a more abstract purpose, then we need to make this philosophy part of our day to day. Right now we donât think or act in those terms.\nContributor: Thatâs largely but not entirely true - we float ideas⊠[along those lines] pretty regularly It never makes it into concrete plans but itâs there.\nTo re-iterate, purpose can be reflexive, in the sense that it can push us, as an organisation, to be better. But thereâs no free lunch. Doing so takes time. It requires a lot of hard and consistent work (an aspirational purpose needs to be embedded into the culture through consistent and frequent communication). If we arenât prepared to do this, then it will feel shallow and inauthentic.\nSo the question in my mind here is not whether or not Lido DAOâs current purpose is bigger than staking, but whether thereâs an appetite for it to be bigger. And if so, whether weâre willing to do the work to manifest it. It feels like there is, but this is something we all need to commit to.\nShould we express our commitment to security in the mission statement?\nContributor: a commitment to security is obvious to us, but itâs not necessarily obvious to everyone.\nItâs part of our DNA that we prefer doing 5 audits over a couple more integrations (or launching earlier for Shapella).\nWhile there was general agreement that security is part of our DNA, the disagreement hinged on whether or not it should be expressed implicitly or explicitly.\nThere was a notable difference in approach here.\nContributor: You can show security without necessarily saying it.\nContributor: Why do folks choose Lido? because of security.\nSince many people choose Volvo because of their commitment to safety, much of the discussion involved understanding how Volvo communicates this commitment (is it implicit or explicit?).\nIt turns out that Volvo cars (a subsidiary of Volvo group) does communicate it explicitly.\nIn particular, their mission is to make life easier, better and safer for everyone.\nWe have made it our mission to make life easier, better and safer for everyone.\nFor a better future. We want to provide you with the freedom to move in a personal, sustainable and safe way.\nSafe is one of their three key words : Personal, sustainable, safe.\nSafe\nWe make cars for people who care about other people. So when it comes to safety, we think just as much about your surroundings as we do about you and your passengers.\nMany of the key phrases they use throughout their initiative re-iterate this:\nCars should protect everyone.\nSome people are less safe on the road than others. Thatâs why itâs time to share more than 40 years of safety research â to make cars safer for everyone. Not just the average male.\nThe seat that reduces whiplash risk by half\nThe most effective lifesaver in traffic.\nVolvoâs co-founder, Gustaf Larson considers safety to be the guiding principle:\nCars are driven by people. The guiding principle behind everything we make at Volvo therefore is, and must remain, safety.\nVolvo has even taken the time to articulate a specific safety vision .\nAiming for zero\nOur Safety Vision is one of the most ambitious safety visions in the automotive industry. It is rooted in our leadership in safety and the fact that everything we do starts with protecting the people inside and around our cars. Our aim is that no one should be killed or seriously injured in a new Volvo. While we are proud of what we have achieved so far, we are not satisfied yet.\nItâs important to note that putting emphasis on safety in the mission statement, does not mean Volvo considers its safety to be perfect. It does not mean nobody dies in a Volvo car.\nVolvo specifically articulates âThree gaps to zeroâ in their safety vision: speeding, intoxication, distraction.\nWhile we have come a long way, there are still a few obstacles on the road to zero fatalities in our cars. More specifically, our safety experts have identified three âgaps to zeroâ that we will address striving for our Safety Vision\nWhat it does mean is that they consider improving car safety to be a core part of their mission. Zero fatalities in Volvo cars is a North star.\nTaking all this into account, my recommendation is that we keep the emphasis on security in our mission statement.\nLido DAO takes tail-risks seriously and puts security first. That doesnât mean itâs perfect, but a commitment to always putting security first is a core part of its DNA.\nNext steps\nThe hope is that posting this on the forum opens up the door to a fruitful long-form discussion around the call to action listed at the start of this post . After a period of time has elapsed, these thoughts will then be synthesized into a follow-up post which will mark the beginning of a DAO vote on the matter.\nAddendum: Guiding principles (WIP)\nN.B. These principles arenât within the scope of the debate at this stage. Iâve included them here to offer a glimpse into the direction weâre heading in.\nMental model: a new contributor should feel free to do what they think is best for the DAO, subject to these principles.\nItâs important to note that these are guiding principles, not operating principles. Some are abstract and hard to operationally pin down â and thatâs ok. A great Constitution will always contain both â in fact, social schelling points which are impossible to turn into operating rules are of particular importance (but that is the subject for another post).\nBelow is an attempt to distil Lido DAOâs essence into a set of guiding principles. These principles have so far primarily come out of discussions with K, V, and H.\nA contributor has voiced a valid concern that âTreat others how you would like to be treated (with respect)â feels out of place, since itâs the only principle that is centered around the human aspect. A question worth reflecting on: Is this the only principle that matters on this front? Or should we spin this out into a separate set of human-centric principles?\nWhile some of these may feel abstract at the moment, the plan is to flesh them out with concrete examples from the DAOâs past. In particular, the examples should give us a feel for what the outcomes have looked like when weâve violated these principles vs what have the outcomes looked like when weâve adhered to them.\n-\nSelf-regulate through technology and incentives, not laws and promises.\n-\nMinimise root-level governance, and favour solutions which push power and compexity to the edges.\n-\nFavour long-term over short-term games.\n-\nIncrease Ethereumâs technical, geographical, and jurisdictional resilience.\n-\nDonât detract from Ethereumâs ability to resist or recover from an attack.\n-\nBuild products that are simple, composable, and mistake-proof.\n-\nOnly do things that have a reasonable chance of being best-in-class.\n-\nEmbrace radical transparency and seek-out constructive feedback from believable people.\n-\nBe scrupulously truthful even if the truth is inconvenient.\n-\nDonât shy away from touching meatspace.\n-\nFavour pragmatic activism over dogmatic idealism.\n-\nTreat others how you would like to be treated (with respect).\n-\nAbide by a philosophy of substraction (less is more).\n-\nThink big, for thinking small is often a self-fulfilling prophecy.\n-\nBias towards measurable actions, for if it canât be measured, it canât be improved.\nInspiration:\n- Principles / Oxide\n- Amazon leadership principles\n- Bill Ackmanâs 8 principles\n- Bertrand Russellâs 10 commandments\n31 Likes\n[Hasu's GOOSE Submission] Proposed goals for Lido DAO to consider\nSushi RouteProcessor2 Post-Exploit Request For Comment\nLIP-25: Staking Router v2.0\nReGOOSE: Updated goals for Lido in the light of MVI and restaking\n[EGG] Establishing the Community Lifeguards Initiative (CLI) Sub-Committee\nTanĂ© Delegate Thread\nEstablish a Public Delegate Platform and Delegate Incentivization Program\nReservoirDAO (AlphaGrowth) Delegate Platform\nStableLab Delegate Thread - Updated\nNumic is joining Pier Two\nCp0x Delegate Thread\nDaniela Zschaber representing Blockful Delegate Thread\nMarcbcs - Delegate Thread\nTokenLogic Delegate Thread\nPol Lanski Delegate Thread\nGOOSE-2025 & EGGs-2025 Final Report\nPolar - Delegate Thread\n[Hasu's GOOSE-2 Submission] A Product Line Approach to Grow Lidoâs Staking Ecosystem\nReevaluation of Lido on Polygon state\n[Lido Labs] GOOSE-3: Lidoâs Next Chapter\nKpk Delegate Thread\n2026 Ecosystem Grant gRequest (EGG): Executing GOOSE-3\nLido DAO Ops Multisigs Policy (2.0)\nWhitePaper Reading Club Delegate Thread\nLido on Solana Funding Proposal\nSushi RouteProcessor2 Post-Exploit Request For Comment\nGovernance Grove Delegate Thread\nSurplus Management Framework: Discussion and Draft Proposal\nAny plan for benefit/ utility more from LDO holding than GOV?\nStaking Router Module Proposal: Simple DVT\nAdopt the xERC20 Open Standard for wstETH Across All Chains\nLido on Ethereum Node Operator (InfStones) Platform Vulnerability Investigation - November 22, 2023\nActivate Lido Protocol Governance with Revenue Share Staking\nWintermute Governance Delegate Thread\nCommunity Staking Module\nJenya_K\nJune 13, 2023, 1:19pm\n2\nAwesome job! A big thanks to all those who were part of this. This discussion marks the initial stage in crafting the Lido DAO Constitution.\nGetting all DAO members on the same page regarding culture, mission, and vision is absolutely crucial before moving forward. It provides a solid foundation for the future strategy, decision-making process and direction of the DAO.\nSpeaking for myself, Iâm fully aligned with the vision statement, and I truly believe that Lido DAO has the potential to bring immense value in turning that vision into reality. Would be interesting to see how the Snapshot voting on this topic unfolds and if there would be more comments on raised question about Ethereum focus.\n10 Likes\npraneet\nJune 20, 2023, 2:57pm\n3\nBias towards measurable actions, for if it canât be measured, it canât be improved\n3 Likes\nJenya_K\nJune 23, 2023, 7:54am\n4\nSnapshot vote started\nPlease get your wallets ready to cast a vote , the Align Lidoâs Vibe (Purpose, Mission, Vision) Snapshot has started! The Snapshots ends on Thu, 29 Jun 2023 18:00:00 GMT.\n1 Like\nAlex_L\nJuly 5, 2023, 8:52am\n5\nHey the Snapshot passed and reached a quorum !\n5 Likes\nRelated topics\nTopic\nReplies\nViews\nActivity\n[Hasu's GOOSE Submission] Proposed goals for Lido DAO to consider\nGeneral\n16\n10089\nOctober 21, 2024\nA message to the Lido team\nGeneral\n32\n696\nOctober 4, 2026\nKuzmich Delegate Thread\nDelegate Platform\n45\n988\nSeptember 24, 2026\nLido teams' objectives and key results for 2022\nGeneral\n11\n8609\nJanuary 18, 2022\n[RCC-3] [LIDO-1] Introduction to the resilience roadmap\nFinance\n4\n8516\nMarch 9, 2023"}
{"url":"https://aave.com/docs/aave-v4/tools/exchange-rate","domain":"aave.com","title":"Live Exchange Rates | Aave Protocol Documentation","hash":"fa9a9796f4070ebfd5e68fed93ef629da256d229912f85f0fa49ceecfe213f28","tokens":350,"chars":1398,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112295675,"text":"Docs\nExchange Rates # Copy\nLearn how to fetch exchange rates between tokens and supported currencies on Aave v4.\nExchange rates in Aave are provided by Oracles using Chainlink price feeds.\nAaveKit provides current conversion rates between ERC-20 tokens, native tokens, and supported currencies: USD, EUR, and GBP. For smart-contract integrations, query USD reserve prices directly from the spoke oracle.\n- React\n- TypeScript\n- GraphQL\n- Solidity\nUse the useExchangeRate hook for live exchange rates with automatic polling every 10 seconds, or the imperative useExchangeRateAction hook for on-demand exchange rates.\nimport { type ExchangeRateRequest , useExchangeRate } from \"@aave/react\" ;\nfunction ExchangeRate ( { request } : { request : ExchangeRateRequest } ) { const { data , loading , error } = useExchangeRate ( request ) ;\nif ( loading ) return < div > Loading⊠;\nif ( error ) return < div > Error: { error . message } ;\n// data: ExchangeAmount return ( < span > { data . symbol } { data . value . toFixed ( 2 ) } ) ; }\nSee below some examples of request objects.\nimport { evmAddress , chainId , Currency } from \"@aave/react\" ;\nconst request : ExchangeRateRequest = { from : { erc20 : { chainId : chainId ( 1 ) , address : evmAddress ( \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\" ) , } , } , to : Currency . Usd , } ;\nPrevious\nUser Activities\nNext\nSwap Features"}
{"url":"https://eips.ethereum.org/EIPS/eip-190","domain":"eips.ethereum.org","title":"ERC-190: Ethereum Smart Contract Packaging Standard","hash":"59f36e0f31d4cd224570ff6199826315ec4aa899e808495b29a1df9391f1bd98","tokens":1176,"chars":4702,"crawler":"hive-genesis","verified":"unchecked","ts":1791112296688,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: ERC\nERC-190: Ethereum Smart Contract Packaging Standard\nAuthors\nPiper Merriam ( @pipermerriam ), Tim Coulter ( @tcoulter ), Denis Erfurt ( @mhhf ), RJ Catalano ( @VoR0220 ), Iuri Matias ( @iurimatias )\nCreated\n2017-01-10\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- Use Cases\n- Package Managers\n- Deterministic builds\n- Bytecode verification\n- Multi-chain deploys\n- Trusted packages\n- Framework support and integration\nAbstract\nThis ERC proposes a specification for Ethereum smart contract packages.\nThe specification was collaboratively developed by the following Ethereum development framework maintainers.\n- Tim Coulter (Truffle)\n- Denis Erfurt (Dapple)\n- Piper Merriam (Populus)\n- RJ Catalano (Eris PM)\n- Iuri Matias (Embark)\nMotivation\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.\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.\nA packaging standard should have the following positive effects on the ecosystem:\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).\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.\nSpecification\nThe full specification for this standard is maintained separately in the repository epm/epm-spec .\nThis EIP refers to the 1.0.0 version of the specification: https://github.com/ethpm/epm-spec/tree/v1.0.0\nThe specification contains details for a single document referred to as a âRelease Lockfileâ .\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\nThese documents have not been inlined into this ERC to ensure that there is a single source of truth for the specification.\nUse Cases\nThis specification covers the following types of smart contract packages.\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.\nFull explanations and examples of these use cases can be found in the README.md from the epm/epm-spec repository.\nPackage Managers\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.\nDeterministic builds\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.\nBytecode verification\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.\nMulti-chain deploys\nSupports deployments across multiple chains, allowing a package to define addresses on both the public mainnet and testnet.\nTrusted packages\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.\nFramework support and integration\nSupport for ERC190 is either implemented or in progress for the following:\n- Truffle\n- Populus\n- Dapple\n- Eris PM\n- Embark\n- Browser Solidity\nCitation\nPlease cite this document as:\nPiper 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."}
{"url":"https://docs.orca.so/liquidity/manage/add","domain":"docs.orca.so","title":"How to Add Liquidity - Orca Documentation","hash":"812955269b38493825af5e3ba1ad874c614ab7b9437ec8e25bee0f98220d745d","tokens":885,"chars":3537,"crawler":"crawler-tpoe","verified":"unchecked","ts":1791112297508,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nManaging Positions\nHow to Add Liquidity\nAdd more liquidity to an existing position.\nAdd liquidity to an existing Orca liquidity position by depositing additional tokens.\nProviding liquidity involves risk. Position outcomes can be affected by impermanent loss, token price movement, range status, slippage, fees, transaction costs, and market conditions. Review the risks before depositing.\nHow to add liquidity\n1\nOpen the Position Details sidebar\nNavigate to your Portfolio and click the position you want to add liquidity to. See the Position Details Sidebar Guide for a full walkthrough.\n2\nSelect the Deposit tab\nIn the sidebar, ensure the Deposit tab is selected.\n3\nEnter deposit amounts\nEnter the amount you want to deposit in one of the token fields.\nEnter your deposit amount in either token field\nThe other value is calculated based on the deposit ratio required for your existing range.\nClick Max to use the available quantity of a token from your wallet.\nUse Max to enter the available token amount\n4\nOptional: use Autoswap\nIf your wallet does not have the token ratio required for the deposit, Autoswap may be available to adjust one token into the other. Review the quoted swap details, price impact, fees, slippage setting, and final deposit amounts before using Autoswap.\n5\nOptional: adjust liquidity slippage\nClick the Liq. slippage button to review or adjust your slippage tolerance. See Understanding Slippage for more information.\n6\nComplete your deposit\nReview the deposit details and click Deposit .\nClick Deposit to add liquidity to your position\n7\nApprove the transaction\nReview the details in your wallet, including any network fees, before approving.\nReview your range, deposit amounts, slippage setting, and current pool price carefully. If the pool price differs from wider market prices, or if the deposit details do not match your expectations, your position outcome may differ from expectations.\nAfter depositing\nYou will not receive a new pool position NFT. Your existing NFT continues to represent the updated position with additional liquidity.\nThe NFT remains in your wallet displaying â DO NOT BURN .â\nProtect your position NFT:\n- Do not sell, transfer, or burn this NFT unless you intend to transfer ownership of the position or permanently give up access to it.\n- This NFT represents ownership of your liquidity position.\n- If you sell, transfer, or burn the NFT, you will lose access to the liquidity position it represents.\n- Orca cannot recover liquidity if the position NFT is burned or transferred away.\nImportant reminders\n- Adding liquidity changes the size of your existing position.\n- Your existing range remains the same unless you create a new position.\n- Fee accrual is not guaranteed and depends on swaps using your in-range liquidity.\n- If your position is out of range, added liquidity may be deposited as one token.\n- Review all wallet prompts before signing.\nNext Steps\nManage Portfolio\nReview and manage all your positions\nHarvest Yield\nUse the Harvest Yield function to collect accrued fees and rewards\nWithdraw Liquidity\nRemove liquidity from your position\nPosition Alerts\nGet notified when selected conditions occur\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.anza.xyz/consensus/vote-signing","domain":"docs.anza.xyz","title":"Secure Vote Signing | Agave","hash":"cad88386779a15462975137d75881b5beaf27ed35c0f249b6d7d66440a4e0256","tokens":393,"chars":1572,"crawler":"hive-genesis","verified":"exact","ts":1791112298490,"text":"Skip to main content\nSecure Vote Signing\nA validator receives entries from the current leader and submits votes confirming those entries are valid. This vote submission presents a security challenge, because forged votes that violate consensus rules could be used to slash the validator's stake.\nThe validator votes on its chosen fork by submitting a transaction that uses an asymmetric key to sign the result of its validation work. Other entities can verify this signature using the validator's public key. If the validator's key is used to sign incorrect data (e.g. votes on multiple forks of the ledger), the node's stake or its resources could be compromised.\nValidators, Vote Signers, and Stakeholders\nWhen a validator receives multiple blocks for the same slot, it tracks all possible forks until it can determine a \"best\" one. A validator selects the best fork by submitting a vote to it.\nA stakeholder is an identity that has control of the staked capital. The stakeholder can delegate its stake to the vote signer. Once a stake is delegated, the vote signer's votes represent the voting weight of all the delegated stakes, and produce rewards for all the delegated stakes.\nValidator voting\nA validator node, at startup, creates a new vote account and registers it with the cluster via gossip. The other nodes on the cluster include the new validator in the active set. Subsequently, the validator submits a \"new vote\" transaction signed with the validator's voting private key on each voting event.\n- Validators, Vote Signers, and Stakeholders\n- Validator voting"}
{"url":"https://governance.aave.com/t/aave-chan-initiative-delegate-platform/10877","domain":"governance.aave.com","title":"Aave Chan Initiative Delegate platform - Delegate Platforms - Aave","hash":"19c6d4b04a962ee0911481a5a72be496693ef12d43043ec7b2cf495f1230f800","tokens":4555,"chars":18219,"crawler":"crawler-tpoe","verified":"exact","ts":1791112299501,"text":"Aave\nAave Chan Initiative Delegate platform\nDelegate Platforms\nMarcZeller\nNovember 30, 2022, 9:41am\n1\nAave Chan Initiative Delegate platform\nKey Info\n- Delegate Address: ACI.eth\n- Telegram: @Lemiscate\n- Discord: Marczeller | Aave#3432\n- Twitter: https://twitter.com/lemiscate (founder) https://twitter.com/AaveChan (ACI)\n- Voting record: Boardroom\nIntroduction\nThe Aave-Chan Initiative (ACI) is a delegate platform founded by Marc Zeller, an independent blockchain consultant working with the Aave Companies since 2019. The ACI aims to participate in governance discussions on Aave and create snapshot votes & AIPs to be submitted to community vote for the benefit of the Aave protocol.\nDelegate Statement (why you should delegate to us)\nThe Aave-Chan Initiative, while being a new structure, already has a long track record in the Aave governance ( Co-author of AIP-1 ) and forum discussions.\nAs the Aave ecosystem is getting more mature, the protocol benefits from more delegation diversity with their independent visions and value propositions for the Aave protocol.\nAs delegates, we commit to dedicating our time and resources to support Aaveâs development and growth.\nWhat voters can expect from Aave-Chan Initiative:\n- Active : we have a strong track record of governance participation and will be involved in governance at each step of AIPs process from ARCs to onchain AIPs votes\n- Vision : The ACI main goal and focus is the Aave protocol success, ACI is dedicated to DeFi ethos and long-term games.\n- Focus : ACI has no plan to expand into other protocols governance actively and will remain laser-focused on Aave.\nOur main focus points at launch are:\n- Treasury efficiency :\nEvery $ in the Ecosystem Reserve, in the Aave DAO treasury, should be cherished as the property of every AAVE token holder, and each spending should be done with the full intent to provide the maximum benefit for the Aave protocol ecosystem and not just be considered as a âbuffetâ to drain easy money by overcharging services. the ACI is fully dedicated to playing âScrooge McDuckâ in Aave and will have a slightly softer spot toward spending in Dev & risk mitigation over other aspects.\nBy providing a defacto alternative to current existing services, the ACI will provide both cooperation and competition to existing services with the full intent to contribute to the efficiency of these services.\n- Treasury Efficiency (II) :\nThe Aave DAO treasury is currently only gaining yield from depositing into Aave. Both for increased yield and for strategic & synergies reasons the ACI is supportive and wants to participate in less passive management of the DAO treasury, such as examples from llama by doing risk-averse investments that will increase yield:\n-\nconvert part of WETH into LSDs to gain staking yield\n-\nDeposit part of stablecoins into stableswaps\n-\nstake veTokens and vote for Aave related pools\n-\nregularly convert part of long tail assets into wETH or stablecoins\n-\nTreasury diversity :\nThe ACI is supportive of Protocol Owned Liquidity (POL) and bonding. While most, if not all, of âDeFi 2.0â died, some ideas executed in a non âponziâ way do have an added-value proposition.\nWith the emergence of GHO, we think there are opportunities to diversify the Aave DAO treasury and rework the Safety module with more robust models and ACI want to be an actor of governance discussions around this point.\n- Stablecoin diversity :\nThe DeFi ecosystem is addicted to USDC, and itâs a central point of failure and an Achilles heel to the ecosystem. While we consider Circle to be a trustworthy and non-hostile actor, supporting decentralized stablecoins diversity to provide alternatives makes the ecosystem both more resilient and attractive.\nAave is the leader of stablecoin diversity and will soon deploy GHO to participate in this diversity, the ACI is a supporter of this strategy.\n- LSD diversity :\nLiquid staking derivatives or LSDs, are the best form of collateral at the disposal of an Aave user, as yield-bearing by nature, yield is linked to actual economic activity. One of the goals of ACI will be the support the onboarding of a more diverse set of LSDs into Aave V3, leveraging supply & borrow caps and isolation mode to increase diversity while maintaining risk mitigation at the protocol level.\n- DeFi synergies :\nOne of the reasons Aave reached a leadership position was their dedication to the protocol to act as a team player with the ecosystem and encourage synergies.\nYield-bearing assets and LP tokens as collateral could be strategically onboarded in protocol V3 to attract more liquidity and allow users of other protocols to gain borrowing power in Aave.\nAave was a pioneer in this area with the AMM V1 market; while it was too early to show success, time only proved the potential of these assets as the ecosystem gained maturity.\nThe ACI is in favor of increased synergies with Curve, Balancer, Arrakis, and others actors.\nTransparency\nThe ACI fully commits to declaring all votes in the current thread and summarizes the reasons for each vote in complete transparency.\nConflicts of Interest\nAave-Chan Initiative is founded by Marc Zeller, an independent blockchain consultant working with the Aave Companies since 2019; The founder owns AAVE and multiple assets in the ecosystem. The founder is also an Angel investor in various ecosystem projects and will disclose accordingly.\nDelegate address\nACI.eth (0x57ab7ee15cE5ECacB1aB84EE42D5A9d0d8112922)\n30 Likes\nImprove permissions management on Aave v2 and define a better strategy for access control roles on Aave v3\n[TEMP CHECK] Defining the Service Provider & Delegation Platform Relationship\n[ARFC] ACI Phase II\nAave Labs Contributions Report\nDoo_StableNode\nNovember 30, 2022, 9:55am\n2\nLike many others in the AAVE community, we believe the community is fortunate to have one whoâs both knowledgeable and reputable to become a delegate. We look forward to see Marc and Aave-Chan continue to contribute to AAVE governance.\n7 Likes\nJordan\nNovember 30, 2022, 10:57am\n3\nMarc / Aavechan has been one of the most impactful representant of Ethereum ethos and decentralisation through his work with the Aave companies and within the Aave communities and itâs healthy for the protocol to have him represent an independant voice within the Aave governance.\nACI focus on true open source, risk management and financial conservatism makes me looking forward to delegate to them.\nThe individual proposals for treasury diversification will have to be thoroughly checked by multiple parties to make sure that we do not end up adding more risks to the protocol but overall itâs a welcome addition to further decentralise Aave delegates, which is a space where the community must always be mindful of centralisation risks.\n4 Likes\nMarcZeller\nDecember 1, 2022, 8:29am\n4\nRisk Parameter Updates for Aave v2 Polygon\nVote Result : YAE\nRationale\nWe voted Yae. While V3 is the future of Polygon, unfreezing specific assets with disabled borrowing does not increase protocol risk and allows users to manage their position. unfortunately, this AIP didnât reach quorum, and weâre supportive of a re-run.\n1 Like\nMarcZeller\nDecember 2, 2022, 5:10pm\n6\nAave StarkNet Phase I - Aave <> StarkNet Bridge deployment/activation by Aave governance\nVote Result : YAE\nRationale\nWe voted YAE. Pretty exciting to see the first steps of Aave toward a new ETH L2. Starknet Zk will allow scalability and new use cases for Aave and is a good direction for Aave expansion.\n1 Like\nMarcZeller\nDecember 8, 2022, 8:11am\n7\nSet LDO, stMATIC, MaticX and SD Emission_Admin for Polygon v3 Liquidity Pool\nVote Result : YAE\nRationale\nThe ACI voted YAE, LSDs yield loops are a strategic growth vector for Aave increasing both liquidity & borrow volume and thus protocol revenue.\nThis AIP allows LSDs partner on polygon to participate in LM program to support Aave liquidity growth, itâs a clear win-win for every party involved.\n2 Likes\nMarcZeller\nDecember 12, 2022, 10:15am\n8\nFreeze Aave V1\nVote Result : YAE\nRationale\nthe ACI voted YAE, Aave V1 is not gas optimized and lack the upgrades of V2 & V3. A freeze will still allow users to repay their position and withdraw.\nunfortunately this proposal didnât meet quorum but as it was non-contentious weâre supportive of a re-run.\n2 Likes\nMarcZeller\nDecember 13, 2022, 9:54am\n9\n[ARFC] Repay Excess CRV Debt on Ethereum v2\nVote Result : YAE\nRationale\nthe ACI voted YAE use USDC to buy CRV, considering the excess debt amount, usage of the safety module is not required, also as CRV is a strategic asset for the emergence of GHO and considering thereâs around 30m$ in DAO treasury in stablecoins, using part of DAO stablecoins while keeping the CRV seems the most efficient strategy.\nwe regret the lack of an âAbstainâ option in this vote, while the ACI had no intention to abstain itâs important that the diversity of opinions of the community can be voiced and encourage @Llamaxyz to follow standards if possible.\n[ARFC] Ethereum v2 Collector Contract Consolidation\nVote Result : YAE\nRationale\nthe ACI voted YAE, consolidating the books to USDC is a net positive for the protocol and with the upcoming emergence of V3 the time to do this is fit. we appreciate llama optimization on premium, theses assets auctions from the protocol are basically âslippage-freeâ winning trades and great opportunities for arb & Market markets, the ACI is supportive of more systemic integration of the auctions (such as with DEX aggregators) to make the clearing of it as fast and smooth as possible while optimizing the premium to make sure the DAO gets the best possible deal from it at the benefit of the protocol.\nDiscussions are ongoing with several potential integrators on this.\n[ARFC] [ARFC] Receipt of Gauntlet Insolvency Fund\nVote Result : ABSTAIN\nRationale\nthe ACI voted ABSTAIN. While we have no strong opposition to this proposal, sending the AAVE to the Ecosystem reserve is basically a gift to the Safety module stakers and these funds will eventually run out. we have the feeling that a more strategic usage of these StkAAVE could have been done (Use them to power a discounted credit line of GHO minting and provide GHO liquidity for example)\nMatthewGraham\nDecember 13, 2022, 1:39pm\n10\nHi @MarcZeller ,\nThank you for the feedback on the [ARFC] Receipt of Gauntlet Insolvency Fund proposal. Please note, that using the stkAAVE to support GHO adoption is something being looked into. With v3 not yet deployed on Ethereum and seeing v2 liquidity migrate to v3 very slowly, any proposal using stkAAVE to support lower GHO borrowing rates just now is a bit early. If such a proposal was to emerge at a later date, it will likely be at a larger scale than what would be supported by the Gauntlet holding.\nGreat delegation thread. I really like reading your feedback on each of the proposals. Thank you for being a consistent voter as well.\n1 Like\nMarcZeller\nDecember 13, 2022, 3:01pm\n11\nIn accordance to our previous position, the ACI voted YAE on the Re-run of this proposal.\nFinger crossed for quorum!\n1 Like\nMarcZeller\nDecember 16, 2022, 1:40pm\n12\n[Temp Check] Deploy Aave on Metis\nVote Result : ABSTAIN\nRationale\nthe ACI rationale was explained in the thread here: Launch Aave V3 on Metis - #47 by MarcZeller\n[ARFC] Aave DAO Policy Change: Halt Listings on all Aave v1 & v2 Non Permissioned Deployments\nVote Result : YAE\nas stated many times, V3 is the future of Aave, with current market situation, the protocol needs to fully use the supply and borrow caps to limit risks, adding new listing to V3 exclusively will also add to V3 attractivity and support transition to the new version of the protocol\n[ARC] Updated: Gauntlet <> Aave Renewal\nVote Result : YAE\nAs Gauntlet switched to a fixed fee model, the ACI is plainly supportive of this proposal. Independent third-party risk service providers are key to protocol resilience and the ACI is looking forward to working with gauntlet in 2023.\n1 Like\nMarcZeller\nDecember 17, 2022, 10:39am\n13\nAave v2 ETH Interest Rate Curve Update\nVote Result : YAE\nRationale\nLSD yield optimizer loops are a massive driver of Aave protocol revenue. This upgrade of interest rate strategy will both increase the expected yield of these strategies and overall protocol revenue while keeping risks at acceptable levels.\nThe ACI is plainy supportive of this proposal and will also support related proposals in the MATIC ecosystem.\nKudos to @Llamaxyz & Gauntlet for their collaboration on this AIP.\n3 Likes\nstani\nDecember 19, 2022, 1:12pm\n14\nSuper exciting to see the Aave Chan Initiative - @MarcZeller has always had his heart within the Aave community and been valuable contributor over the pasts years. ACI is a great initiative to support the Aave DAO directly as a delegate - will support Marc fully on the Aave Chan Initiative\n7 Likes\nMarcZeller\nDecember 20, 2022, 8:36am\n15\nFreeze Aave V1\nVote Result : YAE\nRationale\nThe ACI position did not change with this re-run, V1 is legacy tech and as a cost-to-run (chainlink price feeds infra), weâre supporting progressively fading out legacy versions of Aave to allow focus on V3 and reduce overall cost.\nAgain, ACI position did not change from snapshot vote, we look forward to keep working with Gauntlet in 2023\nMarcZeller\nDecember 20, 2022, 8:51am\n16\nAuthorise the release of Aave <> Chainlink Proof of Reserve for Aave Avalanche\nVote Result : YAE\nRationale\nProof of Reserve is a net positive for the Aave protocol resilience, as Harmony market events shown, even a functioning Aave can suffer from infrastructure itâs built upon. PoR implementation while not eliminating risks, helps in these scenarios. the ACI is supportive.\n[ARFC] Aave v3 Polygon wMATIC Interest Rate Update\nVote Result : YAE\nRationale\nAs stated multiple times and in line with our delegate platform, the ACI supports LSDs yield leverage strategies as big potential drivers of protocol revenue, this interest rate strategy allows for these strategies to scale and be more profitable while making Aave V3 on polygon more attractive overall.\n[ARFC] BAL Interest Rate Curve Upgrade\nVote Result : YAE\nRationale\nFor the same reasons of wMATIC vote, the ACI is supportive of a proposal in line with its delegate platform.\n1 Like\ndaveytea\nDecember 21, 2022, 10:45am\n17\nI fully support and trust @MarcZeller to play Scrooge McDuck to ensure rational spending\n3 Likes\nMarcZeller\nJanuary 10, 2023, 10:44am\n18\nsnapshot votes\n[ARC]: Risk Parameter Updates for Aave V3 Optimism 2022-12-29\nVote Result : YAE\nRationale\nThis temporary arc is an act of caution given the relatively low liquidity of AAVE on OP. It should be followed by a more robust AIP later when risk teams will recommend risk parameters for this asset.\nApprove pricing approach for WBTC on Aave\nVote Result : WBTC oracle based on WBTC\nRationale\nIt was not an easy choice, while we firmly believe wBTC value will always âmechanicallyâ go back to peg due to bitgo redeemability and any offpeg event is temporary in nature. it is a better security practice to track the asset directly and not the underlying, in the case of Bitgo issue, doing this will allows liquidation to happen and reduce the negative consequence of this kind of event.\nUpdated: Aave Grants DAO Renewal\nVote Result : YAE\nRationale\nThe ACI supports this updated proposal, our âScrooge McDuckâ campaign allowed 750k$ cost-cutting while maintaining a high-quality of AGD program.\nAIPs\n-\nUpdate renFIL rate strategy on Aave v2 Ethereum\n-\nRewards controller update across V3 pools\n-\nRisk Parameter Updates for Aave v2 Ethereum - LTs and LTVs for Long Tail Assets\n-\nRisk Parameter Updates for Aave v2 Ethereum - LT and LTV (DAI, USDC)\n-\nSupply/Borrow Cap Updates for Aave v3\n-\nChaos Labs Aave v2 Coverage\n-\nRisk Parameter Updates for Aave V3 Optimism Market (2022-12-29)\nVote Result : YAE\nRationale\nthe ACI voted in support of these proposals (rationales are the same as on snapshot vote). This batch of AIPs during the holidays all reached quorum thanks to the activity of platform delegates and the aave community, that being said, we do not recommend in the future to post AIPs in the middle of holidays to increase the odds of reaching quorum.\nYAE 2949Ă2780 1.06 MB\n5 Likes\nMarcZeller\nMay 15, 2023, 8:25am\n19\nmic check - one two, one two, does this thing work?\nWith the ACI we apologize for the lack of updates in this section of the forum, we got ourselves busy and didnât take the time to update the huge amounts of TEMP CHECK, ARFC, AIPs, votes & updates we participated in.\nWe will try to re-start the updates in here, obviously too much has happened since our last update so we start back from now.\nAIPs/proposals :\n- BUSD offboarding part II\n- fUSD onboarding\n- emode for rETH\n- RPL onboarding\n- onboard MAI on optimism\n- onboard MAI on Arbitrum\n- convert aWETH to LST assets\nFrom now on weâll try to publish here a short-term roadmap (less than a month delivery), then update with work done & publish the next roadmap.\nwith upcoming new hires in the ACI team, we should be able mid-term to publish much more detailed posts in here.\nimage 571Ă513 14.7 KB\nthanks for reading and we would like to express our gratitude towards the 200+ addresses trusting us with their delegations, we will keep working hard to be worthy of your support!\n6 Likes\nMarcZeller\nMay 27, 2023, 8:58am\n20\nfollowing the snapshot vote for the Delegate Code of Conduct.\nBy this post, the ACI is officially stating its intent to follow this code and is proud to participate in this initiative.\n2 Likes\nMarcZeller\nMay 30, 2023, 8:43am\n21\nHenlo frens, hereâs an update on previous Short Term roadmap\nA new âroadmapâ will be published shortly to announce the next areas of focus for the ACI\nAs we react to most proposals on the forum directly, for now, we do not update here with every single vote rational as itâs quite time-consuming.\n6 Likes\nnext page â\nRelated topics\nTopic\nReplies\nViews\nActivity\nACI is leaving Aave\nGeneral\n32\n7049\nJuly 1, 2026\nTokenLogic Delegate Platform\nDelegate Platforms\n37\n6638\nSeptember 8, 2026\nEzR3aL Delegate Platform\nDelegate Platforms\n43\n5117\nJuly 1, 2026\n[ARFC] Governance Framework v2\nGeneral\n2\n692\nAugust 9, 2026\nAreta Delegate Platform\nDelegate Platforms\n581\n13221\nAugust 10, 2026"}
{"url":"https://www.helius.dev/docs/trading/overview","domain":"www.helius.dev","title":"Trading on Solana with Helius - Helius Docs","hash":"ce313d550fc7585f00d43cd543c22a0c49a0fcab9d95c98dafaf9c66507dd9c5","tokens":743,"chars":2972,"crawler":"hive-genesis","verified":"exact","ts":1791112300309,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNew: Try Gatekeeper (Beta) for significantly lower latency. Learn More\nHelius Docs home page\n- Support\n-\nGet started\nHelius Docs home page\nTrading\nTrading on Solana with Helius\nBuild a low-latency Solana trading stack with Helius: see the market first with Preconfirmations and land trades ahead of the competition with Sender.\nOverview\nPricing update: Sender Max now uses a\n0.001 SOL minimum tip to access Heliusâ priority transaction buffer â tip more to land\nfirst. The cost-optimized\nSWQOS-only tier remains at 0.000005\nSOL.\nHelius gives traders a complete low-latency toolkit. Whatever your strategy â propAMMs, snipers, copy traders, liquidation bots, or arbitrage â it comes down to two things: see faster and act faster .\nSee\nPreconfirmations â stream transactions at the lowest possible\nlatency, before they land.\nAct\nHelius Sender â land transactions and bundles ahead of the competition\nwith multi-path routing and a priority tip buffer.\nChoose the right product\nYou want to⊠Use\nReact to onchain activity as early as possible Preconfirmations\nAccess Solanaâs raw network data Shred Delivery\nLand a trade or bundle ahead of competitors Sender Max\nTrade cost-efficiently on a single fast path Sender SWQOS-Only\nProtect transactions from sandwich attacks MEV Protect\nSee: Preconfirmations and Shreds\nPreconfirmations stream transactions before they are shredded â Helius preconfirmations the instant the leader executes them, together with their execution status, and BAM preconfirmations when the validator commits to executing them. It is the earliest transaction signal available, delivered over a preconfSubscribe WebSocket subscription . Requires a Professional plan or higher ; metered at 10 credits per message .\nShred Delivery gives you Solanaâs raw network data â shreds â over UDP. Best for propAMMs, snipers, copy traders, liquidation bots, arbitrage, and RPC node operators who want to remove network sync latency. If youâd rather skip deshredding, preprocessedSubscribe streams the decoded, pre-execution transactions over WebSocket (public beta).\nAct: Helius Sender\nHelius Sender is the traderâs path for landing transactions. It consumes no credits â you pay per send with a SOL tip â and offers two tiers:\nSender Max\nRouted across every high-speed pathway and entered into a priority tip\nbuffer. Handles both transactions and bundles. Minimum 0.001 SOL tip.\nSender SWQOS-Only\nCost-optimized low-latency sending on a single fast path. Minimum 0.000005\nSOL tip.\nRelated\nData Streaming & Event Listening\nThe full streaming hub â compare LaserStream, WebSockets, Webhooks, and Shred\nDelivery for any data workload.\nLaserStream\ngRPC streaming for confirmed and historical onchain data.\nWas this page helpful?\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.celestia.org/build/private-blockspace/quickstart/","domain":"docs.celestia.org","title":"Celestia Documentation","hash":"06d8720ddced111a79d7054fb2dea99b6e500ea06cdc58b2d13b9c54e8c21bf7","tokens":1733,"chars":6929,"crawler":"crawler-tpoe","verified":"exact","ts":1791112301217,"text":"Skip to Content\nBuild Private blockspace Quickstart\nPrivate blockspace quickstart\nPrivate blockspace encrypts your blob data before itâs posted to Celestia using a lightweight proxy.\nIn this quickstart, youâll use hosted Celestia nodes (like Quicknode) instead of running your own.\nGet your node credentials\nTo use Private Blockspace, youâll need access to a hosted Celestia Data Availability (DA) + Consensus Node . The easiest option is Quicknodeâs Celestia service , which provides ready-to-use mainnet and Mocha testnet endpoints. They offer a free 30-day trial, which is enough for this quickstart.\n- Visit the Quicknode Celestia dashboard and log in (or create a free account).\n- Click Create Endpoint , then select:\n- Chain: Celestia\n- Network: Mainnet or Mocha\n- Copy the generated endpoint URL (it looks like this): https://celestia-mocha.quiknode.pro//\n- Copy the token from your endpoint URL (this is your write / read token ).\n- Save both the URL and token â youâll add them to your .env file next.\nCreate your .env\nDownload the repoâs example.env and save it as .env .\nEdit only the following items.\nKey What to do\nPBS_DB_PATH Absolute path for local proxy data (e.g. /Users/you/dev/pbs-db )\nENCRYPTION_KEY 32-byte key â see command below\nCELESTIA_NODE_RPC Your Quicknode HTTPS endpoint (includes your token)\nCELESTIA_CORE_GRPC Same host + :9090 (no token in path)\nCELESTIA_NODE_WRITE_TOKEN Your Quicknode token\nCELESTIA_SIGNING_KEY 32-byte private key for your signer (funded on Mocha)\nTLS_CERTS_PATH / TLS_KEY_PATH Path to your local TLS cert + key (see next step)\nCELESTIA_NETWORK etc. Keep defaults; ensure all paths are absolute\nGenerate an ENCRYPTION_KEY (ChaCha20, 32 bytes)\nThis is a random 256-bit symmetric key, not a wallet key.\nopenssl rand -hex 32\n# or\npython3 -c \"import secrets; print(secrets.token_hex(32))\"\nPaste the value (no quotes) as your ENCRYPTION_KEY .\nGenerate TLS certificates\nThe proxy requires TLS certificates (even for local testing).\nmkdir -p tls\nopenssl req -x509 -nodes -newkey rsa:2048 -keyout tls/tls.key -out tls/tls.crt -days 365 -subj \"/CN=localhost\"\nThen mount that folder when running Docker and set:\nTLS_CERTS_PATH=/app/tls/tls.crt\nTLS_KEY_PATH=/app/tls/tls.key\nWithout valid certs, the proxy will exit with\nTLS_CERTS_PATH required: NotPresent .\nFund your signer\nYour CELESTIA_SIGNING_KEY corresponds to a Mocha testnet address.\nThat address must exist and hold some test TIA.\nGet funds from the Celestia Mocha faucet .\nYou can verify your signer address in the proxy logs it prints the address when starting.\nRun the proxy container\nApple Silicon (M1/M2/M3)\nThe published image is amd64 only â run it under emulation:\ndocker pull --platform=linux/amd64 ghcr.io/celestiaorg/pda-proxy:latest\nmkdir -p \" $PBS_DB_PATH \"\ndocker run --name pda-proxy --rm -it --platform=linux/amd64 --env-file ./.env -v \" $PBS_DB_PATH : $PBS_DB_PATH \" -v \"./tls:/app/tls\" -p 26657:26657 ghcr.io/celestiaorg/pda-proxy:latest\nIntel/AMD Linux or other amd64 hosts\ndocker pull ghcr.io/celestiaorg/pda-proxy:latest\nmkdir -p \" $PBS_DB_PATH \"\ndocker run --name pda-proxy --rm -it --env-file ./.env -v \" $PBS_DB_PATH : $PBS_DB_PATH \" -v \"./tls:/app/tls\" -p 26657:26657 ghcr.io/celestiaorg/pda-proxy:latest\nVerify itâs running\nCheck logs:\ndocker logs -f pda-proxy\nOr test status:\ncurl -k -sS -X POST -H \"Content-Type: application/json\" -H \"Authorization: Bearer YOUR_TOKEN\" --data '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"status\",\"params\":[]}' https://127.0.0.1:26657 | jq .\nOn Apple Silicon, keep --platform=linux/amd64 until a native arm64 image exists.\nSend a blob\nTry a small encrypted payload:\ncurl -k -sS \\\n-H \"Content-Type: application/json\" \\\n-H \"Authorization: Bearer YOUR_TOKEN\" \\\n-X POST --data '{\n\"id\": 1,\n\"jsonrpc\": \"2.0\",\n\"method\": \"blob.Submit\",\n\"params\": [[\n{\n\"namespace\": \"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMJ/xGlNMdE=\",\n\"data\": \"SSBMb3ZlIEJpZyBCbG9icw==\",\n\"share_version\": 0,\n\"commitment\": \"aHlbp+J9yub6hw/uhK6dP8hBLR2mFy78XNRRdLf2794=\",\n\"index\": -1\n}\n], {}]\n}' https://127.0.0.1:26657 | jq .\nThe proxy will:\n- Encrypt your blob\n- Submit to Celestia\n- Return a height and tx hash\nIf the response includes \"result\": { \"height\": \"âŠ\" } , youâre set. Jump to Verify your blob with that height.\nIf you see \"[pda-proxy] Verifiable encryption processing...\" , the proxy queued the job. Two quick options:\nOption A â resend once\nSometimes it finishes fast and youâll get the height on the next call.\nOption B â find the height\nEither tail logs:\ndocker logs -f pda-proxy | egrep -i 'submit|height|commit|error'\nOr poll a small window around the tip for your namespace:\nLATEST = $(\ncurl -k -sS \\\n-H \"Content-Type: application/json\" \\\n-H \"Authorization: Bearer YOUR_TOKEN\" \\\n-X POST --data '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"status\",\"params\":[]}' \\\nhttps://127.0.0.1:26657 |\njq -r '.result.sync_info.latest_block_height'\n)\nfor h in $( seq $(( LATEST-2 )) $(( LATEST+2 ))); do\nRES = $(\ncurl -k -sS \\\n-H \"Content-Type: application/json\" \\\n-H \"Authorization: Bearer YOUR_TOKEN\" \\\n-X POST --data \"{\n\\\" id \\\" :1,\n\\\" jsonrpc \\\" : \\\" 2.0 \\\" ,\n\\\" method \\\" : \\\" blob.GetAll \\\" ,\n\\\" params \\\" :[ $h , [ \\\" AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMJ/xGlNMdE= \\\" ] ]\n}\" \\\nhttps://127.0.0.1:26657\n)\nif echo \" $RES \" | jq -e '.result | length > 0' > /dev/null ; then\necho \"Height $h \"\necho \" $RES \" | jq .\nfi\ndone\nCopy the commitment you see there and use it with blob.Get .\nVerify your blob\nNow, fetch the same blob through your proxy using the following command with HEIGHT replaced with your actual height:\ncurl -k -sS -H \"Content-Type: application/json\" -H \"Authorization: Bearer YOUR_TOKEN\" -X POST --data \"{\n\\\" id \\\" :1,\n\\\" jsonrpc \\\" : \\\" 2.0 \\\" ,\n\\\" method \\\" : \\\" blob.GetAll \\\" ,\n\\\" params \\\" :[HEIGHT,[ \\\" AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMJ/xGlNMdE= \\\" ]]\n}\" https://127.0.0.1:26657 | jq .\nYouâll see a commitment and your decrypted data:\n{\n\"commitment\" : \"âŠbase64âŠ\" ,\n\"data\" : \"SSBMb3ZlIEJpZyBCbG9icw==\" ,\n\"namespace\" : \"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMJ/xGlNMdE=\"\n}\nDecode base64 to plaintext\nWhen you retrieve a blob, the data field is base64. To see the plaintext:\nmacOS/Linux\necho \"SSBMb3ZlIEJpZyBCbG9icw==\" | base64 -d\nPython\npython3 - << 'PY'\nimport base64\nprint(base64.b64decode(\"SSBMb3ZlIEJpZyBCbG9icw==\").decode())\nPY\nNode.js\nnode -e 'console.log(Buffer.from(\"SSBMb3ZlIEJpZyBCbG9icw==\",\"base64\").toString())'\nTroubleshooting\nError message Cause Fix\nTLS_CERTS_PATH required Missing or commented-out cert vars Generate certs (see above).\naccount not found Unfunded signer Use Mocha faucet .\nblob: not found Wrong commitment Run blob.GetAll to find the real one.\ngrpc-status header missing Invalid gRPC URL Must be https://:9090 , no token.\nâ
Youâre done\nYouâre running private blockspace end-to-end using hosted infrastructure.\nâ
No local Celestia node\nâ
Fully containerized\nâ
Encrypted data posted to Celestia\nFeel stuck? Go to our Discord!\nLast updated on October 1, 2026\nAbout Proof queries (legacy)"}
{"url":"https://docs.lightning.engineering/lightning-network-tools/taproot-assets/universes","domain":"docs.lightning.engineering","title":"Universes | Builder's Guide","hash":"52ba84c2967d342973cde989808e4afdec85c12d1d53aa5b3fb614956894b77d","tokens":1390,"chars":5557,"crawler":"hive-genesis","verified":"exact","ts":1791112302416,"text":"Builder's Guide\nâ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nUniverses\nLearn how to run a universe and connect to other universes.\nIn the context of Taproot Assets, a universe is a service that acts as a repository for publicly minted assets. It contains knowledge of assets, mints, metadata, public transfers and their proofs. A universe is required for users to fetch data necessary to validate transfers, and may be public or private.\nAnyone may run a universe, or use one or multiple universes provided by others, such as Lightning Labs.\nYour local universe\nWhen running tapd , you will run a private universe by default. In this mode, all RPC calls to the universe require authentication using the tapd macaroon. To disable macaroon authentication for the QueryProof and InsertProof RPC calls, you may set the following configuration flag:\nallow-public-uni-proof-courier=true\nYou may further open up your local universe to serve the QueryAssetStats , UniverseStats and QueryEvents RPC calls:\nallow-public-stats=true\nYou may do this to operate a public universe, or make it easier for other applications to reach your API endpoints.\nRunning a public universe\nRunning a universe is as simple as running tapd and amending your configuration file. You may run a universe over RPC or REST. By default, tapd is expected to listen on gRPC TCP port 10029 and REST TCP port 8089 , so ensure this port is open on your machine if you would like others to connect to you. Being publicly reachable is not a requirement for a universe, however. Your universe may only serve resources on a private network, or be otherwise restricted.\nWhen running tapd as part of litd , you may also use port 8443 or define your own port. For example, as the REST universe is also usable through a browser over HTTPS, you may configure it over port 443 or set up a proxy.\nSample tapd.conf file:\nrpclisten=0.0.0.0:10029\nrestlisten=0.0.0.0:8089\nallow-public-uni-proof-courier=true\nallow-public-stats=true\nuniverse.public-access=rw\nYou can verify whether your universe is accepting proofs with the command tapcli universe federation config info\n{\n\"global_sync_configs\": [\n{\n\"proof_type\": \"PROOF_TYPE_ISSUANCE\",\n\"allow_sync_insert\": true,\n\"allow_sync_export\": true\n},\n{\n\"proof_type\": \"PROOF_TYPE_TRANSFER\",\n\"allow_sync_insert\": true,\n\"allow_sync_export\": true\n}\n],\n\"asset_sync_configs\": []\n}\nYou can change the configuration from the CLI using tapcli universe federation config global --proof_type issuance --allow_insert true and again with the --proof_type transfer flag\nThe default universe\nBy default, your tapd will connect to the default universe, for instance signet.universe.lightning.finance:10029 for signet, or universe.lightning.finance:10029 on mainnet.\nThe contents of the default universe are also available via a public REST API:\nhttps://universe.lightning.finance/v1/taproot-assets/universe/roots universe.lightning.finance\nYou may also make use of the UI available through Lightning Terminal\nAssets - Lightning Terminal terminal.lightning.engineering\nFederations\nA federation is a list of universes your tapd node connect to. You can see this federation with tapcli universe federation list .\nAt first, your federation consists only of the default universe (mentioned above). If you don't want to use the default universe, set universe.no-default-federation=true in tapd.conf so that it isn't automatically added to your federation list.\nYou can manually add additional universes to your federation that your tapd node pushes to and pulls from. You can do this on with tapcli universe federation add --universe_host \nSimilarly, you can remove universes from this federation with tapcli universe federation del --universe_host :port\nTapping into Taproot Assets #4: Join a Universe Federation\nSyncing to a universe\nBy default, your tapd will sync to universes which have configured in your local federation, and only for assets which you either hold or have created a taproot address for. You may also manually sync specific asset IDs or group keys.\ntapcli universe sync --universe_host --group_key \nTo configure your tapd to regularly sync to other asset IDs or group keys, you may use the universe federation configuration. The config global options will apply to all assets, while the config local options will only apply to specific assets.\ntapcli universe federation config global --proof_type issuance --allow_insert true\ntapcli universe federation config local --proof_type transfer --allow_insert true --group_key \nThe Universe APIs\nA Taproot Asset Universe is available over gRPC and REST on the default ports. You may run your own universe or interact with a public universe. Public universes are unauthenticated, the macaroon checks are skipped.\nFor instance, when making a transfer, the proofs may be pushed to one or multiple universes using the REST API. This requires the asset ID, the leaf key index and script key.\n/v1/taproot-assets/universe/proofs/asset-id/{key.id.asset_id_str}/{key.leaf_key.op.hash_str}/{key.leaf_key.op.index}/{key.leaf_key.script_key_str}\nA detailed list of all available fields as well as code examples can be found under the Taproot Assets Universe API documentation.\nPrevious Collectibles\nNext Asset Loop\nLast updated 7 months ago\nWas this helpful?\n- Your local universe\n- Running a public universe\n- The default universe\n- Federations\n- Syncing to a universe\n- The Universe APIs\nWas this helpful?"}
{"url":"https://www.helius.dev/docs/pre-confirmations/preconf-subscribe","domain":"www.helius.dev","title":"How to Use preconfSubscribe - Helius Docs","hash":"b42177f1a2c1e5408a5c79e6f38a8ae76eb1ca6d1880b146ddb44ec83471bd5a","tokens":3403,"chars":13609,"crawler":"crawler-tpoe","verified":"exact","ts":1791112303199,"text":"Documentation Index\nFetch the complete documentation index at: /docs/llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNew: Try Gatekeeper (Beta) for significantly lower latency. Learn More\nHelius Docs home page\n- Support\n-\nGet started\nHelius Docs home page\nPreconfirmations\nHow to Use preconfSubscribe\nStream Solana transactions at the lowest possible latency with the preconfSubscribe WebSocket method â subscribe, filter, and decode the payload.\nUse Sender Max (min tip: 0.001 SOL) to\nact on Preconfirmations. A preconfirmation only pays off if you land your\ntransaction\nfirst â Sender Max is the fastest way to do that. Build on Sender Max from the\nstart to get the full benefit of Preconfirmations.\nWhat is preconfSubscribe ?\npreconfSubscribe is a Helius WebSocket method that streams Preconfirmations â transactions delivered before they are collected into entries and shredded. It is the lowest-latency transaction signal Helius offers. One subscription delivers both Helius preconfirmations, emitted the instant the leader executes the transaction and carrying its execution status, and BAM preconfirmations from validators running Jitoâs Block Assembly Marketplace client, emitted when the validator commits to executing the transaction. Access requires a Professional plan or higher â see Pricing .\nThe stream is not continuous. Coverage scales with the share of stake\nforwarding to Helius or running BAM, so expect slots with no messages â handle\nthese gaps gracefully. See Coverage .\npreconfSubscribe is served from wss://beta.helius-rpc.com â the Helius Gatekeeper endpoint â rather than mainnet.helius-rpc.com . Authenticate with your API key as a query parameter.\nwss://beta.helius-rpc.com/?api-key=\nThe beta hostname refers to the Gatekeeper rollout,\nnot the maturity of Preconfirmations. Preconfirmations launch on the\nGatekeeper endpoint first; it will become the standard endpoint as Helius\nmigrates traffic to Gatekeeper.\nSubscribe\nSend a JSON-RPC request with the preconfSubscribe method. The server responds with a subscription ID, then streams a notification for each transaction. Pass an optional filter as the first params element to receive only matching transactions; omit params to receive the full stream from both Helius and BAM.\n{\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"preconfSubscribe\"\n}\nSubscribe Response\n{\n\"jsonrpc\" : \"2.0\" ,\n\"result\" : 24040 ,\n\"id\" : 1\n}\nStore the result â it is the subscription ID you use to unsubscribe . After this acknowledgement, notifications stream as binary frames (see below).\nFiltering\nBy default preconfSubscribe streams every transaction from both sources. To narrow the stream, pass a filter object as the first element of params . Filtering happens server-side, so you only pay for and receive the transactions you care about.\n{\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"preconfSubscribe\" ,\n\"params\" : [\n{\n\"includeBam\" : true ,\n\"failed\" : false ,\n\"regionInclude\" : [ \"ewr\" , \"fra\" ],\n\"accountInclude\" : [ \"9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\" ],\n\"accountExclude\" : [ \"TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA\" ],\n\"accountRequired\" : [ \"11111111111111111111111111111111\" ]\n}\n]\n}\nEvery field is optional â a missing field means âno constraintâ for that predicate, so an empty filter (or no params ) matches every transaction from both sources.\nField Type Semantics\nincludeBam boolean Defaults to true . false drops BAM preconfirmations so you receive Helius preconfirmations only.\nfailed boolean true returns only failed (reverted) transactions; false returns only successful transactions. Either value excludes Helius transactions with unknown status. Omit the field to receive all statuses.\nregionInclude string[] If non-empty, the transaction must originate from one of these regions .\naccountInclude string[] If non-empty, the transaction must reference at least one of these accounts.\naccountExclude string[] The transaction is dropped if it references any of these accounts. Takes precedence over accountInclude .\naccountRequired string[] The transaction must reference all of these accounts.\nsignerInclude string[] If non-empty, the transaction must be signed by at least one of these accounts.\nFilter rules:\n- All predicates are ANDed together, evaluated in the order includeBam â failed â regionInclude â accountExclude â accountRequired â accountInclude â signerInclude .\n- Preconfirmations with unknown status ignore the failed status filter and are still delivered if they match the source, region, and account filters.\n- Accounts are base58-encoded pubkeys. An invalid value returns JSON-RPC error -32602 (invalid params).\n- Each account list is capped at 500 entries.\nTo receive Helius preconfirmations only:\n{\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"preconfSubscribe\" ,\n\"params\" : [{ \"includeBam\" : false }]\n}\nAddress lookup table (ALT) resolution\nAccount filters match more than the transactionâs static account keys â Helius resolves v0 address lookup tables server-side, so accountInclude , accountExclude , and accountRequired also match accounts a transaction loads through an ALT.\nThis means you can filter on any account a transaction touches, even when it only appears behind a lookup table â no need to maintain ALT mappings or resolve tables yourself. Just pass the accountâs pubkey and Helius handles the resolution before the filter is applied.\nLocation filtering\nUse regionInclude to receive only transactions that originate from specific regions. Pass one or more region codes; a transaction passes when its origin region matches any of them.\n{\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"method\" : \"preconfSubscribe\" ,\n\"params\" : [{ \"regionInclude\" : [ \"ewr\" , \"fra\" ] }]\n}\nThe origin region depends on the source. For Helius preconfirmations it is the Helius region that ingested the transaction. For BAM preconfirmations it is the regional BAM endpoint that emitted the preconfirmation, not where Helius ingested it. BAMâs Singapore and Dallas endpoints map to sgp and dal .\nValid region codes:\nCode Location\nslc Salt Lake City\nfra Frankfurt\nlon London\npit Pittsburgh\nsgp Singapore\newr Newark\ntyo Tokyo\nams Amsterdam\ndal Dallas\ndub Dublin\nmia Miami\nlax Los Angeles\niad Ashburn\nsea Seattle\nhkg Hong Kong\nsqq Ć iauliai, Lithuania\nWhen regionInclude is set, transactions that donât carry region information are dropped. An unrecognized region code returns JSON-RPC error -32602 (invalid params).\nNotification payload\nNotifications are delivered as binary WebSocket frames (not JSON). Helius and BAM preconfirmations share the same layout. Each frame is a packed byte layout carrying a single transaction:\nBytes Field Type Description\n0 version u8 Payload schema version. Currently 1 .\n1â8 slot u64 (little-endian) The slot the transaction belongs to.\n9â16 tx_index u64 (little-endian) Index of the transaction within the slot. Always 0 for BAM preconfirmations â BAM orders transactions by sequence ID and bundle position rather than a slot index, and neither is carried on this stream.\n17 status u8 Transaction status: 0 = failed, 1 = success, 2 = unknown.\n18+ transaction bytes The transaction in Solana wire format. See Decoding the transaction .\nThe payload has no source field. Donât infer a BAM origin from tx_index = 0 , since Helius preconfirmations can carry the same values.\nTelling the two sources apart\nBecause there is no source field, you cannot label an arbitrary message as Helius or BAM. The status byte gives you a one-way classifier:\n- status is 0 or 1 â the message is a Helius preconfirmation and the transaction has executed. BAM never reports these values.\n- status is 2 â the source is ambiguous: either a BAM preconfirmation, or a Helius preconfirmation whose execution status was unavailable.\nNo other field discriminates. BAMâs sequence ID and bundle position are not carried on this stream, so there is no BAM ordering metadata to key on, and regionInclude is a subscription filter rather than a payload field, so it canât be read per message.\nIf you need every message on a stream to carry the same kind of evidence, set includeBam: false â that leaves only Helius preconfirmations, all emitted at leader execution. There is no BAM-only filter.\nAlways read and check the version byte first. It is currently 1 . If\nHelius needs to update the payload format, the version will increment â branch\non it so your decoder keeps working across schema changes.\nA preconfirmation is an early signal, not a guarantee. The transaction has not\nyet landed onchain and could still be dropped â and a Helius preconfirmationâs\nexecution status reflects the leaderâs local result, which is not final until\nthe block is confirmed. Confirm landing through standard commitment checks\nbefore treating it as final.\nDecoding the transaction\nThe transaction bytes are forwarded exactly as the validator serialized them, in the standard wire encoding for the transactionâs version. Legacy and v0 transactions use the signatures-first layout that bincode produces. Transaction v1 ( SIMD-0385 ) uses a message-first layout with signatures at the end, so bincode fails on v1 payloads. Use a decoder that handles every version:\n- Rust: agave-transaction-view parses legacy, v0, and v1 transactions in place, without an intermediate copy. This is the recommended option. wincode , the bincode-compatible serializer used by current Solana SDKs, also decodes v1 into VersionedTransaction .\n- JavaScript / TypeScript: make sure your library version supports transaction v1. Older VersionedTransaction.deserialize implementations only handle legacy and v0. Use @solana/kit 8.0+ or @solana/web3.js v3. See Transaction v1 support .\nuse agave_transaction_view :: transaction_view :: TransactionView ;\n// `frame` is the full binary WebSocket message\nlet tx_bytes = & frame [ 18 .. ];\nlet tx = TransactionView :: try_new_unsanitized ( tx_bytes ) ? ;\nprintln! ( \"version: {:?}\" , tx . version ()); // Legacy, V0, or V1\nprintln! ( \"signature: {}\" , tx . signatures ()[ 0 ]);\nfor ix in tx . instructions_iter () {\nprintln! ( \"program index {}: {} bytes\" , ix . program_id_index, ix . data . len ());\n}\nDuplicate notifications\nHelius and BAM preconfirmations are deduplicated per source, not across sources. A small share of transactions reach Helius through both, so you can receive the same signature twice, and the two copies may report different slots.\nDeduplicate by signature on the client and make transaction-triggered actions idempotent, so a second notification does not fire the same action twice. Confirm execution and landing through standard commitment checks.\nExample\nconst WebSocket = require ( 'ws' );\nconst ws = new WebSocket ( 'wss://beta.helius-rpc.com/?api-key=' );\nws . on ( 'open' , () => {\nws . send ( JSON . stringify ({\njsonrpc: '2.0' ,\nid: 1 ,\nmethod: 'preconfSubscribe' // Helius and BAM preconfirmations by default\n// Optional: txs from EWR/FRA touching a given account; Helius txs must be successful.\n// BAM ignores the status filter; region and account filters still apply.\n// params: [{ failed: false, regionInclude: ['ewr', 'fra'], accountInclude: ['9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM'] }]\n// Optional: Helius preconfirmations only\n// params: [{ includeBam: false }]\n}));\n// Keep the connection alive\nsetInterval (() => ws . ping (), 30_000 );\n});\nws . on ( 'message' , ( data , isBinary ) => {\n// The subscribe acknowledgement arrives as a JSON text frame\nif ( ! isBinary ) {\nconst msg = JSON . parse ( data . toString ());\nif ( msg . id === 1 ) console . log ( 'Subscribed, ID:' , msg . result );\nreturn ;\n}\n// Notifications arrive as binary frames:\n// version (u8) | slot (u64 LE) | tx_index (u64 LE) | status (u8) | transaction bytes\nconst buf = Buffer . from ( data );\nconst version = buf . readUInt8 ( 0 ); // currently 1 â branch on this if it changes\nif ( version !== 1 ) return ; // unknown schema version; update your decoder\nconst slot = buf . readBigUInt64LE ( 1 );\nconst txIndex = buf . readBigUInt64LE ( 9 ); // always 0 for BAM preconfirmations\nconst status = buf . readUInt8 ( 17 ); // 0 = failed, 1 = success, 2 = unknown\nconst txBytes = buf . subarray ( 18 ); // transaction in Solana wire format (legacy, v0, or v1)\nconsole . log ( 'Preconfirmation:' , { version , slot , txIndex , status , bytes: txBytes . length });\n// Decode txBytes with a decoder that supports transaction v1 (see \"Decoding the transaction\")\n});\nws . on ( 'error' , console . error );\nws . on ( 'close' , () => process . exit ( 1 ));\nUnsubscribing\nTo stop receiving notifications, call preconfUnsubscribe with the subscription ID returned from preconfSubscribe .\n{\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 2 ,\n\"method\" : \"preconfUnsubscribe\" ,\n\"params\" : [ 24040 ]\n}\n{\n\"jsonrpc\" : \"2.0\" ,\n\"result\" : true ,\n\"id\" : 2\n}\nPricing\nPreconfirmations require a Professional plan or higher and cost 10 credits per message â one message per streamed transaction â billed from your plan. See Credits for details.\nBilling is per message, not per unique signature. A transaction delivered by both Helius and BAM counts twice. Set includeBam: false if you only want Helius preconfirmations.\nPreconfirmations is a new product and pricing is subject to change.\nRelated\nPreconfirmations Overview\nWhat Preconfirmations are and where they sit in the validator pipeline.\ntransactionSubscribe\nStream confirmed-commitment transactions with rich filtering.\npreconfSubscribe API reference\nRequest parameters, filter fields, and the binary notification layout.\nWas this page helpful?\nâ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://developers.skyeco.com/protocol/tokens/stusds/","domain":"developers.skyeco.com","title":"stUSDS (Staked USDS) | Sky Protocol Docs","hash":"502aab2bde53305616529fc1791cb34fe933d8c61d454e40358b80bf4a964141","tokens":360,"chars":1438,"crawler":"crawler-tpoe","verified":"exact","ts":1791112304771,"text":"Skip to content\nSky Protocol Docs\nGitHub\nSelect theme\nstUSDS (Staked USDS)\nstUSDS, the first Expert token of the Sky Protocol, is a risk capital token that funds and supports liquidity for SKY stakers and structured to absorb a greater share of system risk in exchange for the potential to capture a larger portion of protocol rewards. When you supply USDS to the stUSDS module of the Protocol, you fund SKY (governance token)-backed borrowing to receive stUSDS tokens and access the stUSDS Rate. stUSDS funds and supports liquidity for SKY stakers, encouraging more participation in SKY governance, leading to a more secure ecosystem.\nDeployments\nSection titled âDeploymentsâ\nstUSDS Token and Vault @ Ethereum\nSection titled âstUSDS Token and Vault @ Ethereumâ\n- Codebase\n- Deployment Addresses\n- Details\n- Contract contains an ERC20 compatible interface to allow users to view and transfer their stUSDS balances, along with Permit functionality for gas-less transfers.\n- Contract contains an ERC4626 compatible interface to allow users to deposit USDS to receive stUSDS or withdraw USDS with their stUSDS balance.\n- Both the entry functions deposit() and mint() have an additional variant each- one is the standard 4626 function, and the other has an additional input field referral (uint16) which can be ignored.\nReleased into the public domain (CC0 1.0 Universal) â trademarks remain with their owners; no warranty. See full license ."}
{"url":"https://docs.ton.org/contracts/standard/overview","domain":"docs.ton.org","title":"Standard contracts","hash":"d2078ff44e19b3cc68db5bd04dea1d9ba3900436391d58e831b0039fcd30a298","tokens":622,"chars":2488,"crawler":"hive-genesis","verified":"unchecked","ts":1791112304025,"text":"Onboarding Nodes Applications APIs Contracts Smart contracts Tolk Tolk language TVM TON Virtual Machine Foundations Blockchain foundations\nStandard contracts\nThis sub-section lists the most popular standardized contracts and describes how to work with them without developing new ones. For the latter, see Techniques and the rest of the Smart contracts and Tolk language sections.\nWallets\nOn TON, wallets are smart contracts that operate under the same rules as any other contract on the blockchain. Their distinctive feature is to act as a proxy: wallets handle an external message sent from off-chain, verify that the message was sent by the wallet's owner using public-key cryptography, and send an internal message somewhere further on-chain.\nTON wallet mnemonics\nDerivation of Ed25519 key pairs from mnemonics and vice versa.\nComparison of wallet contracts\nAll wallets process incoming external messages, yet different versions implement different custom logic, suitable for various use cases.\nWallet V5\nThe most modern consumer version of a wallet contract. On top of the previous functionality, it can handle gasless transfers.\nWallet V4\nPrevious version of a consumer wallet contract. On top of the previous functionality, it can install custom plugins.\nHighload wallets\nSpecialized wallet contracts designed for services and platforms that need to send hundreds of transactions per second with low transfer fees.\nLockup wallets\nSpecialized wallets that lock for a defined period of time until certain timestamp.\nTokens\nTON blockchain supports three distinct categories of digital tokens: Jettons , NFTs , and SBTs . All of them utilize the single metadata standard .\nFungible tokens (Jettons)\nJettons serve as TON's counterpart to Ethereum's ERC-20 tokens, operating as the primary means of creating new currencies.\nNon-Fungible tokens (NFTs)\nNFTs represent the digital embodiment of uniqueness within the TON ecosystem, a distinct entity unlike jettons.\nSoul-bound tokens (SBTs)\nSBTs are non-transferable NFTs that are bound to a single owner.\nToken metadata\nThe metadata standard for jettons, NFTs, and NFT collections as described in the TEP-64.\nTo solve the problem of distributing on-chain assets at scale, use token airdrops .\nMiscellaneous\nVesting contracts\nFinancial agreements that outlines how and when an individual earns rights to certain assets over a specified period.\nVSCode and forks\nPrevious Page\nHow they work\nNext Page\nOn this page\nWallets Tokens Miscellaneous"}
{"url":"https://docs.orca.so/api-reference/overview","domain":"docs.orca.so","title":"API Overview - Orca Documentation","hash":"477cac5301d5f32f7bbfc34121b8b2133e445dd08af6a5605eb20515fdb55fea","tokens":645,"chars":2578,"crawler":"hive-genesis","verified":"unchecked","ts":1791112305729,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nOverview\nAPI Overview\nAccess Orcaâs public REST API for pool data, token information, and protocol analytics.\nOrca Public API\nThe Orca Public API provides programmatic access to Whirlpool data, token information, and protocol analytics on Solana.\nBase URL\nhttps://api.orca.so/v2/{chain}\nChain Base URL\nSolana https://api.orca.so/v2/solana\nAuthentication\nThe Orca Public API is open and does not require authentication for read access.\nRate Limits\nThe API implements rate limiting to ensure fair usage. If you receive a 429 status code, reduce your request frequency.\nResponse Format\nAll responses follow a consistent wrapper format with pagination support:\n{\n\"data\" :
\n
\n\n
\n\nData APIs\n
\n\nAccess data APIs for the C-Chain, P-Chain, and X-Chain.\n\n\n
\n\n\n
"}
{"url":"https://docs.across.to/","domain":"docs.across.to","title":"Across Developer Documentation","hash":"b72a61491b23761808b6af4126c0561b31ab7e55f0241373ca10d1b0b225e8cc","tokens":103,"chars":409,"crawler":"hive-genesis","verified":"exact","ts":1791111955996,"text":"New Bridge to Hyperliquid for free\nAcross Developer Documentation\nThe fastest crosschain infrastructure for builders.\n$40B+\nBridged\n<2s\nFill Time\n26+\nChains\nIntegrate Across\nStart building with the Swap API and go live in under an hour.\nAPI Reference\nFull endpoint docs with parameters, schemas, and code samples.\nAI Agents\nLet AI agents execute cross-chain actions on behalf of users.\nBug Bounty Troubleshoot"}
{"url":"https://docs.farcaster.xyz/","domain":"docs.farcaster.xyz","title":"Farcaster Docs","hash":"26e1937b637cc5ef038c4161f6e9eac9a24f7b0c86ce1adf20dea7796a697f74","tokens":255,"chars":1017,"crawler":"hive-genesis","verified":"unchecked","ts":1791111957820,"text":"Farcaster docs\nFarcaster Docs\nPermissionlessly build and distribute social apps\nBuild a mini app Explore Sign In with Farcaster Learn about the protocol\nBuild a Mini App\nLearn how to build Mini Apps (previously known as Frames v2) that run inside a Farcaster feed.\n- Introduction to Mini Apps - Understand what a mini app is and how it works.\n- Build your first Mini App - Make mini apps that run inside Farcaster.\nExplore Sign In with Farcaster\nAllow users to Sign In with Farcaster and leverage social data in your app.\n- Introduction - Learn about Sign In with Farcaster.\n- Add SIWF using AuthKit - a React toolkit to add SIWF to your app.\n- Examples - see Sign In with Farcaster in action.\nAnalyze Farcaster data\nSync the Farcaster network to a local machine so you can run queries on the data.\n- Write your first snapchain query - get an account's casts from a snapchain node.\n- Set up the replicator - sync a snapchain node to a postgres database.\n- Run a snapchain node - get realtime access to Farcaster data."}
{"url":"https://docs.sei.io/learn/proposals","domain":"docs.sei.io","title":"Proposals - Sei Docs","hash":"856e7c06b5cae5969e15e59d82b95c6614a9406dfdb3aad0edd3085ac9a07fbf","tokens":1022,"chars":4086,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111958070,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nSei Docs home page\nLearn\nEVM\nCosmos-SDK\nNodes\nAI\nProposals\nComplete guide to Sei governance proposals. Learn about different proposal types and how to submit them.\nThis guide shows how to create and submit governance proposals on Sei. It covers the proposal types, their requirements, and the submission commands.\nFor governance parameters and voting requirements, see the Overview section.\nProposal types & submission\nText proposals\nText proposals are non-binding proposals for community discussion. Use them to collect community input and build consensus on important topics.\nCommon uses\n- Strategic direction\n- Policy agreements\n- Network guidelines\nExamples\n- Community input and consensus building\n- Non-binding governance decisions\n- Foundation for policy discussions\n- Protocol direction and priorities\nseid tx gov submit-proposal \\\n--title \"Community Initiative Proposal\" \\\n--description \"Detailed description of the initiative...\" \\\n--type Text \\\n--deposit 3500000000usei \\\n--from mykey \\\n--chain-id pacific-1\nParameter change proposals\nParameter change proposals modify network parameters without a software upgrade.\nCommon changes\n- Governance parameters\n- Staking parameters\n- Fee structures\nPrerequisites\n- Valid JSON format\n- Complete documentation of the change\n- Impact assessment\n- Testing results\nseid tx gov submit-proposal param-change proposal.json \\\n--deposit 3500000000usei \\\n--from mykey \\\n--chain-id pacific-1\nExample proposal.json :\n{\n\"title\" : \"Update Staking Parameters\" ,\n\"description\" : \"This proposal updates the maximum number of validators from 100 to 125.\" ,\n\"changes\" : [\n{\n\"subspace\" : \"staking\" ,\n\"key\" : \"MaxValidators\" ,\n\"value\" : 125\n}\n]\n}\nSoftware upgrade proposals\nSoftware upgrade proposals coordinate network-wide software upgrades. The upgrade executes automatically at a specified block height.\nCommon uses\n- Protocol upgrades\n- Security patches\n- New features\n- Performance improvements\nPrerequisites\n- Upgrade height specification\n- Binary release information\n- Migration documentation\n- Validator coordination\nseid tx gov submit-proposal software-upgrade v2.1.0 \\\n--upgrade-height 15000000 \\\n--upgrade-info \"https://github.com/sei-protocol/sei-chain/releases/v2.1.0\" \\\n--title \"Sei v2.1.0 Upgrade\" \\\n--description \"Network upgrade to v2.1.0 with enhanced performance\" \\\n--deposit 3500000000usei \\\n--from mykey \\\n--chain-id pacific-1\nExpedited proposals\nExpedited proposals are a fast-track process for urgent network changes that need immediate attention. They have higher deposit and approval requirements, and a shorter timeline.\n- Security patches and critical fixes\n- Emergency parameter adjustments\n- Time-sensitive network upgrades\nseid tx gov submit-proposal software-upgrade emergency-patch \\\n--upgrade-height 15100000 \\\n--upgrade-info \"https://github.com/sei-protocol/sei-chain/releases/emergency-patch\" \\\n--title \"Emergency Security Patch\" \\\n--description \"Critical security fix requiring immediate deployment\" \\\n--deposit 7000000000usei \\\n--expedited \\\n--from mykey \\\n--chain-id pacific-1\nProposal management\nQuery & monitor\nCommand Purpose Example\nseid q gov proposals List all proposals --status voting_period\nseid q gov proposal [id] Get a specific proposal seid q gov proposal 42\nseid q gov votes [id] Check voting results seid q gov votes 42\nseid q gov tally [id] View vote tally seid q gov tally 42\nVoting\n# Vote on a proposal\nseid tx gov vote [proposal-id] [vote-option] \\\n--from mykey \\\n--chain-id pacific-1\n# Vote options: yes, no, abstain, no_with_veto\nseid tx gov vote 42 yes \\\n--from mykey \\\n--chain-id pacific-1\nDeposit management\n# Add deposit to proposal\nseid tx gov deposit [proposal-id] [amount] \\\n--from mykey \\\n--chain-id pacific-1\n# Example: Add 1000 SEI to proposal 42\nseid tx gov deposit 42 1000000000usei \\\n--from mykey \\\n--chain-id pacific-1\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.anchor-lang.com/docs","domain":"www.anchor-lang.com","title":"Introduction","hash":"d94f4b1ad24780aa70d91f351f31088e6440c19efb303267de80435024216953","tokens":199,"chars":794,"crawler":"hive-genesis","verified":"unchecked","ts":1791111959674,"text":"Anchor Docs\nGithub Discord Stack Exchange\nIntroduction\nAnchor is a development framework for building secure Solana programs (smart contracts)\nAnchor is the leading development framework for building Solana programs (smart\ncontracts) and simplifies the process of writing, testing, deploying, and\ninteracting with Solana programs.\nThe Anchor framework helps developers build production-ready applications faster\nwhile reducing potential vulnerabilities through built-in security features.\nWhere to start?\nInstallation\nStep-by-step guide to install Anchor framework. Set up your local development\nenvironment.\nQuickstart\nQuickstart guide to start building Solana programs with Anchor. Start building\ndirectly in your browser. No installation required.\nOn this page\nWhere to start?\nEdit on GitHub"}
{"url":"https://discuss.ens.domains/latest","domain":"discuss.ens.domains","title":"Latest topics - ENS DAO Governance Forum","hash":"9b3011769c865f1d08aee1022dc3b86ee215926161cb2833ef1399d2e09cf0da","tokens":744,"chars":2973,"crawler":"crawler-dfxz","verified":"exact","ts":1791111959920,"text":"ENS DAO Governance Forum\nTopic\nReplies\nViews\nActivity\nGovernance Process\nMetaGov Discussion\nWant to contribute to ENSâs governance? Here are the steps.\n1. Familiarise yourself with our governance process\nProposals follow three basic steps:\nTemperature check. Post to the worksteamâs Temp Check category to getâŠ\n3\n13599\nMarch 29, 2023\nProposal & Core Contribution] Resolving 2300 Gas Reverts for Smart Contract Wallets (ERC-4337 & Safe) in ENS Controller â PR #577\nCommunity\n1\n24\nOctober 4, 2026\nMeta-Gov Working Group Term 7 Meetings: Thursday, 4pm UTC. Bi-weekly\nMeetings/events\n12\n616\nOctober 4, 2026\nNamespace - Quarterly Reports\nReports\nservice-providers\n10\n2079\nOctober 2, 2026\nNamespace: SPP3 Quarterly Reports\nReports\nservice-providers\n1\n91\nOctober 2, 2026\nENS Financial Reporting by Steakhouse\nTreasury Management\n53\n9295\nOctober 1, 2026\nENS DAO Newsletter #121 â 10/1/2026\nNewsletter\nnewsletter\n0\n33\nOctober 1, 2026\nENS Advisor: buy an expiring .eth name at your budget without handing anyone your ETH, plus a weekly .eth sales report\nCommunity\n0\n32\nOctober 1, 2026\nMetaGov Transaction Transparency (Term 7 Index)\nDAO-Wide\n5\n175\nSeptember 30, 2026\nFinal ENS Retro Report\nDAO-Wide\n4\n227\nSeptember 28, 2026\nGovernor Nexus - Implementation report\nDAO-Governance\n6\n235\nSeptember 28, 2026\n[RFC] Delegation Increase Incentives System\nDAO-Governance\n29\n1087\nSeptember 28, 2026\n[DRAFT] Endowment permissions to KPK Update #10\nDraft Proposal\n6\n233\nSeptember 27, 2026\nENSIP-31: Payment Preferences\nStandards\nensip\n2\n104\nSeptember 21, 2026\n[Research] ENS-GR-01: A Ten-Proposal Governance Record for Delegation Incentives\nDAO-Governance\n1\n101\nSeptember 21, 2026\nEndowment Monthly Reports\nTreasury Management\n41\n19343\nSeptember 17, 2026\nENS DAO Newsletter #120 â 09/15/2026\nNewsletter\nnewsletter\n0\n69\nSeptember 15, 2026\nENSIP: Stealth Address Resolution\nStandards\nensip\n8\n377\nSeptember 15, 2026\nENSIP: Text Record Attestations\nStandards\n11\n231\nSeptember 15, 2026\nensforge: A unified TypeScript SDK for ENSv1 and ENSv2\nđ§âđ» ENS Development\n2\n113\nSeptember 15, 2026\nIntroduction & Study on ENS DAO Governance Dynamics\nđŹ General Discussion\n0\n60\nSeptember 14, 2026\nBlockful - service provider reports and updates\nReports\nservice-providers\n11\n1018\nSeptember 8, 2026\nSafeNotes Shutting Down\nDAO-Wide\n1\n113\nSeptember 3, 2026\nENSIP-28: ENS Name Owned Accounts\nStandards\nensip\n11\n172\nSeptember 2, 2026\nENS DAO Newsletter #119 â 09/01/2026\nNewsletter\nnewsletter\n0\n67\nSeptember 1, 2026\nđłïž Voting Period Bulletin â Term 7\nđłïž Meta-Governance\nvoting\n3\n128\nSeptember 1, 2026\nReport: Measuring the Impact of ENSâs P-256 Precompile Migration\nEcosystem Discussion\n1\n115\nSeptember 1, 2026\n[Executable] SPP3 Marketplace RFP Award: Nomentum Labs (Grails)\nArchived Proposals\n2\n152\nSeptember 1, 2026\nSPP3: Marketplace RFP Recommendation\nProgram Discussion and Admin\nservice-providers\n1\n261\nAugust 27, 2026\nGoldsky: SPP3 Quarterly Reports\nReports\nservice-providers\n0\n59\nAugust 26, 2026\nnext page â"}
{"url":"https://docs.phantom.com/introduction","domain":"docs.phantom.com","title":"Build with Phantom - Phantom developer documentation","hash":"46cbfdc417ae95dd1886aa8eec0c6fc3c8a6df764fd47840636cbca95b99067f","tokens":679,"chars":2716,"crawler":"hive-genesis","verified":"exact","ts":1791111961554,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nPhantom developer documentation home page\nGet started\nPhantom MCP server\nPhantom CLI\nPhantom Portal\nPhantom Connect SDKs\nRecipes\nDeveloper tools and resources\nOverview\nBuild with Phantom\nIntegrate wallet functionality into your apps with Phantomâs powerful SDKs\nPhantom 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 .\nWhat are you building for?\nAI agents\nGive AI agents a Phantom wallet. The Phantom MCP server lets agents sign transactions, transfer tokens, and interact on-chain. Or build skills and services for those users.\nApp users\nBuild apps with Phantom Connect SDKs. Integrate embedded wallets and social login into your web or mobile app.\nPhantom 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:\nWallet operations\nView addresses and balances, send transactions, sign messages on Solana and EVM chains\nSwaps and portfolio\nSwap tokens on Solana and EVM, cross-chain swaps, and portfolio rebalancing\nSet up the MCP server\nAdd the Phantom MCP server to Claude Desktop, Cursor, or Claude Code\nPhantom 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:\nReact SDK\nReact hooks for wallet integration in your apps with native transaction support\nReact Native SDK\nBuild mobile wallet experiences for iOS and Android with React Native\nBrowser SDK\nFramework-agnostic JavaScript SDK for wallet integration in web apps\nNot sure which SDK to use? Check out our SDK comparison guide to find the perfect fit for your use case.\nDeveloper resources\nRecipes and starter kits\nExplore starter templates and example implementations\nSandbox\nTest your integration in our interactive sandbox\nFAQ\nFind answers to common questions\nSupport\nGet help from our developer support team\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://eips.ethereum.org/EIPS/eip-7870","domain":"eips.ethereum.org","title":"EIP-7870: Hardware and Bandwidth Recommendations","hash":"47002f4b8a3fb8e9f77e58220aadd4cb4263da8f91e957b2dd935b72c4fe1752","tokens":2100,"chars":8400,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791111961505,"text":"Ethereum Improvement Proposals\nđ Living\nInformational\nEIP-7870: Hardware and Bandwidth Recommendations\nSystem recommendations for Validators and Full nodes\nAuthors\nParithosh 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 )\nCreated\n2025-01-26\nDiscussion Link\nhttps://ethereum-magicians.org/t/hardware-and-bandwidth-recommendations-for-full-nodes-and-validators/22675\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- Roles and Their Recommended Specifications\n- Rationale\n- Storage\n- Memory\n- CPU\n- Bandwidth\n- Quick Reference Summary\n- Backwards Compatibility\n- Security Considerations\n- Copyright\nAbstract\nThis proposal specifies hardware and bandwidth recommendations for different types of Ethereum nodes:\n- Full nodes : Nodes that follow the tip of the chain without necessarily proposing blocks.\n- Validators : Split into:\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.\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.\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.\nMotivation\nClear system specifications are crucial for:\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.\nWithout a shared understanding of target hardware specifications:\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.\nSpecification\nRoles and Their Recommended Specifications\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.\nNode Type\nStorage\nMemory\nCPU Cores / Threads\nPassMark CPU Rating\nBandwidth Download / Upload\nFull Node\n4 TB NVMe\n32 GB\n4c / 8t\n~1000 ST / 3000 MT\n50 Mbps / 15 Mbps\nAttester\n4 TB NVMe\n64 GB\n8c / 16t\n~3500 ST / 25000 MT\n50 Mbps / 25 Mbps\nLocal Block Builder\n4 TB NVMe\n64 GB\n8c / 16t\n~3500 ST / 25000 MT\n100 Mbps / 50 Mbps\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.\nRationale\nStorage\n- Recommended : 4 TB NVMe M.2 drive with:\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-\nVerifying IO Performance : You can use the following commands to benchmark your local storage IO speeds:\nSequential R/W:\nfio --name=seq --filename=test --direct=1 --ioengine=libaio --iodepth=64 --bs=1M --size=4G --rw=readwrite\nRandom 4K R/W:\nfio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75\n- Why NVMe over SATA?\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- On Endurance (TBW)\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- Capacity Considerations\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.\nMemory\n- Why 64 GB for Validators (Attesters / Local Block Builders)?\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.\nCPU\n- Single vs. Multi-thread Performance\n- Attesters and local block builders benefit from both high single-thread and multi-thread performance.\nBandwidth\nLocal Block Builders\n- Recommended : 100 Mbps download, 50 Mbps upload.\n- Rationale :\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.\nAttesters\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- 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- Rationale :\n- 25 Mbps was chosen as a buffer to account for these miscellaneous factors that are harder to predict.\nValidators Using MEV-Boost\n- Recommended : 50 Mbps download / 25 Mbps upload.\n- Rationale :\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.\nFull Nodes\n- Recommended : 50 Mbps download / 15 Mbps upload.\n- Rationale :\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.\nQuick Reference Summary\n- Full Node\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- Attester\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- Local Block Builder\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\nBackwards Compatibility\nThis EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware recommendations.\nSecurity Considerations\nN/A\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nParithosh 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."}
{"url":"https://solana.com/docs/core/pda","domain":"solana.com","title":"","hash":"0ce758dd495a0d74722bed55d942cbf28c1788f58af8a82cdedf2328589f425e","tokens":788,"chars":3152,"crawler":"crawler-dfxz","verified":"exact","ts":1791111963426,"text":"---\ntitle: Program Derived Addresses (PDAs)\ndescription:\nSolana Program Derived Addresses (PDAs) are deterministic, off-curve addresses\nderived from seeds and a program ID. No private key exists â only the deriving\nprogram can sign via invoke_signed.\nurl: /docs/core/pda\ntype: conceptual\nprerequisites:\n- /docs/core/accounts\n- /docs/core/programs\nrelated:\n- /docs/core/pda/pda-derivation\n- /docs/core/pda/pda-accounts\n- /docs/core/cpi\n---\nProgram Derived Addresses (PDAs) are 32-byte account addresses that are\ndeterministically derived from a program ID and a set of seeds. They are\nguaranteed to not lie on the Ed25519 curve, which means no private key exists\nfor them. Only the program whose ID was used in the derivation can \"sign\" for a\nPDA, and it does so through [`invoke_signed`](/docs/core/cpi) during\ncross-program invocations (CPIs).\n\n\n
\n\n
\n\nConsole\n
\n\nAccess developer tools, deploy contracts, and manage your blockchain infrastructure.\n\n\n
\n\n\n![](\"https://pbs.twimg.com/media/FVUVaO9XEAAulvK?format=png&name=small\")
\n
\n[Anchor](https://www.anchor-lang.com/) is a framework providing several convenient developer tools for writing Solana programs (sometimes called 'smart contracts').\n- Rust eDSL for writing Solana programs\n- [IDL](https://en.wikipedia.org/wiki/Interface_description_language) specification\n- TypeScript package for generating clients from IDL\n- CLI and workspace management for developing complete applications\nAnchor is the most popular framework for Solana programs.\n> [!NOTE]\n> If you're familiar with developing in Ethereum's [Solidity](https://docs.soliditylang.org/en/), [Truffle](https://www.trufflesuite.com/), [web3.js](https://github.com/ethereum/web3.js), then using Anchor will be familiar. Although the DSL syntax and semantics are targeted at Solana, the high level flow of writing RPC request handlers, emitting an IDL, and generating clients from IDL is the same.\n## Getting Started\nFor a quickstart guide and in depth tutorials, see the [Anchor documentation](https://www.anchor-lang.com/docs).\nTo jump straight to examples, go [here](https://github.com/otter-sec/anchor/tree/master/examples). For the latest Rust and TypeScript API documentation, see [docs.rs](https://docs.rs/anchor-lang) and the [typedoc](https://www.anchor-lang.com/docs/clients/typescript).\n## Installation\nThe recommended way to install the Anchor CLI is with the Anchor Version Manager (AVM).\n```sh\ncurl -sSfL https://raw.githubusercontent.com/otter-sec/anchor/master/avm/install | sh\n```\nThe installer downloads the latest nightly AVM and Anchor CLI binaries, enables\nthe nightly channel, and links the `avm` and `anchor` commands into\n`~/.cargo/bin` when possible. After that, `anchor` will use the latest cached\nnightly build and periodically check for updates.\nIf you already have AVM installed, you can enable the nightly channel directly:\n```sh\navm nightly\n```\nTo leave nightly mode and return to normal AVM version resolution, run:\n```sh\navm nightly --disable\n```\n## Packages\n| Package | Description | Version | Docs |\n| :---------------------- | :------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------- |\n| `anchor-lang` | Rust primitives for writing programs on Solana | [](https://crates.io/crates/anchor-lang) | [](https://docs.rs/anchor-lang) |\n| `anchor-spl` | CPI clients for SPL programs on Solana | [](https://crates.io/crates/anchor-spl) | [](https://docs.rs/anchor-spl) |\n| `anchor-client` | Rust client for Anchor programs | [](https://crates.io/crates/anchor-client) | [](https://docs.rs/anchor-client) |\n| `@anchor-lang/core` | TypeScript client for Anchor programs | [](https://www.npmjs.com/package/@anchor-lang/core) | [](https://otter-sec.github.io/anchor/ts/index.html) |\n| `@anchor-lang/cli` | CLI to support building and managing an Anchor workspace | [](https://www.npmjs.com/package/@anchor-lang/cli) | [](https://www.anchor-lang.com/docs/references/cli) |\n## Examples\nHere's a counter program, where only the designated `authority`\ncan increment the count.\n```rust\nuse anchor_lang::prelude::*;\ndeclare_id!(\"Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS\");\n#[program]\nmod counter {\nuse super::*;\npub fn initialize(ctx: Context\nAnchor
\n\nSolana Program Framework\n
\n\n![\"Build](\"https://github.com/otter-sec/anchor/actions/workflows/tests.yaml/badge.svg\"){kind=icon}
\n![\"Tutorials\"](\"https://img.shields.io/badge/docs-tutorials-blueviolet\"){kind=icon}
![\"Discord](\"https://img.shields.io/discord/889577356681945098?color=blueviolet\")
![\"License\"](\"https://img.shields.io/github/license/otter-sec/anchor?color=blueviolet\")
\n\n![](\"https://contrib.rocks/image?repo=otter-sec/anchor\")
\n\n
"}
{"url":"https://docs.cardano.org/pioneer-programs/community-education","domain":"docs.cardano.org","title":"Community education initiatives | Cardano Docs","hash":"23cbc2bc52cd7e4a6ff26e8b4dc8377b55793c8ce9a88cf196c2ef2cb36abc30","tokens":329,"chars":1315,"crawler":"hive-genesis","verified":"unchecked","ts":1791112001375,"text":"Skip to main content\nCommunity education initiatives\nThis section aims to highlight the diverse educational efforts led by the Cardano community.\nThis space is dedicated to showcasing resources, programs, and projects that support learning and skill development across the ecosystem. Whether itâs tutorials, workshops, or other community-driven content, this section aims to reflect the collective knowledge and commitment to growing Cardanoâs global reach.\ntip\nContributions are encouraged! Share your educational resources to expand this library and help others explore and understand Cardano. Please check the contribution guidelines and submit a pull request.\nCommunity education resources\n- Cardano Academy â learn about blockchain â empowering the digital architects of the future\n- IO Academy YouTube channel â explore learning resources and check out this section for more details\n- Gimbalabs â a space for people to learn about and participate in the Cardano blockchain\n- NMKR Docs â helping users find their way around NMKR to mint non-fungible tokens (NFTs) and fungible tokens on Cardano\n- CTimelines â Cardano Timeline and Research Timeline infographics documenting the ecosystemâs history in a visual, accessible format for learners and the wider community\nOn this page\n- Community education resources"}
{"url":"https://eips.ethereum.org/EIPS/eip-4337","domain":"eips.ethereum.org","title":"ERC-4337: Account Abstraction Using Alt Mempool","hash":"ab4cbd9b99e45ac9697e5069b5e8412229993367452fdc664dba5fac9a67d52c","tokens":9992,"chars":39967,"crawler":"hive-genesis","verified":"unchecked","ts":1791112002968,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: ERC\nERC-4337: Account Abstraction Using Alt Mempool\nAccount abstraction without consensus-layer protocol changes, instead relying on higher-layer infrastructure.\nAuthors\nVitalik Buterin ( @vbuterin ), Yoav Weiss ( @yoavw ), Dror Tirosh ( @drortirosh ), Shahaf Nacson ( @shahafn ), Alex Forshtat ( @forshtat ), Kristof Gazso ( @kristofgazso ), Tjaden Hess ( @tjade273 )\nCreated\n2021-09-29\nRequires\nEIP-712 ,\nEIP-7702\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- Definitions\n- The UserOperation structure\n- EntryPoint interface\n- Smart Contract Account Interface\n- Semi-abstracted Nonce Support\n- Required EntryPoint contract functionality\n- JSON-RPC API for ERC-4337\n- Support for EIP-712 signatures\n- Support for EIP-7702 authorizations\n- Extension: paymasters\n- Bundler behavior upon receiving a UserOperation\n- UserOperation Simulation\n- Estimating preVerificationGas\n- Alternative Mempools\n- Bundling\n- Error codes.\n- Factory contracts\n- Paymasters contracts\n- Aggregator contracts\n- EIP-7702 delegated Smart Contract Accounts\n- Smart Contract Accounts\n- Transient Storage\n- Rationale\n- Validation Rules Rationale\n- Reputation Rationale\n- Paymasters\n- First-time Smart Contract Account creation\n- Backwards Compatibility\n- Security Considerations\n- Copyright\nAbstract\nHistorically, users could interact with Ethereum only by sending transactions from special accounts controlled by private keys, with transaction validation entirely enforced by fixed protocol rules. Account abstraction is an alternative model that allows each account to supply its own validation logic executed as smart contract code, while the protocol provides only minimal constraints.\nThis document is an account abstraction proposal which completely avoids the need for consensus-layer protocol changes. Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a UserOperation . Users send UserOperation objects into a separate mempool. A special class of actor called bundlers package up a set of these objects into a transaction making a handleOps call to a special contract, and that transaction then gets included in a block.\nMotivation\nHistorically, introducing Account Abstraction has been a long-standing goal of the Ethereum protocol.\nA number of proposals have been thoroughly discussed, but so far none of them have been implemented in the protocol.\nThis proposal takes a different approach, avoiding any adjustments to the consensus layer. It seeks to achieve the following goals:\n- Achieve the key goal of Account Abstraction : allow users to use Smart Contract Accounts containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs,\nas required by both status quo Smart Contract Accounts and EIP-7702 .\n- Decentralization\n- Allow any bundler (think: block builder) to participate in the process of including account-abstracted UserOperations\n- Work with all activity happening over a public mempool; users do not need to know the direct communication addresses (eg. IP, onion) of any specific actors\n- Avoid trust assumptions on bundlers\n- Do not require any Ethereum consensus changes : Ethereum consensus layer development is focusing on scalability-oriented features, and there may not be any opportunity for further protocol changes for a long time. Hence, to increase the chance of faster adoption, this proposal avoids Ethereum consensus changes.\n- Support other use cases\n- Privacy-preserving applications\n- Atomic multi-operations (similar goal to EIP-7702 )\n- Pay tx fees with ERC-20 tokens, allow developers to pay fees for their users, and EIP-7702 -like sponsored transaction use cases more generally\n- abstracting the validation allows the contract to use different signature schemes, multisig configuration, custom recovery, and more.\n- abstracting gas payments allows easy onboarding by 3rd party payments, paying with tokens, cross-chain gas payments\n- abstracting execution allows bundled transactions\nSpecification\nDefinitions\n- UserOperation - a structure that describes a transaction to be sent on behalf of a user. To avoid confusion, it is not named âtransactionâ.\n- Like a transaction, it contains to , calldata , maxFeePerGas , maxPriorityFeePerGas , nonce , signature .\n- Unlike a transaction, it contains several other fields, described below.\n- Notably, the signature field usage is not defined by the protocol, but by the Smart Contract Account implementation.\n- Sender - the Smart Contract Account sending a UserOperation .\n- EntryPoint - a singleton contract to execute bundles of UserOperations . Bundlers should whitelist the supported EntryPoint .\n- Bundler - a node (block builder) that can handle UserOperations ,\ncreate a valid entryPoint.handleOps() transaction,\nand add it to the block while it is still valid.\nThis can be achieved by a number of ways:\n- Bundler can act as a block builder itself.\n- If the bundler is not a block builder, it should work with the block builder through an infrastructure such as mev-boost , or any other kind of proposer-builder separation.\n- Paymaster - a helper contract that agrees to pay for the transaction, instead of the sender itself.\n- Factory - a helper contract that performs a deployment for a new sender contract if necessary.\n- Aggregator - also known as âauthorizer contractâ - a contract that enables multiple UserOperations to share a single validation. The full design of such contracts is outside the scope of this proposal.\n- Canonical UserOperation mempool - a decentralized permissionless P2P network where bundlers exchange UserOperations that are valid and conform with the same shared set of rules applied to the validation code. The full specification of such rules is outside the scope of this proposal.\n- Alternative UserOperation mempool - any other P2P mempool where the validity of UserOperations is determined by rules that are different from the shared set of rules, applied to the validation code, in any way.\n- Deposit - an amount of Ether (or any L2 native currency) that a Sender or Paymaster contract has transferred to the EntryPoint contract intended to pay gas costs of the future UserOperations .\nThe UserOperation structure\nTo avoid Ethereum consensus changes, we do not attempt to create new transaction types for account-abstracted transactions. Instead, users package up the action they want their Smart Contract Account to take in a struct named UserOperation :\nField\nType\nDescription\nsender\naddress\nThe Account making the UserOperation\nnonce\nuint256\nAnti-replay parameter (see âSemi-abstracted Nonce Supportâ )\nfactory\naddress\nAccount Factory for new Accounts OR 0x7702 flag for EIP-7702 Accounts, otherwise address(0)\nfactoryData\nbytes\ndata for the Account Factory if factory is provided OR EIP-7702 initialization data, or empty array\ncallData\nbytes\nThe data to pass to the sender during the main execution call\ncallGasLimit\nuint256\nThe amount of gas to allocate the main execution call\nverificationGasLimit\nuint256\nThe amount of gas to allocate for the verification step\npreVerificationGas\nuint256\nExtra gas to pay the bundler\nmaxFeePerGas\nuint256\nMaximum fee per gas (similar to EIP-1559 max_fee_per_gas )\nmaxPriorityFeePerGas\nuint256\nMaximum priority fee per gas (similar to EIP-1559 max_priority_fee_per_gas )\npaymaster\naddress\nAddress of paymaster contract, (or empty, if the sender pays for gas by itself)\npaymasterVerificationGasLimit\nuint256\nThe amount of gas to allocate for the paymaster validation code (only if paymaster exists)\npaymasterPostOpGasLimit\nuint256\nThe amount of gas to allocate for the paymaster post-operation code (only if paymaster exists)\npaymasterData\nbytes\nData for paymaster (only if paymaster exists)\nsignature\nbytes\nData passed into the sender to verify authorization\nUsers send UserOperation objects to a dedicated UserOperation mempool.\nTo prevent replay attacks, either cross-chain or with multiple EntryPoint contract versions,\nthe signature MUST depend on chainid and the EntryPoint address.\nNote that one EIP-7702 âauthorization tupleâ value can be provided alongside the UserOperation struct,\nbut âauthorization tuplesâ are not included in the UserOperation itself.\nEntryPoint interface\nWhen passed on-chain, to the EntryPoint contract, the Account and the Paymaster , a âpackedâ version of the above structure called PackedUserOperation is used:\nField\nType\nDescription\nsender\naddress\nnonce\nuint256\ninitCode\nbytes\nconcatenation of factory address and factoryData (or empty), or EIP-7702 data\ncallData\nbytes\naccountGasLimits\nbytes32\nconcatenation of verificationGasLimit (16 bytes) and callGasLimit (16 bytes)\npreVerificationGas\nuint256\ngasFees\nbytes32\nconcatenation of maxPriorityFeePerGas (16 bytes) and maxFeePerGas (16 bytes)\npaymasterAndData\nbytes\nconcatenation of paymaster fields (or empty)\nsignature\nbytes\nThe core interface of the EntryPoint contract is as follows:\nfunction handleOps ( PackedUserOperation [] calldata ops , address payable beneficiary );\nThe beneficiary is the address that will be paid with all the gas fees collected during the execution of the bundle.\nSmart Contract Account Interface\nThe core interface required for the Smart Contract Account to have is:\ninterface IAccount {\nfunction validateUserOp\n( PackedUserOperation calldata userOp , bytes32 userOpHash , uint256 missingAccountFunds )\nexternal returns ( uint256 validationData );\n}\nThe userOpHash is a hash over the userOp (except signature ), entryPoint and chainId .\nThe Smart Contract Account:\n- MUST validate the caller is a trusted EntryPoint\n- MUST validate that the signature is a valid signature of the userOpHash , and\nSHOULD return SIG_VALIDATION_FAILED ( 1 ) without reverting on signature mismatch. Any other error MUST revert.\n- SHOULD not return early when returning SIG_VALIDATION_FAILED ( 1 ). Instead, it SHOULD complete the normal flow to enable performing a gas estimation for the validation function.\n- MUST pay the EntryPoint (caller) at least the missingAccountFunds (which might be zero, in case the current sender âs deposit is sufficient)\n- The sender MAY pay more than this minimum to cover future transactions. It can also call withdrawTo to retrieve it later at any time.\n- The return value MUST be packed of aggregator / authorizer , validUntil and validAfter timestamps.\n- aggregator / authorizer - 0 for valid signature, 1 to mark signature failure. Otherwise, an address of an aggregator / authorizer contract.\n- validUntil is 6-byte timestamp value, or zero for âinfiniteâ. The UserOperation is valid only up to this time.\n- validAfter is 6-byte timestamp. The UserOperation is valid only after this time.\n- In order to specify a validity range using block numbers, both the validUntil and validAfter need to set their highest bit to 1.\n- Note: The validity range can be expressed by two block timestamps or two block numbers, but one timestamp and one block number cannot be mixed in the same UserOperationâs validity range.\nThe Smart Contract Account MAY implement the interface IAccountExecute\ninterface IAccountExecute {\nfunction executeUserOp ( PackedUserOperation calldata userOp , bytes32 userOpHash ) external ;\n}\nThis method will be called by the EntryPoint with the current UserOperation, instead of executing the callData itself directly on the sender .\nSemi-abstracted Nonce Support\nIn Ethereum protocol, the sequential transaction nonce value is used as a replay protection method as well as to\ndetermine the valid order of transaction being included in blocks.\nIt also contributes to the transaction hash uniqueness, as a transaction by the same sender with the same\nnonce may not be included in the chain twice.\nHowever, requiring a single sequential nonce value is limiting to the sendersâ ability to define their custom logic\nwith regard to transaction ordering and replay protection.\nInstead of sequential nonce we implement a nonce mechanism that uses a single uint256 nonce value in the UserOperation ,\nbut treats it as two values:\n- 192-bit âkeyâ\n- 64-bit âsequenceâ\nThese values are represented on-chain in the EntryPoint contract.\nWe define the following method in the EntryPoint interface to expose these values:\nfunction getNonce ( address sender , uint192 key ) external view returns ( uint256 nonce );\nFor each key the sequence is validated by the EntryPoint for each UserOperation.\nIf the nonce validation fails the UserOperation is considered invalid and the bundle is reverted.\nThe sequence value is incremented sequentially and monotonically for the sender for each UserOperation.\nA new key can be introduced with an arbitrary value at any point, with its sequence starting at 0 .\nThis approach maintains the guarantee of UserOperation hash uniqueness on-chain on the protocol level while allowing\nAccounts to implement any custom logic they may need operating on a 192-bit âkeyâ field, while fitting the 32 byte word.\nReading and validating the nonce\nWhen preparing the UserOperation bundlers may make a view call to this method to determine a valid value for the nonce field.\nBundlerâs validation of a UserOperation SHOULD start with getNonce to ensure the transaction has a valid nonce field.\nIf the bundler is willing to accept multiple UserOperations by the same sender into their mempool,\nthis bundler is supposed to track the key and sequence pair of the UserOperations already added in the mempool.\nUsage examples\n-\nClassic sequential nonce.\nIn order to require the Account to have classic, sequential nonce, the validation function MUST perform:\nrequire ( userOp . nonce < type ( uint64 ). max )\n-\nOrdered administrative events\nIn some cases, an account may need to have an âadministrativeâ channel of operations running in parallel to normal\noperations.\nIn this case, the account may use a specific key when calling methods on the account itself:\nbytes4 sig = bytes4 ( userOp . callData [ 0 : 4 ]);\nuint key = userOp . nonce >> 64 ;\nif ( sig == ADMIN_METHODSIG ) {\nrequire ( key == ADMIN_KEY , \"wrong nonce-key for admin operation\" );\n} else {\nrequire ( key == 0 , \"wrong nonce-key for normal operation\" );\n}\nRequired EntryPoint contract functionality\nThe EntryPoint method is handleOps , which handles an array of UserOperations\nThe EntryPoint âs handleOps function must perform the following steps (we first describe the simpler non-paymaster case). It must make two loops, the verification loop and the execution loop .\nIn the verification loop, the handleOps call must perform the following steps for each UserOperation :\n- Create the sender Smart Contract Account if it does not yet exist , using the initcode provided in the UserOperation .\n- If the factory address is â0x7702â, then the sender MUST be an EOA with an EIP-7702 authorization designation. The EntryPoint validates the authorized address matches the one specified in the UserOperation signature (see Support for [EIP-7702] authorizations ).\n- If the sender does not exist, and the initcode is empty, or does not deploy a contract at the âsenderâ address, the call must fail.\n- WARNING : If the sender does exist, and the initcode is not empty, then the initcode is ignored.\n- calculate the maximum possible fee the sender needs to pay based on validation and call gas limits, and current gas values.\n- calculate the fee the sender must add to its âdepositâ in the EntryPoint\n- Call validateUserOp on the sender contract , passing in the UserOperation , its hash and the required fee.\nThe Smart Contract Account MUST verify the UserOperation âs signature parameter, and pay the fee if the sender considers the UserOperation valid. If any validateUserOp call fails, handleOps must skip execution of at least that UserOperation , and may revert entirely.\n- Validate the accountâs deposit in the EntryPoint is high enough to cover the max possible cost (cover the already-done verification and max execution gas)\nIn the execution loop, the handleOps call must perform the following steps for each UserOperation :\n- Call the account with the UserOperation âs calldata . Itâs up to the account to choose how to parse the calldata; an expected workflow is for the account to have an execute function that parses the remaining calldata as a series of one or more calls that the account should make.\n- If the calldata starts with the methodsig IAccountExecute.executeUserOp , then the EntryPoint must build a calldata by encoding executeUserOp(userOp,userOpHash) and call the account using that calldata.\n- After the call, refund the accountâs deposit with the excess gas cost that was pre-charged.\nA penalty of 10% ( UNUSED_GAS_PENALTY_PERCENT ) is applied on the amounts of callGasLimit and paymasterPostOpGasLimit gas that remains unused .\nThis penalty is only applied if the amount of the remaining unused gas is greater than or equal 40000 ( PENALTY_GAS_THRESHOLD ).\nThis penalty is necessary to prevent the UserOperations from reserving large parts of the gas space in the bundle but leaving it unused and preventing the bundler from including other UserOperations .\n- After the execution of all calls, pay the collected fees from all UserOperations to the beneficiary address provided by the bundler.\nBefore accepting a UserOperation , bundlers SHOULD use an RPC method to locally call the handleOps function on the EntryPoint ,\nto verify that the signature is correct and the UserOperation actually pays fees; see the Simulation section below for details.\nA node/bundler MUST reject a UserOperation that fails the validation, meaning not adding it to the local mempool\nand not propagating it to other peers.\nJSON-RPC API for ERC-4337\nIn order to support sending UserOperation objects to bundlers, which in turn propagate them through the P2P mempool,\nwe introduce a set of JSON-RPC APIs including eth_sendUserOperation and eth_getUserOperationReceipt .\nThe full definition of the new JSON-RPC API is outside the scope of this proposal.\nSupport for EIP-712 signatures\nThe userOpHash is calculated as an [EIP-712] typed message hash with the following parameters:\nbytes32 constant TYPE_HASH =\nkeccak256 (\n\"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)\"\n);\nbytes32 constant PACKED_USEROP_TYPEHASH =\nkeccak256 (\n\"PackedUserOperation(address sender,uint256 nonce,bytes initCode,bytes callData,bytes32 accountGasLimits,uint256 preVerificationGas,bytes32 gasFees,bytes paymasterAndData)\"\n);\nSupport for EIP-7702 authorizations\nOn networks with EIP-7702 enabled, the eth_sendUserOperation method accepts an extra eip7702Auth parameter.\nIf this parameter is set, it MUST be a valid EIP-7702 authorization tuple, and signed by the sender address.\nThe bundler MUST add all required eip7702Auth of all UserOperations in a bundle to the authorizationList and execute\nthe bundle using a transaction type SET_CODE_TX_TYPE .\nAdditionally, the UserOperation hash calculation is updated to include the desired EIP-7702 delegation address.\nIf the initCode field starts with 0x7702 right-padded with 18 zeros, and this account was deployed using an EIP-7702 transaction, then the hash is calculated as follows:\n- For the purpose of hash calculation, the first 20 bytes of the initCode field of the UserOperation are set to accountâs EIP-7702 delegate address (fetched with EXTCODECOPY)\n- The initCode is not used to call a factory contract.\n- If the initCode is longer than 20 bytes, then the rest of the initCode is used to call an initialization function in the account itself.\nNote that a UserOperation may still be executed without such initCode .\nIn this case the EntryPoint doesnât hash the current EIP-7702 delegate , and can be potentially executed against a modified account.\nAdditionally, EIP-7702 defines the gas cost of executing an authorization equal to PER_EMPTY_ACCOUNT_COST = 25000 .\nThis gas consumption is not observable on-chain by the EntryPoint contract and MUST be included in the preVerificationGas value.\nExtension: paymasters\nWe extend the EntryPoint logic to support paymasters that can sponsor transactions for other users. This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with ERC-20 tokens and many other use cases. When the paymasterAndData field in the UserOperation is not empty, the EntryPoint implements a different flow for that UserOperation:\nDuring the verification loop, in addition to calling validateUserOp , the handleOps execution also must check that the paymaster has enough ETH deposited with the EntryPoint to pay for the UserOperation , and then call validatePaymasterUserOp on the paymaster to verify that the paymaster is willing to pay for the UserOperation . Note that in this case, the validateUserOp is called with a missingAccountFunds of 0 to reflect that the accountâs deposit is not used for payment for this UserOperation .\nIf the paymasterâs validatePaymasterUserOp returns a non-empty context byte array, then handleOps must call postOp on the paymaster after making the main execution call.\nOtherwise, no call is done to the postOp function.\nMaliciously crafted paymasters could pose a risk of a DoS attack against the system and bundlers should take steps to mitigate it.\nAs a mitigation, bundlers should use a reputation system for contracts they serve, and the paymaster must either limit its storage usage, or deposit a stake in a reputation system.\nFull specification of a reputation system is outside the scope of this proposal.\nThe paymasterAndData field encoding and paymasterSignature\nThe paymasterAndData field is a byte array that contains a non-standard encoding of the following fields:\n- paymasterAddress - 20 bytes â the address of the paymaster contract\n- paymasterVerificationGasLimit - 16 bytes - the gas limit for the verification function\n- postOpGasLimit - 16 bytes - the gas limit for the postOp function\n- paymasterData - the data that the paymaster contract will receive in the validatePaymasterUserOp call\nThe following data can optionally be appended to the paymasterAndData field:\n- paymasterSignature - the âsignatureâ value byte array to be checked by the paymaster contract; this value can be provided without affecting the UserOperation hash\n- paymasterSignatureLength - 2 bytes - the exact length of the paymasterSignature parameter byte array\n- PAYMASTER_SIG_MAGIC ( 0x22e325a297439656 ) - the magic value that is appended to indicate the use of the paymasterSignature feature by the UserOperation\nNote that as both the signature and the paymasterSignature fields do not affect the UserOperation hash, the signing by the Sender and the Paymaster can be performed in parallel.\nThe paymaster interface is as follows:\nfunction validatePaymasterUserOp\n( PackedUserOperation calldata userOp , bytes32 userOpHash , uint256 maxCost )\nexternal returns ( bytes memory context , uint256 validationData );\nfunction postOp\n( PostOpMode mode , bytes calldata context , uint256 actualGasCost , uint256 actualUserOpFeePerGas )\nexternal ;\nenum PostOpMode {\nopSucceeded , // UserOperation succeeded\nopReverted // UserOperation reverted. paymaster still has to pay for gas.\n}\nThe EntryPoint must implement the following API to let entities like paymasters have a stake, and thus have more flexibility in their storage access.\n// add a stake to the calling entity\nfunction addStake ( uint32 _unstakeDelaySec ) external payable ;\n// unlock the stake (must wait unstakeDelay before can withdraw)\nfunction unlockStake () external ;\n// withdraw the unlocked stake\nfunction withdrawStake ( address payable withdrawAddress ) external ;\nThe paymaster must also have a deposit, which the EntryPoint will charge UserOperation costs from.\nThe deposit (for paying gas fees) is separate from the stake (which is locked).\nThe EntryPoint must implement the following interface to allow Paymasters (and optionally Accounts) to manage their deposit:\n// return the deposit of an account\nfunction balanceOf ( address account ) public view returns ( uint256 );\n// add to the deposit of the given account\nfunction depositTo ( address account ) public payable ;\n// add to the deposit of the calling account\nreceive () external payable ;\n// withdraw from the deposit of the current account\nfunction withdrawTo ( address payable withdrawAddress , uint256 withdrawAmount ) external ;\n// get the currently executing UserOperation hash, or 0 if not called during the execution\nfunction getCurrentUserOpHash () public view returns ( bytes32 );\nBundler behavior upon receiving a UserOperation\nSimilar to an Ethereum transaction, the offchain flow of a UserOperation can be described as follows:\n- Client sends a UserOperation to the bundler through an RPC call eth_sendUserOperation .\n- Before including the UserOperation in the mempool, the bundler runs the first validation of the newly received UserOperation. If the UserOperation fails validation, the bundler drops it and returns an error in response to eth_sendUserOperation .\n- Later, once building a bundle, the bundler takes UserOperations from the mempool and runs the second validation of a single UserOperation on each of them. If it succeeds, it is scheduled for inclusion in the next bundle, and dropped otherwise.\n- Before submitting the new bundle onchain, the bundler performs the third validation of the entire UserOperations bundle. If any of the UserOperations fail validation, the bundler drops them. The bundler should keep track of the peersâ reputation. The full design of such a reputation system is outside the scope of this proposal.\nWhen a bundler receives a UserOperation , it must first run some basic sanity checks, namely that:\n- Either the sender is an existing contract, or the initCode is not empty (but not both)\n- If initCode is not empty, parse its first 20 bytes as a factory address or an EIP-7702 flag.\nRecord whether the factory is staked, in case the later simulation indicates that it needs to be. If the factory accesses the global state, it must be staked.\n- The verificationGasLimit and paymasterVerificationGasLimits are lower than MAX_VERIFICATION_GAS ( 500000 ) and the preVerificationGas is high enough to pay for the calldata gas cost of serializing the UserOperation plus PRE_VERIFICATION_OVERHEAD_GAS ( 50000 ).\n- The paymasterAndData is either empty, or starts with the paymaster address, which is a contract that (i) currently has nonempty code on chain, (ii) has a sufficient deposit to pay for the UserOperation, and (iii) is not currently banned. During simulation, the paymasterâs stake is also checked, depending on its storage usage.\n- The callGasLimit is at least the cost of a CALL with non-zero value.\n- The maxFeePerGas and maxPriorityFeePerGas are above a configurable minimum value that the bundler is willing to accept. At the minimum, they are sufficiently high to be included with the upcoming block.basefee .\n- The sender doesnât have another UserOperation already present in the mempool (or it replaces an existing entry with the same sender and nonce, with a higher maxPriorityFeePerGas and an equally increased maxFeePerGas ).\nOnly one UserOperation per sender may be included in a single bundle.\nA sender is exempt from this rule and may have multiple UserOperations in the mempool and in a bundle if it is staked.\nUserOperation Simulation\nWe define UserOperation simulation, as the offchain view call (or trace call) to the EntryPoint contract with the UserOperation , and the enforcement of the shared set of rules applied to the validation code, as part of the UserOperation validation.\nSimulation Rationale\nTo validate a normal Ethereum transaction tx , the bundler performs static checks, like:\n- ecrecover(tx.v, tx.r, tx.s) has to return a valid EOA\n- tx.nonce has to be the current nonce of the recovered EOA\n- balance of the recovered EOA has to be sufficient to pay for the transaction\n- tx.gasLimit has to be sufficient to cover the intrinsic gas cost of a transaction\n- chainId has to match the current chain\nAll of these checks do not rely on EVM state, and cannot be affected by other Accountsâ transactions.\nIn contrast, UserOperation validation rely on EVM state (calls to validateUserOp , validatePaymasterUserOp ), can be changed by other UserOperations (or normal Ethereum transactions). Therefore, we introduce simulation as a new mechanism to check its validity.\nIntuitively, the aim of the simulation is to ensure the onchain validation code of a UserOperation is sandboxed, isolated from other UserOperations in the same bundle.\nSimulation Specification:\nTo simulate a UserOperation validation, the bundler makes a view call to the handleOps() method with the UserOperation to check.\nSimulation should run only on the validation section of the sender and paymaster , and is not required for the UserOperation âs execution.\nA bundler MAY add second âalways failedâ UserOperation to the bundle, so that the simulation will\nend as soon as the first UserOperationâs validation complete.\nThe bundler MUST drop the UserOperation if the simulation reverts\nThe simulated call performs the full validation, by calling:\n- If initCode is present, create the sender Account.\n- account.validateUserOp .\n- if specified a paymaster: paymaster.validatePaymasterUserOp .\nEither sender or paymaster may return a time-range ( validAfter / validUntil ).\nThe UserOperation MUST be valid at the current time to be considered valid, defined as validAfter<=block.timestamp .\nA bundler MUST drop a UserOperation if it expires too soon and is likely to become invalid before the next block.\nTo decode the returned time-ranges, the bundler MUST run the validation using tracing, to decode the return value from the validateUserOp and validatePaymasterUserOp methods.\nTo prevent DoS attacks on bundlers, they must make sure the validation methods above pass the validation rules, which constrain their usage of opcodes and storage.\nThe full design of such a shared set of rules, applied to the validation code, is outside the scope of this proposal.\nEstimating preVerificationGas\nThis document does not specify a canonical way to estimate this value,\nas it depends on non-permanent network properties such as operation and data gas pricing and the expected bundle size.\nHowever, the requirement is for the estimated value to be sufficient to cover the following costs:\n- Base bundle transaction cost. On Ethereum, 21000 gas divided by the number of UserOperations .\n- The calldata gas cost related to the UserOperation as defined in EIP-2028 .\n- Static EntryPoint contract code execution.\n- Static memory cost when loading the fixed size fields of the UserOperation into EVM memory\n- Memory cost (including expansion cost) due to context returned by paymaster validatePaymasterUserOp function, if relevant.\n- External call to the innerHandleOp() function which is a major part of the EntryPoint implementation.\nNote that this value is not static and depends on the UserOperation âs position in the bundle.\n- [EIP-7702] authorization cost, if any.\n- EIP-7623 calldata floor price increase is estimated as follows:\n- Apply the new formula for tx.gasUsed , replacing the execution_gas_used value with an estimate for value made for this UserOperation.\n- The estimate is calculated as a sum of all verification gas used during simulation (account creation, validation and paymaster validation) and 10% of the sum of execution and postOp gas limit.\nThe bundler MUST require a slack in PreVerificationGas value, to accommodate memory expansion costs in the future bundle, and the expected position of the UserOperation in it.\nAlternative Mempools\nThe simulation rules above are strict and prevent the ability of paymasters to grief the system.\nHowever, there might be use cases where specific paymasters can be validated\n(through manual auditing) and verified that they cannot cause any problem, while still require relaxing of the opcode rules.\nA bundler cannot simply âwhitelistâ a request from a specific paymaster: if that paymaster is not accepted by all\nbundlers, then its support will be sporadic at best.\nInstead, we introduce the term âalternate mempoolâ: a modified validation rules, and procedure of propagating them to other bundlers.\nThe procedure of using alternate mempools is outside the scope of this proposal.\nBundling\nBundling is the process where a node/bundler collects multiple UserOperations and creates a single transaction to submit on-chain.\nDuring bundling, the bundler MUST:\n- Exclude UserOperations that access any sender address of another UserOperation in the same bundle.\n- Exclude UserOperations that access any address created by another UserOperation validation in the same bundle (via a factory).\n- For each paymaster used in the bundle, keep track of the balance while adding UserOperations . Ensure that it has sufficient deposit to pay for all the UserOperations that use it.\nAfter creating the bundle, before including the transaction in a block, the bundler SHOULD:\n- Run debug_traceCall with maximum possible gas, to enforce the validation rules on opcode and storage access,\nas well as to verify the entire handleOps bundle transaction,\nand use the consumed gas for the actual transaction execution.\n- If the call reverted, the bundler MUST use the trace result to find the entity that reverted the call.\nThis is the last entity that is CALLâed by the EntryPoint prior to the revert.\n(the bundler cannot assume the revert is FailedOp )\n- If any verification context rule was violated the bundlers MUST treat it the same as\nif this UserOperation reverted.\n- Remove the offending UserOperation from the current bundle and from mempool.\n- If the error is caused by a factory or a paymaster , and the sender\nof the UserOperation is not a staked entity, then issue a âbanâ for the guilty factory or paymaster.\n- If the error is caused by a factory or a paymaster , and the sender\nof the UserOperation is a staked entity, do not ban the factory / paymaster from the mempool.\nInstead, issue a âbanâ for the staked sender entity.\n- Repeat until debug_traceCall succeeds.\nAs staked entries may use some kind of transient storage to communicate data between UserOperations in the same bundle,\nit is critical that the exact same opcode and precompile banning rules as well as storage access rules are enforced\nfor the handleOps validation in its entirety as for individual UserOperations .\nOtherwise, attackers may be able to use the banned opcodes to detect running on-chain and trigger a FailedOp revert.\nWhen a bundler includes a bundle in a block it must ensure that earlier transactions in the block donât make any UserOperation fail.\nError codes.\nWhile performing validation, the EntryPoint must revert on failures. During simulation, the calling bundler MUST be able to determine which entity ( sender , factory or paymaster ) caused the failure.\nThe attribution of a revert to an entity is done using call-tracing: the last entity called by the EntryPoint prior to the revert is the entity that caused the revert.\n- For diagnostic purposes, the EntryPoint must only revert with explicit SignatureValidationFailed() , FailedOp() or FailedOpWithRevert() errors.\n- The message of the error starts with event code, AA##\n- Event code starting with âAA1â signifies an error during sender creation\n- Event code starting with âAA2â signifies an error during sender validation ( validateUserOp )\n- Event code starting with âAA3â signifies an error during paymaster validation ( validatePaymasterUserOp )\nFactory contracts\nAll factory contracts MUST check that all calls to the createAccount() function originate from the entryPoint.senderCreator() address.\nPaymasters contracts\nAll paymaster contracts MUST check that all calls to the validatePaymasterUserOp() and postOp() functions originate from the EntryPoint .\nAggregator contracts\nAll aggregator contracts MUST check that all calls to the validateSignatures() function originates from the EntryPoint .\nEIP-7702 delegated Smart Contract Accounts\nAll EIP-7702 delegated Smart Contract Account implementations MUST check that all calls to the initialization function originate from the entryPoint.senderCreator() address.\nThere is no way for the EntryPoint contract to know whether an EIP-7702 account has been initialized or not, and therefore the EIP-7702 account initialization code, can be called multiple times through EntryPoint .\nThe Account code SHOULD only allow calling it once and the Wallet Application SHOULD NOT pass the initCode repeatedly.\nSmart Contract Accounts\nStorage layout collisions\nIt is expected that most of ERC-4337 Smart Contract Account will be upgradeable,\neither via on-chain delegate proxy contracts or via EIP-7702.\nWhen changing the underlying implementation, all Accounts MUST ensure that there are no conflicts in the storage layout\nof the two contracts.\nOne common approach to this problem is often referred to as âdiamond storageâ and is fully described in ERC-7201 .\nTransient Storage\nContracts using the EIP-1153 transient storage MUST take into account that ERC-4337 allows multiple\nUserOperations from different unrelated sender addresses to be included in the same underlying transaction.\nThe transient storage MUST be cleaned up manually if contains any sensitive information or is used for access control.\nRationale\nThe main challenge with a purely âSmart Contract Accountsâ based Account Abstraction system is DoS safety: how can a block builder including an operation make sure that it will actually pay fees, without having to first execute the entire operation?\nRequiring the block builder to execute the entire operation opens a DoS attack vector, as an attacker could easily send many operations that pretend to pay a fee but then revert at the last moment after a long execution.\nSimilarly, to prevent attackers from cheaply clogging the mempool, nodes in the P2P network need to check if an operation will pay a fee before they are willing to forward it.\nThe first step is a clean separation between validation (acceptance of UserOperation, and acceptance to pay) and execution.\nIn this proposal, we expect Accounts to have a validateUserOp method that takes as input a UserOperation , verifies the signature and pays the fee.\nOnly if this method returns successfully, the execution will happen.\nThe EntryPoint -based approach allows for a clean separation between verification and execution, and keeps Smart Contract Accountsâ logic simple. It enforces the simple rule that only after validation is successful and the UserOperation can pay, the execution is done and only done once, and also guarantees the fee payment.\nValidation Rules Rationale\nThe next step is protecting the bundlers from denial-of-service attacks by a mass number of UserOperations that appear to be valid (and pay) but that eventually revert, and thus block the bundler from processing valid UserOperations .\nThere are two types of UserOperations that can fail validation:\n- UserOperations that succeed in initial validation (and accepted into the mempool), but rely on the environment state to fail later when attempting to include them in a block.\n- UserOperations that are valid when checked independently but fail when bundled together to be put on-chain.\nTo prevent such rogue UserOperations , the bundler is required to follow a set of shared set of rules applied to the validation code, to prevent such denial-of-service attacks.\nReputation Rationale\nUserOperationâs storage access rules prevent them from interfering with each other.\nBut âglobalâ entities - paymasters and factories are accessed by multiple UserOperations , and thus might invalidate multiple previously valid UserOperations .\nTo prevent abuse, we throttle down (or completely ban for a period of time) an entity that causes invalidation of a large number of UserOperations in the mempool."}
{"url":"https://docs.getmonero.org/","domain":"docs.getmonero.org","title":"Monero Docs - Monero Docs","hash":"b900e90566892f2cc2832f86e9d1b55809dcde016ab07f789c380b5f104859ea","tokens":302,"chars":1207,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112003436,"text":"Skip to content\nInitializing search\nmonero-project/monero-docs\n- Interacting\n- Download & Verify\n-\nMining\n- Pool\n- P2Pool\n- Help\n-\nMonerod\n- Sample Configs\n- Wallets\n- Blockchain Tools\n- External\n- RPC Library\n-\nR&D\n-\nCryptography\n- Base58\n- Keccak-256\n- PRNG\n-\nMnemonics\n-\nProof of Work\n- Wallet Files\nMonero Documentation ¶\nMonero Docs is a Knowledge Base and User Guide for interacting with Monero. Pick a starting point below, use the search bar at the top to jump straight to a topic, or browse the navigation bar for the full list of topics.\n-\nGet started\nNew to Monero? Learn the basics, then download and verify the official software.\nThe basics\nDownload & verify\n-\nRunning a node & mining\nRun monerod , then mine solo, in a pool, or via P2Pool.\nRun a node\nMining guides\n-\nRPC Library\nDeveloper reference for the Node and Wallet JSON-RPC endpoints.\nNode RPC\nWallet RPC\n-\nResearch & development\nHow Monero works under the hood: cryptography, address types, mnemonics, and proof of work.\nR&D overview\nCryptography\nContributing ¶\nContributions can be made via issues and pull requests on GitHub, or communicated via the #monero-docs workgroup on Matrix or IRC (libera.chat).\nGitHub Matrix IRC"}
{"url":"https://docs.cosmos.network/","domain":"docs.cosmos.network","title":"Cosmos Developer Documentation - Cosmos Docs","hash":"8676d52551c7e0de0d2d61730f6caba4f3d8a2f7a93835a6fed878cb9cd77b34","tokens":383,"chars":1532,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112005034,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nCosmos Docs home page\nCosmos SDK Cosmos EVM IBC CometBFT\nTalk to an expert\nCosmos Developer Documentation\nThe most widely adopted, battle-tested Layer 1 blockchain stack, trusted by 200+ chains live in production.\nHow it works\nThe stack is modular. Leverage pre-built components or integrate custom features for your specific use case, from consensus mechanisms to governance and compliance.\nFast and Reliable\nPerformant, customizable, and EVM-compatible, the Cosmos stack offers engineers full control of their blockchain infrastructure and implementation. Its stable and secure codebase enables blockchains to achieve up to 10,000 transactions per second.\nContact Us to Discuss Licensing\nMaintainers and Contributors\nCosmos Labs maintains the core components of the stack: Cosmos SDK, CometBFT, IBC, Cosmos EVM, and various developer tools and frameworks. In addition to developing and maintaining the Cosmos Stack, Cosmos Labs provides advisory and engineering services for blockchain solutions.\nCosmos Labs is a wholly-owned subsidiary of the Interchain Foundation, the Swiss nonprofit responsible for treasury management, funding public goods, and supporting governance for Cosmos.\nThe Cosmos Stack is supported by a global community of open-source contributors.\nGet in Touch with Cosmos Labs\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.orca.so/","domain":"docs.orca.so","title":"Orca Documentation - Orca Documentation","hash":"a8cf006c26bd090f5ae2344b08401fae18f5f373b8dd2063c72c58a2015817b9","tokens":563,"chars":2251,"crawler":"hive-genesis","verified":"exact","ts":1791112004910,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nOrca Documentation home page\nHome\nLiquidity\nTrade\nVaults\nCreate\nDevelopers\nAPI Reference\nGovernance\nSupport\nOrca Documentation\nPut Your Crypto to Work\nEarn yield by providing liquidity on Solanaâs most trusted DEX. Manage your positions, optimize your returns, and grow your portfolio with concentrated liquidity.\nLaunch App Start Earning\nExplore Orca\nEarn yield on your crypto through concentrated liquidity positions\nEarn Yield\nProvide liquidity and earn trading fees on Solanaâs most trusted DEX. Concentrate your capital for maximum efficiency or use full-range positions for a passive approach.\nBeginner Guide Manage Portfolio Liquidity Terminal\nFor Asset Issuers\nLaunch and manage liquid onchain markets for your token. Create pools, incentivize liquidity providers, and build sustainable trading depth.\nLaunch Guide Pool Creation LP Rewards Token List\nUser Guides\nStep-by-step guides to start earning and trading\nProviding Liquidity\nLearn how to provide liquidity and earn trading fees. This guide walks you through creating positions, managing your portfolio, and optimizing your yield.\nTrading\nSwap tokens on Orca with minimal slippage. Our guide covers connecting your wallet, comparing prices, and executing trades.\nDeveloper Resources\nBuild on Orca with our open-source SDK\nSDK & Integration\nIntegrate Orcaâs Whirlpools into your application. Our TypeScript SDK provides everything you need for swaps, liquidity, and pool management.\nSDK Documentation Integrations Glossary\nQuick Start\nGet started with a simple integration example:\nimport { WhirlpoolContext , buildWhirlpoolClient }\nfrom \"@orca-so/whirlpools-sdk\" ;\nconst ctx = WhirlpoolContext . from ( connection , wallet );\nconst client = buildWhirlpoolClient ( ctx );\nconst pool = await client . getPool ( poolAddress );\nResources & Governance\nCommunity, support, and protocol governance\nGovernance\nVote on proposals and shape Orcaâs future\nAI & LLMs\nAccess docs with AI tools and LLMs\nFAQs\nAnswers to common questions\nSupport\nGet help from our team\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.openzeppelin.com/contracts","domain":"docs.openzeppelin.com","title":"OpenZeppelin Contracts | OpenZeppelin Docs","hash":"8f81e47d0fc3642da9c289713039001926a3580b25a57bb531f78d6c9c89f7d6","tokens":610,"chars":2439,"crawler":"hive-genesis","verified":"exact","ts":1791112006656,"text":"Home Forum Website Impact\nOpenZeppelin Contracts\nOpen in Claude\nOpenZeppelin Contracts is a library of modular, reusable, secure smart contracts for the Ethereum network, written in Solidity.\nGetting Started\nContracts Overview\nStart working with the OpenZeppelin Contracts Library.\nContracts Wizard\nUse the interactive Contracts Wizard to bootstrap your contract and learn about the components offered in OpenZeppelin Contracts.\nCore Features\nToken Standards\nImplementations of ERC20, ERC721, ERC1155, and other token standards.\nAccess Control\nManage permissions and roles in your smart contracts securely.\nGovernance\nBuild decentralized governance systems for your protocols.\nUtilities\nHelper contracts and libraries for common blockchain development tasks.\nToken Standards\nERC-20\nFungible token standard implementation with extensions and utilities.\nERC-721\nNon-fungible token (NFT) standard with advanced features.\nERC-1155\nMulti-token standard for both fungible and non-fungible tokens.\nERC-4626\nTokenized vault standard for yield-bearing assets.\nAdvanced Features\nAccount Abstraction\nSmart account implementations and account abstraction utilities.\nUpgradeable Contracts\nLearn how to build upgradeable smart contracts safely.\nContracts Wizard\nInteractive tool to generate smart contracts with custom features.\nUpgrades Plugins\nTools for deploying and upgrading smart contracts with Hardhat and Foundry.\nAPI Reference\nAPI Overview\nComplete API reference for all OpenZeppelin Contracts.\nERC20 API\nDetailed API documentation for ERC20 tokens and extensions.\nERC721 API\nComplete API reference for ERC721 NFT contracts.\nAccess Control API\nAPI documentation for access control and ownership patterns.\nTools & Integrations\nRelayer\nAutomate onchain transactions to schedule jobs, batch calls, and relay gasless meta transactions within your self-hosted infrastructure.\nMonitor\nMonitor onchain activity in real time to watch critical events, detect anomalies, trigger alerts on your preferred channels, and set automated responses with Relayer.\nUI Builder\nSpin 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.\nCommunity Contracts\nAdditional contracts and extensions contributed by the community.\nOverview\nNext Page\nOn this page\nGetting Started Core Features Token Standards Advanced Features API Reference Tools & Integrations"}
{"url":"https://docs.ipfs.tech/","domain":"docs.ipfs.tech","title":"IPFS Documentation | IPFS Docs","hash":"cc70bfbc3d62ef76df2bd477f2010f8bc5f857345abf085fb00bb0c2f95a5de8","tokens":1041,"chars":4164,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112006680,"text":"IPFS Docs\n# Welcome to the IPFS Docs\nThe InterPlanetary File System (IPFS) is a set of building blocks for a better web. Open protocols to make your data smarter: content-addressed, verifiable, and unstoppable.\nOn a more technical level, IPFS is a set of open protocols for addressing, routing, and transferring data on the web, built on the ideas of content addressing and peer-to-peer networking.\nMany popular projects are built with IPFS - see the ecosystem directory (opens new window) and the awesome-ipfs (opens new window) list to find some of these projects.\nNew to IPFS?\nCheck out the Glossary to learn key terms and concepts.\n# Get started\nInstall IPFS Desktop (GUI), Kubo (CLI), or IPFS Companion (browser extension). For infrastructure, see IPFS Cluster, Rainbow, and Someguy .\nLearn how to retrieve data , provide content , deploy websites , or build applications .\n# Retrieve data\nQuickly retrieve data from the IPFS network, no programming required:\n- Fetch data via it's content identifier (CID) using an IPFS gateway .\n- Install the IPFS Companion browser extension to add support for ipfs:// and ipns:// addresses to your browser.\n# Provide data\nProvide data to the IPFS network with IPFS Desktop or a pinning service:\n- Install IPFS Desktop which bundles an IPFS node (Kubo) and a UI to manage files, peers, and explore content on IPFS .\n- Publish content to the IPFS network with IPFS Desktop .\n# Deploy static sites and dapps to the IPFS network\nIPFS is a great fit for deploying static sites and dapps, check out the following guides to get started:\n- Deploy static sites to the IPFS network with a GitHub Action .\n- Set up a DNSLink gateway to serve your site via a custom domain .\n- Configure static site generators for publishing to IPFS .\n# Troubleshooting\nIf you're having trouble retrieving or providing data to the IPFS network, check out the troubleshooting guide .\n# Build\nYou can build apps that leverage IPFS implementations, or use HTTP instead:\n# Using IPFS\nBuild an IPFS-native app using one of the many IPFS implementations and tools:\n- If you are familiar with JavaScript, checkout the IPFS in web apps guide , which covers how to use Helia (opens new window) and related libraries to build IPFS-native apps.\n- To develop IPFS applications using Go and/or interact with IPFS from the terminal, use the IPFS Kubo implementation .\n- Try any of the many other tools and implementations , which are written in different languages and tailored to specific needs and use cases.\n# Using HTTP\nAs the IPFS ecosystem has grown and evolved with multiple implementations in different languages, HTTP has become an important foundation for interoperability. Check out the following resources to learn more:\n- Control an IPFS Kubo node via HTTP using the Kubo RPC API , which supports multiple clients in multiple languages .\n- For an implementation and runtime agnostic HTTP interface for retrieving data, use an IPFS gateway .\n# Learn\n- Look up key terms and definitions in the IPFS Glossary.\n- Learn what IPFS is and isn't, the problems it solves, the different subsystems that it is composed of and how each one works in the Basic Concepts .\n- Dive into ideas like hashing, immutability, persistence (and more) that underlie IPFS in Ideas and theory .\n- Learn more about the subsystems that IPFS is composed of in Subsystems and components\n- Get an overview of IPFS implementations .\n- Compare IPFS to other similar systems .\n- Understand the project history, ecosystem status and more in the Project section .\n- See how other software systems leverage IPFS in the Case Studies section .\n# Join the IPFS community\nTIP\nAre you developing with IPFS implementations and tools, and looking for technical support from IPFS experts? For the fastest possible assistance and resolution of your support needs, see the guide to getting technical help and support .\nIPFS has a bustling community of designers, developers, writers, and activists who are all helping to improve the project. Find out about the events and resources available, and how to get involved in the Community section\nHelp us improve this site!\nEdit this page\nor\nopen an issue"}
{"url":"https://docs.layerzero.network/","domain":"docs.layerzero.network","title":"Introduction - LayerZero","hash":"cd26d77162aa1a67fd3125e3b4d8869a34eed2cf0617cf76b8f4213456bf4d0b","tokens":126,"chars":501,"crawler":"crawler-dfxz","verified":"exact","ts":1791112008437,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nLayerZero home page\nHome\nGet Started\nCore Concepts\nLayerZero Documentation\nCrosschain interoperability, blockchain infrastructure, and financial applications\nBlockchain Infrastructure\nCrosschain & Interoperability\nFinancial Applications & Services\nIâm Just Exploring\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://vitalik.eth.limo/general/2025/06/28/zkid.html","domain":"vitalik.eth.limo","title":"Does digital ID have risks even if it's ZK-wrapped?","hash":"e879c52666e95bb52292c51f73a7f9c5f3622d6c4849e7a14bcbb4462e091e4f","tokens":5320,"chars":21277,"crawler":"hive-genesis","verified":"unchecked","ts":1791112008838,"text":"Dark Mode Toggle\nDoes digital ID have risks even if it's ZK-wrapped?\n2025 Jun 28\nSee all posts\nDoes digital ID have risks even if it's ZK-wrapped?\nSpecial thanks to Balvi volunteers, Silviculture members and\nWorld team members for discussion.\nThe use of zero-knowledge proofs to\nprotect privacy in digital ID systems is now becoming at least\nsomewhat mainstream. Various\nZK-passport projects are creating\nvery user-friendly software packages that use zero-knowledge proofs to\nprove that a user has a valid ID without revealing any details of their\nID. World ID (formerly Worldcoin), which uses\nbiometrics for verification and zero knowledge proofs for privacy,\nrecently\npassed 10 million users . A Taiwan government project\nfor digital ID uses zero knowledge proofs, and EU digital ID work is\nalso increasingly\ntaking zero knowledge proofs seriously .\nOn the surface, widespread adoption of ZK-wrapped digital ID seems\nlike it would be a great victory for d/acc ,\nprotecting our social media, voting, and all kinds of internet services\nagainst manipulation from sybils and bots, all without compromising on\nprivacy. But is it that simple, or does ZK-wrapped ID still have risks?\nThis post will make the following argument:\n- ZK-wrapping solves a lot of important\nproblems.\n- ZK-wrapped ID still has risks . The risks seem\npretty independent of biometric vs passport; the bulk of the risks\n( loss of privacy, vulnerability to coercion, errors )\ncomes specifically from attempting to uphold a\none-identity-per-person property\n- The other extreme, using \"proof of wealth\" for anti-sybil,\nis insufficient for too many use cases, so we need\nsomething \"ID-like\".\n- The theoretical ideal is something in the middle,\nwhere you can get N identities at a cost of NÂČ .\n- This ideal is difficult to achieve in practice, but the right kind\nof \"pluralistic identity\" comes close , and is thus the\nbest realistic solution. Pluralistic identity can be explicit\n(eg. social-graph-based) or implicit (multiple types of\nZK-ID, no single type gets near 100% market share)\nHow ZK-wrapped identity\nworks\nImagine that you've scanned your eyeballs to get a World ID. Or\nperhaps, you scanned your passport with your phone's NFC reader to get a\nZK-passport-based ID. For the purposes of the arguments made in this\npost, the two have the same properties (barring a few edge cases like\nmultiple citizenships).\nOn your phone, you have a secret value, s . In the\nonchain global registry, there is a public hash, H(s) . To\nlog into an application, you generate an application-specific user ID,\nH(s, app_name) , and you use a zero-knowledge proof to\nprove that this ID comes from the same s as one of the\npublic hashes in the registry. Hence, for each public hash, you can only\ngenerate one ID for each application, but it is never revealed\nwhich application-specific ID corresponds to which\npublic hash.\nIn reality, the design can be somewhat more complex. In World ID, the\napp-specific ID is actually a hash that takes in the application ID and\na session ID . Hence, different actions within the same app can\nalso be unlinked from each other. A ZK-passport-based design can be\nbuilt in a similar way.\nBefore we get into the downsides of this type of identity, it's first\nimportant to appreciate the upsides that it offers. Outside of the very\nsmall world of ZKID, in order to authenticate yourself to a service that\nrequires ID, you need to actually reveal your legal identity. This is a\ngross violation of the common computer-security principle\nof least privilege : a process should only get the least authority\nand information required to accomplish its task. They need a proof that\nyou're not a bot, or are over 18, or are from a particular country; they\nget a pointer to your entire identity.\nThe best that we get as an improvement is indirect tokens like phone\nnumbers or credit card numbers, where the actor knowing the link between\nyour phone or credit card number and your activity (the app), and the\nactor knowing the link between your phone or credit card number and your\nlegal identity (the company or bank) are separate. But even this\nseparation is very tenuous: phone\nnumbers get leaked all the time , as does everything else.\nWith ZK-wrapping, these problems to a large extent go\naway . Now, let's get to what has so far been less discussed:\nthe remaining problems that do not go away, and in fact may\neven get worse specifically because of the stronger one-per-person\nrestriction of these schemes.\nZK on its own does\nnot enable pseudonymity\nSuppose that a ZK-identity platform works exactly as intended,\nfaithfully replicating all the logic above, and we even figure out how\nto keep user secrets safe for the long term, for\nnon-technically-proficient users, without trusting centralized\nauthorities. But at the same time, let us make the realistic assumption\nthat applications will not be cooperative; they will be\n\"pragmatic\", pursuing design choices that are justified as maximizing\nuser convenience but that always seem to lean toward their political and\nbusiness interests.\nIn this world, social media apps will not use some fancy design\ninvolving frequently rotating session keys. Instead, they will just use\none app-specific ID for each user - and because the ID system is\none-per-person, each user will only be able to have one account\n(as opposed to \"weak ID\" like eg. Google accounts today, where it's\nreasonably feasible for an average person to get ~5 accounts).\nIn the real world, pseudonymity generally requires having\nmultiple accounts : one for your \"regular identity\" and others\nfor any pseudonymous identities (see \" finsta\nand rinsta \"). Hence, the practical level of pseudonymity that you\nget is plausibly lower than today's status quo, and so\nunder one-per-person ID, even if ZK-wrapped, we\nrisk coming closer to a world where all of your activity must de-facto\nbe under a single public identity . In a world of growing risk\n(eg. drones), taking away the option for people to protect themselves\nthrough pseudonymity has significant downsides.\nZK on its own\ndoes not protect you from coercion\nIf you do not publish your secret s , no one can see the\npublic link between your various accounts. But what if someone does? A\ngovernment could force someone to reveal their secret, so that they can\nsee their entire activity. This is not theoretical: the US government is\nalready starting to require\nvisa applicants to make their social media accounts public.\nAdditionally, employers can easily make revealing your full public\nprofile a condition of employment. Even individual applications could\ntechnically require revealing your identities on other\napplications as a condition of joining (in fact, \"Sign In With [app]\"\ndoes this by default).\nAgain, in these situations, the value of the ZK property falls away,\nbut the downside of the new \"one account per person\" property\nremains.\nIt is possible to design these schemes to make coercion more\ndifficult: for example, you could use a multi-party computation to\ngenerate each app-specific ID, involving the user and the service. This\nwould make it impossible for a user to prove their app-specific ID for a\nparticular application without the application operator's participation.\nThis raises the difficulty of demanding that someone reveal their entire\nidentity - but it does not eliminate the possibility, and such schemes\nhave other downsides, eg. requiring the application developer to be a\nlive entity instead of something like a passive onchain smart\ncontract.\nZK\non its own does not solve non-privacy risks, like errors\nAll forms of ID have edge cases:\n- Government-rooted ID (incl passports) does not cover stateless\npersons . It also does not cover people who do not yet have such a\ndocument.\n- On the flip side, government-rooted ID gives a unique privilege to\nholders of multiple citizenships.\n- Passport issuers could get hacked, or a hostile government\nintelligence agency may even start printing millions of fake identities\n(eg. to manipulate \"guerrilla elections\" like\nthis Russian one if they ever become popular)\n- Biometric ID will fail in the face of people whose relevant\nbiological features have been damaged by some form of injury.\n- Biometric ID may well be spoofed by replicas. If the value of a\nbiometric ID gets very high, we could see entire\nbody parts being grown just to \"farm\" such IDs.\nThese edge cases are most harmful in the case of systems that try to\nmaintain a one-per-person property, and they have nothing to do with\nprivacy; hence, ZK does not help.\nProof\nof wealth for anti-sybil is insufficient; hence, we need some kind of\nidentity\nAmong the purist cypherpunks, a common proposed alternative to\nattempting any kind of identity system is to rely entirely on\nproof-of-wealth as anti-sybil. You can prevent someone from easily\ncreating a huge number of accounts, by making each account cost some\namount of money. This has precedent on the internet; for example, the\nSomethingawful forum required a one-time\nfee of $10 to create an account, which would be forfeited if you get\nbanned - though this was not truly cryptoeconomic in practice, because\nthe hardest part of creating a new account is not replacing the $10,\nit's getting a new credit card.\nPotentially, you can even make\nthe payments conditional : to get an account, you only put the funds\nup at stake, and lose the funds in the rare case that you get banned.\nThis theoretically makes it possible to raise the stakes much\nhigher.\nThis can work well in many types of situations. But there are some\nclasses of situations where this kind of approach does not work at all.\nI will talk about two primary classes, which I will describe as\n\" UBI-like \" and \" governance-like \".\nThe need for\nidentity in UBI-like situations\nBy a UBI-like\nsituation, I mean a situation where there is value in giving a very wide\n(ideally universal) set of users some quantity of assets or services,\nregardless of their ability to pay. Worldcoin does this systematically:\nanyone with a World ID gets a small but regular ongoing supply of WLD\ntokens. Plenty of token airdrops have done this in a more informal way,\ntrying to get at least a few of their tokens in the hands of as many of\ntheir users as possible.\nPersonally, I do not expect such tokens to be worth anywhere close to\nenough to pay for a person's subsistence. In a 1000x richer AI-powered\neconomy, they could be, but in such a world government-run programs\nbacked by natural resource wealth if nothing else would continue to be\nmuch more economically meaningful. Rather, I think the realistic\nproblem that such mini-UBIs solve is giving people access to a\nsufficient quantity of cryptocurrency to make a few basic onchain\ntransactions and online purchases . This could include things\nlike:\n- Getting an ENS name\n- Publishing a hash onchain to initialize some ZK identity\n- Paying for social media platforms\nIf cryptocurrency is very widely adopted worldwide, this stops being\na problem. But while cryptocurrency is not very widely adopted\nworldwide, this can be a lifeline for people to gain access to onchain\nnon-financial apps and to online goods and services that would otherwise\nnot be accessible at all.\nThere is also another way to accomplish a similar thing:\n\"universal basic services\". Give each person with an identity the\nability to send a limited number of free transactions within a\nparticular application . This approach is potentially more\nincentive-aligned and capital-efficient, because it can be done by each\napplication that benefits from such adoption, without needing to pay for\nnon-users, though this comes with the tradeoff of being less universal\n(users only get guaranteed access to participating applications). But\nhere too, you need an identity solution to protect the system from spam,\nwithout the exclusionary nature of requiring payment via a payment\nmethod that perhaps not everyone has access to.\nA final important category to highlight is the \" universal\nbasic security deposit \". One of the functions of identity is to\nhave something that can be targeted for punishment, without requiring\nthe user to put up an amount of capital at stake equal to the size of\nthe incentive. This also serves the goal of making participation less\ncontingent on how much capital you have (or the need to have any capital\nat all).\nThe need\nfor identity in governance-like situations\nConsider the case of a voting system (eg. likes and retweets on a\nsocial media platform). If user A has 10x the resources of user B, then\nthey have 10x the voting power. But each unit of voting power\nbenefits user A 10x more (in economic terms) than it benefits user B\n(because A is bigger, and so A gains or loses more in economic terms\nfrom everything). Hence, in total, A's vote benefits A 100x more than\nB's vote benefits B. For this reason, we would expect A to put far more\neffort into showing up to vote, determining how to vote to maximize\ntheir goals, and perhaps even being strategic in manipulating\nalgorithms. This is the basic reason why whales in coin voting schemes\nhave an outsized effect.\nHere is a more general, deeper reason why a governance system would\nnot want to give equal weight to $100,000 controlled by one person and\n$100,000 split between 1,000 people: the $100,000 split between 1,000\npeople represents 1,000 different people, and so it's more likely to\nincorporate a higher volume of valuable information, as opposed to a\nsmaller volume of information blasted at high volume. The signal from\n1,000 different people is also likely to come more \"muted\", because its\ndifferent component signals from the different people will often cancel\neach other out.\nThis applies both to formal voting systems, and also to\n\"informal voting systems\" , such as people's ability to\nparticipate in the evolution of the culture by making public\nstatements.\nWhat this shows is that a governance-like system would not truly be\nsatisfied with treating each equal-sized bundle of dollars the same\nregardless of provenance. The system has an interest in knowing the\ninternal coordination level of the bundle of dollars.\nNotice that if you accept the frame that I use to describe both cases\n(UBI-like and governance-like), then technically the explicit\nneed for any kind of one-person-one-vote falls away.\n- For a UBI-like application , what you really need is\nan identity scheme where your first identity is free, but there is a\nlimit on how many identities you can get before getting more identities\nbecomes too costly to be useful to attack the system.\n- For a governance-like application , what you need is\nvisibility into some kind of proxy for whether the bundle of resources\nyou're interacting with is a single actor or some kind of \"organic\"\nless-coordinated set.\nIdentity is still very useful in both cases - but the\nrequirement for it to follow any kind of strict one-per-person rule is\nno longer there.\nThe\ntheoretical ideal is N identities at a cost of NÂČ\nFrom the above arguments, we can see that there are two pressures\nthat bound from opposite ends the desired difficulty of acquiring\nmultiple identities in an identity system:\n- There can't be an easily legible hard limit on how\nmany identities you can easily get. If you can only have one identity,\nyou do not have pseudonymity, and you can be coerced into revealing it.\nIn fact, even a constant number greater than one is risky: if it's\ncommon knowledge that everyone has five identities, you can be coerced\ninto revealing all five.\nA secondary argument for this is that\npseudonymity is fragile, and so it requires a large safety\nbuffer . With modern AI tools, it's easy to correlate activity\nbetween multiple platforms: between choices of words\nyou use , times of day you post, time intervals between posts, topics\nof conversation, and other public information, you only need 33 bits of information to\nuniquely identify a person in the world. One could use AI tools\ndefensively to counter this (eg. I've anonymously published things by\nwriting them in other languages and using locally-running LLMs to\ntranslate to English), but even still, you do not want one mistake to be\nthe end of your pseudonymity.\n- Identity can't be purely financial (N identities at a cost\nof N) because this is too vulnerable to large-scale actors having\noversized influence (and hence smaller-scale actors having no\ninfluence at all). We saw some of this with the new Twitter Blue, where\nthe $8 per month cost of getting a checkmark was too low to\nseriously limit any abuse, and today the checkmark is largely ignored by\nusers.\nAdditionally, we may not want actors with N times more\nresources to be able to get away with N times more misbehavior.\nTaking these arguments together, we want it to be as easy as\npossible to get multiple identities, subject to the constraints of (i)\nlimiting the power of large-scale actors in governance-like\napplications, (ii) limiting the ability to exploit UBI-like\napplications.\nIf we draw directly from the mathematical models for governance-like\napplications in the previous section, then we get a very clean answer:\nif having N identities gives you NÂČ power, then the cost of\ngetting N identities should be NÂČ . And, it just so happens,\nthis is a satisfactory answer for UBI-like applications as well.\nLong-time readers of this blog may notice that this looks\nexactly like the chart from an earlier\npost on quadratic funding . This is not a coincidence.\nPluralistic\nidentity accommodates this ideal\nBy \"pluralistic identity\", I mean an identity regime where there is\nno single dominant issuing authority, whether that's a person, or an\ninstitution, or a platform. This can be accomplished in two ways:\n- Explicit pluralistic identity (also called\n\"social-graph-based identity\" ): you prove that you are\na person (or some other claim, eg. that you are a member of a community)\nthrough attestations from others in that community, who are in turn\nthemselves verified through the same mechanism. The Decentralized\nSociety paper talks about these designs in more detail. Circles is a live example of this in\naction.\n- Implicit pluralistic identity . This is the status\nquo today: there are many different identity providers - Google,\nTwitter, their various equivalents in other countries, multiple forms of\ngovernment ID, etc. There are very few applications that accepts only\none of these; most accept multiple, because they have to in order to\nreach their potential users.\nA recent snapshot of the Circles identity graph. Circles\nis one of the largest live running social-graph-based identity\nprojects.\nExplicit pluralistic identity naturally bakes in the capacity\nfor pseudonymity : you can have a pseudonymous identity (or even\nmultiple), and each of those identities can build up reputation in their\ncommunities through their actions. An ideal explicit pluralistic\nidentity system may not even need to have the concept of discrete\nidentities; rather, you might have an amorphous cloud of your provable\npast actions, and prove different parts of it in a fine-grained way as\nneeded for each action.\nZero-knowledge proofs will make pseudonymity easier, because you can\nuse your primary identity to bootstrap a pseudonym, by privately\nproviding the first signal that the new pseudonym should be taken\nseriously (eg. ZK-proving ownership of some quantity of coins to post\nfrom anon.world , or perhaps one can\nZK-prove some claim about what kind of Twitter followers one has). There\nmay well be even more effective ways of using zero-knowledge proofs.\nImplicit pluralistic identity has a \"cost curve\" which is\nsteeper than quadratic, but still has most of the right\nproperties . Most people have some of the forms of ID that I've\nlisted in this post, but not all. You can get one more form of ID with\nsome effort, and the more forms of ID you get, the less favorable the\nbenefit/cost ratio of getting the next one. Hence, it provides the\nneeded brake on governance attacks and other abuse, while still ensuring\nthat there is no fixed set of IDs that a coercer can demand, and\nreasonably expect, you to reveal.\nAny form of pluralistic identity (implicit or explicit) is\nnaturally more error-tolerant : someone with disfigured hands or\neyes would still likely have a passport, and a stateless person would\nstill likely have access to some non-state way of proving that they are\na person.\nNote that these properties break if any one form of ID gets\nclose to 100% market share, and it becomes realistic to demand it as a\nsole login option . This to me is the biggest risk that could\ncome from identity systems that try too hard to be \"universal\": if their\nmarket share gets too close to 100%, they shift the world from the\npluralistic identity to a one-per-person model, which has worse\nproperties for the reasons I described in this post.\nIn my view, the ideal outcome of \"one-per-person\" identity projects\nthat exist today is if they were to merge with social-graph-based\nidentity. The largest problem that social-graph-based identity projects\nhave is scaling to a very large number of users. One-per-person identity\nsystems could be used to bootstrap social graphs, creating millions of\n\"seeds\", at which point there would be enough adoption to safely grow a\nglobally distributed social graph from that point forward."}
{"url":"https://docs.sei.io/learn/user-quickstart","domain":"docs.sei.io","title":"Getting Started with Sei Network: User Quick Start Guide - Sei Docs","hash":"9bd81a693d904221915a73f44262f208b4e9f0b78ba8a84d0ed607f0a0450b4a","tokens":426,"chars":1702,"crawler":"hive-genesis","verified":"unchecked","ts":1791112010249,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nSei Docs home page\nLearn\nEVM\nCosmos-SDK\nNodes\nAI\nGetting Started with Sei Network: User Quick Start Guide\nComprehensive guide to Getting Started with Sei Network: User Quick Start Guide on Sei. Learn key concepts, commands, and best practices.\nThis guide helps you set up your wallet and start using Sei, even if you are new to blockchain.\n1. Get a wallet\nDownload a compatible wallet, such as MetaMask , Rabby , Binance Wallet , or any other supported wallet .\n2. Set up and âassociateâ your wallet\nAny transaction that you make broadcasts your public key to the chain. This gives your wallet full cross-environment functionality. If your wallet is not âassociatedâ, the network does not know that your key exists. A cryptographic algorithm derives the EVM wallet address from the key. Without the key, the network cannot tell which two addresses belong to the same wallet.\nLearn more about how accounts work on Sei.\n3. Get tokens\n- Bridge from another network\n- Transfer from another account\n- Use the faucet (Sei Testnet only)\n- Transfer from a centralized exchange (CEX) to your wallet address\nCheck your CEXâs guidelines to make sure that your transfers go smoothly. Withdrawals from a CEX typically do not need a memo, but deposits back to a CEX may need one.\n4. Explore the ecosystem\nSei has a diverse ecosystem of dApps, including DeFi and games. To find the latest projects, explore the Sei Ecosystem Hub or follow @SeiNetwork on X.\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://eips.ethereum.org/EIPS/eip-721","domain":"eips.ethereum.org","title":"ERC-721: Non-Fungible Token Standard","hash":"b22e96b7f4c7897c6b82fa2760b446eacbae916511d6505f615675c6461c5468","tokens":7325,"chars":29297,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112010225,"text":"Ethereum Improvement Proposals\nđ Final\nStandards Track: ERC\nERC-721: Non-Fungible Token Standard\nAuthors\nWilliam Entriken ( @fulldecent ), Dieter Shirley < dete@axiomzen.co >, Jacob Evans < jacob@dekz.net >, Nastassia Sachs < nastassia.sachs@protonmail.com >\nCreated\n2018-01-24\nRequires\nEIP-165\nTable of Contents\n- Simple Summary\n- Abstract\n- Motivation\n- Specification\n- Caveats\n- Rationale\n- Backwards Compatibility\n- Test Cases\n- Implementations\n- References\n- Copyright\nSimple Summary\nA standard interface for non-fungible tokens, also known as deeds.\nAbstract\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.\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- Physical property â houses, unique artwork\n- Virtual collectibles â unique pictures of kittens, collectible cards\n- âNegative valueâ assets â loans, burdens and other responsibilities\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.\nMotivation\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.\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).\nDifferences between this standard and EIP-20 are examined below.\nSpecification\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.\nEvery ERC-721 compliant contract must implement the ERC721 and ERC165 interfaces (subject to âcaveatsâ below):\npragma solidity ^ 0.4 . 20 ;\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.\nevent Transfer ( address indexed _from , address indexed _to , uint256 indexed _tokenId );\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.\nevent Approval ( address indexed _owner , address indexed _approved , uint256 indexed _tokenId );\n/// @dev This emits when an operator is enabled or disabled for an owner.\n/// The operator can manage all NFTs of the owner.\nevent ApprovalForAll ( address indexed _owner , address indexed _operator , bool _approved );\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\nfunction balanceOf ( address _owner ) external view returns ( uint256 );\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\nfunction ownerOf ( uint256 _tokenId ) external view returns ( address );\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`\nfunction safeTransferFrom ( address _from , address _to , uint256 _tokenId , bytes data ) external payable ;\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\nfunction safeTransferFrom ( address _from , address _to , uint256 _tokenId ) external payable ;\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\nfunction transferFrom ( address _from , address _to , uint256 _tokenId ) external payable ;\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\nfunction approve ( address _approved , uint256 _tokenId ) external payable ;\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\nfunction setApprovalForAll ( address _operator , bool _approved ) external ;\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\nfunction getApproved ( uint256 _tokenId ) external view returns ( address );\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\nfunction isApprovedForAll ( address _owner , address _operator ) external view returns ( bool );\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\nfunction supportsInterface ( bytes4 interfaceID ) external view returns ( bool );\n}\nA wallet/broker/auction application MUST implement the wallet interface if it will accept safe transfers.\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\nfunction onERC721Received ( address _operator , address _from , uint256 _tokenId , bytes _data ) external returns ( bytes4 );\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/// @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\nfunction name () external view returns ( string _name );\n/// @notice An abbreviated name for NFTs in this contract\nfunction symbol () external view returns ( string _symbol );\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\".\nfunction tokenURI ( uint256 _tokenId ) external view returns ( string );\n}\nThis is the âERC721 Metadata JSON Schemaâ referenced above.\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}\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/// @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\nfunction totalSupply () external view returns ( uint256 );\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)\nfunction tokenByIndex ( uint256 _index ) external view returns ( uint256 );\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)\nfunction tokenOfOwnerByIndex ( address _owner , uint256 _index ) external view returns ( uint256 );\n}\nCaveats\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- 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.\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.\nRationale\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âNFTâ Word Choice\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).\nAlternatives considered: distinguishable asset, title, token, asset, equity, ticket\nNFT Identifiers\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.\nThe choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256 .\nTransfer Mechanism\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- The owner of an NFT\n- The approved address of an NFT\n- An authorized operator of the current owner of an NFT\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.\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- 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\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.\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.\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.\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.\nERC-165 Interface\nWe chose Standard Interface Detection (ERC-165) to expose the interfaces that a ERC-721 smart contract supports.\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.\nGas and Complexity (regarding the enumeration extension)\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.\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.\nThis illustration makes clear: the ERC-721 standard scales.\nAlternatives considered: remove the asset enumeration function if it requires a for-loop, return a Solidity array type from enumeration functions.\nPrivacy\nWallets/brokers/auctioneers identified in the motivation section have a strong need to identify which NFTs an owner owns.\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 .\nMetadata Choices (metadata extension)\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.\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.\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.\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.\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)\nCommunity Consensus\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- @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\nA second event was held at ETHDenver 2018 to discuss distinguishable asset standards (notes to be published).\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.\nBackwards Compatibility\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.\nExample NFT implementations as of February 2018:\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.\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).\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 true s.\nTest Cases\n0xcert ERC-721 Token includes test cases written using Truffle.\nImplementations\n0xcert ERC721 â a reference implementation\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\nSu Squares â an advertising platform where you can rent space and place images\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\nERC721ExampleDeed â an example implementation\n- Implements using the OpenZeppelin project format\nXXXXERC721, by William Entriken â a scalable example implementation\n- Deployed on testnet with 1 billion assets and supporting all lookups with the metadata extension. This demonstrates that scaling is NOT a problem.\nReferences\nStandards\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\nIssues\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\nDiscussions\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\nNFT Implementations and Other Projects\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 .\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nWilliam 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."}
{"url":"https://www.metaplex.com/docs/agents/nori","domain":"www.metaplex.com","title":"Nori - Pay-As-You-Go LLM, Image, and RPC Services for Agents | Metaplex","hash":"5dc9ec71c22b1eb655b3222adaba9900137a06843d56e4dd3e858969602234a4","tokens":2689,"chars":10755,"crawler":"hive-genesis","verified":"unchecked","ts":1791112012175,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nNori\nNori - Pay-As-You-Go Services for Metaplex Agents\nLast updated July 8, 2026\nNori is a pay-as-you-go service agent operated by the Metaplex Foundation. It sells LLM inference, image generation, and Solana RPC access to other agents â priced in USD, settled in SOL per call against the calling agent's onchain wallet. Nori is also the open-source reference implementation of a Metaplex service agent: agent builders can study (and copy) its A2A surface , delegate-pay billing, x402 fallback, and rate-card patterns.\nSummary\nNori removes the plumbing every agent operator otherwise wires up themselves â LLM provider keys, an image-generation account, paid Solana RPC, and per-call billing. A consumer agent needs only a Solana keypair and a registered agent asset .\n- Three metered services â chat.completion (Anthropic / OpenAI / Google, tool calls supported), image.generation (gpt-image-1), and solana.rpc (RPC + DAS pass-through)\n- Two payment rails â delegate-pay (primary, one-time onchain setup) and x402 v2 (fallback, per-call HTTP 402 flow)\n- Charge-on-success billing â the upstream call runs first; failed calls are never charged, and every charge carries an onchain Memo receipt\n- Single point of failure caveat â a delegated agent depends on Nori's availability for inference, images, and RPC; see Nori as a single point of failure for mitigations\nTwo audiences, one page\nUse this section if you are consuming Nori's services from your own agent, or if you are building a service agent and want a working reference for A2A skills, per-call billing, and rate-card publication. The source repository is open source.\nServices Nori Provides\nNori exposes three services over two surfaces that share one handler stack. Skill input/output uses canonical OpenAI wire format for chat and images, and standard Solana JSON-RPC for RPC â an A2A caller and an OpenAI-SDK caller send byte-identical payloads.\nService Skill ID Endpoint Upstream\nLLM inference (tool calls supported) chat.completion POST /v1/chat/completions Anthropic, OpenAI, Google â routed by ","hash":"867cfe7ccf651cdedf7769c8adf7d0b35f117310f5a195f3a3489d4f15f63998","tokens":2159,"chars":8635,"crawler":"crawler-dfxz","verified":"exact","ts":1791112015653,"text":"# \n[](https://github.com/OpenZeppelin/openzeppelin-contracts/releases/latest)\n[](https://www.npmjs.org/package/@openzeppelin/contracts)\n[](https://codecov.io/gh/OpenZeppelin/openzeppelin-contracts)\n[](https://docs.openzeppelin.com/contracts)\n[](https://forum.openzeppelin.com/)\n**A library for secure smart contract development.** Build on a solid foundation of community-vetted code.\n* Implementations of standards like [ERC20](https://docs.openzeppelin.com/contracts/erc20) and [ERC721](https://docs.openzeppelin.com/contracts/erc721).\n* Flexible [role-based permissioning](https://docs.openzeppelin.com/contracts/access-control) scheme.\n* Reusable [Solidity components](https://docs.openzeppelin.com/contracts/utilities) to build custom contracts and complex decentralized systems.\n:mage: **Not sure how to get started?** Check out [Contracts Wizard](https://wizard.openzeppelin.com/) â an interactive smart contract generator.\n> [!IMPORTANT]\n> OpenZeppelin 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](https://docs.openzeppelin.com/contracts/backwards-compatibility).\n## Overview\n### Release tags\nWe use NPM tags to clearly distinguish between audited and non-audited versions of our package:\n| Tag | Purpose | Description |\n| :--------- | :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **latest** | â
Audited releases | Stable, audited versions of the package. This is the **default** version installed when users run `npm install @openzeppelin/contracts`. |\n| **dev** | đ§Ș 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. |\n| **next** | đ§ Release candidates | Pre-release versions that are **not final**. Used for testing and validation before the version becomes a final `dev` or `latest` release. |\n### Installation\n#### Hardhat (npm)\n```\n$ npm install @openzeppelin/contracts\n```\nâ Installs the latest audited release (`latest`).\n```\n$ npm install @openzeppelin/contracts@dev\n```\nâ Installs the latest unaudited release (`dev`).\n#### Foundry (git)\n> [!WARNING]\n> When 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.\n> [!WARNING]\n> Foundry installs the latest version initially, but subsequent `forge update` commands will use the `master` branch.\n```\n$ forge install OpenZeppelin/openzeppelin-contracts\n```\nAdd `@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/` in `remappings.txt`.\n### Usage\nOnce installed, you can use the contracts in the library by importing them:\n```solidity\npragma solidity ^0.8.20;\nimport {ERC721} from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\";\ncontract MyCollectible is ERC721 {\nconstructor() ERC721(\"MyCollectible\", \"MCO\") {\n}\n```\n_If you're new to smart contract development, head to [Developing Smart Contracts](https://docs.openzeppelin.com/learn/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.\n## Learn More\nThe guides in the [documentation site](https://docs.openzeppelin.com/contracts) will teach about different concepts, and how to use the related contracts that OpenZeppelin Contracts provides:\n* [Access Control](https://docs.openzeppelin.com/contracts/access-control): decide who can perform each of the actions on your system.\n* [Tokens](https://docs.openzeppelin.com/contracts/tokens): create tradeable assets or collectibles for popular ERC standards like ERC-20, ERC-721, ERC-1155, and ERC-6909.\n* [Utilities](https://docs.openzeppelin.com/contracts/utilities): generic useful tools including non-overflowing math, signature verification, and trustless paying systems.\nThe [full API](https://docs.openzeppelin.com/contracts/api/token/ERC20) 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](https://forum.openzeppelin.com).\nFinally, you may want to take a look at the [guides on our blog](https://blog.openzeppelin.com/), which cover several common use cases and good practices. The following articles provide great background reading, though please note that some of the referenced tools have changed, as the tooling in the ecosystem continues to rapidly evolve.\n* [The Hitchhikerâs Guide to Smart Contracts in Ethereum](https://blog.openzeppelin.com/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05) will help you get an overview of the various tools available for smart contract development, and help you set up your environment.\n* [A Gentle Introduction to Ethereum Programming, Part 1](https://blog.openzeppelin.com/a-gentle-introduction-to-ethereum-programming-part-1-783cc7796094) provides very useful information on an introductory level, including many basic concepts from the Ethereum platform.\n* For a more in-depth dive, you may read the guide [Designing the Architecture for Your Ethereum Application](https://blog.openzeppelin.com/designing-the-architecture-for-your-ethereum-application-9cec086f8317), which discusses how to better structure your application and its relationship to the real world.\n## Security\nThis project is maintained by [OpenZeppelin](https://openzeppelin.com) with the goal of providing a secure and reliable library of smart contract components for the ecosystem. We address security through risk management in various areas such as engineering and open source best practices, scoping and API design, multi-layered review processes, and incident response preparedness.\nThe [OpenZeppelin Contracts Security Center](https://contracts.openzeppelin.com/security) contains more details about the secure development process.\nThe security policy is detailed in [`SECURITY.md`](./SECURITY.md) as well, and specifies how you can report security vulnerabilities, which versions will receive security patches, and how to stay informed about them. We run a [bug bounty program on Immunefi](https://immunefi.com/bounty/openzeppelin) to reward the responsible disclosure of vulnerabilities.\nThe engineering guidelines we follow to promote project quality can be found in [`GUIDELINES.md`](./GUIDELINES.md).\nPast audits can be found in [`audits/`](./audits).\nSmart contracts are a nascent technology and carry a high level of technical risk and uncertainty. Although OpenZeppelin is well known for its security audits, using OpenZeppelin Contracts is not a substitute for a security audit.\nOpenZeppelin Contracts is made available under the MIT License, which disclaims all warranties in relation to the project and which limits the liability of those that contribute and maintain the project, including OpenZeppelin. As set out further in the Terms, you acknowledge that you are solely responsible for any use of OpenZeppelin Contracts and you assume all risks associated with any such use.\n## Contribute\nOpenZeppelin Contracts exists thanks to its contributors. There are many ways you can participate and help build high quality software. Check out the [contribution guide](CONTRIBUTING.md)!\n## License\nOpenZeppelin Contracts is released under the [MIT License](LICENSE).\n## Legal\nYour use of this Project is governed by the terms found at www.openzeppelin.com/tos (the \"Terms\")."}
{"url":"https://aptos.dev/","domain":"aptos.dev","title":"","hash":"8915241adfd83bd0e8322af9af869e258b847034acc1ad56850af2369c54ac31","tokens":602,"chars":2405,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112017492,"text":"Getting Started\n* [Deploy Your First Move Smart Contract](/build/guides/first-move-module) Compile & publish Move modules to devnet in minutes.\n* [Your First Transaction](/build/guides/first-transaction) Write and read on-chain data using the TypeScript SDK.\n* [Code with AI (MCP)](/build/ai/aptos-mcp) Give Cursor, Claude Code, and Codex direct access to Aptos APIs.\n* [Agent Skills](/build/ai/aptos-agent-skills) Move and TS SDK skills for Claude Code, Cursor, Copilot.\nTools\n* [Testnet Faucet](/network/faucet) Fund your testnet account with APT to start building.\n* [Official SDKs](/build/sdks) TypeScript, Python, Go, Rust, and more.\n* [Aptos CLI](/build/cli) Compile, test, publish contracts; accounts & keys; localnet.\nSmart Contracts\n* [NEW! Move on Aptos (VS Code Extension)](/build/smart-contracts/move-vscode-extension) Aptos Labsâ official extension for Move development.\n* [Objects](/build/smart-contracts/objects) Composable on-chain primitives for flexible asset ownership, addressing, & programmability.\n* [The Move Book](https://aptos-labs.github.io/move-book/) Understand Move syntax, types, resources, & best practices.\n* [Vibe Code a full-stack dApp on Learn](https://learn.aptoslabs.com/en/hackathon/vibe-coder-to-aptos-guide/introduction) Interactive AI workshop to quickly build a full-stack dApp.\nOn-Chain Features\n* [Sponsored Transactions](/build/guides/sponsored-transactions) Pay for usersâ gas so they can use your dApp with zero APT.\n* [Keyless Accounts](/build/guides/aptos-keyless) Onboard users and sign without wallets or seed phrases.\n* [NEW! Orderless Transactions](/build/guides/orderless-transactions) High-volume apps can be safer by sending transactions out of order with replay-protection nonce.\n* [On-chain Randomness](/build/smart-contracts/randomness) Verifiable random number = fair games, lotteries, & drops.\nResources\n* [LLMs.txt Integration](/llms-txt) AI-optimized documentation feeds for coding assistants and chat tools.\n* [Query, Index, or Stream On-Chain Data](/build/indexer) Query Indexer API, index contracts, stream raw transactions.\n* [Apply for a Grant](https://aptosnetwork.com/grants)\nConnect\n* [GitHub Developer Discussions](https://github.com/aptos-labs/aptos-developer-discussions/discussions)\n* [Ecosystem Directory](https://aptosnetwork.com/ecosystem/directory)\n* [Discord](https://discord.gg/aptosnetwork)\n* [Telegram](https://t.me/aptos)"}
{"url":"https://docs.velocity.exchange/protocol","domain":"docs.velocity.exchange","title":"Introduction to Velocity | Velocity Protocol","hash":"a7d419b35cf92d8ec90290cb93cebf95699dc185989465344ea1cf83694b2997","tokens":1221,"chars":4881,"crawler":"crawler-dfxz","verified":"unchecked","ts":1791112019231,"text":"Velocity Protocol Developers\nView as Markdown\nIntroduction to Velocity\nWhere perpetual futures and lending meet on one balance, what a fill costs, and where to start reading.\nVelocity is a perpetual futures exchange and a money market, deployed as a single Solana program. Each subaccount holds one pool of collateral, that pool backs every perpetual position opened against it, and the same tokens are lent to borrowers while they sit there. Trading is perpetuals only.\nSpot trading has been removed from the Velocity program. Spot markets exist only for collateral and borrow-lend. Spot assets can still be exchanged through swaps .\nOne deposit doing two jobs\nOn most venues margin is money parked: it backs positions and earns nothing, and moving it somewhere that pays means it stops being margin. Velocity never separates the two balances. A deposit lands in that asset's spot market vault, counts toward the account's margin at the asset's collateral weight, and is lendable inventory from the same moment. Three things follow:\n- Margin earns the lending rate while it backs a trade. Interest accrues to the spot balance continuously, priced off that market's utilization.\n- There is no borrow instruction. A borrow is what a withdrawal becomes once it passes the account's balance in that market.\n- A withdrawal is checked twice. The account's own margin has to survive it, and so does the market's withdrawal limit, because the tokens requested have partly been lent out. The second check is usually why a withdrawal is refused, and it usually clears on its own.\nNot every asset counts for its full value as collateral: the quote asset does, anything more volatile is weighted down. Collateral and margin has the weights; Borrow and lend has the utilization curve.\nWhat a trade costs\nPerpetual fills charge the taker a fee on the filled notional, in the quote asset: 4 bps of notional at the base tier, 3 bps above $5,000,000 and 2 bps above $80,000,000 of trailing 30-day volume. The maker on that fill is paid 0.25 bps of notional out of it, flat at every tier. Individual markets can add to the taker fee, capped at 10 bps on top, so a tier rate is a floor rather than a promise.\nSpot markets and the direct swap path charge no maker or taker fee. Funding is not a fee: it is an hourly payment between longs and shorts, and a position can receive it as readily as pay it. See Trading fees and Funding rates .\nHow an order is filled\nThere is no central matching engine. Orders live onchain as accounts, an offchain network of keepers and market makers watches them, and anyone can submit the transaction that fills one. Three sources of liquidity can end up on the other side of a taker order: resting orders on the decentralized orderbook (DLOB), market makers quoting just in time, and the protocol's own AMM. They are not three stages in a fixed order, and one taker order can fill from more than one of them in a single transaction.\nEvery perpetual market order also carries a short Dutch auction, so its price starts somewhere favorable to the taker and walks toward the limit price while makers compete to take it. The exchange enforces a minimum auction duration, and each market sets its own default. See How fills work and Auctions .\nWhere to go next\nThe app is at app.velocity.exchange . Starting from nothing, read What a perpetual is , then A first trade , which follows one $10,000 account from deposit to withdrawal. The rest is reference:\n- Opening an account : Wallet setup , Subaccounts , Delegated accounts\n- Trading : Collateral and margin , Order types , Auctions , Trading fees , Funding rates , Liquidations\n- Lending and borrowing : Borrow and lend , Interest rates , Withdrawal limits\n- The machinery : How fills work , Velocity AMM , Orderbook and keepers , Oracles , Where the money sits\n- Sizing risk : Risks , Contract tiers , Guard rails , Insurance fund , Admin keys\n- Building on it : TypeScript SDK , Keeper bots , Market makers\nSource and audits\nThe Velocity program is not open source yet. The source will be published once the post-fork audit report is final. The TypeScript SDK is on npm today, and this documentation site is open to contributions. See Velocity for Developers .\nOtterSec audited Velocity's own program after the fork, and the final report is published: 154 findings, no Critical, and every High fixed in the deployed code. The Drift Protocol v2 codebase Velocity forked carries earlier audits by Trail of Bits and Neodyme. See Audits for the record, and the migration guide for porting an existing integration.\nEdit on GitHub\nWhat a perpetual is\nA futures contract settles on a fixed date, and that date is the problem. What removing it breaks, how funding fixes it, and what the position actually is.\nOn this page\nOne deposit doing two jobs\nWhat a trade costs\nHow an order is filled\nWhere to go next\nSource and audits"}
{"url":"https://docs.near.org/","domain":"docs.near.org","title":"Home - NEAR Docs","hash":"ff65ebe8f7aae0691398c8b861ea6bbc68fcb768996ce5d75b68b6d4ff5814c8","tokens":590,"chars":2357,"crawler":"hive-genesis","verified":"exact","ts":1791112019371,"text":"Documentation Index\nFetch the complete documentation index at: /llms.txt\nUse this file to discover all available pages before exploring further.\nSkip to main content\nNEAR Docs home page\nHome\nProtocol\nSmart Contracts\nWeb3 Apps\nMulti-Chain\nTokens & Primitives\nData Infra\nRPC\nMCP Ready LLMs.txt Ready\nNEAR Developer Docs\nBuild contracts in Rust, create Web3 apps, and sign transactions on any chain from a single NEAR account.\nDeploy your First Contract\nCreate, test and deploy contracts with simple commands.\nWhat is a Contract? â\nQuickstart â\ncargo near new hello-world\n# â
Success! Created 'hello-near', a smart contract in Rust\n# Build, test, and deploy your contract with Cargo\ncargo near build\ncargo test\ncargo near deploy\nYou can easily create testnet accounts and request testnet tokens to the faucet .\nnpx create-near-app@latest\n# â
What do you want to build? âș \"A Web App\"\n# â
Select a framework for your frontend âș \"Vite (React)\"\n# â
Name your project: \"hello-near\"\n#Start using your new NEAR app:\ncd hello-near\nnpm run dev\nBuild Web3 Applications\nEasily authenticate users and call smart contracts from any frontend framework.\nWhat are Web3 Apps? â\nCreate your first app â\nWhy NEAR?\nSub-second block finality\nTransactions reach deterministic finality in 1.3s, no reorgs, no waiting.\nNear-zero fees\nAverage transaction fees are $0.002. Storage costs are fully refundable upon deletion.\nSharded & scalable\nThe network automatically scales as demand grows, with no downtime or hard forks.\nWASM contracts in Rust\nWrite complex contracts in Rustâor use community SDKs for JavaScript, Python, and Go.\nChain Signatures\nControl accounts on Bitcoin, Ethereum, Solana, and more.\nTEE-backed agents\nRun AI inference inside Trusted Execution Environments for verifiable, tamper-proof outputs.\nBrowse the docs\nProtocol\nAccounts, access keys, gas, transactions, consensus, and more.\nSmart contract reference\nState, functions, collections, callbacks, cross-contract calls, and security.\nWeb application guides\nWallet authentication, JavaScript APIs, data types, and contract calls.\nTokens and primitives\nFTs, NFTs, DAOs, linkdrops, staking, oracles, and off-chain compute.\nData infrastructure\nIndex and query on-chain data with NEAR Lake, BigQuery, and indexers.\nAI agent tooling\nUse llms.txt, Docs MCP, agent skills, and on-chain MCP tools.\nWas this page helpful?"}
{"url":"https://docs.ton.org/","domain":"docs.ton.org","title":"TON Docs â developer documentation","hash":"14612662575680cde9a5dbca9e8805a3324e8bc5566161c4fbcbaf7189a5f683","tokens":730,"chars":2920,"crawler":"hive-genesis","verified":"exact","ts":1791112021213,"text":"The Open Network\nTON Documentation\nTON is a blockchain platform designed for scalable smart contracts, applications, and payments at consumer scale.\nUnified toolchain for smart contracts\nActon is a TON smart contract toolkit. One CLI handles project setup, builds, tests, scripts, linting, formatting, debugging, deployment, and verification. Acton Studio adds a browser workspace with comprehensive UI for local tests, virtual environments, and interaction with real networks, such as mainnet and testnet.\nTest contract behavior\nRun tests that follow transaction flows between contracts.\nYour browser does not support video playback.\nDebug failures\nPause at a failure and inspect the code, call stack, and local values.\nYour browser does not support video playback.\nConnect contracts to apps\nGenerate typed interfaces for web apps that connect to TON wallets.\nYour browser does not support video playback.\nDeploy and verify\nManage wallets, get testnet funds, deploy and verify contracts.\nYour browser does not support video playback.\nReady to build?\nInstall Acton, then choose a guide below.\ncurl -LsSf https://github.com/ton-blockchain/acton/releases/latest/download/acton-installer.sh | sh\nBuilding a frontend? See the Acton dApp guide .\nTelegram Mini Apps selling digital goods or services must use Stars .\nLearning paths\nOnboarding\nFor newcomers entering Web3 through TON.\n- Overview of TON and the documentation\n- Create a TON wallet\n- Read blockchain data with explorers\n- Enable TON for agents with @ton/mcp\nApplications\nBuild dApps, wallets, and payment services on TON.\n- Overview\n- Create tools using SDKs\n- Integrate dApps and wallets with TON Connect\n- Process payments in business applications\nNodes\nRun and manage TON blockchain nodes.\n- Overview\n- C++ node setup\n- Run a validator node\n- Run a liteserver node\n- Run an archive liteserver\nAPIs\nAccess TON data via hosted APIs or self-hosted options.\n- Overview\n- API v2: direct liteserver\n- API v3: indexed database\n- Streaming API: status updates\n- Get API key\nSmart contracts\nBuild, debug, and deploy smart contracts.\n- Overview\n- Toolchain and IDEs\n- Wallet contracts\n- Jettons and NFTs\n- Advanced techniques\nTolk language\nMaster the language of TON smart contracts.\n- Overview\n- Basic syntax\n- Idioms and conventions\n- Type system\n- Standard library reference\nTVM: TON Virtual Machine\nSkim the detailed reference of the smart-contract runtime.\n- Overview\n- Exit codes\n- Instructions\n- Gas\n- Registers\nBlockchain foundations\nLearn all the ins and outs of the TON blockchain.\n- Overview\n- Addresses\n- Transaction fees\n- Config\n- TL-B\nTroubleshooting\nPress Ctrl K to search the docs. Still stuck? Discuss issues and best practices with other community members.\nGet support\nLearn how to get help on the dedicated page.\nTelegram folder\nAdd the folder with many developer chats.\nTON Dev chat\nJoin the discussion in the main TON development chat on Telegram."}
{"url":"https://raw.githubusercontent.com/anza-xyz/agave/master/README.md","domain":"raw.githubusercontent.com","title":"Building","hash":"5b46d746eb8b2a5194233084775203dd1f493cb61835ebd82ccdf713634f6503","tokens":1117,"chars":4466,"crawler":"crawler-dfxz","verified":"exact","ts":1791112020998,"text":"\n\n![\"Anza\"](\"https://i.postimg.cc/VkKTnMM9/agave-logo-talc-1.png\"){kind=logo}
\n\n