\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/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://eips.ethereum.org/","domain":"eips.ethereum.org","title":"Home | Ethereum Improvement Proposals","hash":"a69dab874eabf20389ea74afd0673ed0556b82115990aabcc4208524c864f3a3","tokens":1079,"chars":4314,"crawler":"crawler-74kg","verified":"exact","ts":1791170345299,"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.optimism.io/","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"896ea3947522cac643fdfdac031ea4799760bca0a1bcf0faea43c62f85e64ef6","tokens":437,"chars":1745,"crawler":"crawler-74kg","verified":"exact","ts":1791170347371,"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://developers.uniswap.org/docs","domain":"developers.uniswap.org","title":"Docs | Uniswap Developers","hash":"47b255c73b03c6fcd7d0265de32caa6b27e9694b5f29708c5636c36612b0f414","tokens":200,"chars":800,"crawler":"crawler-74kg","verified":"exact","ts":1791170375221,"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://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":"crawler-74kg","verified":"exact","ts":1791170378098,"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://raw.githubusercontent.com/ethereum/consensus-specs/master/README.md","domain":"raw.githubusercontent.com","title":"Ethereum Consensus Specifications","hash":"f666481980e801298d7786c04363b8cb1070f3ca46e5b7fb134725be7caffe2e","tokens":831,"chars":3323,"crawler":"crawler-74kg","verified":"exact","ts":1791170411456,"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://kamino.com/docs","domain":"kamino.com","title":"Overview - Kamino Docs","hash":"556e5cc10a88192985ecd7db19b36e88247346ec4b92c2b384b57c0834c5f65d","tokens":1006,"chars":4023,"crawler":"crawler-74kg","verified":"exact","ts":1791170417688,"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://docs.lido.fi/","domain":"docs.lido.fi","title":"Introduction | Lido Docs","hash":"efe199bbd8d6c9bf66b79724077ab3f4e4d379149445615563dc8cfcd4018afb","tokens":2267,"chars":9065,"crawler":"crawler-74kg","verified":"exact","ts":1791170468541,"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.arbitrum.io/","domain":"docs.arbitrum.io","title":"Get started with Arbitrum","hash":"1a172a99161034d30d20b59b4f7e0b9abd5876d057b7831a381ff11fd260fe14","tokens":1184,"chars":4736,"crawler":"crawler-74kg","verified":"exact","ts":1791170470650,"text":"> For a complete page index, fetch \n# Get started with Arbitrum\nArbitrum is the finance-native platform providing infrastructure for applications, tokenization, and dedicated chains. These docs explain the protocols, chains, services, and SDKs developers use to build on the Arbitrum platform.\nIn the programmable economy, markets, transactions, and business processes run in software. Arbitrum provides the infrastructure for those systems to execute with configurable rules and Ethereum settlement.\nIf you're ready to start building, try the [Solidity quickstart](/build-decentralized-apps/quickstart-solidity-remix.md) or [Stylus quickstart](/stylus/quickstart.md).\n## Understand Arbitrum\nLearn how Arbitrum scales Ethereum.\n### [Arbitrum introduction](/get-started/arbitrum-introduction.md)\n[A FAQ-style overview of Arbitrum's finance-native platform.](/get-started/arbitrum-introduction.md)\n### [Inside Nitro](/how-arbitrum-works/inside-arbitrum-nitro.md)\n[A technical deep dive into Nitro's architecture.](/how-arbitrum-works/inside-arbitrum-nitro.md)\n### [Inside AnyTrust](/how-arbitrum-works/deep-dives/anytrust-protocol.md)\n[A technical deep dive into the AnyTrust protocol.](/how-arbitrum-works/deep-dives/anytrust-protocol.md)\n### [Nitro whitepaper](/nitro-whitepaper.pdf)\n[The original whitepaper that introduced Nitro.](/nitro-whitepaper.pdf)\n### [DAO governance](https://docs.arbitrum.foundation/gentle-intro-dao-governance)\n[Docs for members of the Arbitrum DAO.](https://docs.arbitrum.foundation/gentle-intro-dao-governance)\n## Build decentralized apps\nDeploy smart contracts to Arbitrum One, Arbitrum Nova, or any Arbitrum chain.\n### [Quickstart (Solidity)](/build-decentralized-apps/quickstart-solidity-remix.md)\n[Deploy your first Solidity smart contract to Arbitrum using Remix.](/build-decentralized-apps/quickstart-solidity-remix.md)\n### [Quickstart (Rust)](/stylus/quickstart.md)\n[Deploy your first Rust smart contract using Arbitrum Stylus.](/stylus/quickstart.md)\n### [Explore Stylus](/stylus/gentle-introduction.md)\n[Write EVM-compatible smart contracts in Rust, C, and other languages that compile to Wasm.](/stylus/gentle-introduction.md)\n### [Chain info](/for-devs/dev-tools-and-resources/chain-info.md)\n[Chain IDs, RPC endpoints, and network parameters.](/for-devs/dev-tools-and-resources/chain-info.md)\n## Launch your own chain\nLaunch a dedicated chain using the Arbitrum platform. Configure execution, gas tokens, data availability, governance, and validation for your product's requirements.\n### [A gentle introduction](/launch-arbitrum-chain/overview/introduction.md)\n[Understand Arbitrum chains' value proposition and use cases.](/launch-arbitrum-chain/overview/introduction.md)\n### [Deploy a chain](/launch-arbitrum-chain/quickstart/sdk-introduction.md)\n[Use the Arbitrum chain SDK to configure and deploy your chain's core contracts.](/launch-arbitrum-chain/quickstart/sdk-introduction.md)\n### [Configure your chain](/launch-arbitrum-chain/chain-config/additional-configuration-parameters.md)\n[Set up throughput, gas tokens, data availability, governance, and more.](/launch-arbitrum-chain/chain-config/additional-configuration-parameters.md)\n### [Migrate from another stack](/launch-arbitrum-chain/migrate/from-another-stack.md)\n[Move an existing chain to Arbitrum technology.](/launch-arbitrum-chain/migrate/from-another-stack.md)\n## Run a node\nRun the machines that power the Arbitrum ecosystem.\n### [Run a full node](/run-arbitrum-node/run-full-node.md)\n[Access Arbitrum chains without connecting to a third-party node.](/run-arbitrum-node/run-full-node.md)\n### [Run an archive node](/run-arbitrum-node/more-types/run-archive-node.md)\n[Access extensive historical data for advanced analytical purposes.](/run-arbitrum-node/more-types/run-archive-node.md)\n### [Run a feed relay](/run-arbitrum-node/run-feed-relay.md)\n[Distribute the sequencer feed across multiple nodes.](/run-arbitrum-node/run-feed-relay.md)\n### [Configure a DAC](/launch-arbitrum-chain/chain-config/data-availability/dac-get-started.md)\n[Run a Data Availability Server for AnyTrust chains.](/launch-arbitrum-chain/chain-config/data-availability/dac-get-started.md)\n## Bridge tokens\nMove **ETH** and **ERC-20** tokens between Ethereum and Arbitrum chains.\n### [Quickstart (bridge)](/arbitrum-bridge/quickstart.md)\n[Step-by-step instructions for first-time bridge users.](/arbitrum-bridge/quickstart.md)\n### [Arbitrum bridge](https://bridge.arbitrum.io/)\n[Transfer tokens between Ethereum, Arbitrum One, Arbitrum Nova, and other Arbitrum chains.](https://bridge.arbitrum.io/)\n### [Arbitrum Portal](https://portal.arbitrum.io/)\n[Discover dApps deployed on Arbitrum.](https://portal.arbitrum.io/)"}
{"url":"https://forum.arbitrum.foundation/latest","domain":"forum.arbitrum.foundation","title":"Latest topics - Arbitrum","hash":"30f32d754828eafe9eacc3418f3a7063412c5fea8a6475e058969d30577b922c","tokens":846,"chars":3383,"crawler":"crawler-74kg","verified":"exact","ts":1791170521286,"text":"Arbitrum\nTopic\nReplies\nViews\nActivity\nWelcome to Discourse\nGeneral\n41\n21688\nMarch 23, 2026\nStableGuard by FintechCheck: Real-Time Stablecoin Depeg Detection for Treasury & DeFi Protection\nGeneral\nproposal\n,\nproposal-discussions\n12\n131\nOctober 4, 2026\n[CONSTITUTIONAL]: Establish an L1 Voting Recovery System\nProposals\nproposal\n0\n34\nOctober 2, 2026\nSecurity Council Emergency Action – 2/10/2026\nSecurity Council\n0\n199\nOctober 2, 2026\nFrom Governance Token to Utility Token: Evolving ARB Beyond Governance\nGeneral\n35\n1261\nOctober 2, 2026\n[Final Report] Paros: Automated Treasury Management for Arbitrum\nDomain Allocator Offerings (prev Questbook)\n0\n26\nOctober 2, 2026\nMoTZ × Arbitrum — Campaign Final Report\nDomain Allocator Offerings (prev Questbook)\n0\n15\nOctober 2, 2026\n[Final Report] T3tris.finance - Zero-fee, permissionless vault infrastructure\nDomain Allocator Offerings (prev Questbook)\n0\n21\nOctober 1, 2026\n[Constitutional] AIP: Transition Arbitrum One ordering policy to Priority Gas Auctions (PGA)\nFinalized AIPs\n30\n2149\nOctober 1, 2026\nQuestion: How would sequencer decentralization affect Arbitrum users?\nTechnical Discussion\n3\n74\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\n47\nSeptember 30, 2026\nRewarding Active Delegates - September 2026 Results\nRewarding Active Delegates Program (RAD)\n0\n54\nSeptember 29, 2026\nArbitrum Security Program is Live: Applications Now Open\nAnnouncements\n0\n70\nSeptember 29, 2026\nArbitrumDAO Factsheet: Robinhood Chain Mainnet Launch\nAnnouncements\n5\n923\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\n115\nSeptember 24, 2026\nSecurity Council key exposure across three chains — draft for review\nTechnical Discussion\nsecurity-council\n14\n172\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\n57\nSeptember 21, 2026\nBanning projects identified in the high-severity Watchdog Program cases\nFinalized AIPs\n11\n394\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\n262\nSeptember 18, 2026\nPractical examples of how Stylus and Orbit help developers\nTechnical Discussion\n2\n40\nSeptember 18, 2026\nParticipation Architecture - Final Grant Report\nDomain Allocator Offerings (prev Questbook)\n28\n376\nSeptember 17, 2026\nnext page →"}
{"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":"6c796932dd8415866725ef3754e4d2fde770b11e1af9c3f18e26c7f1a1620218","tokens":833,"chars":3330,"crawler":"crawler-74kg","verified":"exact","ts":1791170523864,"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\n38243\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\n1962\nOctober 2, 2026\n[Temp Check] Protocol Fee Expansion: Arc\nTemperature Check\n5\n461\nOctober 1, 2026\n[Temp Check] Rotate Sentinel Addresses on the DUNI-Owned Uniswap Earn Vaults\nTemperature Check\n6\n248\nOctober 1, 2026\nAxia Network Delegate Platform\nDelegation Pitch\n11\n333\nOctober 3, 2026\nUniswap-Arbitrum Delegate Program (UADP) Communication Thread\nDelegation Pitch\n39\n6008\nSeptember 29, 2026\nPGov Delegate Platform\nDelegation Pitch\n73\n6455\nSeptember 27, 2026\n[RFC] Native Execution Privacy in the Uniswap Interface via v4 Hooks and UniswapX\nRequests for Comment\n16\n704\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\n454\nAugust 25, 2026\nUniswap Deployment - Guideline\nGovernance-Meta\n2\n930\nAugust 21, 2026\n[Temp Check] Activate v4 Protocol Fees\nTemperature Check\n24\n2782\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\n530\nJuly 23, 2026\n$UNI staking for IL reduction\nRequests for Comment\n3\n3176\nJuly 23, 2026\nCuria Delegate Platform\nDelegation Pitch\n53\n2381\nJuly 23, 2026\n[RFC - Update] Deploy Uniswap v3 (1 / 0.3 / 0.05 / 0.01) on BNB Chain (Binance)\nRequests for Comment\n101\n45661\nJuly 22, 2026\n[Temp Check] Protocol Fee Expansion: Robinhood Chain\nTemperature Check\n3\n984\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\n2911\nJuly 18, 2026\nArgonaut Delegate Platform\nDelegation Pitch\n63\n1816\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\n4670\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://docs.filecoin.io/","domain":"docs.filecoin.io","title":"Welcome to Filecoin Docs | Filecoin Docs","hash":"5a57fc3d653c027fc6a255b356beedb1bff0eac53c6a4f59c32652dd61a8f824","tokens":320,"chars":1279,"crawler":"crawler-74kg","verified":"exact","ts":1791170652633,"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://raw.githubusercontent.com/Uniswap/v4-core/main/README.md","domain":"raw.githubusercontent.com","title":"Uniswap v4 Core","hash":"226257af46a055f0cd5b5e73386e97a2d44e47ccc61e28198bbd1357efb9a4f0","tokens":1045,"chars":4180,"crawler":"crawler-74kg","verified":"exact","ts":1791170655271,"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://docs.layerzero.network/","domain":"docs.layerzero.network","title":"Introduction - LayerZero","hash":"cd26d77162aa1a67fd3125e3b4d8869a34eed2cf0617cf76b8f4213456bf4d0b","tokens":126,"chars":501,"crawler":"crawler-74kg","verified":"exact","ts":1791170657915,"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://raw.githubusercontent.com/bitcoin/bips/master/README.mediawiki","domain":"raw.githubusercontent.com","title":"","hash":"89d7d3ac8bf5500141f7d6bcaeb695843d5a98f8e544d622696756dc1cb8211e","tokens":8954,"chars":35816,"crawler":"crawler-74kg","verified":"exact","ts":1791170660276,"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://ethereum.org/developers/docs/scaling/","domain":"ethereum.org","title":"Scaling | ethereum.org","hash":"54b661b4755080f687b80b41cfb745ccba31352db14e70e14135037253bab1a1","tokens":2277,"chars":9106,"crawler":"crawler-74kg","verified":"exact","ts":1791170663153,"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://governance.aave.com/t/question-any-idea-what-happened-here/25730","domain":"governance.aave.com","title":"[Question] Any idea what happened here? - Finance - Aave","hash":"db00daff420b0eefce03a929218c830ce046bda7d7d8076522f71a7e28c89ca5","tokens":351,"chars":1401,"crawler":"crawler-74kg","verified":"exact","ts":1791170665906,"text":"Aave\n[Question] Any idea what happened here?\nFinance\n0xmonk\nSeptember 30, 2026, 5:18am\n1\n[Question] Any idea what happened here? Why the service provider expense rose sharply almost 3X from previous Quarters?\nimage 2532×1170 171 KB\n1 Like\nEzR3aL\nSeptember 30, 2026, 9:31am\n2\nI guess its all here Aave Analytics Dashboard | TokenLogic .\nimage 279×360 15.5 KB\nimage 344×259 15.5 KB\n0xmonk\nOctober 2, 2026, 12:37am\n3\nThanks @EzR3aL for sharing the link. Seems it’s desktop only link, I’ll take a look at it. From your screenshot, the majority of the expanse is towards AL, close to 5X of previous year. What I would like to understand, is that one time 10MM thing with regards to AWW? Or the recurring expenses when up multifold for some reason?\nEzR3aL\nOctober 2, 2026, 5:14am\n4\nIt’s much more than 10m.\nCheck the AWW proposal.\n1 Like\n0xmonk\nOctober 3, 2026, 1:45pm\n6\nYea, just read it again, the robbery that we couldn’t stop. Cheers\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nTokenLogic Delegate Platform\nDelegate Platforms\n38\n6665\nOctober 4, 2026\nAL Development Update | September 2026\nDevelopment\n0\n175\nOctober 1, 2026\n[TEMP CHECK] Aave Will Win Framework\nGeneral\n135\n17948\nSeptember 29, 2026\n[ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\nGovernance\n1\n264\nAugust 21, 2026\nLlamaRisk - Monthly Community Update\nGovernance\n27\n3337\nSeptember 4, 2026"}
{"url":"https://gov.uniswap.org/t/urc-2-custom-accounting-hook-swap-event/26154","domain":"gov.uniswap.org","title":"URC-2: Custom Accounting Hook Swap Event - URC Discussion - Uniswap Governance","hash":"7131d0e4223fc09ed9be406761fecf683c5b708dbe6b296d77f717de5deaf71c","tokens":3311,"chars":13242,"crawler":"crawler-f6nn","verified":"exact","ts":1791171621867,"text":"Uniswap Governance\nURC-2: Custom Accounting Hook Swap Event\nUniswap Request for Comment (URC)\nURC Discussion\nUniswapLabs\nJune 30, 2026, 4:32pm\n1\nurc\n2\ntitle\nCustom Accounting Hook Swap Event\nauthor\nEric Sanchirico ( @ericneil-sanc ), Mark Toda ( @MarkToda ), Daniel Gretzke ( @gretzke ), Alice Henshaw ( @hensha256 )\nstatus\nDiscussion\ncreated\n2026-06-11\nAbstract\nThis URC defines HookSwap , a canonical event through which Uniswap v4 hooks report the token deltas they contribute to a swap through custom accounting.\nMotivation\nUniswap v4 custom accounting allows hooks to replace, augment, or reduce the core AMM swap calculation. This enables hooks that wrap assets, route to external venues, deploy active liquidity, use vaults, rehypothecate reserves, settle through off-pool balances, or implement custom liquidity mechanisms.\nIndexers and data systems need a swap event that reflects the actual custom-accounting token deltas. The core v4 Swap event reports only the portion of a swap executed by the AMM, so swaps whose accounting is altered partly or fully through hook accounting are only partially captured. The core event also includes AMM-specific fields such as sqrtPriceX96 , liquidity , and tick , which may be unchanged, irrelevant, or misleading for hooks that bypass the AMM calculation.\nSpecification\nThe key words “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT”, “MAY”, and “OPTIONAL” are to be interpreted as normative requirements.\nScope\nThis URC applies to Uniswap v4 hooks that use custom accounting and want to expose a standardized swap event.\nA custom-accounting hook is a hook that computes swap accounting using hook-specific logic rather than relying solely on the core concentrated-liquidity AMM swap calculation.\nConformance is based on externally observable behavior: emitted events, return values, and documented semantics.\nHookSwap Event\nA custom-accounting hook that conforms to this URC MUST emit HookSwap for every successful swap in which it returns a token delta, whether by filling part or all of the swap or by taking a fee on top of an AMM-executed swap.\nevent HookSwap(\nPoolId indexed id,\naddress indexed sender,\nint128 amount0,\nint128 amount1,\nuint24 swapFee\n);\nFields\nField\nMeaning\nid\nThe PoolId of the pool being swapped.\nsender\nThe address passed into the hook’s swap callback. This is often a router, aggregator, executor, or other intermediate contract.\namount0\nSigned token0 delta of the hook’s fill.\namount1\nSigned token1 delta of the hook’s fill.\nswapFee\nPips-denominated fee rate applied by the hook, or 0 if no single meaningful pips-denominated fee applies.\nConsumers MUST NOT assume that sender is the ultimate end user.\nConsumers SHOULD treat amount0 and amount1 as the authoritative record of the hook’s fill. swapFee is metadata and may be 0 for hooks whose fee model is dynamic, externalized, or not expressible as a single pips value.\nDelta Sign Convention\namount0 and amount1 MUST be emitted in pool token order.\nThe sign convention matches the core v4 Swap event and the BalanceDelta convention, from the swapper’s perspective:\nSign\nMeaning\nPositive\nToken is leaving the pool or hook accounting system, paid to the swapper.\nNegative\nToken is entering the pool or hook accounting system, paid by the swapper.\nFor example, a token0-for-token1 swap SHOULD emit a negative amount0 and a positive amount1 .\nThe emitted deltas MUST reflect the final accounting effect of the hook’s fill after hook-applied fees, wrapping effects, or other custom-accounting adjustments that affect the returned swap deltas.\nImplementations MUST revert rather than silently truncate if an emitted amount cannot be safely represented as int128 .\nRelationship to the Core Swap Event\nHookSwap and the core v4 Swap event each report one portion of a swap. The core Swap event reports the deltas executed by the AMM. HookSwap reports the deltas filled by the hook.\nFor a swap filled entirely by the hook, HookSwap reports the full swap amounts and the core Swap event reports zero deltas.\nFor a swap filled partly by the hook and partly by the AMM, HookSwap reports the hook’s portion and the core Swap event reports the AMM’s portion.\nConsumers can compute the total amounts of a swap by adding the HookSwap and core Swap deltas. Each event covers its portion exactly once, so the sum is free of double counting.\nA hook that takes a fee in one of the swap tokens on top of an AMM-executed swap contributes a token delta even though it fills none of the swap, and MUST emit HookSwap for that delta. For a 100-unit exact-input token0 swap where the hook takes 1 token0 as a fee and the AMM fills the remainder, the core Swap event reports amount0 = -99 while HookSwap reports amount0 = -1 . The two sum to the -100 total paid by the swapper.\nBecause a hook sets its own fill through its return deltas, it can emit HookSwap from whichever callback finalizes its fill amounts. Emitting the event requires no additional hook permissions.\nOmitted AMM Fields\nHookSwap MUST NOT include:\nsqrtPriceX96\nliquidity\ntick\nThese fields describe the core concentrated-liquidity AMM state transition. Custom-accounting hooks may not use that state transition, may not update those fields, and may not have a meaningful internal equivalent.\nA hook MAY expose hook-specific price, inventory, reserve, routing, or strategy information through separate events or views.\nEmission Rules\nA conforming custom-accounting hook MUST emit exactly one HookSwap event for each successful externally requested swap in which it contributes a token delta, by filling part or all of the swap or by taking a fee.\nA hook MUST NOT emit HookSwap for:\n- Swaps in which the hook contributes no token delta.\n- Indicative quote calls.\n- Stats calls.\n- Simulation calls.\n- Reverted swaps.\nIf a hook internally splits its fill across venues, wrappers, vaults, or strategies, it SHOULD still emit one aggregate HookSwap event for its portion of the pool-level swap.\nA hook MAY emit additional hook-specific events for internal execution details.\nConformance\nA hook conforms to this URC if it:\n- Contributes token deltas to swaps through custom accounting.\n- Emits exactly one HookSwap event for each successful swap in which it contributes a token delta.\n- Emits the token0 and token1 deltas of its fill in pool token order.\n- Uses the sign convention defined in this URC.\n- Emits final fill deltas after custom-accounting adjustments and applicable fees.\n- Does not include sqrtPriceX96 , liquidity , or tick in the standard custom-accounting swap event.\nRationale\nInterface-Based Standard\nA shared base contract may be useful for implementation hygiene, but a URC should standardize behavior rather than inheritance structure. Hooks may have different audit constraints, upgrade patterns, gas optimizations, storage layouts, and execution models.\nConformance is therefore based on events and semantics.\nHookSwap Instead of Core Swap Fields\nThe core v4 Swap event is designed for swaps executed through the concentrated-liquidity AMM.\nCustom-accounting hooks may bypass that AMM calculation. For those hooks, sqrtPriceX96 , liquidity , and tick may be unchanged, irrelevant, or misleading.\nHookSwap preserves the most generally useful part of the swap event — token0 and token1 deltas — while avoiding AMM-specific fields that may not apply. The deltas use the same sign convention as the core Swap event so that consumers can interpret the two events uniformly and add them directly.\nHook Fill Deltas\nHookSwap reports the hook’s fill rather than the aggregate swap amounts. Each swap leg is reported by exactly one event — the AMM leg by the core Swap event and the hook leg by HookSwap — so consumers can add the two without double counting.\nPer-leg reporting also keeps emission cheap and permissions minimal. A hook knows its own fill in the callback where it sets its return deltas, so it can emit HookSwap there. Aggregate reporting was considered and rejected: a hook that fills only part of a swap learns the AMM portion of the final amounts only in afterSwap , so aggregate semantics would force such hooks to take on an additional callback and permission solely for event emission.\nBackwards Compatibility\nThis URC does not require changes to Uniswap v4 core.\nExisting hooks remain functional even if they do not emit HookSwap .\nHookSwap complements the core v4 Swap event. The core event continues to report AMM-executed deltas, and HookSwap reports hook-filled deltas.\nTest Cases\nFully Hook-Filled Token0-for-Token1 Swap\nGiven an exact-input swap filled entirely by the hook:\nzeroForOne = true;\namountSpecified < 0;\nhook fill token0 delta = -100;\nhook fill token1 delta = 99;\nswapFee = 0;\nThe hook should emit:\nHookSwap(id, sender, -100, 99, 0);\nThe core Swap event reports zero deltas for the AMM leg.\nFully Hook-Filled Token1-for-Token0 Swap\nGiven an exact-input swap filled entirely by the hook:\nzeroForOne = false;\namountSpecified < 0;\nhook fill token0 delta = 99;\nhook fill token1 delta = -100;\nswapFee = 0;\nThe hook should emit:\nHookSwap(id, sender, 99, -100, 0);\nPartially Hook-Filled Swap\nGiven an exact-input token0-for-token1 swap of 100 token0, where the hook fills half and the AMM fills the rest:\nzeroForOne = true;\namountSpecified = -100;\nhook fill: token0 delta = -50, token1 delta = 49;\nAMM fill: token0 delta = -50, token1 delta = 49;\nThe hook should emit:\nHookSwap(id, sender, -50, 49, 0);\nThe core Swap event reports the AMM fill of (-50, 49) . Adding the two events yields the swap totals of (-100, 98) .\nFee-Only Swap on Top of an AMM Fill\nGiven an exact-input token0-for-token1 swap of 100 token0, where the AMM fills the swap and the hook takes 1 token0 as a fee:\nzeroForOne = true;\namountSpecified = -100;\nhook fee: token0 delta = -1, token1 delta = 0;\nAMM fill: token0 delta = -99, token1 delta = 98;\nThe hook should emit:\nHookSwap(id, sender, -1, 0, swapFee);\nThe core Swap event reports the AMM fill of (-99, 98) . Adding the two events yields the swapper’s totals of (-100, 98) .\nReference Implementation\n// SPDX-License-Identifier: CC0-1.0\npragma solidity >=0.8.0;\nimport {PoolId} from \"@uniswap/v4-core/src/types/PoolId.sol\";\n/// @notice Standard event interface for custom-accounting hook swaps.\ninterface IHookSwapEvents {\n/// @notice Emitted on every successful swap in which the hook fills part or all of the swap.\n/// @param id The pool ID.\n/// @param sender The swap sender, often a router or executor.\n/// @param amount0 Signed token0 delta of the hook's fill. Negative = paid by the swapper.\n/// @param amount1 Signed token1 delta of the hook's fill. Negative = paid by the swapper.\n/// @param swapFee Pips-denominated fee rate, or 0 if not applicable.\nevent HookSwap(\nPoolId indexed id,\naddress indexed sender,\nint128 amount0,\nint128 amount1,\nuint24 swapFee\n);\n}\nSecurity Considerations\nHookSwap is emitted by the hook. Consumers should verify that the emitting hook is the hook associated with the pool being indexed.\nHookSwap values are self-reported by the hook. A hook can emit amount0 , amount1 , or swapFee that do not match the swap’s actual token flows, whether by error or design, and emission carries no protocol-level guarantee of accuracy. Consumers SHOULD treat HookSwap as hook-attested data rather than a verified settlement record, and reconcile against on-chain balance changes where correctness is critical.\nIndexers MUST NOT infer AMM price, liquidity, or tick movement from HookSwap .\nAdding HookSwap and core Swap deltas relies on hooks emitting exactly one event per swap covering only the hook’s fill. A hook that emits aggregate amounts or multiple events per swap would cause double counting in consumers that sum the two.\nThe sender field should not be treated as the ultimate user address.\nImplementations must avoid unsafe casts. If a final token delta cannot fit into int128 , the hook must revert rather than truncate.\nCopyright\nCopyright and related rights waived via CC0 .\n1 Like\nAnzus_GemWallet\nAugust 25, 2026, 4:59pm\n2\nFrom a wallet transaction-history perspective, how should consumers reliably associate a HookSwap event with its corresponding core Swap event when one transaction contains multiple pools, hooks, or split routes?\nAdding the deltas is straightforward in the single-pool examples, but an aggregator or multi-hop transaction may produce several events under the same transaction hash. A multi-route test case, or a recommended canonical grouping method, could help wallets and explorers avoid combining unrelated legs or double-counting amounts.\nIt may also be useful to define the expected display behavior when a hook does not implement this event, so users can distinguish incomplete swap details from an indexing failure.\nRelated topics\nTopic\nReplies\nViews\nActivity\nURC-4: Active Liquidity Framework Hook Interface\nURC Discussion\n2\n208\nJuly 20, 2026\nURC-3: Hook TVL and Effective Liquidity Reporting\nURC Discussion\n0\n134\nJune 30, 2026\n[RFC] Hook Manager Framework – On-Chain Policy Orchestration for Uniswap v4\nRequests for Comment\n6\n657\nMay 14, 2025\n[RFC] Native Execution Privacy in the Uniswap Interface via v4 Hooks and UniswapX\nRequests for Comment\n16\n704\nAugust 29, 2026\nUniswap Council (UC): Season 4 Report\nGovernance-Meta\n0\n343\nMarch 25, 2026"}
{"url":"https://docs.jup.ag/","domain":"docs.jup.ag","title":"Jupiter User Docs - Jupiter Documentation","hash":"4d27e93b703af6b2b85ac9e86969159be7b02ac1daad8132831ece8f9d10080f","tokens":651,"chars":2601,"crawler":"crawler-f6nn","verified":"exact","ts":1791171624953,"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://developers.skyeco.com/","domain":"developers.skyeco.com","title":"Sky Ecosystem | Sky Protocol Docs","hash":"1f47805127db5e7573a58a5e3b3a50690eb29f19919ec8c0e8b942f55f9afaac","tokens":107,"chars":426,"crawler":"crawler-f6nn","verified":"exact","ts":1791171627361,"text":"Skip to content\nSky Protocol Docs\nGitHub\nSelect theme\nSky Ecosystem\nImportant Links\nSection titled “Important Links”\n- GitHub: https://github.com/sky-ecosystem\n- Chainlog: https://chainlog.sky.money/\n- Portal: https://sky.money/\n- Voting: https://vote.sky.money/\n- Info Dashboard: https://info.sky.money\nReleased into the public domain (CC0 1.0 Universal) – trademarks remain with their owners; no warranty. See full license ."}
{"url":"https://bitcoinops.org/en/newsletters/","domain":"bitcoinops.org","title":"Newsletters | Bitcoin Optech","hash":"fe50ac400df5a2cdc0fa0d1aa83d5eba1177ca3665b034c9f7d34ca555319aee","tokens":9996,"chars":39983,"crawler":"crawler-f6nn","verified":"exact","ts":1791171630267,"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://docs.near.org/","domain":"docs.near.org","title":"Home - NEAR Docs","hash":"ff65ebe8f7aae0691398c8b861ea6bbc68fcb768996ce5d75b68b6d4ff5814c8","tokens":590,"chars":2357,"crawler":"crawler-f6nn","verified":"exact","ts":1791171633062,"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.ens.domains/","domain":"docs.ens.domains","title":"ENS Documentation","hash":"be85699d67344533603b9c87e029c7d934c9cdad065fac8c9db195504fad12a8","tokens":213,"chars":851,"crawler":"crawler-f6nn","verified":"exact","ts":1791171634969,"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://docs.ton.org/","domain":"docs.ton.org","title":"TON Docs — developer documentation","hash":"14612662575680cde9a5dbca9e8805a3324e8bc5566161c4fbcbaf7189a5f683","tokens":730,"chars":2920,"crawler":"crawler-f6nn","verified":"exact","ts":1791171637983,"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://docs.ton.org/contracts/standard/overview","domain":"docs.ton.org","title":"Standard contracts","hash":"d2078ff44e19b3cc68db5bd04dea1d9ba3900436391d58e831b0039fcd30a298","tokens":622,"chars":2488,"crawler":"crawler-f6nn","verified":"exact","ts":1791171640699,"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://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":"crawler-f6nn","verified":"exact","ts":1791171642905,"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://docs.base.org/get-started/base","domain":"docs.base.org","title":"Base - Base Documentation","hash":"f60b6c992deb6dce4cb6abe501c17d97b6f87183903cb8e88d8cb3bc96fd3b42","tokens":304,"chars":1216,"crawler":"crawler-f6nn","verified":"exact","ts":1791171645505,"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://docs.ton.org/api/rate-limit","domain":"docs.ton.org","title":"Rate limits","hash":"9f6404a726faa5318bfeb3727889912fe76739d435d056c81c2c01f6afaeb7f7","tokens":631,"chars":2523,"crawler":"crawler-f6nn","verified":"exact","ts":1791171648323,"text":"Onboarding Nodes Applications APIs Contracts Smart contracts Tolk Tolk language TVM TON Virtual Machine Foundations Blockchain foundations\nRate limits\nTo ensure stability and fair access, TON Center applies rate limits to all API requests.\nIf an application exceeds these limits, the API returns a 429 response.\nIncrease limits by requesting an API key and selecting a higher subscription plan. Without any API key, the default rate limit is 1 request per second.\nDefault limits\nPlan Tokens per network Requests per second Notes\nFree 1 10 Shared liteservers suitable for low-volume testing and small projects.\nPlus 3 25 Private liteservers that reduce contention compared to shared access.\nAdvanced 10 100 Private infrastructure with capacity for higher request rates.\nEnterprise Custom Custom Custom throughput and support. Contact @toncenter_support for details.\nRate limits apply to all API keys in total separately for every TON network, including mainnet and testnet. For example, the Plus plan users can create three API keys for the mainnet. The total limit for these three keys will be 25 requests per second.\nEach token represents an individual API key used to authenticate requests. Plans differ by how many tokens can be generated per network (mainnet and testnet). For example, the Free plan allows 1 key per network, while higher plans provide multiple keys for separate apps or environments.\nRate limit exceeded\nWhen requests are sent faster than the allowed rate limit, the TON Center API temporarily blocks new ones. A JSON response indicates the rate limit is exceeded:\n{\n\"ok\" : false ,\n\"result\" : \"Ratelimit exceed\" ,\n\"code\" : 429\n}\nWhen this occurs:\n- Stop sending new requests and wait a few seconds before retrying.\n- Implement exponential backoff to avoid repeated rate-limit violations.\nTroubleshooting\nIf a paid plan is active but the rate remains 1 RPS:\n-\nCheck that the API key is included correctly in the requests. Requests without a valid API key are limited to 1 RPS, even if a subscription is active.\n-\nVerify the correct key is used for the intended environment (mainnet or testnet). Each network requires its own key.\nWait up to 10 minutes after upgrading the plan or changing the API key.\nSubscription and key updates can take several minutes to propagate across TON Center’s rate-limiting system.\nJetton prices API\nDifferent ways to retrieve Jetton's historical prices on Decentralized Exchanges, DEXes\nGet API key\nNext Page\nOn this page\nDefault limits Rate limit exceeded Troubleshooting"}
{"url":"https://docs.jup.ag/llms.txt","domain":"docs.jup.ag","title":"Jupiter Documentation","hash":"8fa7fff900877ee419b4ef8afd4e60b9f1a70b6e51fe57ea8e4d0cc5f19caa91","tokens":8684,"chars":34736,"crawler":"crawler-f6nn","verified":"exact","ts":1791171650889,"text":"# Jupiter Documentation\n- [What is Jupiter Spot?](https://docs.jup.ag/user-docs/trade/spot/index.md): Jupiter Spot: instant token swaps on Solana with best-in-class execution, limit and DCA orders, token discovery, charts, and pro trading tools.\n- [Jupiter Spot Fees](https://docs.jup.ag/user-docs/trade/spot/fees.md): Fee structure for trading on Jupiter Spot — network fees, Jito tips, Jupiter commission, and gasless trading.\n- [Risks and Limitations](https://docs.jup.ag/user-docs/trade/spot/risks-and-limitations.md): Key risks and limitations to understand when trading on Jupiter Spot.\n- [Jupiter Spot FAQ](https://docs.jup.ag/user-docs/trade/spot/faq.md): Frequently asked questions about Jupiter Spot: trading and execution, token safety, charts, features and tools, and limitations.\n- [Ultra Mode](https://docs.jup.ag/user-docs/trade/spot/ultra-mode.md): Jupiter's default trading mode with optimized routing, MEV protection, and gasless support.\n- [Manual Mode](https://docs.jup.ag/user-docs/trade/spot/manual-mode.md): Full control over slippage, transaction fees, and routing on Jupiter.\n- [Jupiter Limit Orders](https://docs.jup.ag/user-docs/trade/spot/limit-orders.md): Set the exact price to buy or sell any Solana token with Jupiter Limit Orders: how they work, how they differ from a CLOB, and Limit Order V2 vs V1.\n- [DCA Orders](https://docs.jup.ag/user-docs/trade/spot/recurring-orders.md): Automatically spread your purchases over time using dollar-cost averaging.\n- [Pulse](https://docs.jup.ag/user-docs/trade/spot/pulse.md): Pulse is Jupiter Spot's at-a-glance market overview — a macro market summary, spotlight tokens, featured token lists, and category dominance.\n- [Discover](https://docs.jup.ag/user-docs/trade/spot/discover.md): How to discover and filter tokens on Jupiter Spot using tabs, screeners, filters, and Quick Buy.\n- [AlphaScan](https://docs.jup.ag/user-docs/trade/spot/alphascan.md): Real-time feed of new token launches on Solana — lifecycle tracking, developer data, and customization.\n- [SmartMoney](https://docs.jup.ag/user-docs/trade/spot/smart-money.md): See what notable and profitable wallets are trading on Jupiter Spot — leaderboards, a live trade feed, and followed wallets.\n- [Watchlist](https://docs.jup.ag/user-docs/trade/spot/watchlist.md): Monitor your favorite tokens with market data and curated news on Jupiter Spot.\n- [Launchpad Screener & Runners](https://docs.jup.ag/user-docs/trade/spot/launchpad-screener-and-runners.md): How the Launchpad Screener works on Jupiter Spot, including Runner criteria and launchpad listing.\n- [Positions](https://docs.jup.ag/user-docs/trade/spot/positions.md): Track your portfolio performance, PnL, and trading history on Jupiter Spot.\n- [Token Pages on Jupiter](https://docs.jup.ag/user-docs/trade/spot/token-page.md): Every tradeable Solana token has a Jupiter token page: live market data, charts, safety indicators, community metrics, and trading tools in one place.\n- [Tokenized Stocks](https://docs.jup.ag/user-docs/trade/spot/tokenized-stocks.md): Trading tokenized equities on Jupiter Spot — how they work, issuers, trading hours, and risks.\n- [Stock Pages on Jupiter](https://docs.jup.ag/user-docs/trade/spot/stock-page.md): Every stock available as a tokenized version on Jupiter has a stock page: underlying price and chart, stock stats, the issuers you can trade it from, and related prediction markets.\n- [Tokenized Stocks](https://docs.jup.ag/user-docs/trade/spot/tokenized-stocks.md): Trading tokenized equities on Jupiter Spot — how they work, issuers, trading hours, and risks.\n- [Stock Pages on Jupiter](https://docs.jup.ag/user-docs/trade/spot/stock-page.md): Every stock available as a tokenized version on Jupiter has a stock page: underlying price and chart, stock stats, the issuers you can trade it from, and related prediction markets.\n- [Jupiter Perps: Perpetual Futures on Solana](https://docs.jup.ag/user-docs/trade/perps/index.md): How Jupiter Perps works: leveraged longs and shorts on SOL, ETH, and wBTC against the JLP pool, plus GUM-powered Beta markets with USDC collateral.\n- [Beta Markets](https://docs.jup.ag/user-docs/trade/perps/beta-markets.md): Jupiter Perps Beta markets, powered by GUM: JUP, HYPE, ZEC and stock perps on USDC collateral, with hourly funding, taker and maker fees, one net position.\n- [Jupiter Perps FAQ](https://docs.jup.ag/user-docs/trade/perps/faq.md): Frequently asked questions about Jupiter Perps: positions, collateral, fees, liquidation, order behavior, and chart tools and settings.\n- [Positions & Collateral](https://docs.jup.ag/user-docs/trade/perps/positions-and-collateral.md): How to open, manage, and close leveraged positions on Jupiter Perps, including collateral rules, leverage, PnL, and order types.\n- [Jupiter Perps Fees](https://docs.jup.ag/user-docs/trade/perps/fees.md): All fees charged on Jupiter Perps: base fee, price impact fee (linear and additive), borrow fee, swap fee, JLP mint/burn fee, and transaction fees.\n- [Liquidation](https://docs.jup.ag/user-docs/trade/perps/liquidation.md): How liquidation works on Jupiter Perps: what triggers it, how the liquidation price is calculated, how it changes over time, and how to avoid it.\n- [Technical Reference](https://docs.jup.ag/user-docs/trade/perps/technical-reference.md): Technical details for developers: price oracle system, request fulfillment model, onchain accounts, and code references for Jupiter Perps.\n- [Prediction Markets](https://docs.jup.ag/user-docs/trade/predict/index.md): Trade on real-world events by buying YES or NO contracts on specific outcomes.\n- [How Predict Works](https://docs.jup.ag/user-docs/trade/predict/how-it-works.md): Detailed mechanics of Jupiter Prediction Markets: events, contracts, orders, fees, settlement, and the Degen mode.\n- [Using Predict](https://docs.jup.ag/user-docs/trade/predict/get-started.md): Step-by-step guide to browsing markets, opening positions, managing trades, and claiming payouts on Jupiter Predict.\n- [Predict FAQ](https://docs.jup.ag/user-docs/trade/predict/faq.md): Frequently asked questions about Jupiter Prediction Markets.\n- [Jupiter Gacha Overview](https://docs.jup.ag/user-docs/trade/gacha/index.md): Open Jupiter Gacha packs to pull real Pokemon, One Piece, Riftbound and sports cards, or luxury watches, vaulted by Collector Crypt and Phygitals.\n- [Providers](https://docs.jup.ag/user-docs/trade/gacha/providers.md): Jupiter Gacha packs come from two collectibles providers, Collector Crypt and Phygitals. Which packs belong to which provider, and how buyback windows, Turbo mode, gifting, shipping, and randomness differ between them.\n- [Opening Packs](https://docs.jup.ag/user-docs/trade/gacha/opening-packs.md): How to open Jupiter Gacha packs: pack tiers and prices by provider, drop odds, expected value, Turbo mode, the rip reveal, and how the card pool inside each machine works.\n- [Instant Buyback](https://docs.jup.ag/user-docs/trade/gacha/instant-buyback.md): Every Jupiter Gacha pull carries an instant buyback paid in USDC: a percentage of the card's value set per pack, available for 3 days on Collector Crypt packs and 7 days on Phygitals packs.\n- [Collection](https://docs.jup.ag/user-docs/trade/gacha/collection.md): Your Jupiter Gacha Collection: the items you own from both providers, your pull activity, and shipping status. Includes the card detail page and what insured value means.\n- [Marketplace](https://docs.jup.ag/user-docs/trade/gacha/marketplace.md): Buy and sell graded, tokenized cards with other collectors on the Jupiter Gacha marketplace: Buy now, listings, filters, and the 2% sell fee.\n- [Shipping](https://docs.jup.ag/user-docs/trade/gacha/shipping.md): Receive a Jupiter Gacha card at home: Collector Crypt cards ship from Jupiter Gacha with tracking, fees and customs rules, Phygitals cards through Phygitals.\n- [Rewards](https://docs.jup.ag/user-docs/trade/gacha/rewards.md): Free packs in Jupiter Gacha: battlepass progress rewards, weekly leaderboard prizes, and how to use free packs.\n- [Gifting Packs and Cards](https://docs.jup.ag/user-docs/trade/gacha/gifting.md): Gift Jupiter Gacha packs to another wallet, or send a card you own to a friend by transferring its token from your wallet: steps, what to check before sending, and what the recipient sees.\n- [Verifiable Randomness](https://docs.jup.ag/user-docs/trade/gacha/verifiable-randomness.md): How Jupiter Gacha pack draws are made provably fair: Collector Crypt's on-chain verifiable randomness (VRF) on Solana, and Phygitals' commit-reveal scheme.\n- [FAQ and Troubleshooting](https://docs.jup.ag/user-docs/trade/gacha/faq.md): Common questions and issues in Jupiter Gacha: pack opening errors, the two providers, insured value vs market price, buyback windows, Turbo mode, card custody, authenticity, sending a card to a friend, and shipping.\n- [Jupiter Lend Overview](https://docs.jup.ag/user-docs/earn/lend/index.md): Jupiter Lend is a lending and borrowing protocol on Solana: supply assets to earn yield, borrow against collateral, or take leveraged positions.\n- [Jupiter Lend Markets](https://docs.jup.ag/user-docs/earn/lend/markets.md): Jupiter Lend operates as a multi-market protocol. Each market is fully isolated, with its own assets, risk parameters, and curator.\n- [Supported Assets](https://docs.jup.ag/user-docs/earn/lend/supported-assets.md): Every asset you can supply, borrow, or use as collateral on Jupiter Lend, with the vault types, debt assets, and pricing method for each one.\n- [Jupiter Lend FAQ](https://docs.jup.ag/user-docs/earn/lend/faq.md): Frequently asked questions about Jupiter Lend: Earn, Borrow, Smart Vaults, Multiply, Strategies, and the Bitwise x Ethena Market\n- [Earn on Jupiter Lend](https://docs.jup.ag/user-docs/earn/lend/earn.md): Earn is the lending side of Jupiter Lend: supply assets to lending pools and earn interest from borrowers, with fees and risks explained.\n- [Borrow on Jupiter Lend](https://docs.jup.ag/user-docs/earn/lend/borrow/introduction.md): Borrow on Jupiter Lend lets you deposit collateral and borrow stablecoins without selling your assets, with specialized vault types and low fees.\n- [Native Staked Vaults](https://docs.jup.ag/user-docs/earn/lend/borrow/native-staked-vaults.md): Use your natively staked SOL as collateral on Jupiter Lend to borrow SOL without unstaking or interrupting staking rewards.\n- [JUICED on Jupiter Lend](https://docs.jup.ag/user-docs/earn/lend/borrow/juiced.md): Earn yield on JupUSD through Jupiter Lend. Use JUICED as collateral to borrow stablecoins.\n- [xStocks](https://docs.jup.ag/user-docs/earn/lend/borrow/xstocks.md): Use tokenized U.S. equities and ETFs as collateral on Jupiter Lend to borrow stablecoins or open leveraged positions.\n- [Smart Vaults](https://docs.jup.ag/user-docs/earn/lend/smart-vaults.md): Earn, borrow, and multiply on your assets, all in one place. Smart Vaults let your collateral and debt double as DEX liquidity to earn trading fees.\n- [Multiply on Jupiter Lend](https://docs.jup.ag/user-docs/earn/lend/multiply.md): Multiply on Jupiter Lend amplifies your exposure to an asset with automated on-chain leverage, looping in a single atomic transaction.\n- [Strategies](https://docs.jup.ag/user-docs/earn/lend/strategies.md): One-click max-leverage positions on pegged vaults within Jupiter Lend\n- [Using Earn](https://docs.jup.ag/user-docs/earn/lend/guides/using-earn.md): Navigate the Earn page, supply assets, withdraw, and review your transaction history on Jupiter Lend.\n- [Using Borrow](https://docs.jup.ag/user-docs/earn/lend/guides/using-borrow.md): Navigate the Borrow page, create and manage positions, and review your transaction history on Jupiter Lend.\n- [Using Smart Vaults](https://docs.jup.ag/user-docs/earn/lend/guides/using-smart-vaults.md): Navigate the Dual Stream Liquidity page, open smart vault and Smart Multiply positions, deposit into Smart Earn, and manage paired-token positions on Jupiter Lend.\n- [Using Multiply](https://docs.jup.ag/user-docs/earn/lend/guides/using-multiply.md): Navigate the Multiply page, create and manage leveraged positions, and review your transaction history on Jupiter Lend.\n- [Using Strategies](https://docs.jup.ag/user-docs/earn/lend/guides/using-strategies.md): Enter pre-built, max-leverage positions on pegged vaults in a single click on Jupiter Lend.\n- [Refinance](https://docs.jup.ag/user-docs/earn/lend/refinance.md): Migrate your existing positions from other protocols into Jupiter Lend in one transaction with Refinance, without closing and reopening manually.\n- [Protocol Details](https://docs.jup.ag/user-docs/earn/lend/protocol-details.md): Key terms and metrics across Jupiter Lend: vaults, position NFTs, withdrawal and borrow limits, and protocol parameters.\n- [Jupiter Lend Statistics](https://docs.jup.ag/user-docs/earn/lend/statistics.md): A complete overview of activity across Jupiter Lend — real-time insights into asset flows, liquidity, vault positions, DEX pools, and protocol health.\n- [Liquidation Calculator](https://docs.jup.ag/user-docs/earn/lend/calculator.md): Simulate liquidation risk on pegged vaults within Jupiter Lend\n- [Liquidity Layer & Risk Management](https://docs.jup.ag/user-docs/earn/lend/liquidity-layer-and-risk-management.md): How the Liquidity Layer connects Earn, Borrow, and Multiply into one shared liquidity pool, and the risk controls protecting Jupiter Lend.\n- [Liquidation Mechanism](https://docs.jup.ag/user-docs/earn/lend/liquidation-mechanism.md): How Jupiter Lend liquidates risky positions: tick-based partial liquidations, penalties, the debt-to-collateral ratio, and the Liquidation Max Limit.\n- [Oracles & Contract-Priced](https://docs.jup.ag/user-docs/earn/lend/oracles-and-contract-priced.md): How Jupiter Lend prices assets: a hop-based oracle system combining multiple trusted providers and on-chain sources, plus contract-priced assets.\n- [Migrating from the Bitwise x Ethena Market to the Sentora Market](https://docs.jup.ag/user-docs/earn/lend/sentora-migration.md): How to move a USDe loop from the Bitwise x Ethena Market to the new Sentora Market on Jupiter Lend, or exit gradually, with minimal slippage.\n- [Offerbook Overview](https://docs.jup.ag/user-docs/earn/offerbook/index.md): Borrow or lend USDC peer-to-peer at fixed rates, with no price-based liquidations on Offerbook\n- [Borrowing](https://docs.jup.ag/user-docs/earn/offerbook/borrowing.md): Borrow USDC against your assets on Offerbook, from asking for a loan to repayment\n- [Lending](https://docs.jup.ag/user-docs/earn/offerbook/lending.md): Lend USDC at fixed rates on Offerbook, from posting an offer to claiming collateral\n- [Offerbook Markets](https://docs.jup.ag/user-docs/earn/offerbook/markets.md): The Tokens and Collectibles markets on Offerbook: eligible collateral and how to read each view\n- [Pro](https://docs.jup.ag/user-docs/earn/offerbook/pro.md): The all-in-one Offerbook order book: both sides of the market and both intent books on a single screen\n- [Counter Offers](https://docs.jup.ag/user-docs/earn/offerbook/counter-offers.md): Negotiate the terms of an open offer on Offerbook instead of accepting it as-is\n- [Loan Extensions on Offerbook](https://docs.jup.ag/user-docs/earn/offerbook/extensions.md): Roll an active Offerbook loan into a fresh period on the same terms, instead of repaying it\n- [Multiply on Offerbook](https://docs.jup.ag/user-docs/earn/offerbook/multiply.md): Loop stable yield-bearing assets or lever any collateral through Offerbook loans, with fixed terms and no liquidations\n- [Intents](https://docs.jup.ag/user-docs/earn/offerbook/intents.md): Advertise the lending or borrowing terms you want on Offerbook, with no funds locked and no fees\n- [Chat](https://docs.jup.ag/user-docs/earn/offerbook/chat.md): Send direct messages and join public channels on Offerbook\n- [Affiliate & Referrals](https://docs.jup.ag/user-docs/earn/offerbook/affiliate-and-referrals.md): How the Offerbook referral program works, vanity slugs, share URLs, and claiming rewards\n- [Settings & Notifications](https://docs.jup.ag/user-docs/earn/offerbook/settings-and-notifications.md): Configure notification channels, hardware wallet authentication, privacy mode, escrow auto top-up, and notification types on Offerbook\n- [Offerbook Statistics](https://docs.jup.ag/user-docs/earn/offerbook/statistics.md): Understand the metrics displayed on the Offerbook Statistics page\n- [Fees & Costs](https://docs.jup.ag/user-docs/earn/offerbook/fees-and-costs.md): Fee structure, referral program, and how costs are distributed on Offerbook\n- [Security & Risks](https://docs.jup.ag/user-docs/earn/offerbook/security-and-risks.md): Risk model, what Offerbook removes and what remains, and audit information\n- [Offerbook FAQ](https://docs.jup.ag/user-docs/earn/offerbook/faq.md): Frequently asked questions about Offerbook: assets, offers, intents, loans, fees, and risks.\n- [JLP — Jupiter Liquidity Provider Token](https://docs.jup.ag/user-docs/earn/jlp/index.md): What the JLP token is and how the JLP pool earns from Jupiter Perps trading activity — asset index, yield sources, and risks.\n- [JLP FAQ](https://docs.jup.ag/user-docs/earn/jlp/faq.md): Frequently asked questions about JLP, JLP Loans, and JLP Delta Neutral.\n- [Earn with JLP](https://docs.jup.ag/user-docs/earn/jlp/earn.md): How JLP generates yield, how the pool's value is calculated, and what risks JLP holders are exposed to.\n- [Loans](https://docs.jup.ag/user-docs/earn/jlp/loans.md): Borrow USDC using JLP as collateral while maintaining JLP yield exposure.\n- [Delta Neutral](https://docs.jup.ag/user-docs/earn/jlp/delta-neutral.md): A managed vault strategy that hedges JLP's directional market exposure to generate stablecoin-denominated yield, powered by Neutral Trade.\n- [Stake SOL Overview](https://docs.jup.ag/user-docs/earn/stake-sol/index.md): Stake SOL with Jupiter's Solana validator. Choose between native staking and JupSOL liquid staking.\n- [Native Staking](https://docs.jup.ag/user-docs/earn/stake-sol/native-staking.md): Stake SOL directly with the Jupiter validator. Earn inflation and MEV rewards. Use your staked SOL as collateral on Jupiter Lend.\n- [JupSOL](https://docs.jup.ag/user-docs/earn/stake-sol/jupsol.md): Liquid staking with the Jupiter validator. Earn staking rewards, MEV, and priority fees while keeping your SOL liquid.\n- [Stake SOL FAQ](https://docs.jup.ag/user-docs/earn/stake-sol/faq.md): Frequently asked questions about staking SOL with Jupiter Stake, native staking, and JupSOL.\n- [JupUSD](https://docs.jup.ag/user-docs/earn/jupusd/index.md): A Solana-native, reserve-backed stablecoin pegged to the U.S. dollar.\n- [JUICED](https://docs.jup.ag/user-docs/earn/jupusd/juiced.md): A yield-bearing token backed by JupUSD. Earns T-bill yield and borrowing interest from Jupiter Lend.\n- [JupUSD FAQ](https://docs.jup.ag/user-docs/earn/jupusd/faq.md): Frequently asked questions about JupUSD and JUICED.\n- [Jupiter Rewards Hub Overview](https://docs.jup.ag/user-docs/earn/rewards-hub/index.md): Overview of the Jupiter Rewards Hub and its campaign system.\n- [Trading Card Game](https://docs.jup.ag/user-docs/earn/rewards-hub/trading-card-game.md): Core mechanics of the Jupiter Trading Card Game — points, cards, lootboxes, referrals, eligibility, and season details.\n- [Jupiter Rewards Hub FAQ](https://docs.jup.ag/user-docs/earn/rewards-hub/faq.md): Frequently asked questions about the Jupiter Rewards Hub and the Trading Card Game.\n- [Portfolio Overview](https://docs.jup.ag/user-docs/manage/portfolio/index.md): What Jupiter Portfolio is: a read-only Solana dashboard for any wallet, how it detects and prices positions, what it does not track, and the protocols covered.\n- [Portfolio Settings](https://docs.jup.ag/user-docs/manage/portfolio/settings.md): The four Portfolio settings on jup.ag: display currency (USD, EUR, GBP, JPY and more), hiding small positions, lending health display, and the Spot PnL period.\n- [Positions and Net Worth](https://docs.jup.ag/user-docs/manage/portfolio/positions.md): The Positions tab of Jupiter Portfolio: the Net worth card and its views, claimable rewards, positions grouped by platform, and the actions on each row.\n- [Spot PnL](https://docs.jup.ag/user-docs/manage/portfolio/spot-pnl.md): Spot trading performance in Jupiter Portfolio: Spot tab metrics, realized and unrealized PnL, top trades, the PnL Calendar with win streaks, Share PnL.\n- [Activity and Export](https://docs.jup.ag/user-docs/manage/portfolio/activity.md): The Activity tab of Jupiter Portfolio: the transaction history, the Hide failed and Hide spam filters, and how to export the full history as a CSV file.\n- [Reclaim SOL](https://docs.jup.ag/user-docs/manage/portfolio/reclaim-sol.md): Recover the SOL locked as rent in empty token accounts from Jupiter Portfolio: eligible accounts, the Reclaim SOL dialog, and what stays in your wallet.\n- [Wallets, Groups and Address Book](https://docs.jup.ag/user-docs/manage/portfolio/address-book.md): How to switch wallets in Jupiter Portfolio, bookmark addresses, create groups of up to 15 wallets to view them together, and manage them in the Address Book.\n- [Newsletter](https://docs.jup.ag/user-docs/manage/portfolio/newsletter.md): The Newsletter tab of Jupiter Portfolio subscribes you to the Portfolio Brief, a free weekly email sent every Monday on what changed across your positions.\n- [Airdrop Checker](https://docs.jup.ag/user-docs/manage/portfolio/airdrop-checker.md): Check your eligibility for Solana airdrops across all your wallets, directly from Jupiter Portfolio.\n- [Portfolio FAQ](https://docs.jup.ag/user-docs/manage/portfolio/faq.md): Troubleshooting Jupiter Portfolio: missing tokens, wrong values, missing positions, unsupported protocols, no net worth history, and Airdrop Checker questions.\n- [Connecting a Wallet or Jupiter ID on jup.ag](https://docs.jup.ag/user-docs/manage/connect-wallet/index.md): Connect on jup.ag with Jupiter Wallet, Jupiter Mobile, Phantom or another Solana wallet, WalletConnect QR, or a Jupiter ID (email, Google, Apple).\n- [What is Jupiter Wallet?](https://docs.jup.ag/user-docs/manage/extension-wallet/index.md): Jupiter Wallet is a self-custodial browser extension wallet for Solana, on Chromium browsers: Ultra swaps, Auto-Earn, Ticker Widget, multi-chain receive.\n- [Getting Started with Jupiter Wallet](https://docs.jup.ag/user-docs/manage/extension-wallet/getting-started.md): Install Jupiter Wallet, create or import a wallet (including from another Solana wallet), add a Ledger, Keystone or Trezor, and sync with Jupiter Mobile.\n- [Swap and Trade in Jupiter Wallet](https://docs.jup.ag/user-docs/manage/extension-wallet/swap-and-trade.md): Swap in Jupiter Wallet through Jupiter Ultra with MEV protection and gasless execution, place limit and recurring orders, and enable Auto-Approve.\n- [Sending and Receiving with Jupiter Wallet](https://docs.jup.ag/user-docs/manage/extension-wallet/sending-and-receiving.md): Send tokens from Jupiter Wallet to an address, domain or contact, and receive on Solana or from six other networks via Universal Deposit.\n- [Portfolio and Holdings in Jupiter Wallet](https://docs.jup.ag/user-docs/manage/extension-wallet/portfolio.md): Track holdings in Jupiter Wallet: token pages, realized and unrealized PnL, NFTs, DeFi positions across 160+ protocols, transaction history, and rent reclaim.\n- [Jupiter Wallet Ticker Widget](https://docs.jup.ag/user-docs/manage/extension-wallet/ticker-widget.md): Jupiter Wallet's Ticker Widget shows price, chart and a swap button for tickers spotted on X, Google, CoinMarketCap, Yahoo Finance, ChatGPT, Claude and Gemini.\n- [Jupiter Wallet Auto-Earn](https://docs.jup.ag/user-docs/manage/extension-wallet/auto-earn.md): Auto-Earn in Jupiter Wallet deposits the stablecoins you enable (USDC, USDT, JupUSD, EURC, USDG, USDS) into Jupiter Lend Earn automatically, checked hourly.\n- [Jupiter Wallet Security](https://docs.jup.ag/user-docs/manage/extension-wallet/security.md): Jupiter Wallet security: self-custody, password and locking, biometric unlock, key export, and Transaction Protection against malicious browser extensions.\n- [Jupiter Wallet Settings](https://docs.jup.ag/user-docs/manage/extension-wallet/settings.md): Jupiter Wallet settings: dApp connections, Connect as Phantom, Auto-Approve, side panel and display preferences, wallet management, and extension updates.\n- [Jupiter Wallet Fees](https://docs.jup.ag/user-docs/manage/extension-wallet/fees.md): Jupiter Wallet fees: free sends, Jupiter Ultra swap fees from 0% to 0.5%, how gasless swaps recover gas costs, limit and recurring orders, and Auto-Earn.\n- [Jupiter Wallet FAQ](https://docs.jup.ag/user-docs/manage/extension-wallet/faq.md): Jupiter Wallet FAQ: browsers, self-custody, fees, moving from another wallet, Jupiter Mobile sync, MEV protection, Auto-Earn, Ticker Widget, troubleshooting.\n- [Jupiter Studio Overview](https://docs.jup.ag/user-docs/launch/studio/index.md): What Jupiter Studio is, who it's for, and how it works.\n- [Launching a Token](https://docs.jup.ag/user-docs/launch/studio/launching-a-token.md): How to launch a token on Jupiter Studio: modes, configuration, and anti-sniper protection.\n- [Graduation and Fees](https://docs.jup.ag/user-docs/launch/studio/graduation-and-fees.md): What happens when a Studio token graduates, how fees work, and post-graduation mechanics.\n- [Jupiter Studio FAQ](https://docs.jup.ag/user-docs/launch/studio/faq.md): Frequently asked questions about launching and trading tokens on Jupiter Studio.\n- [VRFD Overview](https://docs.jup.ag/user-docs/launch/vrfd/index.md): What Jupiter VRFD is, what it covers, and how it helps maintain token quality across the Solana ecosystem.\n- [Token Verification](https://docs.jup.ag/user-docs/launch/vrfd/token-verification.md): How to get your token verified on Jupiter, review methods, criteria, and what Verified status means.\n- [Token Metadata Updates](https://docs.jup.ag/user-docs/launch/vrfd/token-metadata-updates.md): How to update your token's metadata across Jupiter products.\n- [VRFD FAQ](https://docs.jup.ag/user-docs/launch/vrfd/faq.md): Frequently asked questions about Jupiter VRFD: token verification and metadata updates.\n- [Jupiter DTF](https://docs.jup.ag/user-docs/launch/dtf/overview.md): A curated, on-chain token launch platform operated by Jupiter.\n- [How a DTF launch works](https://docs.jup.ag/user-docs/launch/dtf/how-it-works.md): Detailed breakdown of the DTF launch process: curation, phases, token claiming, allocation locking, and liquidity provisioning.\n- [Jupiter Lock Overview](https://docs.jup.ag/user-docs/launch/lock/index.md): A free token locking and vesting tool on Solana.\n- [How Jupiter Lock Works](https://docs.jup.ag/user-docs/launch/lock/how-it-works.md): Vesting model, lock parameters, permissions, claiming, and onchain mechanics.\n- [Jupiter Lock FAQ](https://docs.jup.ag/user-docs/launch/lock/faq.md): Frequently asked questions about Jupiter Lock: creating locks, vesting schedules, claiming tokens, and security.\n- [Jupiter Send Overview](https://docs.jup.ag/user-docs/onramp/send/index.md): Send tokens to any Solana wallet or via Magic Link, even to users without a wallet.\n- [Magic Links](https://docs.jup.ag/user-docs/onramp/send/magic-links.md): Send tokens via a shareable link or QR code. Recipients can claim tokens even without an existing wallet.\n- [Jupiter Send FAQ](https://docs.jup.ag/user-docs/onramp/send/faq.md): Frequently asked questions about Jupiter Send, Magic Links, Gasless Send, and token transfers.\n- [Deposit Overview](https://docs.jup.ag/user-docs/onramp/deposit/index.md): Get your funds onto Solana through Jupiter Deposit: deposit crypto from supported networks, bridge and swap, buy with a card, or send from an exchange.\n- [Universal Deposit](https://docs.jup.ag/user-docs/onramp/deposit/universal-deposit.md): Deposit crypto to your Solana wallet from Ethereum, Base, Arbitrum, Sui, BNB Chain or Robinhood Chain; cross-chain deposits arrive as USDC.\n- [Bridge & Swap](https://docs.jup.ag/user-docs/onramp/deposit/bridges.md): Bridge & swap moves tokens to Solana from 11 networks, comparing GUM Universal Bridge, GUM Universal Deposit and deBridge routes ranked by delivered amount.\n- [Buy with a card](https://docs.jup.ag/user-docs/onramp/deposit/buy-crypto.md): Buy SOL or USDC with a card, Apple Pay, Google Pay, bank transfer, or other local payment methods and receive them in your Solana wallet. Powered by Onramper.\n- [Send from an exchange](https://docs.jup.ag/user-docs/onramp/deposit/send-from-exchange.md): Send crypto from Binance, Coinbase or Uphold to your Solana wallet through Mesh (Secure deposit), or send it yourself to your address (Standard deposit).\n- [Deposit FAQ](https://docs.jup.ag/user-docs/onramp/deposit/faq.md): Frequently asked questions about Jupiter Deposit: Universal Deposit, Bridge & Swap, Buy with a card, and Send from an exchange.\n- [Jupiter Mobile Overview](https://docs.jup.ag/user-docs/global/mobile/index.md): What Jupiter Mobile is, where it runs, and what it supports.\n- [Managing Wallets](https://docs.jup.ag/user-docs/global/mobile/managing-wallets.md): Creating, importing, securing, and managing wallets in Jupiter Mobile.\n- [Funding & Sending](https://docs.jup.ag/user-docs/global/mobile/funding-and-sending.md): How to receive, deposit, send tokens, and use Magic Links in Jupiter Mobile.\n- [Swaps & Orders](https://docs.jup.ag/user-docs/global/mobile/swaps-and-orders.md): Trading in Jupiter Mobile: Market swaps, Limit orders, Recurring orders, perps, and predictions in the Trade tab.\n- [Portfolio](https://docs.jup.ag/user-docs/global/mobile/portfolio.md): Balances, the Home and Portfolio tabs, PnL, token visibility, and NFTs in Jupiter Mobile.\n- [Markets](https://docs.jup.ag/user-docs/global/mobile/discovery.md): The Markets tab in Jupiter Mobile: tokens, tokenized stocks, commodities, watchlist, and token pages.\n- [App Features](https://docs.jup.ag/user-docs/global/mobile/app-features.md): Search, scanning, dApp browser, notifications, widgets, and earning in Jupiter Mobile.\n- [Jupiter Mobile Fees](https://docs.jup.ag/user-docs/global/mobile/fees.md): All fees that apply when using Jupiter Mobile, with links to each product's detailed fee documentation.\n- [Jupiter Mobile FAQ](https://docs.jup.ag/user-docs/global/mobile/faq.md): Jupiter Mobile FAQ: wallets and recovery, funding, swaps and orders, portfolio, fees, and troubleshooting.\n- [Jupiter Spend Overview](https://docs.jup.ag/user-docs/global/spend/index.md): Overview of Jupiter Spend, its products, identity verification, and how to get started.\n- [Risks & Security](https://docs.jup.ag/user-docs/global/spend/risks-and-security.md): Risks that apply across all Jupiter Spend products.\n- [Jupiter Card](https://docs.jup.ag/user-docs/global/spend/jupiter-card.md): Jupiter Card: a Visa debit card to spend USDC as USD, virtual today with physical cards rolling out; fees, refunds, the Claynosaurz card, mobile wallets, countries.\n- [Jupiter QR Pay](https://docs.jup.ag/user-docs/global/spend/qr-pay.md): How Jupiter QR Pay works, where it's available, and its limitations.\n- [Global Fiat Remittance](https://docs.jup.ag/user-docs/global/spend/remittance.md): Virtual accounts, SWIFT transfers, local payouts, and how Global Fiat Remittance works.\n- [Rewards & Referrals](https://docs.jup.ag/user-docs/global/spend/rewards-and-referrals.md): Cashback rewards on every purchase, and referral bonuses for inviting friends to Jupiter Spend.\n- [Campaigns](https://docs.jup.ag/user-docs/global/spend/campaigns.md): Limited-time promotional campaigns and special offers for Jupiter Spend users.\n- [Fees & Limits](https://docs.jup.ag/user-docs/global/spend/fees-and-limits.md): Fee structure, spending limits, and supported countries across all Jupiter Spend products.\n- [Jupiter Spend FAQ](https://docs.jup.ag/user-docs/global/spend/faq.md): Frequently asked questions about Jupiter Spend: Jupiter ID, deposits and withdrawals, cards, QR Pay, bank transfers, cashback, and referrals.\n- [Poker Basics](https://docs.jup.ag/user-docs/more/jupiter-poker.md): Core poker and action-selling concepts you need to understand before using Jupiter Poker.\n- [Jupiter DAO Overview](https://docs.jup.ag/user-docs/more/dao/index.md): Overview of the Jupiter DAO, the J.U.P. vision, community initiatives, and the Catdet community.\n- [Staking](https://docs.jup.ag/user-docs/more/dao/staking.md): How to stake and unstake JUP, the unstaking period, and staking benefits.\n- [Voting](https://docs.jup.ag/user-docs/more/dao/voting.md): How to vote on Jupiter DAO proposals, track votes, and understand voting mechanics.\n- [Active Staking Rewards (ASR)](https://docs.jup.ag/user-docs/more/dao/asr.md): What ASR is, how it's distributed, and how to claim your rewards.\n- [Jupiter DAO FAQ](https://docs.jup.ag/user-docs/more/dao/faq.md): Frequently asked questions about the Jupiter DAO, staking, voting, and ASR.\n- [JUP Token Overview](https://docs.jup.ag/user-docs/more/jup-token/index.md): Contract address, affiliated tokens, and where to trade JUP.\n- [JUP Tokenomics](https://docs.jup.ag/user-docs/more/jup-token/tokenomics.md): JUP token allocation, team vesting on Jupiter Lock, the community-approved supply reduction, and where to track unlocks and circulating supply.\n- [Transparency](https://docs.jup.ag/user-docs/more/jup-token/transparency.md): Jupiter revenue model, value accrual, market maker arrangements, and key resources.\n- [JUP Token FAQ](https://docs.jup.ag/user-docs/more/jup-token/faq.md): Frequently asked questions about the JUP token, including the contract address and where to get JUP.\n- [Security](https://docs.jup.ag/user-docs/more/security/index.md): Independent security audits for Jupiter's onchain programs, with direct links to each audit report.\n- [Brand Kit](https://docs.jup.ag/user-docs/more/brand-kit.md): Logos, labelling guidelines, and brand assets for Jupiter integrations.\n- [Terms of Use](https://docs.jup.ag/user-docs/legal/terms-of-use.md): Terms of Use governing access to and use of the Jupiter interface at jup.ag.\n- [Privacy Policy](https://docs.jup.ag/user-docs/legal/privacy-policy.md): How Jupiter collects, uses, and protects personal data across the Jupiter interface and its dApps.\n- [Jupiter User Docs](https://docs.jup.ag/index.md): Official documentation for every Jupiter product — swap, perps, mobile app, Jupiter Card, lending, staking, and more. Guides, fees, and FAQs.\n## Optional\n- [Developer Platform](https://developers.jup.ag/)\n- [Support Hub](https://support.jup.ag)\nThis documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform."}
{"url":"https://solana.com/docs/core/pda","domain":"solana.com","title":"","hash":"0ce758dd495a0d74722bed55d942cbf28c1788f58af8a82cdedf2328589f425e","tokens":788,"chars":3152,"crawler":"crawler-f6nn","verified":"exact","ts":1791171653120,"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\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://www.metaplex.com/docs/guides","domain":"www.metaplex.com","title":"The leading tokenization platform on Solana. | Metaplex","hash":"ed1b4fae9637404e4a1977aef57e41b14e09ad39b72095c3cb475741fd6d2e58","tokens":504,"chars":2015,"crawler":"crawler-f6nn","verified":"exact","ts":1791171656137,"text":"Metaplex\n- Home\n- Pulse\n- Trending\n- Watchlist\n- Agents Beta\n- Developers\n- Support\n- Twitter\n- Discord\nFor Founders For Founders\nThe leading tokenization platform on Solana.\nLaunch and trade onchain assets.\nLaunch a Token Issue an RWA\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\nWhy Metaplex\nM e t a p l e x i s w h e r e a s s e t s o n S o l a n a m o v e f r o m l a u n c h t o a c t i v e m a r k e t s , w i t h i s s u a n c e a n d l i v e t r a d i n g a l l i n o n e p l a t f o r m .\nTwo sides, one market.\nFor issuers\n-\n1\nRun your token sale with configurable tools for a controlled, fair launch.\nLearn more\n-\n2\nCreate all asset types on Solana including tokens and NFTs with Metaplex protocols.\nLearn more\n-\n3\nIssue tokenized securities or RWAs using Metaplex protocols\nLearn more\nFor Investors & Traders\n-\nDiscover live token sales and trade different asset types with Metaplex.\nStart trading\nInfrastructure the ecosystem already runs on.\nAccess the largest network in the ecosystem, with provenance and settlement the ecosystem already trusts.\nProven scale\n- 1B+ Transactions powered Solana\n- $13B+ Transaction volume Markets\n- 1B+ Digital assets created Issuance\nDEX partner\nToken sale liquidity auto-migrates from Metaplex to Raydium CPMM pools for liquidity depth and healthy trading. Spotlight customers are eligible to use CLMM pools and configure more advanced liquidity strategies.\nRaydium - DEX partner\n1B+\nTransactions powered\nElite Partners"}
{"url":"https://docs.jup.ag/user-docs/trade/spot/positions","domain":"docs.jup.ag","title":"Positions - Jupiter Documentation","hash":"351419bd79ee6d3e7b3949eef3d315709e59d1fdc17d1a4021e30ae82eca1398","tokens":975,"chars":3900,"crawler":"crawler-f6nn","verified":"exact","ts":1791171660626,"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\nFeatures & Tools\nPositions\nTrack your portfolio performance, PnL, and trading history on Jupiter Spot.\nThe Positions view gives you a complete overview of your Spot trading performance across all tokens. It now lives in Jupiter Portfolio , under the Spot tab: open Portfolio , select your wallet, then Spot . The former Positions tab in the Spot interface and the old jup.ag/watch/positions address both point there now.\nAt the top, the page displays your connected wallet’s address, SOL and USDC balances, and total number of tokens held. You can filter all data by time period: 1d , 7d , 30d , or All .\nDashboard\nSummary\n- Holdings — Total current USD value of all tokens you hold\n- — Profit or loss on tokens you still hold\n- — Percentage of trades that were profitable\n- — Profit or loss from tokens already sold\n- Total PnL — Combined unrealised and realised profit or loss\nA Share button lets you export your summary as a shareable image.\nRealised PnL\nA line chart showing the trend of your realised PnL over the selected time period.\nPnL Calendar\nThe PnL Calendar is a monthly calendar view of your daily trading performance, displaying up to 2 months. It shows your profit or loss for each day (green for profit, red for loss), total monthly PnL with a visual win/loss bar, and your longest and current win streaks. The PnL Calendar is accessible from two places:\n- The Portfolio Spot tab (via the PnL Calendar button in the Realised PnL panel)\n- The trader modal on any token page (click on a trader’s address in the tabs below the chart). The modal opens on a compact PnL overview: PnL, holdings, win rate, volume, and top trades.\nYou can navigate between months and toggle between USD and SOL denomination. Daily and monthly PnL cards can be exported as shareable images via the Share button.\nDistribution\nVisual breakdown of your positions by PnL performance: > 500%, 200%–500%, 50%–200%, 0%–50%, and < -50%. Each range shows the count and rate (percentage of your total positions). A color-coded bar shows the overall distribution at a glance.\nCompare your Win Rate with the Distribution panel to understand your trading patterns. A high win rate with most positions in the 0%–50% range and a few large losses in the < -50% range tells a different story than a low win rate with concentrated gains above 200%.\nPositions table\nBelow the dashboard, a detailed table lists your individual token positions. The table has four sub-tabs:\nSub-tab What it shows\nRecent Tokens you traded most recently, sorted by last trade date\nHoldings Tokens you currently hold (non-zero balance)\nProfitable Tokens sorted by highest total PnL\nActivity Full transaction history\nEach row in the table displays:\nField Description\nLast Traded Token name and time since your last trade\nUnrealised Unrealised PnL in USD and percentage\nRealised Realised PnL in USD and percentage, or “Holding” / “Sold all” status\nTotal PnL Combined PnL in USD and percentage\nHolding Current token balance and its USD value\nBought / Avg Total amount spent and average buy price\nSold / Avg Total amount received and average sell price\nPosition % Percentage of your original position still held\nYou can toggle between Price and USD denomination using the controls in the top-right of the table.\nThe Positions view reflects onchain data for the selected wallet. Data updates periodically — the last update time is displayed at the top of the page.\nYou can also view your position for a specific token directly from its token page , under the My Positions tab.\nToken Page\nView position details for a specific token.\nWatchlist\nSave tokens and track them with curated news.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.curve.finance/","domain":"docs.curve.finance","title":"Curve Knowledge Hub","hash":"7a573b34a503a60f387bf300d2520913de7e5e331fa4a62fa416e496c836a02f","tokens":136,"chars":543,"crawler":"crawler-f6nn","verified":"exact","ts":1791171662756,"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://developers.skyeco.com/protocol/tokens/dai/","domain":"developers.skyeco.com","title":"Dai | Sky Protocol Docs","hash":"7da8d9302572e8e7f73357a7195d2baf7e6b7f02e4ec7f16e1f687681f2ac787","tokens":1398,"chars":5589,"crawler":"crawler-f6nn","verified":"exact","ts":1791171665266,"text":"Skip to content\nSky Protocol Docs\nGitHub\nSelect theme\nDai\nThe origin of DAI was designed to represent any token that the core system considers equal in value to its internal debt unit. Thus, the DAI Module contains the DAI token contract and all of the adapters DaiJoin adapters.\nThe Dai contract is the user-facing ERC20 token contract maintaining the accounting for external Dai balances. Most functions are standard for a token with changing supply, but it also notably features the ability to issue approvals for transfers based on signed messages.\nKey Mechanism and Concepts\nSection titled “Key Mechanism and Concepts”\nWhy are these components important to the Multi-Collateral Dai (MCD) System?\nSection titled “Why are these components important to the Multi-Collateral Dai (MCD) System?”\nThe Dai contract is the user facing ERC20 contract maintaining the accounting for external Dai balances. Most functions are standard for a token with changing supply, but it also notably features the ability to issue approvals for transfers based on signed messages.\nJoin consists of three smart contracts, one of which is the DaiJoin contract. Each join contract is created specifically to allow the given token type to be joined to the vat. Because of this, each join contract has slightly different logic to account for the different types of tokens within the system. The DaiJoin contract allows users to withdraw their Dai from the system into a standard ERC20 token.\nDifferences From ERC20:\nSection titled “Differences From ERC20:”\n- transferFrom in the DAI contract works in a slightly different form than the generic transferFrom function. The DAI contract allows for “unlimited approval”. Should the user approve an address for the maximum uint256 value, then that address will have unlimited approval until told otherwise.\n- push , pull & move are aliases for transferFrom calls in the form of transferFrom(msg.sender, usr, amount) , transferFrom(usr, msg.sender, amount) & transferFrom(src, dst, amount) .\n- permit is a signature-based approval function. This allows for an end-user to sign a message which can then be relayed by another party to submit their approval. This can be useful for applications in which the end-user does not need to hold ETH .\n- In order to use this functionality, a user’s address must sign a message with the holder , spender , nonce , expiry and the allowed amount. This can then be submitted to Permit() to update the user’s approval.\nBuilt-in meta-transaction functionality of Dai\nSection titled “Built-in meta-transaction functionality of Dai”\nThe Dai token provides offchain approval, which means that as an owner of an ETH address, you can sign a permission (using the permit() function) which basically grants allowance to another ETH address. The ETH address that you provide permission to can then take care of the execution of the transfer but has an allowance.\nGotchas (Potential sources of user error)\nSection titled “Gotchas (Potential sources of user error)”\nUnlimited allowance is a relatively uncommon practice (though becoming more common). This could be something used to trick a user by a malicious contract into giving access to all their DAI. This is concerning in upgradeable contracts where the contract may appear innocent until upgraded to a malicious contract.\nDAI is also susceptible to the known ERC20 race condition , but should not normally be an issue with unlimited approval. We recommend any users using the approval for a specific amount be aware of this particular issue and use caution when authorizing other contracts to perform transfers on their behalf.\nThere is a slight deviation in transferFrom functionality: If the src == msg.sender the function does not require approval first and treats it as a normal transfer from the msg.sender to the dst .\nFailure Modes (Bounds on Operating Conditions & External Risk Factors)\nSection titled “Failure Modes (Bounds on Operating Conditions & External Risk Factors)”\nThere could potentially be a vat upgrade that would require new join contracts to be created.\nIf a gem contract were to go through a token upgrade or have the tokens frozen while a user’s collateral was in the system, there could potentially be a scenario in which the users were unable to redeem their collateral after the freeze or upgrade was finished. This seems to be a small risk though because it would seem likely that the token going through this upgrade would want to work alongside the Sky community to be sure this was not an issue.\nContract Details\nSection titled “Contract Details”\nGlossary (DAI)\nSection titled “Glossary (DAI)”\nKey Functionalities (as defined in the smart contract)\n- Mint - Mint to an address\n- Burn - Burn at an address\n- Push - Transfer\n- Pull - Transfer From\n- Move - Transfer From\n- Approve - Allow pulls and moves\n- Permit - Approve by signature\nOther\n- name - Dai Stablecoin\n- symbol - DAI\n- version - 1\n- decimals - 18\n- totalSupply - Total DAI Supply\n- balanceOf(usr: address) - User balance\n- allowance(src: address, dst: address) - Approvals\n- nonces(usr: address) - Permit nonce\nGlossary (Join)\nSection titled “Glossary (Join)”\n- vat - storage of the Vat’s address\n- ilk - id of the Ilk for which a GemJoin is created for\n- gem - the address of the ilk for transferring\n- dai - the address of the dai token\n- one - a 10^27 uint used for math in DaiJoin\n- wad - fixed point decimal with 18 decimals (for basic quantities, e.g. balances).\nReleased into the public domain (CC0 1.0 Universal) – trademarks remain with their owners; no warranty. See full license ."}
{"url":"https://docs.cosmos.network/","domain":"docs.cosmos.network","title":"Cosmos Developer Documentation - Cosmos Docs","hash":"8676d52551c7e0de0d2d61730f6caba4f3d8a2f7a93835a6fed878cb9cd77b34","tokens":383,"chars":1532,"crawler":"crawler-f6nn","verified":"exact","ts":1791171667759,"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.farcaster.xyz/","domain":"docs.farcaster.xyz","title":"Farcaster Docs","hash":"26e1937b637cc5ef038c4161f6e9eac9a24f7b0c86ce1adf20dea7796a697f74","tokens":255,"chars":1017,"crawler":"crawler-f6nn","verified":"exact","ts":1791171669954,"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.sui.io/","domain":"docs.sui.io","title":"Sui Documentation","hash":"3448db4d93359d91537c4efcc70d13a2ca060ded702bd87993f23270e145748b","tokens":362,"chars":1448,"crawler":"crawler-f6nn","verified":"exact","ts":1791171672365,"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-magicians.org/latest","domain":"ethereum-magicians.org","title":"Latest topics - Fellowship of Ethereum Magicians","hash":"e6a79e7f152b08990eb003cd837cab78caa0577dcfe60ed88aa360027cdcfa03","tokens":698,"chars":2792,"crawler":"crawler-f6nn","verified":"exact","ts":1791171675562,"text":"Fellowship of Ethereum Magicians\nTopic\nReplies\nViews\nActivity\nERC-8004: Trustless Agents\nERCs\n392\n19923\nOctober 5, 2026\nAll Core Devs - Consensus (ACDC) #189, October 15, 2026\nProtocol Calls & happenings\nacd\n,\nacdc\n1\n20\nOctober 5, 2026\nERC-6551: Non-fungible Token Bound Accounts\nERCs\nnft\n,\naccounts\n,\ntoken\n232\n21539\nOctober 5, 2026\nEIP-8363: Tapered Issuance Burn\nEIPs core\n224\n11176\nOctober 5, 2026\nERC-8436: Agent Collective Decision Framework\nERCs\nagents\n,\nerc\n3\n58\nOctober 5, 2026\nSealed-Bid Award Mechanism for Task Tenders (companion to ERC-8183 / 8195 / 8414)\nERCs\nagentic-commerce\n,\nerc\n,\nacution\n6\n56\nOctober 5, 2026\n[Research] Steganographic Point Obfuscation via Inverse 2-Isogenies for BLS12 Curves (DPI Censorship Resistance)\ncryptography\n11\n50\nOctober 5, 2026\nBend-SSZ: Formally proving SSZ\n0\n12\nOctober 4, 2026\nEIP-8435: Last-Written Block in PBT Leaves\nEIPs\n0\n28\nOctober 4, 2026\nEIP-8425: Quantum Freeze and Account Recovery\nEIPs\nevm\n18\n224\nOctober 4, 2026\nEIP-TBD: Resolution — Non-Self-Authorizing State Transitions\nEIPs informational\n3\n40\nOctober 4, 2026\nEIP-2537 (BLS12 precompile) discussion thread\nEIPs core\nprecompile\n,\ncore-eips\n,\nshanghai-candidate\n90\n42983\nOctober 3, 2026\nEIP-7976: Further increase calldata cost\nEIPs\n6\n219\nOctober 2, 2026\nEIP-8429: Escalating gas for repeated calls\nEIPs\n13\n134\nOctober 2, 2026\nERC-8414: Token-Bound Task Tenders\nERCs\nnft\n,\nerc\n,\nagent\n,\nagents\n20\n330\nOctober 2, 2026\nERC-8434: Agent Identity (AID)\nERCs\nagents\n,\nidentity\n,\nerc\n9\n100\nOctober 2, 2026\n[Pre-ERC Discussion] A Common Interface for RWA Disclosure Records, Evidence, and History\nERCs\nrwa\n,\nerc\n,\ntoken\n10\n248\nOctober 2, 2026\nERC-7579: Minimal Modular Smart Accounts\nERCs\n30\n5584\nOctober 2, 2026\nEIP-8061: Increase churn limits\nEIPs core\n3\n185\nOctober 2, 2026\nEIP-8430: AA Transaction Type (Split out from 8130)\n5\n71\nOctober 2, 2026\nAll Core Devs - Consensus (ACDC) #188, October 1, 2026\nProtocol Calls & happenings\nacd\n,\nacdc\n3\n75\nOctober 1, 2026\nERC-8421: Frame Transaction Alternative Mempools\nERCs\naccount-abstraction\n,\nmempool\n,\nprivacy\n2\n66\nOctober 1, 2026\nERC-8426: Wallet Pass Extension for NFTs\nERCs\n14\n194\nOctober 1, 2026\nERC-8427: Portable Spend Grants\nERCs\nagents\n,\neip-712\n,\neip-7702\n,\naccount-abstraction\n,\nai-agents\n6\n109\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\n257\nOctober 1, 2026\nERC-8419: Know-Your-Agent (KYA) Framework\nERCs\nidentity\n,\nai-agents\n,\nerc\n,\nzk\n,\nagents\n17\n264\nOctober 1, 2026\nERC-8416: Epoch-Based Fixed-Rate Vault\nERCs\n10\n247\nSeptember 30, 2026\nERC-8195: Task Market Protocol\nERCs\n8\n393\nSeptember 30, 2026\nERC-8183: Agentic Commerce\nERCs\npayments\n,\nagents\n,\nescrow\n410\n7163\nSeptember 30, 2026\nnext page →"}
{"url":"https://gov.optimism.io/latest","domain":"gov.optimism.io","title":"Optimism Collective - Optimism Collective","hash":"058956286bcc84ea5edf5096009f5e6dbea6d7247b4b919849cf69e3adfd50ab","tokens":850,"chars":3399,"crawler":"crawler-f6nn","verified":"exact","ts":1791171678365,"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\n61324\nSeptember 8, 2026\nProtocol Delegation Program Renewal\nMetagovernance\nseason-4\n37\n5460\nOctober 4, 2026\n404 Gov - Delegate Platform\nDelegates 🏛\n1\n57\nOctober 4, 2026\nIntroducing improvements to the Protocol Upgrade process\nUpdates and Announcements 📢\nseason-8\n7\n336\nOctober 4, 2026\nProposal to Align the OP Token with Superchain Success\nProposals 📃\nseason-9\n36\n4236\nOctober 4, 2026\nRe-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\nProposals 📃\n12\n1299\nSeptember 27, 2026\nExploring execution-time authorization for Superchain applications\n✨ General\n4\n64\nSeptember 24, 2026\n[RFC] Civilizational Upgrade: Implementing the ACOM P2P Semantic Mesh & Holographic Chain on the OP Superchain\nGovernance Design and Strategy 📐\n4\n119\nSeptember 24, 2026\nEden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\nCommunity Calls\n32\n699\nSeptember 23, 2026\nSeason 9 Final Report\nGrants Updates\n9\n461\nSeptember 23, 2026\nSeason 8 Growth Grants - TVL Impact Review\n✨ General\nseason-8\n2\n162\nSeptember 23, 2026\nUpgrade 20 - Super Root Dispute Games & OPCM v8.0.0\nProtocol Upgrade\n2\n278\nSeptember 16, 2026\n[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\nGovernance Fund Missions\n4\n127\nSeptember 8, 2026\nAn Optimism Governance / Ecosystem Grant Proposal\nProposals 📃\n0\n52\nSeptember 6, 2026\nOptimism Governance / Ecosystem Grant Proposal\nGet Started 🌱\n0\n49\nSeptember 4, 2026\nOP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n✨ General\n3\n104\nSeptember 4, 2026\nSecurity Council Communication Thread\nCouncil Communication Threads\n18\n1436\nSeptember 3, 2026\nPGov - Delegate Communication Thread\nDelegate Updates\n45\n3550\nSeptember 2, 2026\nMaintenance Upgrade Proposal: Unichain ProxyAdmin Owner Transition to Standard Optimism Governance\nProposals 📃\n0\n56\nSeptember 2, 2026\nMaintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit\nProposals 📃\n0\n54\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\n3597\nAugust 26, 2026\nBuyback Communication Thread\nCommunications 📣\nseason-9\n6\n865\nAugust 25, 2026\nMaintenance Upgrade Proposal: Update Soneium Fee Vaults Recipient\nProposals 📃\n1\n117\nAugust 23, 2026\nBrichis - Delegate Communication Thread\nDelegate Updates\n48\n3930\nAugust 21, 2026\nFranklinDAO (Penn Blockchain) - Delegate Communication Thread\nDelegate Updates\n5\n2224\nAugust 21, 2026\nCollective Year 4 Budget Update and Year 5 Budget Outlook\nFoundation Budgets\n2\n438\nAugust 7, 2026\nSandcastles and Social Mercenaries: Why EVM DAOs Are Being Looted\n✨ General\n2\n88\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\nnext page →"}
{"url":"https://docs.anza.xyz/consensus/fork-generation","domain":"docs.anza.xyz","title":"Fork Generation | Agave","hash":"ba0ce1c87d0763f498ba202e1dcacdec6faea96a4c9429c7b9bc947850a0d3ff","tokens":1475,"chars":5898,"crawler":"crawler-f6nn","verified":"exact","ts":1791171683065,"text":"Skip to main content\nFork Generation\nThe Solana protocol doesn’t wait for all validators to agree on a newly produced\nblock before the next block is produced. Because of that, it’s quite common for\ntwo different blocks to be chained to the same parent block. In those\nsituations, we call each conflicting chain a \"fork.\"\nSolana validators need to vote on one of these forks and reach agreement on\nwhich one to use through a consensus algorithm (that is beyond the scope of this\narticle). The main point you need to remember is that when there are competing\nforks, only one fork will be finalized by the cluster and the abandoned blocks\nin competing forks are all discarded.\nThis section describes how forks naturally occur as a consequence of\nleader rotation .\nOverview\nNodes take turns being leader and\ngenerating the PoH that encodes state changes. The cluster can tolerate loss of\nconnection to any leader by synthesizing what the leader would have\ngenerated had it been connected but not ingesting any state changes.\nThe possible number of forks is thereby limited to a \"there/not-there\" skip list\nof forks that may arise on leader rotation slot boundaries. At any given slot,\nonly a single leader's transactions will be accepted.\nForking example\nThe table below illustrates what competing forks could look like. Time\nprogresses from left to right and each slot is assigned to a validator that\ntemporarily becomes the cluster \"leader\" and may produce a block for that slot.\nIn this example, the leader for slot 3 chose to chain its \"Block 3\" directly to\n\"Block 1\" and in doing so skipped \"Block 2\". Similarly, the leader for slot 5\nchose to chain \"Block 5\" directly to \"Block 3\" and skipped \"Block 4\".\nNote that across different forks, the block produced for a given slot is\nalways the same because producing two different blocks for the same slot is\na slashable offense. So the conflicting forks above can be distinguished from\neach other by which slots they have skipped .\nSlot 1 Slot 2 Slot 3 Slot 4 Slot 5\nFork 1 Block 1 Block 3 Block 5\nFork 2 Block 1 Block 3 Block 4\nFork 3 Block 1 Block 2\nMessage Flow\n- Transactions are ingested by the current leader.\n- Leader filters valid transactions.\n- Leader executes valid transactions updating its state.\n- Leader packages transactions into entries based off its current PoH slot.\n- Leader transmits the entries to validator nodes (in signed shreds)\n- The PoH stream includes ticks; empty entries that indicate liveness of the\nleader and the passage of time on the cluster.\n- A leader's stream begins with the tick entries necessary to complete PoH\nback to the leader's most recently observed prior leader slot.\n- Validators retransmit entries to peers in their set and to further downstream\nnodes.\n- Validators validate the transactions and execute them on their state.\n- Validators compute the hash of the state.\n- At specific times, i.e. specific PoH tick counts, validators transmit votes\nto the leader.\n- Votes are signatures of the hash of the computed state at that PoH tick\ncount.\n- Votes are also propagated via gossip.\n- Leader executes the votes, the same as any other transaction, and broadcasts\nthem to the cluster.\n- Validators observe their votes and all the votes from the cluster.\nPartitions, Forks\nForks can arise at PoH tick counts that correspond to a vote. The next leader\nmay not have observed the last vote slot and may start their slot with generated\nvirtual PoH entries. These empty ticks are generated by all nodes in the cluster\nat a cluster-configured rate for hashes/per/tick Z .\nThere are only two possible versions of the PoH during a voting slot: PoH with\nT ticks and entries generated by the current leader, or PoH with just ticks.\nThe \"just ticks\" version of the PoH can be thought of as a virtual ledger, one\nthat all nodes in the cluster can derive from the last tick in the previous\nslot.\nValidators can ignore forks at other points (e.g. from the wrong leader), or\nslash the leader responsible for the fork.\nValidators vote based on a greedy choice to maximize their reward described in\nTower BFT .\nValidator's View\nTime Progression\nThe diagram below represents a validator's view of the PoH stream with possible\nforks over time. L1, L2, etc. are leader slots, and E s represent entries from\nthat leader during that leader's slot. The x s represent ticks only, and time\nflows downwards in the diagram.\nNote that an E appearing on 2 forks at the same slot is a slashable condition,\nso a validator observing E3 and E3' can slash L3 and safely choose x for\nthat slot. Once a validator commits to a fork, other forks can be discarded\nbelow that tick count. For any slot, validators need only consider a single \"has\nentries\" chain or a \"ticks only\" chain to be proposed by a leader. But multiple\nvirtual entries may overlap as they link back to the previous slot.\nTime Division\nIt's useful to consider leader rotation over PoH tick count as time division of\nthe job of encoding state for the cluster. The following table presents the\nabove tree of forks as a time-divided ledger.\nleader slot L1 L2 L3 L4 L5\ndata E1 E2 E3 E4 E5\nticks since prev x xx\nNote that only data from leader L3 will be accepted during leader slot L3. Data\nfrom L3 may include \"catchup\" ticks back to a slot other than L2 if L3 did not\nobserve L2's data. L4 and L5's transmissions include the \"ticks to prev\" PoH\nentries.\nThis arrangement of the network data streams permits nodes to save exactly this\nto the ledger for replay, restart, and checkpoints.\nLeader's View\nWhen a new leader begins a slot, it must first transmit any PoH (ticks)\nrequired to link the new slot with the most recently observed and voted slot.\nThe fork the leader proposes would link the current slot to a previous fork that\nthe leader has voted on with virtual ticks.\n- Overview\n- Forking example\n- Message Flow\n- Partitions, Forks\n- Validator's View\n- Leader's View"}
{"url":"https://bitcoin.org/en/support-bitcoin","domain":"bitcoin.org","title":"Support Bitcoin - Bitcoin","hash":"32b37130be4b2e46e9ec1bbee18c0394672db40c9410275f2fc1a042d58605b9","tokens":1156,"chars":4621,"crawler":"crawler-f6nn","verified":"exact","ts":1791171685039,"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\nSupport Bitcoin\nBitcoin was born from a small community and has grown fast. There are a lot of things you can do to support it and help others learn more.\nUsing Bitcoin\nUsing Bitcoin is the first thing you can do to support Bitcoin. You can use Bitcoin to send and receive payments anywhere in the world, without intermediaries. You can accept payments and make purchases with Bitcoin.\nBe the network\nIf you have a good Internet connection, you can strengthen the Bitcoin network by keeping full node software running on your computer or server with port 8333 open. Full nodes secure and relay all transactions.\nMining\nBitcoin mining today is a specialized industry that uses purpose-built hardware. Running a small miner can still be a way to learn how proof-of-work secures the network and to take part in the mining ecosystem. If you mine, you can help protect the network by preferring smaller mining pools and pools that support decentralized block construction through the Stratum V2 protocol.\nTranslate\nYou can help spread Bitcoin awareness by translating or improving translations inside important parts of the Bitcoin ecosystem. Just pick a project you would like to help with.\nBitcoin Core -\nBitcoin.org -\nBitcoin Wiki -\nBitcoin Wallet (Android) -\nElectrum\nDevelopment\nBitcoin is free software. If you are a developer, you can use your superpowers to do good and improve Bitcoin . You can contribute to Bitcoin Core, self-custody tools, payment infrastructure such as the Lightning Network , libraries, and documentation, or build new services that use Bitcoin.\nDonation\nYou can directly fund open-source projects, educational and community initiatives, research, and non-profit organizations that contribute to Bitcoin's development and adoption.\nOrganizations\nMany non-profit organizations are dedicated to protecting and promoting Bitcoin. You can help these groups by joining them and taking part in their projects, discussions and events.\nSpread\nSpeak about Bitcoin to interested people. Write about it on your blog. Tell your favorite shops you would like to pay with Bitcoin. Help to keep merchant directories up to date. Or be creative and make yourself a nice Bitcoin T-shirt.\nDocumentation\nBitcoin.org and the Bitcoin wiki provide useful documentation and we are constantly improving the information they contain. You can help to improve these resources and keep them up to date.\nMeet the communities\nYou can join Bitcoin communities and talk with other Bitcoin enthusiasts. You can learn more about Bitcoin every day, give help to new users and get involved in interesting projects.\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://kamino.com/docs/kmno","domain":"kamino.com","title":"KMNO - Kamino Docs","hash":"b9af5bc4f05163be3d2b327143a39a9cbd2cfaa35a579ac8bb21e106b3cb9774","tokens":323,"chars":1290,"crawler":"crawler-f6nn","verified":"exact","ts":1791171687667,"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\nToken\nKMNO\nKMNO is the native token of the Kamino protocol\nKMNO is the native token of Kamino Finance, with a total supply of 10,000,000,000. The token launched via genesis event on April 30, 2024.\nToken Info\nParameter Value\nTicker KMNO\nTotal Supply 10,000,000,000\nToken Generation Event April 30, 2024\nInitial Circulating Supply ~1,000,000,000\nBlockchain Solana\nDistribution\nAllocation Share Notes\nCommunity & Grants 35% Builder grants and community incentives managed by Kamino treasury\nKey Stakeholders & Advisors 35% 12-month lockup, then 24-month linear vest\nCore Contributors 20% 12-month lockup, then 24-month linear vest\nLiquidity & Treasury 10% Used to grow KMNO liquidity across platforms\nGenesis Allocation (subset of Community & Grants) - 7.5% of total supply distributed at TGE to existing platform participants (included within Community & Grants allocation above)\nFor the latest information on KMNO distribution and vesting, see the\nKamino governance forum .\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"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-f6nn","verified":"exact","ts":1791171690111,"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://wormhole.com/docs/","domain":"wormhole.com","title":"Wormhole Docs","hash":"e32fd25d855cd305048f55eff8fa87131655c2246c4de4276f725b1b401c124b","tokens":338,"chars":1351,"crawler":"crawler-f6nn","verified":"exact","ts":1791171692191,"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://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-f6nn","verified":"exact","ts":1791171694319,"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://ethereum.org/developers/docs/evm/","domain":"ethereum.org","title":"Ethereum Virtual Machine (EVM) | ethereum.org","hash":"36e7ddc31c6beadd3be7898c9ba82259c5b1e33abdfd3bebe27bc076d4dd6d01","tokens":1523,"chars":6092,"crawler":"crawler-f6nn","verified":"exact","ts":1791171696808,"text":"Skip to main content\nChange page\nEthereum Virtual Machine (EVM)\nEdit page (opens in a new tab)\nThe Ethereum Virtual Machine (EVM) is a decentralized virtual environment that executes code consistently and securely across all Ethereum nodes. Nodes run the EVM to execute smart contracts, using \" gas \" to measure the computational effort required for operations , ensuring efficient resource allocation and network security.\nPrerequisites\nSome basic familiarity with common terminology in computer science such as bytes (opens in a new tab) , memory (opens in a new tab) , and a stack (opens in a new tab) are necessary to understand the EVM. It would also be helpful to be comfortable with cryptography/blockchain concepts like hash functions (opens in a new tab) and the Merkle tree (opens in a new tab) .\nFrom ledger to state machine\nThe analogy of a 'distributed ledger' is often used to describe blockchains like Bitcoin, which enable a decentralized currency using fundamental tools of cryptography. The ledger maintains a record of activity which must adhere to a set of rules that govern what someone can and cannot do to modify the ledger. For example, a Bitcoin address cannot spend more Bitcoin than it has previously received. These rules underpin all transactions on Bitcoin and many other blockchains.\nWhile Ethereum has its own native cryptocurrency (ether) that follows almost exactly the same intuitive rules, it also enables a much more powerful function: smart contracts . For this more complex feature, a more sophisticated analogy is required. Instead of a distributed ledger, Ethereum is a distributed state machine (opens in a new tab) . Ethereum's state is a large data structure which holds not only all accounts and balances, but a machine state , which can change from block to block according to a pre-defined set of rules, and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the EVM.\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nThe Ethereum state transition function\nThe EVM behaves as a mathematical function would: Given an input, it produces a deterministic output. It therefore is quite helpful to more formally describe Ethereum as having a state transition function :\nY(S, T)= S'\nGiven an old valid state (S) and a new set of valid transactions (T) , the Ethereum state transition function Y(S, T) produces a new valid output state S'\nState\nIn the context of Ethereum, the state is an enormous data structure called a modified Merkle Patricia Trie , which keeps all accounts linked by hashes and reducible to a single root hash stored on the blockchain.\nTransactions\nTransactions are cryptographically signed instructions from accounts. There are two types of transactions: those which result in message calls and those which result in contract creation.\nContract creation results in the creation of a new contract account containing compiled smart contract bytecode. Whenever another account makes a message call to that contract, it executes its bytecode.\nEVM instructions\nThe EVM executes as a stack machine (opens in a new tab) with a depth of 1024 items. Each item is a 256-bit word, which was chosen for the ease of use with 256-bit cryptography (such as Keccak-256 hashes or secp256k1 signatures).\nDuring execution, the EVM maintains a transient memory (as a word-addressed byte array), which does not persist between transactions.\nTransient storage\nTransient storage is a per-transaction key–value store accessed through the TSTORE and TLOAD opcodes. It persists across all internal calls during the same transaction but is cleared at the end of the transaction. Unlike memory, transient storage is modeled as part of the EVM state rather than the execution frame, yet it is not committed to the global state. Transient storage enables gas-efficient temporary state sharing across internal calls during a transaction.\nStorage\nContracts contain a Merkle Patricia storage trie (as a word-addressable word array), associated with the account in question and part of the global state. This persistent storage differs from transient storage, which is available only for the duration of a single transaction and does not form part of the account's persistent storage trie.\nOpcodes\nCompiled smart contract bytecode executes as a number of EVM opcodes , which perform standard stack operations like XOR , AND , ADD , SUB , etc. The EVM also implements a number of blockchain-specific stack operations, such as ADDRESS , BALANCE , BLOCKHASH , etc. The opcode set also includes TSTORE and TLOAD , which provide access to transient storage.\nDiagrams adapted from Ethereum EVM illustrated (opens in a new tab)\nEVM implementations\nAll implementations of the EVM must adhere to the specification described in the Ethereum Yellowpaper.\nOver Ethereum's ten year history, the EVM has undergone several revisions, and there are several implementations of the EVM in various programming languages.\nEthereum execution clients include an EVM implementation. Additionally, there are multiple standalone implementations, including:\n- Py-EVM (opens in a new tab) - Python\n- evmone (opens in a new tab) - C++\n- ethereumjs-vm (opens in a new tab) - JavaScript\n- revm (opens in a new tab) - Rust\nFurther Reading\n- Ethereum Yellowpaper (opens in a new tab)\n- Jellopaper aka KEVM: Semantics of EVM in K (opens in a new tab)\n- The Beigepaper (opens in a new tab)\n- Ethereum Virtual Machine Opcodes (opens in a new tab)\n- Ethereum Virtual Machine Opcodes Interactive Reference (opens in a new tab)\n- A short introduction in Solidity's documentation (opens in a new tab)\n- Mastering Ethereum - The Ethereum Virtual Machine (opens in a new tab)\nRelated Topics\n- Gas\nTutorials: Ethereum Virtual Machine (EVM) / Opcodes on Ethereum\n- Understanding the Yellow Paper's EVM Specifications – A guided walkthrough of the formal EVM spec from the Ethereum Yellow Paper.\n- Reverse Engineering a Contract – How to reverse-engineer a compiled smart contract using EVM opcodes.\nTest your Ethereum knowledge"}
{"url":"https://docs.optimism.io/use-cases/implement-a-custom-deposit-flow","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"7a5f0c92c2ea5727f95c2eeb14f64da1546a183b686e6376fd7e9a5dba390b74","tokens":2271,"chars":9083,"crawler":"crawler-f6nn","verified":"exact","ts":1791171699455,"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\nUse cases\nImplement a custom deposit flow\nBuild an L1 to L2 deposit path for your application, choosing the right contract entry point and handling gas, aliasing, and failed messages.\nThis guide takes an app developer whose contracts need to trigger effects on\nan OP Stack chain from Ethereum and walks the deposit path in one pass: how a\ndeposit travels from L1 to L2, which of the three contract entry points fits\nyour use case, and the safety details (gas limits, address aliasing, failed\nmessages) that custom integrations get wrong. It involves the StandardBridge ,\nthe CrossDomainMessenger pair, and the OptimismPortal contract.\nIs this guide for you?\nUse this guide if:\n- You are building contracts or backend infrastructure that initiate L2\nactions from L1: a custom token bridge, an L1-controlled L2 contract, or\na protocol that must be able to force transactions into the L2.\n- You need to choose which contract interface to build against, not just\nfollow one path.\nIf you only need to move ETH or a standard ERC-20 between layers, use the\nStandard Bridge as is. If\nyour goal is L2 to L1 (withdrawals), read the\nwithdrawal flow explanation instead; the\n7-day challenge period makes it a different problem. For messaging between two\nOP Stack chains rather than L1 and L2, see\ninterop explainer . This guide covers the L1 to\nL2 direction only.\nBefore you start\nYou should already have:\n- A Solidity development environment and a funded account on Sepolia and\nOP Sepolia (or another OP Stack testnet).\n- Basic familiarity with how contracts call each other on a single chain;\nthe bridging basics guide sets\nthe baseline vocabulary.\nStep 1: Map the deposit path\nEvery L1 to L2 write, whatever interface you use, ends as a call to the\nOptimismPortal contract’s depositTransaction function, which emits a\nTransactionDeposited event that the rollup node derives into an L2\ntransaction. Read the deposit flow explanation\nand take away:\n- The encapsulation chain: your contract calls a messenger, the messenger\ncalls the portal, the portal emits the event, and op-node turns the\nevent into an L2 transaction. Each layer you use adds convenience and\nsafety on top of the one below it.\n- That deposits are included by derivation, not by the sequencer’s grace:\nonce the L1 transaction is confirmed, the L2 transaction will happen.\nThen skim Sending data between L1 and L2\nand take away the sendMessage(target, message, minGasLimit) interface shape,\nthe 1 to 3 minute L1 to L2 delivery time, and how the portal charges for L2\nexecution by burning L1 gas.\nStep 2: Choose your entry layer\nThis is the decision that shapes everything downstream. Work down the table\nand stop at the first row that fits:\nIf … Choose … Because …\nYou are moving ETH or ERC-20 tokens and standard lock-and-mint accounting fits StandardBridge , extended if necessary It is the audited path, it is compatible with the Superchain Bridges UI and the token list, and building a custom bridged token covers most “the standard token doesn’t fit” cases without a new bridge.\nYou are calling an L2 contract and want delivery guarantees L1CrossDomainMessenger.sendMessage The messenger records messages that fail on L2 and lets anyone replay them with more gas, and the target can authenticate the L1 sender via xDomainMessageSender .\nYou need raw deposited transactions: forced inclusion when the sequencer censors you, or full control of the L2 call OptimismPortal.depositTransaction , called directly Nothing sits between you and derivation. But you give up the messenger’s replay safety net and sender authentication, and address aliasing applies to your contract (Step 3).\nFor the current contract interfaces, use the\ncontracts-bedrock reference\nor the source on develop :\nStandardBridge.sol ,\nCrossDomainMessenger.sol ,\nand OptimismPortal2.sol .\nDeployed addresses for OP Mainnet and OP Sepolia are on the\ncontract addresses page .\nIf you concluded you need a custom bridge, read the\ncustom bridges guide and take\naway the recommendation to extend StandardBridge rather than start from\nscratch, and the requirement to register bridged tokens in the Superchain\nToken List.\nStep 3: Get the safety details right\nThree properties of the deposit path surprise custom integrations. Check each\nagainst your design before writing code:\n- Address aliasing. When a contract (not an EOA) initiates a deposit,\nthe from address on L2 is the L1 contract’s address plus a constant\noffset. If your L2 contract checks msg.sender against an L1 contract\naddress, it must check the aliased form. Read\naddress aliasing in the deposits spec\nand take away the offset constant and the reason it exists. The messenger\nabstracts this away; portal-direct integrations must handle it themselves.\n- Gas limits are minimums with real floors. The minGasLimit you pass\nto sendMessage is a minimum for the L2 execution, and the portal\nenforces its own data-size-scaled minimum on every deposit (see\nminimumGasLimit in\nOptimismPortal2.sol )\nplus a hard cap on deposit calldata size. The L1 gas burned to pay for L2\ngas is dynamic, so follow the\nfee guidance in the messaging guide\nand take away the recommendation to buffer your gas limit by at least 20%.\n- Sender authentication. On the receiving side, msg.sender is the L2\nmessenger, not your L1 contract. Read\naccessing msg.sender\nand take away the xDomainMessageSender check pattern. Portal-direct\ndeposits do not get this: the L2 target sees only the (aliased) from .\nStep 4: Build against the pattern\nEach entry layer has a worked, runnable path. Follow the one matching your\nStep 2 decision; each is a tutorial, so it includes environment setup this\nguide skips:\n- Standard Bridge with a custom token : follow the custom-token path of\nCreate an L2 token for the Standard Bridge\nto deploy an OptimismMintableERC20 variant with custom logic.\n- Messenger-based contract calls : follow\nCommunicating between contracts on L1 and L2\nfor the full send, relay, and authenticate loop in Solidity.\n- Portal-direct deposits : there is no dedicated tutorial; work from the\ndepositTransaction interface in\nOptimismPortal2.sol\nand the\ndeposits spec ,\nand keep Step 3’s aliasing and gas rules in front of you.\nStep 5: Test the flow locally\nDeposits cross two chains, so test against a local multi-chain environment\nbefore testnet. Follow the\nsupersim deposit transactions tutorial\nand take away how supersim surfaces the OptimismPortal ,\nL1CrossDomainMessenger , and L1StandardBridge addresses for each local\nchain, and how to watch a deposit land on the L2 without running a full\nderivation pipeline.\nStep 6: Plan for failed deposits\nAn L2 execution can fail (usually out-of-gas), and your design must decide in\nadvance who notices and who pays for the retry:\nIf … Choose … Because …\nYou went through the messenger (or Standard Bridge) A monitoring-and-replay runbook Failed messages are recorded on L2 and anyone can replay them later with a higher gas limit.\nYou went portal-direct Conservative gas limits and idempotent L2 handlers There is no recorded-message safety net; a failed deposited transaction is final.\nFor the messenger path, follow the\nreplaying a failed deposit tutorial\nand take away how a failed message is detected and the replay call that\nretries it with more gas.\nStep 7: Verify the outcome\nRun your flow end to end on testnet and confirm each link of the chain:\n- The L1 side : your transaction emits a TransactionDeposited event\nfrom the OptimismPortal (directly or via the messenger). This event is\nthe canonical proof the deposit entered the system.\n- The L2 side : the corresponding L2 transaction appears within a few\nminutes, and the target contract observed the sender it expected\n( xDomainMessageSender for messenger flows, the aliased address for\nportal-direct flows).\n- The failure drill (messenger flows): force one deposit to fail with an\nundersized minGasLimit , confirm it is recorded as a failed message, and\nreplay it successfully per Step 6.\n- Token accounting (bridge flows): amounts locked on L1 match amounts\nminted on L2, and the round trip back burns and releases correctly.\nNext steps\n- Deposits in the protocol specs :\nthe normative definition of deposited transactions, the deposit contract,\nand address aliasing.\n- contracts-bedrock reference :\ngenerated interface documentation for the current contracts, for when you\nneed the exact function and event signatures.\n- OptimismPortal2.sol on develop :\nthe deposit entry point’s source, including minimumGasLimit and the\ncalldata cap. Tracks the develop branch, so read it alongside the\nrelease your chain actually runs.\n- Superchain Token List :\nwhere custom-bridged tokens must be registered before users can find\nthem.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.solana.com/latest","domain":"forum.solana.com","title":"Latest topics - Solana Developer Forums","hash":"faeb56638b9c13f7c304b2d0605a2225af5861dc7409e54ae081515955f66551","tokens":733,"chars":2929,"crawler":"crawler-f6nn","verified":"exact","ts":1791171701742,"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\n128\nAugust 28, 2026\nSIMD-0550: Proposal to Double Disinflation\nGovernance\neconomics\n9\n1979\nAugust 18, 2026\nDecreasing number of validators, centralizing steak, and overall network health / resilience under extreme events\nGovernance\n0\n75\nAugust 12, 2026\nTest Validator Plugin Framework\nRFP\n15\n2172\nJuly 31, 2026\nVOTE! First Governance Advisory Vote by Validators\nGovernance\nvote\n6\n2811\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\n11685\nJune 13, 2026\nSIMD-0411: Proposal for Doubling the Disinflation Rate\nGovernance\neconomics\n1\n3387\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\n305\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\n5616\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\n1086\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://ethresear.ch/latest","domain":"ethresear.ch","title":"Ethereum Research","hash":"26684f41dd50feb0de528100b69aabcab9b86cac8f9918d57f947838b8a25fc7","tokens":831,"chars":3322,"crawler":"crawler-f6nn","verified":"exact","ts":1791171704541,"text":"Ethereum Research\nTopic\nReplies\nViews\nActivity\nRead this before posting\nAdministrivia\n13\n61457\nAugust 20, 2026\nProposal for a minimal compute-anchored purchasing power signal\nEconomics\n0\n47\nOctober 2, 2026\nSix defects in one signature verification tool, found from outside in six rounds\nSecurity\n0\n45\nOctober 2, 2026\nThe Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\nExecution Layer Research\nstateless\n10\n778\nOctober 2, 2026\nMempool Account Transaction Capacity from Historical Activity (MATCHA)\nExecution Layer Research\naccount-abstraction\n,\ntransaction-privacy\n9\n515\nOctober 2, 2026\nStaking rewards as venture capital, governed by futarchy\nEconomics\nfutarchy\n,\ndao\n2\n211\nOctober 1, 2026\nTrust minimized transaction simulation using state proofs\nSecurity\n7\n628\nOctober 1, 2026\nPQ anonymity for Stealth Address Protocol\nPrivacy\n4\n198\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\n147\nSeptember 30, 2026\nTowards Encrypted Mempools from Threshold IBE without Batching\nCryptography\n4\n231\nSeptember 29, 2026\nEthereum's TCB, Part 1: The client\nSecurity\nsecurity\n3\n337\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\n407\nSeptember 27, 2026\nFormal Verification of Execution and Consensus Clients\nSecurity\nsecurity\n12\n594\nSeptember 25, 2026\nSnappy with a memory: ~40% less gossip traffic\nNetworking\nsingle-slot-finality\n1\n149\nSeptember 25, 2026\nCapacity oracles\nEconomics\n4\n406\nSeptember 25, 2026\nDesigns for EVM gas accounting in EIP-7999\nExecution Layer Research\nfee-market\n6\n460\nSeptember 24, 2026\nProprietary AMMs and Ethereum\nExecution Layer Research\nmev\n13\n1315\nSeptember 24, 2026\nCHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\nExecution Layer Research\nnetworking\n,\np2p\n0\n104\nSeptember 24, 2026\nPost-Poseidon: Hash Function Variants for Ethereum\nCryptography\n0\n307\nSeptember 23, 2026\nEIP-8411 payload segmentation under the Shadow simulator\nNetworking\nscaling\n,\np2p\n0\n79\nSeptember 23, 2026\nPost-Quantum Lattice or Hash-Based: One Question, Two Right Answers\nCryptography\npost-quantum\n1\n179\nSeptember 22, 2026\nEtheorem update: the complete executable consensus specs written in Lean 4\nConsensus\n0\n190\nSeptember 21, 2026\nPost-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\nEconomics\n0\n144\nSeptember 21, 2026\nStrict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)\nPrivacy\n0\n53\nSeptember 19, 2026\nCryptographic canaries and backups\nCryptography\n8\n7556\nSeptember 18, 2026\nSame instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter\nExecution Layer Research\n1\n130\nSeptember 18, 2026\nBounding Collusion in Capital Allocation DAOs via Subjective Human Oracles\nEconomics\ncollusion\n,\ndao\n,\npublic-good\n4\n157\nSeptember 17, 2026\nHow Hegotá can influence the state roadmap\nExecution Layer Research\n1\n216\nSeptember 17, 2026\nWen fast payload broadcast? Segment, code, push, pull, and everything in between\nNetworking\np2p\n5\n243\nSeptember 17, 2026\nnext page →"}
{"url":"https://docs.ipfs.tech/","domain":"docs.ipfs.tech","title":"IPFS Documentation | IPFS Docs","hash":"cc70bfbc3d62ef76df2bd477f2010f8bc5f857345abf085fb00bb0c2f95a5de8","tokens":1041,"chars":4164,"crawler":"crawler-f6nn","verified":"exact","ts":1791171707467,"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://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-f6nn","verified":"exact","ts":1791171709912,"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://forum.arbitrum.foundation/t/constitutional-establish-an-l1-voting-recovery-system/31534","domain":"forum.arbitrum.foundation","title":"[CONSTITUTIONAL]: Establish an L1 Voting Recovery System - Proposals - Arbitrum","hash":"f8325b2f843a66a0143ad66b2e8439711214148919b93ab1615a8b304096cfb1","tokens":3416,"chars":13663,"crawler":"crawler-f6nn","verified":"exact","ts":1791171712206,"text":"Arbitrum\n[CONSTITUTIONAL]: Establish an L1 Voting Recovery System\nProposals\nproposal\noffchain\nOctober 2, 2026, 11:15pm\n1\n[Constitutional] AIP: Establish an L1 Voting Recovery System\nAbstract\nThis AIP proposes a L1 voting system that allows ArbitrumDAO proposals to be created, voted on, queued, and executed from Ethereum L1. Voting power is derived from ARB delegations proven against confirmed Arbitrum assertions. Approved actions would be routed through a new L1 timelock to the existing upgrade executors.\nThe system is intended as a last-resort recovery path if L2 governance is broken and the Security Council is unable to act. It does not replace normal L2 governance or modify the Security Council’s authority.\nMotivation\nA simultaneous failure of L2 governance and the Security Council could prevent the DAO from repairing its governance contracts. L2 governance could become unavailable because of a contract defect. Active delegates would still exist, but the DAO would have no independent path to authorize a repair.\nThe proposed system preserves a DAO-controlled recovery path by proving L2 voting state on L1 and allowing governance to proceed without relying on the L2 governor or Security Council.\nRationale\n- Maintain an always-available L1 governance path so that it remains accessible during an emergency.\n- Use extended delays to preserve delegate reaction time, effective voting time, and a weaker form of the right to withdraw.\nSpecifications\nFor supporting technical documentation, see l1-voting.md .\nAffected Governed Chains\nTo be confirmed before the temperature check. At that time this AIP will specify if it affects Arbitrum One and Arbitrum Nova.\nSystem Components\n- L1ArbitrumGovernor : A modified OpenZeppelin governor that creates proposals, checks proven voting power, records votes, and queues successful proposals.\n- L1ArbitrumTimelock : A new deployment of the same timelock contract that exists on L1.\n- DelegateMapping : A contract deployed on L1 and L2 that links an L1 voting address to an L2 delegate.\n- L2StateMirror : A contract that checkpoints confirmed assertions and stores L2 state values proven against them.\n- ProofHelper : A helper contract for handling L2 block headers and storage proofs.\n- VotingTokenMirror : The governor-facing contract that resolves L1 voters to L2 delegates and returns proven voting power and quorum inputs.\nDelegate Registration\n- Delegates using contract addresses: Must register an L1 voting address through DelegateMapping on Arbitrum One. Registration should preferably occur before an L1 proposal is created. Following proposal creation, delegates have 3 days to register so the updated mapping can be included in a confirmed assertion before voting begins.\n- Delegates using EOAs: May register an L1 voting address using an EIP-712 signature submitted through L2StateMirror.claimL1AddressBySig , without first registering the address on Arbitrum One. The signature is bound to the applicable assertion.\n- In both cases, the L1 voting address must claim the corresponding L2 delegate through the L1 DelegateMapping before proposing or voting.\nDeployment Parameters\nFor more detail on the “7 day censorship budget”, see the BoLD whitepaper .\n- Voting delay: 17 days, comprising 3 days for delegate reaction, including acquiring voting power or registering in the L2 DelegateMapping , plus up to 14 days for assertion confirmation.\n- Voting period: 21 days, comprising 14 days of effective voting time plus a 7-day censorship budget\n- Timelock delay: 25 days, comprising a 14-day worst-case assertion-confirmation period plus 11 additional days corresponding to the current 8-day L2 timelock and 3-day L1 timelock.\n- Proposal block lookback: Up to 300 L1 blocks, approximately one hour, for the proposal-threshold checkpoint. This gives proposers time to prove prerequisite information in the L2StateMirror\n- Quorum numerator: 5000 (50%), applied to the totalDelegated Votable Tokens at the locked snapshot block, consistent with the core governor on L2.\n- Late-quorum extension period: 2 days, consistent with the core governor on L2.\n- Minimum and maximum quorum: 150 million and 450 million ARB, respectively, consistent with the core governor on L2.\nGovernance and Execution\n- Deploy the L1 governance components behind transparent proxies owned by the existing proxy admin or admins, as applicable. See DeployL1Voting.s.sol for the deployment procedure.\n- Grant the new L1 timelock the EXECUTOR_ROLE on the L1 upgrade executor.\n- Grant the L2 alias of the new L1 timelock the EXECUTOR_ROLE on the L2 upgrade executor.\nProposed Changes to the ArbitrumDAO Constitution\nThis proposal would amend Section 2 of the ArbitrumDAO Constitution to recognize an additional L1 voting procedure.\nThe existing AIP process on Arbitrum One would remain unchanged. The L1 Voting Procedure would operate as an additional DAO-controlled governance path using ARB voting power proven from confirmed Arbitrum state.\nClarify the Scope of the Existing Process\nLocation: Section 2: DAO Proposals and Voting Procedures\nCurrent text:\nThe following process governs the rules and procedures by which the ArbitrumDAO may propose, vote on and implement Arbitrum Improvement Proposals (AIPs). No AIP may be in violation of applicable laws, in particular sanctions-related regulations.\nProposed new text:\nThe following process governs the rules and procedures by which the ArbitrumDAO may propose, vote on and implement Arbitrum Improvement Proposals (AIPs). For AIPs submitted through the L1 Voting Procedure described below, the rules and procedures in this Section apply except where expressly modified by the L1 Voting Procedure. No AIP may be in violation of applicable laws, in particular sanctions-related regulations.\nClarify the Existing Phase 2\nLocation: Section 2: DAO Proposals and Voting Procedures, Phase 2\nCurrent text:\nPhase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/ . The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens. After 3 days, a voter distribution snapshot will be taken and the voting period will begin; this gives interested parties time to discuss the AIP and gather votes before the voter distribution snapshot is taken.\nProposed new text:\nPhase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/ . The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens.\nAfter 3 days, a voter distribution snapshot will be taken and the voting period will begin;\nthis gives interested parties time to discuss the AIP and gather votes before the voter\ndistribution snapshot is taken.\nFor an AIP submitted through the L1 Voting Procedure, the requirements in the\npreceding two paragraphs concerning submission, the proposer threshold, the voter\ndistribution snapshot and the start of voting are replaced by the corresponding\nrequirements of the L1 Voting Procedure. The remaining provisions of this Phase 2,\nincluding those concerning labeling and classification of AIPs, specification of affected\nGoverned Chains, and the recommended AIP contents, apply to an AIP submitted\nthrough the L1 Voting Procedure.\nClarify the Existing Phase 3\nLocation: Section 2: DAO Proposals and Voting Procedures, Phase 3\nCurrent text:\nPhase 3: DAO votes on AIP, on Arbitrum One (14-16 days): During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP.\nProposed new text:\nPhase 3: DAO votes on AIP, on Arbitrum One (14-16 days): During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP, unless the AIP was submitted through the L1 Voting Procedure in which case voting takes place as provided in the L1 Voting Procedure. Threshold 1 and Threshold 2, as set out below, apply to every AIP, including an AIP submitted through the L1 Voting Procedure.\nAdd an L1 Voting Procedure\nLocation: Section 2: DAO Proposals and Voting Procedures\nCurrent text:\nNo corresponding provision currently exists.\nProposed new text:\nL1 Voting Procedure\nIn addition to the AIP process described above, the ArbitrumDAO may propose, vote on, approve, and implement AIPs through governance smart contracts deployed on Ethereum.\nVoting power under this procedure must be derived from Votable Tokens delegated on Arbitrum One and proven on Ethereum against a confirmed Arbitrum One assertion.\nThe AIP proposer is required to have an address on Arbitrum One that is delegated at least 1,000,000 Votable Tokens, or an Ethereum address registered as the L1 voting address for such an address, in each case as proven against a confirmed Arbitrum One assertion.\nFollowing submission of an AIP through the L1 Voting Procedure, voting will begin after 17 days . This comprises 3 days for delegates to gather voting power or register their L1 voting addresses, plus up to 14 days for assertion confirmation.\nAfter the voting delay, the ArbitrumDAO will be able to vote directly on-chain through the governance smart contracts deployed on Ethereum. Before the first vote is cast, the voter distribution snapshot must be fixed to a confirmed Arbitrum One block.\nThe voting period ends 21 days after the start of voting. However, if Threshold 2 was reached within the last 2 days of the 21-day voting period, the voting period will be extended to end 2 days after Threshold 2 was reached.\nAn AIP submitted through the L1 Voting Procedure passes if Threshold 1 and the Constitutional AIP requirements under Threshold 2 are satisfied. Voting power and Delegated Votable Tokens will be determined using Arbitrum One state proven on Ethereum against the confirmed assertion used for the voter distribution snapshot.\nIf the AIP passes, it will be queued in the L1VotingTimelock, a governance timelock smart contract deployed on Ethereum, for a minimum period of 25 days. Following that period, the AIP may be implemented through the relevant upgrade executor or executors.\nThe provisions of Phases 2 and 3 identified above as replaced, and phases 4 through 7 of the ordinary AIP process, do not apply to an AIP submitted through the L1 Voting Procedure. Instead the 17-day voting delay, 21-day voting period, applicable late-quorum extension, and 25-day L1 timelock govern its submission, voting, approval, and implementation.\nThe provisions of this Section concerning forum discussion, temperature checks, AIP labeling and classification, affected Governed Chains, recommended AIP contents voting options, Threshold 1, and Threshold 2 apply to AIPs submitted through the L1 Voting Procedure, except that threshold 2 applies as provided above.\nAn AIP may not be submitted through the L1 Voting Procedure while another AIP proposing the same or conflicting actions is pending under the ordinary AIP process, and an AIP may not be submitted under the ordinary AIP process while another AIP proposing the same or conflicting actions is pending under the L1 Voting Procedure. An AIP is pending from its submission until it fails to pass or is implemented. As a recommended guideline, DAO members should vote against any AIP submitted in violation of this paragraph.\nThe L1 Voting Procedure does not replace or modify the ordinary AIP process. It does not modify the Security Council’s powers under Section 3 of this Constitution.\nSteps to Implement\n- Publish this proposal on the ArbitrumDAO governance forum for community and delegate review.\n- Complete the forum discussion period.\n- Submit the proposal to Snapshot for a temperature check.\n- Incorporate applicable DAO feedback and finalize the contracts, deployment configuration, tests, and operating procedures.\n- Complete an independent security audit and publish the audit report and applicable remediations.\n- Test proposal creation, proof submission, voting, queuing, cross-chain execution, and recovery from stale checkpoints in a designated test environment.\n- Publish the final contract addresses, verified source code, deployment parameters, audit materials, constitutional amendments, and executable governance payload.\n- Submit the final Constitutional AIP through the standard ArbitrumDAO governance process.\n- If approved, deploy and initialize the system, grant the required executor roles, and begin checkpoint monitoring.\nTimeline\nThe implementation timeline will be finalized following technical review, audit scoping, and review by the Arbitrum Foundation and Legal.\n- Forum publication: This post\n- Temperature check: To be confirmed\n- Security audit and testing: Ongoing\n- Constitutional on-chain vote: Following successful technical review, audit, testing, and publication of the executable payload\n- Deployment: Subject to approval of the Constitutional AIP\nOverall costs\nAll engineering and research conducted for this proposal was done so by Offchain Labs at no explicit or additional costs to the ArbitrumDAO\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nConstitutional - Extend Delay on L2Time Lock\nFinalized AIPs\n68\n1349\nNovember 1, 2024\nProposal: AIP-1.2 - Foundation and DAO Governance\nFinalized AIPs\npassed\n,\ntally\n65\n19046\nJune 21, 2023\n[Constitutional] AIP: DVP Quorum\nFinalized AIPs\n21\n897\nDecember 12, 2025\nExploring the Viability of Governance Attacks - Part 1: Arbitrum Governance and its Challenges\nARDC Research Member\n0\n361\nApril 9, 2025\nAreta Delegate Thread\nDelegate Statements\ndelegation\n,\ndelegate-statements\n27\n817\nAugust 12, 2026"}
{"url":"https://docs.celestia.org/","domain":"docs.celestia.org","title":"Celestia Documentation","hash":"546343424bf7aeafe6a2bf00e87acdf98ec60c7d07356e0b181f125b6fcef1a9","tokens":106,"chars":423,"crawler":"crawler-f6nn","verified":"exact","ts":1791171714526,"text":"Skip to Content\nCelestia docs\nCelestia is the modular blockchain powering unstoppable apps with full-stack\ncontrol.\n📚\nLearn\nUnderstand modular blockchains and Celestia’s architecture\n🛠️\nBuild\nStart building applications on Celestia’s data availability layer\n⚙️\nOperate\nRun and maintain Celestia nodes and infrastructure\n🔌\nAPI\nReference for Celestia’s node RPC methods and client libraries\nLast updated on October 1, 2026"}
{"url":"https://docs.anza.xyz/cli","domain":"docs.anza.xyz","title":"Solana CLI Tool Suite | Agave","hash":"a28d45f2fcdcfb3a758c35fc79dd5ba053c7d12d698f330774db63072fa356b9","tokens":205,"chars":820,"crawler":"crawler-f6nn","verified":"exact","ts":1791171716444,"text":"Skip to main content\nSolana CLI Tool Suite\nIn this section, we will describe how to use the Solana command-line tools to\ncreate a wallet , to send and receive SOL tokens, and to participate in the\ncluster by delegating stake.\nTo interact with a Solana cluster, we will use its command-line interface, also\nknown as the CLI. We use the command-line because it is the first place the\nAnza core team deploys new functionality. The command-line interface is not\nnecessarily the easiest to use, but it provides the most direct, flexible, and\nsecure access to your Solana accounts.\nGetting Started\nTo get started using the Solana Command Line (CLI) tools:\n- Install the Solana CLI Tool Suite\n- Introduction to our CLI conventions\n- Create a Wallet using the CLI\n- Choose a Cluster to connect to using the CLI\n- Getting Started"}
{"url":"https://solana.com/docs/core/transactions","domain":"solana.com","title":"","hash":"638e58ef5223351ab022ddbad9233d29eb14bf5c668f0a43ddc617ff7cceecf3","tokens":962,"chars":3846,"crawler":"crawler-f6nn","verified":"exact","ts":1791171718416,"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://forum.arbitrum.foundation/c/proposals/finalized-aips/9","domain":"forum.arbitrum.foundation","title":"Latest Finalized AIPs topics - Arbitrum","hash":"f1da36067346f2bb31391ff53742923d1bdb73454b77a9d4959e8d5713eebb44","tokens":665,"chars":2658,"crawler":"crawler-f6nn","verified":"exact","ts":1791171722320,"text":"Arbitrum\nProposals\nFinalized AIPs\nTopic\nReplies\nViews\nActivity\nAbout the Finalized AIPs category\n0\n405\nJanuary 23, 2023\n[Constitutional] AIP: Transition Arbitrum One ordering policy to Priority Gas Auctions (PGA)\n30\n2149\nOctober 1, 2026\n[Constitutional] AIP Fast Feed\n22\n999\nSeptember 22, 2026\nBanning projects identified in the high-severity Watchdog Program cases\n11\n394\nSeptember 21, 2026\nArbitrum Security Program\n20\n573\nSeptember 13, 2026\n[Constitutional] AIP: Ratification of Security Council Election Process Improvements\n27\n640\nSeptember 1, 2026\nEntropy Advisors: Exclusively Working With Arbitrum DAO\nproposal\n86\n3854\nAugust 25, 2026\nTransfer 6,000 ETH and Idle Stablecoins from the Treasury to the Treasury Management Portfolio\n27\n938\nAugust 12, 2026\nArbitrum Audit Program\n128\n4558\nAugust 3, 2026\n[Constitutional] AIP: ArbOS 61 Elara\n30\n1437\nJuly 30, 2026\nProposed Amendment to the Code of Conduct: AI tools and Responsible Participation Policy\n4\n123\nJuly 20, 2026\nContinued Funding for the Arbitrum Foundation\n37\n2048\nJuly 15, 2026\nAGV Wind-Down: Structured Transition & Return of Capital to the DAO Treasury\n16\n769\nJuly 7, 2026\nExtending DRIP's Mandate\n14\n405\nJune 26, 2026\n[Constitutional] AIP: Approve Release of Frozen ETH\n53\n7272\nJune 15, 2026\n[RFC] Proposal to Adjust the Voting Power of the Arbitrum Community Pool & Ratifying the Agentic Governance Pivot\ndelegation\n,\nproposal\n,\nproposal-discussions\n65\n1655\nJune 14, 2026\n[Constitutional] AIP: Minimize Arbitrum Nova\n21\n809\nJune 9, 2026\nImprovements to the Arbitrum Audit Program\n13\n512\nApril 24, 2026\n[Constitutional] DVP Quorum for ArbitrumDAO: Implementation & Parameters\n52\n1755\nApril 24, 2026\nUpdating the Code of Conduct & DAO Procedures to Become Living Documents\n12\n395\nApril 14, 2026\nAutomate the Consolidation of Idle Funds into the Treasury Management Portfolio\n21\n725\nMarch 26, 2026\nChange to New Governance Contracts that Allow Proposal Cancellation\n51\n1728\nFebruary 28, 2026\n[Constitutional] AIP: Security Council Election Process Improvements [OLD]\n68\n2233\nFebruary 17, 2026\nResearch on context and retention\nproposal\n74\n1336\nFebruary 16, 2026\nUpdating the Code of Conduct & DAO's Procedures\n37\n1382\nFebruary 9, 2026\nRewarding Active Delegates (RAD) Program\n46\n2295\nJanuary 29, 2026\n[Non-Constitutional] [RFC] Arbitrum D.A.O. (Domain Allocator Offerings) Grant Program - Season 3\n157\n4410\nJanuary 13, 2026\nAIP: Raise the gas target, min L2 base fee, & implement improvements to the pricing algorithm\n33\n2175\nDecember 21, 2025\n[CONSTITUTIONAL] AIP: ArbOS Version 50 Dia\nproposal\n38\n1780\nDecember 18, 2025\n[Constitutional] AIP: DVP Quorum\n21\n897\nDecember 12, 2025\nnext page →"}
{"url":"https://docs.jup.ag/user-docs/launch/studio","domain":"docs.jup.ag","title":"Jupiter Studio Overview - Jupiter Documentation","hash":"455f2ccdc34e821d6f9c4216e0ec109fa14c11056cb1e29333e0fdb0cbada273","tokens":964,"chars":3855,"crawler":"crawler-f6nn","verified":"exact","ts":1791171725047,"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\nJupiter Studio\nJupiter Studio Overview\nWhat Jupiter Studio is, who it’s for, and how it works.\nJupiter Studio is a token launch tool built into the Jupiter ecosystem. It lets anyone create a token on Solana and launch it on a (a pricing mechanism where the price adjusts automatically based on buys and sells), without providing initial liquidity. Once the token reaches a threshold, its liquidity migrates to a Meteora pool, where it continues to trade.\nWho Studio is for\nStudio is for creators launching community tokens on Solana (memes, project tokens, collectibles). There are two launch modes:\n- Meme mode : a preconfigured setup for a quick launch.\n- Custom mode : adjustable parameters for the quote token, market caps, anti-sniping, and creator vesting.\nNo coding knowledge or initial liquidity is required.\nCreator earnings\nStudio creators earn fees throughout the lifetime of their token, both on the bonding curve and on the Meteora pool after graduation.\nSource Amount When\nTrading fees 50% of the 1% fee charged on every buy and sell Lifetime of the token, before and after graduation\nAnti-sniper fees 100% of the additional fee charged during the first 15 to 60 seconds after launch Once at launch\nCreator earnings depend on trading volume. There is no guarantee that a token will graduate or generate fees.\nIn addition to fees, Custom mode lets creators allocate up to 80% of token supply to themselves, subject to a vesting schedule. See Launching a Token for the full set of vesting parameters.\nFor details on how fees are charged and claimed, see Graduation and Fees .\nCore concepts\nToken supply\nEvery token launched through Studio has a fixed supply of 1,000,000,000 (1 billion) tokens. This is not configurable.\nBonding curve\nA bonding curve is a smart contract that sets the token price according to a mathematical formula. Studio uses a constant product curve (xy=k, same model as Uniswap v2). When a user buys, the price increases along the curve. When a user sells, the price decreases.\nBuying and selling can happen freely at any time before graduation. No initial liquidity deposit is required from the creator. Capital enters the curve as users buy in.\nGraduation\nGraduation is the moment a token moves from the Studio bonding curve to a Meteora liquidity pool. After graduation, the token trades on Meteora instead of the bonding curve.\nIt is triggered when the bonding curve has raised enough (the token used to buy on the curve, either SOL or USDC) to meet the graduation threshold. The minimum amount raised to graduate is 15,000 USDC (or equivalent in SOL).\nWhen graduation triggers:\n- The quote tokens raised on the curve are migrated to a Meteora pool (Dynamic Automated Market Maker v2, a constant product liquidity pool on Meteora).\n- The corresponding share of tokens is paired with the raised capital in the pool.\n- All LP tokens from this pool are permanently locked. No one can withdraw liquidity from the graduated pool.\nToken page\nEach Studio token gets a dedicated page where the creator can post content, share updates, and claim earned fees.\nEcosystem visibility\nEvery token launched through Studio automatically appears on Alphascan (within Jup Pro) and is flagged as a Studio token.\nIf a token has no trading activity, it may temporarily fall off Alphascan. It reappears when new trades occur.\nNext steps\nLaunch a token\nModes, configuration, and anti-sniper protection.\nGraduation and fees\nWhat happens after graduation, how fees work, and how to claim them.\nStudio FAQ\nCommon questions about launching and trading tokens on Jupiter Studio.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.anza.xyz/cli/wallets/file-system","domain":"docs.anza.xyz","title":"File System Wallets using the CLI | Agave","hash":"c0225ac7f8e888cd0bd33b48bc8125de5778c7272b41c1b18c376b4bb1361cac","tokens":563,"chars":2250,"crawler":"crawler-f6nn","verified":"exact","ts":1791171727246,"text":"Skip to main content\nFile System Wallets using the CLI\nThis document describes how to create and use a file system wallet with the\nSolana CLI tools. A file system wallet exists as an unencrypted keypair file\non your computer system's filesystem.\nFile system wallets are the least secure method of storing SOL tokens. Storing large amounts of tokens in a file system wallet is not recommended .\nBefore you Begin\nMake sure you have\ninstalled the Solana Command Line Tools\nGenerate a File System Wallet Keypair\nUse Solana's command-line tool solana-keygen to generate keypair files. For\nexample, run the following from a command-line shell:\nmkdir ~/my-solana-wallet\nsolana-keygen new --outfile ~/my-solana-wallet/my-keypair.json\nThis file contains your unencrypted keypair. In fact, even if you specify\na password, that password applies to the recovery seed phrase, not the file. Do\nnot share this file with others. Anyone with access to this file will have access\nto all tokens sent to its public key. Instead, you should share only its public\nkey. To display its public key, run:\nsolana-keygen pubkey ~/my-solana-wallet/my-keypair.json\nIt will output a string of characters, such as:\nErRr1caKzK8L8nn4xmEWtimYRiTCAZXjBtVphuZ5vMKy\nThis is the public key corresponding to the keypair in\n~/my-solana-wallet/my-keypair.json . The public key of the keypair file is\nyour wallet address .\nVerify your Address against your Keypair file\nTo verify you hold the private key for a given address, use\nsolana-keygen verify :\nsolana-keygen verify ~/my-solana-wallet/my-keypair.json\nwhere is replaced with your wallet address.\nThe command will output \"Success\" if the given address matches the\none in your keypair file, and \"Failed\" otherwise.\nCreating Multiple File System Wallet Addresses\nYou can create as many wallet addresses as you like. Simply re-run the\nsteps in Generate a File System Wallet\nand make sure to use a new filename or path with the --outfile argument.\nMultiple wallet addresses can be useful if you want to transfer tokens between\nyour own accounts for different purposes.\n- Before you Begin\n- Generate a File System Wallet Keypair\n- Verify your Address against your Keypair file\n- Creating Multiple File System Wallet Addresses"}
{"url":"https://docs.sei.io/","domain":"docs.sei.io","title":"Home - Sei Docs","hash":"bb9d6a13b6e10b17c22d850ffd59ebbd9a5a067e7a42d2594eb77e6ba6e9e81f","tokens":683,"chars":2729,"crawler":"crawler-f6nn","verified":"exact","ts":1791171729634,"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\nHome\nSei documentation: guides, references, and tutorials for building on the Sei EVM and ecosystem.\nSei is the first parallelized EVM blockchain, built for scalability and speed.\nQuick start\nDeploy a smart contract\nDeploy EVM contracts with parallelized execution.\nBuild a frontend\nCreate dApps that use Sei’s fast finality.\nScaffold with create-sei\nSet up a full-stack Sei project in seconds.\nVerify contracts\nVerify and publish your contract source code.\nEVM compatibility\nviem, ethers, ERC-20, ERC-721, pointer contracts, and differences in Sei behavior.\nEssential resources\nChain info\nRPC URLs and chain IDs\nFaucet\nSei Testnet tokens\nBlock explorers\nInspect transactions\nWallets\nSupported wallets\nRPC providers\nInfrastructure partners\nGas and fees\nPricing and optimization\nEcosystem & integrations\nSei Global Wallet\nOnboard users from any chain with a single wallet.\nBuild with AI\nsei-skill, MCP Server, and agent frameworks for AI-powered development on Sei.\nTokens\nView and manage SEI, ERC-20, and ERC-721 tokens in wallets.\nIndexers\nQuery on-chain data with Goldsky, The Graph, and other indexers.\nOracles\nChainlink, Pyth, RedStone, and API3 price feeds.\nUSDC and payments\nFast, low-fee payments with immediate finality.\nx402 micropayments\nMonetize APIs with HTTP-native payments.\nIn-app swaps\nEmbed token swaps directly in your dApp.\nMigrate to Sei\nSei vs Ethereum\nThe main differences to know.\nFrom other EVMs\nMigrate existing EVM dApps.\nFrom Solana\nMove from Solana to Sei.\nLearn\nSei Giga architecture\nNext-generation design for gigagas execution bandwidth.\nTwin Turbo Consensus\nSub-second finality and fast block production.\nParallelization engine\nOptimistic, multi-core transaction execution.\nSeiDB\nState access optimized for high throughput.\nGovernance\nOverview of proposals, voting, and staking.\nInteroperability\nEVM and CosmWasm cross-VM communication.\nSmart contracts\nDeploy and debug on Sei\nWrite, deploy, and debug Solidity smart contracts with your preferred toolchain. Sei is fully EVM-compatible, with 400 ms blocks and parallelized execution.\nHardhat\nFoundry\nDebug tracing\nBest practices\nInfrastructure & tools\nRun a node\nParticipate in the Sei network.\n- Full node\n- Validator node\nPrecompiles\nAccess native Sei features from Solidity contracts.\nSolidity resources\nLibraries, tools, and learning materials.\nEcosystem contracts\nAddresses of the main contracts deployed on Sei.\nNetwork information\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://aptos.dev/","domain":"aptos.dev","title":"","hash":"8915241adfd83bd0e8322af9af869e258b847034acc1ad56850af2369c54ac31","tokens":602,"chars":2405,"crawler":"crawler-f6nn","verified":"exact","ts":1791171731870,"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://ethereum.org/what-is-ethereum/","domain":"ethereum.org","title":"What is Ethereum? (A Complete Guide) | ethereum.org","hash":"a4a85781cc04804d90064380f6e9d85c83c93ba91caa68877abd7d2dc7bc3834","tokens":4410,"chars":17640,"crawler":"crawler-f6nn","verified":"exact","ts":1791171734442,"text":"Skip to main content\nWhat is Ethereum?\nEthereum is a decentralized blockchain network and software development platform, powered by the cryptocurrency ether (ETH).\nIt's home to thousands of cryptocurrencies and applications across DeFi, NFTs, gaming, decentralized social media and stablecoins.\nEthereum is an open, public blockchain launched in July 2015 by a software developer called Vitalik Buterin and a small team of co-founders.\nThe idea behind Ethereum was simple. While Bitcoin lets you send and receive digital cash, Ethereum would build on this with open-source programs called smart contracts .\nSmart contracts let anyone create their own digital assets and decentralized applications (dapps) that run 24/7, globally. And unlike banks, corporations or other institutions, smart contracts are available to anyone with an internet connection.\nSince 2015, Ethereum has grown into a thriving ecosystem of digital assets like stablecoins , non-fungible tokens ( NFTs ), and governance tokens, as well as a sprawling world of dapps for decentralized finance ( DeFi ), art and collectibles, gaming and decentralized social media.\nCollectively, this ecosystem is called \" web3 \", representing the third phase of the internet centered around ownership .\nToday, Ethereum is used by millions of people (opens in a new tab) around the world holding billions of dollars (opens in a new tab) in assets who send and receive trillions of dollars (opens in a new tab) every year—all without a bank.\nAt the heart of all this is Ethereum's native cryptocurrency ether (ETH) , a new kind of digital money used to power the whole network.\nWhat is the Ethereum network?\nYou can think of the ethereum network as a global digital infrastructure that anyone can use but nobody can abuse.\nThe network is made up of thousands of independent computers around the world called nodes. These nodes, run by regular people, work together to provide financial services and digital applications to anyone, anywhere.\nThe Ethereum network has 3 key advantages over traditional networks owned by institutions. These are censorship resistance, enhanced security and improved reliability.\nCensorship resistant\nWhile traditional apps and financial services rely on banks or corporations that can decide to block access or freeze accounts, dapps on Ethereum are censorship resistant.\nThis is because ethereum's network of nodes record every single transaction without discrimination—and this rule is embedded in the code.\nHighly secure\nWhile many apps today are hosted on cloud providers like AWS and can be vulnerable to takedowns and attacks, dapps on Ethereum are secured by the network itself. Every node stores and syncs the entire state of Ethereum, including all contracts.\nIf someone tried to change a contract, the network would reject it since it wouldn't match their records. To take down a single app, attackers need to take over the entire network, which would cost billions and be extremely hard to coordinate.\nDurable and reliable\nDowntime on cloud hosting platforms can take apps offline, but Ethereum's design ensures perfect uptime. The network will keep running even if some nodes go offline due to software bugs, government crackdowns, natural disaster, or war.\nMillions of people use thousands of dapps on Ethereum every day. While high demand can lead to elevated transaction fees, it reflects the strength of a network that prioritizes security, decentralization, and the guarantee that it's always available when you need it.\nEthereum extensions (Layer 2)\nDifferent teams have created Layer 2 (L2) networks that run on top of Ethereum to increase Ethereum's capacity. L2s act like express lanes, making transactions faster and cheaper—sometimes costing less than a cent on average.\nSome of the most popular L2s including Optimism (opens in a new tab) , Arbitrum (opens in a new tab) , ZKSync (opens in a new tab) , and Base (opens in a new tab) now process millions of transactions worth billions of dollars each year.\nLearn more about the Ethereum network\nWhat is ether (ETH)?\nEther (ETH) is the native cryptocurrency of Ethereum.\nIt's a new kind of digital money you can send to anyone, anywhere in the world in seconds for as little as a few cents. But ETH is about more than just payments. It plays a vital role in keeping the Ethereum network running.\nWhen you use Ethereum to send money, collect art or build a new dapp, you pay a small transaction fee (or gas fee) in ETH . This fee helps prevent spam and rewards the people called validators who process transactions.\nThese validators help secure the ethereum network through a system called staking. By locking up their ETH they're eligible to process transactions. In return, they earn ETH as a reward. This gives Ethereum its own self-sustaining economy, powered by users rather than companies.\nUnlike many traditional currencies, ETH can become more scarce over time . Every time someone uses Ethereum, a small portion of ETH is burned, which permanently removes it from the supply. On busy days, more ETH is burned than created, making ETH deflationary and increasing its value over time. The more Ethereum is used, the more ETH is burned.\nBecause of this, many people see ETH as an investment and choose to hold, stake or lend it to grow their savings.\nLearn more about ether (ETH)\nHow does Ethereum work?\nWhen Ethereum launched in 2015 , it used a system called proof of work.\nThis mechanism, pioneered by Bitcoin, is how all computers agreed on who owns what. Computers would use a lot of energy trying to solve a complex mathematical puzzle. The winner would get to propose a block of incoming transactions and earn new ETH.\nIn 2022, Ethereum upgraded to a new system called proof of stake that's 99% more energy efficient . Instead of mathematical puzzles, validators lock their ETH as a security deposit to earn the right to process transactions.\nIf they do it correctly, they earn ETH. If they cheat, they lose some of their stake.\nHere's an example:\nWhen you send $10 in stablecoins to a friend on Ethereum:\n- You open your wallet, add the account address to send to and the amount, then click send.\n- Your wallet signs the payment and broadcasts it to the network.\n- The payment waits in the public queue (mempool) until a block proposer picks it.\n- The block proposer adds it to the next block of transactions, broadcasts it, and earns a fee.\n- The stablecoin contract moves $10 from you to your friend, and both wallets update.\n- A global network of validators double-check and attest to the validity of the changes.\nWhen you mint a $5 collectible on Ethereum:\n- You connect your wallet to the dapp and choose the item to mint.\n- You confirm the purchase; the wallet signs and broadcasts the transaction.\n- The mint request joins the mempool and is added to a block by a validator.\n- The NFT smart contract records your wallet as the new owner.\n- Your new collectible appears in your wallet a few seconds later.\nThis is all possible thanks to the power of smart contracts; open-source programs that live on Ethereum and run 24/7, 365 accessible to anyone, anywhere.\nEvery transaction, update, and action is synced across thousands of independent nodes. This gives Ethereum its reliability, transparency, and censorship resistance.\nLearn more about how Ethereum works Read developer docs for a technical overview of Ethereum\nWhat is Ethereum used for?\nPeople use Ethereum to do things that weren't possible before.\nFarmers in Kenya can receive automated insurance on their crops (opens in a new tab) without applying to a bank. Businesses like Visa can launch new payment systems that works globally (opens in a new tab) from day one. Global organizations like the UN can deliver aid to refugees (opens in a new tab) saving millions in bank fees.\nThese dapps and assets run on Ethereum using open-source code and can't be restricted, censored or turned off.\nHere's how different groups are using it today:\nConsumers\nMillions of people already use dapps on Ethereum to move money, trade, and own digital assets every day. Unlike traditional apps, there's no need to register with your name, wait for a bank to approve you, or hand over your personal data.\nWith just a wallet and an internet connection you can:\n- Access financial services without a bank account or credit history\n- Own digital collectibles , art, and assets that can't be copied or confiscated\n- Sign into dapps using your wallet, not your email— no passwords, no personal information necessary\n- Participate in global communities where you can vote, contribute, and earn borderlessly\nBusinesses & developers\n- Launch dapps with built-in global payments system from day one\n- Deploy tamper-proof contracts that automatically enforce agreements\n- Create financial products that anyone can build on and drive value to\nFor example, PayPal launched its own stablecoin, PYUSD, on Ethereum (opens in a new tab) . This is a sign that even the world's largest payments companies see the benefit of Ethereum's open and programmable nature.\nGovernments\nGovernments are also starting to explore what Ethereum makes possible.\n- Distribute public funds and benefits directly to citizens with full transparency\n- Issue digital IDs or records that are verifiable and portable across borders\n- Build tamper-proof public infrastructure for voting , land titles, and registries\nIn another case, Ukraine's Ministry of Digital Transformation used Ethereum to distribute wartime aid (opens in a new tab) .\nFunds were sent directly to citizens and NGOs using open smart contracts, providing transparency, speed, and accountability during a crisis.\nHow to start using Ethereum\nGetting started with Ethereum is easier than you might think.\nYou don't need permission. You don't need a bank or even an ID document. All you need to get started is a device and an internet connection.\nFor individuals\nThe first step is downloading a wallet.\nPopular wallets like Zerion (opens in a new tab) , Rainbow (opens in a new tab) , and Coinbase Wallet (opens in a new tab) are free and easy to use. Once your wallet is set up, you can:\n- Buy a small amount of ETH on an exchange or directly inside some wallets\n- Use that ETH to pay for transactions like sending tokens or collecting NFTs\n- Explore dapps like Zora (opens in a new tab) , Uniswap (opens in a new tab) , or Farcaster (opens in a new tab) —no new logins or approvals needed\nThese priorities will help ensure Ethereum is secure, scalable and user friendly as more people rely on the network everyday.\nThese dapps run in your browser and work with your wallet instantly. You can start using Ethereum in minutes.\nStart here See apps\nFor developers\nEthereum is a playground for developers. You can start building without permission, approvals, or even real money.\nThe Ethereum Developer Docs walk you through everything from writing your first smart contract to deploying on test networks like Sepolia.\nYou can build full-stack dapps with tools like Hardhat (opens in a new tab) , Foundry (opens in a new tab) , and Ethers.js (opens in a new tab) , or experiment with low-code platforms like thirdweb (opens in a new tab) or Moralis (opens in a new tab) .\nEverything is open-source and composable, so you can remix and build on what's already out there without asking for permission.\nStart building on Ethereum\nUse Ethereum in business\nEnterprises are already using Ethereum to power new infrastructure.\nMany enterprises are starting with L2 networks like Optimism and Base to support high-volume use cases. These networks offer lower fees, faster speeds while still benefiting from Ethereum's security and removing counterparty risk.\nYou can:\n- Launch modular loyalty programs that boost retention and cut third-party costs\n- Tokenize assets like tickets, coupons, or certificates to reduce fraud and resale risk\n- Enable instant global payments to lower transaction fees and unlock new markets\nFor example, in 2025, Shopify launched on Base (opens in a new tab) to allow consumers to spend stablecoins with millions of merchants around the globe.\nUse Ethereum in business (opens in a new tab)\nWhat's the difference between Ethereum and Bitcoin?\nBitcoin and Ethereum are the two biggest cryptocurrencies in the world.\nThey both let you send money without a bank, both run on blockchain technology, and both are open to anyone . But that's where the similarities end.\nBitcoin is like digital gold.\nIt has a fixed supply of 21 million coins, a narrow focus on peer-to-peer payments, and a basic scripting language that limits what you can build with it. This simplicity is by design since Bitcoin prioritizes predictability, durability, and long-term security over flexibility.\nEthereum takes a broader approach.\nIt's not just money, it's programmable infrastructure. Instead of just sending and receiving value, Ethereum lets developers build entire applications. You've already seen this in action: from lending markets and stablecoins to collectibles, social media, and real-time payments—all powered by smart contracts and secured by ETH.\nThe way the networks reach consensus is also different.\nBitcoin uses miners to secure the network. These are powerful computers that compete to solve complex puzzle, and the winner gets to add the next block of transactions to the chain and claim bitcoins as a reward. This process is called mining and it uses large amounts of electricity.\nEthereum used to work like this too. But in 2022, it transitioned from proof of work to proof of stake. Today, transactions are confirmed by validators who lock up ETH as collateral. Honest validators earn ETH rewards while any dishonest ones lose part of their stake. This shift made Ethereum over 99.988% more energy efficient without sacrificing security or decentralization.\nThere's also a difference in how supply is handled.\nBitcoin has a fixed supply. There will only ever be 21 million coins. Ethereum, on the other hand, has a dynamic supply. New ETH is issued to reward validators, while a portion is burned with every transaction. This means Ethereum can't just \"print infinite ETH.\"\nThe issuance rate is limited by how much ETH is staked. As more ETH is staked, individual rewards decrease, creating a natural balance. This design ensures a sustainable security budget well into the future, without relying solely on transaction fees.\nIn short, Bitcoin is a tool for sending value. Ethereum is a platform for building it.\nLearn more about the difference between Ethereum and Bitcoin\nWhen did Ethereum launch, who founded it and who runs it now?\nFrom the start, Ethereum was designed to run by its community.\nIn 2013, Vitalik Buterin published a white paper proposing a new kind of blockchain for money and apps anyone could use. The idea quickly gained traction.\nBy 2014, co-founders like Gavin Wood and Joseph Lubin joined the effort, and the team raised funds through one of the earliest crypto crowdfunding campaigns.\nEthereum officially launched in July 2015.\nKey moments in Ethereum's history\n- 2013: 19-year-old Vitalik Buterin publishes the Ethereum whitepaper\n- 2014: The Ethereum Foundation forms and launches a crowdfunding campaign\n- 2015: Developers launch the Ethereum network with the Frontier release\n- 2016: Smart contract exploit drains $60M (3.6M ETH) from The DAO prompting a chain fork\n- 2020: Beacon Chain launch starts the move to Proof-of-Stake\n- 2021: London upgrade starts burning gas fees via EIP-1559\n- 2022: The Merge replaces mining with staking, cutting energy use by 99%\n- 2025: Pectra upgrade improves smart wallet support and L2 compatibility\nToday, no single person or company runs Ethereum.\nThe network is maintained by a broad group of contributors:\n- Developers who write and propose upgrades\n- Node operators contributing to distributed physical infrastructure\n- Stakers who validate transactions\n- Community members who build the tools and culture\n- You by using the network\nThere's no CEO, board, or central authority. The Ethereum Foundation still helps fund research and development, but the ecosystem runs on open participation.\nChanges are proposed through Ethereum Improvement Proposals (EIPs) (opens in a new tab) , discussed publicly, and only adopted if the wider community supports them .\nThis makes Ethereum slower to change than a startup, but also much harder to shut down or take over.\nLearn more about Ethereum's history\nWhat is the Ethereum roadmap for 2026?\nEthereum doesn't follow a fixed roadmap. It follows a shared vision.\nNetwork upgrades are made as EIPs and developed in public by contributors around the world. There's no central team deciding what happens, just people building what they believe is useful based on users' needs.\nFusaka is the most recent upgrade, launched in December 2025. It introduced PeerDAS for more efficient L2 data availability and raised the default gas limit to ~60M. Looking ahead to 2026, Glamsterdam is in development and expected in Q4 2026.\nLooking ahead (opens in a new tab) , Ethereum's priorities include:\n- Making the core protocol and its L2s faster and cheaper for everyone\n- Improving the experience for users and developers\nThese priorities will help ensure Ethereum is secure, scalable and user friendly as more people rely on the network everyday.\nIf you want to steer the direction for Ethereum, get involved . You don't need permission, just the desire to make a difference in this new digital economy.\nSee an overview of the Ethereum roadmap\nRead next\n-\nWhat are wallets?\n-\nWhat is ether (ETH)?\n-\nWhat is web3?\n-\nLearn more about the Ethereum network\nTest your Ethereum knowledge"}
{"url":"https://wormhole.com/docs/products/token-transfers/native-token-transfers/configuration/rate-limiting/","domain":"wormhole.com","title":"Native Token Transfers Rate Limiting | Wormhole Docs","hash":"b773ddc779643cb7bc68dbe93680d1decaaf497498393e01ac27231495350809","tokens":1186,"chars":4742,"crawler":"crawler-f6nn","verified":"exact","ts":1791171737335,"text":"Skip to content\nInitializing 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\nRate Limiting ＃\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nThe Native Token Transfer (NTT) framework provides configurable per-chain rate limits for sending and receiving token transfers. Integrators can manage these limits via their own governance processes to quickly adapt to on-chain activity.\nIf a transfer is rate-limited on the source chain and queueing is enabled via shouldQueue = true , the transfer is placed into an outbound queue and can be released after the rate limit expires.\nYou can configure the following limits on every chain where NTT is deployed directly using the manager:\n- Sending limit : A single outbound limit for sending tokens from the chain.\n- Per-chain receiving limits : The maximum receiving limit, which can be configured on a per-chain basis. For example, allowing 100 tokens to be received from Ethereum but only 50 tokens to be received from Arbitrum.\nRate limits are replenished every second over a fixed duration. While the default duration is 24 hours, the value is configurable at contract creation. Rate-limited transfers on the destination chain are added to an inbound queue with a similar release delay.\nUpdate Rate Limits ＃\nTo configure or update the sending and receiving rate limits, follow these steps:\n-\nLocate the deployment file : Open the deployment.json file in your NTT project directory. This file contains the configuration for your deployed contracts.\n-\nModify the limits section : For each chain, locate the limits field and update the outbound and inbound values as needed.\n\"limits\" : {\n\"outbound\" : \"1000.000000000000000000\" ,\n\"inbound\" : {\n\"Ethereum\" : \"100.000000000000000000\" ,\n\"Arbitrum\" : \"50.000000000000000000\"\n}\n- outbound : Sets the maximum tokens allowed to leave the chain.\n- inbound : Configures per-chain receiving limits for tokens arriving from specific chains.\n-\nPush the configuration : Use the NTT CLI to synchronize the updated configuration with the blockchain.\nntt push\n-\nVerify the changes : After pushing, confirm the new rate limits by checking the deployment status.\nntt status\ndeployment.json example\n{\n\"network\" : \"Testnet\" ,\n\"chains\" : {\n\"Sepolia\" : {\n\"version\" : \"1.1.0\" ,\n\"mode\" : \"burning\" ,\n\"paused\" : false ,\n\"owner\" : \"0x0088DFAC40029f266e0FF62B82E47A07467A0345\" ,\n\"manager\" : \"0x5592809cf5352a882Ad5E9d435C6B7355B716357\" ,\n\"token\" : \"0x5CF5D6f366eEa7123BeECec1B7c44B2493569995\" ,\n\"transceivers\" : {\n\"threshold\" : 1 ,\n\"wormhole\" : {\n\"address\" : \"0x91D4E9629545129D427Fd416860696a9659AD6a1\" ,\n\"pauser\" : \"0x0088DFAC40029f266e0FF62B82E47A07467A0345\"\n}\n},\n\"limits\" : {\n\"outbound\" : \"184467440737.095516150000000000\" ,\n\"inbound\" : {\n\"ArbitrumSepolia\" : \"500.000000000000000000\"\n}\n},\n\"pauser\" : \"0x0088DFAC40029f266e0FF62B82E47A07467A0345\"\n}\nQueuing Mechanism ＃\nWhen a transfer exceeds the rate limit, it is held in a queue and can be released after the set rate limit duration has expired. The sending and receiving queuing behavior is as follows:\n- Sending : If an outbound transfer violates rate limits, users can either revert and try again later or queue their transfer. Users must return after the queue duration has expired to complete sending their transfer.\n- Receiving : If an inbound transfer violates rate limits, it is in a queue. Users or relayers must return after the queue duration has expired to complete receiving their transfer on the destination chain.\nQueuing is configured dynamically during each transfer by passing the shouldQueue parameter to the transfer function in the NttManager contract.\nCancel Flows ＃\nIf users bridge frequently between a given source chain and destination chain, the capacity could be exhausted quickly. Loss of capacity can leave other users rate-limited, potentially delaying their transfers. The outbound transfer cancels the inbound rate limit on the source chain to avoid unintentional delays. This allows for refilling the inbound rate limit by an amount equal to the outbound transfer amount and vice-versa, with the inbound transfer canceling the outbound rate limit on the destination chain and refilling the outbound rate limit with an amount.\nLast update: September 28, 2026\n| Created: September 28, 2026"}
{"url":"https://docs.ens.domains/resolvers/writing","domain":"docs.ens.domains","title":"Writing a Resolver | ENS Docs","hash":"200da5c65c1da6325e375aeaf3ea0221da281805d4ea8f12324759009fac46f2","tokens":1132,"chars":4528,"crawler":"crawler-f6nn","verified":"exact","ts":1791171739477,"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\nWriting a Resolver\nEvery ENS name has a resolver, which is responsible for resolving information about a name.\nResolvers are a core part of the ENS protocol. They give each name, represented as a \"node\" , the power to control the resolution process for itself and all of its subnames. Resolvers were originally standardized in EIP 137 , but have since received a few updates such as EIP 181 , EIP 2304 , and ENSIP-10 .\nYou can find the latest default resolver implementation, called the Public Resolver, on GitHub and Etherscan .\nResolver Interface\nYou can view an extended list of resolver methods here , however a simple interface might look something like this:\ninterface IMyResolver {\nfunction supportsInterface ( bytes4 interfaceId ) external view returns ( bool );\nfunction addr ( bytes32 node ) external view returns ( address payable );\nfunction addr ( bytes32 node , uint256 coinType ) external view returns ( bytes memory );\nfunction contenthash ( bytes32 node ) external view returns ( bytes memory );\nfunction text ( bytes32 node , string calldata key ) external view returns ( string memory );\nfunction setAddr ( bytes32 node , address addr ) external ;\nfunction setAddr ( bytes32 node , uint256 coinType , bytes calldata a ) external ;\nfunction setContenthash ( bytes32 node , bytes calldata hash ) external ;\nfunction setText ( bytes32 node , string calldata key , string calldata value ) external ;\n}\nWildcard Resolution\nIn ENSIP-10 a new resolve() method was added to the resolver interface to allow for wildcard resolution.\ninterface IExtendedResolver {\n/**\n* @dev Performs ENS name resolution for the supplied name and resolution data.\n* @param name The name to resolve, in normalised and DNS-encoded form.\n* @param data The resolution data, as specified in ENSIP-10.\n* @return The result of resolving the name.\n*/\nfunction resolve (\nbytes memory name ,\nbytes memory data\n) external view returns ( bytes memory );\n}\nOnchain Resolvers\nBy default, ENS names use the Public Resolver which stores all data onchain. An extremely basic resolver that stores a mapping of ENS names to addresses might look like this:\ncontract OnchainResolver {\nmapping ( bytes32 node => address addr) public addr;\nfunction setAddr ( bytes32 node , address _addr) external {\naddr[node] = _addr;\n}\nfunction supportsInterface (\nbytes4 interfaceID\n) external pure returns ( bool ) {\nreturn\ninterfaceID == OnchainResolver.supportsInterface.selector ||\n// function addr(bytes32 node) external view returns (address)\ninterfaceID == 0x3b3b57de ;\n}\nSince the mapping is stored internally, it costs gas for the owner of a name to update their address. This is great for a maximal decentralization, but is not always practical.\nOffchain Resolvers\nAn offchain resolver is a resolver that implements CCIP Read to defer a name's resolution to an HTTP server. This server can then load data from any source including offchain databases, APIs, or other blockchains. Learn more about CCIP Read .\nAn equivalent offchain resolver to the above onchain example looks something like this:\ncontract OffchainResolver {\nstring public url =\n\"https://docs.ens.domains/api/example/basic-gateway\" ;\nerror OffchainLookup (\naddress sender,\nstring [] urls,\nbytes callData,\nbytes4 callbackFunction,\nbytes extraData\n);\nfunction addr ( bytes32 node ) external view returns ( address ) {\nbytes memory callData = abi . encodeWithSelector (\nOffchainResolver.addr.selector,\nnode\n);\nstring [] memory urls = new string []( 1 );\nurls[ 0 ] = url;\nrevert OffchainLookup (\naddress ( this ),\nurls,\ncallData,\nOffchainResolver.addrCallback.selector,\nabi . encode (callData, address ( this ))\n);\n}\nfunction addrCallback (\nbytes calldata response ,\nbytes calldata\n) external pure returns ( address ) {\naddress _addr = abi . decode (response, ( address ));\nreturn _addr;\n}\nfunction supportsInterface (\nbytes4 interfaceID\n) external pure returns ( bool ) {\nreturn\ninterfaceID == OffchainResolver.supportsInterface.selector ||\ninterfaceID == OffchainResolver.addr.selector;\n}\nAny ENS name that sets its resolver to this contract would resolve to whatever address the Gateway returns, which can be changed at any time offchain for free. See the gateway code here .\nFor the same functionality to work with subnames, you'd need to implement the resolve() method from ENSIP-10. A feature-complete example can be found here , and easily deployed via https://ccip-tools.pages.dev ."}
{"url":"https://solana.com/docs/core/accounts","domain":"solana.com","title":"","hash":"aa0c37ebffb266d1ca09d7b54f294929708c85141bcd42f6b712b58055ca53c5","tokens":821,"chars":3281,"crawler":"crawler-f6nn","verified":"exact","ts":1791171741720,"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.berachain.com/","domain":"docs.berachain.com","title":"Introduction - Berachain","hash":"2c28bfb83848ae5d41fbbd654612e955ec8fa5b1d96dafa34cd65b733d3654ab","tokens":273,"chars":1091,"crawler":"crawler-f6nn","verified":"exact","ts":1791171744189,"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://governance.aave.com/","domain":"governance.aave.com","title":"Aave - Governance Forum","hash":"0cc66ea2a053fb2672f03b1838533eee9e10e94a0d712bbcffec03320d51bd3b","tokens":679,"chars":2715,"crawler":"crawler-f6nn","verified":"exact","ts":1791171746419,"text":"Aave\nGovernance forum for Aave protocol discussion.\nTopic\nReplies\nViews\nActivity\n[ARFC] Deploy Aave V4 on the Monad Network\nNew Market\n2\n343\nOctober 5, 2026\n[ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\nNew Market\n3\n695\nOctober 5, 2026\nRisk Stewards: Supply and Borrow Cap Reductions on Aave V3 / 2026.08.10\nRisk\n3\n186\nOctober 4, 2026\n[ARFC] The Aave Foundation, Phase 1\nGovernance\n2\n864\nOctober 4, 2026\n[Discussion] A second, issuer-controlled verifier for cross-chain GHO on CCIP 2.0\nGovernance\n0\n45\nOctober 4, 2026\nTokenLogic Delegate Platform\nDelegate Platforms\n38\n6665\nOctober 4, 2026\n[ARFC] Onboard wstLINK to Aave V3 Core Instance\nNew Asset\n15\n3068\nOctober 4, 2026\n[Question] Any idea what happened here?\nFinance\n4\n215\nOctober 3, 2026\n[GHO Stewards] October 2026 - GHO Borrow Rate Update\nGovernance\n0\n136\nOctober 2, 2026\nAave Chan Initiative Delegate platform\nDelegate Platforms\n43\n13835\nOctober 2, 2026\n[ARFC] Aave Institutional\nGovernance\n7\n516\nOctober 2, 2026\n[Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\nNew Asset\n1\n119\nOctober 2, 2026\nRisk Stewards: Cap and IRM Changes on Aave V3 / 2026.10.01\nRisk\n0\n84\nOctober 1, 2026\nAL Development Update | September 2026\nDevelopment\n0\n175\nOctober 1, 2026\n[Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\nGeneral\n1\n84\nOctober 1, 2026\n[ARFC] Aave V4 Activation on Ethereum Mainnet\nGovernance\n50\n7821\nOctober 1, 2026\n[ARFC] Activate Aave Risk Stewards on Aave V4\nGovernance\n7\n523\nSeptember 30, 2026\n[ARFC] Onboard OUSD to Aave V3 Core Instance and Aave V4 Core Hub\nNew Asset\n0\n220\nSeptember 30, 2026\n[Direct-to-AIP] Onboard PT-USDG-25FEB2027 on X Layer\nNew Asset\n0\n71\nSeptember 30, 2026\n[ARFC] Onboard syrupUSDC to Aave V4 on Arc\nGovernance\n2\n178\nSeptember 30, 2026\n[ARFC] Onboard mWIN (Midas / Wellington Management) to Aave Horizon\nHorizon\n9\n569\nSeptember 29, 2026\nSyrup USDC (syrupUSDC) on Aave Arc Assessments\nAssessments\n1\n81\nSeptember 29, 2026\n[TEMP CHECK] Aave Will Win Framework\nGeneral\n135\n17948\nSeptember 29, 2026\nRisk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.28\nRisk\n0\n105\nSeptember 28, 2026\n[ARFC] Deploy Aave V4 on Base\nNew Asset\n7\n1314\nSeptember 25, 2026\n[ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE\nGovernance\n3\n763\nSeptember 25, 2026\n[RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\nGovernance\n0\n104\nSeptember 25, 2026\n[Direct-To-AIP] Umbrella - Renew Allowances\nGovernance\n0\n82\nSeptember 25, 2026\nwstETH borrows enabled\nGovernance\n2\n115\nSeptember 24, 2026\n[RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\nGeneral\n0\n87\nSeptember 24, 2026\nnext page →"}
{"url":"https://governance.aave.com/t/arfc-onboard-wstlink-to-aave-v3-core-instance/22169","domain":"governance.aave.com","title":"[ARFC] Onboard wstLINK to Aave V3 Core Instance - New Asset - Aave","hash":"4cfde8a51ac0991da19cd01e78ae0b04de490d30dd1712cdefd06d56eb0bfeb7","tokens":9944,"chars":39773,"crawler":"crawler-f6nn","verified":"exact","ts":1791171749540,"text":"Aave\n[ARFC] Onboard wstLINK to Aave V3 Core Instance\nGovernance\nNew Asset\nACI\nMay 26, 2025, 5:32am\n1\n[ARFC] Onboard wstLINK to Aave V3 Core Instance\nDate: 2025-05-26\nAuthor: ACI\nRisk Parameters and analysis have been updated after being provided by Risk Service Providers 2025-06-06\nProposal updated again with Risk Parameters provided by Risk Service Providers 2025-12-19\nSummary\nThe current proposal plans to onboard wstLINK to Aave V3 Core Instance, after successful [TEMP-CHECK] Onboard wstLINK to Aave v3 Core Instance posted by LinkPool, and successful [TEMP CHECK Snapshot] . This proposal is powered by Skywards.\nAs a TLDR wstLINK is a wrapped liquid staking token that enables users to earn LINK staking rewards and additional returns through DeFi strategies for stLINK and wstLINK. Its growing adoption, deep liquidity, and robust security measures make wstLINK a strong candidate to enhance Aave’s asset offerings, increase utilization of existing LINK liquidity and attract additional liquidity.\nMotivation:\nwstLINK is the wrapped liquid staking token stLINK of stake.link, the only permissionless liquid staking protocol built for LINK staking. By leveraging stake.link users can participate in LINK staking and profit from a higher reward rate as well as composability and faster withdrawals.\nKey highlights of wstLINK, stLINK and stake.link include:\n- Secure: Audited by industry-leading experts, maintaining the high standards set by Chainlink Labs:\n- CodeHawks\n- Cyfrin\n- Sigma Prime\n- Trust Security\n- Decentralized: Powered by 15 major Chainlink Node Operators, handling over 57% of network activity ( https://prism.dextrac.com/chainlink )\n- Liquid - Instant Withdrawals, No Cooldown:\n- Priority Pool: Withdraw instantly as long as there’s LINK ( amount can be viewed here ) (The Priority Pool is a holding zone that users can deposit their LINK into that automatically stakes their LINK into Chainlink Staking Contracts whenever a LINK Staker withdraws their LINK).\n- Native Withdrawals: Withdraw LINK natively within at least 7 days. 25% of the entire LINK pool will be unbonded at any point via stake.link, there’s some edge cases but that’s generally what will be the norm. Withdrawal requests will run in a 7 day queue, if you send a withdrawal request 4 days into the queue it’ll only take 3 days etc.)\n- Ecosystem Participant:\n- Chainlink Labs as ecosystem participant owning roughly 7.7% of SDL supply\n- High Adoption and TVL:\n- stake.link holds over $74 million (~4.4m LINK) in total value locked (TVL) within its ecosystem integrated across DeFi platforms like Curve, Beefy, and Uniswap\n- stake.link has established approximately $5 million pool of stLINK on Curve.fi with an a-coefficient of 500 enabling liquidations on par or with significant upside for the liquidator\n- Another $3 million of liquidity is still to migrate to the new pool\n- The new pool features a very innovative incentive by using 3% of the generated fees by the protocol (stLINK) that are distributed as LP tokens ensuring a steady growth of the pool over time with sustainable reward rate.\nSpecification\nRisk Parameters and analysis have been updated after being provided by Risk Service Providers 2025-12-19\nSpecification\nParameter\nValue\nAsset\nwstLINK\nIsolation Mode\nN/A\nBorrowable\nNo\nCollateral Enabled\nNo\nSupply Cap\n500,000\nBorrow Cap\n-\nDebt Ceiling\n-\nLTV\n-\nLT\n-\nLiquidation Penalty\n-\nLiquidation Protocol Fee\n10%\nVariable Base\n-\nVariable Slope1\n-\nVariable Slope2\n-\nUoptimal\n-\nReserve Factor\n-\nStable Borrowing\nDisabled\nFlashloanable\nYes\nSiloed Borrowing\nNo\nBorrowable in Isolation\nNo\nE-Mode Category\nwstLINK/LINK\nE-Mode (wstLINK/LINK)\nParameter\nValue\nAsset\nwstLINK\nLINK\nCollateral\nYes\nNo\nBorrowable\nNo\nYes\nMax LTV\n90.00%\n-\nLiquidation Threshold\n92.00%\n-\nLiquidation Bonus\n2.00%\n-\nCAPO\nmaxYearlyRatioGrowthPercent\nratioReferenceTime\nMINIMUM_SNAPSHOT_DELAY\n6.89%\nmonthly\n14\nInterest Rate\nInstance\nAsset\nCurrent Base\nRecommended Base\nCurrent Slope2\nRecommended Slope2\nEthereum Core\nLINK\n0%\n1.5%\n300%\n150%\nBorrow Cap\nInstance\nAsset\nCurrent Supply Cap\nRecommended Supply Cap\nCurrent Borrow Cap\nRecommended Borrow Cap\nEthereum Core\nLINK\n20,000,000\n-\n13,000,000\n6,000,000\nToken Contracts:\n- wstLINK on Ethereum: 0x911D86C72155c33993d594B0Ec7E6206B4C803da\nLiquidity Pools:\n- Curve stLINK-LINK stablepool: 0x7e13876b92f1a62c599c231f783f682e96b91761\n- LINK Priority Pool: 0xddc796a66e8b83d0bccd97df33a6ccfba8fd60ea\nUseful Links:\n- stake.link · GitHub\n- https://docs.stake.link/\nNext Steps\n- Publication of a standard ARFC (currently here), collect community & service providers feedback before escalating proposal to ARFC snapshot stage.\n- If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.\nDisclaimer\nCurrent proposal has been created by ACI, as this proposal is powered by Skyward from TEMP CHECK stage. ACI did not received payment or compensation for the publication of this proposal and is not affiliated with LinkPool or Chainlink.\nCopyright\nCopyright and related rights waived under CC0 .\n9 Likes\nChaos Labs - Monthly Community Update\nLlamaRisk\nJune 2, 2025, 7:07pm\n2\nSummary\nLlamaRisk supports adding wstLINK to the Aave V3 Core. wstLINK is a liquid-staking token that represents staked LINK on Chainlink’s network, with stake.link serving as the delegated staking provider. By staking LINK, the protocol strengthens the cryptoeconomic security of Chainlink’s oracle infrastructure.\nThe primary risk for Aave lies in potential slashing penalties on delegated LINK. Since slashing rules remain in beta, they may evolve, and any slashing event would drive net-negative rewards (i.e. a negative rebase on the underlying stLINK).\nOn the market side, liquidity for stLINK is concentrated in two Curve pools, offering roughly $5M–$5.4M of swap capacity at up to 7% slippage. The largest pool counts about 40 LPs, over 95% of whose funds sit in a Curve Gauge. Stake.link’s contracts have been audited by four independent firms and are now covered by a bug-bounty program. Governance runs through a 6-of-8 multisig, whose signers include core contributors, node operators, community members. Chainlink itself operates uniquely as a DAO participant.\nIn summary, onboarding of wstLINK would not alter Aave’s risk profile and poses minimal incremental risk, though it’s wise to monitor developments in the Chainlink Staking environment.\nCollateral Risk Assessment\n1. Asset Fundamental Characteristics\n1.1 Asset\nwstLINK (Wrapped staked LINK) is a liquid staking ERC20 token that represents a receipt of staked LINK utilised to secure the Chainlink Network through stake.link . LINK, the network’s native token, allows users to provide cryptoeconomic security to oracle networks in return for staking rewards. Stake.link is the issuer of wstLINK and the sole third-party delegated staking provider for Chainlink.\nimage 1536×864 96.9 KB\nSource: Chainlink Staking, Chainlink Economics 2.0\nChainlink staking was initially launched with v0.1 in December 2022 as a capped staking pool for the ETH/USD Data Feed on mainnet, with Community and Node Operator native staking allotments. Users can stake as Community Stakers to participate in maintaining the network (see section 1.2), with LINK auto-delegated evenly to all nodes currently.\nThe most recent beta update, v.02 (November 2023), expanded the pool from 25M to 45M LINK and introduced upgrades such as a withdrawal mechanism, variable reward rates, and the use of modular architecture. As a part of Chainlink’s Economics 2.0, staking forms part of a set of initiatives to increase oracle network utilization and adoption.\nimage 1100×591 80.5 KB\nSource: Chainlink Staking roadmap, Chainlink Blog\nAt the time of writing, it has been ~1.5 years since the last Chainlink Staking update, and no new announcements or expansions (including pools and feeds) have been made. The stake.link team indicated a lack of insight into the project’s roadmap progress.\n1.2 Architecture\nstLINK is wstLINK’s sole underlying asset, LINK is deposited into both the Node Operator and Community Staking Pools. Key contracts that enable wstLINK include:\n- StakingPool : Controls deposits and withdrawals of underlying LINK. The pool deposits assets into strategy contracts and mints stLINK, which represent a share of the pool.\n- PriorityPool : Queues deposits and acts as a liquidity buffer for withdrawals.\n- WithdrawalPool : Queues withdrawals if there is insufficient liquidity in the PriorityPool.\n- WrappedSDToken : Wraps stLINK into wstLINK.\n- RewardsInitiator : Handles reward accounting and updates the StakingPool. In the event of slashing, the contract also handles rebasing within the StakingPool.\n- RewardsPool : Manages the distribution of a single reward token to a parent pool.\n- Vaults: CommunityVaults and OperatorsVaults that are used to stake LINK.\n- VCS: Staking strategies that manage many Community and Operator vaults.\n- OperatorStakingPool : Tracks node operator LST balances.\nSlashing\nReward penalties for node operators found to have excessive downtimes were introduced in v0.1, with up to 3 months of accrued staking rewards at risk of being slashed.\nSlashing on committed LINK is currently active for v.02, and is expected to evolve as a part of the staking implementation roadmap. The slashing mechanism is based on oracle networks failing to meet their performance standard , e.g., not submitting a new oracle report for more than three hours. Node operators staked LINK are at risk of slashing should an alert be validated, with node operators slashing currently set to 700 LINK. Each stake.link node operator is max staked 75K LINK, slashing therefore represents a 0.9% penalty on the total stake per node operator. The delegated Community staked LINK is currently not at risk of slashing, but this is subject to change.\nAs a third-party delegation system, underlying LINK in wstLINK is subject to slashing risk, as it forms part of the Node Operator pools.\nRewards\nNative LINK emissions support staking rewards and alerting rewards in Beta versions of staking, with oracle network user fees being introduced from V1 onwards. Current Community rewards have a 4.5% base annualized rewards rate of the maximum staking pool size. Additionally, node operators are entitled to a 4% Delegation reward from auto-delegated Community rewards. The Community pool has an effective base rate of 4.32%. The Node Operator pool generates a base effective rate of 6.28% currently (of a maximum pool size).\nPost v0.1 updates, annualized rewards will vary based on user fees and staker commitment, reducing reliance on LINK emissions.\nWithdrawals\nA Priority pool allows users to deposit LINK in the event of unavailable deposit space into the Staking pool, queuing deposits until space becomes available. The Priority pool also acts as a liquidity buffer, allowing users to withdraw wstLINK provided there is sufficient liquidity in the pool.\nimage 535×501 39.9 KB\nSource: Priority Pool Balance, Dune , May 30th, 2025\nAs of May 31st, the Priority pool balance stood at 242K LINK (~$3.4M). Historically, the pool saw its largest balance in December 2023 (~1M/$15.8M LINK). This peak and prior growth coincided with the v0.2 update and is likely explained by the start of Early Access and General Access (December 7 and December 11). The pool’s balance declined thereafter and saw its lowest levels between August and November 2024. Liquidity has since improved and fluctuated periodically.\nUnstaking\nStaked LINK can be withdrawn from Chainlink by initiating a request and undergoing a 28-day cooldown window. After this window, users are given 7 days to claim their LINK; unclaimed LINK thereafter are restaked. Version 0.2’s unbonding mechanism reserves potential penalties on accrued rewards depending on the length of staking. Rewards are made up of Claimable and Locked rewards. Claimable rewards can be withdrawn at any time, but Locked rewards go through a 90-day lockup period before they become Claimable. Lock-up periods, called ‘ramp-up’ periods, are tracked linearly from 0% to 100% of days’ completed. Should a staker withdraw before the complete 90-day window, they will earn the percentage completed and forfeit the rest.\nIn the event the protocol withdrawal buffer described above is insufficient, stake.link withdrawals will depend on secondary markets and Chainlink’s unbonding delay. In reality, if the withdrawal buffer is depleted, in most cases the withdrawal delay will be around 7 days instead of 28 days in native Chainlink Staking, as claimed by stake.link’s team. If the amount of withdrawal requests exceeded 20% of the pool, the withdrawals will then fall back to the next unbonding cycle, incurring up to 28 days of delay.\nNode Operators\nimage 1121×555 60.5 KB\nSource: stake.link Node Operators, Mirror\nCurrently, stake.link delegates LINK to 15 node operators.\n1.3 Tokenomics\nUsers receive stLINK by staking LINK with stake.link, and wrapping to receive wstLINK via the wrapper contract. wstLINK is denominated in LINK and is a value-accruing non-rebasing token representing a user’s stake in the underlying assets + staking rewards. Supply is capped by Chainlink Staking pool size (currently 45M LINK)and the number of node operators that stake.link utilizes.\nimage 608×264 11 KB\nSource: stLINK pool info , stake.link, May 28th, 2025.\nAt the time of writing, the available pool capacity has been reached and can only expand with a Chainlink update to the pool size and/or the onboarding of additional node operators with spare capacity. Holders receive a blended reward rate from the Community and Node Operator Staking Pools, less protocol fees.\n1.3.1 Token Holder Concentration\nimage 967×475 78.1 KB\nSource: Top 100 wstLINK Holders, Etherscan , May 28th, 2025.\nwstLINK is concentrated in a few holders, with only 68 addresses holding the token. The top 10 holders collectively own 84.66%, and consist of 9 EOAs and the RewardsPoolWSD contract.\nimage 974×468 61.1 KB\nSource: Top 100 stLINK Holders, Etherscan, May 28th, 2025\nThe top 10 holders of stLINK own 63.52% of the total supply. The top 5 accounts and their holdings include:\n- LINK Priority Pool contract : 25.02%\n- wstLINK contract : 17.07%\n- EOA 1 : 4.20%\n- EOA 2 : 3.92%\n- EOA 3 : 3.51%\nThe largest DEX holding is a Curve stLINK/LINK stablepool , which holds 2.95% of the current stLINK supply.\n2. Market Risk\n2.1 Liquidity\nLiquidity for wstLINK is low, with liquidations requiring an unwrap step to stLINK for greater liquidity availability.\nimage 1304×394 57.3 KB\nSource: stLINK/LINK swap, DeFiLlama Liquidity , May 29th, 2025\n~$5.4M worth of stLINK (~338K) can be swapped for LINK within a ~7% slippage. A less correlated swap involving WETH allows for ~$5M worth of stLINK (~315K) to be swapped within a ~7% slippage.\n2.1.1 Liquidity Venue Concentration\nimage 855×210 33.1 KB\nSource: stLINK Liquidity Pools on Ethereum, Geckoterminal , May 29th, 2025\nAs mentioned in section 1.3.1, a Curve stLINK/LINK stablepool represents the largest source of DEX liquidity on Ethereum with $1.9M stLINK and $4.5M LINK. An older Curve stLINK/LINK pool is also available with $632K and $637K worth of stLINK and LINK, respectively.\n2.1.2 DEX LP Concentration\nCurve stLINK/LINK LP distribution is concentrated in a LiquidityGaugeV6 contract (95% of stLINK/LINK-ng LP token), with 33 deposits in the contract. Of the 33 deposit token holders, the top 10 holders collectively own 74.4%. The top 5 accounts and their holdings include:\n- EOA 1: 10.6%\n- EOA 2: 10.3%\n- EOA 3: 10.3%\n- EOA 4: 9.2%\n- 2/2 Multisig: 7.4%\nWhile the number of liquidity providers is low, no single account holds a majority of the available liquidity that would be of concern in the event they decided to pull liquidity from the pool.\n2.2 Volatility\nimage 600×371 35.3 KB\nSource: Llamarisk, data sourced from Coingecko, February 28th to May 29th, 2025\nRelative volatility between stLINK and underlying LINK, as measured by daily returns over the last 90 days, was similar, with stLINK and LINK averaging 5.4% and 5.3%, respectively.\nimage 831×280 31.7 KB\nSource: stLINK/USD, Geckoterminal , May 29th, 2025\n2.3 Exchanges\nwstLINK is currently not listed on centralized exchanges.\n2.4 Growth\nimage 1081×340 26.7 KB\nSource: Dune , May 29th, 2025\nstLINK retains strong user interest, as shown in section 1.3, pool capacity has been reached, with queued deposits from the Priority Pool still pending. Growth in rewards over time has remained upward since January 2024, indicating strong deposit retention and overall growth. Over the last 3 months, the rewards rate has averaged 5.41%.\n3. Technological Risk\n3.1 Smart Contract Risk\n13 audits have been performed on stake.link by 4 independent auditors. The most recent audits from each auditor include:\n- Cyfrin ( February 2025 ): 1 informational and 1 gas-related issue found, both acknowledged\n- Trust Security ( February 2025 ): 1 high, 3 medium, and 3 low severity issues found, the high issue was fixed and all others were either acknowledged or fixed.\n- Codehawks ( November 2024 ): 1 high, 7 medium, 17 low severity findings. The sole high issue, along with 5 medium and 8 low issues were fixed.\n- Sigma Prime: ( January 2023 ): 1 high, 1 medium, and 17 low severity issues were found. 1 high and 6 low issues were resolved, 5 low were closed, and the rest remained open at the time.\nThese audits reflect a history of regular and diverse risk assessments over time.\n3.2 Bug Bounty Program\nAn Immunefi bug bounty with a max payout of $100K is live. Additionally, the most recent Chainlink Staking bug bounty program for v0.2 consisted of a Code4arena contest, which lasted for 18 days in 2023, and had a total prize pool of $250K .\n3.3 Price Feed Risk\n1 stLINK is minted for every 1 LINK staked, this 1:1 basis is translated in a varying exchange rate for wstLINK. In the event of slashing, rebases to stLINK generate net negative rewards and therefore affect the wstLINK/stLINK exchange rate negatively. stLINK rebases occur on a weekly basis.\nChainlink LINK/USD market price feed is available, with a 1% deviation threshold and 1 hour heartbeat. Using the internal exchange rate along with a CAPO adapter and LINK/USD market price feed would help reflect slashing penalties more accurately than a wstLINK/USD market price feed, therefore this approach is preferred.\n3.4 Dependency Risk\nNode operators and Chainlink Staking represent the main dependencies for wstLINK. Node operators are vulnerable to slashing penalties should they not meet performance standards set out in the SLA for an oracle network. As stake.link stakes LINK in Node Operator pools, user funds are exposed to losses should the operators stake.link selects underperform.\nChainlink Staking is still in the early phases of its roadmap and will introduce more features that may affect rewards. LINK emissions are expected to taper as the main rewards asset as, oracle user fees are introduced. A reputational system will also influence the selection of nodes in an oracle network and therefore rewards.\nSlashing represents the main dependency risk, which could potentially expand to Community Staker pools, however, operator selection based on the reputational system could be a mitigating factor.\n4. Counterparty Risk\n4.1 Governance and Regulatory Risk\nStake.link continues to operate through a bifurcated architecture. The protocol was incubated by LinkPool, a veteran Chainlink node operator whose UK vehicle, LinkPool UK Ltd. , remains on the Companies House register. Following the December 2024 community proposal SLURP-30 , the ecosystem incorporated stakedotlink Limited in the British Virgin Islands as a company limited by guarantee—a not-for-profit form without share capital—tasked with “representing the DAO” in off-chain matters. This wrapper affords the project limited liability, capacity to execute service agreements (e.g. with auditors and market-makers), and an identifiable tax domicile, while token-holder supremacy is preserved through the guarantee-member structure.\nThe platform’s Terms dated 21 September 2023 underline its corporate independence by stating that “the Platform is separate from, and not a corporate affiliate of, Chainlink.” Accordingly, ownership of the front-end, branding and ancillary intellectual property lies with stake.link rather than Chainlink Labs.\nThose Terms further describe stake.link as a “strictly technology provider” operating on a “non-custodial” basis, then proceed to disclaim liability for virtually every foreseeable contingency—from smart-contract exploits and price volatility to erroneous artificial-intelligence outputs (e.g. SergAI clause). Users must indemnify the platform for defence costs, and while access is barred to Office of Foreign Assets Control–sanctioned jurisdictions, it is otherwise left open to U.S. persons, subject to unilateral suspension rights. New York law governs; all disputes must be submitted to three-member ICDR arbitration seated in New York; fiduciary, professional, custody and suitability duties are expressly disavowed; class actions, VPN circumvention and sanctioned-country access are contractually prohibited.\nWhen a user mints wstLINK pursuant to these Terms, the resulting receipt token entitles its holder to a pro-rata economic interest in a professionally managed staking pool. Contractual waivers, however, cannot forestall a regulator from categorizing that interest as a security or collective-investment unit if the underlying functional tests are satisfied.\nwstLINK itself embodies a transferable, yield-bearing claim on an aggregated asset base, with smart-contract logic and DAO governance compounding rewards autonomously. These additional layers—pooling, tokenization, secondary liquidity—mirror the characteristics that U.S. courts and the Securities and Exchange Commission have previously cited when treating Lido’s stETH and Coinbase’s staking program as investment contracts. In its 29 May 2025 statement , the SEC’s Division of Corporation Finance drew a bright line: “protocol staking” does not constitute a securities offering, but “liquid-staking tokens” such as wstLINK were conspicuously excluded from that safe harbour. Validator-level staking therefore enjoys a clearer regulatory pathway in the United States, yet the transferable receipt token minted atop Stake.link remains in limbo—and may draw increased scrutiny. A footnote in the statement explicitly declines to address “liquid staking, restaking or liquid restaking,” and contemporaneous commentary emphasizes that the guidance lacks binding legal effect, postponing a view on more complex receipt-token models.\nNotwithstanding the foregoing, a canvass of SEC, CFTC, FCA, BaFin, MAS and public-court dockets reveals no enforcement proceedings or civil claims against Stake.link, stakedotlink Limited or LinkPool as of 2 June 2025.\nBeyond that, we have formally requested that stake.link produce documentary evidence of any legal analysis previously conducted on wstLINK. If such an opinion exists—whether as an external counsel memorandum or an internal regulatory assessment—it would supply contemporaneous support capable of addressing several of the concerns outlined above.\n4.2 Access Control Risk\n4.2.1 Contract Modification Options\nAll stake.link contracts and Treasury wallet are controlled by a 6/8 multisig , which is managed by the Node Operator Council (see section 1.2 for key contracts).\nPrivileged functions in the stLINK contract that are exposed include:\nFunction\nImpact\naddStrategy() / removeStrategy()\nAdd/remove staking strategies. Could redirect funds to malicious contracts if compromised.\nsetRebaseController()\nGrants reward distribution control.\naddFee() / updateFee()\nConfigure fee. Modifies or removes an existing fee.\nsetPriorityPool()\nRestricts who can stake/withdraw.\nburn()\nBurns liquid staking tokens.\nDeployed contracts are well documented along with their functions in stake.link docs .\n4.2.2 Timelock Duration and Function\nstLINK is owned by a Governance Timelock contract, which has a 24-hour delay. This delay may potentially be too short for users to make assessments of any parameter changes and opt out.\n4.2.3 Multisig Threshold / Signer identity\nThe Node Operator Council is made up of 8 council members. Current signers to the governance multisig include:\n- 2 Core Contributors from LinkPool.io\n- Matrixed.Link\n- LinkForest.io\n- Chainlayer.io\n- Galaxy Digital\n- The SDL DAO\n- Harris and Trotter.\nNote : This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here .\nAave V3 Specific Parameters\nThe wstLINK deployment parameters have been decided jointly with @ChaosLabs and will be published in their follow-up shortly. The asset is to be onboarded with a similar setup as ETH LSTs, enabling a LINK Correlated E-Mode designed for efficient wstLINK yield looping.\nPrice feed Recommendation\nWe recommend to price wstLINK employing the internal exchange rate, in combination with CAPO and Chainlink’s LINK/USD market price feed. This will lessen the dependence on secondary market fluctuations while covering the asset’s slashing risk.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n4 Likes\nLlamaRisk - Monthly Community Update\nsid_areta\nJune 4, 2025, 12:54pm\n3\nGreat to hear the feedback on the wstLINK risk profile - liquidity does seem to be slightly constrained on Curve and this should be reflected in the risk parameters, but bringing LINK into DeFi is a big opportunity and one that we’re very much in favour of.\n2 Likes\nChaosLabs\nJune 4, 2025, 5:19pm\n4\nOverview\nChaos Labs supports listing wstLINK on Aave’s Ethereum Core instance. Below is our analysis and initial risk parameter recommendations.\nChainlink Staking\nChainlink Staking is one of the components of Chainlink’s cryptoeconomic security model, designed to enhance the reliability of oracle services by aligning incentives and introducing accountability through staking and slashing mechanisms. In its current form, Chainlink Staking secures the ETH/USD data feed on Ethereum Mainnet. Node operators help ensure data integrity by putting capital at risk, thereby strengthening the trust guarantees of Chainlink oracles.\nChainlink Staking was first introduced with v0.1 in December 2022. As an initial iteration, v0.1 enabled LINK holders to stake tokens and earn protocol rewards, but it did not include any slashing mechanisms. The total staking cap for v0.1 was 25 million LINK, allocated across early Community and Node Operator participants.\nIn November 2023, Chainlink Staking was upgraded to v0.2. This upgrade introduced a set of improvements, including an unbonding mechanism for withdrawals, and most notably, slashing capabilities for Node Operator Stakers. Alongside these functional enhancements, the total staking capacity increased by 80%, raising the overall cap from 25 million to 45 million LINK.\nChainlink Staking v0.2 is composed of two primary pools:\n- Community Staking Pool, capped at 40.875 million LINK\n- Node Operator Staking Pool, capped at 4.125 million LINK\nThese pools serve distinct roles within the system:\n- Community Stakers are individual or institutional LINK holders who contribute capital but do not provide oracle services directly. Instead, they delegate their stake to the Node Operators. Importantly, Community Stakers are not subject to slashing under v0.2.\n- Node Operator Stakers are responsible for running Chainlink oracle services (e.g., the ETH/USD data feed). These participants must stake LINK and operate reliable infrastructure. Node Operator stakes can be slashed if performance criteria are violated.\nSince the launch of v0.2, the Community Pool has consistently operated at full capacity, with nearly all 40.875 million LINK staked. In contrast, the Node Operator Pool has remained underutilized, with approximately 1.9 million LINK staked out of the 4.125 million LINK cap.\nmulti_line_stacked_chart_1748599201 1920×1405 96.1 KB\nDeposit and Withdrawals\nFor Community Stakers, deposits can be made through the Chainlink Staking interface or third-party protocols like stake.link, which offer liquid staking tokens such as stLINK and wstLINK. Once staked, LINK is delegated to Node Operators to support oracle services. Deposits into the Community Pool are subject to pool capacity constraints, which have generally been reached since the launch of v0.2.\nWithdrawals from the Community Pool follow a two-step unbonding mechanism:\n- Cooldown Period: Stakers initiate a withdrawal request, triggering a fixed 28-day cooldown period during which the staked LINK continues to accrue rewards.\n- Claim Window: After the cooldown, a 7-day claim window opens. If the staker does not withdraw during this window, the LINK is automatically restaked into the pool.\nThis unbonding mechanism is a preventative measure against mass exits during slashing events, helping maintain pool stability and ensuring sufficient staked LINK remains available to enforce penalties.\nNode Operator Stakers follow a similar deposit process but must also meet eligibility criteria, including operating approved Chainlink nodes. Withdrawals from the Node Operator Pool are also governed by the 28-day unbonding period and the 7-day claim window.\nRewards\nChainlink Staking v0.2 features a redesigned reward model that accounts for pool utilization and introduces cryptoeconomic penalties to enhance service reliability.\nStaking rewards are distributed in LINK and reward rates are variable, based on pool utilization and the total amount of rewards available per unit time. At full pool capacity, the base floor reward rate for Community Stakers is 4.5% annually. However, 4% of this is redirected to Node Operator Stakers, resulting in an effective base reward rate of 4.32% for Community participants.\nScreenshot 2025-06-02 at 10.22.18 1726×1104 26 KB\nNode Operator Stakers earn rewards from multiple sources, including their share of the base 4.5% annual reward rate and the 4% delegation fee redirected from Community Stakers. As a result, operator yields are structurally higher and designed to incentivize reliable and sustained oracle service provision.\nWhile current rewards rely primarily on LINK emissions, the long term goal is to gradually taper off emission based rewards and begin distributing user fees as the primary source of staking incentives. In parallel, ecosystem projects participating in the Chainlink BUILD program have committed a portion of their native tokens to Chainlink Staking. These tokens are expected to be distributed to Community and Node Operator Stakers over time, further diversifying the reward base and aligning incentives across the Chainlink ecosystem.\nPenalties\nThe introduction of Chainlink Staking v0.2 brought with it the first implementation of slashing penalties, designed to hold Node Operator Stakers accountable for the reliability of the oracle services they secure. These penalties are intended to safeguard data integrity by creating real economic consequences for underperformance.\nCurrently, only the ETH/USD data feed on Ethereum Mainnet is secured by v0.2 staking. If the feed experiences more than three hours of downtime, a valid alert can be raised onchain. Node Operators have a 20-minute priority window to submit the alert. If no alert is raised within that window, any eligible Community Staker may submit it. Only the first valid alert for each incident is accepted; additional alerts during the same event are disregarded.\n- Each slashed Node Operator incurs a penalty of 700 LINK\n- The first valid alerter is rewarded with 7,000 LINK\nAs of writing, 31 different Node Operators are actively participating in Chainlink Staking v0.2. Each operator can stake up to 75,000 LINK. In practice, approximately 1.9 million LINK is currently staked in the Node Operator Pool, representing the capital currently at risk of being slashed.\nGiven the fixed penalty of 700 LINK per operator, the theoretical (albeit very unlikely) total maximum slashable amount in a single event is 31 × 700 = 21,700 LINK, which constitutes approximately 1.1% of the Node Operator Pool and 0.05% of the total v0.2 staking pool.\nTo date, there have been no recorded slashing events affecting any node operator participating in the Chainlink Node Operator Staking Pool. This reflects the relatively low risk profile of the current staking configuration. Nonetheless, slashing remains a theoretical possibility and should be accounted for in any comprehensive risk assessment.\nIt is important to note that Community Stakers are not subject to slashing under the current version. Any future change to this design would require a version upgrade and a corresponding opt-out period enforced via a time-locked upgrade mechanism. This approach helps ensure protocol transparency and allows participants to react accordingly before changes take effect.\nstake.link\nstake.link is a delegated liquid staking protocol purpose built for Chainlink Staking by LinkPool, a long standing Chainlink node operator and infrastructure provider. It enables LINK holders to stake their tokens into Chainlink’s staking system by abstracting away the complexities of staking and node operation.\nWhen users stake LINK through stake.link, they receive stLINK, a liquid staking token that rebases weekly to reflect accrued staking rewards. For use cases requiring a non-rebasing token, stake.link also offers wstLINK, a wrapped version of stLINK that preserves staking value in a fixed supply format.\nOne of the key benefits for users is the auto staking functionality: whenever new staking capacity becomes available on Chainlink, such as when another user withdraws from the Community Staking Pool, stake.link automatically stakes LINK from its Priority Pool on behalf of users waiting in the queue.\nUnlike directly staking with the Community Staking Pool through the Chainlink interface, stake.link stakes LINK into both the Community and Node Operator pools. Since Node Operator stakes earn a higher effective yield, partly due to receiving delegation fees from Community Stakers, this blended strategy results in a higher aggregate return for stLINK holders compared to staking solely with the Community Pool. However, this additional yield exposure comes with slashing risk on the portion of stake delegated to the Node Operator Pool, a consideration we will explore in the following sections.\nPriority Pool\nThe Priority Pool is a core mechanism within stake.link designed to improve user experience around staking and redemption by introducing a liquidity buffer between users and the Chainlink Staking protocol. It serves two primary functions:\n- Auto-staking Queue: When users deposit LINK into stake.link but there is no immediate staking capacity available on Chainlink, their funds are held in the Priority Pool. As soon as capacity becomes available, due to unstakes or staking limit increases, stake.link automatically stakes LINK on behalf of users in the queue.\n- Redemption Liquidity Buffer: The Priority Pool also enables faster or instant redemptions of stLINK and wstLINK. Instead of waiting through the native 28-day cooldown and 7-day claim window required by Chainlink Staking, users can redeem their staked tokens instantly, as long as there is sufficient LINK available in the Priority Pool to cover the withdrawal.\nOver the past three months, the Priority Pool buffer has typically hovered between 100,000 and 300,000 LINK, offering a meaningful layer of liquidity for redemptions. Since its creation on 20 September 2023, there have been periods when the pool was fully depleted, causing some redemption requests to be temporarily delayed until new deposits replenished the balance or withdrawal requests were unbonded through Chainlink Staking. However, such instances have been historically limited. In practice, the pool has maintained a healthy buffer: over 85% of the time, it has held more than 10,000 LINK available for redemptions.\nline_chart_1748877483 1920×1377 74.1 KB\nSlashing Risk\nWhile stake.link enhances yield for stakers through its dual pool strategy (Community and Node Operator staking pools), it also introduces a limited degree of slashing risk due to its exposure to the Node Operator Staking Pool on Chainlink.\nBy design, stake.link allocates user deposits across both staking modules within Chainlink Staking v0.2:\n- The Community Staking Pool, which carries no slashing risk under the current version\n- The Node Operator Staking Pool, which is subject to slashing in the event of oracle underperformance\nAs of now, approximately 25% of the backing for stLINK, equivalent to 1,125,000 LINK, is actively staked with the Node Operator Pool. This portion is distributed evenly across 15 different node operators.\nOnly the LINK delegated to this module is exposed to slashing. In a worst-case scenario, where all 15 node operators are simultaneously slashed, the total amount penalized would be:\n- 15 × 700 LINK = 10,500 LINK\nThis represents just 0.23% of the total backing of stLINK, a relatively small impact when viewed in the context of the protocol’s overall stake distribution. While highly unlikely, this scenario illustrates the bounded downside stLINK and wstLINK holders face due to partial exposure to slashing.\nAs can be seen in the chart, stake.link’s allocation to the Node Operator Pool has remained flat since early 2024, indicating that the protocol has not onboarded new operators in recent months and years. Instead, stake.link appears to be increasingly utilizing available capacity in the Community Staking Pool whenever possible. This trend is evidenced by the consistent growth in community pool allocations, which has had the effect of diluting the relative slashing exposure within the total stLINK backing over time.\nmulti_line_chart_1748855380 1920×1378 96.2 KB\nMint and Redemption\nMinting in stake.link is not always atomic, due to the staking caps enforced by the Chainlink Staking protocol. When a user deposits LINK into stake.link, the funds are first placed in the Priority Pool, rather than being staked immediately.\nFrom there, the protocol waits for available capacity to open up in Chainlink Staking, either through withdrawal activity or increases in pool limits. As space becomes available, the Priority Pool automatically stakes the user’s LINK into either the Community or Node Operator Pools.\nAs staking occurs incrementally, users begin accruing eligibility to claim stLINK (or wstLINK) proportionally. Users have two options:\n- Wait until their entire deposit has been staked and mint their full stLINK/wstLINK balance in one transaction\n- Claim progressively as portions of their LINK are staked, minting partial amounts of stLINK over time\nThis flow ensures that stLINK is only minted against LINK that has actually been staked on-chain. It also means that minting is dependent on staking availability, introducing some delay during periods when Chainlink staking capacity is saturated.\nTo redeem LINK, users return their stLINK or wstLINK to the protocol. There are two potential redemption paths:\n-\nInstant Redemption via Priority Pool\nIf the Priority Pool holds enough unallocated LINK, users can redeem their tokens immediately.\n-\nDelayed Redemption via Chainlink Unbonding"}
{"url":"https://bitcoin.org/en/you-need-to-know","domain":"bitcoin.org","title":"Some things you need to know - Bitcoin","hash":"ec5511ab97e2dcb7399717e815b0468dd3c83b60d82a2aa671b085bbcd91dc7a","tokens":1800,"chars":7198,"crawler":"crawler-f6nn","verified":"exact","ts":1791171751733,"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\nSome things you need to know\nIf you're getting started with Bitcoin, there are a few things you should know. Bitcoin lets you exchange money and transact in a different way than you normally do. As such, you should take time to inform yourself before using Bitcoin for any serious transaction. Bitcoin should be treated with the same care as your regular wallet, or even more in some cases!\nSecuring your wallet\nLike in real life, your wallet must be secured. Bitcoin makes it possible to transfer value anywhere in a very easy way and it allows you to be in control of your money. Such great features also come with great security concerns. At the same time, Bitcoin can provide very high levels of security if used correctly. Always remember that it is your responsibility to adopt good practices in order to protect your money. Read more about securing your wallet .\nThere is no undo button\nBitcoin has no central authority to reverse a mistake. If you permanently lose access to your wallet—for example by losing your recovery phrase—your funds are gone permanently. No one—not developers, miners, wallet providers, or exchanges—can recover funds that you permanently lose from a self-custodied wallet. Always back up your wallet and keep your recovery information safe and private.\nYou are your own bank\nWhen you hold your own private keys, you control your bitcoin—but you are also responsible for keeping it secure. If you leave your coins with an exchange or another custodian, you rely on that third party to safeguard them and to honor withdrawals. That reliance introduces counterparty risk: the custodian's own security, solvency, and policies now stand between you and your funds. Holding your own keys removes that risk, but requires you to secure your wallet and backups yourself.\nBitcoin is not anonymous\nSome effort is required to protect your privacy with Bitcoin. All Bitcoin transactions are stored publicly and permanently on the network, which means anyone can see the balance and transactions of any Bitcoin address. However, the identity of the user behind an address remains unknown until information is revealed during a purchase or in other circumstances. This is one reason why Bitcoin addresses should only be used once. Always remember that it is your responsibility to adopt good practices in order to protect your privacy. Read more about protecting your privacy .\nBitcoin payments are irreversible\nA Bitcoin transaction cannot be reversed, it can only be refunded by the person receiving the funds. This means you should take care to do business with people and organizations you know and trust, or who have an established reputation. For their part, businesses need to keep track of the payment requests they are displaying to their customers. Bitcoin can detect typos and usually won't let you send money to an invalid address by mistake, but it's best to have controls in place for additional safety and redundancy. Services such as escrow and multi-signature wallets provide additional choice and protection for both businesses and consumers.\nConfirmations\nLightweight wallets\nBitcoin Core\n0\nOnly safe if you trust the person paying you\n1\nSomewhat reliable\nMostly reliable\n3\nMostly reliable\nHighly reliable\n6\nMinimum recommendation for high-value bitcoin transfers\n30\nRecommendation during emergencies to allow human intervention\nUnconfirmed transactions aren't secure\nTransactions do not become irreversible immediately. Instead, they accumulate confirmations, each making them increasingly difficult to reverse (see table). New blocks are added to the blockchain approximately every 10 minutes on average, but block discovery is probabilistic—an individual confirmation may arrive much sooner or much later, and there is no guaranteed minimum or maximum delay. If the transaction pays a fee below what the network is currently prioritizing, the first confirmation may take considerably longer.\nBitcoin price is volatile\nThe price of a bitcoin can unpredictably increase or decrease over a short period of time due to its economy, evolving adoption, and sometimes illiquid markets. Bitcoin should be treated as a high-risk asset, and you should never store money that you cannot afford to lose in bitcoin. If you receive payments with Bitcoin, many service providers can convert them to your local currency.\nBitcoin is still in active development\nBitcoin continues to evolve through active development. Improvements make the network more capable, but can also introduce new challenges as adoption grows. During these growing pains you might encounter increased fees, slower confirmations, or even more severe issues. Be prepared for problems and consult a technical expert before making any major investments, but keep in mind that nobody can predict Bitcoin's future.\nGovernment taxes and regulations\nBitcoin is not an official currency. That said, most jurisdictions still require you to pay income, sales, payroll, and capital gains taxes on anything that has value, including bitcoins. It is your responsibility to ensure that you adhere to tax and other legal or regulatory mandates issued by your government and/or local municipalities.\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.polkadot.com/","domain":"docs.polkadot.com","title":"Polkadot Developer Docs","hash":"de6e254c6060b29c5fae8930e89adcf547bf1f9e6be23ce660dee638e4b573c9","tokens":395,"chars":1577,"crawler":"crawler-f6nn","verified":"exact","ts":1791171753852,"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://ethereum.org/roadmap/","domain":"ethereum.org","title":"Ethereum roadmap | ethereum.org","hash":"8686639d32303961cbc7b630793d1f5da9c7db379e76b9a574a5607361e698b3","tokens":2524,"chars":10095,"crawler":"crawler-f6nn","verified":"exact","ts":1791171756204,"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://eips.ethereum.org/EIPS/eip-712","domain":"eips.ethereum.org","title":"EIP-712: Typed structured data hashing and signing","hash":"18d05923ac5fdbdcd9410d52bd2c63f9845c0cb475ece1052fe63191fc1be455","tokens":5404,"chars":21616,"crawler":"crawler-f6nn","verified":"exact","ts":1791171758439,"text":"Ethereum Improvement Proposals\n🎉 Final\nStandards Track: Interface\nEIP-712: Typed structured data hashing and signing\nA procedure for hashing and signing of typed structured data as opposed to just bytestrings.\nAuthors\nRemco Bloemen ( @Recmo ), Leonid Logvinov ( @LogvinovLeon ), Jacob Evans ( @dekz )\nCreated\n2017-09-12\nRequires\nEIP-155 ,\nEIP-191\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- Definition of typed structured data 𝕊\n- Definition of hashStruct\n- Definition of encodeType\n- Definition of encodeData\n- Definition of domainSeparator\n- Specification of the eth_signTypedData JSON RPC\n- Specification of the Web3 API\n- Rationale\n- Rationale for typeHash\n- Rationale for encodeData\n- Rationale for domainSeparator\n- Backwards Compatibility\n- Test Cases\n- Security Considerations\n- Replay attacks\n- Frontrunning attacks\n- Copyright\nAbstract\nThis is a standard for hashing and signing of typed structured data as opposed to just bytestrings. It includes a\n- theoretical framework for correctness of encoding functions,\n- specification of structured data similar to and compatible with Solidity structs,\n- safe hashing algorithm for instances of those structures,\n- safe inclusion of those instances in the set of signable messages,\n- an extensible mechanism for domain separation,\n- new RPC call eth_signTypedData , and\n- an optimized implementation of the hashing algorithm in EVM.\nIt does not include replay protection.\nMotivation\nSigning data is a solved problem if all we care about are bytestrings. Unfortunately in the real world we care about complex meaningful messages. Hashing structured data is non-trivial and errors result in loss of the security properties of the system.\nAs such, the adage “don’t roll your own crypto” applies. Instead, a peer-reviewed well-tested standard method needs to be used. This EIP aims to be that standard.\nThis EIP aims to improve the usability of off-chain message signing for use on-chain. We are seeing growing adoption of off-chain message signing as it saves gas and reduces the number of transactions on the blockchain. Currently signed messages are an opaque hex string displayed to the user with little context about the items that make up the message.\nHere we outline a scheme to encode data along with its structure which allows it to be displayed to the user for verification when signing. Below is an example of what a user could be shown when signing a message according to the present proposal.\nSpecification\nThe set of signable messages is extended from transactions and bytestrings 𝕋 ∪ 𝔹⁸ⁿ to also include structured data 𝕊 . The new set of signable messages is thus 𝕋 ∪ 𝔹⁸ⁿ ∪ 𝕊 . They are encoded to bytestrings suitable for hashing and signing as follows:\n- encode(transaction : 𝕋) = RLP_encode(transaction)\n- encode(message : 𝔹⁸ⁿ) = \"\\x19Ethereum Signed Message:\\n\" ‖ len(message) ‖ message where len(message) is the non-zero-padded ascii-decimal encoding of the number of bytes in message .\n- encode(domainSeparator : 𝔹²⁵⁶, message : 𝕊) = \"\\x19\\x01\" ‖ domainSeparator ‖ hashStruct(message) where domainSeparator and hashStruct(message) are defined below.\nThis encoding is deterministic because the individual components are. The encoding is injective because the three cases always differ in first byte. ( RLP_encode(transaction) does not start with \\x19 .)\nThe encoding is compliant with ERC-191 . The ‘version byte’ is fixed to 0x01 , the ‘version specific data’ is the 32-byte domain separator domainSeparator and the ‘data to sign’ is the 32-byte hashStruct(message) .\nDefinition of typed structured data 𝕊\nTo define the set of all structured data, we start with defining acceptable types. Like ABIv2 these are closely related to Solidity types. It is illustrative to adopt Solidity notation to explain the definitions. The standard is specific to the Ethereum Virtual Machine, but aims to be agnostic to higher level languages. Example:\nstruct Mail {\naddress from;\naddress to;\nstring contents;\n}\nDefinition : A struct type has valid identifier as name and contains zero or more member variables. Member variables have a member type and a name.\nDefinition : A member type can be either an atomic type, a dynamic type or a reference type.\nDefinition : The atomic types are bytes1 to bytes32 , uint8 to uint256 , int8 to int256 , bool and address . These correspond to their definition in Solidity. Note that there are no aliases uint and int . Note that contract addresses are always plain address . Fixed point numbers are not supported by the standard. Future versions of this standard may add new atomic types.\nDefinition : The dynamic types are bytes and string . These are like the atomic types for the purpose of type declaration, but their treatment in encoding is different.\nDefinition : The reference types are arrays and structs. Arrays are either fixed size or dynamic and denoted by Type[n] or Type[] respectively. Structs are references to other structs by their name. The standard supports recursive struct types.\nDefinition : The set of structured typed data 𝕊 contains all the instances of all the struct types.\nDefinition of hashStruct\nThe hashStruct function is defined as\n- hashStruct(s : 𝕊) = keccak256(typeHash ‖ encodeData(s)) where typeHash = keccak256(encodeType(typeOf(s)))\nNote : The typeHash is a constant for a given struct type and does not need to be runtime computed.\nDefinition of encodeType\nThe type of a struct is encoded as name ‖ \"(\" ‖ member₁ ‖ \",\" ‖ member₂ ‖ \",\" ‖ … ‖ memberₙ \")\" where each member is written as type ‖ \" \" ‖ name . For example, the above Mail struct is encoded as Mail(address from,address to,string contents) .\nIf the struct type references other struct types (and these in turn reference even more struct types), then the set of referenced struct types is collected, sorted by name and appended to the encoding. An example encoding is Transaction(Person from,Person to,Asset tx)Asset(address token,uint256 amount)Person(address wallet,string name) .\nDefinition of encodeData\nThe encoding of a struct instance is enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ) , i.e. the concatenation of the encoded member values in the order that they appear in the type. Each encoded member value is exactly 32-byte long.\nThe atomic values are encoded as follows: Boolean false and true are encoded as uint256 values 0 and 1 respectively. Addresses are encoded as uint160 . Integer values are sign-extended to 256-bit and encoded in big endian order. bytes1 to bytes31 are arrays with a beginning (index 0 ) and an end (index length - 1 ), they are zero-padded at the end to bytes32 and encoded in beginning to end order. This corresponds to their encoding in ABI v1 and v2.\nThe dynamic values bytes and string are encoded as a keccak256 hash of their contents.\nThe array values are encoded as the keccak256 hash of the concatenated encodeData of their contents (i.e. the encoding of SomeType[5] is identical to that of a struct containing five members of type SomeType ).\nThe struct values are encoded recursively as hashStruct(value) . This is undefined for cyclical data.\nDefinition of domainSeparator\ndomainSeparator = hashStruct(eip712Domain)\nwhere the type of eip712Domain is a struct named EIP712Domain with one or more of the below fields. Protocol designers only need to include the fields that make sense for their signing domain. Unused fields are left out of the struct type.\n- string name the user readable name of signing domain, i.e. the name of the DApp or the protocol.\n- string version the current major version of the signing domain. Signatures from different versions are not compatible.\n- uint256 chainId the EIP-155 chain id. The user-agent should refuse signing if it does not match the currently active chain.\n- address verifyingContract the address of the contract that will verify the signature. The user-agent may do contract specific phishing prevention.\n- bytes32 salt a disambiguating salt for the protocol. This can be used as a domain separator of last resort.\nFuture extensions to this standard can add new fields with new user-agent behaviour constraints. User-agents are free to use the provided information to inform/warn users or refuse signing. Dapp implementers should not add private fields, new fields should be proposed through the EIP process.\nThe EIP712Domain fields should be the order as above, skipping any absent fields. Future field additions must be in alphabetical order and come after the above fields. User-agents should accept fields in any order as specified by the EIP712Domain type.\nSpecification of the eth_signTypedData JSON RPC\nThe method eth_signTypedData is added to the Ethereum JSON-RPC. The method parallels eth_sign .\neth_signTypedData\nThe sign method calculates an Ethereum specific signature with: sign(keccak256(\"\\x19\\x01\" ‖ domainSeparator ‖ hashStruct(message))) , as defined above.\nNote : the address to sign with must be unlocked.\nParameters\n- Address - 20 Bytes - Address of the account that will sign the messages.\n- TypedData - Typed structured data to be signed.\nTyped data is a JSON object containing type information, domain separator parameters and the message object. Below is the json-schema definition for TypedData param.\n{\ntype: 'object',\nproperties: {\ntypes: {\ntype: 'object',\nproperties: {\nEIP712Domain: {type: 'array'},\n},\nadditionalProperties: {\ntype: 'array',\nitems: {\ntype: 'object',\nproperties: {\nname: {type: 'string'},\ntype: {type: 'string'}\n},\nrequired: ['name', 'type']\n}\n},\nrequired: ['EIP712Domain']\n},\nprimaryType: {type: 'string'},\ndomain: {type: 'object'},\nmessage: {type: 'object'}\n},\nrequired: ['types', 'primaryType', 'domain', 'message']\n}\nReturns\nDATA : Signature. As in eth_sign it is a hex encoded 65 byte array starting with 0x . It encodes the r , s and v parameters from appendix F of the yellow paper in big-endian format. Bytes 0…32 contain the r parameter, bytes 32…64 the s parameter and the last byte the v parameter. Note that the v parameter includes the chain id as specified in EIP-155 .\nExample\nRequest:\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_signTypedData\",\"params\":[\"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\", {\"types\":{\"EIP712Domain\":[{\"name\":\"name\",\"type\":\"string\"},{\"name\":\"version\",\"type\":\"string\"},{\"name\":\"chainId\",\"type\":\"uint256\"},{\"name\":\"verifyingContract\",\"type\":\"address\"}],\"Person\":[{\"name\":\"name\",\"type\":\"string\"},{\"name\":\"wallet\",\"type\":\"address\"}],\"Mail\":[{\"name\":\"from\",\"type\":\"Person\"},{\"name\":\"to\",\"type\":\"Person\"},{\"name\":\"contents\",\"type\":\"string\"}]},\"primaryType\":\"Mail\",\"domain\":{\"name\":\"Ether Mail\",\"version\":\"1\",\"chainId\":1,\"verifyingContract\":\"0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC\"},\"message\":{\"from\":{\"name\":\"Cow\",\"wallet\":\"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\"},\"to\":{\"name\":\"Bob\",\"wallet\":\"0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB\"},\"contents\":\"Hello, Bob!\"}}],\"id\":1}'\nResult:\n{\n\"id\":1,\n\"jsonrpc\": \"2.0\",\n\"result\": \"0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c\"\n}\nAn example how to use Solidity ecrecover to verify the signature calculated with eth_signTypedData can be found in the Example.js . The contract is deployed on the testnet Ropsten and Rinkeby.\npersonal_signTypedData\nThere also should be a corresponding personal_signTypedData method which accepts the password for an account as the last argument.\nSpecification of the Web3 API\nTwo methods are added to Web3.js version 1 that parallel the web3.eth.sign and web3.eth.personal.sign methods.\nweb3.eth.signTypedData\nweb3.eth.signTypedData(typedData, address [, callback])\nSigns typed data using a specific account. This account needs to be unlocked.\nParameters\n- Object - Domain separator and typed data to sign. Structured according to the JSON-Schema specified above in the eth_signTypedData JSON RPC call.\n- String|Number - Address to sign data with. Or an address or index of a local wallet in :ref: web3.eth.accounts.wallet .\n- Function - (optional) Optional callback, returns an error object as first parameter and the result as second.\nNote : The 2. address parameter can also be an address or index from the web3.eth.accounts.wallet . It will then sign locally using the private key of this account.\nReturns\nPromise returns String - The signature as returned by eth_signTypedData .\nExample\nSee the eth_signTypedData JSON-API example above for the value of typedData .\nweb3.eth.signTypedData(typedData, \"0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826\")\n.then(console.log);\n> \"0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c\"\nweb3.eth.personal.signTypedData\nweb3.eth.personal.signTypedData(typedData, address, password [, callback])\nIdentical to web3.eth.signTypedData except for an additional password parameter analogous to web3.eth.personal.sign .\nRationale\nThe encode function is extended with a new case for the new types. The first byte of the encoding distinguishes the cases. For the same reason it is not safe to start immediately with the domain separator or a typeHash . While hard, it may be possible to construct a typeHash that also happens to be a prefix of a valid RLP encoded transaction.\nThe domain separator prevents collision of otherwise identical structures. It is possible that two DApps come up with an identical structure like Transfer(address from,address to,uint256 amount) that should not be compatible. By introducing a domain separator the DApp developers are guaranteed that there can be no signature collision.\nThe domain separator also allows for multiple distinct signatures use-cases on the same struct instance within a given DApp. In the previous example, perhaps signatures from both from and to are required. By providing two distinct domain separators these signatures can be distinguished from each other.\nAlternative 1 : Use the target contract address as domain separator. This solves the first problem, contracts coming up with identical types, but does not address the second use-case. The standard does suggest implementors to use the target contract address where this is appropriate.\nThe function hashStruct starts with a typeHash to separate types. By giving different types a different prefix the encodeData function only has to be injective within a given type. It is okay for encodeData(a) to equal encodeData(b) as long as typeOf(a) is not typeOf(b) .\nRationale for typeHash\nThe typeHash is designed to turn into a compile time constant in Solidity. For example:\nbytes32 constant MAIL_TYPEHASH = keccak256(\n\"Mail(address from,address to,string contents)\");\nFor the type hash several alternatives were considered and rejected for the reasons:\nAlternative 2 : Use ABIv2 function signatures. bytes4 is not enough to be collision resistant. Unlike function signatures, there is negligible runtime cost incurred by using longer hashes.\nAlternative 3 : ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the semantics other than the function. This is already causing a practical collision between ERC-20 ’s and ERC-721 ’s transfer(address,uint256) , where in the former the uint256 refers to an amount and the latter to a unique id. In general ABIv2 favors compatibility where a hashing standard should prefer incompatibility.\nAlternative 4 : 256-bit ABIv2 signatures extended with parameter names and struct names. The Mail example from above would be encoded as Mail(Person(string name,address wallet) from,Person(string name,address wallet) to,string contents) . This is longer than the proposed solution. And indeed, the length of the string can grow exponentially in the length of the input (consider struct A{B a;B b;}; struct B {C a;C b;}; … ). It also does not allow a recursive struct type (consider struct List {uint256 value; List next;} ).\nAlternative 5 : Include natspec documentation. This would include even more semantic information in the schemaHash and further reduces chances of collision. It makes extending and amending documentation a breaking changes, which contradicts common assumptions. It also makes the schemaHash mechanism very verbose.\nRationale for encodeData\nThe encodeData is designed to allow easy implementation of hashStruct in Solidity:\nfunction hashStruct(Mail memory mail) pure returns (bytes32 hash) {\nreturn keccak256(abi.encode(\nMAIL_TYPEHASH,\nmail.from,\nmail.to,\nkeccak256(mail.contents)\n));\n}\nit also allows for an efficient in-place implementation in EVM\nfunction hashStruct(Mail memory mail) pure returns (bytes32 hash) {\n// Compute sub-hashes\nbytes32 typeHash = MAIL_TYPEHASH;\nbytes32 contentsHash = keccak256(mail.contents);\nassembly {\n// Back up select memory\nlet temp1 := mload(sub(mail, 32))\nlet temp2 := mload(add(mail, 128))\n// Write typeHash and sub-hashes\nmstore(sub(mail, 32), typeHash)\nmstore(add(mail, 64), contentsHash)\n// Compute hash\nhash := keccak256(sub(mail, 32), 128)\n// Restore memory\nmstore(sub(mail, 32), temp1)\nmstore(add(mail, 64), temp2)\n}\nThe in-place implementation makes strong but reasonable assumptions on the memory layout of structs in memory. Specifically it assumes structs are not allocated below address 32, that members are stored in order, that all values are padded to 32-byte boundaries, and that dynamic and reference types are stored as a 32-byte pointers.\nAlternative 6 : Tight packing. This is the default behaviour in Solidity when calling keccak256 with multiple arguments. It minimizes the number of bytes to be hashed but requires complicated packing instructions in EVM to do so. It does not allow in-place computation.\nAlternative 7 : ABIv2 encoding. Especially with the upcoming abi.encode it should be easy to use abi.encode as the encodeData function. The ABIv2 standard by itself fails the determinism security criteria. There are several valid ABIv2 encodings of the same data. ABIv2 does not allow in-place computation.\nAlternative 8 : Leave typeHash out of hashStruct and instead combine it with the domain separator. This is more efficient, but then the semantics of the Solidity keccak256 hash function are not injective.\nAlternative 9 : Support cyclical data structures. The current standard is optimized for tree-like data structures and undefined for cyclical data structures. To support cyclical data a stack containing the path to the current node needs to be maintained and a stack offset substituted when a cycle is detected. This is prohibitively more complex to specify and implement. It also breaks composability where the hashes of the member values are used to construct the hash of the struct (the hash of the member values would depend on the path). It is possible to extend the standard in a compatible way to define hashes of cyclical data.\nSimilarly, a straightforward implementation is sub-optimal for directed acyclic graphs. A simple recursion through the members can visit the same node twice. Memoization can optimize this.\nRationale for domainSeparator\nSince different domains have different needs, an extensible scheme is used where the DApp specifies a EIP712Domain struct type and an instance eip712Domain which it passes to the user-agent. The user-agent can then apply different verification measures depending on the fields that are there.\nBackwards Compatibility\nThe RPC calls, web3 methods and SomeStruct.typeHash parameter are currently undefined. Defining them should not affect the behaviour of existing DApps.\nThe Solidity expression keccak256(someInstance) for an instance someInstance of a struct type SomeStruct is valid syntax. It currently evaluates to the keccak256 hash of the memory address of the instance. This behaviour should be considered dangerous. In some scenarios it will appear to work correctly but in others it will fail determinism and/or injectiveness. DApps that depend on the current behaviour should be considered dangerously broken.\nTest Cases\nAn example contract can be found in Example.sol and an example implementation of signing in JavaScript in Example.js\nSecurity Considerations\nReplay attacks\nThis standard is only about signing messages and verifying signatures. In many practical applications, signed messages are used to authorize an action, for example an exchange of tokens. It is very important that implementers make sure the application behaves correctly when it sees the same signed message twice. For example, the repeated message should be rejected or the authorized action should be idempotent. How this is implemented is specific to the application and out of scope for this standard.\nFrontrunning attacks\nThe mechanism for reliably broadcasting a signature is application-specific and out of scope for this standard. When the signature is broadcast to a blockchain for use in a contract, the application has to be secure against frontrunning attacks. In this kind of attack, an attacker intercepts the signature and submits it to the contract before the original intended use takes place. The application should behave correctly when the signature is submitted first by an attacker, for example by rejecting it or simply producing exactly the same effect as intended by the signer.\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nRemco Bloemen ( @Recmo ), Leonid Logvinov ( @LogvinovLeon ), Jacob Evans ( @dekz ), \"EIP-712: Typed structured data hashing and signing,\" Ethereum Improvement Proposals , no. 712, September 2017. Available: https://eips.ethereum.org/EIPS/eip-712."}
{"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-f6nn","verified":"exact","ts":1791171761160,"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://docs.meteora.ag/get-started","domain":"docs.meteora.ag","title":"We Build Liquidity Pools - Meteora Documentation","hash":"37bd58f29367e77bd7d39bd842b7862cda1651c27405da0eaac314de1c663848","tokens":1346,"chars":5381,"crawler":"crawler-f6nn","verified":"exact","ts":1791171763841,"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.marginfi.com/","domain":"docs.marginfi.com","title":"Project 0 Documentation","hash":"bc575a29b2fa965ad7d31e4a7a4a340242b29e88db7423c4d86da4965a5bebc1","tokens":250,"chars":1000,"crawler":"crawler-f6nn","verified":"exact","ts":1791171766088,"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://docs.monad.xyz/","domain":"docs.monad.xyz","title":"Introduction - Monad Documentation","hash":"d77ac3cdc585eced57fec68175a545414df397bb3e6a25584887a6efdb018f58","tokens":730,"chars":2920,"crawler":"crawler-f6nn","verified":"exact","ts":1791171768704,"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.berachain.com/general/tokens/bera","domain":"docs.berachain.com","title":"BERA Token - Berachain","hash":"4cb5781ef52ac44b9d40c4741852b34ce37385ec57b756465c785eb1ee3b337f","tokens":778,"chars":3112,"crawler":"crawler-f6nn","verified":"exact","ts":1791171770989,"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://discuss.ens.domains/latest","domain":"discuss.ens.domains","title":"Latest topics - ENS DAO Governance Forum","hash":"d5b2a13df2abe7959fa0aa8d62e1701389b838ae3afcf530cdd33b141a125737","tokens":744,"chars":2973,"crawler":"crawler-f6nn","verified":"exact","ts":1791171773266,"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\n32\nOctober 4, 2026\nMeta-Gov Working Group Term 7 Meetings: Thursday, 4pm UTC. Bi-weekly\nMeetings/events\n12\n626\nOctober 4, 2026\nNamespace - Quarterly Reports\nReports\nservice-providers\n10\n2083\nOctober 2, 2026\nNamespace: SPP3 Quarterly Reports\nReports\nservice-providers\n1\n94\nOctober 2, 2026\nENS Financial Reporting by Steakhouse\nTreasury Management\n53\n9298\nOctober 1, 2026\nENS DAO Newsletter #121 — 10/1/2026\nNewsletter\nnewsletter\n0\n39\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\n176\nSeptember 30, 2026\nFinal ENS Retro Report\nDAO-Wide\n4\n228\nSeptember 28, 2026\nGovernor Nexus - Implementation report\nDAO-Governance\n6\n237\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\n235\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\n102\nSeptember 21, 2026\nEndowment Monthly Reports\nTreasury Management\n41\n19344\nSeptember 17, 2026\nENS DAO Newsletter #120 — 09/15/2026\nNewsletter\nnewsletter\n0\n69\nSeptember 15, 2026\nENSIP: Stealth Address Resolution\nStandards\nensip\n8\n380\nSeptember 15, 2026\nENSIP: Text Record Attestations\nStandards\n11\n232\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\n1020\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\n116\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.morpho.org/get-started/","domain":"docs.morpho.org","title":"Get Started","hash":"a44a7f095414960964fd604f961974b0eef1d89f64bc6e02cb7072054e0c5708","tokens":680,"chars":2717,"crawler":"crawler-f6nn","verified":"exact","ts":1791171775559,"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://docs.velocity.exchange/protocol","domain":"docs.velocity.exchange","title":"Introduction to Velocity | Velocity Protocol","hash":"a7d419b35cf92d8ec90290cb93cebf95699dc185989465344ea1cf83694b2997","tokens":1221,"chars":4881,"crawler":"crawler-f6nn","verified":"exact","ts":1791171777789,"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.compound.xyz/","domain":"docs.compound.xyz","title":"Compound III Documentation","hash":"41c23224456ab0fa91b72fdf24b3a86a0b3cabfae08d737ca0dd4d23999641dd","tokens":1270,"chars":5079,"crawler":"crawler-f6nn","verified":"exact","ts":1791171780410,"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://aave.com/docs","domain":"aave.com","title":"Aave Protocol Overview","hash":"b79c5985a8db1e8c92cd7347ac34c522f1435cdcc4d159ea70d09b27ff1d01aa","tokens":355,"chars":1420,"crawler":"crawler-f6nn","verified":"exact","ts":1791171782911,"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://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-f6nn","verified":"exact","ts":1791171785945,"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.marinade.finance/","domain":"docs.marinade.finance","title":"Welcome to Marinade | Marinade Documentation","hash":"1f83a138e28b993919631920ed0a6102261dec8bb09569db3093a2c4ec2e9abe","tokens":778,"chars":3112,"crawler":"crawler-f6nn","verified":"exact","ts":1791171788673,"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.anza.xyz/validator/tvu","domain":"docs.anza.xyz","title":"Transaction Validation Unit in a Solana Validator | Agave","hash":"d12a998ee4b0133d9455e5813e1aedca9760e22687747689e7716fef3382d122","tokens":569,"chars":2273,"crawler":"crawler-f6nn","verified":"exact","ts":1791171791282,"text":"Skip to main content\nTransaction Validation Unit in a Solana Validator\nTVU (Transaction Validation Unit) is the logic of the validator\nresponsible for propagating blocks between validators and ensuring that\nthose blocks' transactions reach the replay stage. Its principal external\ninterface is the turbine protocol.\nRetransmit Stage\nTVU sockets\nExternally, TVU UDP receiver appears to bind to one port, typically 8002 UDP.\nInternally, TVU is actually bound with multiple sockets to improve kernel's handling of the packet queues.\nNOTE: TPU sockets use similar logic\nA node advertises one external ip/port for TVU while binding multiple sockets to that same port:\nlet ( tvu_port , tvu_sockets ) = multi_bind_in_range_with_config (\nbind_ip_addr ,\nport_range ,\nsocket_config ,\nnum_tvu_sockets . get ( ) ,\n)\n. expect ( \"tvu multi_bind\" ) ;\nmulti_bind_in_range_with_config sets SO_REUSEPORT . This means that other nodes only need to know about the one ip/port pair for TVU (similar principle applies in the case of TPU UDP sockets). The kernel distributes the incoming packets to all sockets bound to that port, and each socket can be serviced by a different thread.\nThe TVU socket information is published via Gossip and is available in the ContactInfo struct.\nTo set a TVU socket, the node calls set_tvu(...) . The set_tvu() method is created by the macro set_socket! . For example:\ninfo . set_tvu ( UDP , ( addr , tvu_udp_port ) ) . unwrap ( ) ;\nUnder the hood, set_tvu() calls set_socket() .\nIn the ContactInfo struct, all sockets are identified by a tag/key, e.g.:\nconst SOCKET_TAG_TVU : u8 = 10 ; // For UDP\n- set_socket() creates a SocketEntry and stores that into ContactInfo::sockets\n- set_socket() updates ContactInfo::cache\ncache : [ SocketAddr ; SOCKET_CACHE_SIZE ]\ncache is purely for quick lookups and optimization; it is not serialized and sent to peer nodes.\nSocketEntry is serialized and sent to peer nodes within the gossip message type CrdsData::ContactInfo . Upon receiving the ContactInfo , the peer node calls the get_socket! macro to retrieve the TVU port associated with the node.\nFor example, to retrieve the TVU ports of the remote node, the peer node calls:\nget_socket! ( tvu , SOCKET_TAG_TVU , SOCKET_TAG_TVU_UDP ) ;\n- Retransmit Stage\n- TVU sockets"}
{"url":"https://solana.com/docs/tokens","domain":"solana.com","title":"","hash":"6873484169bc77d41c277288c73cf9d8f70ba9c6d7a01c6c1200c5e99a19b148","tokens":1881,"chars":7523,"crawler":"crawler-f6nn","verified":"exact","ts":1791171793160,"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://docs.anza.xyz/","domain":"docs.anza.xyz","title":"Home | Agave","hash":"ffa38694837027774485707cd90d0a3a47ade83b7377900dbfd7a9a672386bfe","tokens":487,"chars":1945,"crawler":"crawler-f6nn","verified":"exact","ts":1791171795120,"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://vitalik.eth.limo/","domain":"vitalik.eth.limo","title":"Vitalik Buterin's website","hash":"35b4bbce4a8d44a6b54c958f7e4440c08c812745c928d460126300d8eae21ecb","tokens":2301,"chars":9204,"crawler":"crawler-f6nn","verified":"exact","ts":1791171797428,"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.layerzero.network/v2/concepts/getting-started/what-is-layerzero","domain":"docs.layerzero.network","title":"What is LayerZero? - LayerZero","hash":"d220d6914543e579f894126ff662b847dd67697003c64670934807ea1d7be472","tokens":1956,"chars":7822,"crawler":"crawler-f6nn","verified":"exact","ts":1791171799819,"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\nConcepts\nWhat is LayerZero?\nLayerZero is an omnichain messaging protocol — a permissionless, open framework designed to securely move information between blockchains. It empowers any…\nLayerZero is an omnichain messaging protocol — a permissionless, open framework designed to securely move information between blockchains. It empowers any application to bring its own security, execution, and crosschain interaction, providing a predictable and adaptable foundation for decentralized applications living on multiple networks.\nBefore LayerZero\nBefore LayerZero, crosschain communication was a patchwork of monolithic bridges and isolated solutions. Achieving true crosschain communication was a complex and often fragile endeavor.\nTraditional methods relied on monolithic bridges with centralized verifiers or a fixed set of signers — approaches that imposed rigid structures and created single points of failure. When any component of these systems faltered, every connected application was put at risk, stifling innovation and leaving developers scrambling for secure solutions.\nThe LayerZero Framework\nLayerZero redefines crosschain interactions by combining several key architectural elements:\n-\nImmutable Smart Contracts:\nNon-upgradeable endpoint contracts are deployed on each blockchain. These immutable contracts serve as secure entry and exit points for messages, ensuring consistency and trust across all networks.\n-\nConfigurable Message Libraries:\nLayerZero offers flexible libraries that developers can select to tailor the way messages are emitted off-chain. This adaptability means applications can optimize message formatting and handling according to specific needs without being tied to a one-size-fits-all solution.\n-\nModular Security Owned by the Application:\nInstead of relying on a centralized verifier network, LayerZero enables each application to configure its own security stack. Developers can choose from various decentralized verifier networks (DVNs) and set parameters like finality and execution rules. This modular approach shifts control to the application, allowing for tailored security that evolves with emerging technologies.\n-\nPermissionless Execution:\nBy making the execution of crosschain messages available to anyone, LayerZero ensures that once a message is verified, it can be executed without gatekeepers. This open design removes bottlenecks and facilitates seamless interaction across the blockchain mesh.\nTogether, these elements create a robust foundation that makes the following primitives possible.\nGetting Started with LayerZero Concepts\nNew to blockchain interoperability? Start with our foundational concept modules that progressively build from basic principles to LayerZero’s specific approach:\nFoundational Concepts\n-\nModule 1: Interoperability Foundations\nExplore the fundamental approaches to blockchain interoperability—from trusted intermediaries to cryptographic proofs—and understand the trade-offs that shape crosschain architecture decisions.\n-\nModule 2: Interface Coupling Problems\nLearn why traditional bridges create tight coupling between applications and infrastructure, and how this architectural limitation constrains innovation and security.\n-\nModule 3: LayerZero Protocol Architecture\nDiscover LayerZero’s five-layer separation of concerns—from immutable endpoints to configurable libraries—that enables composable crosschain architectures without compromising security.\nImplementation Concepts\n-\nModule 4: Verification & Execution Services\nUnderstand how LayerZero’s worker services—Decentralized Verifier Networks (DVNs) and Executors—provide configurable security models and permissionless message delivery.\n-\nModule 5: Application Design Patterns\nMaster the core patterns for building Omnichain Applications (OApps), from basic messaging to advanced coordination patterns across multiple blockchains.\n-\nModule 6: Value Transfer Implementations\nLearn how LayerZero’s token standards (OFT, ONFT) implement secure crosschain asset movement through specialized messaging with token-specific invariants.\nThese modules provide a structured learning path from theoretical foundations to practical implementation, equipping you with the knowledge to build secure, scalable omnichain solutions.\nDeveloper Documentation\nReady to start building? Explore our platform-specific implementation guides and deployment resources:\nPlatform-Specific Development\n-\nEVM Development\nComplete guide to building LayerZero applications on Ethereum Virtual Machine chains using Solidity contract standards.\n-\nSolana Development\nBuild omnichain applications on Solana using Rust and Anchor framework with LayerZero’s Solana programs.\n-\nAptos Move Development\nDevelop secure omnichain applications using the Move programming language on Aptos and other Move-based chains.\n-\nHyperliquid Development\nLearn to integrate with Hyperliquid’s unique dual-network architecture using LayerZero Composer patterns.\nNetwork Support & Deployment\n-\nDeployed Contracts\nView all supported blockchain networks with their LayerZero V2 contract addresses, including Endpoints, Message Libraries, and Executors.\n-\nDVN Addresses\nBrowse the complete list of Decentralized Verifier Networks (DVNs) that provide verification services for LayerZero applications across all supported chains.\nFurther Reading\nReady for deeper technical understanding? Explore LayerZero’s core architecture components and key primitives:\nCore Architecture Components\nFor detailed technical understanding of LayerZero’s architectural elements:\n-\nProtocol Overview\nLearn how LayerZero defines secure messaging channels between sender and receiver contracts through immutable Endpoints and standardized Message Packets.\n-\nMessage Library Overview\nUnderstand the modular, immutable libraries that handle message encoding, verification, and processing across different blockchain environments.\n-\nWorkers Overview\nDiscover how Decentralized Verifier Networks (DVNs) and Executors provide verification and execution services through the unified Worker interface.\n-\nOmnichain Applications Overview\nExplore the generic messaging interface that enables applications to send and receive arbitrary data across multiple blockchain networks.\nKey Primitives Built into LayerZero\nLayerZero’s architecture provides a robust set of core primitives that redefine crosschain interaction:\n-\nOmnichain Message Passing (Generic Messaging)\nThis primitive enables applications to send and receive arbitrary data across a fully-connected mesh of blockchains. Applications can push state transitions to any network in the LayerZero mesh.\n-\nOmnichain Tokens (OFT & ONFT)\nUnified token standards that empower the crosschain transfer of both fungible and non-fungible tokens. These standards ensure a consistent global supply through mechanisms like burn/mint or lock/unlock—abstracting away the differences across blockchain environments and providing a seamless token experience.\n-\nOmnichain State Queries (lzRead)\nGo beyond simple messaging—this primitive allows smart contracts to request and retrieve onchain state from other blockchains securely. It empowers your applications to “pull” data across chains efficiently.\n-\nOmnichain Composability\nBy decoupling security from execution, this design enables developers to build complex, multi-step workflows across chains. It breaks down crosschain operations into discrete, manageable messages that achieve instant finality, facilitating advanced use cases and improved user experiences.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://research.lido.fi/latest","domain":"research.lido.fi","title":"Lido Governance - Lido - The Ethereum Liquid Staking Community","hash":"d04f50f1695d1e7133f1d5b390a4e1282c945bf534d4a82ed1abcd46c37fbd9d","tokens":707,"chars":2825,"crawler":"crawler-f6nn","verified":"exact","ts":1791171803750,"text":"Lido Governance\nTopic\nReplies\nViews\nActivity\nWelcome to Lido DAO\nGeneral\n32\n35591\nOctober 1, 2026\nA message to the Lido team\nGeneral\n33\n716\nOctober 4, 2026\nNode Operator Admission: HostDeFi as stVault Basic Operator\nstVaults Identification\n0\n34\nOctober 1, 2026\nCommunity Staking Module\nProposals\n232\n26673\nOctober 1, 2026\nCommunity Staking Module Committee\nProposals\n38\n1519\nOctober 1, 2026\nNode Operator Admission: Northstake as stVault Professional Operator\nstVaults Identification\n5\n229\nOctober 1, 2026\nThe Guided Open Objective Setting Exercise (“GOOSE”) proposal; A genesis step to jump-start a DAO-wide goal setting exercise and cadence\nProposals\n25\n7031\nOctober 1, 2026\nAuthorize a Contingent LDO CEX Liquidity Market-Making Mandate\nProposals\n34\n956\nOctober 1, 2026\n[Security Disclosure] MetaMask Staking Precautionary Out of Order Exits\nNode Operators\n0\n1357\nSeptember 30, 2026\nLido on Cosmos: Initial Deployment\nProposals\n6\n4972\nSeptember 30, 2026\nCurated Module Committee (CMC) reporting thread\nGeneral\n4\n147\nSeptember 30, 2026\nEIP-7251: Effects on Rewards & Risks\nGeneral\n3\n903\nSeptember 29, 2026\nLEGO Grant Proposal: trace-interop, cross-client trace_* API standardization\nCommunity Grants / Initiatives\n0\n76\nSeptember 29, 2026\nLido Earn DAO Treasury Allocation — Q2 2026\nFinance\n3\n187\nSeptember 29, 2026\nCSM does not count my High Signal score (~100) — missing exactly 1 point to pass ICS\nCSM Support\n8\n244\nSeptember 29, 2026\nFuture of the Curated Module | CMv2 Landscape\nProposals\n38\n3292\nSeptember 28, 2026\nNode Operator Admission: Myrmidon Staking as stVaults Professional Operator\nstVaults Identification\n1\n94\nSeptember 28, 2026\nLIP-37: Execution Delegation Framework (EDF)\nThe LIP - Lido Improvement Proposal - Process\n32\n846\nSeptember 25, 2026\nProposal: Add Easy Track factory for Deposit Reserve Target management by CMC\nProposals\n12\n318\nSeptember 25, 2026\nUtilizing Market Opportunities: stETH / LDO trade\nProposals\n74\n6470\nSeptember 25, 2026\nProposal for Comprehensive Expense Optimization and NEST/stETH Buyback Parameter Restructuring\nProposals\n3\n322\nSeptember 24, 2026\nKuzmich Delegate Thread\nDelegate Platform\n45\n991\nSeptember 24, 2026\nPRO Delegators - Delegate Thread\nDelegate Platform\n6\n280\nSeptember 22, 2026\nAnthony Leuts - Delegate Thread\nDelegate Platform\n44\n1380\nSeptember 22, 2026\nLido Alliance proposes Leeward as a new Supervisor\nProposals\n3\n145\nSeptember 21, 2026\nPost-mortem — Gateway.fm AS (NO 35): August 2026 incidents\nNode Operators\n0\n54\nSeptember 21, 2026\nstVaults Committee Proposal\nLido V3\n19\n1006\nSeptember 21, 2026\n[Post-Mortem] Stakefish Lido Validator Connectivity Loss - August 7-8, 2026\nNode Operators\n0\n86\nSeptember 20, 2026\nBatux Delegate Thread\nDelegate Platform\n9\n279\nSeptember 19, 2026\nPol Lanski Delegate Thread\nDelegate Platform\n34\n1303\nSeptember 18, 2026\nnext page →"}
{"url":"https://docs.openzeppelin.com/contracts","domain":"docs.openzeppelin.com","title":"OpenZeppelin Contracts | OpenZeppelin Docs","hash":"8f81e47d0fc3642da9c289713039001926a3580b25a57bb531f78d6c9c89f7d6","tokens":610,"chars":2439,"crawler":"crawler-f6nn","verified":"exact","ts":1791171806545,"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.across.to/","domain":"docs.across.to","title":"Across Developer Documentation","hash":"b72a61491b23761808b6af4126c0561b31ab7e55f0241373ca10d1b0b225e8cc","tokens":103,"chars":409,"crawler":"crawler-f6nn","verified":"exact","ts":1791171808581,"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.near.org/chain-abstraction/what-is","domain":"docs.near.org","title":"What is Chain Abstraction? - NEAR Docs","hash":"ba301a6d349a4c749bea146ec80017cbca3b6f403ce37c1e2d5a4560730f8d45","tokens":632,"chars":2527,"crawler":"crawler-f6nn","verified":"exact","ts":1791171811137,"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\nWhat is Chain Abstraction?\nLearn how NEAR allows you to seamlessly work across all chains\nThrough a combination of innovative technologies, NEAR enables developers to build applications that work seamlessly across multiple blockchains while abstracting away the underlying complexity for both developers and end users.\nMulti-Chain Accounts\nChain Signatures allow NEAR accounts and smart contracts to sign transactions for all other chains (including Bitcoin, Ethereum and Solana)\nSwaps via Intents\nA decentralized system where users simply express desired outcomes (like “swap BTC for ETH at the best price”), and a network of solvers competes to fulfill these intents optimally\nOmniBridge\nA multi-chain bridge that enables secure and efficient cross-chain transfers. The bridge serves as both a token factory and custodian, managing native and bridged tokens through a unified interface\nWhy Chain Abstraction Matters\nBy building on NEAR, developers do not need to worry about the complexities of integrating with multiple blockchains. Instead, they can focus on building great applications that work seamlessly across all chains.\nMeanwhile, users can enjoy a smooth experience, using unified accounts and assets without needing to even understand on which blockchain they are operating.\nBenefits for Developers\n- Integrate with multiple blockchains through a single NEAR API\n- Focus on application logic instead of blockchain complexity\n- Reach users regardless of their preferred blockchain network\nBenefits for Users\n- Operate across all chains using a single NEAR account\n- Access assets and services from multiple blockchains seamlessly\n- Enjoy a unified and intuitive user experience\nExample: Cross-Chain NFT Marketplace\nImagine building a digital art marketplace where users can purchase NFTs from different blockchains (Ethereum, Solana, etc.). Without chain abstraction, you’d need to:\n- Implement multiple blockchain connections\n- Handle different wallet types\n- Manage cross-chain transfers\n- Build complex UIs to explain blockchain concepts\nWith chain abstraction, both you and your users just focus on the core experience: browsing and trading art. All blockchain complexity is handled automatically behind the scenes.\nWas this page helpful?"}
{"url":"https://solana.com/docs/core/cpi","domain":"solana.com","title":"","hash":"92a89596610a5e4f7e2b17e95cc1f0c7af2c1314968517eecbbd66dd50c7a437","tokens":1301,"chars":5203,"crawler":"crawler-f6nn","verified":"exact","ts":1791171813214,"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/","domain":"docs.getmonero.org","title":"Monero Docs - Monero Docs","hash":"b900e90566892f2cc2832f86e9d1b55809dcde016ab07f789c380b5f104859ea","tokens":302,"chars":1207,"crawler":"crawler-f6nn","verified":"exact","ts":1791171815986,"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://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-f6nn","verified":"exact","ts":1791171818438,"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. Use --trace for debugger input.\"\ndocs=\"/references/cli/replay\"\n/>\n- [Move Trace Debugger](/references/ide/debugger): Step-through debugger for Move execution traces with variable inspection and breakpoints.\n- [Object Display V2 Templates](/develop/objects/display/display-preview): Build and preview Display templates for on-chain objects.\n- [SuiBase](https://suibase.io/): Create workdirs, each defining a distinct development environment targeting a network.\n- [Sentio Debugger](https://docs.sentio.xyz/docs/debugger): Shows the trace of a transaction. Mainnet only.\n### Faucets\nObtain testing tokens for Testnet deployment.\n- [Sui Faucet](https://faucet.sui.io/): Request Testnet or Devnet SUI tokens for development and testing.\n- [N1 Stake Faucet](http://faucet.n1stake.com/): Community-provided faucet for obtaining Testnet SUI tokens.\n- [SuiLearn Faucet](http://faucet.suilearn.io/): Community-provided faucet for obtaining Testnet SUI tokens.\n## Security and auditing\nFormal verification, source verification, linting, and phishing protection.\n- [Sui Prover](https://info.asymptotic.tech/sui-prover): Prover for doing formal verification of Move on Sui code.\n- [Package Source Code Verification](https://docs.blockberry.one/docs/contract-verification): Verify your package source code on Suiscan, powered by WELLDONE Studio and Blockberry.\n- [SuiSecBlockList](https://github.com/SuiSec/SuiSecBlockList): Block malicious websites and packages. Identify and hide phishing objects.\n- [Guardians](https://github.com/suiet/guardians): Phishing website protection for Sui.\n- [HoneyPotDetectionOnSui](https://github.com/SuiSec/HoneyPotDetectionOnSui): Detect honeypot scams on Sui.\n- [Sui RPC Proxy](https://github.com/SuiSec/sui-rpc-proxy): Monitor and analyze the network requests made by wallet applications and Sui apps.\n## Data and indexing\nIndexers, data APIs, and analytics services for querying on-chain state.\n- **Sui GraphQL RPC**: Rich data query interface for Sui.\n- [ZettaBlock](https://docs.zettablock.com): Generate custom GraphQL or REST APIs from SQL queries and incorporate private off-chain data.\n- [Sentio Indexer](https://docs.sentio.xyz/docs/sui): Transform raw indexed data into meaningful queryable data by writing custom processor logic.\n- [BlockVision](https://docs.blockvision.org/reference/welcome-to-blockvision): Pre-built APIs for Sui indexed data including tokens, NFTs, and DeFi.\n- [Blockberry (Suiscan)](https://docs.blockberry.one/reference/sui-quickstart): API providing endpoints for significant entities on Sui, including NFTs, domains, collections, coins, and market data.\n- [Space and Time (SxT)](https://docs.spaceandtime.io/): Verifiable compute layer for AI and blockchain. Decentralized data warehouse with sub-second ZK proof.\n- [Birdeye Data Services](https://data.birdeye.so/docs/authentication): Crypto market data APIs on Sui.\n- [Indexer.xyz (TradePort)](https://tradeport.xyz/docs): Toolkit for accessing NFT data and integrating trading functionality on Sui.\n- [Dubhe Indexer (Dubhe Engine)](https://dubhe-docs.obelisk.build/dubhe/sui/indexer): Automatic indexing of all events based on Dubhe Engine configuration files.\n- [Surflux](https://docs.surflux.dev/): Developer infrastructure for Sui. Build production-ready apps with APIs, indexing, and real-time data streams.\n- [Indexer Generator](https://www.npmjs.com/package/sui-events-indexer): Code generator that creates an indexer for all events in a given smart contract. Uses TypeScript and Prisma.\n- [OKLink](https://www.oklink.com/sui): Explorer and data APIs for Sui.\n## Explorers\nBlock explorers and network monitoring dashboards.\n- [SuiVision](https://docs.blockvision.org/reference/integrate-suivision-into-your-dapp): Data analytics covering transactions, wallets, staking, and validators.\n- [Suiscan](https://docs.blockberry.one/reference/welcome-to-blockberry-api): Explorer and analytics platform for Sui.\n- [Polymedia Explorer](https://explorer.polymedia.app): Community fork of the discontinued Sui Explorer from Mysten Labs. Available to build locally or use online.\n- [Local Sui Explorer](https://github.com/suiware/sui-explorer): Sui Explorer for your localnet.\n- [Suimon](https://github.com/bartosian/suimon): Command-line tool providing detailed dashboards for monitoring the Sui network.\n- [RPC Tools (Polymedia)](https://rpcs.polymedia.app/): Web app that helps users find the fastest RPC endpoint for their location.\n- [devxplorer](https://devxplorer.io/): Developer-focused explorer built on GraphQL. Works with local and custom RPCs, focusing on transactions, effects, objects, events, packages, and types.\n- [Sui Data Stack Explorer](https://github.com/abhinavg6/sui-data-stack-explorer): AI-native explorer with smart routing across gRPC, GraphQL, and Archival Service. Includes a Pulse checkpoint feed and an object Time Machine for historical inspection.\n## Oracles\nPrice feeds and off-chain data delivery for on-chain contracts.\n- [Pyth Network](https://docs.pyth.network/price-feeds/use-real-time-data/sui): Oracle protocol that connects the owners of market data to applications on multiple blockchains including Sui.\n- [Supra Oracles](https://docs.supra.com/oracles/data-feeds/pull-oracle#sui): Oracle protocol providing reliable data feeds through pull and push models.\n- [Switchboard](https://docs.switchboard.xyz/docs-by-chain/sui): Data feed customization and management for Sui.\n## AI\nAutonomous agents, verifiable inference, and TEE infrastructure.\n- [Talus](https://docs.talus.network/): Build autonomous digital economy powered by Sui.\n- [Atoma](https://atoma.network/): Developer-focused infrastructure for private, verifiable, and customized AI experiences.\n- [Eliza](https://github.com/elizaOS/eliza): Framework for building autonomous agents.\n- [Sui Pilot](https://contract-hero.github.io/sui-pilot/): Claude Code plugin that bundles Sui ecosystem docs, a Move LSP bridge, and formal verification tooling into a doc-first development agent.\n- [Local Sui MCP Server](https://github.com/abhinavg6/sui-mcp-server): Local MCP server exposing 29 agent-callable tools for querying Sui via gRPC, GraphQL, and Archival Service with automatic transport routing.\n- [WaaP CLI](https://docs.waap.human.tech/for-agents): Agent payments from a headless wallet, with spend caps the AI agent cannot raise. Scoped, expiring grants let it transact autonomously on Sui, Solana and EVM.\n## Sui stack tooling\nTooling for other pieces of the Sui stack, including Walrus, Seal, and Nautilus.\n- [Walrus CLI](https://docs.wal.app/getting-started/advanced-setup): CLI for interacting with the Walrus platform for configuration, orchestration, and environment setup.\n- [Walrus site-builder](https://docs.wal.app/sites/getting-started/installing-the-site-builder): CLI tool that lets you create, edit, and publish Walrus Sites.\n- [Seal CLI](https://github.com/MystenLabs/seal/tree/main/crates/seal-cli): Command-line interface for Seal encryption and access control.\n- [Nautilus Ops](https://github.com/Ashwin-3cS/nautilus-ops): Operations tooling for Nautilus.\n- [Nautilus TypeScript](https://github.com/unconfirmedlabs/nautilus-ts): TypeScript utilities for Nautilus.\n- [Marlin Oyster and Nautilus](https://docs.marlin.org/oyster/build-cvm/guides/sui-oyster/): Trusted execution environment (TEE) infrastructure for AI and blockchain workloads on Sui.\n## SDKs\nSDKs for building on Sui, grouped by language. Use the filter bar to search by language name.\n### TypeScript\n- [Sui TypeScript SDK](https://sdk.mystenlabs.com/typescript): Modular library of tools for interacting with Sui, maintained by Mysten Labs.\n- [Enoki TypeScript SDK](https://docs.enoki.mystenlabs.com/ts-sdk): TypeScript SDK for Enoki.\n- [Enoki Connect SDK](https://docs.enoki.mystenlabs.com/enoki-connect): TypeScript SDK for Enoki Connect integration.\n- [Seal SDK](https://seal-docs.wal.app/GettingStarted/): TypeScript SDK for Seal, providing encryption and access control on Sui.\n- [zkSend SDK](https://sdk.mystenlabs.com/zksend): TypeScript SDK for sending assets through zkSend on Sui.\n- [DeepBookV3 SDK](https://www.npmjs.com/package/@mysten/deepbook-v3): TypeScript SDK for integrating with DeepBook V3.\n- [Slush Wallet SDK](https://sdk.mystenlabs.com/slush-wallet/dapp): TypeScript SDK for integrating Slush Wallet into your app.\n- [Kiosk SDK](https://sdk.mystenlabs.com/kiosk): TypeScript SDK for building with Sui Kiosk, the decentralized commerce primitive.\n- [Walrus SDK](https://sdk.mystenlabs.com/walrus): TypeScript SDK for integrating with Walrus decentralized storage.\n- [PAS TypeScript SDK](https://www.npmjs.com/package/@mysten/pas): Programmable Asset Standard TypeScript package.\n- [Sui Wallet Standard](/onchain-finance/asset-custody/wallets/wallet-standard): Standard TypeScript utilities for implementing wallets and libraries based on the Wallet Standard.\n- [BCS TypeScript](https://sdk.mystenlabs.com/bcs): Binary Canonical Serialization library for TypeScript.\n- [Codegen](https://sdk.mystenlabs.com/codegen): Code generation utilities for the Sui TypeScript SDK.\n- [Payment Kit](https://sdk.mystenlabs.com/payment-kit): SDK for handling payments on Sui.\n- [Sui Kit (Scallop)](https://github.com/scallop-io/sui-kit): Toolkit for interacting with the Sui network in TypeScript.\n- [Sui Client Gen (Kuna Labs)](https://github.com/kunalabs-io/sui-client-gen): Generate TypeScript SDKs for Sui Move smart contracts. Works with source code and on-chain packages, no IDLs or ABIs required.\n- [TypeMove (Sentio)](https://github.com/sentioxyz/typemove/blob/main/packages/sui/Readme.md): Generate TypeScript bindings for Sui contracts.\n- [CoinMeta (Polymedia)](https://github.com/juzybits/polymedia-coinmeta): Library for fetching coin metadata for Sui coins.\n- [Dubhe Client](https://dubhe-docs.obelisk.build/): Multi-platform client supporting browsers, Node.js, and game engines for interacting with Sui Move contracts.\n- [Dubhe Client BCS Decoding](https://github.com/0xobelisk/dubhe-docs/blob/main/pages/dubhe/sui/client.md#bcs-data-decoding): Automatic parsing of BCS types based on contract metadata with automatic conversion formatting.\n- [dApp Kit (Vue)](https://github.com/SuiFansCN/suiue): Sui dApp Kit for the Vue framework.\n### Rust\n- [Sui Rust SDK](https://docs.rs/sui-graphql/latest/sui_graphql/): Rust SDK for interacting with Sui. Supports gRPC and GraphQL.\n- [Walrus Rust SDK](https://github.com/MystenLabs/walrus/tree/main/crates/walrus-core): Rust SDK for interacting with Walrus.\n- [Legacy Sui Rust SDK](https://mystenlabs.github.io/sui/sui_sdk/index): Legacy Rust crate providing the wallet and client configuration used by the Sui CLI. Use the current Sui Rust SDK for new integrations.\n- [Rust External Signers](https://github.com/MystenLabs/rust-signers): Rust-based external signer implementations for Sui.\n- [BCS Rust](https://github.com/zefchain/bcs): BCS serialization and deserialization in Rust.\n### Python\n- [Pysui](https://pysui.readthedocs.io/): Python SDK for interacting with Sui.\n### Go\n- [Sui Go SDK (SuiVision)](https://pkg.go.dev/github.com/block-vision/sui-go-sdk): Golang SDK to interact with Sui.\n- [Sui Go SDK (Pattonkan)](https://pkg.go.dev/github.com/pattonkan/sui-go): Golang SDK with PTB and devInspect support.\n### Kotlin\n- [Sui Kotlin SDK (Ksui)](https://suicookbook.com): Kotlin Multiplatform SDK for integrating with Sui.\n- [BCS Kotlin](https://suicookbook.com/bcs): BCS serialization and deserialization in Kotlin.\n### Swift\n- [SuiKit](https://github.com/opendive/suikit): Swift SDK natively designed for developing on Sui.\n- [BCS Swift](https://github.com/OpenDive/SuiKit/tree/main/Sources/SuiKit/Utils/BCS): BCS serialization and deserialization in Swift.\n### Dart\n- [Sui Dart SDK](https://pub.dev/documentation/sui/latest/): A cross-platform Dart SDK to interact with Sui.\n- [BCS Dart](https://github.com/mofalabs/bcs): BCS serialization and deserialization in Dart.\n### C# and Unity\n- [Sui Unity SDK (OpenDive)](https://github.com/OpenDive/Sui-Unity-SDK): Fully featured Unity SDK with offline transaction building.\n- [BCS Unity](https://github.com/OpenDive/Sui-Unity-SDK/tree/main/Assets/Sui-Unity-SDK/Code/OpenDive.BCS): BCS serialization and deserialization in Unity C#.\n### DeFi protocol SDKs\nThese SDKs are built and maintained by their respective protocol teams for integrating with specific DeFi protocols on Sui.\n- [NAVI Protocol SDK](https://github.com/naviprotocol/navi-sdk): TypeScript SDK for interacting with NAVI Protocol on Sui.\n- [Bucket Protocol SDK](https://github.com/Bucket-Protocol/bucket-protocol-sdk): TypeScript SDK for interacting with Bucket Protocol.\n- [Suilend SDK](https://www.npmjs.com/package/@suilend/sdk): TypeScript SDK for interacting with the Suilend program.\n- [Scallop SDK](https://github.com/scallop-io/sui-scallop-sdk): TypeScript SDK for interacting with the Scallop lending protocol on Sui.\n- [Cetus CLMM SDK](https://github.com/CetusProtocol/cetus-clmm-sui-sdk): SDK for integration with Cetus-CLMM on Sui.\n- [Aftermath SDK](https://github.com/AftermathFinance/aftermath-ts-sdk): TypeScript SDK for interacting with Aftermath Protocol.\n- [FlowX SDK](https://github.com/FlowX-Finance/sdk): TypeScript SDK for interacting with FlowX protocols.\n- [7k Aggregator SDK](https://github.com/7k-ag/7k-sdk-ts): TypeScript SDK for interacting with 7k Aggregator protocol.\n## APIs\n- [Sui gRPC API](https://github.com/MystenLabs/sui-apis/tree/main): gRPC API definitions and protocol buffers for Sui.\n- [Enoki API](https://docs.enoki.mystenlabs.com/): REST API for zkLogin and sponsored transactions.\n## Misc\n- [OpenZeppelin Contracts for Sui](https://docs.openzeppelin.com/contracts-sui): Audited libraries including deterministic arithmetic, decimal scaling, and ownership-transfer wrappers.\n- [Minting Server](https://github.com/MystenLabs/minting-server): A scalable system architecture that processes multiple Sui transactions in parallel using a producer-consumer worker scheme.\n- [Docker Sui Node Image](https://hub.docker.com/r/mysten/sui-node): Official Docker image for running a Sui node.\n- [Sui Terraform Modules](https://github.com/bartosian/sui-terraform-modules): All-in-one solution for deploying, monitoring, and managing Sui infrastructure.\n- [Sui Tears (Interest Protocol)](https://docs.interestprotocol.com/overview/sui-tears): Open source, production-ready Sui Move library for new and experienced developers.\n- [Sui Codec](https://github.com/sui-potatoes/app/tree/main/packages/codec): Encoding solution for Sui.\n- [SkipList (Cetus)](https://github.com/CetusProtocol/move-stl): A skip list implementation in Move on Sui.\n- [IntegerMate (Cetus)](https://github.com/CetusProtocol/integer-mate): Move module providing signed integer and integer math functions.\n- [Cetus CLMM Contracts](https://github.com/CetusProtocol/cetus-contracts/tree/main/packages/cetus_clmm): Open source Cetus CLMM DEX contracts.\n- [SuiDouble Metadata](https://github.com/suidouble/suidouble_metadata): Move library and tools to store, retrieve, and manage primitive data as chunks in a vector without dependencies.\n- [SuiGPT Decompiler](https://suigpt.tools/decompile): Uses generative AI to convert Move bytecode back to source code.\n- [Revela](https://revela.verichains.io/): Decompile Sui smart contracts to recover Move source code.\n- [Sui Token CLI](https://github.com/otter-sec/sui-token-gen): Rust-based CLI tool and RPC service for generating and verifying Sui token smart contracts.\n- [Dubhe Engine (Obelisk Labs)](https://dubhe.obelisk.build/): Open source toolchain for building intent-centric worlds with Move applications.\n- [Dubhe CLI (Dubhe Engine)](https://dubhe-docs.obelisk.build/dubhe/sui/cli): CLI for building and managing apps built on Dubhe Engine in Sui.\n- [Sui Protocol Config](https://github.com/MystenLabs/sui/blob/main/crates/sui-protocol-config/src/lib.rs): Transaction limits and protocol configuration values for Sui.\n- [Polymedia Commando](https://github.com/juzybits/polymedia-commando): Command-line tools for Sui airdrops, data gathering from RPCs and indexers, and more.\n- [sui-tool](https://github.com/MystenLabs/sui/tree/main/crates/sui-tool): Internal diagnostic utility for Sui network operations."}
{"url":"https://docs.openzeppelin.com/ecosystem-adapters","domain":"docs.openzeppelin.com","title":"Ecosystem Adapters | OpenZeppelin Docs","hash":"a182d85cb4ea92cd4d80cf42c7698c566b88584bc41cea2a9cc15a34147200b2","tokens":875,"chars":3500,"crawler":"crawler-f6nn","verified":"exact","ts":1791171827526,"text":"Home Forum Website Impact\nEcosystem Adapters\nOpen in Claude\nOpenZeppelin Ecosystem Adapters are a set of modular, chain-specific integration packages that let applications interact with any supported blockchain through a single, unified interface. Built on 13 composable capability interfaces organized in 3 tiers, each adapter encapsulates contract loading, type mapping, transaction execution, wallet connection, and network configuration in one place, while keeping consuming applications completely chain-agnostic.\nSource code : The adapters are open-source. Browse the implementation, open issues, and contribute at github.com/OpenZeppelin/openzeppelin-adapters .\nArchitecture\nUnderstand the capability-based architecture: tiers, profiles, and the runtime lifecycle.\nGetting Started\nInstall adapters, configure profiles, and run your first cross-chain interaction.\nSupported Ecosystems\nExplore the production-ready EVM, Stellar, Polkadot, and Midnight adapters.\nBuilding an Adapter\nStep-by-step guide to implementing a new adapter for your blockchain.\nWhy Adapters?\nBuilding cross-chain tooling traditionally forces developers into one of two traps: a monolithic abstraction that leaks chain details, or per-chain forks that drift apart over time. Adapters solve this with a capability-based decomposition . Each chain implements only the interfaces it supports, and consuming applications pull in only what they need.\nKey Design Principles\n- Pay for what you use. Tier 1 capabilities are stateless and never pull in wallet SDKs or RPC clients. Import addressing and you get only address validation; nothing else is bundled.\n- Profiles simplify consumption. Five pre-composed profiles (Declarative, Viewer, Transactor, Composer, Operator) match common application archetypes so you don't have to assemble capabilities manually.\n- Adapters own their chains. All chain-specific logic (ABI parsing, Soroban type mapping, ZK proof orchestration) stays inside the adapter package. The consuming application never touches it.\n- Runtime lifecycle is explicit. Runtimes are immutable and network-scoped. Switching networks means disposing the old runtime and creating a new one. There are no hidden state mutations.\nPackages\nPackage Description Status\n@openzeppelin/adapter-evm Ethereum, Polygon, and EVM-compatible chains Production\n@openzeppelin/adapter-stellar Stellar / Soroban Production\n@openzeppelin/adapter-polkadot Polkadot Hub, Moonbeam (EVM path) Production\n@openzeppelin/adapter-midnight Midnight Network (ZK artifacts, Lace wallet) Production\n@openzeppelin/adapter-solana Solana (scaffolding) In Progress\n@openzeppelin/adapter-evm-core Shared EVM capability implementations (internal) Internal\n@openzeppelin/adapter-runtime-utils Profile composition and lifecycle utilities (internal) Internal\n@openzeppelin/adapters-vite Shared Vite/Vitest build integration Utility\nWho Uses Adapters?\nAdapters are consumed by several OpenZeppelin products:\n- UI Builder : full-featured smart contract interaction UI\n- OpenZeppelin UI : shared UI components and React integration\n- UIKit example app (live) : hosted demo of OpenZeppelin UI with ecosystem adapters\n- Role Manager : role and permission management tool\n- RWA Wizard : real-world asset token generation\nAny TypeScript application that needs chain-agnostic blockchain interaction can use adapters directly.\nWebAuthn Smart Accounts\nPrevious Page\nArchitecture\nNext Page\nOn this page\nWhy Adapters? Key Design Principles Packages Who Uses Adapters?"}
{"url":"https://eips.ethereum.org/EIPS/eip-5","domain":"eips.ethereum.org","title":"EIP-5: Gas Usage for `RETURN` and `CALL*`","hash":"501f3388815e8b3355b06daba88f2f354c11fde4ed7a2d413e66a2966de7139d","tokens":1554,"chars":6216,"crawler":"crawler-f6nn","verified":"exact","ts":1791171829793,"text":"Ethereum Improvement Proposals\n🎉 Final\nStandards Track: Core\nEIP-5: Gas Usage for `RETURN` and `CALL*`\nAuthors\nChristian Reitwiessner < c@ethdev.com >\nCreated\n2015-11-22\nTable of Contents\n- Abstract\n- Specification\n- Motivation\n- Rationale\n- Backwards Compatibility\n- Implementation\nAbstract\nThis EIP makes it possible to call functions that return strings and other dynamically-sized arrays.\nCurrently, when another contract / function is called from inside the Ethereum Virtual Machine,\nthe size of the output has to be specified in advance. It is of course possible to give a larger\nsize, but gas also has to be paid for memory that is not written to, which makes returning\ndynamically-sized data both costly and inflexible to the extent that it is actually unusable.\nThe solution proposed in this EIP is to charge gas only for memory that is actually written to at\nthe time the CALL returns.\nSpecification\nThe gas and memory semantics for CALL , CALLCODE and DELEGATECALL (called later as CALL* )\nare changed in the following way ( CREATE does not write to memory and is thus unaffected):\nSuppose the arguments to CALL* are gas, address, value, input_start, input_size, output_start, output_size ,\nthen, at the beginning of the opcode, gas for growing memory is only charged for input_start + input_size , but not\nfor output_start + output_size .\nIf the called contract returns data of size n , the memory of the calling contract is grown to\noutput_start + min(output_size, n) (and the calling contract is charged gas for that) and the\noutput is written to the area [output_start, output_start + min(n, output_size)) .\nThe calling contract can run out of gas both at the beginning of the opcode and at the end\nof the opcode.\nAfter the call, the MSIZE opcode should return the size the memory was actually grown to.\nMotivation\nIn general, it is good practice to reserve a certain memory area for the output of a call,\nbecause letting a subroutine write to arbitrary areas in memory might be dangerous. On the\nother hand, it is often hard to know the output size of a call prior to performing the call:\nThe data could be in the storage of another contract which is generally inaccessible and\ndetermining its size would require another call to that contract.\nFurthermore, charging gas for areas of memory that are not actually written to is unnecessary.\nThis proposal tries to solve both problems: A caller can choose to provide a gigantic area of\nmemory at the end of their memory area. The callee can “write” to it by returning and the\ncaller is only charged for the memory area that is actually written.\nThis makes it possible to return dynamic data like strings and dynamically-sized arrays\nin a very flexible way. It is even possible to determine the size of the returned data:\nIf the caller uses output_start = MSIZE and output_size = 2**256-1 , the area of\nmemory that was actually written to is (output_start, MSIZE) (here, MSIZE as evaluated\nafter the call). This is important because it allows “proxy” contracts\nwhich call other contracts whose interface they do not know and just return their output,\ni.e. they both forward the input and the output. For this, it is important that the caller\n(1) does not need to know the size of the output in advance and (2) can determine the\nsize of the output after the call.\nRationale\nThis way of dealing with the problem requires a minimal change to the Ethereum Virtual Machine.\nOther means of achieving a similar goal would have changed the opcodes themselves or\nthe number of their arguments. Another possibility would have been to only change the\ngas mechanics if output_size is equal to 2**256-1 . Since the main difficulty in the\nimplementation is that memory has to be enlarged at two points in the code around CALL ,\nthis would not have been a simplification.\nAt an earlier stage, it was proposed to also add the size of the returned data on the stack,\nbut the MSIZE mechanism described above should be sufficient and is much better\nbackwards compatible.\nSome comments are available at https://github.com/ethereum/EIPs/issues/8\nBackwards Compatibility\nThis proposal changes the semantics of contracts because contracts can access the gas counter\nand the size of memory.\nOn the other hand, it is unlikely that existing contracts will suffer from this change due to\nthe following reasons:\nGas:\nThe VM will not charge more gas than before. Usually, contracts are written in a way such\nthat their semantics do not change if they use up less gas. If more gas were used, contracts\nmight go out-of-gas if they perform a tight estimation for gas needed by sub-calls. Here,\ncontracts might only return more gas to their callers.\nMemory size:\nThe MSIZE opcode is typically used to allocate memory at a previously unused spot.\nThe change in semantics affects existing contracts in two ways:\n-\nOverlaps in allocated memory. By using CALL , a contract might have wanted to allocate\na certain slice of memory, even if that is not written to by the called contract.\nSubsequent uses of MSIZE to allocate memory might overlap with this slice that is\nnow smaller than before the change. It is, though, unlikely that such contracts exist.\n-\nMemory addresses change. Rather general, if memory is allocated using MSIZE , the\naddresses of objects in memory will be different after the change. Contracts should\nall be written in a way, though, such that objects in memory are relocatable ,\ni.e. their absolute position in memory and their relative position to other\nobjects does not matter. This is of course not the case for arrays, but they\nare allocated in a single allocation and not with an intermediate CALL .\nImplementation\nVM implementers should take care not to grow the memory until the end of the call and after a check that sufficient\ngas is still available. Typical uses of the EIP include “reserving” 2**256-1 bytes of memory for the output.\nPython implementation:\nold: http://vitalik.ca/files/old.py\nnew: http://vitalik.ca/files/new.py\nCitation\nPlease cite this document as:\nChristian Reitwiessner < c@ethdev.com >, \"EIP-5: Gas Usage for `RETURN` and `CALL*`,\" Ethereum Improvement Proposals , no. 5, November 2015. Available: https://eips.ethereum.org/EIPS/eip-5."}
{"url":"https://raw.githubusercontent.com/ethereum/go-ethereum/master/README.md","domain":"raw.githubusercontent.com","title":"","hash":"91d0e5a67228b54610ce481a81b23d09e5b19f261eb0c19c73245407d8766c8a","tokens":3535,"chars":14139,"crawler":"crawler-f6nn","verified":"exact","ts":1791171831902,"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://docs.zksync.io/","domain":"docs.zksync.io","title":"ZKsync Docs","hash":"aea0a0c8b4912678d882a6ead390826b9e1db4a9d8937cab6c562eff063f5836","tokens":262,"chars":1047,"crawler":"crawler-f6nn","verified":"exact","ts":1791171834061,"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://raw.githubusercontent.com/anza-xyz/agave/master/README.md","domain":"raw.githubusercontent.com","title":"Building","hash":"5b46d746eb8b2a5194233084775203dd1f493cb61835ebd82ccdf713634f6503","tokens":1117,"chars":4466,"crawler":"crawler-f6nn","verified":"exact","ts":1791171836370,"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://ethereum.org/developers/tools/","domain":"ethereum.org","title":"Developer builder resources | ethereum.org","hash":"622b582c2add4a54665794213c895afe381b3f2dfb3fdea13493e28d30859597","tokens":9989,"chars":39955,"crawler":"crawler-f6nn","verified":"exact","ts":1791171839556,"text":"Skip to main content\nBuilder resources\nFind the right resources faster and help elevate the builders who create the infrastructure our ecosystem relies on.\nResources found : 440 / 440\nContract tooling\n( 88 )\nContract frameworks\n( 11 )\nApe Framework\nThe smart contract development tool for Pythonistas, Data Scientists, and Security Professionals\nScaffold-ETH 2\nScaffold-ETH 2 is a Next.js plus Hardhat or Foundry starter with wallet hooks, hot contract reload, local faucet utilities, and extension modules for full-stack dapp deployment.\nHuff\nHuff is a low-level assembly language and compiler for writing hand-optimized EVM bytecode, with development continuing in huff2. Builders reach for it when bytecode has to be tuned by hand.\nBrownie\nA Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine.\nRemix Project\nA rich and accessible Web3 toolset for learning, building, and testing on multiple chains\nStylus SDK (Rust)\nThe Stylus SDK is the Rust SDK for writing smart contracts that run in Arbitrum's Stylus environment alongside the EVM. Rust builders use it when contract logic should be written in Rust rather than Solidity.\nBuildBear\nBuildBear is a hosted service that spins up a private testnet sandbox mirroring a real chain such as Ethereum, Polygon, BSC, or Arbitrum. Builders point tests at it to work against a private fork with real chain state.\n@nomicfoundation/slang\nslang from the Nomic Foundation is a modular Solidity compiler frontend with a parser, concrete syntax tree, and bindings. Builders import it when writing a linter, formatter, or other tool that has to understand Solidity source.\nWake\nWake is a Python framework for testing, fuzzing, and static analysis of Solidity projects. Builders reach for it when they want to write contract tests and fuzzing campaigns in Python and run analysis over the same codebase.\npy-solc-x\npy-solc-x is a Python wrapper and version manager for the solc Solidity compiler, used by Brownie and Ape style test suites. Python builders install it to fetch and switch compiler versions from their own scripts.\nMoccasin\nMoccasin is Cyfrin's Python-first workflow on Titanoboa for testing, fuzzing, and deploying Vyper written smart contracts.\nDeployment & devops\n( 25 )\nHardhat\nHardhat is a development environment to build and deploy your Ethereum software\nFoundry\nFoundry is a fast, portable Rust toolchain for Ethereum smart contract engineering that manages dependencies, compiles Solidity, runs fuzz and unit tests, deploys contracts, and drives scripted chain interaction from the terminal or Solidity automation scripts.\nPoWFaucet\nPoWFaucet is a modular testnet faucet for EVM chains with anti-abuse methods including a mining puzzle, captcha, IP limits, and Gitcoin Passport, and it backs the Sepolia proof-of-work faucet. Teams running a testnet self-host it to hand out test ETH without giving it all to one address.\nhardhat-deploy\nhardhat-deploy is a Hardhat plugin for replicable deployments with named accounts, proxies, and diamonds. Builders install it when deployments must be repeatable across networks and track upgradeable contracts.\neth-docker\neth-docker is a Dockerized stack for deploying and managing execution, consensus, and validator clients on mainnet. Node operators use it to run a full node setup from configuration files instead of hand-installed binaries.\nKurtosis ethereum-package\nThe Kurtosis ethereum-package spins up reproducible multi-client Ethereum devnets, including mev-boost and supporting tooling. Builders run it when they need a local network that mirrors a real client mix.\nKurtosis\nKurtosis packages reproducible multi-service devnets so you can spin up realistic Ethereum or rollup stacks for integration tests faster than hand-maintained compose files.\nDAppNode\nDAppNode is an operating system with an app store for running Ethereum execution and consensus clients and other node software on your own hardware. Someone setting up a home node installs it and picks client packages instead of configuring each service by hand.\nsimple-optimism-node\nsimple-optimism-node is a one-command Docker setup for running an OP Stack node. Builders run it to get their own Optimism node, in the same way eth-docker covers mainnet clients.\nethereum-helm-charts\nethereum-helm-charts are Helm charts from ethPandaOps for running Ethereum execution and consensus clients and related infrastructure on Kubernetes. Teams add them to a cluster rather than writing client manifests themselves.\nChainlink Faucets\nChainlink Faucets dispense testnet ETH and LINK across the supported test networks. Builders use them to fund an account before deploying and testing contracts on a testnet.\nDecker\nDecker is a TypeScript CLI for creating configurable local Ethereum devnets with execution and consensus clients, relays, and block builders. Teams use its recipes for integration tests and infrastructure development.\nethereal\nethereal is a Go command line tool for everyday Ethereum tasks, including sending transactions, managing ENS records, transferring tokens, and inspecting accounts. Builders install it for one-off operations that do not justify a script.\nImmunefi\nImmunefi is a bug bounty platform where projects post rewards for whitehats who find and responsibly disclose contract vulnerabilities. Teams list a program there to give researchers a paid route to report issues.\nrocketh\nrocketh is a deployment and test harness for Ethereum contracts built around viem, keeping one record of deployments per network so scripts and tests agree. Builders use it when they want repeatable deployments without Hardhat, which the hardhat-deploy plugin wraps over the same code.\nRocket Pool Smart Node\nRocket Pool Smart Node is the command line package node operators run to set up and manage a Rocket Pool minipool, wrapping execution and consensus clients plus validator duties.\nCreateX\nCreateX is pcaversaccio's trustless universal deployer that wraps CREATE, CREATE2, and CREATE3-style flows so teams can launch contracts from predictable addresses without bespoke factory code.\nfoundry-toolchain (GitHub Action)\nfoundry-toolchain is the official GitHub Action that installs Foundry in continuous integration. Builders add it to a workflow so forge test and forge script run on every pull request.\nxdeployer\nHardhat plugin to deploy your smart contracts across multiple EVM chains with the same deterministic address. A total of 133 EVM chains are currently supported, including (almost) all OP-stack-powered chains.\nSedge\nSedge is a command line setup tool from Nethermind that generates docker-compose configurations for execution, consensus, and validator client combinations. Builders run it to get a working node setup without writing the compose files.\nethereum-genesis-generator\nethereum-genesis-generator creates execution and consensus layer genesis state for a testnet and serves it over a web server. Devnet and rollup teams run it to produce the genesis files for a custom network.\nCreate2Deployer\nCreate2Deployer is a minimal factory contract from pcaversaccio that wraps the CREATE2 opcode with safety checks so teams can deploy counterfactual contracts at deterministic addresses.\ntxtx\nTxtx turns the stress, pain and tears of Smart Contract Infrastructure management by introducing Crypto Infrastructure as Code. Runbooks are the blueprint for Engineering Excellence, setting the new standard for Web3 Infrastructures.\nCannon\nCannon is a DevOps tool for protocols on Ethereum. It manages smart contract deployment and configuration for local development and live networks.\nEthPillar\nEthPillar is a setup script and terminal interface for installing and managing an Ethereum staking node with execution, consensus and MEV-Boost clients. Solo stakers run it to stand up a node without editing client configuration by hand.\nSmart contract libraries & utilities\n( 27 )\nOpenZeppelin Contracts\nOpenZeppelin Contracts are the go-to library for smart contract development.\nSolidity\nSolidity is an object-oriented, high-level language for implementing smart contracts.\nVyper\nPythonic Smart Contract Language for the EVM\nSolarity\nSolidity-Oriented Development Tooling\nSafe Smart Account (Gnosis Safe)\nSafe Smart Account is the widely deployed set of modular multisig smart-account contracts behind Safe. Wallet and treasury builders deploy or extend it to add multisignature control and account modules.\nSolady\nSolady by Vectorized collects aggressively optimized Solidity snippets from Merkle proofs to compression helpers, wrapping careful inline assembly in approachable APIs so advanced developers can ship gas-efficient patterns while learning cutting-edge optimization techniques from a living reference library.\nSolmate\nSolmate is a modern, opinionated collection of gas-optimized Solidity building blocks and utilities for smart contract development.\nFe Language\nFe is a Rust-inspired language targeting the EVM; today you can explore Fe v2's type system via CLI or editor tooling even while bytecode generation is still evolving.\nSolhint\nSolhint is a Solidity linter you wire into editors or CI to enforce style rules and catch footgun patterns early.\nVscode Solidity Extension\nJuan Blanco's VS Code Solidity extension adds syntax highlighting, compile commands, hover metadata, quick fixes, monorepo detection, optional Nethereum codegen, lint integration, and an LSP server.\nERC721A\nERC721A is a gas-optimized ERC-721 implementation with cheap consecutive batch minting. Builders import it when an NFT contract mints several tokens to the same address at once and minting cost matters.\nIntelliJ Solidity\nSolidity plugin for IntelliJ\nWhatsABI\nWhatsABI recovers selectors, proxies, and partial ABIs from bytecode alone-use it in wallets, explorers, or local tools when verified source is missing but you still need calldata decoding.\nPRBMath\nPRBMath is a smart contract library that adds support for fixed-point types and advanced math functions like logarithms and exponentials in Solidity. Operating with 18-decimal numbers, PRBMath is at the same time gas efficient and user-friendly.\nSolc-select\nSolc-select is a command line utility for quickly installing and switching between Solidity compiler versions.\nMulticall3\nMulticall3 is the canonical contract for batching many reads or writes into a single transaction. Builders call it from contracts and scripts to fetch or update state across several contracts in one round trip.\nSolar\nBlazingly fast, modular Solidity compiler written in Rust by Paradigm. Designed as a contributor-friendly compiler stack for faster builds and better diagnostics.\nsnekmate\nState-of-the-art, highly opinionated, hyper-optimised, and secureVyper smart contract building blocks.\nPrettier Solidity\nA Prettier plugin for automatically formatting your Solidity code.\nSolidState Solidity\nSolidState Solidity is an upgradeable-first contract library built around the diamond pattern of EIP-2535. Teams import it when contracts are organized as diamond facets from the start.\nweiroll\nweiroll is an operation-chaining scripting language and set of contracts for composing many EVM calls into one transaction. Teams building call-routing or batching systems use it to express the call sequence as a script.\nSolidity Bytes Arrays Utils Library\nSolidity Bytes Utils is a classic library for concatenating, slicing, and casting dynamic bytes arrays in Solidity memory or storage-long maintained and widely forked across major protocols.\nsolx\nA gas-efficient Solidity compiler for Ethereum powered by LLVM from the ZKsync team and collaborators. Works as a drop-in replacement for solc in workflows like Foundry and Hardhat.\nABDKMath64x64\nABDKMath64x64 is a Solidity library for 64.64-bit binary fixed-point math. Builders import it when a contract needs fixed-point arithmetic that Solidity does not provide natively.\nERC721A-Upgradeable\nERC721A-Upgradeable is the proxy-upgradeable variant of the ERC721A implementation. Builders import it when a proxy-based NFT contract needs the batch minting design of ERC721A.\nDiamondscaffold\nDiamondscaffold is a CLI tool designed to scaffold EIP-2535 diamond projects with an opinionated layout and scripts, making it faster to stand up modular upgradeable proxies.\nsolidity-docgen\nsolidity-docgen generates Markdown documentation for a Solidity project from its NatSpec comments. Teams run it so published docs stay in step with the contract source.\nZK circuits & privacy\n( 25 )\nZK Email\nZK Email provides circuits and SDKs for proving facts about redacted email transcripts onchain. Useful when you want privacy-preserving identity or receipt checks without doxxing inboxes.\nSP1 (Succinct)\nSP1 from Succinct is a zero-knowledge virtual machine that proves correct execution of RISC-V programs, and it is used to generate proofs for rollups and bridges. Teams compile a Rust program with it when a proof must stand in for re-executing that program onchain.\nsnarkjs\nsnarkjs is a JavaScript and CLI toolkit for generating and verifying zkSNARK proofs, and for running common proving workflows in Node.js and the browser.\nCircom\nCircom is a domain-specific language and compiler for writing and compiling arithmetic circuits used in zero-knowledge proof systems.\nSemaphore\nSemaphore is a zero-knowledge protocol for private group membership proofs, enabling anonymous signaling and authentication without revealing identity.\nSelf Protocol\nSelf Protocol provides open identity and proof primitives builders can embed when they need privacy-preserving verification flows tied to wallets or credentials.\nzkTLS/ TLSNotary\nzkTLS / TLSNotary is an open protocol for proving properties of TLS sessions with MPC so verifiers can trust transcripts without seeing full plaintext.\nRISC Zero risc0-ethereum\nrisc0-ethereum holds the integration libraries and verifier contracts for using the RISC Zero zkVM with Ethereum and other EVM chains. Teams proving computation off chain import these crates to settle the resulting proofs onchain.\nMACI\nMACI (Minimal Anti-Collusion Infrastructure) uses zero-knowledge proofs to enable collusion-resistant, private voting and signaling systems on Ethereum.\ngnark-crypto\ngnark-crypto provides elliptic curve and pairing cryptography for BN, BLS12, BLS24, and BW6 curves, and it is the backend of the gnark SNARK library. Go builders import it directly for curve and pairing math.\nMopro\nA toolkit that makes client-side zero-knowledge proving on mobile simple. Connects ZK proof systems (Halo2, Circom) to generate iOS, Android, and browser bindings, leveraging mobile GPU for improved performance.\nZK-Kit\nA monorepo of reusable zero-knowledge libraries across multiple languages (JavaScript, Solidity, Rust, Noir), offering well-tested implementations of cryptographic primitives like Merkle trees, Poseidon hash, and more.\nSonobe\nA modular folding library supporting multiple folding schemes (Nova, HyperNova, ProtoGalaxy, CycleFold) and decider backends (Groth16, KZG) for Incremental Verifiable Computation. Supports Arkworks, Circom, Noir, and Noname frontends.\nAnon Aadhaar\nTools for building privacy-preserving applications using Indian government Aadhaar ID cards. Provides ZK circuits, TypeScript, Solidity, and React libraries to enable Aadhaar holders to prove residency without revealing personal data.\nZKPassport\nPrivate identity verification using zero-knowledge proofs. Verify age, country, or proof of personhood without revealing any personal information. Mobile-first design with SDK for integration and onchain registry contracts.\nHalo2\nPSE's re-architected fork of Zcash's Halo2 PLONK proof system, featuring a KZG backend with Solidity verifier for economical L1 verification, support for multiple elliptic curves, and decoupled frontend/backend architecture.\np0tion\nA toolkit for Groth16 Phase 2 Trusted Setup ceremonies. Helps developers create and manage trusted setups for ZK applications, with a companion webapp (DefinitelySetup) for monitoring and participation.\narkworks algebra\narkworks algebra is a set of Rust libraries for finite field, elliptic curve, and polynomial arithmetic, and it is the math layer under many SNARK and STARK toolchains. Rust builders add the ark crates when writing proving code from the ground up.\nLambdaworks\nLambdaworks is a Rust library of SNARK and STARK prover components that can be used piecemeal or assembled into a custom proving system. Teams pull its crates when building their own prover rather than adopting a finished one.\nop-succinct\nop-succinct is a proving engine that generates SP1 validity proofs for OP Stack rollups. Rollup teams deploy it to turn an OP Stack chain into a validity proof rollup, running it as a separate service.\nPlonky3\nPlonky3 is a toolkit of polynomial IOP building blocks for constructing custom SNARK and STARK proving systems, and several zkVM projects build on it. Rust builders add the p3 crates when writing their own proving system.\npowdr\npowdr is a toolkit for accelerating and hardening zkVMs by moving specific computations into custom circuits. Teams running a zkVM use it to generate custom precompiles and check constraints, and its authors still describe the code as experimental.\nrsp (Succinct)\nrsp from Succinct generates zero-knowledge proofs of Ethereum and OP Stack block execution, built on Reth. Its authors describe it as a minimal work in progress that is not meant for production, so it mainly serves teams already building on SP1.\nsnark-verifier (Axiom)\nsnark-verifier generates gas-efficient onchain verifiers for halo2 SNARKs and is maintained by Axiom, forked from the original PSE repository. halo2 developers import the crate to produce the Solidity verifier that checks their proofs onchain.\nPerpetual Powers of Tau\nAn ongoing (since 2019) zk-SNARK trusted setup ceremony for circuits up to 2^28 constraints, generating 530M+ powers of tau. A multi-party ceremony where security holds as long as one participant is honest.\nSecurity & testing\n( 56 )\nDebugging & inspection\n( 31 )\nSemgrep (smart-contracts rules)\nSemgrep is a pattern-based static analysis tool with rulesets for Solidity vulnerabilities. Builders run those rules over a codebase to catch known vulnerable patterns and style issues before review.\nheimdall-rs\nheimdall-rs is a Rust EVM toolkit that disassembles bytecode, decompiles contracts, generates control flow graphs, and decodes calldata and traces. Builders reach for it when they need to understand a contract that has no published source.\nsol2uml\nsol2uml generates UML class and storage-layout diagrams from Solidity source or from verified contracts. Builders run it to see contract relationships and how state variables are packed into storage.\nCodeTracer\nCodeTracer is a user-friendly time-traveling debugger designed to support a wide range of web3 programming languages.\nEDB: The Ethereum Project Debugger\nEDB is a source-level debugger for Solidity execution with stepping, locals, watches, and breakpoints when you need IDE-grade visibility into contract behavior onchain or in tests.\nABI Calldata Layout Visualizer\nThe ABI Calldata Layout Visualizer decodes ABI calldata and draws its byte layout, showing where heads, tails, and offsets sit in the encoded payload. Builders open it when a plain decoder does not explain why an encoding is wrong.\nEVMConnector\nEVMConnector is a browser workspace for calling contract functions on any EVM chain, with saved contracts and shareable call links. Builders use it to drive a contract without writing a script.\nHashEx ABI Encoder\nThe HashEx ABI Encoder is a web form that ABI-encodes constructor and function arguments from a pasted signature and values. Builders use it when they need encoded arguments and are not at a terminal.\nRadar (Auditware)\nRadar, from Auditware, is a static analysis tool that covers Solidity as well as Rust, Anchor, and Stylus contracts. Auditors run it to get findings across a mixed contract codebase.\nrecursive calldata decoder\nA calldata decoder that also unwraps nested function calls. Builders open it when a flat decoder leaves the inner calls of a batched or forwarded transaction unreadable.\nSmartContractGUI\nSmartContractGUI turns an uploaded ABI into an interface for reading from and writing to that contract on any EVM chain. Builders use it when they have an ABI but no frontend.\nsol-profiler\nsol-profiler is a command line tool that lists a Solidity contract's methods with their visibility, mutability and modifiers. Reviewers run it to see the surface of a contract at a glance.\nTenderly\nTenderly provides transaction simulation, trace debugging, alerting, and Virtual TestNets for contracts. Builders use it to replay a failing transaction, watch deployed contracts, and test against a forked network.\nTenderly CLI\nThe Tenderly CLI is the command line client for Tenderly, pushing contracts for verification and driving error tracking, monitoring, and alerting. Builders install it to run those steps from a terminal or a continuous integration job.\nWeb3Client\nWeb3Client is a browser tool for creating, testing, and sharing contract ABIs and the calls made against them. Builders use it to work out a call and hand the result to someone else.\nrevm-inspectors\nrevm-inspectors is a Rust crate of EVM execution hooks and tracing built on revm, and it powers call tracing in Reth and Foundry. Rust builders import it to build their own tracers and debuggers.\npyevmasm\npyevmasm is a Python disassembler and assembler for EVM bytecode from Trail of Bits. Analysis scripts import it to turn bytecode into instructions and back.\nEVMole\nEVMole extracts function selectors, arguments, and control flow from raw EVM bytecode, including contracts with no verified source. Builders point it at an unknown contract to work out what its functions take.\nSimbolik - Solidity Debugger\nSimbolik is a powerful Solidity debugger that combines traditional breakpoint debugging with symbolic execution, enabling developers to explore every possible execution path and uncover vulnerabilities with precision. Available as a VSCode extension, Simbolik integrates seamlessly into existing workflows, offering breakpoint-style debugging, Solidity and EVM-level inspection, and formal verification capabilities.\nAbi Ninja\nAbi Ninja is a browser UI for calling contracts with known ABIs, pasted ABIs, or decompiled bytecode, with proxy-aware reads across many networks including your locally running Hardhat or Anvil node.\nhardhat-tracer\nhardhat-tracer is a Hardhat plugin that prints internal calls, events, and storage operations for a transaction in the console. Hardhat users install it to see what actually happened inside a failing test transaction.\ngeas (Good Ethereum Assembler)\ngeas, the Good Ethereum Assembler, is an assembler for writing raw EVM bytecode by hand, maintained by a go-ethereum core developer. It is used for EIP test cases and other low-level contract work.\nevm-storage\nevm-storage turns a transaction hash into readable state diffs and can list a contract's full storage. Builders install the command line tool when they need to see exactly which storage slots a call changed.\nscopelint\nscopelint is an opinionated formatter and linter for Foundry Solidity projects. Builders install it to hold a codebase to the ScopeLift conventions.\nWalnut\nWeb-based transaction debugger and simulator for the EVM. Open-source and self-hostable. Inspect variable states at every step, simulate transactions before deploying, and profile gas usage. Supports any RPC provider.\nforky\nforky is a fork choice viewer for the Ethereum beacon chain. Consensus client developers self-host it or use the public instances to see and debug fork choice behavior on mainnet and testnets.\ntracoor\ntracoor is an explorer for beacon states and execution traces. Client and protocol developers self-host it to inspect block and state traces on devnets and testnets.\n4byte\n4byte.directory maps four-byte function selectors and 32-byte event-signature hashes to their human-readable signatures. Builders query it when decoding calldata or logs from contracts without a published ABI.\nviem-tracer\nviem-tracer augments a Viem client so failed ethestimateGas and ethsendTransaction calls automatically include human-readable trace output decoded with sourcify.dev, and it adds typed helpers around debug_traceCall so developers can inspect execution without leaving their existing RPC stack.\nhardhat-gas-reporter\nhardhat-gas-reporter is a Hardhat plugin that reports gas used by each function call and deployment while the test suite runs, with optional fiat cost estimates. Hardhat users add it when they need to see the gas impact of a change in the test output.\nSlippy\nSlippy is a Solidity linter for static analysis of smart contracts. Teams install the npm package to lint contracts as part of a build.\nFuzz/Property testing\n( 18 )\nChimera\nChimera is a framework to write Solidity tests in foundry and be able to reuse them with other Open Source Tools such as Echidna, Medusa, Halmos and Kontrol\nSlither\nSlither is Trail of Bits' Python static analysis engine for Solidity and Vyper: run it in CI to fire detectors, print structural views of contracts, or script custom checks over whole codebases.\nEchidna\nEchidna is a property-based and grammar fuzzer for Ethereum smart contracts. Builders and auditors write properties with it to find inputs that break contract invariants.\nSynpress\nSynpress layers Playwright with Ethereum-aware browser automation so you can end-to-end test dapps, including wallet popups and chain switches, in CI.\nItyFuzz\nItyFuzz is a bytecode-level smart-contract fuzzer that combines fuzzing with symbolic analysis. Builders and auditors run it against EVM bytecode when source-level fuzzing is not enough or no source is available.\nAderyn\nAderyn is Cyfrin's open-source, Rust-based solidity smart contract static analyzer designed to help protocol engineers and security researchers find vulnerabilities in Solidity code bases\nMedusa\nMedusa is a stateful smart contract fuzzer inspired by Echidna. It provides parallelized fuzz testing of smart contracts and the verification of advanced smart contract invariants.\neth-tester\neth-tester is a pluggable in-memory Ethereum backend used by web3.py for fast unit tests. Python builders import it when tests should run against a simulated chain instead of a node.\nTitanoboa\nTitanoboa is an interactive Vyper interpreter and test harness for fast feedback loops when you are experimenting with contracts outside a full Foundry loop.\nHive\nHive is an end-to-end integration test harness that runs Ethereum clients in Docker across simulator scenarios. Client teams use it to check that implementations agree with each other.\ngoevmlab\ngoevmlab is an EVM fuzzing and differential testing lab built by a go-ethereum core developer. EVM implementers use it to fuzz their own implementation and compare its behavior against others to find divergences.\nsolidity-coverage\nsolidity-coverage provides smart-contract code coverage for the Hardhat developer platform. It's highly accurate, supports full viaIR solidity compilation and a large set of solidity-specific code branch patterns. It's installed on ~230k Github projects and is downloaded ~100k times a week from NPM.\nhevm\nhevm is an open source, state-of-the art, fast symbolic and concrete EVM execution engine that can find issues in smart contracts. Through its symbolic execution and analysis system, hevm can symbolically, semi-concretely, or concretely execute contracts to find bugs, or compare two different contracts for discrepancies, performing equivalence checking.\nCrytic-Properties\nCrytic-Properties is a suite of re-usable security tests for some of the most widely used token standards such as ERC20, ERC721, ERC4626, and more.\ncontender (Flashbots)\ncontender from Flashbots is a load-testing tool that floods EVM execution nodes over JSON-RPC and benchmarks the results. Teams benchmarking a client point it at an endpoint to generate load and measure throughput.\nbulloak\nA smart contract test generator based on the Branching Tree Technique.\nspamoor\nspamoor is a configurable Ethereum transaction generator for load-testing testnets and devnets with realistic traffic. Teams point it at a network to see how it behaves under sustained transaction volume.\nAssertoor\nAssertoor runs configurable checks and assertions against a live Ethereum devnet to validate its behavior. Client and devnet teams use it to confirm a running network is healthy, in the same family as Hive.\nFormal verification\n( 7 )\nK Semantics of the Ethereum Virtual Machine (EVM)\nKEVM is the K-framework executable semantics of the EVM: point it at bytecode when you need conformance-checked execution, symbolic exploration, gas reasoning, or proofs that track Ethereum's rules closely.\nhax\nhax is a tool for high assurance translations of a large subset of Rust into formal languages such as F* or Rocq.\nCertora Prover\nCertora Prover is a cloud formal-verification service that checks specifications written in CVL against deployed contract code. Verification engineers use it to prove that a contract holds stated properties for all inputs.\nKontrol - formal verification tool based on Foundry and KEVM\nKontrol lifts Foundry property tests into KEVM-backed proofs so you can chase formal guarantees with less hand-written specification work than raw KEVM alone.\nAct\nAct is Ethereum's declarative specification language and toolchain for describing all behaviors of an EVM program so SMT solvers, theorem provers, or economic analysis tools can reason about bytecode-level correctness and incentive compatibility, including automatic refinement proofs against concrete implementations.\nVerifereum\nVerifereum connects Ethereum smart contracts to HOL4-backed theorem proving so you can aim at very strong correctness claims when automated SMT approaches are not enough.\nCertora AutoProver\nCertora AutoProver is an AI bot that automates parts of formal verification for smart contracts. Verification engineers use it to generate and run checks with less manual specification work.\nApp integration\n( 124 )\nCore SDKs/libraries\n( 35 )\nWeb3j\nLightweight, modular, reactive Java and Android library for Ethereum. JSON-RPC client API, wallet support, and auto-generated Solidity contract wrappers for deployment and interaction. Includes CLI, Maven/Gradle plugins, and ENS support.\nweb3.py\nweb3.py is the open source library that connects Python developers to Ethereum. The same team maintains more than a dozen additional building blocks including py-evm, eth-account, and eth-utils.\ngo-ethereum (ethclient/accounts/abigen)\ngo-ethereum ships Go packages for Ethereum development, including the ethclient RPC client, account and key handling, and abigen for type-safe contract bindings. Go builders import them to talk to nodes and call contracts from generated code.\nEthers.js\nEthers.js is a compact TypeScript library for scripts, wallets, and services that need predictable JSON-RPC, ABI encoding, and signing helpers in Node or the browser.\nViem: TypeScript Interface for Ethereum\nViem is the most used modern TypeScript Interface for Ethereum. Viem provides robust, performant, and type-safe modules to be the foundation for building Web Applications, TypeScript Libraries, Wallets, Backends, Indexers, Scripts, and more, on top of Ethereum.\nNethereum\nNethereum is the .Net integration library for Ethereum, simplifying the access and smart contract interaction with Ethereum nodes both public like Geth (or your preferred client) L2 chains like Optimism, Arbitrum (or your preferred L2), any compatible EVM chain (Gnosis, etc) and permissioned chains like Quorum.\nRust Libp2p\nrust-libp2p is the reference Rust implementation of libp2p's modular peer-to-peer stack used by Magi on the OP Stack, Lighthouse, Forest, and many other projects that need composable transports, security, pubsub, and discovery primitives for decentralized networking.\nRevm\nRevm is a critical component in the Ethereum ecosystem used by builders, toolings, clients and chains.\nethereumjs (monorepo)\nThe ethereumjs monorepo holds core JavaScript primitives for Ethereum, including transaction signing, an EVM implementation, RLP encoding, tries, and shared utilities. JavaScript builders import individual packages when they need protocol-level pieces rather than a full client library.\nweb3.swift (Argent)\nweb3.swift from Argent is a Swift library covering Ethereum RPC calls, ABI encoding, and transaction signing. iOS and macOS builders use it to talk to Ethereum from native applications.\nSafe Protocol Kit (safe-core-sdk)\nSafe Protocol Kit is the TypeScript SDK of safe-core-sdk for building, signing, and executing Safe multisignature transactions. Builders use it to drive Safe accounts from application or script code.\nMerkleTreeJS\nA JavaScript library to construct Merkle Trees and verify proofs.\nDelphereum\nDelphereum is a web3 implementation for Delphi that lets Object Pascal desktop and mobile applications sign transactions and read contract state. It is the maintained route to Ethereum for builders working in that language.\nEthereumex\nEthereumex is an Elixir JSON-RPC client for Ethereum and the transport layer that higher-level libraries such as Elixir Ethers build on. Elixir builders configure it by name even when they work through a higher-level library.\nheadlong\nheadlong is a Java library for encoding and decoding contract ABI calldata and RLP, tuned for throughput in JVM services. Java builders add it when a backend has to process a high volume of Ethereum calls.\nhs-web3\nhs-web3 is a Haskell library for talking to Ethereum nodes, with contract ABI code generation through Template Haskell. It is the route to Ethereum for builders working in Haskell.\nruint\nruint is a const-generic unsigned integer type for Rust that represents Ethereum's 256-bit words, and it sits under Alloy and Reth. Rust builders add it directly when they need fixed-width big integers.\nrust-web3\nrust-web3 is a Rust implementation of the web3 JSON-RPC client with pluggable transports. It predates Alloy and carries no deprecation notice.\nweb3dart\nweb3dart is an Ethereum client library for Dart and Flutter covering JSON-RPC calls, contract bindings, and local transaction signing. Flutter builders use it as the general client for mobile applications.\nsafe-eth-py\nsafe-eth-py is the Python SDK from the Safe team for building, signing, and relaying Safe multisig transactions. Python builders use it to drive Safe accounts from backend code.\nabitype\nabitype provides strict TypeScript types and static inference for Ethereum ABIs, and it is the type layer under viem and wagmi. TypeScript builders import it when contract calls should be checked against the ABI at compile time.\nessential-eth\nessential-eth is a lightweight JavaScript client library that bundles to roughly a tenth of the size of ethers.js or web3.js. Builders install it when bundle size on the frontend is the constraint.\nox\nox is a low-level TypeScript library of Ethereum primitives covering ABI, RLP, hex, signing, and transactions, and it sits under viem and other wevm tools. Builders import it directly when they want the primitives without the client layer.\nmulticall.py\nmulticall.py is a Python client that batches many contract calls into a single Multicall aggregate call. Python builders install it to turn hundreds of reads into one RPC request.\nethkit (Sequence)\nethkit is a Go toolkit for building Ethereum applications from the team behind the Sequence JavaScript SDK. Go builders import it for wallet handling, ABI work, and RPC calls.\nw3 (Golang JSON-RPC client)\nw3 is a modular Go JSON-RPC client for Ethereum with first-class ABI support and request batching. Go builders import it when contract calls should be typed and many requests sent in one batch.\nElixir Ethers\nElixir Ethers is a library for calling and decoding Ethereum smart contracts from Elixir. Builders use it when the backend is written in Elixir, where options are few.\nZabi\nZabi is a Zig library for interacting with Ethereum and other EVM chains, providing JSON-RPC clients, ABI utilities, signers, and wallet primitives.\nethers-kt\nethers-kt is an async Kotlin library for interacting with EVM chains, targeting the JVM and Android. Kotlin builders use it to read contracts and send transactions from server or mobile code.\nMulticaller\nMulticaller from Vectorized is a collection of gas-optimized multicall-style contracts that batch arbitrary external calls while preserving the original msg.sender context for each callee, making complex router or aggregator flows cheaper and safer on EVM chains.\nlibethc\nlibethc is an open-source ethereum library for C/C++\nVoltaire\nVoltaire is a modern general-purpose Ethereum library for TypeScript, Zig, C, and Swift. Type-safe primitives, WASM-accelerated performance, and designed for AI-assisted development.\nethereum-bloom-filters\nA lightweight bloom filter client which allows you to test ethereum blooms for fast checks of set membership.\nGelato Automate SDK\nAutomate your smart contracts using Automate SDK\nprimitive-types\nprimitive-types provides the shared Rust U256, H160, and H256 types used across Ethereum and Substrate node and tooling codebases. Rust builders add it when their code has to carry Ethereum-sized integers and hashes.\nFrontend/integration tooling\n( 8 )\nCurvegrid MultiBaas\nCurvegrid MultiBaas is a hosted control plane with REST APIs for deploying and operating multi-chain EVM backends when you want managed keys, indexing hooks, and dashboards without building all ops in-house.\nWagmi: Reactive primitives for Ethereum apps\nWagmi is a React hook layer on top of Viem for reading, writing, and caching Ethereum state in frontends without rebuilding wallet plumbing each project.\nImpersonator.xyz\nImpersonator.xyz lets developers connect to dapps through WalletConnect, an iframe shim, or a browser extension while masquerading as any address without holding private keys, which is ideal for QA teams that need to preview balances, capture calldata for Tenderly simulations, or regression-test wallet flows safely.\nant-design-web3\nant-design-web3 is a React component library from the Ant Design team for wallet connection and account interfaces. Builders drop it into a React application as an alternative to RainbowKit or ConnectKit.\nOnchainKit\nOnchainKit is a set of React components from Coinbase for wallets, transactions, identity, and other onchain interfaces. React builders use it to assemble an onchain frontend from prebuilt pieces.\nSwiss-Knife.xyz\nSwiss-Knife aggregates all the useful EVM tools in one place to ease developer experience while they are debugging or building new stuff.\nNexth\nNexth is a Next.js starter kit wired up with viem, wagmi, Sign-In with Ethereum, and Tailwind. Builders clone it to start from a working frontend rather than assembling the same pieces again.\nOne Click Dapp\nOne Click Dapp generates a hosted web interface for a deployed contract from its ABI and address. Builders use it to give a contract a usable interface without writing frontend code.\nWallet integration & auth\n( 20 )\nHuman Passport\nHuman Passport aggregates identity credentials, called Stamps, into one Unique Humanity Score per wallet, so projects can check that an address is a distinct person before an airdrop, grant round, vote or signup. Read scores from the REST API or drop in the Passport Embed React component.\nthirdweb\nthirdweb is a full stack, open-source web3 development platform with frontend, backend, and onchain tools to build complete web3 apps - on every EVM chain.\nModular Account\nAlchemy's Modular Account is a maximally modular, upgradeable smart contract account that is compatible with ERC-4337 and ERC-6900. Alchemy's Modular Account most efficient smart account on the market with release of v2 released in feb 2025\nEthereum Attestation Service (EAS)"}
{"url":"https://ethereum.org/whitepaper/","domain":"ethereum.org","title":"Ethereum Whitepaper | ethereum.org","hash":"eaba833518b6e1f336946314a1f54fda929f69bff77a31e873e29b87ccf44a37","tokens":9900,"chars":39599,"crawler":"crawler-f6nn","verified":"exact","ts":1791171842841,"text":"Skip to main content\nEthereum Whitepaper\nBefore you read\nLooking to understand Ethereum?\nThis whitepaper was published in 2014 , before Ethereum launched. After 10+ years of development, major upgrades, and ecosystem growth, the original whitepaper no longer reflects what Ethereum is today .\nLearn about Ethereum today Download original PDF (2014)\nWhat's changed since 2014?\nEthereum moved from proof-of-work to proof-of-stake (The Merge, 2022)\nLayer 2 scaling solutions now process millions of transactions\nDeFi, NFTs, and DAOs emerged as major use cases\nSmart contract standards (ERC-20, ERC-721) became industry foundations\nWhile several years old, we maintain the original paper below because it continues to serve as a useful reference and an accurate representation of Ethereum and its vision.\nA Next-Generation Smart Contract and Decentralized Application Platform\nSatoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or \" intrinsic value (opens in a new tab) \" and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments (\" colored coins (opens in a new tab) \"), the ownership of an underlying physical device (\" smart property (opens in a new tab) \"), non-fungible assets such as domain names (\" Namecoin (opens in a new tab) \"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules (\" smart contracts (opens in a new tab) \") or even blockchain-based \" decentralized autonomous organizations (opens in a new tab) \" (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create \"contracts\" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.\nIntroduction to Bitcoin and Existing Concepts\nHistory\nThe concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money (opens in a new tab) became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of \" reusable proofs of work (opens in a new tab) \", a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend. In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as \"proof-of-work\".\nThe mechanism behind proof-of-work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof-of-stake , calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.\nBitcoin As A State Transition System\nFrom a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a \"state\" consisting of the ownership status of all existing bitcoins and a \"state transition function\" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value in A's account by $X and increases the value in B's account by $X. If A's account has less than $X in the first place, the state transition function returns an error. Hence, one can formally define:\nAPPLY(S,TX) -> S' or ERROR\nIn the banking system defined above:\nAPPLY ({ Alice : $50 , Bob : $50 }, \" send $20 from Alice to Bob \" ) = { Alice : $30 , Bob : $70 }\nJS\nBut:\nAPPLY ({ Alice : $50 , Bob : $50 }, \" send $70 from Alice to Bob \" ) = ERROR\nJS\nThe \"state\" in Bitcoin is the collection of all coins (technically, \"unspent transaction outputs\" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key fn1 ). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.\nThe state transition function APPLY(S,TX) -> S' can be defined roughly as follows:\n-\nFor each input in TX :\n- If the referenced UTXO is not in S , return an error.\n- If the provided signature does not match the owner of the UTXO, return an error.\n- If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.\n- Return S with all input UTXO removed and all output UTXO added.\nThe first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC \"change\", with the owner being Alice herself.\nMining\nIf we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called \"blocks\". The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, \"blockchain\" that constantly updates to represent the latest state of the Bitcoin ledger.\nThe algorithm for checking if a block is valid, expressed in this paradigm, is as follows:\n- Check if the previous block referenced by the block exists and is valid.\n- Check that the timestamp of the block is greater than that of the previous block fn2 and less than 2 hours into the future\n- Check that the proof-of-work on the block is valid.\n- Let S[0] be the state at the end of the previous block.\n- Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1 , set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.\n- Return true, and register S[n] as the state at the end of this block.\nEssentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.\nThe one validity condition present in the above list that is not found in other systems is the requirement for \"proof-of-work\". The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2 187 . The purpose of this is to make block creation computationally \"hard\", thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudo-random function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.\nAt the current target of ~2 187 , the network must make an average of ~2 69 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a \"transaction fee\". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.\nIn order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:\n- Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)\n- Wait for the delivery of the product\n- Produce another transaction sending the same 100 BTC to himself\n- Try to convince the network that his transaction to himself was the one that came first.\nOnce step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus \"confirming\" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a \"fork\" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof-of-work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not \"point\" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, \"51% attack\").\nMerkle Trees\nLeft: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.\nRight: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.\nAn important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The \"hash\" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the \"top\" of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof-of-work).\nThe Merkle tree protocol is arguably essential to long-term sustainability. A \"full node\" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month. Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate. A protocol known as \"simplified payment verification\" (SPV) allows for another class of nodes to exist, called \"light nodes\", which download the block headers, verify the proof-of-work on the block headers, and then download only the \"branches\" associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.\nAlternative Blockchain Applications\nThe idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of \" secure property titles with owner authority (opens in a new tab) \", a document describing how \"new advances in replicated database technology\" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.\n- Namecoin - created in 2010, Namecoin (opens in a new tab) is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudo-random hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy . Ideally, one would like to be able to have an account with a name like \"george\". However, the problem is that if one person can create an account named \"george\" then someone else can use the same process to register \"george\" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.\n- Colored coins - the purpose of colored coins (opens in a new tab) is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one \"issues\" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.\n- Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY' . Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX) returns an error, the protocol defaults to APPLY'(S,TX) = S . This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol. Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.\nThus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.\nThe Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all \"light\" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.\nScripting\nEven without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of \"smart contracts\". UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate (\"multisig\"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like \"this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me\", essentially allowing decentralized cross-cryptocurrency exchange.\nHowever, the scripting language as implemented in Bitcoin has several important limitations:\n- Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.\n- Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (e.g., one UTXO of 2 k for every k up to 30) and having the oracle pick which UTXO to send to A and which to B.\n- Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex \"stateful\" contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.\n- Blockchain-blindness - UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.\nThus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security. Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.\nEthereum\nThe intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic \"boxes\" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.\nEthereum Accounts\nIn Ethereum, the state is made up of objects called \"accounts\", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields:\n- The nonce , a counter used to make sure each transaction can only be processed once\n- The account's current ether balance\n- The account's contract code , if present\n- The account's storage (empty by default)\n\"Ether\" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: externally owned accounts , controlled by private keys, and contract accounts , controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.\nNote that \"contracts\" in Ethereum should not be seen as something that should be \"fulfilled\" or \"complied with\"; rather, they are more like \"autonomous agents\" that live inside of the Ethereum execution environment, always executing a specific piece of code when \"poked\" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.\nMessages and Transactions\nThe term \"transaction\" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:\n- The recipient of the message\n- A signature identifying the sender\n- The amount of ether to transfer from the sender to the recipient\n- An optional data field\n- A STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take\n- A GASPRICE value, representing the fee the sender pays per computational step\nThe first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode using which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two \"fields\", the first field being a domain to register and the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage.\nThe STARTGAS and GASPRICE fields are crucial for Ethereum's anti-denial of service model. In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is \"gas\"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.\nMessages\nContracts have the ability to send \"messages\" to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. A message contains:\n- The sender of the message (implicit)\n- The recipient of the message\n- The amount of ether to transfer alongside the message\n- An optional data field\n- A STARTGAS value\nEssentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.\nNote that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.\nEthereum State Transition Function\nThe Ethereum state transition function, APPLY(S,TX) -> S' can be defined as follows:\n- Check if the transaction is well-formed (i.e., has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.\n- Calculate the transaction fee as STARTGAS * GASPRICE , and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error.\n- Initialize GAS = STARTGAS , and take off a certain quantity of gas per byte to pay for the bytes in the transaction.\n- Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.\n- If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.\n- Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.\nFor example, suppose that the contract's code is:\nif ! self . storage [ calldataload ( 0 )]:\nself . storage [ calldataload ( 0 )] = calldataload ( 32 )\nPython\nNote that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2 and bytes 32-63 representing the string CHARLIE fn3 . The process for the state transition function in this case is as follows:\n- Check that the transaction is valid and well formed.\n- Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account.\n- Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left.\n- Subtract 10 more ether from the sender's account, and add it to the contract's account.\n- Run the code. In this case, this is simple: it checks if the contract's storage at index 2 is used, notices that it is not, and so it sets the storage at index 2 to the value CHARLIE . Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963\n- Add 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.\nIf there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.\nNote that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert. This means that it is \"safe\" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas. Finally, note that there is an opcode, CREATE , that creates a contract; its execution mechanics are generally similar to CALL , with the exception that the output of the execution determines the code of a newly created contract.\nCode Execution\nThe code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as \"Ethereum virtual machine code\" or \"EVM code\". The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected. The operations have access to three types of space in which to store data:\n- The stack , a last-in-first-out container to which values can be pushed and popped\n- Memory , an infinitely expandable byte array\n- The contract's long-term storage , a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term.\nThe code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.\nThe formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas) , where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pc th byte of code (or 0 if pc >= len(code) ), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.\nBlockchain and Mining\nThe Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:\n- Check if the previous block referenced exists and is valid.\n- Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future\n- Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.\n- Check that the proof-of-work on the block is valid.\n- Let S[0] be the state at the end of the previous block.\n- Let TX be the block's transaction list, with n transactions. For all i in 0...n-1 , set S[i+1] = APPLY(S[i],TX[i]) . If any applications returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT , return an error.\n- Let S_FINAL be S[n] , but adding the block reward paid to the miner.\n- Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid."}
{"url":"https://developer.bitcoin.org/devguide/","domain":"developer.bitcoin.org","title":"Developer Guides — Bitcoin","hash":"9badf1b848cd9abd472d87018cdc87694565a108b39134bf78fbdba9d455c993","tokens":204,"chars":813,"crawler":"crawler-f6nn","verified":"exact","ts":1791171844809,"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://forum.skyeco.com/latest","domain":"forum.skyeco.com","title":"Latest topics - Sky Forum","hash":"ca27ba14e9993757ed96020c60fbe97e9c2b98ad8347373944989365fb61e2e2","tokens":829,"chars":3316,"crawler":"crawler-f6nn","verified":"exact","ts":1791171847194,"text":"Sky Forum\nTopic\nReplies\nViews\nActivity\nTechnical Scope: Sentora x Spark RLUSD WBTC Relative Supply Cap Reduction\nSpark Prime\n0\n8\nOctober 4, 2026\nAtlas Edit Weekly Cycle Proposal - Week Of 2026-10-05\nSky Core\natlas-edit-weekly-proposal\n0\n14\nOctober 4, 2026\nS&P Report Question re: Fixed Sky Reserve target\nSky Core\n0\n25\nOctober 4, 2026\nTechnical scope of the Beacon and Configurator launch on Arbitrum\nSky Core\npas-configurator\n,\narbitrum\n,\ntechnical-scope\n0\n30\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\n203\nOctober 3, 2026\nConfirming interest rate mechanism scope across SparkLend Ethereum reserves\nSpark Prime\n0\n20\nOctober 2, 2026\nHow to get back DAI mistakenly transferred?\nMiscellaneous\n13\n4530\nOctober 2, 2026\nMSC #13 - Settlement Summary (September 2026)\nSky Core\noea\n,\nmsc\n,\nmonthly-settlement-cycle\n0\n39\nOctober 2, 2026\nSettlement Reconciliation — MSC #5–#12 (January–August 2026)\nSky Core\noea\n,\nmsc\n,\nmonthly-settlement-cycle\n0\n29\nOctober 2, 2026\nGrove cBEAM Configuration\nGrove Prime\noea\n,\npas\n24\n382\nOctober 2, 2026\n[October 8, 2026] - Proposed Changes to Grove for Upcoming Spell\nGrove Prime\n8\n192\nOctober 2, 2026\nA free, read-only checker for MKR still sitting in old contracts\nGeneral Discussion\nmigration\n,\ntool\n,\ntoken-migration\n0\n28\nOctober 2, 2026\nRevisiting DAI sent to the DAI token contract after MIP13c3-SP14\nGovernance\npublic-call\n,\nsummary\n3\n60\nOctober 2, 2026\nIntroducing the Redline Portal\nGeneral Discussion\n0\n28\nOctober 1, 2026\n[ChainFundamentals AI Research] Two years in, steadying out - September2026\nGeneral Discussion\nchain-fundamentals\n0\n37\nOctober 1, 2026\nRisk Month in Review: September 2026\nGeneral Discussion\nba-labs\n0\n32\nOctober 1, 2026\nRemi's Spark Delegate Communications\nSpark Prime\ngovernance\n26\n598\nOctober 1, 2026\nYvonPiPi's Grove Delegate Communications\nGrove Prime\n9\n222\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\n1282\nSeptember 29, 2026\nAegisD AD Recognition Submission\nAlignment Conservers\naligned-delegates\n100\n1565\nSeptember 29, 2026\nBLUE AD Recognition Submission\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n240\n11836\nSeptember 29, 2026\nPBG Aligned Delegate Communication Platform\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n237\n14601\nSeptember 28, 2026\nWBC Aligned Delegate Communications\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n208\n11826\nSeptember 28, 2026\nMax Staking Yield AD Recognition Submission\nAlignment Conservers\naligned-delegates\n105\n1732\nSeptember 28, 2026\nAtlas Edit Weekly Cycle Proposal - Week Of 2026-09-28\nSky Core\natlas-edit-weekly-proposal\n2\n110\nSeptember 28, 2026\nBONAPUBLICA Aligned Delegate Communication\nAlignment Conservers\nactive-aligned-delegate\n,\naligned-delegates\n,\ndelegates\n273\n17567\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\n460\nSeptember 25, 2026\nnext page →"}
{"url":"https://solana.com/docs/core/fees","domain":"solana.com","title":"","hash":"ced6ad4c86706d641bd28fb30948f5ebd6b05c96241c3b6a5fb741145307cb7d","tokens":676,"chars":2703,"crawler":"crawler-f6nn","verified":"exact","ts":1791171850015,"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.openzeppelin.com/ecosystem-adapters/architecture","domain":"docs.openzeppelin.com","title":"Architecture | OpenZeppelin Docs","hash":"6c6bb044ada0409012984baeb650131e3f6dc2f4ff2274e02189545def561316","tokens":1481,"chars":5921,"crawler":"crawler-f6nn","verified":"exact","ts":1791171852649,"text":"Home Forum Website Impact\nEcosystem Adapters\nArchitecture\nOpen in Claude\nThis page describes the capability-based architecture that underpins all OpenZeppelin Ecosystem Adapters. Understanding this architecture will help you choose the right profile for your application, consume capabilities efficiently, and build your own adapter if you need to.\nPackage Topology\nThe adapter system is split across several packages with clear dependency boundaries:\n- @openzeppelin/ui-types defines all 13 capability interfaces. It is the single source of truth.\n- adapter-runtime-utils provides profile composition, lazy capability instantiation, and staged disposal.\n- adapter-evm-core centralizes reusable EVM implementations shared by adapter-evm and adapter-polkadot .\n- Each public adapter exposes an ecosystemDefinition conforming to EcosystemExport .\nCapability Tiers\nAdapter functionality is decomposed into 13 capability interfaces organized across 3 tiers . The tiers reflect increasing levels of runtime requirements: stateless metadata, network-aware schema operations, and stateful wallet-dependent interactions.\nTier Category Network Wallet Capabilities\n1 Lightweight No No Addressing , Explorer , NetworkCatalog , UiLabels\n2 Schema Yes No ContractLoading , Schema , TypeMapping , Query\n3 Runtime Yes Yes Execution , Wallet , UiKit , Relayer , AccessControl\nTier Import Rules\nTier isolation is enforced physically through sub-path exports, not tree-shaking:\n- Tier 1 modules must not import from Tier 2 or Tier 3 modules\n- Tier 2 modules may import from Tier 1\n- Tier 3 modules may import from Tier 1 and Tier 2\nThis means importing @openzeppelin/adapter-evm/addressing will never pull in wallet SDKs, RPC clients, or access control code, regardless of your bundler configuration.\nCapability Reference\nCapability Interface Tier Key Methods\nAddressing AddressingCapability 1 isValidAddress\nExplorer ExplorerCapability 1 getExplorerUrl , getExplorerTxUrl\nNetworkCatalog NetworkCatalogCapability 1 getNetworks\nUiLabels UiLabelsCapability 1 getUiLabels\nContractLoading ContractLoadingCapability 2 loadContract , getContractDefinitionInputs\nSchema SchemaCapability 2 isViewFunction , getWritableFunctions\nTypeMapping TypeMappingCapability 2 mapParameterTypeToFieldType , getTypeMappingInfo\nQuery QueryCapability 2 queryViewFunction , formatFunctionResult , getCurrentBlock\nExecution ExecutionCapability 3 signAndBroadcast , formatTransactionData , validateExecutionConfig\nWallet WalletCapability 3 connectWallet , disconnectWallet , getWalletConnectionStatus\nUiKit UiKitCapability 3 getAvailableUiKits , configureUiKit\nRelayer RelayerCapability 3 getRelayers , getNetworkServiceForms\nAccessControl AccessControlCapability 3 registerContract , grantRole , and 17 more\nProfiles\nProfiles are pre-composed bundles of capabilities that match common application archetypes. They exist for convenience. You can always consume individual capabilities directly via the CapabilityFactoryMap .\nEach profile is a strict superset of Declarative. Higher profiles add capabilities incrementally:\nProfile-Capability Matrix\nCapability Declarative Viewer Transactor Composer Operator\nAddressing ✅ ✅ ✅ ✅ ✅\nExplorer ✅ ✅ ✅ ✅ ✅\nNetworkCatalog ✅ ✅ ✅ ✅ ✅\nUiLabels ✅ ✅ ✅ ✅ ✅\nContractLoading ✅ ✅ ✅ ✅\nSchema ✅ ✅ ✅ ✅\nTypeMapping ✅ ✅ ✅ ✅\nQuery ✅ ✅ ✅\nExecution ✅ ✅ ✅\nWallet ✅ ✅ ✅\nUiKit ✅ ✅\nRelayer ✅\nAccessControl ✅\nProfile Selection Guide\nIf your application needs to… Choose\nValidate addresses, list networks, link to explorers Declarative\nRead contract state without sending transactions Viewer\nSend transactions without reading contract state first Transactor\nBuild full contract interaction UIs with relayer support Composer\nManage contract roles and permissions Operator\nRuntime Lifecycle\nRuntimes are immutable and network-scoped . When a user switches networks, the consuming application must dispose the current runtime and create a new one.\nDispose Contract\n- dispose() is idempotent : calling it multiple times is a no-op\n- After dispose() , any method or property access throws RuntimeDisposedError\n- Pending async operations (e.g., in-flight signAndBroadcast ) are rejected with RuntimeDisposedError\n- Cleanup follows a staged order: mark disposed → reject pending operations → clean up listeners and subscriptions → dispose capabilities → release wallet and RPC resources\n- Runtime disposal does not disconnect the wallet. Disconnect is always an explicit user action\nExecution Strategies\nThe Execution capability uses a strategy pattern to support multiple transaction submission methods. Each adapter can provide its own set of strategies.\nThe EVM and Stellar adapters ship with both EOA and Relayer strategies. Adapter authors can implement custom strategies by conforming to the AdapterExecutionStrategy interface.\nSub-Path Exports\nEach adapter publishes every implemented capability and profile as a dedicated sub-path export:\n// Tier 1: no wallet, no RPC, no heavy dependencies\nimport { createAddressing } from '@openzeppelin/adapter-stellar/addressing' ;\nimport { createExplorer } from '@openzeppelin/adapter-stellar/explorer' ;\n// Tier 2: network-aware\nimport { createQuery } from '@openzeppelin/adapter-stellar/query' ;\n// Tier 3: wallet-dependent\nimport { createExecution } from '@openzeppelin/adapter-stellar/execution' ;\n// Profile runtimes\nimport { createRuntime } from '@openzeppelin/adapter-stellar/profiles/composer' ;\n// Metadata and networks\nimport { networks } from '@openzeppelin/adapter-stellar/networks' ;\nThis structure ensures that a Declarative-profile consumer never bundles wallet SDKs, and that individual capabilities can be tested in isolation.\nOverview\nPrevious Page\nGetting Started\nNext Page\nOn this page\nPackage Topology Capability Tiers Tier Import Rules Capability Reference Profiles Profile-Capability Matrix Profile Selection Guide Runtime Lifecycle Dispose Contract Execution Strategies Sub-Path Exports"}
{"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":"crawler-f6nn","verified":"exact","ts":1791171855389,"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://eips.ethereum.org/EIPS/eip-4844","domain":"eips.ethereum.org","title":"EIP-4844: Shard Blob Transactions","hash":"ec420a6703b3297c8dfa920c5ce6a48022cd68d6c5a30e4bd81ebc98e4c88c14","tokens":5855,"chars":23417,"crawler":"crawler-f6nn","verified":"exact","ts":1791171857864,"text":"Ethereum Improvement Proposals\n🎉 Final\nStandards Track: Core\nEIP-4844: Shard Blob Transactions\nShard Blob Transactions scale data-availability of Ethereum in a simple, forwards-compatible manner.\nAuthors\nVitalik Buterin ( @vbuterin ), Dankrad Feist ( @dankrad ), Diederik Loerakker ( @protolambda ), George Kadianakis ( @asn-d6 ), Matt Garnett ( @lightclient ), Mofi Taiwo ( @Inphi ), Ansgar Dietrichs ( @adietrichs )\nCreated\n2022-02-25\nRequires\nEIP-1559 ,\nEIP-2718 ,\nEIP-2930 ,\nEIP-4895\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- Parameters\n- Type aliases\n- Cryptographic Helpers\n- Helpers\n- Blob transaction\n- Header extension\n- Gas accounting\n- Opcode to get versioned hashes\n- Point evaluation precompile\n- Consensus layer validation\n- Execution layer validation\n- Networking\n- Rationale\n- On the path to sharding\n- How rollups would function\n- Versioned hashes & precompile return data\n- Base fee per blob gas update rule\n- Throughput\n- Backwards Compatibility\n- Blob non-accessibility\n- Mempool issues\n- Test Cases\n- Security Considerations\n- Copyright\nAbstract\nIntroduce a new transaction format for “blob-carrying transactions” which contain a large amount of data that cannot be\naccessed by EVM execution, but whose commitment can be accessed.\nThe format is intended to be fully compatible with the format that will be used in full sharding.\nMotivation\nRollups are in the short and medium term, and possibly in the long term, the only trustless scaling solution for Ethereum.\nTransaction fees on L1 have been very high for months and there is greater urgency in doing anything required to help facilitate an ecosystem-wide move to rollups.\nRollups are significantly reducing fees for many Ethereum users: Optimism and Arbitrum frequently provide fees that are ~3-8x lower than the Ethereum base layer itself,\nand ZK rollups, which have better data compression and can avoid including signatures, have fees ~40-100x lower than the base layer.\nHowever, even these fees are too expensive for many users. The long-term solution to the long-term inadequacy of rollups\nby themselves has always been data sharding, which would add ~16 MB per block of dedicated data space to the chain that rollups could use.\nHowever, data sharding will still take a considerable amount of time to finish implementing and deploying.\nThis EIP provides a stop-gap solution until that point by implementing the transaction format that would be used in sharding,\nbut not actually sharding those transactions. Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded\nby all consensus nodes (but can be deleted after only a relatively short delay).\nCompared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.375 MB per block and a limit of ~0.75 MB.\nSpecification\nParameters\nConstant\nValue\nBLOB_TX_TYPE\nBytes1(0x03)\nBYTES_PER_FIELD_ELEMENT\n32\nFIELD_ELEMENTS_PER_BLOB\n4096\nBLS_MODULUS\n52435875175126190479447740508185965837690552500527637822603658699938581184513\nVERSIONED_HASH_VERSION_KZG\nBytes1(0x01)\nPOINT_EVALUATION_PRECOMPILE_ADDRESS\nBytes20(0x0A)\nPOINT_EVALUATION_PRECOMPILE_GAS\n50000\nMAX_BLOB_GAS_PER_BLOCK\n786432\nTARGET_BLOB_GAS_PER_BLOCK\n393216\nMIN_BASE_FEE_PER_BLOB_GAS\n1\nBLOB_BASE_FEE_UPDATE_FRACTION\n3338477\nGAS_PER_BLOB\n2**17\nHASH_OPCODE_BYTE\nBytes1(0x49)\nHASH_OPCODE_GAS\n3\nMIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS\n4096\nType aliases\nType\nBase type\nAdditional checks\nBlob\nByteVector[BYTES_PER_FIELD_ELEMENT * FIELD_ELEMENTS_PER_BLOB]\nVersionedHash\nBytes32\nKZGCommitment\nBytes48\nPerform IETF BLS signature “KeyValidate” check but do allow the identity point\nKZGProof\nBytes48\nSame as for KZGCommitment\nCryptographic Helpers\nThroughout this proposal we use cryptographic methods and classes defined in the corresponding consensus 4844 specs .\nSpecifically, we use the following methods from polynomial-commitments.md :\n- verify_kzg_proof()\n- verify_blob_kzg_proof_batch()\nHelpers\ndef kzg_to_versioned_hash ( commitment : KZGCommitment ) -> VersionedHash :\nreturn VERSIONED_HASH_VERSION_KZG + sha256 ( commitment )[ 1 :]\nApproximates factor * e ** (numerator / denominator) using Taylor expansion:\ndef fake_exponential ( factor : int , numerator : int , denominator : int ) -> int :\ni = 1\noutput = 0\nnumerator_accum = factor * denominator\nwhile numerator_accum > 0 :\noutput += numerator_accum\nnumerator_accum = ( numerator_accum * numerator ) // ( denominator * i )\ni += 1\nreturn output // denominator\nBlob transaction\nWe introduce a new type of EIP-2718 transaction, “blob transaction”, where the TransactionType is BLOB_TX_TYPE and the TransactionPayload is the RLP serialization of the following TransactionPayloadBody :\n[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s]\nThe fields chain_id , nonce , max_priority_fee_per_gas , max_fee_per_gas , gas_limit , value , data , and access_list follow the same semantics as EIP-1559 .\nThe field to deviates slightly from the semantics with the exception that it MUST NOT be nil and therefore must always represent a 20-byte address. This means that blob transactions cannot have the form of a create transaction.\nThe field max_fee_per_blob_gas is a uint256 and the field blob_versioned_hashes represents a list of hash outputs from kzg_to_versioned_hash .\nThe EIP-2718 ReceiptPayload for this transaction is rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]) .\nSignature\nThe signature values y_parity , r , and s are calculated by constructing a secp256k1 signature over the following digest:\nkeccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes])) .\nHeader extension\nThe current header encoding is extended with two new 64-bit unsigned integer fields:\n- blob_gas_used is the total amount of blob gas consumed by the transactions within the block.\n- excess_blob_gas is a running total of blob gas consumed in excess of the target, prior to the block. Blocks with above-target blob gas consumption increase this value, blocks with below-target blob gas consumption decrease it (bounded at 0).\nThe resulting RLP encoding of the header is therefore:\nrlp([\nparent_hash,\n0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash\ncoinbase,\nstate_root,\ntxs_root,\nreceipts_root,\nlogs_bloom,\n0, # difficulty\nnumber,\ngas_limit,\ngas_used,\ntimestamp,\nextradata,\nprev_randao,\n0x0000000000000000, # nonce\nbase_fee_per_gas,\nwithdrawals_root,\nblob_gas_used,\nexcess_blob_gas,\n])\nThe value of excess_blob_gas can be calculated using the parent header.\ndef calc_excess_blob_gas ( parent : Header ) -> int :\nif parent . excess_blob_gas + parent . blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK :\nreturn 0\nelse :\nreturn parent . excess_blob_gas + parent . blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK\nFor the first post-fork block, both parent.blob_gas_used and parent.excess_blob_gas are evaluated as 0 .\nGas accounting\nWe introduce blob gas as a new type of gas. It is independent of normal gas and follows its own targeting rule, similar to EIP-1559.\nWe use the excess_blob_gas header field to store persistent data needed to compute the blob gas base fee. For now, only blobs are priced in blob gas.\ndef calc_blob_fee ( header : Header , tx : Transaction ) -> int :\nreturn get_total_blob_gas ( tx ) * get_base_fee_per_blob_gas ( header )\ndef get_total_blob_gas ( tx : Transaction ) -> int :\nreturn GAS_PER_BLOB * len ( tx . blob_versioned_hashes )\ndef get_base_fee_per_blob_gas ( header : Header ) -> int :\nreturn fake_exponential (\nMIN_BASE_FEE_PER_BLOB_GAS ,\nheader . excess_blob_gas ,\nBLOB_BASE_FEE_UPDATE_FRACTION\n)\nThe block validity conditions are modified to include blob gas checks (see the Execution layer validation section below).\nThe actual blob_fee as calculated via calc_blob_fee is deducted from the sender balance before transaction execution and burned, and is not refunded in case of transaction failure.\nOpcode to get versioned hashes\nWe add an instruction BLOBHASH (with opcode HASH_OPCODE_BYTE ) which reads index from the top of the stack\nas big-endian uint256 , and replaces it on the stack with tx.blob_versioned_hashes[index]\nif index < len(tx.blob_versioned_hashes) , and otherwise with a zeroed bytes32 value.\nThe opcode has a gas cost of HASH_OPCODE_GAS .\nPoint evaluation precompile\nAdd a precompile at POINT_EVALUATION_PRECOMPILE_ADDRESS that verifies a KZG proof which claims that a blob\n(represented by a commitment) evaluates to a given value at a given point.\nThe precompile costs POINT_EVALUATION_PRECOMPILE_GAS and executes the following logic:\ndef point_evaluation_precompile ( input : Bytes ) -> Bytes :\n\"\"\"\nVerify p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof.\nAlso verify that the provided commitment matches the provided versioned_hash.\n\"\"\"\n# The data is encoded as follows: versioned_hash | z | y | commitment | proof | with z and y being padded 32 byte big endian values\nassert len ( input ) == 192\nversioned_hash = input [: 32 ]\nz = input [ 32 : 64 ]\ny = input [ 64 : 96 ]\ncommitment = input [ 96 : 144 ]\nproof = input [ 144 : 192 ]\n# Verify commitment matches versioned_hash\nassert kzg_to_versioned_hash ( commitment ) == versioned_hash\n# Verify KZG proof with z and y in big endian format\nassert verify_kzg_proof ( commitment , z , y , proof )\n# Return FIELD_ELEMENTS_PER_BLOB and BLS_MODULUS as padded 32 byte big endian values\nreturn Bytes ( U256 ( FIELD_ELEMENTS_PER_BLOB ). to_be_bytes32 () + U256 ( BLS_MODULUS ). to_be_bytes32 ())\nThe precompile MUST reject non-canonical field elements (i.e. provided field elements MUST be strictly less than BLS_MODULUS ).\nConsensus layer validation\nOn the consensus layer the blobs are referenced, but not fully encoded, in the beacon block body.\nInstead of embedding the full contents in the body, the blobs are propagated separately, as “sidecars”.\nThis “sidecar” design provides forward compatibility for further data increases by black-boxing is_data_available() :\nwith full sharding is_data_available() can be replaced by data-availability-sampling (DAS) thus avoiding all blobs being downloaded by all beacon nodes on the network.\nNote that the consensus layer is tasked with persisting the blobs for data availability, the execution layer is not.\nThe ethereum/consensus-specs repository defines the following consensus layer changes involved in this EIP:\n- Beacon chain: process updated beacon blocks and ensure blobs are available.\n- P2P network: gossip and sync updated beacon block types and new blob sidecars.\n- Honest validator: produce beacon blocks with blobs; sign and publish the associated blob sidecars.\nExecution layer validation\nOn the execution layer, the block validity conditions are extended as follows:\ndef validate_block ( block : Block ) -> None :\n...\n# check that the excess blob gas was updated correctly\nassert block . header . excess_blob_gas == calc_excess_blob_gas ( block . parent . header )\nblob_gas_used = 0\nfor tx in block . transactions :\n...\n# modify the check for sufficient balance\nmax_total_fee = tx . gas * tx . max_fee_per_gas\nif get_tx_type ( tx ) == BLOB_TX_TYPE :\nmax_total_fee += get_total_blob_gas ( tx ) * tx . max_fee_per_blob_gas\nassert signer ( tx ). balance >= max_total_fee\n...\n# add validity logic specific to blob txs\nif get_tx_type ( tx ) == BLOB_TX_TYPE :\n# there must be at least one blob\nassert len ( tx . blob_versioned_hashes ) > 0\n# all versioned blob hashes must start with VERSIONED_HASH_VERSION_KZG\nfor h in tx . blob_versioned_hashes :\nassert h [ 0 ] == VERSIONED_HASH_VERSION_KZG\n# ensure that the user was willing to at least pay the current blob base fee\nassert tx . max_fee_per_blob_gas >= get_base_fee_per_blob_gas ( block . header )\n# keep track of total blob gas spent in the block\nblob_gas_used += get_total_blob_gas ( tx )\n# ensure the total blob gas spent is at most equal to the limit\nassert blob_gas_used <= MAX_BLOB_GAS_PER_BLOCK\n# ensure blob_gas_used matches header\nassert block . header . blob_gas_used == blob_gas_used\nNetworking\nBlob transactions have two network representations. During transaction gossip responses ( PooledTransactions ), the EIP-2718 TransactionPayload of the blob transaction is wrapped to become:\nrlp([tx_payload_body, blobs, commitments, proofs])\nEach of these elements are defined as follows:\n- tx_payload_body - is the TransactionPayloadBody of standard EIP-2718 blob transaction\n- blobs - list of Blob items\n- commitments - list of KZGCommitment of the corresponding blobs\n- proofs - list of KZGProof of the corresponding blobs and commitments\nThe node MUST validate tx_payload_body and verify the wrapped data against it. To do so, ensure that:\n- There are an equal number of tx_payload_body.blob_versioned_hashes , blobs , commitments , and proofs .\n- The KZG commitments hash to the versioned hashes, i.e. kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i]\n- The KZG commitments match the corresponding blobs and proofs . (Note: this can be optimized using verify_blob_kzg_proof_batch , with a proof for a\nrandom evaluation at a point derived from the commitment and blob data for each blob)\nFor body retrieval responses ( BlockBodies ), the standard EIP-2718 blob transaction TransactionPayload is used.\nNodes MUST NOT automatically broadcast blob transactions to their peers.\nInstead, those transactions are only announced using NewPooledTransactionHashes messages, and can then be manually requested via GetPooledTransactions .\nRationale\nOn the path to sharding\nThis EIP introduces blob transactions in the same format in which they are expected to exist in the final sharding specification.\nThis provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.375 MB per slot,\nwith a separate fee market allowing fees to be very low while usage of this system is limited.\nThe core goal of rollup scaling stopgaps is to provide temporary scaling relief,\nwithout imposing extra development burdens on rollups to take advantage of this relief.\nToday, rollups use calldata. In the future, rollups will have no choice but to use sharded data (also called “blobs”)\nbecause sharded data will be much cheaper.\nHence, rollups cannot avoid making a large upgrade to how they process data at least once along the way.\nBut what we can do is ensure that rollups need to only upgrade once.\nThis immediately implies that there are exactly two possibilities for a stopgap: (i) reducing the gas costs of existing calldata,\nand (ii) bringing forward the format that will be used for sharded data, but not yet actually sharding it.\nPrevious EIPs were all a solution of category (i); this EIP is a solution of category (ii).\nThe main tradeoff in designing this EIP is that of implementing more now versus having to implement more later:\ndo we implement 25% of the work on the way to full sharding, or 50%, or 75%?\nThe work that is already done in this EIP includes:\n- A new transaction type, of the exact same format that will need to exist in “full sharding”\n- All of the execution-layer logic required for full sharding\n- All of the execution / consensus cross-verification logic required for full sharding\n- Layer separation between BeaconBlock verification and data availability sampling blobs\n- Most of the BeaconBlock logic required for full sharding\n- A self-adjusting independent base fee for blobs\nThe work that remains to be done to get to full sharding includes:\n- A low-degree extension of the commitments in the consensus layer to allow 2D sampling\n- An actual implementation of data availability sampling\n- PBS (proposer/builder separation), to avoid requiring individual validators to process 32 MB of data in one slot\n- Proof of custody or similar in-protocol requirement for each validator to verify a particular part of the sharded data in each block\nThis EIP also sets the stage for longer-term protocol cleanups. For example, its (cleaner) gas base fee update rule could be applied to the primary basefee calculation.\nHow rollups would function\nInstead of putting rollup block data in transaction calldata, rollups would expect rollup block submitters\nto put the data into blobs. This guarantees availability (which is what rollups need) but would be much cheaper than calldata.\nRollups need data to be available once, long enough to ensure honest actors can construct the rollup state, but not forever.\nOptimistic rollups only need to actually provide the underlying data when fraud proofs are being submitted.\nThe fraud proof can verify the transition in smaller steps, loading at most a few values of the blob at a time through calldata.\nFor each value it would provide a KZG proof and use the point evaluation precompile to verify the value against the versioned hash that was submitted before,\nand then perform the fraud proof verification on that data as is done today.\nZK rollups would provide two commitments to their transaction or state delta data:\nthe blob commitment (which the protocol ensures points to available data) and the ZK rollup’s own commitment using whatever proof system the rollup uses internally.\nThey would use a proof of equivalence protocol, using the point evaluation precompile,\nto prove that the two commitments refer to the same data.\nVersioned hashes & precompile return data\nWe use versioned hashes (rather than commitments) as references to blobs in the execution layer to ensure forward compatibility with future changes.\nFor example, if we need to switch to Merkle trees + STARKs for quantum-safety reasons, then we would add a new version,\nallowing the point evaluation precompile to work with the new format.\nRollups would not have to make any EVM-level changes to how they work;\nsequencers would simply have to switch over to using a new transaction type at the appropriate time.\nHowever, the point evaluation happens inside a finite field, and it is only well defined if the field modulus is known. Smart contracts could contain a table mapping the commitment version to a modulus, but this would not allow smart contract to take into account future upgrades to a modulus that is not known yet. By allowing access to the modulus inside the EVM, the smart contract can be built so that it can use future commitments and proofs, without ever needing an upgrade.\nIn the interest of not adding another precompile, we return the modulus and the polynomial degree directly from the point evaluation precompile. It can then be used by the caller. It is also “free” in that the caller can just ignore this part of the return value without incurring an extra cost – systems that remain upgradable for the foreseeable future will likely use this route for now.\nBase fee per blob gas update rule\nThe base fee per blob gas update rule is intended to approximate the formula base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) ,\nwhere excess_blob_gas is the total “extra” amount of blob gas that the chain has consumed relative to the “targeted” number ( TARGET_BLOB_GAS_PER_BLOCK per block).\nLike EIP-1559, it’s a self-correcting formula: as the excess goes higher, the base_fee_per_blob_gas increases exponentially, reducing usage and eventually forcing the excess back down.\nThe block-by-block behavior is roughly as follows.\nIf block N consumes X blob gas, then in block N+1 excess_blob_gas increases by X - TARGET_BLOB_GAS_PER_BLOCK ,\nand so the base_fee_per_blob_gas of block N+1 increases by a factor of e**((X - TARGET_BLOB_GAS_PER_BLOCK) / BLOB_BASE_FEE_UPDATE_FRACTION) .\nHence, it has a similar effect to the existing EIP-1559, but is more “stable” in the sense that it responds in the same way to the same total usage regardless of how it’s distributed.\nThe parameter BLOB_BASE_FEE_UPDATE_FRACTION controls the maximum rate of change of the base fee per blob gas. It is chosen to target a maximum change rate of e**(TARGET_BLOB_GAS_PER_BLOCK / BLOB_BASE_FEE_UPDATE_FRACTION) ≈ 1.125 per block.\nThroughput\nThe values for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK are chosen to correspond to a target of 3 blobs (0.375 MB) and maximum of 6 blobs (0.75 MB) per block. These small initial limits are intended to minimize the strain on the network created by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.\nBackwards Compatibility\nBlob non-accessibility\nThis EIP introduces a transaction type that has a distinct mempool version and execution-payload version,\nwith only one-way convertibility between the two. The blobs are in the network representation and not in the consensus representation;\ninstead, they are coupled with the beacon block. This means that there is now a part of a transaction that will not be accessible from the web3 API.\nMempool issues\nBlob transactions have a large data size at the mempool layer, which poses a mempool DoS risk,\nthough not an unprecedented one as this also applies to transactions with large amounts of calldata.\nBy only broadcasting announcements for blob transactions, receiving nodes will have control over which and how many transactions to receive,\nallowing them to throttle throughput to an acceptable level.\nEIP-5793 will give further fine-grained control to nodes by extending the NewPooledTransactionHashes announcement messages to include the transaction type and size.\nIn addition, we recommend including a 1.1x base fee per blob gas bump requirement to the mempool transaction replacement rules.\nTest Cases\nExecution layer test cases for this EIP can be found in the eip4844_blobs of the ethereum/execution-spec-tests repository. Consensus layer test cases can be found here .\nSecurity Considerations\nThis EIP increases the bandwidth requirements per beacon block by a maximum of ~0.75 MB.\nThis is 40% larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.\nPost-merge, block times are static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.\nThe sustained load of this EIP is much lower than alternatives that reduce calldata costs, even if the calldata is limited,\nbecause there is no expectation that the blobs need to be stored for as long as an execution payload.\nThis makes it possible to implement a policy that these blobs must be kept for at least a certain period. The specific value chosen is MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epochs, which is around 18 days,\na much shorter delay compared to proposed (but yet to be implemented) one-year rotation times for execution payload history.\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nVitalik Buterin ( @vbuterin ), Dankrad Feist ( @dankrad ), Diederik Loerakker ( @protolambda ), George Kadianakis ( @asn-d6 ), Matt Garnett ( @lightclient ), Mofi Taiwo ( @Inphi ), Ansgar Dietrichs ( @adietrichs ), \"EIP-4844: Shard Blob Transactions,\" Ethereum Improvement Proposals , no. 4844, February 2022. Available: https://eips.ethereum.org/EIPS/eip-4844."}
{"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-f6nn","verified":"exact","ts":1791171859866,"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 .json .\nOn-chain IDL storage uses the Program Metadata system. This reduces program\nbinary sizes and provides a standardized approach to on-chain metadata. Use\nanchor idl init to upload your IDL to the blockchain.\nThe code snippets in the sections below highlight how the program, IDL, and\nclient relate to each other.\nProgram Instructions\nThe instructions array in the IDL corresponds directly to the instructions\ndefined in your program. It specifies the required accounts and parameters for\neach instruction.\nThe program below includes an initialize instruction, specifying the accounts\nand parameters it requires.\nlib.rs\nuse anchor_lang :: prelude ::* ;\ndeclare_id! ( \"BYFW1vhC1ohxwRbYoLbAWs86STa25i9sD5uEusVjTYNd\" );\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);\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\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}\nProgram Accounts\nThe accounts array in the IDL corresponds to the structs in a program\nannotated with the #[account] attribute. These structs define the data stored\non accounts created by the program.\nThe program below defines a NewAccount struct with a single data field of\ntype u64 .\nlib.rs\nuse anchor_lang :: prelude ::* ;\ndeclare_id! ( \"BYFW1vhC1ohxwRbYoLbAWs86STa25i9sD5uEusVjTYNd\" );\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);\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\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}\nDiscriminators\nAnchor assigns a unique 8 byte discriminator to each instruction and account\ntype in a program. These discriminators serve as identifiers to distinguish\nbetween different instructions or account types.\nThe discriminator is generated using the first 8 bytes of the Sha256 hash of a\nprefix combined with the instruction or account name. As of Anchor v0.30, these\ndiscriminators are included in the IDL file.\nNote that when working with Anchor, you typically won't need to interact\ndirectly with these discriminators. This section is primarily to provide\ncontext on how the discriminator is generated and used.\nThe instruction discriminator is used by the program to determine which specific\ninstruction to execute when called.\nWhen an Anchor program instruction is invoked, the discriminator is included as\nthe first 8 bytes of the instruction data. This is done automatically by the\nAnchor client.\nIDL\n\"instructions\" : [\n{\n\"name\" : \"initialize\" ,\n\" discriminator \" : [ 175 , 175 , 109 , 31 , 13 , 152 , 155 , 237 ],\n...\n}\n]\nThe discriminator for an instruction is the first 8 bytes of the Sha256 hash of\nthe prefix global plus the instruction name.\nFor example:\nsha256(\"global:initialize\")\nHexadecimal output:\naf af 6d 1f 0d 98 9b ed d4 6a 95 07 32 81 ad c2 1b b5 e0 e1 d7 73 b2 fb bd 7a b5 04 cd d4 aa 30\nThe first 8 bytes are used as the discriminator for the instruction.\naf = 175\n6d = 109\n1f = 31\n0d = 13\n98 = 152\n9b = 155\ned = 237\nYou can find the implementation of the discriminator generation in the Anchor\ncodebase\nhere ,\nfor the\ngen_discriminator method here ,\nwhich is used\nhere .\nPrevious\nProgram Structure\nNext\nProgram Derived Address\nOn this page\nProgram Instructions Program Accounts Discriminators\nEdit on GitHub"}
{"url":"https://docs.anza.xyz/cli/examples/test-validator","domain":"docs.anza.xyz","title":"Solana Test Validator | Agave","hash":"0b19a14b1a7785e75f9630ab396f5ab6c37bea2c26519f6dab666a25ccf71368","tokens":1056,"chars":4221,"crawler":"crawler-f6nn","verified":"exact","ts":1791171891839,"text":"Skip to main content\nSolana Test Validator\nDuring early stage development, it is often convenient to target a cluster with\nfewer restrictions and more configuration options than the public offerings\nprovide. This is easily achieved with the solana-test-validator binary, which\nstarts a full-featured, single-node cluster on the developer's workstation.\nAdvantages\n- No RPC rate-limits\n- No airdrop limits\n- Direct on-chain program deployment\n( --bpf-program ... )\n- Clone accounts from a public cluster, including programs ( --clone ... )\n- Load accounts from files\n- Configurable transaction history retention ( --limit-ledger-size ... )\n- Configurable epoch length ( --slots-per-epoch ... )\n- Jump to an arbitrary slot ( --warp-slot ... )\nInstallation\nThe solana-test-validator binary ships with the Solana CLI Tool Suite.\nInstall before continuing.\nRunning\nFirst take a look at the configuration options\nsolana-test-validator --help\nNext start the test validator\nsolana-test-validator\nBy default, basic status information is printed while the process is running.\nSee Appendix I for details\nLedger location: test-ledger\nLog: test-ledger/validator.log\nIdentity: EPhgPANa5Rh2wa4V2jxt7YbtWa3Uyw4sTeZ13cQjDDB8\nGenesis Hash: 4754oPEMhAKy14CZc8GzQUP93CB4ouELyaTs4P8ittYn\nVersion: 1.6.7\nShred Version: 13286\nGossip Address: 127.0.0.1:1024\nTPU Address: 127.0.0.1:1027\nJSON RPC URL: http://127.0.0.1:8899\n⠈ 00:36:02 | Processed Slot: 5142 | Confirmed Slot: 5142 | Finalized Slot: 5110 | Snapshot Slot: 5100 | Transactions: 5142 | ◎499.974295000\nLeave solana-test-validator running in its own terminal. When it is no longer\nneeded, it can be stopped with ctrl-c.\nInteracting\nOpen a new terminal to interact with a running solana-test-validator\ninstance using other binaries from the Solana CLI Tool Suite or your own client\nsoftware.\nConfigure the CLI Tool Suite to target a local cluster by default\nsolana config set --url http://127.0.0.1:8899\nVerify the CLI Tool Suite configuration\nsolana genesis-hash\n- NOTE: The result should match the Genesis Hash: field in the\nsolana-test-validator status output\nCheck the wallet balance\nsolana balance\n- NOTE: Error: No such file or directory (os error 2) means that the default\nwallet does not yet exist. Create it with solana-keygen new .\n- NOTE: If the wallet has a zero SOL balance, airdrop some localnet SOL with\nsolana airdrop 10\nPerform a basic transfer transaction\nsolana transfer EPhgPANa5Rh2wa4V2jxt7YbtWa3Uyw4sTeZ13cQjDDB8 1\nMonitor msg!() output from on-chain programs\nsolana logs\n- NOTE: This command needs to be running when the target transaction is\nexecuted. Run it in its own terminal\nAppendix I: Status Output\nLedger location: test-ledger\n- File path of the ledger storage directory. This directory can get large. Store\nless transaction history with --limit-ledger-size ... or relocate it with\n--ledger ...\nLog: test-ledger/validator.log\n- File path of the validator text log file. The log can also be streamed by\npassing --log . Status output is suppressed in this case.\nIdentity: EPhgPANa5Rh2wa4V2jxt7YbtWa3Uyw4sTeZ13cQjDDB8\n- The validator's identity in the gossip network\nVersion: 1.6.7\n- The software version\nGossip Address: 127.0.0.1:1024\nTPU Address: 127.0.0.1:1027\nJSON RPC URL: http://127.0.0.1:8899\n- The network address of the Gossip ,\nTransaction Processing Unit and JSON RPC\nservice, respectively\n⠈ 00:36:02 | Processed Slot: 5142 | Confirmed Slot: 5142 | Finalized Slot: 5110 | Snapshot Slot: 5100 | Transactions: 5142 | ◎499.974295000\n- Session running time, current slot of the three block\ncommitment levels ,\nslot height of the last snapshot, transaction count,\nvoting authority balance\nAppendix II: Runtime Features\nBy default, the test validator runs with all runtime features activated.\nYou can verify this using the Solana command-line tools :\nsolana feature status -ul\nSince this may not always be desired, especially when testing programs meant for deployment to mainnet, the CLI provides an option to deactivate specific features:\nsolana-test-validator --deactivate-feature --deactivate-feature \n- Advantages\n- Installation\n- Running\n- Interacting\n- Appendix I: Status Output\n- Appendix II: Runtime Features"}
{"url":"https://forum.solana.com/c/research/9","domain":"forum.solana.com","title":"Latest Research topics - Solana Developer Forums","hash":"cfe8c9d15febf8dbb94a2b344344bd21084008e596fab7d23834b605f6e96aaf","tokens":264,"chars":1054,"crawler":"crawler-f6nn","verified":"exact","ts":1791171893753,"text":"Solana Developer Forums\nResearch\nTopic\nReplies\nViews\nActivity\nAbout the Research category\n0\n538\nJune 19, 2023\nTesting Compatibility Across Solana Program Changes\ninterfaces\n0\n31\nSeptember 18, 2026\nWhat Can a Landed Solana Transaction Actually Prove About DeFi Execution?\nfeature\n0\n128\nAugust 28, 2026\nSteak Proposal - A Solana Proposal For Memecoins\n0\n388\nJuly 2, 2026\nA Practical Overview of Scheduler Implementations in Solana Validators\ncore\n1\n305\nMay 22, 2026\nState of BLS signature verification on Solana\n6\n726\nMay 3, 2026\nState of tinydancer / light clients on Solana\n0\n81\nMay 3, 2026\nHas the problem described in this paper \"Halting the Solana Blockchain with Epsilon Stake\" been mitigated?\ncore\n1\n422\nJuly 31, 2025\nDeprecate X.509 certs for P2P connections\nquic\n,\ntls\n,\np2p\n2\n1858\nJune 21, 2024\nQUIC-TLS in Firedancer (fd_tls)\nquic\n,\ntls\n,\np2p\n3\n2159\nAugust 26, 2023\nProtocol TODOs 2024\naccounts-db\n,\neconomics\n0\n1773\nJanuary 9, 2024\nBLAKE3 slower than SHA-256 for small inputs\ncryptography\n,\nperformance\n2\n2294\nDecember 28, 2023\nDiscourse Footer"}
{"url":"https://bitcoin.org/ro/","domain":"bitcoin.org","title":"Bitcoin - bani P2P open source","hash":"e7c648fa1871f693bd2c73c89553a713883f1a03a73e22fadea02c07cd79bc5f","tokens":672,"chars":2687,"crawler":"crawler-f6nn","verified":"exact","ts":1791171895963,"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- Introducere\n- Persoane fizice\n- Companii\n- Dezvoltatori\n- Noțiuni de bază\n- Cum funcționează\n- Trebuie să știi\n- Resurse\n- Exchanges\n- Comunitate\n- BIPs list\n- Vocabular\n- Bitcoin Core\n- Inovaţie\n- Participă\n- Susţine Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Dezvoltare\n- Întrebări Frecvente\n- Română\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: ro\nBitcoin reprezintă o rețea inovatoare de efectuare a plăților și o nouă monedă.\nNoțiuni de bază despre Bitcoin\nAlege portofelul tău\nBuy Bitcoin\nSau vezi pe scurt despre\nPersoane fizice\nLearn more\nCompanii\nLearn more\nDezvoltatori\nLearn more\nNoțiuni de bază despre Bitcoin\nBitcoin foloseşte tehnologia peer-to-peer pentru a opera fără vreo autoritate centrală sau bancă; administrarea tranzacţiilor şi emiterea de bitcoini se face în mod colectiv, de către reţea. Bitcoin este opensource; proiectul este public, nimeni nu deţine sau controlează Bitcoin şi oricine poate contribui . Prin multiplele sale proprietăţi unice, Bitcoin permite lucruri ce nu pot fi făcute de către vreun sistem de plăți precedent.\n-\nTranzacţii instante\npeer-to-peer\n-\nTranzacţii\nglobale\n-\nComisioane\nmici sau inexistente\nNoțiuni de bază despre Bitcoin\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroducere:\n-\nPersoane fizice\n-\nCompanii\n-\nDezvoltatori\n-\nNoțiuni de bază\n-\nCum funcționează\n-\nTrebuie să știi\nResurse:\n-\nResurse\n-\nExchanges\n-\nComunitate\n-\nBIPs list\n-\nVocabular\n-\nBitcoin Core\nParticipă:\n-\nSusţine Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nDezvoltare\nOther:\nLegal\nPrivacy Policy\nPresă\nDespre bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Lansat sub licența MIT\nNetwork Status\n- Română\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- 繁體中文\nro"}
{"url":"https://developers.skyeco.com/guides/sky/token-governance-upgrade/integrators/","domain":"developers.skyeco.com","title":"Integrators | Sky Protocol Docs","hash":"7e1594f2194b445efe797f1251e77e92992fc368fadd7193871c9e1012de132b","tokens":1717,"chars":6867,"crawler":"crawler-f6nn","verified":"exact","ts":1791171897881,"text":"Skip to content\nSky Protocol Docs\nGitHub\nSelect theme\nIntegrators\nMKR Upgrade Notice\nSection titled “MKR Upgrade Notice”\nDisplay a notice prominently on your interfaces wherever MKR or SKY tokens are referenced. This helps users understand the upgrade process and the steps required to avoid the Delayed Upgrade Penalty.\nThe Sky Ecosystem Governance community has voted to make SKY the sole governance token of the Sky Protocol. You can no longer vote with MKR. MKR holders are encouraged to upgrade to SKY promptly to maintain the ability to participate in governance and avoid the Delayed Upgrade Penalty. For more information, please visit the MKR to SKY Upgrade Hub.\nIntegrator Categories\nSection titled “Integrator Categories”\nThis section provides guidance for various platform types to ensure a seamless transition from MKR to SKY tokens. As the protocol upgrades from MKR to SKY, integrators play a critical role in helping users navigate this change. The transition involves a one-directional conversion mechanism with a time-sensitive fee structure that increases after September 2025.\nEach category below addresses specific integration points and offers actionable steps to:\n- Support both MKR and SKY tokens during the transition period\n- Help users convert their MKR to SKY through the Converter V2 contract\n- Update interfaces to accommodate the new token while maintaining user experience\n- Mitigate risks associated with diminishing MKR liquidity and potential price volatility\nReview the Upgrade Timeline and Codebase Change Analysis sections to identify the necessary steps that best fit your use case. You can contact the Integrations team at [email protected] to discuss your specific situation and develop a custom action plan.\nWallets\nSection titled “Wallets”\nList SKY Token\nEnsure your wallet lists the SKY token with the proper brand assets:\n- Token symbol: SKY\n- Token address: 0x56072C95FAA701256059aa122697B133aDEd9279\n- SKY token logo: Available on the brand assets page\nFacilitate MKR to SKY Upgrade\nDirect users to the Sky Portal where they can upgrade from MKR to SKY. You can facilitate this conversion by integrating with the Converter V2 contract.\nDEXes\nSection titled “DEXes”\nIntegrate with Converter Contract for Optimal Liquidity\nThe Converter V2 contract provides the most reliable source of MKR to SKY swap liquidity. Users can convert their tokens at a fixed ratio without incurring slippage. To support your users during the transition period:\n- Add SKY Token Support to your trading pairs and interfaces\n- Implement Direct Integration with the Converter V2 contract for seamless conversion\n- Display Conversion Information to educate users about the fixed conversion ratio\n- Update Trading UI to highlight the MKR to SKY upgrade opportunity\nAs MKR liquidity decreases over time, routing users to the Converter V2 contract will deliver a superior user experience compared to traditional market-based trading.\nExchanges\nSection titled “Exchanges”\nDirect users to navigate the upgrade process on the Sky portal. You can also integrate with the Converter V2 contract to upgrade your users’ MKR balances to SKY efficiently on their behalf.\nRewards and Borrow Positions\nSection titled “Rewards and Borrow Positions”\nThe Staking Engine introduces important changes that affect all integrators who offer Seal Engine functionality. Key improvements include the removal of exit fees and transition from MKR to SKY token support. Exit fees in the current Seal Engine V1 have also been set to 0 to allow current users to migrate without incurring any additional fees.\nIf you currently offer an interface to Seal Engine, you must update it to support Staking Engine functionality.\nKey Changes\nSection titled “Key Changes”\n- Token Support : Staking Engine only accepts SKY tokens, while Seal Engine V1 supported both MKR and SKY tokens.\n- Exit Fee Removal : The exit fee previously charged when withdrawing from positions has been eliminated. The exit fee value is set to zero in Seal Engine V1 and the feature is removed in V2.\nMigration Strategies\nSection titled “Migration Strategies”\nFor Positions Without Debt\nThe recommended approach for positions without debt is a three-step process:\n- Close the existing Seal Engine V1 position to withdraw MKR\n- Upgrade the withdrawn MKR to SKY using the Converter V2 contract\n- Open a new position in Staking Engine with the converted SKY\nUsers can maintain the same reward settings as their previous positions after migration.\nFor Positions With Outstanding Debt\nThe Sky Portal supports a specialized migration pathway that allows users to:\n- Transfer their position from Seal Engine V1 to Staking Engine\n- Automatically convert their MKR to SKY in the process\n- Maintain their existing debt without requiring repayment to complete the migration, provided there is sufficient space in the debt ceiling of Staking Engine\nLending Protocols\nSection titled “Lending Protocols”\nImplement these measures to support a smooth MKR to SKY transition:\n- List the SKY token with identical lending parameters as MKR\n- Update MKR Debt Ceiling to 0 to limit new positions with MKR.\n- Notify MKR borrowers about the upcoming conversion deadline and fee schedule\n- Provide clear documentation for closing MKR positions efficiently\nAs MKR holders convert to SKY, the diminishing MKR supply creates two significant risks:\n- Liquidity Risk : Thinning MKR markets will make it increasingly difficult for borrowers to source tokens for loan repayment\n- Price Volatility Risk : Reduced market depth may trigger severe price fluctuations, potentially leading to unexpected liquidations\nThe one-directional conversion mechanism (MKR → SKY only) creates a progressively challenging environment for borrowers who delay transition. Additionally, once the Late Conversion Phase begins in mid-September.\nFor your lending interface, add a prominent alert informing users of the conversion timeline and directing them to the SKY Portal at sky.money .\nOracles\nSection titled “Oracles”\nAvoid implementing automatic price conversions between MKR and SKY tokens. After the governance upgrade, the tokens will trade independently with MKR becoming increasingly illiquid as trading volume and market availability decrease. Due to the one-directional conversion mechanism, accurate price extrapolation between the tokens will not be reliable, even with the defined conversion ratio between MKR to SKY.\nThe MKR to SKY conversion ratio, initially set at 1:24000, is subject to reduction by governance through the fee parameter in the Converter V2 contract. This fee parameter acts as a mechanism to decrease the effective conversion rate, making the fixed-ratio relationship between the tokens subject to change.\nReleased into the public domain (CC0 1.0 Universal) – trademarks remain with their owners; no warranty. See full license ."}
{"url":"https://docs.getmonero.org/interacting/overview/","domain":"docs.getmonero.org","title":"Interacting with Monero - Monero Docs","hash":"4df357001eec559d75f67e26a0acb3d6e690054edec580b2959c31d02d90b2fe","tokens":1320,"chars":5277,"crawler":"crawler-f6nn","verified":"exact","ts":1791171900138,"text":"Skip to content\nInitializing search\nmonero-project/monero-docs\n- Tokenomics\n- Networks\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\nInteracting with Monero ¶\nYou can interact with Monero via the desktop GUI, command-line interface, and programming API.\nOn top of that, Monero nodes interact with each other in a peer-to-peer network.\nInstallation directory overview ¶\nOnce unpacked you will see several executable files. You will also find a nice PDF guide for the GUI wallet.\nMonero project nicely decouples network node logic from wallet logic. Wallet logic is offered through three independent user interfaces - the GUI, the CLI, and the HTTP API.\n# cd monero-gui-v0.18.4.5\n# ---- guide to Monero GUI ----\nmonero-gui-wallet-guide.pdf\n# ---- main executable files -----------\nmonerod\nmonero-wallet-gui\n# ---- extra executable files -----------\nextras/monero-wallet-cli\nextras/monero-wallet-rpc\nextras/monero-blockchain-prune\nextras/monero-gen-trusted-multisig\nextras/monero-gen-ssl-cert\nextras/monero-blockchain-export\nextras/monero-blockchain-import\n# ---- don't bother with these ----------\nextras/monero-blockchain-stats\nextras/monero-blockchain-mark-spent-outputs\nextras/monero-blockchain-prune-known-spent-data\nextras/monero-blockchain-usage\nextras/monero-blockchain-ancestry\nextras/monero-blockchain-depth\nExecutables ¶\nExecutable Description\nmonerod The full node daemon. Does not require a wallet.\nDocumentation .\nmonero-wallet-gui Wallet logic and graphical user interface.\nRequires monerod running.\nmonero-wallet-cli Wallet logic and commandline user interface.\nRequires monerod running.\nmonero-wallet-rpc Wallet logic and HTTP API (JSON-RPC protocol).\nRequires monerod running.\nmonero-blockchain-prune Prune existing local blockchain. This saves 2/3 of disk space (down to 100 GiB as of 2026-01-20). This is preferable over monerod --prune-blockchain which only logically releases space inside the file while the file remains large. The monero-blockchain-prune creates a shrunken copy of the blockchain file. See tutorial1 , tutorial2 .\nmonero-gen-ssl-cert Generate 4096 bit RSA private key and self signed TLS certificate for use with monerod RPC interface. Note, Monero daemon automatically generates TLS certificate on each restart. Manual generation with this tool is only useful if you want to pin TLS certificate fingerprint in your monero wallet. See the pull request .\nmonero-gen-trusted-multisig Tool to generate a set of multisig wallets.\nSee chapter on multisignatures .\nmonero-blockchain-export Tool to export blockchain to blockchain.raw file.\nmonero-blockchain-import Tool to import a raw blockchain, ideally your own trusted copy.\nExecutables - legacy ¶\nYou most likely should not bother with these legacy or very specialized tools.\nExecutable Description\nmonero-blockchain-stats Generate stats like tx/day, blocks/day, bytes/day based on your local blockchain.\nmonero-blockchain-mark-spent-outputs Advanced tool to mitigate potential privacy issues related to Monero forks. You normally shouldn't be concerned with that.\nSee the commit and pull request .\nmonero-blockchain-prune-known-spent-data Previous limited pruning tool to prune select \"known spent\" transaction outputs (from the before RCT era). Nowadays prefer monero-blockchain-prune . This only saves ~200 MB. See the commit .\nmonero-blockchain-usage Advanced tool to mitigate potential privacy issues related to Monero forks. You normally shouldn't be concerned with that.\nSee the commit and the pull request .\nmonero-blockchain-ancestry Advanced research tool to learn ancestors of a transaction, block or chain. Irrelevant for normal users. See this pull request .\nmonero-blockchain-depth Advanced research tool to learn depth of a transaction, block or chain. Irrelevant for normal users. See this commit .\nInteracting ¶\nThere are quite a few ways you can interact with Monero software. Perhaps the most surprising for newcomers is that monerod daemon accepts interactive keyboard commands while it is running.\nAlso, please note that monerod and monero-wallet-rpc are both accessible via their respective HTTP API / JSON-RPC endpoints.\n- monerod-rpc\n- wallet-rpc\nAll wallet implementations depend on a fully synchronized monerod running.\nExecutable p2p network commands via keyboard HTTP API GUI\nmonerod ✔ ✔ ✔\nmonero-wallet-cli ✔\nmonero-wallet-rpc ✔\nmonero-wallet-gui ✔\nData directory ¶\nThis is where the blockchain, log files, and p2p network memory are stored.\nBy default data directory is at:\n- $HOME/.bitmonero/ on Linux and macOS\n- C:\\ProgramData\\bitmonero\\ on Windows\nPlease keep in mind:\n- data directory is hidden as per OS convention\n- the bitmonero directory name is a historical artifact from before Monero forked away from Bitmonero\nData directory contains:\n- lmdb/ - the blockchain database directory\n- p2pstate.bin - saved memory of discovered and rated peers\n- bitmonero.log - log file\nIt can also contain subdirectories for stagenet and testnet, mirroring the same structure:\n- stagenet/ - data directory for Stagenet\n- testnet/ - data directory for Testnet"}
{"url":"https://docs.velocity.exchange/developers/migrate-from-drift","domain":"docs.velocity.exchange","title":"Migrating from Drift | Velocity Protocol","hash":"896b73fc4a5458f4614a0676a92521a31d265b6739c191012303cc2cce2ebdba","tokens":3456,"chars":13824,"crawler":"crawler-f6nn","verified":"exact","ts":1791171902977,"text":"Velocity Protocol Developers\nMigrate from Drift\nView as Markdown\nMigrating from Drift\nVelocity is a fork of Drift v2 at SDK v2.163.0-beta.0, not an upgrade in place: a new program deployment, no onchain state carried over, and every PDA address different.\nVelocity Protocol is a fork of Drift Protocol v2, taken at Drift SDK v2.163.0-beta.0 . It is not an upgrade of Drift in place. It is an entirely new onchain program deployment with a new program ID, a reduced feature set, and its own renamed SDK. The Drift program is paused, and no onchain state carries over : user accounts must be re-initialized and balances start fresh on Velocity.\nBecause the program ID changed, every PDA address is different from Drift: even for the accounts whose seeds are byte-for-byte unchanged ( user , user_stats , perp_market , spot_market , spot_market_vault , insurance_fund_vault ). One trading seed was also renamed: the State PDA seed went from drift_state to velocity_state . Never reuse a Drift-derived address on Velocity.\nAt a glance\nDrift Velocity\nProgram ID dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH vELoC1audYbSYVRXn1vPaV8Axoa9oU6BYmNGZZBDZ1P\nnpm package @drift-labs/sdk ( 2.163.0-beta.0 ) @velocity-exchange/sdk ( 0.20.0 )\nClient class DriftClient VelocityClient (no back-compat alias)\nAnchor @coral-xyz/anchor@0.29.0 @anchor-lang/core@1.0.1 (aliased as @coral-xyz/anchor )\nIDL file drift.json velocity.json\nMainnet quote asset USDC USDT\nData API host data.api.drift.trade data.velocity.exchange\nThis page covers the TypeScript SDK at @velocity-exchange/sdk 0.20.0. Rust ( velocity-rs ) and raw-ABI integrators need the full layout-and-ABI reference as well, which lives in the velocity-v1 monorepo. That repository is not public; ask the team for the document.\nQuote asset is now USDT\nThis is the single most money-relevant change. On Drift, spot market 0 (the cross-margin quote and collateral asset) is USDC . On Velocity mainnet-beta it is USDT .\nNetwork Quote mint\nDrift mainnet (USDC) EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\nVelocity mainnet-beta (USDT) Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB\nVelocity devnet (dUSDT placeholder) GqmEqYsy8EyvofDpmtFxK8zhYrgWgNokAtYoduQdL7v6\nBoth are 6-decimal SPL tokens, so notional amounts look identical and nothing type-checks differently. A desk that funds accounts with USDC, as it did on Drift, is depositing the wrong token: deposits, withdrawals, ATA derivation, collateral, and settlement all reference the USDT mint.\nSwitch every quote-mint hardcode and associated token account to USDT on mainnet, and to dUSDT on devnet. Never assume QUOTE_MINT_ADDRESS == USDC . The reliable fix is to stop hardcoding the mint at all and read getConfig().QUOTE_MINT_ADDRESS ; see Setup for the config accessor.\nRemoved features\nSeveral Drift subsystems were dropped. Their SDK exports are gone (no back-compat), and their onchain error variants are preserved only as deprecated, code-stable stubs.\nFeature What changed\nSpot DLOB trading place_spot_order , place_and_take_spot_order , place_and_make_spot_order , fill_spot_order are removed. Spot markets still exist (for collateral and borrow-lend) but placing orders on a spot book is not possible. Attempting it returns SpotDlobTradingDisabled (6350).\nExternal spot fulfillment Serum, Phoenix, and OpenBook fulfillment are gone. The serum/* , phoenix/* , openbook/* subscribers and fulfillment-config maps, and the SERUM_V3 / PHOENIX / OPENBOOK env config fields, are removed.\nFuel The math/fuel module and the FuelSeasonRecord / FuelSweepRecord event types are removed.\nvAMM LP (BAMM) shares LP provisioning on the vAMM is gone: PerpPosition.lp_shares and the LPRecord / LPAction types are removed.\nProtected maker mode The four protected-maker instructions, the ProtectedMakerModeConfig account type, and VelocityClient.updateUserProtectedMakerOrders are removed.\nHigh leverage mode The five HLM instructions and their config-account subscribers are removed. The onchain MarginMode enum and the User.marginMode field are gone. (The TS MarginMode class still exists in the SDK, reduced to DEFAULT only, so imports don't break.)\nPrediction markets initialize_prediction_market is removed; ContractType.PREDICTION is now DEPRECATED_PREDICTION .\nLegacy Pyth pull/push The legacy Pyth pull/push instructions are removed, along with oracles/pythPullClient and util/pythOracleUtils . Pyth Lazer is the supported Pyth path. The PythSolanaReceiver and WormholeCoreBridgeSolana root exports are also gone.\nSwitchboard oracles oracles/switchboardClient and oracles/switchboardOnDemandClient are removed; the OracleSource Switchboard variants are renamed DEPRECATED_SWITCHBOARD / DEPRECATED_SWITCHBOARD_ON_DEMAND (discriminants preserved).\nGov-token stake fee discounts Staking a gov token for a fee discount is gone: updateUserGovTokenInsuranceStake , GOV_SPOT_MARKET_INDEX , and the delegate variant are removed. Perp fee tier is now based on 30-day volume, floored by an admin-set promo tier (see below).\nIF rebalance / protocol-IF shares Protocol-owned insurance-fund shares and IF rebalancing are removed (the admin IF-withdraw, protocol-IF-share transfer, IF-swap, and IF-rebalance-config instructions).\nLegacy referrer-reward fee path UserStats.fees.total_referrer_reward , UserStats.fees.current_epoch_referrer_reward , and UserStats.next_epoch_ts are deleted; FeeStructure.referrer_reward_epoch_upper_bound is now padding. The SDK's referrerInfo? param is dropped from placeAndMakePerpOrder , placeAndMakeSignedMsgPerpOrder , and fillPerpOrder .\nNew on Velocity\nVelocity also adds subsystems Drift never had. In brief:\n- Velocity liquidity pool module : a liquidity-pool and vAMM-hedge component, configured per market through PerpMarketAccount.hedgeConfig .\n- Isolated perp positions : per-position isolated collateral. The instructions are feature-gated out of mainnet builds pending audit ; the state layout is present in every build.\n- Builder codes : the change_approved_builder instruction, a RevenueShare escrow account, and ReferrerStatus.BuilderReferral = 4 . See Builder Codes .\n- Tiered admin keys : the single State.admin is split into cold_admin , warm_admin , pause_admin , and a set of narrowly scoped hot keys. See Account Model .\n- Continuous funding dead zone : a per-market funding clamp threshold and ramp slope, fundingClampThreshold and fundingRampSlope .\n- Per-market funding-bias spread widening : an opt-in vAMM spread widen on the funding-paying side, off by default.\n- Fast-fill auctions : the DLOB server can force fast, marketable auctions. See the behavior changes below.\n- Protocol fee redesign : fees are re-routed through a three-way AMM, insurance fund, and protocol split rather than changing the taker rate itself.\nBehavior changes to review\nThese are semantic changes a compiler cannot catch: a port that builds cleanly can still mispredict onchain behavior. What follows is the shortlist, ordered by impact for a market maker. Every item is enumerated in full, with the exact condition and the check to run, in Section 5 of the agent guide , which is the reference version of this list.\n- Quote asset is USDT on mainnet. See above. Funding an account with the wrong token is the highest-severity failure mode on this page.\n- Fast-fill auctions. At DLOB server API version 3 and above, every market is fast-fill: the auction starts inside the touch and lasts 2000ms of wall clock. Auctions become marketable almost immediately, so a maker quoting off stale prices gets run over. Derive the window from the live slot duration rather than hardcoding 5 slots, and use the generatedAt response field for staleness checks.\n- Trigger orders are priced at their post-trigger price. The Rust DLOB library used by fillers and keeper bots now rewrites a resting trigger order's book price to its computed post-trigger auction price, clamped to the limit price for TriggerLimit , instead of tagging it with the raw trigger price. Stop assuming a resting trigger order's book price equals its trigger price.\n- AMM JIT is dropped from match fills under a hard gate. With a pause, a drawdown, MM-oracle volatility, or an invalid oracle in force, a DLOB match fills DLOB-only and fills can be capped to the resting maker's size. Do not assume AMM JIT backstops a match.\n- MM-oracle native writes are throttled and clamped. update_mm_oracle_native silently skips a write, returning Ok with no error, on a non-positive price, a non-increasing sequence id, a non-advancing slot, or a source slot more than 800ms from the landing slot. An oversized price step is the exception: it is clamped to the 1% per-write cap and written, so a large move converges over several writes rather than freezing the oracle. Throttle crank writes to at least 800ms apart and expect no error signal when one is dropped.\n- The funding floor rose from 7.3% to 10.95% annualized. FUNDING_RATE_OFFSET_DENOMINATOR dropped from 5000 to 3333, making the always-applied floor and ceiling roughly 1.5x higher. The SDK mirror is in sync, so re-pull it and re-model funding carry on any perp inventory.\n- Fee costs changed for referred and previously staked accounts. The gov-token stake discount is gone; the perp fee tier now comes from 30-day volume, floored by the admin-set State.promo_fee_tier where 0 means no floor. Separately, getMarketFees now subtracts the referee discount, and calculateFeeForQuoteAmount became calculatePerpTakerFee , which rounds predicted fees up rather than down. Re-model taker fees with no stake benefit.\n- MarketStatus discriminants shifted. Four now-removed pause variants sat between Active and ReduceOnly on Drift, so ReduceOnly , Settlement , and Delisted were 6, 7, and 8. They are 2, 3, and 4 here. IDL-based decoding is fine; any custom raw-byte decoder silently misclassifies market state until it is rebuilt.\n- Bulk order margin is tighter. place_orders and place_scale_orders accumulate risk across the batch and check initial margin once per touched risk scope, instead of gating only the last order at maintenance margin. Batches that previously slipped a risk-increasing order past a weak gate now revert with InsufficientCollateral . Size batches against initial margin.\n- Deposits and transfers enforce per-market admission. Same-market transfer_deposit , its delegate variant, and direct deposit() now apply the full admission logic: active status, max_token_deposits , the reduce-only cap, and the per-market Deposit pause bit independently of the global pause. Calls that used to succeed against a capped, non-active, or reduce-only market now revert. Pre-check spot market status and caps.\nData API: Drift-only columns\nThe Data API's Trades/Market Trades tables drop the spotFulfillmentMethodFee column (external spot fulfillment is removed), and the Funding Rates table drops periodRevenue and baseAssetAmountWithUnsettledLp (vAMM LP shares are removed). One entire table has no Velocity equivalent:\nLP (BAL), Drift-only, no Velocity equivalent. Drift's vAMM LP shares ( PerpPosition.lpShares and the addLiquidity / settleLiquidity actions below) were removed entirely on Velocity. There is no per-user LP-share mechanism to emit these events. Liquidity provision against a market now happens through the separate Velocity liquidity pool module (a hedge-pool architecture configured per-market via PerpMarketAccount.hedgeConfig ), which has its own accounting and does not map onto this table.\nColumn Unit Description\naction addLiquidity / settleLiquidity\nnShares int Number of perpetual contract shares traded.\ndeltaBaseAssetAmount int Change in base asset position due to the trade.\ndeltaQuoteAssetAmount int Change in quote asset position due to the trade.\npnl int Profit or loss from the trade.\nSee the Data API glossary for the full current column reference.\nSDK surface\nThe headline renames a TypeScript integrator hits first: there are no back-compat aliases , so these surface as build errors:\n- DriftClient → VelocityClient\n- DRIFT_PROGRAM_ID → VELOCITY_PROGRAM_ID\n- DriftEnv → VelocityEnv\n- Account subscribers: webSocketDriftClientAccountSubscriber(V2) → webSocketVelocityClientAccountSubscriber(V2) , pollingDriftClientAccountSubscriber → pollingVelocityClientAccountSubscriber , grpcDriftClientAccountSubscriber(V2) → grpcVelocityClientAccountSubscriber(V2)\n- Config field USDC_MINT_ADDRESS → QUOTE_MINT_ADDRESS\n- Order.oraclePriceOffset / OrderParams.oraclePriceOffset widened from number to BN : wrap raw numbers in new BN(...)\n- Removed root exports include PythSolanaReceiver and WormholeCoreBridgeSolana : importing either from the package root now breaks\nNote also that the IDL account names are PascalCase (e.g. PerpMarket , SpotMarket , User ). Pass those exact names to the account coder.\nFor the exhaustive symbol tables and a step-by-step procedure an AI coding agent can execute, see the AI Agent Migration Guide .\nScope & currency\nThis page reflects @velocity-exchange/sdk 0.20.0 and covers the TypeScript SDK. The canonical layout-and-ABI reference, which Rust ( velocity-rs ) and raw-ABI integrators need, is docs/DRIFT-TO-VELOCITY.md in the velocity-v1 monorepo. That repository is not public and will not be until the post-fork audit report is final, so ask the team for the document rather than looking for a clone URL.\nEdit on GitHub\nData API Glossary\nEvery column the Data API returns, grouped by category, with the ones Velocity has since removed marked inline.\nAI Agent Migration Guide\nExecutable instructions for an AI coding agent migrating a TypeScript codebase from @drift-labs/sdk to @velocity-exchange/sdk: inventory, ordered procedure, symbol maps, and what to stop on.\nOn this page\nAt a glance\nQuote asset is now USDT\nRemoved features\nNew on Velocity\nBehavior changes to review\nData API: Drift-only columns\nSDK surface\nScope & currency"}
{"url":"https://www.anchor-lang.com/docs/testing/litesvm","domain":"www.anchor-lang.com","title":"LiteSVM","hash":"d0c6f7d5e5fa96550bde85954bccb59b554609dbb6a1107a5c7d63c7819c762a","tokens":2119,"chars":8473,"crawler":"crawler-f6nn","verified":"exact","ts":1791171905176,"text":"Anchor Docs\nGithub Discord Stack Exchange\nTesting Libraries\nLiteSVM\nWrite tests for Solana programs in Rust, TS/JS or Python using LiteSVM.\nOverview\nlitesvm is a fast and lightweight library for testing Solana programs.\nIt works by creating an in-process Solana VM optimized for program developers.\nThis makes it much faster to run and compile than alternatives like solana-program-test and solana-test-validator .\nlitesvm is available in Rust, TS/JS and Python (as part of the solders library).\nInstallation\ncargo add litesvm --dev\nMinimal Example\nuse litesvm :: LiteSVM ;\nuse solana_message :: Message ;\nuse solana_pubkey :: Pubkey ;\nuse solana_system_interface :: instruction :: transfer;\nuse solana_keypair :: Keypair ;\nuse solana_signer :: Signer ;\nuse solana_transaction :: Transaction ;\nlet from_keypair = Keypair :: new ();\nlet from = from_keypair . pubkey ();\nlet to = Pubkey :: new_unique ();\nlet mut svm = LiteSVM :: new ();\nsvm . airdrop ( & from, 10_000 ) . unwrap ();\nlet instruction = transfer ( & from, & to, 64 );\nlet tx = Transaction :: new (\n& [ & from_keypair],\nMessage :: new ( & [instruction], Some ( & from)),\nsvm . latest_blockhash (),\n);\nlet tx_res = svm . send_transaction (tx) . unwrap ();\nlet from_account = svm . get_account ( & from);\nlet to_account = svm . get_account ( & to);\nassert_eq! (from_account . unwrap () . lamports, 4936 );\nassert_eq! (to_account . unwrap () . lamports, 64 );\nDeploying Programs\nMost of the time we want to do more than just mess around with token transfers -\nwe want to test our own programs.\nTip : if you want to pull a Solana program from mainnet or devnet, use the solana program dump command from the Solana CLI.\nTo add a compiled program to our tests we can use .add_program_from_file .\nHere's an example using a simple program\nfrom the Solana Program Library that just does some logging:\nuse {\nlitesvm :: LiteSVM ,\nsolana_instruction :: { account_meta :: AccountMeta , Instruction },\nsolana_keypair :: Keypair ,\nsolana_pubkey :: {pubkey, Pubkey },\nsolana_message :: { Message , VersionedMessage },\nsolana_signer :: Signer ,\nsolana_transaction :: VersionedTransaction ,\n};\nfn test_logging () {\nlet program_id = pubkey! ( \"Logging111111111111111111111111111111111111\" );\nlet account_meta = AccountMeta {\npubkey : Pubkey :: new_unique (),\nis_signer : false ,\nis_writable : true ,\n};\nlet ix = Instruction {\nprogram_id,\naccounts : vec! [account_meta],\ndata : vec! [ 5 , 10 , 11 , 12 , 13 , 14 ],\n};\nlet mut svm = LiteSVM :: new ();\nlet payer = Keypair :: new ();\nlet bytes = include_bytes! ( \"../../node-litesvm/program_bytes/spl_example_logging.so\" );\nsvm . add_program (program_id, bytes);\nsvm . airdrop ( & payer . pubkey (), 1_000_000_000 ) . unwrap ();\nlet blockhash = svm . latest_blockhash ();\nlet msg = Message :: new_with_blockhash ( & [ix], Some ( & payer . pubkey ()), & blockhash);\nlet tx = VersionedTransaction :: try_new ( VersionedMessage :: Legacy (msg), & [payer]) . unwrap ();\n// let's sim it first\nlet sim_res = svm . simulate_transaction (tx . clone ()) . unwrap ();\nlet meta = svm . send_transaction (tx) . unwrap ();\nassert_eq! (sim_res . meta, meta);\nassert_eq! (meta . logs[ 1 ], \"Program log: static string\" );\nassert! (meta . compute_units_consumed < 10_000 ) // not being precise here in case it changes\n}\nTime travel\nMany programs rely on the Clock sysvar: for example, a mint that doesn't become available until after\na certain time. With litesvm you can dynamically overwrite the Clock sysvar\nusing svm.set_sysvar::()\n(or .setClock in TS, or .set_clock in Python).\nHere's an example using a program that panics if clock.unix_timestamp is greater than 100\n(which is on January 1st 1970):\nuse {\nlitesvm :: LiteSVM ,\nsolana_clock :: Clock ,\nsolana_instruction :: Instruction ,\nuse solana_keypair :: Keypair ,\nsolana_message :: { Message , VersionedMessage },\nsolana_pubkey :: Pubkey ,\nsolana_signer :: Signer ,\nsolana_transaction :: VersionedTransaction ,\n};\nfn test_set_clock () {\nlet program_id = Pubkey :: new_unique ();\nlet mut svm = LiteSVM :: new ();\nlet bytes = include_bytes! ( \"../../node-litesvm/program_bytes/litesvm_clock_example.so\" );\nsvm . add_program (program_id, bytes);\nlet payer = Keypair :: new ();\nlet payer_address = payer . pubkey ();\nsvm . airdrop ( & payer . pubkey (), 1_000_000_000 ) . unwrap ();\nlet blockhash = svm . latest_blockhash ();\nlet ixs = [ Instruction {\nprogram_id,\ndata : vec! [],\naccounts : vec! [],\n}];\nlet msg = Message :: new_with_blockhash ( & ixs, Some ( & payer_address), & blockhash);\nlet versioned_msg = VersionedMessage :: Legacy (msg);\nlet tx = VersionedTransaction :: try_new (versioned_msg, & [ & payer]) . unwrap ();\n// set the time to January 1st 2000\nlet mut initial_clock = svm . get_sysvar :: < Clock >();\ninitial_clock . unix_timestamp = 1735689600 ;\nsvm . set_sysvar :: < Clock >( & initial_clock);\n// this will fail because it's not January 1970 anymore\nsvm . send_transaction (tx) . unwrap_err ();\n// so let's turn back time\nlet mut clock = svm . get_sysvar :: < Clock >();\nclock . unix_timestamp = 50 ;\nsvm . set_sysvar :: < Clock >( & clock);\nlet ixs2 = [ Instruction {\nprogram_id,\ndata : vec! [ 1 ], // unused, this is just to dedup the transaction\naccounts : vec! [],\n}];\nlet msg2 = Message :: new_with_blockhash ( & ixs2, Some ( & payer_address), & blockhash);\nlet versioned_msg2 = VersionedMessage :: Legacy (msg2);\nlet tx2 = VersionedTransaction :: try_new (versioned_msg2, & [ & payer]) . unwrap ();\n// now the transaction goes through\nsvm . send_transaction (tx2) . unwrap ();\n}\nSee also: warp_to_slot , which lets you jump to a future slot.\nWriting arbitrary accounts\nLiteSVM lets you write any account data you want, regardless of\nwhether the account state would even be possible.\nHere's an example where we give an account a bunch of USDC,\neven though we don't have the USDC mint keypair. This is\nconvenient for testing because it means we don't have to\nwork with fake USDC in our tests:\nuse {\nlitesvm :: LiteSVM ,\nsolana_account :: Account ,\nsolana_program_option :: COption ,\nsolana_program_pack :: Pack ,\nsolana_pubkey :: {pubkey, Pubkey },\nspl_associated_token_account_client :: address :: get_associated_token_address,\nspl_token :: {\nstate :: { Account as TokenAccount , AccountState },\nID as TOKEN_PROGRAM_ID ,\n},\n};\nfn test_infinite_usdc_mint () {\nlet owner = Pubkey :: new_unique ();\nlet usdc_mint = pubkey! ( \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\" );\nlet ata = get_associated_token_address ( & owner, & usdc_mint);\nlet usdc_to_own = 1_000_000_000_000 ;\nlet token_acc = TokenAccount {\nmint : usdc_mint,\nowner : owner,\namount : usdc_to_own,\ndelegate : COption :: None ,\nstate : AccountState :: Initialized ,\nis_native : COption :: None ,\ndelegated_amount : 0 ,\nclose_authority : COption :: None ,\n};\nlet mut svm = LiteSVM :: new ();\nlet mut token_acc_bytes = [ 0 u8 ; TokenAccount :: LEN ];\nTokenAccount :: pack (token_acc, &mut token_acc_bytes) . unwrap ();\nsvm . set_account (\nata,\nAccount {\nlamports : 1_000_000_000 ,\ndata : token_acc_bytes . to_vec (),\nowner : TOKEN_PROGRAM_ID ,\nexecutable : false ,\nrent_epoch : 0 ,\n},\n)\n. unwrap ();\nlet raw_account = svm . get_account ( & ata) . unwrap ();\nassert_eq! (\nTokenAccount :: unpack ( & raw_account . data) . unwrap () . amount,\nusdc_to_own\n)\n}\nCopying Accounts from a live environment\nIf you want to copy accounts from mainnet or devnet, you can use the solana account command in the Solana CLI to save account data to a file.\nOther features\nOther things you can do with litesvm include:\n- Changing the max compute units and other compute budget behaviour using .with_compute_budget .\n- Disable transaction signature checking using .with_sigverify(false) .\n- Find previous transactions using .get_transaction .\nWhen should I use solana-test-validator ?\nWhile litesvm is faster and more convenient, it is also less like a real RPC node.\nSo solana-test-validator is still useful when you need to call RPC methods that LiteSVM\ndoesn't support, or when you want to test something that depends on real-life validator behaviour\nrather than just testing your program and client code.\nIn general though it is recommended to use litesvm wherever possible, as it will make your life\nmuch easier.\nPrevious\nTesting\nNext\nMollusk\nOn this page\nOverview Installation Minimal Example Deploying Programs Time travel Writing arbitrary accounts Copying Accounts from a live environment Other features When should I use solana-test-validator ?\nEdit on GitHub"}
{"url":"https://docs.monad.xyz/faq","domain":"docs.monad.xyz","title":"Frequently Asked Questions - Monad Documentation","hash":"f1e230173d84961edab91da492850a8b74b59fd224afbee1a58097ea6045d399","tokens":3296,"chars":13181,"crawler":"crawler-f6nn","verified":"exact","ts":1791171908318,"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\nFrequently Asked Questions\nExecution\nAre there any differences in opcode pricing?\nA few opcodes and precompiles have been repriced to more correclty account for their relative\ncost. See details here .\nHow does Monad's optimistic parallel execution manage interdependent transactions?\nIn Monad, like in Ethereum, transactions are ordered linearly within a block. The guarantee\nthat Monad provides is that the result at the end of each block will be as if the transactions\nwere executed serially, even though under the hood there was work done in parallel. Monad handles interdependent transactions gracefully by separating the concerns of\ncomputation (which can be done in parallel) from commitment (which is still done\nserially). Transactions are computed in parallel optimistically (i.e. assuming that any storage slots read\nin during execution are correct), generating a pending result for each transaction. A pending\nresult consists of the set of input storage slots (and their values) and output storage slots\n(and their values). Pending results are committed serially in the original order of the transactions, checking\neach input for correctness at the time of commitment. (An input will be incorrect if it was\nmutated by one of the previously-committed pending results.) If a pending result has any\nincorrect inputs, it will be re-executed; no other pending results can be committed until\nthat completes. Committing pending results serially ensures that correctness is always preserved.\nAn example illustrates this best. Suppose that at the start of a block, Alice, Bob, and\nCharlie each have a balance of 100 USDC. These are the first two transactions:\nTransaction # What happens\n0 Alice sends Bob 5 USDC\n1 Bob sends Charlie 10 USDC\nWhen transactions 0 and 1 are executed in parallel, they produce the following pending results:\nPending Result # Inputs Outputs\n0 Alice: 100\nBob: 100 Alice: 95\nBob: 105\n1 Bob: 100\nCharlie: 100 Bob: 90\nCharlie: 110\nNow we commit the pending results serially. Pending result 0 gets committed. When we try to\ncommit pending result 1, we notice that one of the inputs is wrong - Bob’s balance was expected\nto be 100, but it is actually 105. This re-triggers execution for transaction 1. No other\ntransactions can be committed until transaction 1 is re-executed.\nIn optimistic parallel execution, transactions get re-executed if their first execution was done with inputs that subsequently were mutated. What if there is a long list of serially dependent transactions?\n(Note: This question is asking about re-execution as discussed here .) While it’s true that having to re-execute a pending result is slower than immediately committing\nit, re-execution is also typically much faster than the original execution because inputs are\nstored in cache (RAM). Also note that every transaction will be executed at most twice: once\ninitially, and once on re-execution. More generally, you can think of optimistic parallel execution as a two-pass strategy. The first\npass begins executing many transactions in parallel, thus surfacing many storage slot\ndependencies in parallel and pulling them all into cache. The second pass iterates over the\ntransactions serially, either committing the pending result immediately or re-executing it (but\nfrom a position where most storage slots are cached). This strategy, combined with efficient SSD\nlookups from MonadDb , delivers a workload that uses the full\nSSD throughput more efficiently.\nDo I need to change my code to take advantage of Monad’s parallelism? Would it make sense to split my contract into many contracts to reduce the probability of two transactions touching the same contract?\nNo, no need! Transactions interacting with your smart contract behave as if every transaction\nis being executed serially. Parallel execution is strictly an implementation detail. Also, it is important to note that all state contention is evaluated on a slot-by-slot basis.\nSo for example, suppose that transaction 1 involves Alice sending USDC to Bob, and transaction\n2 involves Charlie sending USDC to David. It doesn’t matter that both transactions involve the\nsame smart contract (the USDC ERC-20 contract); the two affected storage slots in transaction\n1 are completely independent from the two affected storage slots in transaction 2.\nWhat specific optimizations does MonadDB introduce over traditional databases for EVM state storage?\nMonadDb stores Merkle Patricia Trie data natively, rather than embedding the trie inside a\ngeneric database (like LevelDB or RocksDB) which have their own logic for mapping database\nentries to locations on disk. This eliminates a level of indirection and substantially reduces\nthe number of IOPS and page reads to look up one value. Trie operations such as recomputing the\nmerkle root at the end of each block are much more efficient. MonadDb further reduces latency and increases throughput by implementing asynchronous I/O using\nio_uring and by bypassing the filesystem. io_uring is a new linux kernel technology that\nallows execution threads to issue I/O requests without stalling or tieing up threads. This allows\nmany I/O requests to be issued in parallel, sequenced by the kernel, and serviced by the first\navailable thread on return. Finally, in MonadDb, each node in the trie is versioned, allowing for intuitive maintenance of\nthe merkle trie and efficient state synchronization algorithms. Only the necessary trie\ncomponents are sent during statesync, making bootstrapping and recovery faster.\nWhy doesn't Monad make EIP-2930 access lists mandatory? Wouldn’t it make execution more efficient?\n-\nUsage of access lists generally increases the size of transactions; long-term we think that\nbandwidth is the biggest bottleneck\n-\nIn Ethereum, the workflow for a user to submit using access lists is: simulate the\ntransaction, note which storage slots are accessed, then submit the transaction with these\nslots mentioned in the access list. However, the state of the world may change between\nsimulation and the real execution; we feel that it’s the job of the system to handle this\ngracefully under the hood.\n-\nIt would break integrations with existing wallets which don’t support EIP-2930.\n-\nNote that EIP-2930 access lists are actually underspecified, at least from the perspective\nof anticipating state contention. If two transactions both read from the same storage slot\n(but neither writes to it) then, with respect to that storage slot, there is no state\ncontention - neither transaction can invalidate the other’s computation. Contention only\noccurs when an earlier transaction writes to a storage slot that a later transaction will\nread. EIP-2930 access lists mention which storage slots are accessed, but don’t make note\nof whether the transaction will read from or write to that storage slot.\nConsensus\nHow are leaders selected?\nThe leader schedule is constructed by a deterministic, stake-weighted process that is computed\nonce per epoch:\n- An epoch occurs roughly every 4 hours 12 minutes (50,000 blocks). Validator stake weights are locked in\none epoch ahead (i.e. any changes for epoch N+1 must be registered prior to the start of epoch N).\n- At the start of each epoch, each validator computes the leader schedule based on running a\ndeterministic pseudorandom function on the stake weights. Since the function is deterministic,\neveryone arrives at the same leader schedule.\nHow many nodes can participate in consensus? Is participation permissionless?\nThe client codebase has a parameter called ACTIVE_VALSET_SIZE\nwhich is currently set to 200.\nThus, the top 200 validators (ordered by stake weight) can participate directly in consensus.\nThis parameter is likely to change over time. Participation is permissionless; one simply needs to be in the top ACTIVE_VALSET_SIZE\nvalidators.\nRaptorcast\nWhere can I find a detailed description of RaptorCast?\nCheck this blog post!\nWhy was UDP chosen instead of TCP in RaptorCast?\nSee the discussion in this\nblog post. UDP was selected, accepting lossyness but alleviating it by adding additional data\nintegrity (Raptor codes) and message authentication (signatures over merkle roots), because the\ncombination of those strategies over UDP is substantially more efficient than using TCP.\nWhat is the difference between Raptorcast and the propagation methods in Ethereum, Solana, or L2s?\nEthereum is using libp2p . It is gossip based\n(each node propagates its message to a set of peers) which is a lot less efficient (more\nduplicate messages and a more meandering process for getting the word out). As a result,\nEthereum budgets several seconds for the block to propagate throughout the network. Solana uses Turbine .\nTurbine and RaptorCast are similar in the sense that they both use erasure coding, cut packets\ninto MTU-sized chunks, and send transactions through a broadcast tree for efficiency. Some of\nthe differences include:\n- Monad uses Raptor codes while Turbine uses Reed-Solomon\n- Monad uses a 2-level broadcast tree with every other validator as a level-1 node while Solana\nuses a deeper, less structured broadcast tree with fewer level-1 nodes and more complex logic\nfor determining the broadcast tree. There aren’t BFT guarantees on block delivery the way that\nthere are for Monad.\nIn L2s there’s only 1 sequencer so there isn’t a notion of block propagation for consensus.\nThe sequencer just pushes transaction batches occasionally to L1.\nMempool\nIf there is a gap in nonces, will transactions after the gap be preserved in the mempool?\nFor example, if my EOA currently has nonce 0, and I send a transaction with nonce 3, then I\nsend transactions with nonce 0, 1, and 2. Will the transaction with nonce 3 be executed or\ndropped? Answer: Transaction 3 will be executed.\nBlock States and Finality\nWhen can a node start executing a block?\nA node can start executing speculatively\nas soon as a new block proposal is received. Executing a block just generates new states and a\nnew merkle trie root - but the official pointer is still to the old one. This is like receiving\na possible piece of homework from your teacher which will be finalized soon - you can start\nworking on it on a new piece of paper, and just throw it away if it turns out that the homework\nisn’t needed.\nWhen can a node be sure about the state?\nAs soon as a block enters the Finalized state, the\nmerkle root for the speculative execution of that block becomes the official local merkle root\nfor that block. That merkle root won’t be verified by consensus for another D=3 blocks, but\nit is still known locally because state is deterministic given a fixed ordering of transactions. If you want to be certain that your local node did not make a computation error (e.g. due to\ncosmic rays), you may wait D=3 blocks for the delayed merkle root, which makes the block in\nquestion enter the Verified state.\nRPC\nWhen calling eth_call with an old block number, I received this response: Block requested not found. Request might be querying historical state that is not available. If possible, reformulate query to point to more recent blocks . What's going on?\nDue to Monad’s high throughput, full nodes do not provide access to arbitrarily old state,\nas this would require too much storage. See\nHistorical Data for a fuller discussion. When writing smart contracts, it is recommended to use events to log any state that will\nbe needed later, or use a smart contract indexer\nto compute it off-chain.\nFeatures\nIs EIP-7702 supported?\nYes, EIP-7702 is supported. Note that when accounts are delegated under EIP-7702, their treatment under Monad’s\nReserve Balance rules changes slightly.\nYou can learn more about it here .\nIs EIP-7951 (or RIP-7212) supported?\nYes, it is the precompile at 0x0100 following EIP-7951. This enables on-chain verification\nof WebAuthn/passkey signatures using the P256 curve. See\nPrecompiles for\nusage details and a Solidity example.\nMiscellaneous\nWhat is the point of low validator hardware requirements (32 GB RAM, 2x 2TB SSD, 16-core CPU), if there will only be 100-200 voting nodes?\nMonad’s north star is decentralization. If it’s really expensive to run a node, only professional\nvalidation companies with a large amount of stake will be able to justify the cost. Making nodes\neconomical is crucial to making it feasible for anyone to run a full node, as well as to\nsupporting a large validator set - the Day-1 mainnet target of 100-200 nodes is just a starting\npoint.\nWhy was rust chosen for the consensus client and C++ for execution?\nRust and C++ are both great high-performance languages. C++ was selected for the database and\nexecution system to get finer control over the filesystem and to use libraries like io_uring\nand boost::fibers . Rust was selected for consensus to take advantage of stricter memory safety\ngiven that consensus concerns itself with slightly higher-level systems engineering problems.\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.lightning.engineering/community-resources/resource-list","domain":"docs.lightning.engineering","title":"Resource List | Builder's Guide","hash":"71f84d8838c0103140de8b80e1264a77a41179b59d8cc8f35f1cb0076e17d897","tokens":1276,"chars":5103,"crawler":"crawler-f6nn","verified":"exact","ts":1791171910976,"text":"Builder's Guide\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nResource List\nThis section houses example code for those looking to build on lnd. Please let us know if something is missing!\nLightning Nodes\n-\nLND - developed in Go by Lightning Labs\n-\nCore Lightning - developed in C by Blockstream\n-\neclair - developed in Scala by ACINQ\n-\nElectrum - developed in Python by Thomas Voegtlin\n-\nRust Lightning - developed in Rust\n-\nPtarmigan - developed in C++ by Nayuta Core\nWallets\nNon-custodial wallets\n-\nBlixt Wallet ( Github ) - available in Google Play and for iOS\n-\nBreez ( Github ) - available in Google Play and for iOS\n-\nElectrum ( Github ) - available for Linux, OSX, Windows and Android\n-\nMutiny ( Github ) - available for all browsers\n-\nMuun ( Github ) - available on Google Play and the Apple AppStore\n-\nOpen Bitcoin Wallet ( Github ) - available in F-Droid\n-\nPhoenix ( Github ) - available on Google Play and the Apple AppStore\n-\nZebedee ( Github ) - available on Google Play and the Apple AppStore\n-\nZeus ( Github ) - available for Android and the Apple AppStore\nCustodial & Other Wallets\n-\nBitcoin Beach Wallet - available in Google Play\n-\nBridge Wallet - Available on Google Play and on the App Store\n-\nStrike - available in Google Play, the Apple AppStore and Chrome\n-\nWallet of Satoshi - available in Google Play and the Apple AppStore\n-\nBottlepay - available in Google Play and the Apple AppStore\n-\nAlby ( Github ) - connect various wallet interfaces to this browser extension for web-native payments. And login with lightning. Available for Firefox, Chrome, Brave and others\nLightning node interfaces\n-\nZeus - available in Google Play, F-Droid and the Apple AppStore\n-\nRide the Lightning - runs on your personal computer, accessible through your browser\nExplorers\n-\n1ML - Lightning network and node statistics\n-\nAmboss - Detailed information on channels and fee rates\n-\nCheese Robot - Telegram bot with Lightning Network explorer capabilities\n-\nLightning Terminal - Evaluating channels and peers\n-\nLNnodeinsight - Analytics from the perspective of your own node\n-\nVR Explorer - the Lightning Network... in VR!\nApplications\n-\nBoltwall - paywall and authentication using LSATs built with Node.js and Typescript\n-\nLightning Faucet - opens a payment channel with the target user\n-\nLightning Terminal - a browser-based interface for managing channel liquidity\n-\nLNBig Server - lnbig autopilot and rebalancing engin e\n-\nRide the Lightning - node management via Node.js\n-\nShockwallet - decentralized social network enabled by GUN db and lnd\n-\nSphinx Relay - e2e encrypted group chat enabled by a Node.js wrapper around lnd\n-\nThunderhub - node management via a NextJS server handling a backend Graphql server and frontend React App\n-\nTLV shop - webshop with no browser, shopping cart, checkout page, nor credit card required\n-\nsms4sats - send text messages and receive sms for online services on the web and via API\n-\nlightsats - Onboard newbies with lightning tips\n-\nLNURL Auth For WordPress - Login to WordPress with Bitcoin Lightning\nSoftware bundles that include Lightning\n-\nmyNode\n-\nRaspiBlitz\n-\nUmbrel\n-\nStart9\nDeveloper Libraries & Tools\n-\nBalance of Satoshis - Command line tool for working with lnd balances\n-\nChantools - Helper functions that can be used to rescue funds locked in lnd\n-\nln-service - Node.js REST interface to lnd\n-\nLNbits - Simple Python server that provides an account system, extension framework, and more on top of lnd\n-\nlndhub - Wrapper for lnd that provides separate accounts for users sharing a node\n-\nlsat-js - A javascript library for working with L402s\n-\nPolar - One-click Bitcoin Lightning networks for local app development and testing\n-\nWebLN - A library for secure communication between Lightning apps and user nodes\n-\nrebalance-lnd Python script for circular rebalancing in LND\n-\nFaraday - A suite of tools built to help node operators and businesses run lnd, the leading implementation of the Lightning Network\nWikis, Guides & Resources\n-\nAlby's WebLN Guide\n-\nBen Congdon's Awesome Lightning Network\n-\nElectric Capital's Lightning Ecosystem Repository\n-\nJameson Lopp's Lightning Network Resources\n-\nLearnBitcoin's Lightning Routing explainer - how pathfinding, onion routing, and multi-part payments work, with diagrams\n-\nopennoms Lightning Node Management book\nPayment processors\n-\nBitfinex Pay\n-\nCoingate\n-\nOpenNode\n-\nBTCPayServer\n-\nLNBits\n-\nVoltage - Lightning Network node hosting platform\nExchanges & Brokerages\n-\nAzteco\n-\nBinance\n-\nBipa\n-\nBitaroo\n-\nBitfinex\n-\nBoltz\n-\nCoinbase\n-\nCoincorner\n-\nFixedFloat\n-\nKraken\n-\nLNMarkets\n-\nLOFT\n-\nMt Pelerin\n-\nNiceHash\n-\nOKX\n-\nRiver Financial\n-\nStrike\n-\nSouthxchange\n-\nVBTC\nPrevious Skills\nNext Lightning Bulb 💡\nLast updated 22 days ago\nWas this helpful?\n- Lightning Nodes\n- Wallets\n- Non-custodial wallets\n- Custodial & Other Wallets\n- Lightning node interfaces\n- Explorers\n- Applications\n- Software bundles that include Lightning\n- Developer Libraries & Tools\n- Wikis, Guides & Resources\n- Payment processors\n- Exchanges & Brokerages\nWas this helpful?"}
{"url":"https://docs.phantom.com/llms.txt","domain":"docs.phantom.com","title":"Phantom Developer Documentation","hash":"755d5c374097527326c2fb3930c2aac4b9a9b172f2b2a013e90f2fdb0f67c5df","tokens":4544,"chars":18174,"crawler":"crawler-f6nn","verified":"exact","ts":1791171913654,"text":"# Phantom Developer Documentation\n> Phantom is a leading crypto wallet for Solana, Ethereum, Bitcoin, Base, and Polygon. Monad and Sui support have been deprecated. This documentation covers two main integration paths: the Phantom MCP server (giving AI agents a wallet) and Phantom Connect SDKs (building apps with embedded wallets and social login).\n## Getting Started\nStart here to understand what Phantom offers and choose the right integration path.\n- [Build with Phantom](https://docs.phantom.com/introduction): Overview of Phantom developer tools — routes to either the MCP server (AI agents) or Connect SDKs (app users)\n- [Phantom Connect](https://docs.phantom.com/phantom-connect): Onboard users with embedded wallets using Google or Apple social login, or connect existing Phantom extension wallets\n- [SDK Overview](https://docs.phantom.com/wallet-sdks-overview): Compare React, React Native, and Browser SDKs — includes feature matrix and platform guidance\n## Phantom MCP server\nThe Phantom MCP server (`@phantom/mcp-server`) gives AI agents a Phantom wallet. Agents can sign transactions, transfer tokens, swap with no fees, and interact on-chain across Solana, Ethereum, Bitcoin, and Sui. Monad and Sui support have been deprecated. It's a Phantom wallet product for users who interact through AI agents. Phantom does not charge transaction fees, platform fees, or commission on swaps.\n- [Phantom MCP Server Overview](https://docs.phantom.com/phantom-mcp-server): What the MCP server is, quick install, available tools, and supported clients (Claude Desktop, Cursor, Claude Code)\n- [Setup and Reference](https://docs.phantom.com/phantom-mcp-server/setup): Full installation guide, prerequisites (Phantom Portal App ID), environment variables, all 25 tools with parameters, supported networks, session management, and troubleshooting\n## Quickstarts\nStep-by-step guides to get a working Phantom Connect integration running in minutes.\n- [Next.js Quickstart](https://docs.phantom.com/recipes/quickstarts/nextjs): Full setup guide for Next.js App Router including provider config, auth callback, and portal setup\n- [React (Vite) Quickstart](https://docs.phantom.com/recipes/quickstarts/react): Full setup guide for React with Vite including provider config and routing\n- [Vanilla JavaScript Quickstart](https://docs.phantom.com/recipes/quickstarts/vanilla-js): Plain JavaScript integration using the Browser SDK with event listeners and callbacks\n- [React Native Quickstart](https://docs.phantom.com/recipes/quickstarts/react-native): Mobile app setup including dependencies, app scheme, polyfills, and wallet screen\n## Recipes\nCopy-paste code examples for the most common Phantom Connect integration patterns.\n### Authentication\n- [Social Login (Google, Apple)](https://docs.phantom.com/recipes/auth/social-login): Let users sign in with Google or Apple and automatically receive an embedded wallet — includes React, Browser SDK, and React Native examples\n- [Browser Extension Login](https://docs.phantom.com/recipes/auth/extension-login): Connect to existing Phantom browser extension wallets with fallback handling\n- [Session Management](https://docs.phantom.com/recipes/auth/session-management): Persist wallet connections across page reloads using the SDK's automatic session persistence\n- [Sign-in with Solana (SIWS)](https://docs.phantom.com/recipes/auth/sign-in-with-solana): Wallet-based authentication — user signs a message, backend verifies the signature to prove ownership\n### Payments\n- [Send SOL](https://docs.phantom.com/recipes/payments/send-sol): Transfer native SOL tokens using SystemProgram transfer instruction\n- [Send USDC](https://docs.phantom.com/recipes/payments/send-usdc): Transfer USDC stablecoin payments with automatic recipient token account creation\n- [Send any SPL Token](https://docs.phantom.com/recipes/payments/send-spl-token): Transfer any SPL token by mint address and decimals, including token account creation\n- [Request Payment](https://docs.phantom.com/recipes/payments/request-payment): Generate payment request links and QR codes using the Solana Pay standard\n### Signatures\n- [Sign a Message](https://docs.phantom.com/recipes/signatures/sign-message): Request a signature from the connected wallet for authentication or verification\n- [Verify a Signature](https://docs.phantom.com/recipes/signatures/verify-signature): Server-side signature verification using tweetnacl and bs58 to prove wallet ownership\n- [Sign Typed Data (EIP-712)](https://docs.phantom.com/recipes/signatures/sign-typed-data): Sign structured, human-readable data on Ethereum/EVM chains\n### Wallet Operations\n- [Check Wallet Balance](https://docs.phantom.com/recipes/wallet-operations/check-balance): Fetch SOL and SPL token balances for a connected wallet using the Solana Connection API\n- [Get All Token Accounts](https://docs.phantom.com/recipes/wallet-operations/get-token-accounts): List all SPL token accounts and balances for a wallet to display a portfolio\n### Transactions\n- [Add Priority Fees](https://docs.phantom.com/recipes/transactions/add-priority-fees): Add ComputeBudgetProgram instructions for faster confirmation during network congestion\n- [Check Transaction Status](https://docs.phantom.com/recipes/transactions/check-transaction-status): Poll and monitor transaction confirmation status (pending, confirmed, finalized)\n## Phantom Connect SDKs\nBuild wallet-connected apps with React, React Native, or framework-agnostic JavaScript. All SDKs support social login (Google, Apple), browser extension connection, and multi-chain operations.\n### React SDK\n- [React SDK](https://docs.phantom.com/sdks/react-sdk): Install `@phantom/react-sdk`, wrap your app in `PhantomProvider`, and use hooks like `useConnect`, `useAccounts`, `useSolana`, and `useEthereum`\n- [Connect](https://docs.phantom.com/sdks/react-sdk/connect): Wallet connection methods — Google, Apple, and extension providers with `useConnect` hook\n- [Sign Messages](https://docs.phantom.com/sdks/react-sdk/sign-messages): Message signing for authentication using `useSolana` and `useEthereum` hooks\n- [Sign and Send Transactions](https://docs.phantom.com/sdks/react-sdk/sign-and-send-transaction): Transaction signing and broadcasting with chain-specific hooks\n### React Native SDK\n- [React Native SDK](https://docs.phantom.com/sdks/react-native-sdk): Install `@phantom/react-native-sdk` with Expo dependencies, configure app scheme, and add required polyfills\n- [Connect](https://docs.phantom.com/sdks/react-native-sdk/connect): Mobile wallet connection with OAuth providers and connection modal UI\n- [Sign Messages](https://docs.phantom.com/sdks/react-native-sdk/sign-messages): Message signing on mobile with hardware-backed key security\n- [Sign and Send Transactions](https://docs.phantom.com/sdks/react-native-sdk/sign-and-send-transaction): Mobile transaction handling with system browser authentication\n### Browser SDK\n- [Browser SDK](https://docs.phantom.com/sdks/browser-sdk): Install `@phantom/browser-sdk` and use `createPhantom()` for framework-agnostic wallet integration\n- [Connect](https://docs.phantom.com/sdks/browser-sdk/connect): Browser-based wallet connection with `phantom.connect({ provider })` for Google, Apple, or the Phantom browser extension (injected)\n- [Sign Messages](https://docs.phantom.com/sdks/browser-sdk/sign-messages): Message signing via `phantom.solana.signMessage()` and `phantom.ethereum.signPersonalMessage()`\n- [Sign and Send Transactions](https://docs.phantom.com/sdks/browser-sdk/sign-and-send-transaction): Transaction handling with `phantom.solana.signAndSendTransaction()` and `phantom.ethereum.sendTransaction()`\n### Guides\n- [Wallet Authentication with JWTs](https://docs.phantom.com/sdks/guides/wallet-authentication-with-jwts): Implement custom JWT-based authentication using wallet signatures for backend verification\n## Phantom Portal\nSelf-service dashboard for registering your app, configuring allowed origins, and managing branding within 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.\n- [Portal Overview](https://docs.phantom.com/phantom-portal/portal): Dashboard for app configuration, branding, access modes (DISABLED, PRIVATE, PUBLIC), and domain verification\n- [Get Started](https://docs.phantom.com/phantom-portal/getting-started): Six-step setup guide for an existing app, from sign-in through App ID retrieval\n- [Sign in to Your Account](https://docs.phantom.com/phantom-portal/create-account): Sign in to an existing account with Google or Apple\n- [Open Your App](https://docs.phantom.com/phantom-portal/create-app): Open an existing application and review its details\n- [Verify Your Domain](https://docs.phantom.com/phantom-portal/verify-domain): DNS-based domain verification required for public listing in Phantom\n- [Configure URLs](https://docs.phantom.com/phantom-portal/configure-urls): Set allowed origins and redirect URLs for your SDK integration\n- [Add App Information](https://docs.phantom.com/phantom-portal/edit-app-info): Configure icon, cover image, description, and branding metadata\n- [Get Your App ID](https://docs.phantom.com/phantom-portal/get-app-id): Obtain the `appId` credential required by all Phantom Connect SDKs\n## Browser Extension — Solana\nIntegrate directly with the Phantom browser extension for Solana using the injected `window.phantom.solana` provider.\n- [Get Started with Solana](https://docs.phantom.com/solana/integrating-phantom): Solana integration overview and architecture\n- [Detect the Provider](https://docs.phantom.com/solana/detecting-the-provider): Check if Phantom is installed via `window.phantom?.solana?.isPhantom`\n- [Establish a Connection](https://docs.phantom.com/solana/establishing-a-connection): Call `provider.connect()` to request the user's public key\n- [Send a Legacy Transaction](https://docs.phantom.com/solana/sending-a-transaction): Build and send transactions using `@solana/web3.js` Transaction class\n- [Send a Versioned Transaction](https://docs.phantom.com/solana/sending-a-transaction-1): Versioned transactions with Address Lookup Tables for larger account sets\n- [Sign a Message](https://docs.phantom.com/solana/signing-a-message): Arbitrary message signing for authentication and verification\n- [Error Messages and Codes](https://docs.phantom.com/solana/errors): Solana error codes reference (4001, 4100, etc.)\n## Browser extension — EVM networks\nIntegrate with Phantom on EVM networks using the EIP-1193 standard provider at `window.phantom.ethereum`. This guide covers Ethereum, Base, Polygon, Robinhood Chain, and Arc. Robinhood Chain uses chain ID `4663` (`0x1237`) on mainnet and `46630` (`0xb626`) on testnet. Arc uses chain ID `5042` (`0x13b2`) on mainnet and `5042002` (`0x4cef52`) on testnet. Testnet Mode is required for testnets. Monad support has been deprecated.\n- [Get Started with EVM](https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/getting-started): EVM integration overview, network IDs covered by the guide, and Monad deprecation guidance\n- [Detect the Provider](https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/detecting-the-provider): Check for Phantom via `window.phantom?.ethereum?.isPhantom`\n- [Establish a Connection](https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/establishing-a-connection): Request accounts via `eth_requestAccounts` RPC method\n- [Send a Transaction](https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/sending-a-transaction): Send EVM transactions via `eth_sendTransaction`\n- [Sign a Message](https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/signing-a-message): EVM message signing with `personal_sign`\n- [Provider API Reference](https://docs.phantom.com/ethereum-monad-testnet-base-and-polygon/provider-api-reference): Complete EVM provider API — properties, events, methods, and error codes\n## Browser Extension — Bitcoin (deprecated)\nThe `window.phantom.bitcoin` injected provider has been deprecated.\n- [Get Started with Bitcoin](https://docs.phantom.com/bitcoin/integrating-phantom): Bitcoin integration overview\n- [Detect the Provider](https://docs.phantom.com/bitcoin/detecting-the-provider): Check for Phantom via `window.phantom?.bitcoin?.isPhantom`\n- [Establish a Connection](https://docs.phantom.com/bitcoin/establishing-a-connection): Call `provider.requestAccounts()` for Bitcoin address\n- [Send a Transaction](https://docs.phantom.com/bitcoin/sending-a-transaction): Bitcoin transaction construction and sending\n- [Sign a Message](https://docs.phantom.com/bitcoin/signing-a-message): Bitcoin message signing\n- [Provider API Reference](https://docs.phantom.com/bitcoin/provider-api-reference): Complete Bitcoin provider API reference\n## Browser Extension — Sui (deprecated)\nSui support through `window.phantom.sui` has been deprecated.\n- [Get Started with Sui](https://docs.phantom.com/sui/getting-started-with-sui): Sui deprecation notice\n- [Detect the Provider](https://docs.phantom.com/sui/detecting-the-provider): Check for Phantom via `window.phantom?.sui?.isPhantom`\n- [Establish a Connection](https://docs.phantom.com/sui/establishing-a-connection): Connect to Sui wallet\n- [Send a Transaction](https://docs.phantom.com/sui/sending-a-transaction): Sui transaction handling\n- [Sign a Message](https://docs.phantom.com/sui/signing-a-message): Sui message signing\n## Mobile Deep Links\niOS and Android native apps can interact with Phantom through universal links (`https://phantom.com/ul/v1/`). Currently Solana only.\n- [Deep Links Overview](https://docs.phantom.com/phantom-deeplinks/deeplinks-ios-and-android): Protocol format, supported methods, and universal link vs custom scheme comparison\n- [Handle Sessions](https://docs.phantom.com/phantom-deeplinks/handling-sessions): Session structure, validation with base58 and cryptographic signatures\n- [Specifying Redirects](https://docs.phantom.com/phantom-deeplinks/specifying-redirects): HTTPS URL redirects vs custom scheme URIs for redirect_link parameters\n- [Encryption](https://docs.phantom.com/phantom-deeplinks/encryption): Symmetric key encryption and Diffie-Hellman key exchange for secure communications\n- [Limitations](https://docs.phantom.com/phantom-deeplinks/limitations): Android 500KB limit, iOS 1MB limit\n## Developer Tools\nAI tools, testing, and debugging resources for building with Phantom.\n- [AI-Assisted Development](https://docs.phantom.com/developer-powertools/ai-tools): Use Phantom's MCP servers and Cursor AI prompts to generate production-ready SDK code\n- [Phantom MCP Server Setup](https://docs.phantom.com/phantom-mcp-server/setup): MCP server that gives AI agents direct access to Phantom wallet operations (sign transactions, transfer tokens, view addresses)\n- [Phantom Connect SDK MCP Server](https://docs.phantom.com/resources/mcp-server): Model Context Protocol server for AI coding assistants — search Phantom docs from Cursor, Claude Code, or VS Code\n- [Cursor AI Prompts](https://docs.phantom.com/resources/cursor-prompts): One-shot prompts for generating React, React Native, and Browser SDK implementations\n- [Testnet Mode](https://docs.phantom.com/developer-powertools/testnet-mode): Access supported test networks, including Solana devnet/testnet, Ethereum Sepolia, Polygon Amoy, Base Sepolia, Robinhood Chain Testnet, and Arc Testnet\n- [Mobile Web Debugging](https://docs.phantom.com/developer-powertools/mobile-web-debugging): Debug mobile web dapps using Safari (iOS) and Chrome (Android)\n- [Wallet Standard](https://docs.phantom.com/developer-powertools/wallet-standard): Chain-agnostic Wallet Standard interface integration for Solana dapps\n## Security and Advanced Features\n- [Domain and Transaction Warnings](https://docs.phantom.com/developer-powertools/domain-and-transaction-warnings): Understanding new domain warnings, app identity verification warnings, transaction simulation warnings, and how to resolve them\n- [Transaction Validation](https://docs.phantom.com/developer-powertools/lighthouse): Lighthouse assertion instructions for runtime transaction validation\n- [Sign-In-With Standards](https://docs.phantom.com/developer-powertools/sign-in-with-standards): SIWS (Solana), SIWE (EIP-4361), and SIWx (CAIP-122) authentication standards\n- [Solana Priority Fees](https://docs.phantom.com/developer-powertools/solana-priority-fees): How Phantom auto-calculates priority fees based on compute units and congestion\n- [Solana Versioned Transactions](https://docs.phantom.com/developer-powertools/solana-versioned-transactions): Address Lookup Tables enabling up to 256 accounts per transaction\n- [Solana Token Extensions (Token22)](https://docs.phantom.com/developer-powertools/solana-token-extensions-token22): Token-2022 program support for interest-bearing, transfer fees, and metadata extensions\n## Best Practices\n- [Go-Live Checklist](https://docs.phantom.com/best-practices/go-live-checklist): Pre-launch verification covering Portal setup, integration testing, and security checks\n- [Display Apps in Dialogs](https://docs.phantom.com/best-practices/display-apps-within-dialogs): How Phantom reads Open Graph tags and favicon for dialog branding\n- [Token Display](https://docs.phantom.com/best-practices/tokens): Token metadata, verification, and display for fungibles, NFTs, and semi-fungibles\n## Resources\n- [FAQ](https://docs.phantom.com/resources/faq): Common questions about Phantom Connect, embedded vs extension wallets, SDK selection, and Robinhood Chain and Arc support through the traditional EVM provider\n- [Demo Apps](https://docs.phantom.com/resources/sandbox): Multi-chain sandbox on CodeSandbox, Solana-only sandbox, and React Native deep link demo\n- [Logos and Assets](https://docs.phantom.com/resources/logos-and-assets): Phantom brand assets for your integration\n## Optional\n- [Updates](https://docs.phantom.com/updates): Changelog and release notes\n- [User Limits](https://docs.phantom.com/user-limits): Access modes (PRIVATE, PUBLIC, DISABLED) and team member limits"}
{"url":"https://docs.getmonero.org/multisignature/","domain":"docs.getmonero.org","title":"Multisignature - Monero Docs","hash":"9e8e0c332153f83821981f0cde2a3af003d7ed0201d9a18fd07b29b6a65c05b5","tokens":5590,"chars":22357,"crawler":"crawler-f6nn","verified":"exact","ts":1791171916562,"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.marinade.finance/partnerships/marinade-press-kit","domain":"docs.marinade.finance","title":"Marinade Press Kit | Marinade Documentation","hash":"e8c9df1783916ed9870e2e9b5adfd3bb3a55f7f7031adb36d289382cd7f1fb59","tokens":235,"chars":939,"crawler":"crawler-f6nn","verified":"exact","ts":1791171919621,"text":"Marinade Documentation\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nMarinade Press Kit\nPlease find official Marinade imagery below for your use. For additional info or media inquiries, contact [email protected]\nMarinade Logos\nMarinade logo.zip\narchive · 389KB\nOpen\nToken Logos\nMNDE and mSOL icons.zip\narchive · 93KB\nOpen\nFonts\nHere are the main fonts used on Marinade:\nFonts.zip\narchive · 3MB\nOpen\nIllustrations\nIllustrations.zip\narchive · 2MB\nOpen\nView real-time statistics about Marinade\nView Marinade's DAO treasury and votes on Realms .\nYou can use this dashboard to get real-time data on Marinade.\nDownload Our Brand Book\nMarinade Brand Book.pdf\nPDF · 22MB\nOpen\nPrevious Become our Partner\nLast updated 6 months ago\nWas this helpful?\n- Marinade Logos\n- Token Logos\n- Fonts\n- Illustrations\n- View real-time statistics about Marinade\n- Download Our Brand Book\nWas this helpful?"}
{"url":"https://docs.sui.io/getting-started/onboarding/","domain":"docs.sui.io","title":"Hello, World!","hash":"f4e932a8cb34758dd27c127782ba66b2265116d80ada790c04139cb1faf17ba3","tokens":135,"chars":539,"crawler":"crawler-f6nn","verified":"exact","ts":1791171921714,"text":"# Hello, World!\n*[Documentation index](/llms.txt) · [Full index](/llms-full.txt)*\nGet started with Sui, the first internet-scale programmable blockchain platform.\n- [Install Sui](/getting-started/onboarding/sui-install)\n- [Configure a Sui Client](/getting-started/onboarding/configure-sui-client)\n- [Create a Sui Address](/getting-started/onboarding/get-address)\n- [Get SUI from Faucet](/getting-started/onboarding/get-coins)\n- [Hello, World!](/getting-started/onboarding/hello-world)\n- [Next Steps](/getting-started/onboarding/next-steps)"}
{"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":"crawler-f6nn","verified":"exact","ts":1791171925496,"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.polkadot.com/reference/","domain":"docs.polkadot.com","title":"Technical Reference Overview | Polkadot Developer Docs","hash":"53606bf44da8847456e76c15d1de3f1282d1b9e23eafa1c10291bbfcd7c724b9","tokens":1845,"chars":7378,"crawler":"crawler-f6nn","verified":"exact","ts":1791171927957,"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- Polkadot Hub\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\nOverview\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nIntroduction ¶\nThe Technical Reference section provides comprehensive documentation of Polkadot's architecture, core concepts, and development tooling. Whether you're exploring how Polkadot's relay chain coordinates parachains, understanding governance mechanisms, or building applications on the network, this reference covers the technical foundations you need.\nPolkadot is a multi-chain network that enables diverse, interconnected blockchains to share security and communicate seamlessly. Understanding how these components interact from the Relay Chain that validates parachains to the Governance mechanisms that evolve the protocol is essential for developers, validators, and network participants.\nThis guide organizes technical documentation across five core areas: Polkadot Hub , Parachains, On-Chain Governance, Glossary, and Tools, each providing detailed information on different aspects of the Polkadot ecosystem.\nPolkadot Hub ¶\nPolkadot Hub is the entry point to Polkadot for all users and application developers. It provides access to essential Web3 services including smart contracts, asset management, staking, governance, identity management, and cross-ecosystem interoperability—without requiring you to deploy or manage a parachain.\nThe Hub encompasses a set of core functionality that enables developers and users to build and interact with applications on Polkadot. Key capabilities include:\n- Smart contracts : Deploy Ethereum-compatible smart contracts and build decentralized applications.\n- Asset management : Create, manage, and transfer fungible tokens and NFTs across the ecosystem.\n- Staking : Participate in network security and earn rewards by staking DOT.\n- Governance : Vote on proposals and participate in Polkadot's decentralized decision-making through OpenGov.\n- Identity services : Register and manage on-chain identities, enabling access to governance roles and network opportunities.\n- Cross-chain interoperability : Leverage XCM messaging to interact securely with other chains in the Polkadot ecosystem.\n- Collectives and DAOs : Participate in governance collectives and decentralized autonomous organizations.\nParachains ¶\nParachains are specialized blockchains that connect to the Polkadot relay chain, inheriting its security while maintaining their own application-specific logic. The parachains documentation covers:\n- Accounts : Deep dive into account types, storage, and management on parachains.\n- Blocks, transactions and fees : Understand block production, transaction inclusion, and fee mechanisms.\n- Consensus : Learn how parachain blocks are validated and finalized through the relay chain's consensus.\n- Chain data : Explore data structures, storage layouts, and state management.\n- Cryptography : Study cryptographic primitives used in Polkadot SDK-based chains.\n- Data encoding : Understand how data is encoded and decoded for blockchain compatibility.\n- Networks : Learn about networking protocols and peer-to-peer communication.\n- Interoperability : Discover Cross-Consensus Messaging (XCM) , the standard for cross-chain communication.\n- Randomness : Understand how randomness is generated and used in Polkadot chains.\n- Node and runtime : Learn about parachain nodes, runtime environments, and the Polkadot SDK .\nOn-Chain Governance ¶\nOn-Chain governance is the decentralized decision-making mechanism for the Polkadot network. It manages the evolution and modification of the network's runtime logic, enabling community oversight and approval for proposed changes. The governance documentation details:\n- OpenGov framework : Understand Polkadot's next-generation governance system with enhanced delegation, flexible tracks, and simultaneous referendums.\n- Origins and tracks : Learn how governance proposals are categorized, prioritized, and executed based on their privilege level and complexity.\n- Voting and delegation : Explore conviction voting, vote delegation, and how token holders participate in governance.\n- Governance evolution : See how Polkadot's governance has evolved from Governance V1 to the current OpenGov system.\nGlossary ¶\nThe Glossary provides quick-reference definitions for Polkadot-specific terminology. Essential terms include:\n- Blockchain concepts (blocks, transactions, state)\n- Consensus mechanisms (validators, collators, finality)\n- Polkadot-specific terms (relay chain, parachain, XCM, FRAME)\n- Network components (nodes, runtimes, storage)\n- Governance terminology (origins, tracks, referendums)\nTools ¶\nThe Tools section documents essential development and interaction tools for the Polkadot ecosystem:\n- Light clients : Lightweight solutions for interacting with the network without running full nodes.\n- JavaScript/TypeScript tools : Libraries like Polkadot.js API and PAPI for building applications.\n- Rust tools : Polkadart and other Rust-based libraries for SDK development.\n- Python tools : py-substrate-interface for Python developers.\n- Testing and development : Tools like Moonwall , Chopsticks , and Omninode for smart contract and parachain testing.\n- Indexing and monitoring : Sidecar for data indexing and Dedot for substrate interaction.\n- Cross-chain tools : ParaSpell for XCM integration and asset transfers.\nWhere to Go Next ¶\nFor detailed exploration of specific areas, proceed to any of the main sections:\n-\nLearn Polkadot Hub\nUnderstand the relay chain's role in coordinating parachains, providing shared security, and enabling governance.\nReference\n-\nLearn Parachains\nDeep dive into parachain architecture, consensus, data structures, and building application-specific blockchains.\nReference\n-\nLearn On-Chain Governance\nExplore Polkadot's decentralized governance framework and how to participate in network decision-making.\nReference\n-\nGuide Glossary\nQuick reference for Polkadot-specific terminology and concepts used throughout the documentation.\nReference\n-\nGuide Tools\nDiscover development tools, libraries, and frameworks for building and interacting with Polkadot.\nReference\nLast update: June 29, 2026\n| Created: January 14, 2026"}
{"url":"https://docs.openzeppelin.com/symbiotic","domain":"docs.openzeppelin.com","title":"Symbiotic Templates | OpenZeppelin Docs","hash":"d9d27fb9d325c9178365fb969ef2d03b1fe530207c6a48560aa9b81f6986d558","tokens":268,"chars":1072,"crawler":"crawler-f6nn","verified":"exact","ts":1791171930369,"text":"Home Forum Website Impact\nSymbiotic Templates\nOpen in Claude\nFor Operators\nRunning, configuring, and monitoring the stack.\n- Setup -- Config structure, environment setup, running locally\n- Deployment -- Testnet deployment\n- Choose your provider:\n- LayerZero -- DVN for LayerZero V2\n- Chainlink CCV -- Cross-Chain Verifier for CCIP\n- Acceptance Hooks -- Native and webhook policy checks before batching\n- CLI & API Reference -- Commands, HTTP endpoints, webhook config\n- Troubleshooting -- Common issues and debugging\nFor Integrators\nUnderstanding the system and adding new providers.\n- Architecture -- Provider model, shared infra, Merkle batching, BLS signing\n- Choose your provider:\n- LayerZero -- Message flow, contracts, code pointers\n- Chainlink CCV -- Message flow, contracts, code pointers\n- Acceptance Hooks -- Hook contract and webhook wire format\n- Architecture: Adding a New Provider -- Provider trait, registration, templates\n- Security -- Trust model, access control, invariants\nStorage\nPrevious Page\nSetup\nNext Page\nOn this page\nFor Operators For Integrators"}
{"url":"https://docs.berachain.com/general/proof-of-liquidity/incentives","domain":"docs.berachain.com","title":"Incentive Marketplace - Berachain","hash":"43ef3ee3c25f457e4080193d85a4c78636ce8f0daaf7f7889db24149a1f4cd2d","tokens":1057,"chars":4226,"crawler":"crawler-f6nn","verified":"exact","ts":1791171933081,"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\nIncentive Marketplace\nHow businesses and protocols bid for validator-allocated WBERA emissions.\nProof of Liquidity lets businesses and protocols bid for validator reward allocation by attaching incentive tokens to whitelisted Reward Vaults. Validators allocate $WBERA emissions to those vaults and earn incentive commission when their allocation captures funded incentives.\nThis page covers the market-based path for routing emissions through validator allocation. Dedicated Emission Streams are a separate routing path for selected businesses that receive predictable emissions outside the standard validator-allocation market.\nHow incentives work\n- Validators stake $BERA to enter the active set; the more BERA staked, the greater probability to produce a block\n- When validators produce blocks, BeraChef applies their reward allocation to route $WBERA to whitelisted vaults.\n- Businesses and protocols fund Reward Vault incentives to attract validator allocation..\n- Incentives split into two paths: validator commission and incentives redirected to $sWBERA. Validator commission is paid to the validator operator. Redirected incentives are settled through the Incentive Auction, converted into $BERA / $WBERA yield, and accrued into $sWBERA.\nIncentive distribution roles\nParticipant Role\nProtocol Funds incentive tokens to attract validator reward allocation.\nValidator Allocates Reward Vault emission and earns commission on incentive tokens.\nBERA staker Stakes $BERA with validators, increasing block-production probability.\n$sWBERA staker Earns WBERA yield from the Incentive Auction through $sWBERA.\nLST staker Earns WBERA yield when their LST has a registered staker vault.\nVault staker Stakes receipt tokens and earns allocated WBERA emissions from the vault.\nIncentive token lifecycle\nWhitelisting\nReward Vaults can whitelist up to two incentive tokens through governance.\nToken managers\nEach whitelisted incentive token has a token manager that funds incentives and manages rates under governance constraints.\nIncentive rate\nIncentives use an exchange rate per unit of allocated emission:\nincentiveTokens = emissionAllocatedToVault * incentiveRate\nRates can increase when the token manager deposits more inventory. Decreasing rates is restricted until existing inventory is exhausted.\nCommission and payouts\nValidator commission is capped at 20% . Reward Vault incentive processing sends the validator commission to the validator operator and sends the remaining incentive tokens to IncentivesCollector .\nIncentive fee settlement\nThe redirected incentive share collects in IncentivesCollector , the shared settlement path for Reward Vault incentives. Incentive tokens accumulate in the collector,\nand WBERA paid into settlement becomes yield for $sWBERA stakers and registered LST stakers.\nSee Deployed contract addresses for the current IncentivesCollector address.\nSettlement behavior\nSettlement is a fixed-price exchange against the collector: a buyer pays WBERA into the incentive collector, receives the selected incentive tokens held by the collector, and the paid WBERA is split pro-rata (by WBERA-denominated total assets) between the $sWBERA staking vault and registered LSTStakerVault s. Registered LST vaults receive yield through their LST adapter ( receiveRewards ).\nLST integration: issuers deploy an LSTStakerVault system via LSTStakerVaultFactory , then register the vault and adapter on the collector’s LST registry to join the auction split. See LST Integration for the full integrator workflow.\nIncentive redirection\nAfter validator commission, redirected incentives move through the auction path:\n- Validator commission : paid directly to the validator operator.\n- Incentive Auction : redirected incentive tokens are settled for $WBERA.\n- Yield receivers : auction WBERA becomes yield for $sWBERA stakers and registered LST stakers.\nSee $sWBERA Token for the staking-vault side of this flow.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.layerzero.network/v2/concepts/applications/stargate-finance","domain":"docs.layerzero.network","title":"Stargate Finance - LayerZero","hash":"4d6fe484b469eb18d5ffa3bc8c244a740165ce861449c6cb08496e863404d421","tokens":2745,"chars":10980,"crawler":"crawler-f6nn","verified":"exact","ts":1791171936070,"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\nApplications\nStargate Finance\nStargate is a composable crosschain liquidity protocol built on LayerZero V2 as its transport layer. It provides unified liquidity pools for native…\nLooking for the Stargate docs? Stargate documentation now lives here as part of LayerZero. Stargate is a core application built on LayerZero - read through this page and the Stargate Integration Guide for everything you need.\nStargate is a composable crosschain liquidity protocol built on LayerZero V2 as its transport layer. It provides unified liquidity pools for native assets (USDC, USDT, ETH) across multiple blockchains, enabling seamless asset transfers without fragmenting liquidity.\nStargate uses LayerZero V2 messaging infrastructure to coordinate liquidity between StargatePool contracts on chains with native assets and StargateOFT contracts on emerging chains needing access to deep liquidity, creating a unified network where any protocol can access native assets instead of bootstrapping their own crosschain infrastructure.\nStargate’s Dual Role\nStargate plays two key roles in the LayerZero ecosystem: (1) a set of onchain smart contracts providing deep crosschain liquidity infrastructure, and (2) a unified frontend bridge that routes omnichain transfers for both Stargate assets and all LayerZero Omnichain Fungible Tokens (OFTs) .\n1. Liquidity Protocol (EVM Smart Contracts)\nStargate operates smart contracts that manage coordinated liquidity pools for native assets:\n- StargatePool : Holds native assets (e.g., USDC, ETH) on core chains with deep liquidity\n- StargateOFT : Mints backed representations (e.g., USDC.e) on emerging chains\n- TokenMessaging : Every transfer uses LayerZero messaging, DVNs, and Executors\n- EVM Only : Protocol contracts deployed on EVM chains.\nFor Developers :\n- StargatePool contracts hold native ERC20 tokens (e.g., USDC) or native assets (e.g., ETH) and implement the IOFT interface for crosschain transfers\n- StargateOFT contracts have mint/burn authority on their corresponding ERC20 OFT tokens and implement the IOFT interface\nBoth contract types are drop-in compatible with LayerZero composability and other LayerZero contract standards (e.g., Omnichain Vaults ).\nHow Stargate V2 Works\nStargate V2 uses two types of contracts to represent assets on multiple chains:\nStargatePool (Native Chains)\n- Holds native assets (e.g., USDC, ETH) in credit-allocated liquidity pools\n- Deployed on major chains with existing deep liquidity in specific assets\n- Pools can transfer directly to other pools on native chains or to Hydra chains\nStargateOFT (Hydra Chains)\n- Minted OFT representations backed by pool liquidity\n- Deployed on emerging chains where deep native liquidity doesn’t yet exist\n- Can transfer point-to-point to other Hydra chains or redeem to native pools\nThe Hydra Mechanism\nStargate Hydra connects native liquidity pools with Hydra-enabled chains:\nKey Benefits :\n- Liquidity Extension : Emerging chains get instant access to deep pool liquidity\n- No Bootstrapping : No need to create new liquidity on every chain\n- Full Redeemability : Any Hydra OFT can be redeemed for native pool assets\n- Unified Network : All chains share the same liquidity base\nCredit Allocation System\nStargate uses a credit allocation system to manage liquidity across all Stargate contracts (both StargatePool and StargateOFT) and ensure reliable transfers.\nWhat are Credits?\nCredits track token inflows and outflows in the protocol. Each pathway between chains (LayerZero endpoint IDs ) has allocated credits that determine how much liquidity can move through that route.\nInstant Guaranteed Finality\nThanks to credit allocation, Stargate provides Instant Guaranteed Finality : swaps are settled locally and immediately on the source chain, without risk of revert, rollback, or double spending. While you still wait for LayerZero to deliver tokens on the destination chain, Stargate guarantees the destination transaction will succeed.\nThis is possible because Stargate maintains these invariants:\n- For each pool : Pool balance ≥ local unallocated credits + sum of allocated credits in remote paths\n- For the system : Sum of pool balances ≥ sum of OFT supplies + sum of total values locked\nAI Planning Module (AIPM)\nCredits in Stargate V2 are managed by the AI Planning Module, which conducts automated credit rebalancing via LayerZero messages. The AIPM:\n- Monitors transfer volume across all pathways\n- Dynamically reallocates credits to high-demand routes\n- Ensures optimal capital efficiency\n- Prevents credit shortages on active pathways\nStargate V1 vs V2 : Stargate V1 had static credits on pathways. Stargate V2 has dynamic credits, providing much greater capital efficiency through automated rebalancing.\nCredit Operations\nCredit increases/decreases are coordinated through LayerZero messages between chains using the CreditMessaging contract. All OFTs are backed by pool liquidity through credit guarantees verified by LayerZero DVNs.\nTransfer Types\nStargate supports four transfer patterns, all coordinated through LayerZero V2 messaging and the credit allocation system:\nNative Pool Transfers\nPool-to-Pool : Direct transfers between core chains (e.g., Ethereum ↔ Arbitrum) where native assets are locked/unlocked between StargatePool contracts. This provides the most efficient path for moving established assets between chains with deep liquidity.\nHydra OFT Transfers\nPool-to-OFT : Extending liquidity from core chains to Hydra chains (e.g., Ethereum → Bera) where native assets are locked in pools and minted as OFTs on emerging chains.\nOFT-to-OFT : Point-to-point transfers between Hydra chains (e.g., Bera ↔ Scroll) where OFTs are burned and minted without touching pool liquidity.\nOFT-to-Pool : Redeeming back to native assets (e.g., Bera → Ethereum) where OFTs are burned and native assets are unlocked from pools, providing global redeemability.\nAll transfers use LayerZero V2 for secure crosschain communication, with DVNs verifying state changes and Executors handling automatic execution.\n2. Universal Bridge Hub (Frontend Application)\nBecause of its critical role in moving liquidity and proven LayerZero integration, Stargate also operates the de facto bridge interface for the broader omnichain ecosystem:\nThe stargate.finance frontend supports :\n- Stargate protocol assets (StargatePool and StargateOFT)\n- All LayerZero OFTs across any chain (EVM and non-EVMs)\n- Circle’s CCTP and other common interoperability standards\nImportant: The stargate.finance frontend bridges LayerZero OFT transfers across EVM and non-EVM chains, but Stargate protocol contracts are EVM-only and live solely on LayerZero V2. Frontend support for non-EVMs does not mean the Stargate protocol itself covers non-EVM chains.\nWhy Stargate Matters\nStargate holds a unique position in the LayerZero ecosystem, serving as both critical infrastructure and the primary user gateway for omnichain assets.\nAs Protocol Infrastructure : Stargate provides the foundational liquidity layer that other protocols build on. Instead of every DeFi protocol bootstrapping their own crosschain USDC or ETH infrastructure, they can simply integrate with Stargate’s existing deep pools. This creates a network effect - as more protocols use Stargate liquidity, it becomes the standard liquidity layer for the ecosystem.\nAs Application Gateway : Because Stargate already solved the hard problems of liquidity management and crosschain coordination at scale, the Stargate team built the most comprehensive bridge interface for the broader OFT ecosystem. The stargate.finance frontend serves as the de facto bridge UI not just for Stargate assets, but for all LayerZero OFTs across any chain.\nAs Proof of Concept : Stargate demonstrates that LayerZero V2 can support production-grade financial protocols with real economic value. It’s not just a messaging layer - it’s secure and reliable enough to manage hundreds of millions in liquidity across dozens of chains, with sophisticated credit allocation and automated rebalancing happening entirely through LayerZero messages.\nThis dual role - providing both the liquidity infrastructure and the user interface - makes Stargate the central hub for omnichain asset movement in the LayerZero ecosystem.\nWhen to Use Stargate vs Custom OFT\nScenario Recommendation\nNeed USDC/USDT/ETH liquidity ✅ Use Stargate protocol contracts\nBuilding vaults/lending with native assets ✅ Use Stargate as underlying asset\nLaunching a new token ⚠️ Deploy your own OFT\nNeed custom token economics ⚠️ Deploy your own OFT\nMaking existing ERC20 omnichain ⚠️ Deploy OFT Adapter\nFinding Stargate Contracts\nLayerZero Deployments Page :\n- Visit OFT Ecosystem & Stargate Assets\n- Search for your chain or asset (e.g., “USDC”)\n- Stargate contracts appear at the top of each chain’s contract list\nStargate Resources :\n- Contract Addresses\n- Stargate API\nTransfer Modes & Composability\nStargate supports two transfer modes with different composability capabilities:\nTaxi Mode\n- Single transfer per Stargate message\n- Supports composability - composeMsg can trigger additional actions on destination (e.g., vault deposits, swaps)\n- Automatically enabled when composeMsg is non-empty and oftCmd is empty\n- Required for OVaults and other composable strategies\nBus Mode\n- Multiple transfers bundled in one Stargate message for gas efficiency\n- Does NOT support composability - no lzCompose() execution on destination\n- Optimized for simple transfers without additional logic\nComposability Requirement\nComposable strategies require Taxi mode . Bus mode will not trigger lzCompose() calls. All implementation guides in this documentation cover Taxi mode only.\nNext Steps\nLearn More :\n- Stargate Protocol Docs - Full protocol documentation and architecture\n- OFT Standard - Understand the IOFT interface\n- Value Transfer Patterns - Compare approaches\nBuild :\n- Stargate Integration Guide - Integrate Stargate contracts\n- OVault Overview - Build vaults with Stargate assets\n- Find Contracts - Get deployed addresses\nExplore :\n- Stargate App - Use the bridge interface\n- LayerZero Scan - Track transfers\n- Stargate Analytics - View pool liquidity\nSummary\nStargate Protocol : EVM smart contracts providing unified liquidity for native assets, built entirely on LayerZero V2\nStargate Frontend : Bridge UI serving as the universal gateway for all OFT transfers and common interoperability standards\nFor LayerZero Developers : Use Stargate’s deep liquidity pools instead of bootstrapping your own, or integrate via the frontend for multi-chain OFT support.\nStargate demonstrates the power of building sophisticated financial protocols on LayerZero’s messaging infrastructure.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.lightning.engineering/the-lightning-network/wavelength","domain":"docs.lightning.engineering","title":"Wavelength | Builder's Guide","hash":"0da5f90f75e7c3e010429004625bfd9c4af037912cb266c046af4e12dae6b4a7","tokens":862,"chars":3446,"crawler":"crawler-f6nn","verified":"exact","ts":1791171938551,"text":"Builder's Guide\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nWavelength\nA short overview over the principles that make Wavelength work.\nWavelength is an ark-like settlement layer on Bitcoin. Each participant fully owns their own funds in the form of unpublished Bitcoin transactions (Virtual Transaction Outputs, VTXO). During regular operations, these vtxos do not have to be published to the Bitcoin blockchain, giving the impression that multiple individuals share a single Bitcoin utxo (Unspent Transaction Output), which minimizes onchain transaction fees.\nOnly when the operator is unavailable does it become necessary for the participants to publish their VTXOs and settle them onchain, allowing them to claim their funds. This incurs onchain fees but can be initiated at any time by any participant.\nLightning Network\nWavelength is meant to be fully interoperable with the Lightning Network from the start. All users of Wavelength can receive and send funds over the Lightning Network without additional configuration or software. Eventual internal payments are also conducted through Lightning Network invoices, establishing the Lightning invoice as the conductive tissue between Wavelength and merchants, exchanges and other wallets, including among two participants of Wavelength.\nLightweight and Ready to Go\nWavelength is designed as a lightweight daemon running on a server, desktop, mobile device or inside of a browser tab. It does not have to be continuously running to provide the user a good experience, and the user does not have to manage their own liquidity, but can always receive or send offchain or onchain.\nBoarding\nUpon downloading and initializing Wavelength, the user may generate a Lightning Network invoice. This invoice pays to a virtual HTLC (vHTLC) and that only the user holds the preimage to. Once the vHTLC has been created in the fraction of a second, the user’s wallet claims their VTXO using the preimage, and the Lightning Network payment is settled.\nSimilarly, the user may generate a Bitcoin address, using their own key, the server’s key and a timeout. Any confirmed transactions to this address can then be swapped for a VTXO inside of Wavelength.\nVTXO\nVirtual Transaction Outputs are spendable either cooperatively by the user and the server, or unilaterally by the user using a pre-signed transaction the user holds in memory. This allows VTXOs to be passed instantly without waiting to be included in blocks on the Bitcoin blockchain.\nVTXOs may be split into change VTXOs, allowing arbitrary amounts to be settled. They may also be consolidated by swapping multiple small VTXOs for a larger one.\nUnlike regular onchain transaction outputs, VTXOs expire after a pre-defined number of blocks. They have to regularly be rolled into new VTXOs, or else they are forfeited.\nFees\nOnchain fees occur when an onchain boarding transaction is swept or when at outgoing payment is made. They are generally passed on to the user. Unilateral exists also incur such onchain fees which have to be paid by the user. A new UTXO from an external wallet is typically required to pay such fees.\nLightning Network fees are relevant for all outgoing Lightning payments and are passed on to the user.\nPrevious Glossary\nNext LND\nLast updated 2 months ago\nWas this helpful?\n- Lightning Network\n- Lightweight and Ready to Go\n- Boarding\n- VTXO\n- Fees\nWas this helpful?"}
{"url":"https://bitcoin.org/pl/co-potrzebujesz-wiedziec","domain":"bitcoin.org","title":"Parę rzeczy, o których powinieneś wiedzieć - Bitcoin","hash":"9ad178dcd108c6e06092cc6879a3ff286422c2f7befd22d15c662e0b87867095","tokens":1755,"chars":7020,"crawler":"crawler-f6nn","verified":"exact","ts":1791171940620,"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- Wprowadzenie\n- Osób fizycznych\n- Firm\n- Deweloperów\n- Pierwsze kroki\n- Jak to działa\n- Musisz to wiedzieć\n- Zasoby\n- Exchanges\n- Społeczność\n- BIPs list\n- Słownik\n- Bitcoin Core\n- Innowacje\n- Weź udział\n- Wesprzyj Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Rozwój\n- FAQ\n- Polski\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: pl\nParę rzeczy, o których powinieneś wiedzieć\nJeśli zamierzasz odkrywać Bitcoin, jest kilka rzeczy, o których powinieneś wiedzieć. Bitcoin pozwala na wymianę pieniędzy w nieco inny sposób niż za pośrednictwem tradycyjnych banków, dlatego też powinieneś dokładnie przestudiować dostępne informacje, zanim zdecydujesz się na przeprowadzenie jakichkolwiek poważnych transakcji. Bitcoin należy traktować z taką samą troską, jak realny portfel we własnej kieszeni, a w niektórych przypadkach nawet poważniej!\nOchrona Twojego portfela\nZupełnie jak w prawdziwym życiu, Twój portfel potrzebuje zabezpieczeń. Bitcoin umożliwia transfery środków oraz przekazywanie ich w dowolne miejsce w bardzo prosty sposób. Tak wspaniałe cechy mogą rodzić obawy o bezpieczeństwo. Równocześnie Bitcoin może zapewnić bardzo wysoki poziom bezpieczeństwa, o ile jest poprawnie używany. Zawsze pamiętaj, że przyjęcie dobrych praktyk w celu zapewnienia prawidłowej ochrony Twoich pieniędzy to Twój obowiązek. Przeczytaj więcej o zabezpieczaniu swego portfela .\nThere is no undo button\nBitcoin has no central authority to reverse a mistake. If you permanently lose access to your wallet—for example by losing your recovery phrase—your funds are gone permanently. No one—not developers, miners, wallet providers, or exchanges—can recover funds that you permanently lose from a self-custodied wallet. Always back up your wallet and keep your recovery information safe and private.\nYou are your own bank\nWhen you hold your own private keys, you control your bitcoin—but you are also responsible for keeping it secure. If you leave your coins with an exchange or another custodian, you rely on that third party to safeguard them and to honor withdrawals. That reliance introduces counterparty risk: the custodian's own security, solvency, and policies now stand between you and your funds. Holding your own keys removes that risk, but requires you to secure your wallet and backups yourself.\nBitcoin nie jest anonimowy\nAby chronić Twoją prywatność w Bitcoin niezbędny jest pewien wysiłek. Wszystkie transakcje Bitcoin są przechowywane stale i publicznie w sieci co oznacza, że każdy może sprawdzić saldo i transakcje zawarte przez dowolny adresy Bitcoin. Jednakże tożsamość właściciela danego adresu jest nieznana, dopóki nie ujawni on swoich danych osobowych podczas dokonywania transakcji lub w innej okoliczności. Jest to jeden z powodów, dla których adresy Bitcoin powinny być używane tylko raz. Zawsze pamiętaj że stosowanie dobrych praktyk w celu ochrony prywatności to Twój obowiązek. Przeczytaj więcej o ochronie Twej prywatności .\nTransakcje Bitcoin są nieodwracalne\nŻadna transakcja dokonana przy użyciu Bitcoin nie może być cofnięta, może być jedynie zwrócona przez osobę, która otrzymała środki. Oznacza to, że powinieneś zwracać uwagę, by prowadzić interesy z ludźmi lub organizacjami, których znasz i ufasz lub o ugruntowanej renomie. Ze swojej strony firmy muszą kontrolować żądania płatności, które przedstawiają klientom. Bitcoin potrafi wykrywać literówki i zwykle nie zezwoli Ci omyłkowo przesłać pieniędzy na nieprawidłowy adres. Dodatkowe serwisy mogą w przyszłości oferować więcej wyboru i zabezpieczenia dla konsumenta.\nBłyskawiczne transakcje są mniej bezpieczne\nTransakcja Bitcoin jest zwykle wykonana w ciągu kilku sekund i zaczyna być potwierdzana w ciągu 10 następnych minut. W tym czasie transakcja może zostać uznana za autentyczną, lecz odwracalną. Nieuczciwi użytkownicy mogą próbować oszukiwać. Jeśli nie możesz czekać na potwierdzenie, bezpieczeństwo może zostać zwiększone poprzez zastosowanie niewielkiej opłaty za transakcję lub użycie systemu detekcji podwójnego wydatkowania. Dla większych transakcji, na przykład o wartości 1000 USD, warto poczekać na 6 lub więcej potwierdzeń. Każde potwierdzenie wykładniczo obniża ryzyko odwrócenia transakcji.\nCena bitcoina jest zmienna\nWartość bitcoina może w krótkim czasie niespodziewanie wzrosnąć lub zmaleć z powodu młodej gospodarki, nowatorskiej natury oraz niekiedy niepłynności rynków. Z tego też powodu nie zaleca się obecnie trzymania oszczędności w Bitcoin. Bitcoin powinien być uznany za aktywa wysokiego ryzyka i nigdy nie powinno się przechowywać tu pieniędzy, na których utratę nie można sobie pozwolić. Jeśli otrzymasz płatność poprzez Bitcoin, istnieje wiele serwisów, które pozwolą Ci je natychmiastowo wymienić na lokalną walutę.\nBitcoin jest nadal w fazie eksperymentalnej\nBitcoin jest eksperymentalną, aktywnie rozwijaną walutą. Choć staje się coraz mniej eksperymentalna w miarę wzrostu użytkowania, powinieneś pamiętać, że Bitcoin jest nowym wynalazkiem, testującym pomysły, których nikt nigdy wcześniej nie próbował. Dlatego też nikt nie może przewidzieć jego przyszłości.\nRządowe podatki i regulacje\nBitcoin nie jest oficjalną walutą. Wiedząc to pamiętaj, że większość obszarów jurysdykcji nadal wymaga od ciebie opłacenia podatku dochodowego, od sprzedaży, kosztów płacy czy podatku od zysków ze sprzedaży towarów zawierających wartość włączając w to Bitcoin. Twoim obowiązkiem jest upewnić się, że stosujesz się do podatków i innych upoważnień ustawowych lub wykonawczych wydanych przez rząd lub lokalne gminy.\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nWprowadzenie:\n-\nOsób fizycznych\n-\nFirm\n-\nDeweloperów\n-\nPierwsze kroki\n-\nJak to działa\n-\nMusisz to wiedzieć\nZasoby:\n-\nZasoby\n-\nExchanges\n-\nSpołeczność\n-\nBIPs list\n-\nSłownik\n-\nBitcoin Core\nWeź udział:\n-\nWesprzyj Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nRozwój\nOther:\nInformacje prawne\nPrivacy Policy\nPrasa\nO bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Dostępny w ramach licencji MIT\nNetwork Status\n- Polski\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- 繁體中文\npl"}
{"url":"https://www.anchor-lang.com/docs/clients","domain":"www.anchor-lang.com","title":"Clients","hash":"dab4b8e3f36ad809bcae81edf40d67f0190b896add23ddec7091816e5672035e","tokens":103,"chars":409,"crawler":"crawler-f6nn","verified":"exact","ts":1791171942660,"text":"Anchor Docs\nGithub Discord Stack Exchange\nClients\nLearn how to interact with Anchor programs using client libraries in TypeScript and Rust.\nTypeScript\nLearn how to use Anchor's TypeScript client library to interact with Solana programs\nRust\nLearn how to use Anchor's Rust client library to interact with Solana programs\nPrevious\nCross Program Invocation\nNext\nTypeScript\nOn this page\nNo Headings\nEdit on GitHub"}
{"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-f6nn","verified":"exact","ts":1791171945106,"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://docs.openzeppelin.com/contracts/5.x/utilities","domain":"docs.openzeppelin.com","title":"Utilities | OpenZeppelin Docs","hash":"d8014dfa09310858c17131cd6ed9aeb39f25b431edf0b35a00299d4864ba3093","tokens":6661,"chars":26644,"crawler":"crawler-f6nn","verified":"exact","ts":1791171947989,"text":"Home Forum Website Impact\nOpenZeppelin Contracts\nUtilities\nOpen in Claude\nThe OpenZeppelin Contracts provide a ton of useful utilities that you can use in your project. For a complete list, check out the API Reference .\nHere are some of the more popular ones.\nCryptography\nChecking Signatures On-Chain\nAt a high level, signatures are a set of cryptographic algorithms that allow for a signer to prove himself as the owner of a private key used to authorize a piece of information (generally a transaction or UserOperation ). Natively, the EVM supports the Elliptic Curve Digital Signature Algorithm ( ECDSA ) using the secp256k1 curve, however other signature algorithms such as P256 and RSA are supported.\nEthereum Signatures (secp256k1)\nECDSA provides functions for recovering and managing Ethereum account ECDSA signatures. These are often generated via web3.eth.sign , and form a 65-byte array (of type bytes in Solidity) arranged the following way: [[v (1)], [r (32)], [s (32)]] .\nThe data signer can be recovered with ECDSA.recover , and its address compared to verify the signature. Most wallets will hash the data to sign and add the prefix \\x19Ethereum Signed Message:\\n , so when attempting to recover the signer of an Ethereum signed message hash, you’ll want to use toEthSignedMessageHash .\nusing ECDSA for bytes32 ;\nusing MessageHashUtils for bytes32 ;\nfunction _verify ( bytes32 data , bytes memory signature , address account ) internal pure returns ( bool ) {\nreturn data\n. toEthSignedMessageHash ()\n. recover (signature) == account;\n}\nGetting signature verification right is not trivial: make sure you fully read and understand MessageHashUtils 's and ECDSA 's documentation.\nP256 Signatures (secp256r1)\nP256, also known as secp256r1, is one of the most used signature schemes. P256 signatures are standardized by the National Institute of Standards and Technology (NIST) and they are widely available in consumer hardware and software.\nThese signatures are different from regular Ethereum Signatures (secp256k1) in that they use a different elliptic curve to perform operations but have similar security guarantees.\nusing P256 for bytes32 ;\nfunction _verify (\nbytes32 data ,\nbytes32 r ,\nbytes32 s ,\nbytes32 qx ,\nbytes32 qy\n) internal view returns ( bool ) {\nreturn data. verify (r, s, qx, qy);\n}\nBy default, the verify function will try calling the RIP-7212 precompile at address 0x100 and will fallback to an implementation in Solidity if not available. We encourage you to use verifyNative if you know the precompile is available on the chain you’re working on and on any other chain on which you intend to use the same bytecode in the future. In case of any doubts regarding the implementation roadmap of the native precompile P256 of potential future target chains, please consider using verifySolidity .\nusing P256 for bytes32 ;\nfunction _verify (\nbytes32 data ,\nbytes32 r ,\nbytes32 s ,\nbytes32 qx ,\nbytes32 qy\n) internal view returns ( bool ) {\n// Will only call the precompile at address(0x100)\nreturn data. verifyNative (r, s, qx, qy);\n}\nThe P256 library only allows for s values in the lower order of the curve (i.e. s <= N/2 ) to prevent malleability. In case your tooling produces signatures in both sides of the curve, consider flipping the s value to keep compatibility.\nRSA\nRSA is a public-key cryptosystem that was popularized by corporate and governmental public key infrastructures ( PKIs ) and DNSSEC .\nThis cryptosystem consists of using a private key that’s the product of 2 large prime numbers. The message is signed by applying a modular exponentiation to its hash (commonly SHA256), where both the exponent and modulus compose the public key of the signer.\nRSA signatures are known for being less efficient than elliptic curve signatures given the size of the keys, which are big compared to ECDSA keys with the same security level. Using plain RSA is considered unsafe, this is why the implementation uses the EMSA-PKCS1-v1_5 encoding method from RFC8017 to include padding to the signature.\nTo verify a signature using RSA, you can leverage the RSA library that exposes a method for verifying RSA with the PKCS 1.5 standard:\nusing RSA for bytes32 ;\nfunction _verify (\nbytes32 data ,\nbytes memory signature ,\nbytes memory e ,\nbytes memory n\n) internal pure returns ( bool ) {\nreturn data. pkcs1Sha256 (signature, e, n);\n}\nAlways use keys of at least 2048 bits. Additionally, be aware that PKCS#1 v1.5 allows for replayability due to the possibility of arbitrary optional parameters. To prevent replay attacks, consider including an onchain nonce or unique identifier in the message.\nSignature Verification\nThe SignatureChecker library provides a unified interface for verifying signatures from different sources. It seamlessly supports:\n- ECDSA signatures from externally owned accounts (EOAs)\n- ERC-1271 signatures from smart contract wallets like Argent and Safe Wallet\n- ERC-7913 signatures from keys that don’t have their own Ethereum address\nThis allows developers to write signature verification code once and have it work across all these different signature types.\nBasic Signature Verification\nFor standard signature verification that supports both EOAs and ERC-1271 contracts:\nusing SignatureChecker for address ;\nfunction _verifySignature ( address signer , bytes32 hash , bytes memory signature ) internal view returns ( bool ) {\nreturn SignatureChecker. isValidSignatureNow (signer, hash , signature);\n}\nThe library automatically detects whether the signer is an EOA or a contract and uses the appropriate verification method.\nERC-1271 Contract Signatures\nFor smart contract wallets that implement ERC-1271, you can explicitly use:\nfunction _verifyContractSignature ( address signer , bytes32 hash , bytes memory signature ) internal view returns ( bool ) {\nreturn SignatureChecker. isValidERC1271SignatureNow (signer, hash , signature);\n}\nERC-7913 Extended Signatures\nERC-7913 extends signature verification to support keys that don’t have their own Ethereum address. This is useful for integrating non-Ethereum cryptographic curves, hardware devices, or other identity systems.\nA signer is represented as a bytes object that concatenates a verifier address and a key: verifier || key .\nfunction _verifyERC7913Signature ( bytes memory signer , bytes32 hash , bytes memory signature ) internal view returns ( bool ) {\nreturn SignatureChecker. isValidSignatureNow (signer, hash , signature);\n}\nThe verification process works as follows:\n- If signer.length < 20 : verification fails\n- If signer.length == 20 : verification is done using standard signature checking\n- Otherwise: verification is done using an ERC-7913 verifier\nBatch Verification\nFor verifying multiple ERC-7913 signatures at once:\nfunction _verifyMultipleSignatures (\nbytes32 hash ,\nbytes [] memory signers ,\nbytes [] memory signatures\n) internal view returns ( bool ) {\nreturn SignatureChecker. areValidSignaturesNow ( hash , signers, signatures);\n}\nThis function will reject inputs that contain duplicated signers. Sorting the signers by their keccak256 hash is recommended to minimize the gas cost.\nThis unified approach allows smart contracts to accept signatures from any supported source without needing to implement different verification logic for each type.\nVerifying Merkle Proofs\nDevelopers can build a Merkle Tree off-chain, which allows for verifying that an element (leaf) is part of a set by using a Merkle Proof. This technique is widely used for creating whitelists (e.g., for airdrops) and other advanced use cases.\nOpenZeppelin Contracts provides a JavaScript library for building trees off-chain and generating proofs.\nMerkleProof provides:\n- verify - can prove that some value is part of a Merkle tree .\n- multiProofVerify - can prove multiple values are part of a Merkle tree.\nFor an on-chain Merkle Tree, see the MerkleTree library.\nIntrospection\nIn Solidity, it’s frequently helpful to know whether or not a contract supports an interface you’d like to use. ERC-165 is a standard that enables runtime interface detection. Contracts provide helpers both for implementing ERC-165 in your contracts and querying other contracts:\n- IERC165 — this is the ERC-165 interface that defines supportsInterface . When implementing ERC-165, you’ll conform to this interface.\n- ERC165 — inherit this contract if you’d like to support interface detection using a lookup table in contract storage. You can register interfaces using _registerInterface(bytes4) : check out example usage as part of the ERC-721 implementation.\n- ERC165Checker — ERC165Checker simplifies the process of checking whether or not a contract supports an interface you care about.\n- include with using ERC165Checker for address;\n- myAddress._supportsInterface(bytes4)\n- myAddress._supportsAllInterfaces(bytes4[\\])\ncontract MyContract {\nusing ERC165Checker for address ;\nbytes4 private InterfaceId_ERC721 = 0x80ac58cd ;\n/**\n* @dev transfer an ERC-721 token from this contract to someone else\n*/\nfunction transferERC721 (\naddress token ,\naddress to ,\nuint256 tokenId\n)\npublic\n{\nrequire (token. supportsInterface (InterfaceId_ERC721), \"IS_NOT_721_TOKEN\" );\nIERC721 (token). transferFrom ( address ( this ), to, tokenId);\n}\nMath\nAlthough Solidity already provides math operators (i.e. + , - , etc.), Contracts includes Math ; a set of utilities for dealing with mathematical operators, with support for extra operations (e.g., average ) and SignedMath ; a library specialized in signed math operations.\nInclude these contracts with using Math for uint256 or using SignedMath for int256 and then use their functions in your code:\ncontract MyContract {\nusing Math for uint256 ;\nusing SignedMath for int256 ;\nfunction tryOperations ( uint256 a , uint256 b ) internal pure {\n( bool succeededAdd, uint256 resultAdd) = x. tryAdd (y);\n( bool succeededSub, uint256 resultSub) = x. trySub (y);\n( bool succeededMul, uint256 resultMul) = x. tryMul (y);\n( bool succeededDiv, uint256 resultDiv) = x. tryDiv (y);\n// ...\n}\nfunction unsignedAverage ( int256 a , int256 b ) {\nint256 avg = a. average (b);\n// ...\n}\nEasy!\nWhile working with different data types that might require casting, you can use SafeCast for type casting with added overflow checks.\nStructures\nSome use cases require more powerful data structures than the arrays and mappings offered natively in Solidity. These contracts provide libraries for enhanced data structure management:\n- BitMaps : Store packed booleans in storage.\n- Checkpoints : Checkpoint values with built-in lookups.\n- DoubleEndedQueue : Store items in a queue with pop() and queue() constant time operations.\n- EnumerableSet : A set with enumeration capabilities.\n- EnumerableMap : A mapping variant with enumeration capabilities.\n- MerkleTree : An on-chain Merkle Tree with helper functions.\n- Heap : A binary heap to store elements with priority defined by a comparator function.\nThe Enumerable* structures are similar to mappings in that they store and remove elements in constant time and don’t allow for repeated entries, but they also support enumeration , which means you can easily query all stored entries both on and off-chain.\nBuilding a Merkle Tree\nBuilding an on-chain Merkle Tree allows developers to keep track of the history of roots in a decentralized manner. For these cases, the MerkleTree includes a predefined structure with functions to manipulate the tree (e.g. pushing values or resetting the tree).\nThe Merkle Tree does not keep track of the roots intentionally, so that developers can choose their tracking mechanism. Setting up and using a Merkle Tree in Solidity is as simple as follows:\nFunctions are exposed without access control for demonstration purposes\nusing MerkleTree for MerkleTree .Bytes32PushTree;\nMerkleTree.Bytes32PushTree private _tree;\nfunction setup ( uint8 _depth, bytes32 _zero) public /* onlyOwner */ {\nroot = _tree. setup (_depth, _zero);\n}\nfunction push ( bytes32 leaf ) public /* onlyOwner */ {\n( uint256 leafIndex, bytes32 currentRoot) = _tree. push (leaf);\n// Store the new root.\n}\nThe library also supports custom hashing functions, which can be passed as an extra parameter to the push and setup functions.\nUsing custom hashing functions is a sensitive operation. After setup, it requires continuing to use the same hashing function for every new value pushed to the tree to avoid corrupting the tree. For this reason, it’s a good practice to keep your hashing function static in your implementation contract as follows:\nusing MerkleTree for MerkleTree .Bytes32PushTree;\nMerkleTree.Bytes32PushTree private _tree;\nfunction setup ( uint8 _depth, bytes32 _zero) public /* onlyOwner */ {\nroot = _tree. setup (_depth, _zero, _hashFn);\n}\nfunction push ( bytes32 leaf ) public /* onlyOwner */ {\n( uint256 leafIndex, bytes32 currentRoot) = _tree. push (leaf, _hashFn);\n// Store the new root.\n}\nfunction _hashFn ( bytes32 a , bytes32 b ) internal view returns ( bytes32 ) {\n// Custom hash function implementation\n// Kept as an internal implementation detail to\n// guarantee the same function is always used\n}\nUsing a Heap\nA binary heap is a data structure that always stores the most important element at its peak and it can be used as a priority queue.\nTo define what is most important in a heap, these frequently take comparator functions that tell the binary heap whether a value has more relevance than another.\nOpenZeppelin Contracts implements a Heap data structure with the properties of a binary heap. The heap uses the lt function by default but allows to customize its comparator.\nWhen using a custom comparator, it’s recommended to wrap your function to avoid the possibility of mistakenly using a different comparator function:\nfunction pop ( Uint256Heap storage self ) internal returns ( uint256 ) {\nreturn pop (self, Comparators.gt);\n}\nfunction insert ( Uint256Heap storage self , uint256 value ) internal {\ninsert (self, value, Comparators.gt);\n}\nfunction replace ( Uint256Heap storage self , uint256 newValue ) internal returns ( uint256 ) {\nreturn replace (self, newValue, Comparators.gt);\n}\nMisc\nPacking\nThe storage in the EVM is shaped in chunks of 32 bytes, each of these chunks is known as a slot , and can hold multiple values together as long as these values don’t exceed 32 bytes. This property allows for a technique known as packing --placing values together in a single storage slot to reduce the costs associated with reading and writing these values.\nCommonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires loading such struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory.\nThe Packing library is a set of utilities for packing values that fit in 32 bytes. The library includes 3 main functionalities:\n- Packing 2 bytesXX values\n- Extracting a packed bytesXX value from a bytesYY\n- Replacing a packed bytesXX value from a bytesYY\nWith these primitives, one can build custom functions to create custom packed types. For example, suppose you need to pack an address of 20 bytes with a bytes4 selector and an uint64 time period:\nfunction _pack ( address account , bytes4 selector , uint64 period ) external pure returns ( bytes32 ) {\nbytes12 subpack = Packing. pack_4_8 (selector, bytes8 (period));\nreturn Packing. pack_20_12 ( bytes20 (account), subpack);\n}\nfunction _unpack ( bytes32 pack ) external pure returns ( address , bytes4 , uint64 ) {\nreturn (\naddress (Packing. extract_32_20 (pack, 0 )),\nPacking. extract_32_4 (pack, 20 ),\nuint64 (Packing. extract_32_8 (pack, 24 ))\n);\n}\nStorage Slots\nSolidity allocates a storage pointer for each variable declared in a contract. However, there are cases when it’s required to access storage pointers that can’t be derived by using regular Solidity.\nFor those cases, the StorageSlot library allows for manipulating storage slots directly.\nbytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc ;\nfunction _getImplementation () internal view returns ( address ) {\nreturn StorageSlot. getAddressSlot (_IMPLEMENTATION_SLOT).value;\n}\nfunction _setImplementation ( address newImplementation ) internal {\nrequire (newImplementation.code.length > 0 );\nStorageSlot. getAddressSlot (_IMPLEMENTATION_SLOT).value = newImplementation;\n}\nThe TransientSlot library supports transient storage through user defined value types ( UDVTs ), which enables the same value types as in Solidity.\nbytes32 internal constant _LOCK_SLOT = 0xf4678858b2b588224636b8522b729e7722d32fc491da849ed75b3fdf3c84f542 ;\nfunction _getTransientLock () internal view returns ( bool ) {\nreturn _LOCK_SLOT. asBoolean (). tload ();\n}\nfunction _setTransientLock ( bool lock ) internal {\n_LOCK_SLOT. asBoolean (). tstore (lock);\n}\nManipulating storage slots directly is an advanced practice. Developers MUST make sure that the storage pointer is not colliding with other variables.\nOne of the most common use cases for writing directly to storage slots is ERC-7201 for namespaced storage, which is guaranteed to not collide with other storage slots derived by Solidity.\nUsers can leverage this standard using the SlotDerivation library.\nusing SlotDerivation for bytes32 ;\nstring private constant _NAMESPACE = \"\" // eg. example.main\nfunction erc7201Pointer () internal view returns ( bytes32 ) {\nreturn _NAMESPACE. erc7201Slot ();\n}\nBase64\nBase64 util allows you to transform bytes32 data into its Base64 string representation.\nThis is especially useful for building URL-safe tokenURIs for both ERC-721 or ERC-1155 . This library provides a clever way to serve URL-safe Data URI compliant strings to serve on-chain data structures.\nHere is an example to send JSON Metadata through a Base64 Data URI using an ERC-721:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24 ;\nimport { ERC721 } from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\" ;\nimport { Strings } from \"@openzeppelin/contracts/utils/Strings.sol\" ;\nimport { Base64 } from \"@openzeppelin/contracts/utils/Base64.sol\" ;\ncontract Base64NFT is ERC721 {\nusing Strings for uint256 ;\nconstructor () ERC721 (\"Base64NFT\", \"MTK\") {}\n// ...\nfunction tokenURI ( uint256 tokenId ) public pure override returns ( string memory ) {\n// Equivalent to:\n// {\n// \"name\": \"Base64NFT #1\",\n// // Replace with extra ERC-721 Metadata properties\n// }\n// prettier-ignore\nstring memory dataURI = string . concat ( \"{\\\"name\\\": \\\"Base64NFT #\" , tokenId. toString (), \"\\\"}\" );\nreturn string . concat ( \"data:application/json;base64,\" , Base64. encode ( bytes (dataURI)));\n}\nMulticall\nThe Multicall abstract contract comes with a multicall function that bundles together multiple calls in a single external call. With it, external accounts may perform atomic operations comprising several function calls. This is not only useful for EOAs to make multiple calls in a single transaction, it’s also a way to revert a previous call if a later one fails.\nConsider this dummy contract:\n// contracts/Box.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20 ;\nimport { Multicall } from \"@openzeppelin/contracts/utils/Multicall.sol\" ;\ncontract Box is Multicall {\nfunction foo () public {\n// ...\n}\nfunction bar () public {\n// ...\n}\nThis is how to call the multicall function using Ethers.js, allowing foo and bar to be called in a single transaction:\n// scripts/foobar.js\nconst instance = await ethers. deployContract ( \"Box\" );\nawait instance. multicall ([\ninstance.interface. encodeFunctionData ( \"foo\" ),\ninstance.interface. encodeFunctionData ( \"bar\" )\n]);\nLow-level Calls\nThe LowLevelCall library provides low-level external calls with fixed-size return data handling, protecting against return bombing attacks where callees allocate excessive memory.\nThe library efficiently handles return data up to 64 bytes, allowing you to ignore it entirely or extract 1-2 bytes32 values:\nusing LowLevelCall for address ;\nfunction example ( address target , bytes memory data ) internal {\nbool success;\nbytes32 result1;\nbytes32 result2;\n// Ignore return data\nsuccess = target. callNoReturn (data);\n// Extract single 32-byte value\n(success, result1, ) = target. callReturn64Bytes (data);\n// Extract two 32-byte values\n(success, result1, result2) = target. callReturn64Bytes (data);\n}\nYou can also check return data size before processing:\nfunction checkReturnSize ( address target , bytes memory data ) internal returns ( uint256 value , uint256 otherValue ) {\n( bool success, bytes32 result1, bytes32 result2) = target. callReturn64Bytes (data);\nif ( ! success || LowLevelCall. returnDataSize () < 32 ) {\nreturn ( 0 , 0 );\n} else if (LowLevelCall. returnDataSize () < 64 ) {\nreturn ( uint256 (result1), 0 );\n} else {\nreturn ( uint256 (result1), uint256 (result2));\n}\nMemory\nThe Memory library provides functions for advanced use cases that require granular memory management. A common use case is to avoid unnecessary memory expansion costs when performing repeated operations that allocate memory in a loop. Consider the following example:\nfunction processMultipleItems ( uint256 [] memory items ) internal {\nfor ( uint256 i = 0 ; i < items.length; i ++ ) {\nbytes memory tempData = abi . encode (items[i], block .timestamp);\n// Process tempData...\n}\nNote that each iteration allocates new memory for tempData , causing the memory to expand continuously. This can be optimized by resetting the memory pointer between iterations:\nfunction processMultipleItems ( uint256 [] memory items ) internal {\nMemory.Pointer ptr = Memory. getFreeMemoryPointer (); // Cache pointer\nfor ( uint256 i = 0 ; i < items.length; i ++ ) {\nbytes memory tempData = abi . encode (items[i], block .timestamp);\n// Process tempData...\nMemory. unsafeSetFreeMemoryPointer (ptr); // Reset pointer for reuse\n}\nThis way, memory allocated for tempData in each iteration is reused, significantly reducing memory expansion costs when processing many items.\nOnly use these functions after carefully confirming they’re necessary. By default, Solidity handles memory safely. Using this library without understanding memory layout and safety may be dangerous. See the memory layout and memory safety documentation for details.\nHistorical Block Hashes\nBlockhash provides L2 protocol developers with extended access to historical block hashes beyond Ethereum’s native 256-block limit. By leveraging EIP-2935 's history storage contract, the library enables access to block hashes up to 8,191 blocks in the past, making it invaluable for L2 fraud proofs and state verification systems.\nThe library seamlessly combines native BLOCKHASH opcode access for recent blocks (≤256) with EIP-2935 history storage queries for older blocks (257-8,191). It handles edge cases gracefully by returning zero for future blocks or those beyond the history window, matching the EVM’s behavior. The implementation uses gas-efficient assembly for static calls to the history storage contract.\ncontract L1Inbox {\nusing Blockhash for uint256 ;\nfunction verifyBlockHash ( uint256 blockNumber , bytes32 expectedHash ) public view returns ( bool ) {\nreturn blockNumber. blockHash () == expectedHash;\n}\nAfter EIP-2935 activation, it takes 8,191 blocks to completely fill the history storage. Before that, only block hashes since the fork block will be available.\nTime\nThe Time library provides helpers for manipulating time-related objects in a type-safe manner. It uses uint48 for timepoints and uint32 for durations, helping to reduce gas costs while providing adequate precision.\nOne of its key features is the Delay type, which represents a duration that can automatically change its value at a specified point in the future while maintaining delay guarantees. For example, when reducing a delay value (e.g., from 7 days to 1 day), the change only takes effect after the difference between the old and new delay (i.e. a 6 days) or a minimum setback period, preventing an attacker who gains admin access from immediately reducing security timeouts and executing sensitive operations. This is particularly useful for governance and security mechanisms where timelock periods need to be enforced.\nConsider this example for using and safely updating Delays:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.27 ;\nimport { Time } from \"contracts/utils/types/Time.sol\" ;\ncontract MyDelayedContract {\nusing Time for * ;\nTime.Delay private _delay;\nconstructor () {\n_delay = Time. toDelay ( 3 days );\n}\nfunction schedule ( bytes32 operationId ) external {\n// Get the current `_delay` value, respecting any pending delay changes if they've taken effect\nuint32 currentDelay = _delay. get ();\nuint48 executionTime = Time. timestamp () + currentDelay;\n// ... schedule the operation at `executionTime`\n}\nfunction execute ( bytes32 operationId ) external {\nuint48 executionTime = getExecutionTime (operationId);\nrequire (executionTime > 0 , \"Operation not scheduled\" );\nrequire (Time. timestamp () >= executionTime, \"Delay not elapsed yet\" );\n// ... execute the operation\n}\n// Update the delay with `Time`'s safety mechanism\nfunction updateDelay ( uint32 newDelay ) external {\n(Time.Delay updatedDelay, uint48 effect) = _delay. withUpdate (\nnewDelay, // The new delay value\n5 days // Minimum setback if reducing the delay\n);\n_delay = updatedDelay;\n// ... emit events\n}\n// Get complete delay details including pending changes\nfunction getDelayDetails () external view returns (\nuint32 currentValue , // The current delay value\nuint32 pendingValue , // The pending delay value\nuint48 effectTime // The timepoint when the pending delay change takes effect\n) {\nreturn _delay. getFull ();\n}\nThis pattern is used extensively in OpenZeppelin’s AccessManager for implementing secure time-based access control. For example, when changing an admin delay:\n// From AccessManager.sol\nfunction _setTargetAdminDelay ( address target , uint32 newDelay ) internal virtual {\nuint48 effect;\n(_targets[target].adminDelay, effect) = _targets[target].adminDelay. withUpdate (\nnewDelay,\nminSetback ()\n);\nemit TargetAdminDelayUpdated (target, newDelay, effect);\n}\nGovernance\nPrevious Page\nOverview\nNext Page\nOn this page\nCryptography Checking Signatures On-Chain Ethereum Signatures (secp256k1) P256 Signatures (secp256r1) RSA Signature Verification Basic Signature Verification ERC-1271 Contract Signatures ERC-7913 Extended Signatures Batch Verification Verifying Merkle Proofs Introspection Math Structures Building a Merkle Tree Using a Heap Misc Packing Storage Slots Base64 Multicall Low-level Calls Memory Historical Block Hashes Time"}
{"url":"https://docs.meteora.ag/protocol/protocol-revenues","domain":"docs.meteora.ag","title":"Protocol Revenues - Meteora Documentation","hash":"d11e55bc96bf089c698f488e855d78a79306c57594f5ad109c63c9c6df7548f3","tokens":947,"chars":3786,"crawler":"crawler-f6nn","verified":"exact","ts":1791171950285,"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\nProtocol Revenues\nMeteora protocol revenues and protocol fee distribution across DLMM, DAMM v2, DAMM v1, and DBC\nMeteora earns a share of the trading fees generated on swaps routed through its pools. These protocol fee percentages apply to the trading fee, not to the full swap notional.\nFee Distribution Logic\nThe pool first calculates the total trading fee for the swap. The program then splits that trading fee between LPs, market makers, limit order owners, launch partners, token creators, the protocol, and optional referral or host accounts depending on the product.\nTrading Fee = LP/MM/LO/Trading Fee Share + Protocol-Side Fee\nWhen a referral or host fee account is included, that fee is paid from the protocol-side fee:\nProtocol Revenue = Protocol-Side Fee - Referral/Host Fee\nReferral and host fees do not increase the total trading fee paid by the swapper. They are carved out of the protocol-side fee when the swap includes the required referral or host account.\nDLMM\nDLMM fees can be split between market-maker liquidity, limit-order liquidity, protocol fees, and host fees.\nFee Source Pool Type Protocol-Side Fee LP/Owner Fee Notes\nMM position Standard pools 10% 90% LP fee Standard pool protocol share is set by the operator or preset.\nMM position Launch pools 20% 80% LP fee Launch pools use the ILM protocol share.\nLimit order Limit-order supported pools 50% 50% limit-order owner fee Applies to the limit-order portion of the trading fee.\nDLMM swaps can include a host fee account. When present, the host fee is 20% of the eligible protocol-side fee. If no host fee account is provided, the host fee is 0 .\nDAMM v2\nDAMM v2 applies the same protocol split to standard pools and launch pools.\nFee Source Pool Type Protocol-Side Fee LP Fee\nMM position Standard pools 20% 80%\nMM position Launch pools 20% 80%\nDAMM v2 swaps can include a referral token account. When present, the referral fee is 20% of the protocol-side fee. If no referral account is provided, the referral fee is 0 .\nFor DAMM v2 compounding pools, the LP side can be split between claimable fees and auto-compounded fees after the protocol fee is removed.\nDAMM v1\nDAMM v1 fee distribution depends on whether the pool is constant product or stable swap.\nPool Type Protocol-Side Fee LP Fee Trade Fee\nConstant product standard pools 20% 80% 0.25%\nConstant product launch pools 20% 80% Customizable\nStable swap pools 0% 100% 0.01%\nDAMM v1 swaps can include a referral or host fee account. When present, the referral/host fee is 20% of the protocol-side fee. If no referral or host account is provided, the referral/host fee is 0 .\nDBC\nDBC splits bonding-curve swap fees between protocol fees and the virtual liquidity trading fee share.\nFee Source Protocol-Side Fee Trading Fee Share Notes\nVirtual liquidity position 20% 80% The trading fee share is split between partner and creator according to the config’s creator trading fee percentage.\nDBC swaps can include a referral token account. When present, the referral fee is 20% of the protocol-side fee. If no referral account is provided, the referral fee is 0 .\nCollection in Base or Quote Tokens\nRevenues are derived from swap fees, which are collected in the tokens currently being swapped. Therefore, Meteora accumulates a diverse basket of base and quote tokens, such as SOL, USDC, MET, and other pool assets.\nMeteora’s revenues are not automatically converted to stablecoins such as USDC at the moment of collection.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.openzeppelin.com/symbiotic/architecture","domain":"docs.openzeppelin.com","title":"Architecture | OpenZeppelin Docs","hash":"5b5fc65f7278ee2160c6afa2f5c6e0f3238b13d24a4e9a9c5499a093ce82b317","tokens":1539,"chars":6154,"crawler":"crawler-f6nn","verified":"exact","ts":1791171953336,"text":"Home Forum Website Impact\nSymbiotic Templates\nArchitecture\nOpen in Claude\nSystem overview for the Symbiotic multi-provider template.\nCore Model\n- One active provider per running stack, selected in config/environments/.json .\n- Shared off-chain runtime:\n- OZ Monitor for ingress\n- 3 operator processes\n- 3 Symbiotic relay sidecars for BLS signatures\n- OZ Relayer for destination submission\n- Redis queue\n- Provider-specific on-chain contracts and calldata format.\nProvider Matrix\nProvider Source ingress event Destination submit call Local Testnet Mainnet\nlayerzero JobAssigned SymbioticLayerZeroDVN.submitProof(...) Supported Supported Verified end-to-end (operator-owned config)\nchainlink_ccv CCIPMessageSent OffRamp.execute(...) Supported Supported Not yet\nShared Off-Chain Runtime\nThe provider abstraction decides:\n- which source-chain event the monitor watches\n- how operators encode the signed payload\n- which destination call the relayer submits\nMerkle Batching\nMessages are collected into Merkle trees so one quorum signature can cover many messages:\n- ingress events become message records\n- operators batch message leaves into a Merkle root\n- the root is signed through the Symbiotic relay sidecars\n- proofs let the destination verify individual messages against that signed root\nSymbiotic Integration\nSymbiotic provides the shared security layer:\n- operators register BLS public keys\n- settlement verifies quorum signatures\n- voting power and epoch rules define signature validity\nOperator Internals\nModule Location Purpose\nAPI Server operator/src/api/ Axum HTTP server, webhook endpoint, debug routes\nProvider operator/src/provider/ Provider trait, event decoding, message storage\nSignerJob operator/src/signer/ Batches messages into Merkle trees, requests BLS signatures\nRelaySubmitterJob operator/src/relay_submitter/ Submits signed proofs via OZ Relayer\nStorage operator/src/storage/ redb key-value store for messages, Merkle trees, and submissions\nCrypto operator/src/crypto/ Merkle tree construction, leaf hashing, signing message encoding\nProduction Topology\nThe starter kit runs everything on one machine; production needs a distributed layout. The parts that matter:\nAttestation API availability\nFor the Chainlink CCV path, executors fetch attestations from the URLs the verifier advertises on-chain ( getStorageLocations() ). A single attestation node is a single point of failure that stalls the lane : messages keep verifying, but executors cannot fetch attestations, so nothing executes until the node returns.\nEvery operator node serves the same attestation data ( GET /verifications ) — all of them hold the messages and the aggregated quorum signatures. Production options, in order of preference:\n- Load balancer over multiple operator nodes — advertise one stable URL, health-check /healthz , route to any live operator.\n- Multiple URLs on-chain — getStorageLocations() returns a list; advertise several operators directly and let executors fail over.\n- One designated HA node — acceptable only with real redundancy behind that name (failover, monitoring).\nThe advertised URL is on-chain state, not config: rotate it with the owner-gated updateStorageLocations and treat DNS you can repoint as more operable than raw hosts.\nWhere aggregation happens\nIndividual operators do not serve partial signatures. Each operator signs the Merkle root through its Symbiotic relay sidecar; the relay network aggregates BLS signatures across operators, and every operator then stores the same aggregated result. That is why any single operator can answer attestation queries — availability of the API is your concern; signature aggregation already tolerates individual signer downtime as long as quorum voting power signs.\nAvailability assumptions to engineer for\n- The CCIP indexer polls your attestation API — sustained unavailability means unexecuted (not lost) messages, recoverable once service returns.\n- Operators must reach source-chain RPC (event ingestion + finality gating) and the relay sidecars; run operators across failure domains.\n- The OZ Monitor→operator webhook path is at-least-once, not exactly-once; operators de-duplicate. Monitor outages are recovered by block backfill on restart — bound your max_past_blocks accordingly.\nAdding a New Provider\n- Implement the Provider trait in operator/src/provider/.rs .\n#[async_trait]\npub trait Provider : Send + Sync + ' static {\nfn name ( & self ) -> & ' static str ;\nasync fn handle_webhook_event ( & self , event : & WebhookEvent ) -> Result <(), ProviderError >;\n// Required for a functional provider: the trait ships default impls for\n// these that return an error, so the signing/submission path fails until\n// you override all three.\nfn compute_leaf_hash ( & self , message : & MessageData ) -> Result < B256 , ProviderError >;\nfn encode_signing_message ( & self , tree : & MerkleTreeData ) -> Result < Vec < u8 >, ProviderError >;\nfn prepare_submission (\n& self ,\nmessage : & MessageData ,\ntree : & MerkleTreeData ,\nproof : & MerkleProof ,\ntarget_address : & str ,\n) -> Result < PreparedSubmission , ProviderError >;\n// Optional overrides (sensible defaults provided):\nfn register_api_routes ( & self , router : Router < AppState >) -> Router < AppState > { router }\nfn max_batch_size ( & self ) -> usize { usize :: MAX }\nasync fn acceptance_hook (\n& self ,\n_msg : & MessageData ,\n_context : & AcceptanceContext ,\n) -> Result < AcceptanceDecision , ProviderError > {\nOk ( AcceptanceDecision :: accept ())\n}\nfn verifier_result_for (\n& self ,\n_id : & B256 ,\n) -> Result < Option < VerifierResult >, ProviderError > {\nOk ( None )\n}\n- Add provider config to operator/src/config/mod.rs .\n- Register the provider in operator/src/provider/mod.rs .\n- Add monitor templates under config/templates/oz-monitor/ .\n- Add docs/.mdx and update the docs index .\nSetup\nPrevious Page\nLayerZero\nNext Page\nOn this page\nCore Model Provider Matrix Shared Off-Chain Runtime Merkle Batching Symbiotic Integration Operator Internals Production Topology Attestation API availability Where aggregation happens Availability assumptions to engineer for Adding a New Provider"}
{"url":"https://ethereum.org/staking/solo/","domain":"ethereum.org","title":"Home stake your ETH | ethereum.org","hash":"015b8f952e0156422c44cc09642bb1b2ca525d4d518a3154995661f269d79cf5","tokens":6014,"chars":24053,"crawler":"crawler-f6nn","verified":"exact","ts":1791171956443,"text":"Skip to main content\nHome stake your ETH\n- Receive maximum rewards directly from the protocol for keeping your validator properly functioning and online\n- Run home hardware and personally add to the security and decentralization of the Ethereum network\n- Remove trust, and never give up control of the keys to your funds\nEdit page (opens in a new tab)\nWhat is home staking?\nHome staking is the act of running an Ethereum node connected to the internet and depositing at least 32 ETH to activate a validator , giving you the ability to participate directly in network consensus.\nHome staking is the most direct way to stake. No smart contracts, operators, or custodians stand between you and the protocol. You hold your own keys, actively participate in validating the Ethereum network, and receive network rewards directly. Every other staking method adds layers of technology, middleware, or services on top of this core network activity.\nHome staking increases the decentralization of the Ethereum network , making Ethereum more censorship-resistant and robust against attacks. Other staking methods may not help the network in the same ways. Home staking is the best staking option for securing Ethereum.\nAn Ethereum node consists of both an execution layer (EL) client, as well as a consensus layer (CL) client. These clients are software that work together, along with a valid set of signing keys, to verify transactions and blocks, attest to the correct head of the chain, aggregate attestations, and propose blocks.\nHome stakers are responsible for operating the hardware needed to run these clients. It is highly recommended to use a dedicated machine for this that you operate from home–this is extremely beneficial to the health of the network.\nA home staker receives rewards directly from the protocol for keeping their validator properly functioning and online.\nWhy stake from home?\nHome staking comes with more responsibility but provides you with maximum control over your funds and staking setup.\nKeep all rewards\nHome stakers receive 100% of protocol rewards, paid directly by the protocol while your validator is online.\nSelf-sovereignty\nKeep your own keys and full custody of your funds at all times. Choose the combination of clients and hardware that allows you to minimize your risk. No third party can make these decisions for you or restrict your withdrawals.\nClient and geographic diversity\nHome stakers running minority clients on hardware spread across many locations strengthen the decentralization and security of the network.\nConsiderations before home staking\nAs much as we wish that home staking was accessible and risk free to everyone, this is not reality. There are some practical and serious considerations to keep in mind before choosing to home stake your ETH.\nWhen operating your own node you should spend some time learning how to use the software you've chosen. This involves reading relevant documentation and being attune to communication channels of those dev teams.\nThe more you understand about the software you're running and how proof-of-stake works, the less risky it will be as a staker, and the easier it will be to fix any issues that may arise along the way as a node operator.\nNode setup requires a reasonable comfort level when working with computers, although new tools are making this easier over time. Understanding of the command-line interface is helpful, but no longer strictly required.\nIt also requires very basic hardware setup, and some understanding of minimum recommended specs.\nCurrent community guidance for validator hardware and bandwidth is maintained in the hardware and bandwidth recommendations (EIP-7870) (opens in a new tab) . As a rough guide, plan for a 4 TB NVMe SSD, 64 GB of RAM (less can work, but this is the recommended headroom), a solid modern multi-core CPU, and an internet connection of around 50 Mbps download / 25 Mbps upload.\nSince the Fusaka upgrade introduced PeerDAS, a staking node only needs to store and download a fraction of the network's blob data, significantly reducing disk and bandwidth requirements for home stakers.\nJust like how private keys secure your Ethereum address, you will need to generate keys specifically for your validator. You must understand how to keep any seed phrases or private keys safe and secure.\nEthereum security and scam prevention\nHardware occasionally fails, network connections error out, and client software occasionally needs upgrading. Node maintenance is inevitable and will occasionally require your attention. You'll want to be sure you stay aware of any anticipated network upgrades, or other critical client upgrades.\nYour rewards are proportional to the time your validator is online and properly attesting. Downtime incurs penalties proportional to how many other validators are offline at the same time, but does not result in slashing . Bandwidth also matters, as rewards are decreased for attestations that are not received in time. Requirements will vary, but the current hardware and bandwidth recommendations (EIP-7870) (opens in a new tab) suggest around 50 Mbps download and 25 Mbps upload.\nDifferent from inactivity penalties for being offline, slashing is a much more serious penalty reserved for malicious offenses. By running a minority client with your keys loaded on only one machine at time, your risk of being slashed is minimized. That being said, all stakers must be aware of the risks of slashing.\nMore on slashing and validator lifecycle\nComparison of staking options\nDelegated staking, or staking as a service (SaaS)\nWith SaaS providers you're still required to deposit 32 ETH, but don't have to run hardware. You typically maintain access to your validator keys, but also need to share your signing keys so the operator can act on behalf of your validator. This introduces a layer of trust not present when running your own hardware, and unlike solo staking at home, SaaS does not help as much with geographic distribution of nodes. If you're uncomfortable operating hardware but still looking to stake 32 ETH, using a SaaS provider may be a good option for you.\nLearn more about delegated staking\nLiquid & pooled staking\nSolo staking is significantly more involved than staking with a pooling service, but offers full access to ETH rewards, and full control over the setup and security of your validator. Pooled staking has a significantly lower barrier to entry. Users can stake small amounts of ETH, are not required to generate validator keys, and have no hardware requirements beyond a standard internet connection. Liquidity tokens enable the ability to exit from staking before this is enabled at the protocol level. If you're interested in these features, pooled staking may be a good fit.\nLearn more about pooled staking\nHow it works\n-\nGet some hardware: You need to run a node to stake\n-\nSync an execution layer client\n-\nSync a consensus layer client\n-\nGenerate your keys and load them into your validator client\n-\nMonitor and maintain your node\n-\nDeposit your stake (32 ETH minimum, up to 2048 ETH per validator) to activate your validator\nOnce your node is synced and your keys are generated, you deposit your stake to activate your validator. A single validator requires a minimum of 32 ETH, and can hold up to 2048 ETH. The network recognizes deposits in around 13 minutes, but new validators pass through an activation queue before they start attesting; its length varies with demand.\nWhile active you will earn ETH rewards. With compounding (0x02) withdrawal credentials, rewards are added to your stake automatically; with regular withdrawals (0x01) credentials, rewards above the initial 32 ETH are periodically swept to your withdrawal address.\nIf ever desired, you can exit as a validator, which eliminates the requirement to be online and stops any further rewards. Your remaining balance will then be withdrawn to the withdrawal address that you designate during setup. Exits can be initiated with your validator signing keys, or triggered directly from your withdrawal address with an execution layer transaction, so ultimate control of your funds always rests with your withdrawal address.\nCompounding and the 2048 ETH maximum\nValidators have one of two types of withdrawal credentials:\n- Regular withdrawals (0x01) : the validator's effective balance is capped at 32 ETH, and any balance above that is automatically swept to your withdrawal address every few days.\n- Compounding (0x02) : the validator's effective balance can grow up to 2048 ETH. Rewards compound automatically, and you earn rewards on every whole ETH above the 32 ETH minimum, so you can stake flexible amounts like 40 ETH, not just multiples of 32. Only balance above 2048 ETH is swept automatically; withdrawing anything else means manually triggering a partial withdrawal from your withdrawal address, which costs gas.\nIf you run multiple validators, you can consolidate them into a single compounding validator without exiting and re-entering the network, reducing your maintenance overhead. Consolidation is requested from your withdrawal address and is subject to processing queues. Switching a validator from 0x01 to 0x02 credentials uses this same mechanism, and cannot be reversed without fully exiting and depositing again.\nMore on staking withdrawals\nGet started on the Staking Launchpad\nThe Staking Launchpad is an open source application that will help you become a staker. It will guide you through choosing your clients, generate your keys and depositing your ETH to the staking deposit contract. A checklist is provided to make sure you've covered everything to get your validator set up safely.\nSolo validators are expected to test their setup and operational skills on the Hoodi testnet before risking funds. Remember it is important to choose a minority client as it improves the security of the network and limits your risk.\nIf you're comfortable with it, you can set up everything needed from the command line using the Staking Launchpad alone.\nChoose network\nStart staking on Hoodi testnet (opens in a new tab) Start staking on Mainnet (opens in a new tab)\nTo make things easier, check out some of the tools and guides below that can help you alongside the Staking Launchpad to get your clients set up with ease.\nSoftware tools and guide\nWhat to consider with node and client setup tools\nThere are a growing number of tools and services to help you home stake your ETH, but each come with different risks and benefits.\nAttribute indicators are used below to signal notable strengths or weaknesses a listed staking tool may have. Use this section as a reference for how we define these attributes while you’re choosing what tools to help with your staking journey.\nOpen source\nEssential code is 100% open source and available to the public to fork and use\nOpen source\nClosed source\nExplore node and client setup tools\nThere are a variety of options available to help you with your setup. Use the above indicators to help guide you through the tools below.\nProducts and services are listed as a convenience for the Ethereum community. Inclusion of a product or service does not represent an endorsement from the ethereum.org website team, or the Ethereum Foundation.\nNode tools\nRocket Pool CLI\nFrom 8 ETH\nLinux\nmacOS\nWindows\nCLI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\neth-docker\nFrom 32 ETH\nLinux\nCLI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nGet started (opens in a new tab)\nStereum\nFrom 32 ETH\nLinux\nmacOS\nWindows\nGUI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\nAvado\nFrom 10.4 ETH\nBrowser\nGUI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\nVouch + Dirk\nFrom 32 ETH\nLinux\nWindows\nCLI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\nDAppNode\nFrom 10.4 ETH\nBrowser\nGUI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\nEthereum on Arm\nFrom 32 ETH\nLinux\nCLI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nGet started (opens in a new tab)\nLaunchnodes\nFrom 32 ETH\nLinux\nmacOS\nWindows\nCLI\nAWS\nAzure\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Trustless\n- Permissionless\n- Multi-client\n- Self custody\n- Economical\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\nPlease note the importance of choosing a minority client as it improves the security of the network, and limits your risk. Tools that allow you to setup minority client are denoted as \"multi-client.\"\nKey Generators\nThese tools can be used as an alternative to the Staking Deposit CLI (opens in a new tab) to help with key generation.\nethdo\nLinux\nWindows\nCLI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Permissionless\n- Self custody\nGet started (opens in a new tab)\nWagyu Key Gen\nLinux\nmacOS\nWindows\nGUI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Permissionless\n- Self custody\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\nAvado\nBrowser\nGUI\n- Open source\n- Audited\n- Bug bounty\n- Battle tested\n- Permissionless\n- Self custody\nVisit on\n(opens in a new tab)\nGet started (opens in a new tab)\nHave a suggestion for a staking tool we missed? Check out our product listing policy to see if it would be a good fit, and to submit it for review.\nExplore home staking guides\nCoinCashew's Ethereum 2.0 Guide (opens in a new tab)\nLinux (CLI)\nSomer Esat (opens in a new tab)\nLinux (CLI)\nRocket Pool Node Operators (opens in a new tab)\nLinux, macOS (CLI)\nStakeWise Node Operators (opens in a new tab)\nLinux, Windows, MacOS (CLI)\nLido CSM Node Operators (opens in a new tab)\nLinux (CLI)\nSquad staking: home staking with fault tolerance\nDistributed validator technology (DVT) lets a single validator run across a cluster of machines instead of just one. The validator key is split into shares using distributed key generation, and a threshold of the cluster (for example, any 3 of 4 nodes) must sign together; the full key never exists on any single machine. If one machine fails, goes offline, or is misconfigured, the rest of the cluster keeps the validator attesting.\nFor home stakers this enables \"squad staking\": teaming up with friends or other community members to run validators together, removing the single points of failure of a solo setup and reducing the risk of slashing from a single misbehaving machine. Obol and SSV Network both provide production DVT implementations, used today across home staking, staking as a service, and staking pools.\nMore on distributed validator technology\nRun validators for a staking protocol\nIf you have the hardware and skills to run a node but less than 32 ETH, some staking protocols will match your validator with ETH from their pooled stakers. You post a smaller bond as collateral and run the validator on your own machine; the protocol supplies the rest of the stake, and you earn a share of the rewards.\nThis is a hybrid approach: you keep the responsibilities (and satisfaction) of operating your own hardware, but your validator operates under the protocol's smart contracts, governance, and performance rules, which is a different trust profile from staking your own ETH directly.\nLearn more about how these protocols work, including their trust assumptions and token mechanics, on the pooled staking page .\nMore ways to use your node\nYou don't need to stake at all to put node-operation skills to work. Anyone can run an Ethereum node without depositing any ETH. You get a self-verified view of the chain, your own private endpoint for sending transactions and interacting with applications, and you contribute to the health and resilience of the network. Running a node is also a good way to build experience before activating a validator, with no ETH at risk.\nFrequently asked questions\nThese are a few of the most common questions about staking that are worth knowing about.\nA validator is a virtual entity that lives on Ethereum and participates in the consensus of the Ethereum protocol. Validators are represented by a balance, public key, and other properties. A validator client is the software that acts on behalf of the validator by holding and using its private key. A single validator client can hold many key pairs, controlling many validators.\nYes. A validator with compounding (0x02) withdrawal credentials can hold an effective balance of up to 2048 ETH, while the minimum to activate remains 32 ETH. Rewards on a compounding validator are added to its stake automatically, and it earns rewards on every whole ETH above the 32 ETH minimum, so you can stake amounts that aren't multiples of 32. See Compounding and the 2048 ETH maximum .\nValidators with regular withdrawals (0x01) credentials remain capped at an effective balance of 32 ETH, with any balance above that automatically swept to the withdrawal address every few days.\nFor a compounding validator, only balance above the 2048 ETH maximum is swept automatically. To withdraw anything below that, you trigger a partial withdrawal from your withdrawal address (a transaction that costs gas), which can draw down any balance above the 32 ETH minimum. If you run multiple validators, you can also consolidate them into a single compounding validator without exiting the network.\nMore on staking withdrawals\nGoing offline when the network is finalizing properly will NOT result in slashing. Small inactivity penalties are incurred if your validator is not available to attest for a given epoch (each 6.4 minutes long), but this is very different to slashing . These penalties are slightly less than the reward you would have earned had the validator been available to attest, and losses can be earned back with approximately an equal amount of time back online again.\nNote that penalties for inactivity are proportional to how many validators are offline at the same time. In cases where a large portion of the network is all offline at once, the penalties for each of these validators will be greater than when a single validator is unavailable.\nIn extreme cases if the network stops finalizing as a result of more than a third of the validators being offline, these users will suffer what is known as a quadratic inactivity leak , which is an exponential drain of ETH from offline validator accounts. This enables the network to eventually self-heal by burning the ETH of inactive validators until their balance reaches 16 ETH, at which point they will be automatically ejected from the validator pool. The remaining online validators will eventually comprise over 2/3 the network again, satisfying the supermajority needed to once again finalize the chain.\nIn short, this can never be fully guaranteed, but if you act in good faith, run a minority client and only keep your signing keys on one machine at a time, the risk of getting slashed is nearly zero.\nThere are only a few specific ways that can result in a validator getting slashed and ejected from the network. At time of writing, the slashings that have occurred have been exclusively a product of redundant hardware setups where signing keys are stored on two separate machines at once. This can inadvertently result in a double vote from your keys, which is a slashable offense.\nRunning a supermajority client (any client used by over 2/3 the network) also holds the risk of potential slashing in the event this client has a bug that results in a chain fork. This can result in a faulty fork that gets finalized. To correct back to the intended chain would require submitting a surround vote by trying to undo a finalized block. This is also a slashable offense and can be avoided simply by running a minority client instead.\nEquivalent bugs in a minority client would never finalize and thus would never result in a surround vote, and would simply result in inactivity penalties, not slashing .\n- Learn more about the importance of running a minority client.\n- Learn more about rewards, penalties, and slashing\nIndividual clients may vary slightly in terms of performance and user interface, as each are developed by different teams using a variety of programming languages. That being said, none of them are \"best.\" All production clients are excellent pieces of software, that all perform the same core functions to sync and interact with the blockchain.\nSince all production clients provide the same basic functionality, it is actually very important that you choose a minority client , meaning any client that is NOT currently being used by a majority of validators on the network. This may sound counterintuitive, but running a majority or supermajority client puts you at an increased risk of slashing in the event of a bug in that client. Running a minority client drastically limits these risks.\nLearn more about why client diversity is critical\nAlthough a virtual private server (VPS) can be used as a replacement to home hardware, the physical access and location of your validator client does matter . Centralized cloud solutions such as Amazon Web Services or Digital Ocean allow the convenience of not having to obtain and operate hardware, at the expense of centralizing the network.\nThe more validator clients running on a single centralized cloud storage solution, the more dangerous it becomes for these users. Any event that takes these providers offline, whether by an attack, regulatory demands, or just power/internet outages, will result in every validator client that relies on this server to go offline at the same time.\nOffline penalties are proportional to how many others are offline at the same time. Using a VPS greatly increases the risk that offline penalties will be more severe, and increases your risk of quadratic leaking or slashing in the event the outage is large enough. To minimize your own risk, and the risk to the network, users are strongly encouraged to obtain and operate their own hardware.\nEvery withdrawal requires your validator to have a withdrawal address set. New stakers set this at time of key generation and deposit. Stakers from the network's early days who have not yet set a withdrawal address will need to update their withdrawal credentials before withdrawing.\nFor validators with regular withdrawals (0x01) credentials, reward payments (accumulated ETH over the initial 32) are periodically distributed to the withdrawal address automatically. For compounding (0x02) validators, rewards remain staked and compound automatically. You can withdraw any balance above 32 ETH by triggering a partial withdrawal from your withdrawal address.\nTo unlock and receive your entire balance back you must exit your validator. You can do this using your validator signing keys, or trigger it directly from your withdrawal address with an execution layer transaction, meaning your funds remain recoverable even if your signing keys are lost.\nMore on staking withdrawals\nFurther reading\n- Client diversity statistics and migration guides (opens in a new tab)\n- Helping Client Diversity (opens in a new tab) - Jim McDonald 2022\n- Client diversity on Ethereum's consensus layer (opens in a new tab) - jmcook.eth 2022\n- How To: Shop For Ethereum Validator Hardware (opens in a new tab) - EthStaker 2022\n- EIP-7870: Hardware and bandwidth recommendations (opens in a new tab)\n- The Pectra upgrade: max effective balance and more\nTest your Ethereum knowledge"}
{"url":"https://docs.lightning.engineering/the-lightning-network/multihop-payments","domain":"docs.lightning.engineering","title":"Making Payments | Builder's Guide","hash":"804f73c09d2a168857402739c753320646e9e8b0601cf2317520c29fd3d419de","tokens":965,"chars":3860,"crawler":"crawler-f6nn","verified":"exact","ts":1791171959244,"text":"Builder's Guide\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nMaking Payments\nIndividual payments are atomic, meaning they either arrive at their destination in full or they never leave the accounts of their sender. This is achieved through Hash Time-lock Contracts (HTLC), which in short make a payment to the recipient under the condition that the recipient produces the preimage, as identified by its hash.\nAll payments along the route are made to this hash, and can only be claimed if the preimage is revealed. In case the preimage is not revealed, the payment goes back to its sender. HTLCs can be settled on the blockchain, but generally are resolved between the peers no matter if they succeed or fail.\nOnce you don’t have to trust the intermediaries, you no longer even care who they are. This allows Lightning nodes to be fully anonymous, which is a huge win for privacy.\nConcretely, suppose Alice has a channel with Bob, who has a channel with Carol, who has a channel with Dave: A<->B<->C<->D . How can Alice pay Dave?\nAlice first notifies Dave that she wants to send him some money.\nIn order for Dave to accept this payment, he must generate a random number R . He keeps R secret, but hashes it and gives the hash H to Alice.\nDave gives hash H to Alice\nAlice tells Bob: “I will pay you if you can produce the preimage of H within 3 days.” In particular, she signs a transaction where for the first three days after it is broadcast, only Bob can redeem it with knowledge of R, and afterwards it is redeemable only by Alice. This transaction is called a Hash Time-Locked Contract (HTLC) and allows Alice to make a conditional promise to Bob while ensuring that her funds will not be accidentally burned if Bob never learns what R is. She gives this signed transaction to Bob, but neither of them broadcast it, because they are expecting to clear it out later.\nAlice creates HTLC with Bob\nBob, knowing that he can pull funds from Alice if he knows R, now has no issue telling Carol: “I will pay you if you can produce the preimage of H within 2 days.”\nCarol does the same, making an HTLC that will pay Dave if Dave can produce R within 1 day. However, Dave does in fact know R. Because Dave is able to pull the desired amount from Carol, Dave can consider the payment from Alice completed. Now, he has no problem telling R to Carol and Bob so that they are able to collect their funds as well.\nDave distributes R\nNow, everyone can clear out, because they have a guaranteed way to pull their deserved funds by broadcasting these HTLCs onto Bitcoin’s network (i.e. on-chain). They would prefer not to do that though, since broadcasting on-chain is more expensive, and instead settle each of these hops off chain. Alice knows that Bob can pull funds from her since he has R , so she tells Bob: “I’ll pay you, regardless of R , and in doing so we’ll terminate the HTLC so we can forget about R.” Bob does the same with Carol, and Carol with Dave.\nEveryone terminates their HTLCs\nNow, what if Dave is uncooperative and refuses to give R to Bob and Carol? Note that Dave must broadcast the transaction from Carol within 1 day, and in doing so must reveal R in order to redeem the funds. Bob and Carol can simply look at the blockchain to determine what R is and settle off-chain as well.\nWe have shown how to make a payment across the Lightning Network using only off-chain transactions, without requiring direct channel links or trusting any intermediaries. As long as there is a path from the payer to the payee, payments can be routed, just like the Internet.\nThe Payment Cycle Hashed Timelock Contract (HTLC) Payment Etymology What Makes a Good Routing Node Understanding Submarine Swaps\nPrevious Understanding Lightning Invoices\nNext The Payment Cycle\nLast updated 4 years ago\nWas this helpful?"}
{"url":"https://docs.cosmos.network/evm","domain":"docs.cosmos.network","title":"Overview - Cosmos Docs","hash":"17d8be004353aa21781cebb7018b5ad5b1078ad214766d94502c578e1d9417f7","tokens":1046,"chars":4183,"crawler":"crawler-f6nn","verified":"exact","ts":1791171961766,"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\nDocumentation\nAPI Reference\nChangelog\nAbout\nOverview\nCosmos EVM is an open-source Cosmos SDK module that embeds a full Ethereum Virtual Machine into a CometBFT-based chain. Deploy existing Solidity contracts, use standard EVM tooling, and launch a sovereign L1 with instant finality and native cross-chain support.\nUnlike rollups, Cosmos EVM chains control their own validator set, governance, and fee economics, all while preserving full Ethereum bytecode and JSON-RPC compatibility.\nGetting Started\nBuild and run your own EVM-compatible chain using the evmd reference implementation\nCosmos EVM Repository\nExplore the source code, open issues, and contribute to Cosmos EVM\nEthereum Tooling & JSON-RPC\nDeploy existing Solidity contracts and use MetaMask, Hardhat, Foundry, Remix, ethers.js, viem, and more\nCosmos-Native Capabilities\nAccess staking, governance, IBC, and other Cosmos SDK modules directly from smart contracts\nWhat you can build\nCosmos EVM is for teams that want full EVM compatibility without giving up the benefits of launching a sovereign L1. You control the entire stack: the EVM execution environment, gas model, validator set, governance rules, and which Cosmos SDK modules to include. If you already deploy to Ethereum or EVM rollups, you can deploy to a Cosmos EVM chain with no contract changes.\nChains can also run a permissioned EVM—restricting contract deployment or calls to whitelisted addresses—for use cases that require access controls at the protocol level.\nEVM Equivalent\nYour chain runs standard Ethereum bytecode and behaves like any Ethereum network: deploy Solidity contracts with Hardhat, Foundry, or Remix; connect MetaMask or any EVM wallet; use ethers.js, viem, or web3.js without changes. See the tooling and resources page for a list of supported tools.\nCosmos EVM implements the full Ethereum JSON-RPC API and supports all common transaction formats: EIP-155 (chain ID protection), EIP-1559 (dynamic fees), EIP-2930 (access lists), and EIP-7702 (EOA code delegation). Because Cosmos EVM chains are sovereign L1 chains, they do not support L2-specific features like blob transactions ( EIP-4844 ) and other rollup-oriented primitives.\nEthereum with more\nIf you know Solidity, you already know how to build on Cosmos EVM. Contracts compile and deploy the same way , the same opcodes are available , and the same libraries work. The differences are additions, not substitutions.\n- Instant finality: On Ethereum, transactions reach probabilistic finality over multiple blocks. On Cosmos EVM, transactions are final after one block (~1–2 seconds) via CometBFT with no possibility of reorganization. Your contracts don’t need to account for reorgs.\n- Fee distribution: Both use EIP-1559 dynamic fees. The base fee on Cosmos EVM is distributed to validators and delegators rather than burned—same fee mechanics for the developer, different economics for the chain.\n- Native cross-chain: Rather than relying on external bridge contracts, Cosmos EVM has IBC (Inter-Blockchain Communication) built into the protocol. Cross-chain token transfers are a first-class feature, accessible from Solidity via the IBC precompile .\n- Precompiles: Cosmos EVM exposes protocol-level functionality as precompiled contracts at fixed addresses. From Solidity, you can call into staking, distribution, governance, bank, IBC transfers (ICS-20), slashing, vesting, and address conversion utilities the same way you’d call any other contract. See the precompiles reference for the full list of addresses and interfaces.\n- EIP-712 signing: MetaMask and other EVM wallets can sign Cosmos SDK transactions—including governance votes, staking operations, and more—using the standard eth_signTypedData method. No separate Cosmos wallet required.\nGetting started\nThe quickest way to get started is running the example chain locally — it takes less than 3 minutes and requires only Go and Make.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://ethresear.ch/t/trust-minimized-transaction-simulation-using-state-proofs/23857","domain":"ethresear.ch","title":"Trust minimized transaction simulation using state proofs - Security - Ethereum Research","hash":"9537c08358ecbc47b9fb5d9f4a2cfb9ad1b1878e6846b9c35fa2051b82470007","tokens":4702,"chars":18805,"crawler":"crawler-f6nn","verified":"exact","ts":1791171964904,"text":"Ethereum Research\nTrust minimized transaction simulation using state proofs\nSecurity\nSednaoui\nJanuary 15, 2026, 7:54am\n1\nSummary\nTransaction simulation is critical for wallet security. Users need to preview what a transaction will do before signing. But current simulation approaches require blindly trusting RPC providers for state data, creating a dangerous single point of failure. We explore a trust minimized simulation approach using Merkle Patricia Trie proofs and multi-node consensus to cryptographically verify the prestate before execution, eliminating the need to trust any single RPC provider while remaining practical for production wallets.\nThe Simulation Trust Problem\nUsers can’t read raw transaction data. A transaction is encoded calldata: bytes that specify contract calls, parameters, and state changes. Users have no way to verify what a transaction actually does just by looking at it. This is the blind signing problem : users must trust their wallet to tell them what they’re signing.\nTransaction simulation emerged as the solution. Before users sign, wallets simulate the transaction to show what tokens will be transferred, what approvals will be granted, what contract state changes will occur, and whether the transaction will revert. This prevents users from signing malicious transactions that drain funds, grant dangerous approvals, or behave unexpectedly. Simulation transforms blind signing into informed signing where users see decoded, human-readable results before they sign.\nBut there’s a fundamental trust issue: Most wallets don’t run simulations themselves. Instead, they rely on third-party simulation APIs: black box services where you send a transaction and receive back decoded results showing what will happen. But here’s what actually happens behind the scenes: these services typically call trace APIs (like debug_traceTransaction or trace_call ) from third-party RPC providers (Infura, Alchemy, etc.), receive execution traces from those providers, decode and format the results, then return them to the wallet.\nThis creates multiple layers of trust: you’re trusting the simulation service’s decoding and display logic, which is trusting the RPC provider’s state data, which is trusting their EVM execution and trace generation. The simulation service doesn’t typically run its own nodes or execution - it’s aggregating and formatting data from third-party infrastructure. There’s no way to verify any of this. Even wallets that do run simulations locally still face the core problem: they fetch state and execution traces from RPC providers and trust them completely.\nThe infrastructure layer has centralized around a handful of RPC providers (Infura, Alchemy, QuickNode) serving the majority of users. Meanwhile, running your own node is resource-intensive, and mobile/browser wallets can’t run full nodes at all. This centralization accelerates as mobile-first wallets dominate adoption and users prioritize convenience.\nA Concrete Attack\nAlice sends Bob a transaction to approve: supposedly transferring 50,000 USDC to charity. Bob can’t read the encoded transaction bytes, so he relies on his wallet’s simulation.\nBob’s wallet uses a compromised simulation API. The API returns results showing “Transfer 50,000 USDC to Charity (0x1234…)”. Bob reviews it, sees his donation to a recognized charity, and signs.\nBut the simulation lied. The actual transaction calldata drains Bob’s entire USDC balance to an attacker’s address (0xabcd…). The malicious service showed fake execution traces while the real transaction does something completely different.\nBob was blind signing with extra steps. Even a hardware wallet wouldn’t help because it can only verify Bob is signing what was sent to it, not whether the simulation accurately represents what the transaction will do. The attack works because the simulation service is a complete black box with no way to verify the results.\nThis isn’t theoretical. RPC providers get compromised through infrastructure breaches, DNS hijacking, MitM attacks, and malicious browser extensions. A single compromised simulation service could show fake simulations to millions of users across hundreds of wallets.\nWhy Not Light Clients?\nLight clients are the principled solution: verify state without downloading the full chain. But they face significant practical barriers including resource requirements prohibitive for mobile, long sync times, complex WASM compilation for browser support, and protocols still in active development. Many L2s lack mature light client implementations entirely. We need a practical solution today for production wallets.\nOur Approach: Verified Prestate Simulation\nVerify the prestate cryptographically using Merkle Patricia Trie proofs and multi-node consensus, then execute the transaction locally with revm to generate our own execution traces.\nThe mechanism:\n-\nFetch prestate : Use debug_traceCall with prestateTracer to discover required state\n-\nEstablish consensus : Query multiple RPC nodes for state root at the simulation block\n-\nRequire unanimous agreement : All nodes must agree on state root, otherwise reject the simulation\n-\nRequest proofs : Call eth_getProof for all accounts and storage in prestate\n-\nVerify proofs locally : Walk MPT proofs, verify hashes, confirm values\n-\nExecute locally with revm : Only if all proofs validate, execute transaction with verified state using revm (Rust EVM implementation)\n-\nGenerate our own traces : Produce execution traces, state changes, and results from our own EVM execution\nSimulation Flow Diagram 637×560 9.62 KB\nTechnical Implementation\nStep 1: Discover Required State\nUse debug_traceCall with the prestateTracer to discover exactly what state the transaction will access. This returns the complete prestate: all accounts that will be touched, their balances and nonces, all storage slots that will be read, and code for any contracts executed.\nThis discovery enables local simulation without a full node and tells us what state to verify using MPT proofs.\nStep 2: Establish State Root Consensus\nQuery N independent RPC nodes to establish consensus on the state root at the simulation block. For each verification node, call eth_getBlockByNumber and extract the stateRoot . All verification nodes must agree on the state root. If even one node disagrees, reject the simulation entirely since disagreement indicates you’re being targeted.\nThis consensus mechanism prevents a malicious simulation node from lying about the prestate. Because the prestate is verified using the consensus state root, to lie about the prestate it has to control all of your verification nodes.\nStep 3: Request and Verify Cryptographic Proofs\nFor each account and storage slot in the prestate, call eth_getProof . The response contains Merkle Patricia Trie proofs that we verify locally by walking through the proof nodes, hashing each node, and confirming values match what was claimed. Account proofs verify against the global state root; storage proofs verify against the account’s storageHash. For accounts that don’t exist yet, we verify they’re actually not deployed, and trust the local REVM execution for their state.\nStep 4: Execute Locally with Revm\nOnly after all proofs validate successfully, execute the transaction locally using revm (Rust EVM implementation) with the verified prestate. This is critical: we don’t just verify state and trust someone else’s execution. We run our own EVM to generate execution traces, state changes, and event logs.\nThe execution happens entirely on the user’s device with verified inputs. REVM is pinned to a known version with auditable upgrades, unlike opaque node provider APIs where you have no visibility into what code is running or when it changes.\nIf any proof fails to verify, reject the entire simulation and either retry with different nodes or alert the user to a potential attack.\nSecurity Properties\nThe threat model assumes adversarial RPC providers and simulation services. The approach maintains decentralization by requiring unanimous agreement on the state root across all verification nodes. If even a single node disagrees, the system detects the manipulation and rejects the simulation. The proofs are deterministic and transparent; anyone can verify the verification.\nTrade-offs and Limitations\nThe approach requires access to multiple independent RPC providers for the consensus mechanism. It depends on RPC support for eth_getProof (widely supported) and debug_traceCall with prestateTracer (less common). The unanimous agreement requirement means that if even one verification node is down or returns a different state root, the simulation will be rejected. This trades off availability for security.\nPrestate completeness verification is not yet implemented. The current implementation verifies that provided prestate is accurate, but doesn’t verify it’s complete. A malicious node could provide accurate proofs for incomplete prestate (hiding critical storage slots). The planned defense is to verify post-execution that no storage was accessed beyond the verified prestate, but this is future work.\nConditional flows in smart contracts can trick the simulation. A malicious contract could behave differently based on conditions like block.timestamp , msg.sender , or other state variables, causing the simulation to show benign behavior while the actual onchain execution does something malicious. Another vector is MEV, where the transaction order in a block can change from what the simulation resulted. These are a general problem with all transaction simulation approaches, not specific to state verification. We’re interested in feedback on potential mitigations for this attack vector.\nThe approach works for EVM chains that support eth_getProof : Ethereum mainnet and most L2s. Chains with different state representations would need adapted verification logic.\nDiscussion\nThis demonstrates that trust minimized transaction simulation is practical today without waiting for light client maturity. It’s not a perfect solution, but it eliminates the single point of trust that exists in nearly every wallet today.\nOn the general approach: Are there fundamental issues we’re missing? The mechanism relies on eth_getProof returning valid Merkle Patricia Trie proofs and consensus on state roots across independent nodes. We’d appreciate critical feedback on whether this foundation is sound for production wallet simulation or if there are attack vectors we haven’t considered.\nOn consensus design: We currently require unanimous agreement across all verification nodes for the state root. If even one node disagrees, the simulation is rejected. The reasoning is that in theory, there’s no legitimate reason for verification nodes to disagree on the state root unless you’re being targeted. This prioritizes security over availability. Is this the right trade-off for production wallets, or should there be configurability for users who prefer different security/availability balances?\nOn light client comparison: How does this compare to running a full light client for simulation? We see this as a pragmatic solution that works today across all platforms (mobile, browser, desktop). Light clients provide stronger guarantees by following the consensus layer directly, but face adoption barriers. Are there specific security properties we’re sacrificing that make this approach unsuitable for wallet simulation?\nLooking forward to your feedback.\n7 Likes\nmmsaki\nJanuary 29, 2026, 4:13am\n2\nThis is such a profound way of using eth_getProof . I had no idea that this would be a good usecase so thank you for posting this. Still have to read this a few time to fully understand the problem with trusting RPC providers.\nFrom my experience I notice that many providers do not serve the debug_traceCall method publicly but not sure about your experience getting debug traces from rpc providers .\n1 Like\nthegaram33\nJanuary 29, 2026, 12:51pm\n3\nWhy not just simulate/trace the transaction on N independent RPC nodes then? What is the benefit of local re-execution?\nAlso, two additional ideas that you might want to consider:\n- The RPC provider could provide a validity proof of correct simulation, along with the result. I recall some team is already working on this.\n- Another concern is that the simulated result might not match the actual execution result, if the transaction’s pre-state changes. Smart accounts could execute pre- and post-execution checks to deal with this.\n1 Like\nSednaoui\nJanuary 29, 2026, 4:43pm\n4\nSimulating on multiple RPCs gives you consensus on the result, but not proof of correct execution. A few issues:\n-\nTrace quality: eth_debugTraceCall doesn’t give you full execution traces. Local execution with REVM gives you complete control over trace generation. You can extract exactly what you need for verification/display.\n-\nSeparation of concerns: state proofs verify the INPUT is correct (verified state). Local execution verifies the EXECUTION is correct. Cleaner trust model.\n-\nAccess to debug_traceCall is usually restricted and often gated behind paid subscriptions at RPC providers, which makes executing the same request on 5 or more independent nodes challenging. By contrast, eth_getProof is widely supported, including by public nodes, enabling straightforward verification across multiple independent providers. (cc @mmsaki , yes it is challenging to find rpc providers with debug_traceCall enabled)\nThe key insight is that verifying state gives you a known good starting point . Local execution gives you a known good process . Together are end-to-end verification.\nYes! this is interesting. We know a few teams exploring zk-proven execution and will keep an eye when they release.\nThis is a valid concern for simulation regardless of our approach. Simulation happens at block N, execution at block N+X. State can change. This is where execution time protection comes in. You are right, we are using this approach specifically for Safe Smart Accounts, where guards can enforce invariants at execution time and implement pre/post execution checks.\nEl_clou\nMay 3, 2026, 5:56pm\n5\nI’m brand new to this and I don’t know coding at all. But here in Canada when we e-transfer money (CAD) to someone else we’re asked to insert a question with a unique answer or code that the recipient will answer to confirm and accept the transaction. Maybe there’s a way we could implement this, instead of always transferring a test transaction prior to our real transaction which brings more gas fees. You would have only 1 transaction. The idea would be once the sender request the transaction the amount is locked in ( for a periods of time could be like 24-48 hrs or something) or until the recipient approves with the answer to the question.\nMicahZoltu\nMay 4, 2026, 5:56am\n6\nYou can implement this easily on a contract-based blockchain with a mailbox pattern. When you send money to someone, you send it to a contract that where either the recipient can withdraw from it, or the sender can withdraw from it after some delay. This way if the sender typos the transfer, the recipient will be unable to withdraw and then after the delay the sender can take the money back.\nHowever, this is very off topic for this thread.\n1 Like\nowanikin\nJune 5, 2026, 3:48pm\n7\nHey @Sednaoui\nI’m doing a focused research on EIP-7999 / Universal Overflow design ethresear.ch/t/gas-overflow-for-multidimensional-fee-markets/24766 , specifically around contract and infra compatibility assumptions around gas observability (gasleft(), CALL gas forwarding, retained-gas patterns, etc.).\nI’m currently collecting real-world perspectives from protocol engineers, account abstraction / infra teams, and smart contract developers to understand something quite specific:\nWhether Universal Overflow preserves the actual invariants developers rely on today , or mainly preserves a simplified model that looks correct at the protocol level but diverges from production usage patterns.\nFor example, in infra-heavy systems (bundlers / paymasters / solvers), gas is often treated less as a “remaining execution metric” and more as a budgeting and safety boundary across nested execution paths . I’m trying to understand whether that mental model breaks under multidimensional gas + overflow semantics.\nIf you have a moment, I’d really value your perspective on:\n-\nwhether gas observability is actually relied on for correctness in your stack (vs just estimation / safety margins),\n-\nand whether Universal Overflow would change any assumptions in bundling / execution simulation.\nI’m essentially aggregating perspectives across different implementation contexts (clients, infra, and contracts) to see where the real fragility is.\nWould you be open to a quick 15–20 min chat, or I can also just take your thoughts here if easier.\nThanks,\nIfeoluwa\nstkux\nOctober 1, 2026, 10:45am\n8\nVerifying prestate with MPT proofs and then executing locally is the right decomposition for wallet simulation; @thegaram33 (trace quality, input vs execution trust, and eth_getProof being far more available than debug_traceCall ) matches what we’ve run into in practice as well — cc @mmsaki on the debug-API gate.\nA few concrete contact points with Colibri (stateless prover/verifier; public specs ):\n- State-root trust. Your Step 2 uses unanimous stateRoot agreement across N RPCs. Colibri instead verifies the EL header (incl. stateRoot ) via Sync-Committee aggregates / light-client-style proofs, then verifies account+storage Patricia proofs against that root (same shape as eth_getProof ). That doesn’t remove all assumptions (bootstrap / weak subjectivity, prover availability), but it changes the failure mode from “all my chosen RPCs collude on a root” to “break consensus attestation or forge Merkle proofs.”\n- Local simulation. colibri_simulateTransaction rides the same Call-Proof path as eth_call / eth_estimateGas : proven accounts/storage (+ code vs codeHash ), local EVM, Tenderly-style state diffs / logs / access list. So the “don’t trust someone else’s trace API” goal is shared; the discovery step differs (we don’t require prestateTracer as the primary trust path).\n- Prestate completeness. You flag incomplete-but-accurate prestate as future work. Worth comparing to lazy fetch + prove-after-access / re-execute-on-mismatch — curious how you’d surface a mid-sim proof failure in wallet UX.\n- Light clients. Agree on mobile/browser constraints. Colibri’s difference from continuous light clients is request-driven verification; interested whether that still counts as “unsuitable” for your threat model, or as a drop-in upgrade for Steps 2–3. Colibri is designed for exactly this use case: full verification at the edge, while using a minimum on ressources (no sync, no p2p, no state storage)."}
{"url":"https://developer.bitcoin.org/examples/intro.html","domain":"developer.bitcoin.org","title":"Introduction — Bitcoin","hash":"805068a19a78ff337c1d4dbe4a176a5540b4e212f772cf3b965145551e89e673","tokens":718,"chars":2870,"crawler":"crawler-f6nn","verified":"exact","ts":1791171967253,"text":"-\nBitcoin\n-\nExamples\n- Introduction\n« Examples\nTesting Applications »\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\nExamples\nNext topic\nTesting Applications\nContribute\nEdit Page\nIntroduction ¶\nThe following guide aims to provide examples to help you start building Bitcoin-based applications. To make the best use of this document, you may want to install the current version of Bitcoin Core, either from source or from a pre-compiled executable .\nOnce installed, you’ll have access to three programs: bitcoind , bitcoin-qt , and bitcoin-cli .\n-\nbitcoin-qt provides a combination full Bitcoin peer and wallet frontend. From the Help menu, you can access a console where you can enter the RPC commands used throughout this document.\n-\nbitcoind is more useful for programming: it provides a full peer which you can interact with through RPCs to port 8332 (or 18332 for testnet).\n-\nbitcoin-cli allows you to send RPC commands to bitcoind from the command line. For example, bitcoin-cli help\nAll three programs get settings from bitcoin.conf in the Bitcoin application directory:\n-\nWindows: %APPDATA%\\Bitcoin\\\n-\nOSX: $HOME/Library/Application Support/Bitcoin/\n-\nLinux: $HOME/.bitcoin/\nTo use bitcoind and bitcoin-cli , you will need to add a RPC password to your bitcoin.conf file. Both programs will read from the same file if both run on the same system as the same user, so any long random password will work:\nrpcpassword = change_this_to_a_long_random_password\nYou should also make the bitcoin.conf file only readable to its owner. On Linux, Mac OSX, and other Unix-like systems, this can be accomplished by running the following command in the Bitcoin application directory:\nchmod 0600 bitcoin . conf\nFor development, it’s safer and cheaper to use Bitcoin’s test network (testnet) or regression test mode (regtest) described below.\nQuestions about Bitcoin use are best sent to the BitcoinTalk forum and IRC channels . Errors or suggestions related to documentation on Bitcoin.org can be submitted as an issue or posted to the bitcoin-documentation mailing list .\nIn the following documentation, some strings have been shortened or wrapped: “[…]” indicates extra data was removed, and lines ending in a single backslash “\\” are continued below. If you hover your mouse over a paragraph, cross-reference links will be shown in blue. If you hover over a cross-reference link, a brief definition of the term will be displayed in a tooltip.\n×\nDonate to Bitcoin.org\nUse this QR code or address below\n3E8ociqZa9mZUSwGdSmAEMAoAxBK3FNDcd"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/api/utils","domain":"docs.openzeppelin.com","title":"Utils | OpenZeppelin Docs","hash":"d5be052388ba6dc9862906340047075a584ec0ab8c017fd0777113f9d57305e2","tokens":9987,"chars":39945,"crawler":"crawler-f6nn","verified":"exact","ts":1791171970472,"text":"Home Forum Website Impact\nOpenZeppelin Contracts API Reference\nUtils\nSmart contract utils utilities and implementations\nOpen in Claude\nMiscellaneous contracts and libraries containing utility functions you can use to improve security, work with new data types, or safely use low-level primitives.\n- Math , SignedMath : Implementation of various arithmetic functions.\n- SafeCast : Checked downcasting functions to avoid silent truncation.\n- Nonces : Utility for tracking and verifying address nonces that only increment.\n- NoncesKeyed : Alternative to Nonces , that support keyed nonces following ERC-4337 specifications .\n- Pausable : A common emergency response mechanism that can pause functionality while a remediation is pending.\n- ReentrancyGuard : A modifier that can prevent reentrancy during certain functions.\n- ReentrancyGuardTransient : Variant of ReentrancyGuard that uses transient storage ( EIP-1153 ).\n- ERC165 , ERC165Checker : Utilities for inspecting interfaces supported by contracts.\n- Accumulators : A library for merging an arbitrary dynamic number of bytes buffers.\n- BitMaps : A simple library to manage boolean value mapped to a numerical index in an efficient way.\n- Checkpoints : A data structure to store values mapped to a strictly increasing key. Can be used for storing and accessing values over time.\n- CircularBuffer : A data structure to store the last N values pushed to it.\n- DoubleEndedQueue : An implementation of a double ended queue whose values can be added or removed from both sides. Useful for FIFO and LIFO structures.\n- EnumerableMap : A type like Solidity’s mapping , but with key-value enumeration : this will let you know how many entries a mapping has, and iterate over them (which is not possible with mapping ).\n- EnumerableSet : Like EnumerableMap , but for sets . Can be used to store privileged accounts, issued IDs, etc.\n- Heap : A library that implements a binary heap in storage.\n- MerkleTree : A library with Merkle Tree data structures and helper functions.\n- Address : Collection of functions for overloading Solidity’s address type.\n- Arrays : Collection of functions that operate on arrays .\n- Base58 : On-chain base58 encoding and decoding.\n- Base64 : On-chain base64 and base64URL encoding according to RFC-4648 .\n- Blockhash : A library for accessing historical block hashes beyond the standard 256 block limit utilizing EIP-2935’s historical blockhash functionality.\n- Bytes : Common operations on bytes objects.\n- CAIP2 , CAIP10 : Libraries for formatting and parsing CAIP-2 and CAIP-10 identifiers.\n- Calldata : Helpers for manipulating calldata.\n- Comparators : A library that contains comparator functions to use with the Heap library.\n- Context : A utility for abstracting the sender and calldata in the current execution context.\n- Create2 : Wrapper around the CREATE2 EVM opcode for safe use without having to deal with low-level assembly.\n- InteroperableAddress : Library for formatting and parsing ERC-7930 interoperable addresses.\n- LowLevelCall : Collection of functions to perform calls with low-level assembly.\n- Memory : A utility library to manipulate memory.\n- Multicall : Abstract contract with a utility to allow batching together multiple calls in a single transaction. Useful for allowing EOAs to perform multiple operations at once.\n- Packing : A library for packing and unpacking multiple values into bytes32.\n- Panic : A library to revert with Solidity panic codes .\n- RelayedCall : A library for performing calls that use minimal and predictable relayers to hide the sender.\n- RLP : Library for encoding and decoding data in Ethereum’s Recursive Length Prefix format.\n- ShortStrings : Library to encode (and decode) short strings into (or from) a single bytes32 slot for optimizing costs. Short strings are limited to 31 characters.\n- SlotDerivation : Methods for deriving storage slot from ERC-7201 namespaces as well as from constructions such as mapping and arrays.\n- StorageSlot : Methods for accessing specific storage slots formatted as common primitive types.\n- Strings : Common operations for strings formatting.\n- Time : A library that provides helpers for manipulating time-related objects, including a Delay type.\n- TransientSlot : Primitives for reading from and writing to transient storage (only value types are currently supported).\nBecause Solidity does not support generic types, EnumerableMap and EnumerableSet are specialized to a limited number of key-value types.\nMath\nSignedMath\nSafeCast\nSecurity\nNonces\nNoncesKeyed\nPausable\nReentrancyGuard\nReentrancyGuardTransient\nIntrospection\nThis set of interfaces and contracts deal with type introspection of contracts, that is, examining which functions can be called on them. This is usually referred to as a contract’s interface .\nEthereum contracts have no native concept of an interface, so applications must usually simply trust that they are not making an incorrect call. For trusted setups this is a non-issue, but often unknown and untrusted third-party addresses need to be interacted with. There may not even be any direct calls to them! (e.g. ERC-20 tokens may be sent to a contract that lacks a way to transfer them out of it, locking them forever). In these cases, a contract declaring its interface can be very helpful in preventing errors.\nIERC165\nERC165\nERC165Checker\nData Structures\nAccumulators\nBitMaps\nCheckpoints\nCircularBuffer\nDoubleEndedQueue\nEnumerableMap\nEnumerableSet\nHeap\nMerkleTree\nLibraries\nAddress\nArrays\nBase58\nBase64\nBlockhash\nBytes\nCAIP10\nCAIP2\nCalldata\nComparators\nContext\nCreate2\nInteroperableAddress\nLowLevelCall\nMemory\nMulticall\nPacking\nPanic\nRelayedCall\nRLP\nShortStrings\nSlotDerivation\nStorageSlot\nStrings\nTime\nTransientSlot\nAddress\nimport \"@openzeppelin/contracts/utils/Address.sol\" ;\nCollection of functions related to the address type\nFunctions\n- sendValue(recipient, amount)\n- functionCall(target, data)\n- functionCallWithValue(target, data, value)\n- functionStaticCall(target, data)\n- functionDelegateCall(target, data)\n- verifyCallResultFromTarget(target, success, returndata)\n- verifyCallResult(success, returndata)\nErrors\n- AddressEmptyCode(target)\nsendValue(address payable recipient, uint256 amount)\ninternal\n#\nReplacement for Solidity's transfer : sends amount wei to\nrecipient , forwarding all available gas and reverting on errors.\nEIP1884 increases the gas cost\nof certain opcodes, possibly making contracts go over the 2300 gas limit\nimposed by transfer , making them unable to receive funds via\ntransfer . Address.sendValue removes this limitation.\nLearn more .\nbecause control is transferred to recipient , care must be\ntaken to not create reentrancy vulnerabilities. Consider using\nReentrancyGuard or the\nchecks-effects-interactions pattern .\nfunctionCall(address target, bytes data) → bytes\ninternal\n#\nPerforms a Solidity function call using a low level call . A\nplain call is an unsafe replacement for a function call: use this\nfunction instead.\nIf target reverts with a revert reason or custom error, it is bubbled\nup by this function (like regular Solidity function calls). However, if\nthe call reverted with no returned reason, this function reverts with a\nErrors.FailedCall error.\nReturns the raw returned data. To convert to the expected return value,\nuse abi.decode .\nRequirements:\n- target must be a contract.\n- calling target with data must not revert.\nfunctionCallWithValue(address target, bytes data, uint256 value) → bytes\ninternal\n#\nSame as functionCall ,\nbut also transferring value wei to target .\nRequirements:\n- the calling contract must have an ETH balance of at least value .\n- the called Solidity function must be payable .\nfunctionStaticCall(address target, bytes data) → bytes\ninternal\n#\nSame as functionCall ,\nbut performing a static call.\nfunctionDelegateCall(address target, bytes data) → bytes\ninternal\n#\nSame as functionCall ,\nbut performing a delegate call.\nverifyCallResultFromTarget(address target, bool success, bytes returndata) → bytes\ninternal\n#\nTool to verify that a low level call to smart-contract was successful, and reverts if the target\nwas not a contract or bubbling up the revert reason (falling back to Errors.FailedCall ) in case\nof an unsuccessful call.\nThis function is DEPRECATED and may be removed in the next major release.\nverifyCallResult(bool success, bytes returndata) → bytes\ninternal\n#\nTool to verify that a low level call was successful, and reverts if it wasn't, either by bubbling the\nrevert reason or with a default Errors.FailedCall error.\nAddressEmptyCode(address target)\nerror\n#\nThere's no code at target (it is not a contract).\nArrays\nimport \"@openzeppelin/contracts/utils/Arrays.sol\" ;\nCollection of functions related to array types.\nFunctions\n- sort(array, comp)\n- sort(array)\n- sort(array, comp)\n- sort(array)\n- sort(array, comp)\n- sort(array)\n- findUpperBound(array, element)\n- lowerBound(array, element)\n- upperBound(array, element)\n- lowerBoundMemory(array, element)\n- upperBoundMemory(array, element)\n- slice(array, start)\n- slice(array, start, end)\n- slice(array, start)\n- slice(array, start, end)\n- slice(array, start)\n- slice(array, start, end)\n- splice(array, start)\n- splice(array, start, end)\n- replace(array, pos, replacement)\n- replace(array, pos, replacement, offset, length)\n- splice(array, start)\n- splice(array, start, end)\n- replace(array, pos, replacement)\n- replace(array, pos, replacement, offset, length)\n- splice(array, start)\n- splice(array, start, end)\n- replace(array, pos, replacement)\n- replace(array, pos, replacement, offset, length)\n- unsafeAccess(arr, pos)\n- unsafeMemoryAccess(arr, pos)\n- unsafeSetLength(array, len)\nsort(uint256[] array, function (uint256,uint256) pure returns (bool) comp) → uint256[]\ninternal\n#\nSort an array of uint256 (in memory) following the provided comparator function.\nThis function does the sorting \"in place\", meaning that it overrides the input. The object is returned for\nconvenience, but that returned value can be discarded safely if the caller has a memory pointer to the array.\nthis function's cost is O(n · log(n)) in average and O(n²) in the worst case, with n the length of the\narray. Using it in view functions that are executed through eth_call is safe, but one should be very careful\nwhen executing this as part of a transaction. If the array being sorted is too large, the sort operation may\nconsume more gas than is available in a block, leading to potential DoS.\nConsider memory side-effects when using custom comparator functions that access memory in an unsafe way.\nsort(uint256[] array) → uint256[]\ninternal\n#\nVariant of Arrays.sort that sorts an array of uint256 in increasing order.\nsort(address[] array, function (address,address) pure returns (bool) comp) → address[]\ninternal\n#\nSort an array of address (in memory) following the provided comparator function.\nThis function does the sorting \"in place\", meaning that it overrides the input. The object is returned for\nconvenience, but that returned value can be discarded safely if the caller has a memory pointer to the array.\nthis function's cost is O(n · log(n)) in average and O(n²) in the worst case, with n the length of the\narray. Using it in view functions that are executed through eth_call is safe, but one should be very careful\nwhen executing this as part of a transaction. If the array being sorted is too large, the sort operation may\nconsume more gas than is available in a block, leading to potential DoS.\nConsider memory side-effects when using custom comparator functions that access memory in an unsafe way.\nsort(address[] array) → address[]\ninternal\n#\nVariant of Arrays.sort that sorts an array of address in increasing order.\nsort(bytes32[] array, function (bytes32,bytes32) pure returns (bool) comp) → bytes32[]\ninternal\n#\nSort an array of bytes32 (in memory) following the provided comparator function.\nThis function does the sorting \"in place\", meaning that it overrides the input. The object is returned for\nconvenience, but that returned value can be discarded safely if the caller has a memory pointer to the array.\nthis function's cost is O(n · log(n)) in average and O(n²) in the worst case, with n the length of the\narray. Using it in view functions that are executed through eth_call is safe, but one should be very careful\nwhen executing this as part of a transaction. If the array being sorted is too large, the sort operation may\nconsume more gas than is available in a block, leading to potential DoS.\nConsider memory side-effects when using custom comparator functions that access memory in an unsafe way.\nsort(bytes32[] array) → bytes32[]\ninternal\n#\nVariant of Arrays.sort that sorts an array of bytes32 in increasing order.\nfindUpperBound(uint256[] array, uint256 element) → uint256\ninternal\n#\nSearches a sorted array and returns the first index that contains\na value greater or equal to element . If no such index exists (i.e. all\nvalues in the array are strictly less than element ), the array length is\nreturned. Time complexity O(log n).\nThe array is expected to be sorted in ascending order, and to\ncontain no repeated elements.\nDeprecated. This implementation behaves as Arrays.lowerBound but lacks\nsupport for repeated elements in the array. The Arrays.lowerBound function should\nbe used instead.\nlowerBound(uint256[] array, uint256 element) → uint256\ninternal\n#\nSearches an array sorted in ascending order and returns the first\nindex that contains a value greater or equal than element . If no such index\nexists (i.e. all values in the array are strictly less than element ), the array\nlength is returned. Time complexity O(log n).\nSee C++'s lower_bound .\nupperBound(uint256[] array, uint256 element) → uint256\ninternal\n#\nSearches an array sorted in ascending order and returns the first\nindex that contains a value strictly greater than element . If no such index\nexists (i.e. all values in the array are strictly less than element ), the array\nlength is returned. Time complexity O(log n).\nSee C++'s upper_bound .\nlowerBoundMemory(uint256[] array, uint256 element) → uint256\ninternal\n#\nSame as Arrays.lowerBound , but with an array in memory.\nupperBoundMemory(uint256[] array, uint256 element) → uint256\ninternal\n#\nSame as Arrays.upperBound , but with an array in memory.\nslice(address[] array, uint256 start) → address[]\ninternal\n#\nCopies the content of array , from start (included) to the end of array into a new address array in\nmemory.\nreplicates the behavior of Javascript's Array.slice\nslice(address[] array, uint256 start, uint256 end) → address[]\ninternal\n#\nCopies the content of array , from start (included) to end (excluded) into a new address array in\nmemory. The end argument is truncated to the length of the array .\nreplicates the behavior of Javascript's Array.slice\nslice(bytes32[] array, uint256 start) → bytes32[]\ninternal\n#\nCopies the content of array , from start (included) to the end of array into a new bytes32 array in\nmemory.\nreplicates the behavior of Javascript's Array.slice\nslice(bytes32[] array, uint256 start, uint256 end) → bytes32[]\ninternal\n#\nCopies the content of array , from start (included) to end (excluded) into a new bytes32 array in\nmemory. The end argument is truncated to the length of the array .\nreplicates the behavior of Javascript's Array.slice\nslice(uint256[] array, uint256 start) → uint256[]\ninternal\n#\nCopies the content of array , from start (included) to the end of array into a new uint256 array in\nmemory.\nreplicates the behavior of Javascript's Array.slice\nslice(uint256[] array, uint256 start, uint256 end) → uint256[]\ninternal\n#\nCopies the content of array , from start (included) to end (excluded) into a new uint256 array in\nmemory. The end argument is truncated to the length of the array .\nreplicates the behavior of Javascript's Array.slice\nsplice(address[] array, uint256 start) → address[]\ninternal\n#\nMoves the content of array , from start (included) to the end of array to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:].\nThis function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\nsplice(address[] array, uint256 start, uint256 end) → address[]\ninternal\n#\nMoves the content of array , from start (included) to end (excluded) to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:end]. The\nend argument is truncated to the length of the array .\nThis function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\nreplace(address[] array, uint256 pos, address[] replacement) → address[]\ninternal\n#\nReplaces elements in array starting at pos with all elements from replacement .\nParameters are clamped to valid ranges (e.g. pos is clamped to [0, array.length] ).\nIf pos >= array.length , no replacement occurs and the array is returned unchanged.\nThis function modifies the provided array in place.\nreplace(address[] array, uint256 pos, address[] replacement, uint256 offset, uint256 length) → address[]\ninternal\n#\nReplaces elements in array starting at pos with elements from replacement starting at offset .\nCopies at most length elements from replacement to array .\nParameters are clamped to valid ranges (i.e. pos is clamped to [0, array.length] , offset is\nclamped to [0, replacement.length] , and length is clamped to min(length, replacement.length - offset, array.length - pos) ). If pos >= array.length or offset >= replacement.length , no replacement occurs\nand the array is returned unchanged.\nThis function modifies the provided array in place.\nsplice(bytes32[] array, uint256 start) → bytes32[]\ninternal\n#\nMoves the content of array , from start (included) to the end of array to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:].\nThis function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\nsplice(bytes32[] array, uint256 start, uint256 end) → bytes32[]\ninternal\n#\nMoves the content of array , from start (included) to end (excluded) to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:end]. The\nend argument is truncated to the length of the array .\nThis function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\nreplace(bytes32[] array, uint256 pos, bytes32[] replacement) → bytes32[]\ninternal\n#\nReplaces elements in array starting at pos with all elements from replacement .\nParameters are clamped to valid ranges (e.g. pos is clamped to [0, array.length] ).\nIf pos >= array.length , no replacement occurs and the array is returned unchanged.\nThis function modifies the provided array in place.\nreplace(bytes32[] array, uint256 pos, bytes32[] replacement, uint256 offset, uint256 length) → bytes32[]\ninternal\n#\nReplaces elements in array starting at pos with elements from replacement starting at offset .\nCopies at most length elements from replacement to array .\nParameters are clamped to valid ranges (i.e. pos is clamped to [0, array.length] , offset is\nclamped to [0, replacement.length] , and length is clamped to min(length, replacement.length - offset, array.length - pos) ). If pos >= array.length or offset >= replacement.length , no replacement occurs\nand the array is returned unchanged.\nThis function modifies the provided array in place.\nsplice(uint256[] array, uint256 start) → uint256[]\ninternal\n#\nMoves the content of array , from start (included) to the end of array to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:].\nThis function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\nsplice(uint256[] array, uint256 start, uint256 end) → uint256[]\ninternal\n#\nMoves the content of array , from start (included) to end (excluded) to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:end]. The\nend argument is truncated to the length of the array .\nThis function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\nreplace(uint256[] array, uint256 pos, uint256[] replacement) → uint256[]\ninternal\n#\nReplaces elements in array starting at pos with all elements from replacement .\nParameters are clamped to valid ranges (e.g. pos is clamped to [0, array.length] ).\nIf pos >= array.length , no replacement occurs and the array is returned unchanged.\nThis function modifies the provided array in place.\nreplace(uint256[] array, uint256 pos, uint256[] replacement, uint256 offset, uint256 length) → uint256[]\ninternal\n#\nReplaces elements in array starting at pos with elements from replacement starting at offset .\nCopies at most length elements from replacement to array .\nParameters are clamped to valid ranges (i.e. pos is clamped to [0, array.length] , offset is\nclamped to [0, replacement.length] , and length is clamped to min(length, replacement.length - offset, array.length - pos) ). If pos >= array.length or offset >= replacement.length , no replacement occurs\nand the array is returned unchanged.\nThis function modifies the provided array in place.\nunsafeAccess(address[] arr, uint256 pos) → struct StorageSlot.AddressSlot\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeAccess(bytes32[] arr, uint256 pos) → struct StorageSlot.Bytes32Slot\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeAccess(uint256[] arr, uint256 pos) → struct StorageSlot.Uint256Slot\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeAccess(bytes[] arr, uint256 pos) → struct StorageSlot.BytesSlot\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeAccess(string[] arr, uint256 pos) → struct StorageSlot.StringSlot\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeMemoryAccess(address[] arr, uint256 pos) → address res\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeMemoryAccess(bytes32[] arr, uint256 pos) → bytes32 res\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeMemoryAccess(uint256[] arr, uint256 pos) → uint256 res\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeMemoryAccess(bytes[] arr, uint256 pos) → bytes res\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeMemoryAccess(string[] arr, uint256 pos) → string res\ninternal\n#\nAccess an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.\nOnly use if you are certain pos is lower than the array length.\nunsafeSetLength(address[] array, uint256 len)\ninternal\n#\nHelper to set the length of a dynamic array. Directly writing to .length is forbidden.\nthis does not clear elements if length is reduced, or initialize elements if length is increased.\nunsafeSetLength(bytes32[] array, uint256 len)\ninternal\n#\nHelper to set the length of a dynamic array. Directly writing to .length is forbidden.\nthis does not clear elements if length is reduced, or initialize elements if length is increased.\nunsafeSetLength(uint256[] array, uint256 len)\ninternal\n#\nHelper to set the length of a dynamic array. Directly writing to .length is forbidden.\nthis does not clear elements if length is reduced, or initialize elements if length is increased.\nunsafeSetLength(bytes[] array, uint256 len)\ninternal\n#\nHelper to set the length of a dynamic array. Directly writing to .length is forbidden.\nthis does not clear elements if length is reduced, or initialize elements if length is increased.\nunsafeSetLength(string[] array, uint256 len)\ninternal\n#\nHelper to set the length of a dynamic array. Directly writing to .length is forbidden.\nthis does not clear elements if length is reduced, or initialize elements if length is increased.\nBase58\nimport \"@openzeppelin/contracts/utils/Base58.sol\" ;\nProvides a set of functions to operate with Base58 strings.\nBase58 is an encoding scheme that converts binary data into a human-readable text format.\nSimilar to Base64 but specifically designed for better human usability.\n- Human-friendly alphabet: Excludes visually similar characters to reduce human error:\n- No 0 (zero) vs O (capital o) confusion\n- No I (capital i) vs l (lowercase L) confusion\n- No non-alphanumeric characters like + or =\n- URL-safe: Contains only alphanumeric characters, making it safe for URLs without encoding.\nInitially based on storyicon's implementation (MIT).\nBased on the updated and improved Vectorized version (MIT).\nFunctions\n- encode(input)\n- decode(input)\nErrors\n- InvalidBase58Char()\nencode(bytes input) → string\ninternal\n#\nEncode a bytes buffer as a Base58 string .\ndecode(string input) → bytes\ninternal\n#\nDecode a Base58 string into a bytes buffer.\nInvalidBase58Char(bytes1)\nerror\n#\nUnrecognized Base58 character on decoding.\nBase64\nimport \"@openzeppelin/contracts/utils/Base64.sol\" ;\nProvides a set of functions to operate with Base64 strings.\nFunctions\n- encode(data)\n- encodeURL(data)\n- decode(data)\nErrors\n- InvalidBase64Char()\nencode(bytes data) → string\ninternal\n#\nConverts a bytes to its Base64 string representation.\nencodeURL(bytes data) → string\ninternal\n#\nConverts a bytes to its Base64Url string representation.\nOutput is not padded with = as specified in rfc4648 .\ndecode(string data) → bytes\ninternal\n#\nConverts a Base64 string to the bytes it represents.\n- Supports padded and unpadded inputs.\n- Supports both encoding ( Base58.encode and Base64.encodeURL ) seamlessly.\n- Reverts with Base64.InvalidBase64Char if the input contains an invalid character.\nInvalidBase64Char(bytes1)\nerror\n#\nBlockhash\nimport \"@openzeppelin/contracts/utils/Blockhash.sol\" ;\nLibrary for accessing historical block hashes beyond the standard 256 block limit.\nUses EIP-2935's history storage contract which maintains a ring buffer of the last\n8191 block hashes in state.\nFor blocks within the last 256 blocks, it uses the native BLOCKHASH opcode.\nFor blocks between 257 and 8191 blocks ago, it queries the EIP-2935 history storage.\nFor blocks older than 8191 or future blocks, it returns zero, matching the BLOCKHASH behavior.\nAfter EIP-2935 activation, it takes 8191 blocks to completely fill the history.\nBefore that, only block hashes since the fork block will be available.\nFunctions\n- blockHash(blockNumber)\nblockHash(uint256 blockNumber) → bytes32\ninternal\n#\nRetrieves the block hash for any historical block within the supported range.\nThe function gracefully handles future blocks and blocks beyond the history window\nby returning zero, consistent with the EVM's native BLOCKHASH behavior.\nBytes\nimport \"@openzeppelin/contracts/utils/Bytes.sol\" ;\nBytes operations.\nFunctions\n- indexOf(buffer, s)\n- indexOf(buffer, s, pos)\n- lastIndexOf(buffer, s)\n- lastIndexOf(buffer, s, pos)\n- slice(buffer, start)\n- slice(buffer, start, end)\n- splice(buffer, start)\n- splice(buffer, start, end)\n- replace(buffer, pos, replacement)\n- replace(buffer, pos, replacement, offset, length)\n- concat(buffers)\n- toNibbles(input)\n- equal(a, b)\n- reverseBytes32(value)\n- reverseBytes16(value)\n- reverseBytes8(value)\n- reverseBytes4(value)\n- reverseBytes2(value)\n- clz(buffer)\nindexOf(bytes buffer, bytes1 s) → uint256\ninternal\n#\nForward search for s in buffer\n- If s is present in the buffer, returns the index of the first instance\n- If s is not present in the buffer, returns type(uint256).max\nreplicates the behavior of Javascript's Array.indexOf\nindexOf(bytes buffer, bytes1 s, uint256 pos) → uint256\ninternal\n#\nForward search for s in buffer starting at position pos\n- If s is present in the buffer (at or after pos ), returns the index of the next instance\n- If s is not present in the buffer (at or after pos ), returns type(uint256).max\nreplicates the behavior of Javascript's Array.indexOf\nlastIndexOf(bytes buffer, bytes1 s) → uint256\ninternal\n#\nBackward search for s in buffer\n- If s is present in the buffer, returns the index of the last instance\n- If s is not present in the buffer, returns type(uint256).max\nreplicates the behavior of Javascript's Array.lastIndexOf\nlastIndexOf(bytes buffer, bytes1 s, uint256 pos) → uint256\ninternal\n#\nBackward search for s in buffer starting at position pos\n- If s is present in the buffer (at or before pos ), returns the index of the previous instance\n- If s is not present in the buffer (at or before pos ), returns type(uint256).max\nreplicates the behavior of Javascript's Array.lastIndexOf\nslice(bytes buffer, uint256 start) → bytes\ninternal\n#\nCopies the content of buffer , from start (included) to the end of buffer into a new bytes object in\nmemory.\nreplicates the behavior of Javascript's Array.slice\nslice(bytes buffer, uint256 start, uint256 end) → bytes\ninternal\n#\nCopies the content of buffer , from start (included) to end (excluded) into a new bytes object in\nmemory. The end argument is truncated to the length of the buffer .\nreplicates the behavior of Javascript's Array.slice\nsplice(bytes buffer, uint256 start) → bytes\ninternal\n#\nMoves the content of buffer , from start (included) to the end of buffer to the start of that buffer,\nand shrinks the buffer length accordingly, effectively overriding the content of buffer with buffer[start:].\nThis function modifies the provided buffer in place. If you need to preserve the original buffer, use Arrays.slice instead\nsplice(bytes buffer, uint256 start, uint256 end) → bytes\ninternal\n#\nMoves the content of buffer , from start (included) to end (excluded) to the start of that buffer,\nand shrinks the buffer length accordingly, effectively overriding the content of buffer with buffer[start:end].\nThe end argument is truncated to the length of the buffer .\nThis function modifies the provided buffer in place. If you need to preserve the original buffer, use Arrays.slice instead\nreplace(bytes buffer, uint256 pos, bytes replacement) → bytes\ninternal\n#\nReplaces bytes in buffer starting at pos with all bytes from replacement .\nParameters are clamped to valid ranges (i.e. pos is clamped to [0, buffer.length] ).\nIf pos >= buffer.length , no replacement occurs and the buffer is returned unchanged.\nThis function modifies the provided buffer in place.\nreplace(bytes buffer, uint256 pos, bytes replacement, uint256 offset, uint256 length) → bytes\ninternal\n#\nReplaces bytes in buffer starting at pos with bytes from replacement starting at offset .\nCopies at most length bytes from replacement to buffer .\nParameters are clamped to valid ranges (i.e. pos is clamped to [0, buffer.length] , offset is\nclamped to [0, replacement.length] , and length is clamped to min(length, replacement.length - offset, buffer.length - pos)) . If pos >= buffer.length or offset >= replacement.length , no replacement occurs\nand the buffer is returned unchanged.\nThis function modifies the provided buffer in place.\nconcat(bytes[] buffers) → bytes\ninternal\n#\nConcatenate an array of bytes into a single bytes object.\nFor fixed bytes types, we recommend using the solidity built-in bytes.concat or (equivalent)\nabi.encodePacked .\nthis could be done in assembly with a single loop that expands starting at the FMP, but that would be\nsignificantly less readable. It might be worth benchmarking the savings of the full-assembly approach.\ntoNibbles(bytes input) → bytes output\ninternal\n#\nSplit each byte in input into two nibbles (4 bits each)\nExample: hex\"01234567\" → hex\"0001020304050607\"\nequal(bytes a, bytes b) → bool\ninternal\n#\nReturns true if the two byte buffers are equal.\nreverseBytes32(bytes32 value) → bytes32\ninternal\n#\nReverses the byte order of a bytes32 value, converting between little-endian and big-endian.\nInspired by Reverse Parallel\nreverseBytes16(bytes16 value) → bytes16\ninternal\n#\nSame as Bytes.reverseBytes32 but optimized for 128-bit values.\nreverseBytes8(bytes8 value) → bytes8\ninternal\n#\nSame as Bytes.reverseBytes32 but optimized for 64-bit values.\nreverseBytes4(bytes4 value) → bytes4\ninternal\n#\nSame as Bytes.reverseBytes32 but optimized for 32-bit values.\nreverseBytes2(bytes2 value) → bytes2\ninternal\n#\nSame as Bytes.reverseBytes32 but optimized for 16-bit values.\nclz(bytes buffer) → uint256\ninternal\n#\nCounts the number of leading zero bits a bytes array. Returns 8 * buffer.length\nif the buffer is all zeros.\nCAIP10\nimport \"@openzeppelin/contracts/utils/CAIP10.sol\" ;\nHelper library to format and parse CAIP-10 identifiers\nCAIP-10 defines account identifiers as:\naccount_id: chain_id + \":\" + account_address\nchain_id: [-a-z0-9] 8 :[-_a-zA-Z0-9] 32 (See CAIP2 )\naccount_address: [-.%a-zA-Z0-9] 128\nAccording to CAIP-10's canonicalization section ,\nthe implementation remains at the developer's discretion. Please note that case variations may introduce ambiguity.\nFor example, when building hashes to identify accounts or data associated to them, multiple representations of the\nsame account would derive to different hashes. For EVM chains, we recommend using checksummed addresses for the\n\"account_address\" part. They can be generated onchain using Strings.toChecksumHexString .\nFunctions\n- local(account)\n- format(caip2, account)\n- parse(caip10)\nlocal(address account) → string\ninternal\n#\nReturn the CAIP-10 identifier for an account on the current (local) chain.\nformat(string caip2, string account) → string\ninternal\n#\nReturn the CAIP-10 identifier for a given caip2 chain and account.\nThis function does not verify that the inputs are properly formatted.\nparse(string caip10) → string caip2, string account\ninternal\n#\nParse a CAIP-10 identifier into its components.\nThis function does not verify that the CAIP-10 input is properly formatted. The caip2 return can be\nparsed using the CAIP2 library.\nCAIP2\nimport \"@openzeppelin/contracts/utils/CAIP2.sol\" ;\nHelper library to format and parse CAIP-2 identifiers\nCAIP-2 defines chain identifiers as:\nchain_id: namespace + \":\" + reference\nnamespace: [-a-z0-9] 8\nreference: [-_a-zA-Z0-9] 32\nIn some cases, multiple CAIP-2 identifiers may all be valid representation of a single chain.\nFor EVM chains, it is recommended to use eip155:xxx as the canonical representation (where xxx is\nthe EIP-155 chain id). Consider the possible ambiguity when processing CAIP-2 identifiers or when using them\nin the context of hashes.\nFunctions\n- local()\n- format(namespace, ref)\n- parse(caip2)\nlocal() → string\ninternal\n#\nReturn the CAIP-2 identifier for the current (local) chain.\nformat(string namespace, string ref) → string\ninternal\n#\nReturn the CAIP-2 identifier for a given namespace and reference.\nThis function does not verify that the inputs are properly formatted.\nparse(string caip2) → string namespace, string ref\ninternal\n#\nParse a CAIP-2 identifier into its components.\nThis function does not verify that the CAIP-2 input is properly formatted.\nCalldata\nimport \"@openzeppelin/contracts/utils/Calldata.sol\" ;\nHelper library for manipulating objects in calldata.\nFunctions\n- emptyBytes()\n- emptyString()\nemptyBytes() → bytes result\ninternal\n#\nemptyString() → string result\ninternal\n#\nComparators\nimport \"@openzeppelin/contracts/utils/Comparators.sol\" ;\nProvides a set of functions to compare values.\nAvailable since v5.1.\nFunctions\n- lt(a, b)\n- gt(a, b)\nlt(uint256 a, uint256 b) → bool\ninternal\n#\ngt(uint256 a, uint256 b) → bool\ninternal\n#\nContext\nimport \"@openzeppelin/contracts/utils/Context.sol\" ;\nProvides information about the current execution context, including the\nsender of the transaction and its data. While these are generally available\nvia msg.sender and msg.data, they should not be accessed in such a direct\nmanner, since when dealing with meta-transactions the account sending and\npaying for execution may not be the actual sender (as far as an application\nis concerned).\nThis contract is only required for intermediate, library-like contracts.\nFunctions\n- _msgSender()\n- _msgData()\n- _contextSuffixLength()\n_msgSender() → address\ninternal\n#\n_msgData() → bytes\ninternal\n#\n_contextSuffixLength() → uint256\ninternal\n#\nCreate2\nimport \"@openzeppelin/contracts/utils/Create2.sol\" ;\nHelper to make usage of the CREATE2 EVM opcode easier and safer.\nCREATE2 can be used to compute in advance the address where a smart\ncontract will be deployed, which allows for interesting new mechanisms known\nas 'counterfactual interactions'.\nSee the EIP for more\ninformation.\nFunctions\n- deploy(amount, salt, bytecode)\n- computeAddress(salt, bytecodeHash)\n- computeAddress(salt, bytecodeHash, deployer)\nErrors\n- Create2EmptyBytecode()\ndeploy(uint256 amount, bytes32 salt, bytes bytecode) → address addr\ninternal\n#\nDeploys a contract using CREATE2 . The address where the contract\nwill be deployed can be known in advance via Create2.computeAddress .\nThe bytecode for a contract can be obtained from Solidity with\ntype(contractName).creationCode .\nRequirements:\n- bytecode must not be empty.\n- salt must have not been used for bytecode already.\n- the factory must have a balance of at least amount .\n- if amount is non-zero, bytecode must have a payable constructor.\ncomputeAddress(bytes32 salt, bytes32 bytecodeHash) → address\ninternal\n#\nReturns the address where a contract will be stored if deployed via Create2.deploy . Any change in the\nbytecodeHash or salt will result in a new destination address.\ncomputeAddress(bytes32 salt, bytes32 bytecodeHash, address deployer) → address addr\ninternal\n#\nReturns the address where a contract will be stored if deployed via Create2.deploy from a contract located at\ndeployer . If deployer is this contract's address, returns the same value as Create2.computeAddress .\nCreate2EmptyBytecode()\nerror\n#\nThere's no code to deploy.\nErrors\nimport \"@openzeppelin/contracts/utils/Errors.sol\" ;\nCollection of common custom errors used in multiple contracts\nBackwards compatibility is not guaranteed in future versions of the library.\nIt is recommended to avoid relying on the error API for critical functionality.\nAvailable since v5.1.\nErrors\n- InsufficientBalance(balance, needed)\n- FailedCall()\n- FailedDeployment()\n- MissingPrecompile()\nInsufficientBalance(uint256 balance, uint256 needed)\nerror\n#\nThe ETH balance of the account is not enough to perform the operation.\nFailedCall()\nerror\n#\nA call to an address target failed. The target may have reverted.\nFailedDeployment()\nerror\n#\nThe deployment failed.\nMissingPrecompile(address)\nerror\n#\nA necessary precompile is missing.\nLowLevelCall\nimport \"@openzeppelin/contracts/utils/LowLevelCall.sol\" ;\nLibrary of low level call functions that implement different calling strategies to deal with the return data.\nUsing this library requires an advanced understanding of Solidity and how the EVM works. It is recommended\nto use the Address library instead.\nFunctions\n- callNoReturn(target, data)\n- callNoReturn(target, value, data)\n- callReturn64Bytes(target, data)\n- callReturn64Bytes(target, value, data)\n- staticcallNoReturn(target, data)\n- staticcallReturn64Bytes(target, data)\n- delegatecallNoReturn(target, data)\n- delegatecallReturn64Bytes(target, data)\n- returnDataSize()\n- returnData()\n- bubbleRevert()\n- bubbleRevert(returndata)"}
{"url":"https://www.anchor-lang.com/docs/basics/program-structure","domain":"www.anchor-lang.com","title":"Program Structure","hash":"8cfd1429f6d3f8aa377a7243f24c1a586025cf775b92cd93a109fb7e17bf6d52","tokens":2925,"chars":11697,"crawler":"crawler-f6nn","verified":"exact","ts":1791171973306,"text":"Anchor Docs\nGithub Discord Stack Exchange\nThe Basics\nProgram Structure\nLearn about the structure of Anchor programs, including key macros and their roles in simplifying Solana program development\nThe Anchor framework uses\nRust macros to reduce\nboilerplate code and simplify the implementation of common security checks\nrequired for writing Solana programs.\nThe main macros found in an Anchor program include:\n- declare_id : Specifies the program's on-chain address\n- #[program] : Specifies the module containing the\nprogram’s instruction logic\n- #[derive(Accounts)] : Applied to structs to indicate\na list of accounts required by an instruction\n- #[account] : Applied to structs to create custom\naccount types for the program\nExample Program\nLet's examine a simple program that demonstrates the usage of the macros\nmentioned above to understand the basic structure of an Anchor program.\nThe program below includes a single instruction called initialize that creates\na new account ( NewAccount ) and initializes it with a u64 value.\nlib.rs\nuse anchor_lang :: prelude ::* ;\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);\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\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}\ndeclare_id! macro\nThe\ndeclare_id\nmacro specifies the on-chain address of the program, known as the program ID.\nYou can find the implementation of the code generated by the declare_id! macro\nhere .\nlib.rs\nuse anchor_lang :: prelude ::* ;\ndeclare_id! ( \"11111111111111111111111111111111\" );\nBy default, the program ID is the public key of the keypair generated at\n/target/deploy/your_program_name.json .\nTo update the value of the program ID in the declare_id macro with the public\nkey of the keypair in the /target/deploy/your_program_name.json file, run the\nfollowing command:\nTerminal\nanchor keys sync\nThe anchor keys sync command is useful to run when cloning a repository where\nthe value of the program ID in a cloned repo's declare_id macro won't match\nthe one generated when you run anchor build locally.\n#[program] attribute\nThe\n#[program]\nattribute annotates the module containing all the instruction handlers for your\nprogram. Each public function within this module corresponds to an instruction\nthat can be invoked.\nYou can find the implementation of the code generated by the #[program]\nattribute\nhere .\nlib.rs\nuse anchor_lang :: prelude ::* ;\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);\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\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}\nInstruction Context\nInstruction handlers are functions that define the logic executed when an\ninstruction is invoked. The first parameter of each handler is a Context\ntype, where T is a struct implementing the\nAccounts\ntrait and specifies the accounts the instruction requires.\nThe\nContext\ntype provides the instruction with access to the following non-argument inputs:\npub struct Context <' info , T : Bumps > {\n/// Currently executing program id.\npub program_id : & ' info Pubkey ,\n/// Deserialized accounts.\npub accounts : & ' info mut T ,\n/// Remaining accounts given but not deserialized or validated.\n/// Be very careful when using this directly.\npub remaining_accounts : & ' info [ AccountInfo <' info >],\n/// Bump seeds found during constraint validation. This is provided as a\n/// convenience so that handlers don't have to recalculate bump seeds or\n/// pass them in as arguments.\n/// Type is the bumps struct generated by #[derive(Accounts)]\npub bumps : T :: Bumps ,\n}\nThe Context fields can be accessed in an instruction using dot notation:\n- ctx.accounts : The accounts required for the instruction\n- ctx.program_id : The program's public key (address)\n- ctx.remaining_accounts : Additional accounts not specified in the Accounts\nstruct.\n- ctx.bumps : Bump seeds for any Program Derived Address (PDA) accounts\nspecified in the Accounts struct\nAdditional parameters are optional and can be included to specify arguments that\nmust be provided when the instruction is invoked.\nlib.rs\npub fn initialize (ctx : Context < Initialize >, data : u64 ) -> Result <()> {\nctx . accounts . new_account . data = data;\nmsg! ( \"Changed data to: {}!\" , data);\nOk (())\n}\nIn this example, the Initialize struct implements the Accounts trait where\neach field in the struct represents an account required by the initialize\ninstruction.\nlib.rs\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);\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\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#[derive(Accounts)] macro\nThe\n#[derive(Accounts)]\nmacro is applied to a struct to specify the accounts that must be provided when\nan instruction is invoked. This macro implements the\nAccounts\ntrait, which simplifies account validation and serialization and deserialization\nof account data.\nYou can find the implementation of the code generated by the\n#[derive(Accounts)] macro\nhere .\n#[derive( Accounts )]\npub struct Initialize <' info > {\n#[account(init, payer = signer, space = 8 + 8)]\npub new_account : Account <' info , NewAccount >,\n#[account( mut )]\npub signer : Signer <' info >,\npub system_program : Program <' info , System >,\n}\nEach field in the struct represents an account required by an instruction. The\nnaming of each field is arbitrary, but it is recommended to use a descriptive\nname that indicates the purpose of the account.\n#[derive( Accounts )]\npub struct Initialize <' info > {\n#[account(init, payer = signer, space = 8 + 8)]\npub new_account : Account <' info , NewAccount >,\n#[account( mut )]\npub signer : Signer <' info >,\npub system_program : Program <' info , System >,\n}\nAccount Validation\nTo prevent security vulnerabilities, it's important to verify that accounts\nprovided to an instruction are the expected accounts. Accounts are validated in\nAnchor programs in two ways that are generally used together:\n-\nAccount Constraints : Constraints\ndefine additional conditions that an account must satisfy to be considered\nvalid for the instruction. Constraints are applied using the #[account(..)]\nattribute, which is placed above a field in a struct that implements the\nAccounts trait.\nYou can find a full list of the constraints\nhere\nand implementation\nhere .\n#[derive( Accounts )]\npub struct Initialize <' info > {\n#[account(init, payer = signer, space = 8 + 8)]\npub new_account : Account <' info , NewAccount >,\n#[account( mut )]\npub signer : Signer <' info >,\npub system_program : Program <' info , System >,\n}\n-\nAccount Types : Anchor provides various\naccount types to help ensure that the account provided by the client matches\nwhat the program expects.\nYou can find the implementation of the account types\nhere .\n#[derive( Accounts )]\npub struct Initialize <' info > {\n#[account(init, payer = signer, space = 8 + 8)]\npub new_account : Account <' info , NewAccount >,\n#[account( mut )]\npub signer : Signer <' info >,\npub system_program : Program <' info , System >,\n}\nWhen an instruction in an Anchor program is invoked, the program first validates\nthe accounts provided before executing the instruction's logic. After\nvalidation, these accounts can be accessed within the instruction using the\nctx.accounts syntax.\nlib.rs\nuse anchor_lang :: prelude ::* ;\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);\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\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}\n#[account] attribute\nThe\n#[account]\nattribute is applied to structs that define the structure of the data stored in\ncustom accounts created by your program.\n#[account]\npub struct NewAccount {\ndata : u64 ,\n}\nThis macro implements various traits\ndetailed here .\nThe key functionalities of the #[account] macro include:\n- Assign Program Owner :\nWhen creating an account, the program owner of the account is automatically\nset to the program specified in declare_id .\n- Set Discriminator :\nA unique 8 byte discriminator, specific to the account type, is added as the\nfirst 8 bytes of account data during its initialization. This helps in\ndifferentiating account types and is used for account validation.\n- Data Serialization and Deserialization :\nAccount data is automatically serialized and deserialized as the account type.\nlib.rs\nuse anchor_lang :: prelude ::* ;\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);\nOk (())\n}\n#[derive( Accounts )]\npub struct Initialize <' info > {\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}\nAccount Discriminator\nAn account discriminator in an Anchor program refers to an 8 byte identifier\nunique to each account type. You can find the implementation of the account\ndiscriminator\nhere .\nThe discriminator is the first 8 bytes of the SHA256 hash of the string\naccount: . This discriminator is stored as the first 8 bytes of\naccount data when an account is created.\nWhen creating an account in an Anchor program, 8 bytes must be allocated for the\ndiscriminator.\n#[account(init, payer = signer, space = 8 + 8)]\npub new_account : Account <' info , NewAccount >,\nThe discriminator is used during the following two scenarios:\n- Initialization: When an account is created, the discriminator is set as the\nfirst 8 bytes of the account's data.\n- Deserialization: When account data is deserialized, the first 8 bytes of\naccount data is checked against the discriminator of the expected account\ntype.\nIf there's a mismatch, it indicates that the client has provided an unexpected\naccount. This mechanism serves as an account validation check in Anchor\nprograms.\nPrevious\nAnchor Framework Basics\nNext\nProgram IDL File\nOn this page\nExample Program declare_id! macro #[program] attribute Instruction Context #[derive(Accounts)] macro Account Validation #[account] attribute Account Discriminator\nEdit on GitHub"}
{"url":"https://docs.ethena.fi/protocol-overview/rewards-mechanism","domain":"docs.ethena.fi","title":"Rewards Mechanism | Ethena","hash":"aa4af52e3e6e317c8299bbfacb9bc2bdac0dbc048a00b680aabf7f7598aa6d30","tokens":845,"chars":3377,"crawler":"crawler-f6nn","verified":"exact","ts":1791171975854,"text":"⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nRewards Mechanism\nHow sUSDe accrues discretionary rewards\nContext\nUsers are able to accrue fully discretionary incentive rewards by staking their USDe and receiving sUSDe atomically in return.\nOnce users stake their USDe for sUSDe , they begin to accrue rewards, to the extent provided, without any further action or cost. USDe that is staked is not rehypothecated in any way to generate returns.\nOverview\nThe amount of sUSDe a user receives is determined by how much USDe was transferred as well as when it was transferred. Ethena's sUSDe utilizes a reward-bearing \"Token Vault\" mechanism, the same as Rocketpool's rETH or Binance's WBETH .\nThe protocol does not rehypothecate, lend out, or otherwise utilize deposited USDe for any purpose. There is no need for any such action, as the USDe backing mechanic inherently creates value in the system.\nThis mechanism simply enables Ethena to provide rewards to ecosystem participants without users having to do any action to \"earn\" it. The USDe value of sUSDe grows on its own. When a user unstakes his or her USDe , the user receives an amount of USDe equal to the initial amount staked plus their share of rewards deposited in the staking contract as rewards while that user's USDe was staked, as reflected in the USDe value increase of sUSDe .\nImportant Notes\n-\nThe amount of sUSDe you receive when you stake USDe is likely to be less in number, but valued at the equivalent amount of USDe . This is a result of the \"Token Vault\" mechanism and the ratio defined below in the worked example.\n-\nThe value of USDe will remain worth the market trading price of USDe while sUSDe will grow in USDe value as the protocol (via a subsidiary of the Ethena Foundation) deposits discretionary rewards in the staking contract.\n-\nIf the protocol were to suffer a loss due to funding or another reason, Ethena's Reserve Fund is intended to bear the cost, rather than the staking contract.\nsUSDe can only accrue positive or flat rewards while staking USDe; periods of negative protocol revenue are not passed on to sUSDe . During such periods, no discretionary rewards will be provided.\nCalculation & Worked Example\nsUSDe : USDe ratio = (total sUSDe supply) / (total USDe staked + total protocol revenue deposited in USDe terms)@c\nsUSDe Rewards Mechanism\nThe Ethena Foundation, via a subsidiary, calculates APY weekly as part of internal accounting when distributing rewards to the StakingRewardsDistributor contract .\nTo prevent lumpy distributions which people can arbitrage, and because its not currently feasible for Ethena to distribute more frequently than weekly, sUSDe rewards are distributed the week after the period to which they relate, in multiple smaller payments throughout the week. In that period, the USDe supply can increase or decrease, as can the % of USDe supply staked.\nThis can cause distortions between the APY published, and a number that's just based on the most recent 8 hourly payment to sUSDe, as seen on some data aggregator sites.\nEthena's APY is also annualized with weekly compounding reflecting the compounding interval users actually experience.\nLast updated 2 months ago\nWas this helpful?\n- Context\n- Overview\n- Important Notes\n- Calculation & Worked Example\n- sUSDe Rewards Mechanism\nWas this helpful?"}
{"url":"https://bitcoin.org/fa/","domain":"bitcoin.org","title":"بیتکوین - پولی P2P با متن باز","hash":"7ef75d34973041cc53e860cae93405ab704c3ad90e00f03e7cd261cb6d428084","tokens":644,"chars":2573,"crawler":"crawler-f6nn","verified":"exact","ts":1791171978109,"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- مقدمه\n- افراد\n- کسب و کارها\n- توسعه دهندگان\n- آغاز به کار\n- چگونه کار می کند\n- لازم است بدانید\n- منابع\n- Exchanges\n- جامعه\n- BIPs list\n- دایره واژگان\n- Bitcoin Core\n- نو آوری\n- مشارکت\n- حمایت از بیت کوین\n- Buy Bitcoin\n- Sell Bitcoin\n- توسعه\n- پرسشهای رایج\n- فارسی\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: fa\nبیتکوین یک شبکهی پرداخت نوآورانه و نوع جدیدی از پول است.\nآغاز به کار با بیتکوین\nکیف پول خود را انتخاب کنید\nBuy Bitcoin\nیا مروری سریع بر\nافراد\nLearn more\nکسب و کارها\nLearn more\nتوسعه دهندگان\nLearn more\nآغاز به کار با بیتکوین\nبیت کوین با استفاده از تکنولوژی همتا به همتا و بدون هیچ مرجع یا بانک مرکزی، کار می کند؛ تراکنشها را مدیریت کرده و بیت کوینهایی صادر می کند که توسط شبکه بطور دسته جمعی ساخته می شوند. بیت کوین متن باز است، طراحی آن عمومی است، هیچکس مالک آن نیست یا آنرا کنترل نمی کند و همه می توانند در آن مشارکت کنند . با این همه ویژگیهای بی نظیر، بیت کوین کاربردهای هیجان انگیزی دارد که نمی توان در هیچیک از سیستمهای پرداخت پیش از این پیدا کرد.\n-\nتراکنش های\nهمتا به همتای آنی\n-\nپرداختهایی\nدر سطح جهان\n-\nکارمزد پردازش کم\nیا بدون کارمزد\nآغاز به کار با بیتکوین\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nمقدمه:\n-\nافراد\n-\nکسب و کارها\n-\nتوسعه دهندگان\n-\nآغاز به کار\n-\nچگونه کار می کند\n-\nلازم است بدانید\nمنابع:\n-\nمنابع\n-\nExchanges\n-\nجامعه\n-\nBIPs list\n-\nدایره واژگان\n-\nBitcoin Core\nمشارکت:\n-\nحمایت از بیت کوین\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nتوسعه\nOther:\nحقوقی\nPrivacy Policy\nمطبوعات\nدرباره bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 منتشر شده تحت MIT license\nNetwork Status\n- فارسی\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- 繁體中文\nfa"}
{"url":"https://docs.openzeppelin.com/contracts/5.x","domain":"docs.openzeppelin.com","title":"Contracts | OpenZeppelin Docs","hash":"b2a91434db3458e38381b80d61a02a3de4c3fcac0c9275396ae469ea1c2bd668","tokens":1122,"chars":4485,"crawler":"crawler-f6nn","verified":"exact","ts":1791171980556,"text":"Home Forum Website Impact\nOpenZeppelin Contracts\nContracts\nOpen in Claude\nA library for secure smart contract development. Build on a solid foundation of community-vetted code.\n- Implementations of standards like ERC20 and ERC721 .\n- Flexible role-based permissioning scheme.\n- Reusable Solidity components to build custom contracts and complex decentralized systems.\nOpenZeppelin Contracts uses semantic versioning to communicate backwards compatibility of its API and storage layout. For upgradeable contracts, the storage layout of different major versions should be assumed incompatible, for example, it is unsafe to upgrade from 4.9.3 to 5.0.0. Learn more at Backwards Compatibility .\nOverview\nRelease Tags\nWe use NPM tags to clearly distinguish between audited and non-audited versions of our package:\n| Tag |\n| --- | --- | --- |\n| Purpose | Description | latest |\n| ✅ Audited releases | Stable, audited versions of the package. This is the default version installed when users run npm install @openzeppelin/contracts . | dev |\n| 🧪 Final but not audited | Versions that are finalized and feature-complete but have not yet been audited . This version is fully tested, can be used in production and is covered by the bug bounty. | next |\nInstallation\nHardhat (npm)\n$ npm install @openzeppelin/contracts\n→ Installs the latest audited release ( latest ).\n$ npm install @openzeppelin/contracts@dev\n→ Installs the latest unaudited release ( dev ).\nFoundry (git)\nWhen installing via git, it is a common error to use the master branch. This is a development branch that should be avoided in favor of tagged releases. The release process involves security measures that the master branch does not guarantee.\nFoundry installs the latest version initially, but subsequent forge update commands will use the master branch.\n$ forge install OpenZeppelin/openzeppelin-contracts\nAdd @openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/ in remappings.txt.\nUsage\nOnce installed, you can use the contracts in the library by importing them:\n// contracts/MyNFT.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24 ;\nimport { ERC721 } from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\" ;\ncontract MyNFT is ERC721 {\nconstructor () ERC721 (\"MyNFT\", \"MNFT\") {}\n}\nIf you’re new to smart contract development, head to Developing Smart Contracts to learn about creating a new project and compiling your contracts.\nTo keep your system secure, you should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself. The library is designed so that only the contracts and functions you use are deployed, so you don’t need to worry about it needlessly increasing gas costs.\nSecurity\nPlease report any security issues you find via our bug bounty program on Immunefi or directly to [email protected] .\nThe Security Center contains more details about the secure development process.\nLearn More\nThe guides in the sidebar will teach about different concepts, and how to use the related contracts that OpenZeppelin Contracts provides:\n- Access Control : decide who can perform each of the actions on your system.\n- Tokens : create tradable assets or collectibles, like the well known ERC20 and ERC721 standards.\n- Utilities : generic useful tools, including non-overflowing math, signature verification, and trustless paying systems.\nThe full API is also thoroughly documented, and serves as a great reference when developing your smart contract application. You can also ask for help or follow Contracts' development in the community forum .\nThe following articles provide great background reading, though please note, some of the referenced tools have changed as the tooling in the ecosystem continues to rapidly evolve.\n- The Hitchhiker’s Guide to Smart Contracts in Ethereum will help you get an overview of the various tools available for smart contract development, and help you set up your environment.\n- A Gentle Introduction to Ethereum Programming, Part 1 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 , which discusses how to better structure your application and its relationship to the real world.\nGetting Started\nPrevious Page\nContracts Wizard\nNext Page\nOn this page\nOverview Release Tags Installation Hardhat (npm) Foundry (git) Usage Security Learn More"}
{"url":"https://docs.monad.xyz/developer-essentials/gas-pricing","domain":"docs.monad.xyz","title":"Gas Pricing - Monad Documentation","hash":"75cbee10d0828665c4efe61776af7f6880a0753e6d5cd6bf945cffd8f72519d5","tokens":1997,"chars":7987,"crawler":"crawler-f6nn","verified":"exact","ts":1791171982965,"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\nGas Pricing\nAn estimated USD cost for a typical Monad transaction, plus how gas fees are calculated.\nSummary\nMonad, like Ethereum, charges for processing transactions based on the complexity of the\ntransaction. Complexity is measured in units of gas .\nThis page summarizes how gas is charged, i.e. the conversion between the gas of a transaction\nand the amount of MON that a user will have to pay.\nA separate page, Opcode Pricing , describes how much\neach opcode costs in units of gas.\nFeature Detail\nGas charged The gas charged for a transaction is the gas limit . Discussion\nPrice per gas EIP-1559-compatible, i.e. price paid per unit of gas is the sum of a system-controlled base fee and a user-specified priority fee. Discussion\nBase fee Base fee (aka base_price_per_gas ) follows a dynamic controller, similar to the EIP-1559 controller but with slower increases and faster decreases. Details\nMinimum base fee 100 MON-gwei ( 100 * 10^-9 MON )\nTypical cost A typical 200,000-gas transaction costs about $0.0005 at the minimum base fee (≈ 0.02 MON). Worked example\nBlock gas limit 150M gas\nTransaction gas limit 30M gas\nOpcode pricing See Opcode Pricing\nTransaction ordering Default Monad client behavior is to order transactions according to a Priority Gas Auction (descending total gas price).\nThese changes are covered formally in the\nMonad Initial Spec Proposal\nHow much does a transaction cost?\nA typical 200,000-gas transaction on Monad costs about $0.0005 at the minimum base fee of\n100 MON-gwei, and a simple MON transfer (21,000 gas) costs about $0.00005 , a fraction of a\ncent. Fees are paid in MON, so these dollar amounts are approximate; the MON cost is exact.\nThe cost of a transaction is the gas it is charged multiplied by the price paid per unit of gas. At\nthe minimum base fee of 100 MON-gwei and no priority fee, a 200,000-gas transaction costs 0.02 MON,\nor about $0.0005:\nfee = gas limit × price per gas = 200 , 000 × ( 100 × 1 0 − 9 MON ) = 0.02 MON\n200,000 gas is a common reference size for a swap or comparable contract call; a transaction’s\nactual gas depends on what it does. The table below lists representative sizes.\nTransaction Gas limit Cost (MON) Cost (USD, approx.)\nNative MON transfer 21,000 0.0021 MON ~$0.00005\nERC-20 token transfer ~65,000 ~0.0065 MON ~$0.00016\nTypical DEX swap ~200,000 ~0.02 MON ~$0.0005\nMonad charges the gas limit you set, not the gas actually used\n( details ), so these amounts can’t rise after execution the way a\ngas-used estimate can. They are the most you would pay while the base fee is at its floor. Under\nsustained network load the base fee can rise above 100 MON-gwei\n(see base fee controller ). A native MON transfer always uses\nexactly 21,000 gas; gas for token transfers and swaps varies by contract.\nGas definitions\nA common point of confusion among users is the distinction between gas of a transaction (units\nof work) and the gas price of a transaction (price in native tokens per unit of work).\nFeature Definition\nGas A unit of work. Gas measures the amount of work the network has to do to process something.\nSince the network has multiple kinds of resources (network bandwidth, CPU, SSD bandwidth, and state growth), gas is inherently a projection from many dimensions into a single one.\nGas price (price_per_gas) The price (in native tokens) paid to process one unit of gas.\nGas limit The maximum number of units of gas that a transaction is allowed to consume.\nGas limit, not gas used\nIn Monad, the gas charged for a transaction is the gas limit set in the transaction, rather than\nthe gas used in the course of execution.\nThis is a design decision to support asynchronous execution. Under asynchronous execution,\nleaders build blocks (and validators vote on block validity) prior to executing.\nIf the protocol charged gas_used , a user could submit a transaction with a large gas_limit\nthat actually consumes very little gas. This transaction would take up a lot of space toward the\nblock gas limit but wouldn’t pay very much for taking up that space, opening up a DOS vector.\ngas_paid = gas_limit * price_per_gas\nEIP-1559 Compatibility\nMonad supports EIP-1559.\nEIP-1559 (type 2) transactions have the parameters priority_price_per_gas and\nmax_price_per_gas , which, together with base_price_per_gas (a system parameter that changes\neach block), determine the gas bid for the transaction:\nprice_per_gas = min(base_price_per_gas + priority_price_per_gas, max_price_per_gas)\nNotes:\n- base_price_per_gas is a system parameter that changes each block. Every transaction in the\nsame block will have the same base_price_per_gas\n- Users specify priority_price_per_gas and max_price_per_gas when signing a transaction\n- Since everyone in the same block will pay the same base_price_per_gas , the\npriority_price_per_gas is a way for users to pay more to prioritize their transactions.\n- Since users don’t determine base_price_per_gas , the max_price_per_gas is a safeguard that\nlimits the amount they may end up paying. Of course, if that value is set too low, the\ntransaction will not end up being chosen for inclusion.\nThis article provides another good explanation\nof EIP-1559 gas pricing.\nbase_price_per_gas controller\nMonad uses a different controller for base_price_per_gas than Ethereum:\nblock_gas k base_price_per_gas k + 1 η k trend k + 1 moment k + 1 = tx ∈ block k ∑ gas_limit tx = max { min_base_price_per_gas , base_price_per_gas k ⋅ exp ( η k ⋅ block_gas_limit − target block_gas k − target ) } = ϵ + moment k − trend k 2 max_step_size ⋅ ϵ = β ⋅ trend k + ( 1 − β ) ⋅ ( target − block_gas k ) = β ⋅ moment k + ( 1 − β ) ⋅ ( target − block_gas k ) 2\nThis inductive formula starts with\nbase_price_per_gas 0 moment 0 trend 0 = 0 = 0 = 0\nand with the following parameters:\nmax_step_size target β ϵ = 1/28 = 160 M (80% full) = 0.96 = target = 160 M\nAnd\nmin_base_price_per_gas = 100 MON-gwei ( 100 × 1 0 − 9 MON )\nCompared to the base_price_per_gas controller in Ethereum, this controller increases more\nslowly and decreases more quickly. This is to avoid underutilization of blockspace due to an overpriced base_price_per_gas .\nFor a more comprehensive discussion of Monad controller design considerations and behavior, check out this blog post from Category Labs.\nRecommendations for developers\nSet the gas limit explicitly if it is constant\nMany on-chain actions have a fixed gas cost. The simplest example is that a transfer of native\ntokens always costs 21,000 gas, but there are many others.\nFor actions where the gas cost of the transaction is known ahead of time, it is recommended to set\nit directly prior to handing the transaction off to the wallet. This offers several benefits:\n- It reduces latency and gives users a better experience, since the wallet doesn’t have to call\neth_estimateGas and wait for the RPC to respond.\n- It retains greater control over the user experience, avoiding cases where the wallet sets a high\ngas limit in a corner case as described in the warning below.\nSome wallets, including MetaMask, are known to have the following behavior: when\neth_estimateGas is called and the contract call reverts, they set the gas limit for this\ntransaction to a very high value. This is the wallet’s way of giving up on setting the gas limit and accepting whatever gas usage is\nat execution time. However, it doesn’t make sense on Monad where the full gas limit is charged. Contract call reversion happens whenever the user is trying to do something impossible. For\nexample, a user might be trying to mint an NFT that has minted out. If the gas limit is known ahead of time, setting it explicitly is best practice, since it ensures\nthe wallet won’t handle this case unexpectedly.\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://aave.com/docs/vaults/stable-vaults/architecture","domain":"aave.com","title":"Stable Vault Architecture | Aave Protocol Documentation","hash":"53ea2f275a6dae2edc48185f415c410c673e9049150fbce8e1dedbd167e83208","tokens":1336,"chars":5342,"crawler":"crawler-f6nn","verified":"exact","ts":1791171987169,"text":"Docs\nStable Vault Architecture # Copy\nThe system is split across an Accounting Chain and one or more Earning Chains. The Accounting Chain is the source of truth for user balances, the system surplus, and withdrawal accounting. Earning Chains host yield strategies and periodically publish balance snapshots back to the Accounting Chain through a Chainlink-powered oracle feed. An off-chain system monitors protocol state and submits rebalance and bridge transactions.\nAccounting Chain # Copy\nThe Accounting Chain handles deposits, withdrawal requests, share accounting, and surplus gating. For the Aave App, the Accounting Chain is Arbitrum.\nThe Stable Vault is the user entrypoint. It validates asset prices through the Price Oracle on each deposit, mints shares into the user's assigned SubVault, and manages the two-step withdrawal flow. On requestWithdrawal , shares are burned and IOU tokens are minted representing a denomination currency claim. The principal portion of a position is always redeemable as IOUs; the interest portion is gated by the system's trusted surplus. On executeWithdrawal , IOUs are burned, the Withdrawal Execution Policy applies any fees, and the user receives their chosen output asset. Share positions can be transferred between users via transfer and transferAll .\nThe Funds Handler sits between the Stable Vault and the Allocator. It aggregates the total price-weighted asset value across local balances and registered Earning Chains by querying the Chain Balance Oracle on demand for remote chain data. Stale Earning Chain data contributes zero to the aggregation, so the system conservatively underestimates its surplus rather than overstating it. This protects depositors by not inflating the global interest pool earned by the Stable Vault's assets.\nThe Allocator holds idle assets and executes rebalances. It maintains an approved list of ERC-4626 strategy contracts and handles swaps through a dedicated Swapper. Swaps enforce a nominal one-to-one exchange rate, with any slippage or venue fees covered by an external Slippage Coverage Vault rather than customer deposits. User deposits land idle on the Allocator and are allocated to strategies by the off-chain manager via rebalance() , so strategy-side issues such as supply cap breaches or paused markets do not block user deposits.\nThe Accounting Chain Gateway routes outbound funds and messages to Earning Chains and ingests inbound messages. It validates inbound message block numbers against the Chain Balance Oracle to preserve accounting integrity.\nEarning Chains # Copy\nEarning Chains (Ethereum mainnet initially) host yield strategies and the infrastructure needed to exchange IOUs for local assets and return funds to the Accounting Chain.\nFunds and messages move between the Accounting Chain and Earning Chains through multiple bridge providers, such as CCIP, LayerZero, Hyperlane, and Across, as well as potentially others, as long as their usage follows the protocol's security requirements.\nThe Earning Chain Gateway handles inbound bridge messages, exchanges IOU tokens for local assets against available liquidity, and pushes funds back to the Accounting Chain when needed. It computes price-weighted local balances using the same aggregation logic as the Funds Handler.\nThe Earning Chain State Provider exposes the local price-weighted balance in an encoded format that Chainlink operators read and publish to the Accounting Chain via the Chain Balance Oracle. Feed updates are triggered by specific on-chain events such as funds received or sent and asset trust status changes, by a configured deviation threshold, and by a fixed heartbeat interval. The Accounting Chain treats data older than the configured staleness threshold as zero, keeping the surplus accounting conservative.\nRoles & Access Controls # Copy\nThe protocol separates configuration authority from operational authority through a role hierarchy. Higher roles define the boundaries; lower roles operate within them.\nIntegrators hold the broadest authority. They configure the total trusted surface of the vault:\n-\nAssets : which stablecoins can be deposited, swapped, or used as withdrawal outputs (via the Asset Registry)\n-\nYield strategies : which ERC-4626 adapters are approved on the Allocator (e.g. Aave v4 markets, sGHO, or any other compliant vault)\n-\nBridges : which cross-chain bridge contracts are permitted for moving funds between the Accounting Chain and Earning Chains\nThese allowlists are additive: a manager can never access a strategy, asset, or bridge that the integrator has not explicitly approved.\nManagers operate within whatever the integrator has configured. A manager can:\n-\nCall rebalance() to shift allocations between approved yield strategies\n-\nInitiate bridge transfers to/from approved Earning Chains\n-\nAdjust yield allocations in response to changing market conditions\nManagers cannot modify the allowlists or claim protocol revenue, those actions are reserved for the integrator role.\nThis separation means a fintech deploying a vault can lock down protocol-level risk (which counterparties are trusted, which assets move) while safely delegating routine yield operations to an automated off-chain system or third-party manager without exposing configuration authority.\nRequest Integration\nPrevious\nFeatures\nNext\nYield Strategies"}
{"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-f6nn","verified":"exact","ts":1791171989459,"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://docs.layerzero.network/crosschain","domain":"docs.layerzero.network","title":"Crosschain Development - LayerZero","hash":"b779bde5dcf0e0e83afb2e7e2fcebda8882fa961b41f9417ff01f418311220b6","tokens":952,"chars":3805,"crawler":"crawler-f6nn","verified":"exact","ts":1791171992145,"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\nCrosschain Development\nBuild omnichain applications with LayerZero. Transfer tokens, compose crosschain operations, and send arbitrary messages across 150+ blockchains.\nLayerZero is an omnichain interoperability protocol that enables secure communication between different blockchains. You can transfer tokens, send arbitrary messages, or build custom crosschain applications on top of it.\nNew to LayerZero? If you want to understand how the protocol works before building, start with LayerZero Overview for a high-level introduction, or dive into Core Concepts for the technical details.\nWhat Can You Build?\nMost developers come to LayerZero for one of these use cases, ordered from most common to most advanced:\n1. Transfer Existing Crosschain Assets\nThe easiest path is integrating assets that already exist on LayerZero. Stargate has liquidity pools for USDC and ETH across 60+ chains. Other teams have issued OFTs like USDT0 , USDe , and WBTC that you can integrate directly.\nStargate Protocol\nUnified liquidity pools for ETH and USDC. No deployment needed.\nView Existing OFTs\nSee all OFT deployments (USDT0, USDe, WBTC, etc.) available to integrate.\n2. Issue Your Own Crosschain Asset\nDeploy your own Omnichain Fungible Token (OFT) that works natively across 150+ chains. OFTs maintain unified supply across all chains through debit/credit mechanisms. No bridges, no wrapped tokens.\nOFT Standard\nLearn how OFTs enable native crosschain token transfers.\nDeploy an OFT\nStep-by-step guide to issuing your own crosschain token.\n3. Compose Token Transfers with Logic\nComposers let you bundle a token transfer with calldata that executes on the destination chain. Send tokens and trigger a swap, deposit into a vault, or call any contract in a single crosschain transaction.\nOmnichain Composers\nCombine token transfers with arbitrary contract calls.\nOVault\nCrosschain vault standard for unified liquidity management.\n4. Build Custom Crosschain Systems\nLayerZero supports arbitrary message passing for developers who need complete control. You can build crosschain governance, oracles, games, or anything else.\nOApp Standard\nSend arbitrary data between contracts on any chain.\nlzRead\nPull data from other chains into your smart contracts.\nOApp and lzRead require more systems understanding. You’re designing the message format, handling edge cases, and building the receive logic yourself. Start with Stargate or OFTs if you just need token transfers.\nChoose Your Path\nI want to understand how it works first\nLearn the core concepts before building.\nI want to transfer existing tokens\nUse Stargate or integrate existing OFTs.\nI want to issue my own token\nDeploy OFTs across chains. Your token, unified supply.\nI want tokens + custom logic\nUse Composers to bundle transfers with contract calls.\nI want to build something custom\nUse OApp for arbitrary crosschain messaging.\nPlatform Support\nLayerZero supports multiple blockchain platforms with native implementations:\nPlatform Language Chains\nEVM Solidity Ethereum, Arbitrum, Optimism, Base, and 100+ more\nSolana Rust/Anchor Solana mainnet and devnet\nSui Move Sui mainnet\nIOTA Move IOTA L1\nAptos Move Aptos mainnet\nHyperliquid Solidity Hyperliquid L1\nDeveloper Resources\nCreate LZ OApp CLI\nBootstrap a new LayerZero project with our CLI tool.\nSample Projects\nExplore example implementations and reference code.\nSupported Chains\nView all supported networks and contract addresses.\nTroubleshooting\nDebug crosschain messages and resolve common errors.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.optimism.io/app-developers/guides/bridging/custom-bridge","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"34572466c6c342dbcaaeb3c7616cebdfae2ccb5cab657883327c47d81c52b4cf","tokens":589,"chars":2355,"crawler":"crawler-f6nn","verified":"exact","ts":1791171994859,"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\nBridging\nCustom bridges\nImportant considerations when building custom bridges for OP Mainnet.\nCustom token bridges are any bridges other than the Standard Bridge .\nYou may find yourself in a position where you need to build a custom token bridge because the Standard Bridge doesn’t completely support your use case.\nThis guide provides important information you should be aware of when building a custom bridge.\nCustom bridges can bring a significant amount of complexity and risk to any project.\nBefore you commit to a custom bridge, be sure that the Standard Bridge definitely does not support your use case.\nBuilding a custom bridged token is often sufficient for projects that need more flexibility.\nGuidelines\nCustom bridges can use any design pattern you can think of.\nHowever, with increased complexity comes increased risk.\nConsider directly extending or modifying the StandardBridge contract before building your own bridge contracts from scratch.\nDoing so will provide you with an audited foundation upon which you can add extra logic.\nIf you choose not to extend the StandardBridge contract, you may still want to follow the interface that the StandardBridge provides.\nBridges that extend this interface will be compatible with the Superchain Bridges UI .\nYou can read more about the design of the Standard Bridge in the guide on Using the Standard Bridge .\nThe Superchain Token List\nThe Superchain Token List exists to help users and developers find the right bridged representations of tokens native to another blockchain.\nOnce you’ve built and tested your custom bridge, make sure to register any tokens meant to flow through this bridge by making a pull request against the Superchain Token List repository .\nYou must deploy your bridge to OP Sepolia before it can be added to the Superchain Token List.\nNext steps\nYou can explore several examples of custom bridges for OP Mainnet:\n- NFT Bridge\n- L2 DAI Token Bridge and deployed addresses\n- SNX Bridge\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.helius.dev/solana-token-apis","domain":"www.helius.dev","title":"Solana Token APIs: Holders, Metadata, and Balances","hash":"48a65c81f09d7536d70d87dccc5c091f69639a785fbbbfb2d3d4190d7844c8b0","tokens":1369,"chars":5473,"crawler":"crawler-f6nn","verified":"exact","ts":1791171996875,"text":"---\ntitle: \"Solana Token APIs: Holders, Metadata, and Balances\"\ndescription: \"Every token. Every transaction. Instantly available. Trusted by Solana's leading wallets and DeFi applications.\"\ncanonical: \"https://www.helius.dev/solana-token-apis\"\nlast-updated: \"2025-12-02T21:15:15.969Z\"\n---\n# Solana Token APIs: Holders, Metadata, and Balances\n> Every token. Every transaction. Instantly available. Trusted by Solana's leading wallets and DeFi applications.\n## Solana's most powerful Token API\nAccess token metadata for all Solana tokens or check token balances, stats and transaction histories for any token on Solana.\n[Start for free](https://dashboard.helius.dev/signup) | [Documentation](https://www.helius.dev/docs/das-api)\n## Every token. Every transaction. Instantly available.\nAccess high-level token metadata and stats or track token balances and complete history of all transaction and token activities for any account with our Solana token APIs.\n## Get all tokens under an account with a single call\nAll you need is an account or wallet address and you'll instantly get a full list of every single token and their balances held by that account.\n- Supports SPL tokens and Token-2022\n- Fetch all tokens and balances in USD\n- Auto-updated with new activity\n## Get metadata for any fungible token\nReturn important token information including the account balance, program address, associated token address, total supply in circulation, price, and more.\n- Get verification status and token prices in USD\n- Supports SPL as well as Token22 extension\n- Backwards compatible with the original DAS API\n## Get all transactions associated with any token\nGet complete history for any token including every single transfer, swap, and application interaction across accounts.\n- Filtered by event type\n- Auto-updated with new activity\n## Parse token transactions to make them easy to read\nThe Parsed Events API decodes over 3,600 programs from their onchain IDLs to give you clear, structured data about what happened during transactions.\n- Named instructions, accounts, and every token transfer\n- Plain-language summaries for all named events\n- Parse signatures or wallet history (REST or GraphQL)\n## Solana Token APIs for every use case\n- **Wallets**: Get a complete view of all tokens held by an account including token and USD balances.\n- **Trading platforms**: Power your platform with reliable token metadata and important metrics like price, market cap, and holder count.\n- **Portfolio trackers**: Build user-friendly dashboards that enable users to track and analyze their token holdings.\n- **DeFi dashboards**: Track any token on Solana with granular transaction data. Monitor supply changes, holder distribution and transaction patterns.\n- **Blockchain explorers**: Build human-readable block explorers by extracting and parsing metadata and activity for any token.\n- **Token-gated experiences**: Gate access to your app based on token ownership. Verify holdings and transactions in real-time for seamless authorization.\n## Frequently Asked Questions\n### What token standards do Helius's Token APIs support?\nThe [DAS API](/docs/das-api) covers SPL Token and Token-2022, including Token-2022 extensions, plus regular NFTs and compressed NFTs. Plain SPL mints without metadata are included. One set of methods returns balances, supply, metadata, ownership, and USD prices for verified tokens. To read what a token transaction did, the [Parsed Events API](/parsed-data) decodes instructions from more than 3,600 programs.\n### How much do Helius's Token APIs cost?\nEvery DAS API request costs 10 credits. Each Parsed Events request also costs 10 credits. Both use the same monthly allowance as RPC: 1 million credits on Free ($0), 10 million on Developer ($49), 100 million on Business ($499), and 200 million on Professional ($999). Additional credits are $5 per million. See the [credits docs](/docs/billing/credits).\n### What are Helius's Token API rate limits?\nToken API calls use the DAS and Enhanced API limit, which is separate from RPC rate limits. That limit is 2 requests per second on Free, 10 on Developer, 50 on Business, and 100 on Professional. Enterprise limits are custom. See [rate limits](/docs/billing/rate-limits).\n### What is the difference between the DAS API and Parsed Events?\nThe DAS API returns the current state of an asset: balances, metadata, price, ownership, and search. Parsed Events turns a signature, or a wallet's history, into named instructions, accounts, token transfers, and a plain-language summary. Use DAS for holdings and token data, and Parsed Events to read what a transaction did. Docs: [DAS API](/docs/das-api) and [Parsed Events](/docs/parsed-events).\n### Can I fetch every token a wallet holds in one call?\nYes. Pass a wallet address to `getAssetsByOwner` and the DAS API returns the SPL and Token-2022 tokens that address holds, with balances. Verified tokens include a USD price. The walkthrough is in [get tokens](/docs/das/get-tokens).\n### How can I get started with the DAS API?\nTo get started, explore these resources:\n- [DAS API Documentation Overview](/docs/das-api)\n- [Get Tokens](/docs/das/get-tokens)\n- [DAS API Reference](/docs/api-reference/das)\n- [Get NFTs](/docs/das/get-nfts)\n- [Search Assets](/docs/das/search)\n## Ready to build?\nGet started in less than 10 seconds. No credit cards or email required.\n[Start for free](https://dashboard.helius.dev/signup)\n| [Learn more](https://www.helius.dev/docs/das-api)"}
{"url":"https://ethresear.ch/t/staking-rewards-as-venture-capital-governed-by-futarchy/26030","domain":"ethresear.ch","title":"Staking rewards as venture capital, governed by futarchy - Economics - Ethereum Research","hash":"e86ab62d1206dd8427f92b048595bce6d6148afc1ae4348d43b6d995a97e65b8","tokens":2736,"chars":10941,"crawler":"crawler-f6nn","verified":"exact","ts":1791171999553,"text":"Ethereum Research\nStaking rewards as venture capital, governed by futarchy\nEconomics\nfutarchy ,\ndao\nK1-R1\nSeptember 17, 2026, 6:56pm\n1\nTL;DR: An ETH-native VC DAO that turns staking rewards into venture capital, with investments chosen by futarchy and judged against real outcomes. Think Lido-style staking: principal stays staked, chosen rewards buy venture-vault shares. Shareholders risk those shares in prediction markets that choose investments. Funded projects’ results move shares from wrong forecasts to right ones and build a public reputation for judgement. The ambition is to outperform conventional VC by drawing on Ethereum’s builders and operators to find, judge and support ventures, while changing the risk-reward profile of staking and growing the value and use of ETH.\nRawVentures is the working name. This is an early proposal.\nTurn staking rewards into venture capital\nThe starting point is Lido-style staking, with a proposed integration that routes a chosen share of future rewards into an Ethereum venture vault. Those rewards buy portfolio shares as they arrive. Your staking principal stays staked, outside the venture vault.\nSuppose 100 ETH is staked and earns 3 ETH in net rewards. Its holder routes half the rewards to RawVentures. The holder keeps or compounds 1.5 ETH, and the other 1.5 ETH buys vault shares. Those shares represent ownership of the venture portfolio and a claim on its returns.\nThis changes the chosen rewards’ risk–reward profile. Instead of keeping or compounding all the income from staking, the holder uses part of it to pursue venture returns. That capital could remain illiquid for years or be lost; vault shares would not offer redemption on demand. The underlying staking position retains its own risks.\nFor the vault, voluntary reward routing could provide recurring investment capital. Routing 1% of Ethereum’s estimated annual staking rewards would supply roughly 10,800 ETH—about $27 million a year at the 17 September 2026 snapshot.\nDirect ETH contributions could buy the same portfolio shares. The aim is to earn strong returns for the vault while backing ventures that increase the value and use of ETH.\nFutarchy chooses investments. Outcomes build reputation\nVault shareholders use prediction markets to choose what RawVentures funds. Their own vault shares are at risk if they are wrong. We call this Reputational Futarchy : the market chooses the investment, then actual outcomes settle the forecasts and build a record of who was right.\nMetaDAO is a useful reference: its decision markets compare conditional token prices. RawVentures instead proposes markets settled against declared project outcomes after funding.\nConsider an Ethereum settlement business seeking 100 ETH and help reaching customers, offering the vault a revenue share in return. Shareholders forecast the return on that investment and milestones that would help assess the business’s prospects. For example:\nIf funded on these terms, will three independent enterprise customers use the product in production for 90 consecutive days within the next year?\nThe proposal sets the deal terms, forecast questions, deadlines and evidence before trading. Forecasts could also examine the ETH demand generated by customer activity: the business could earn revenue for the vault while its customers create recurring economic use for ETH.\nShareholders back their forecasts with existing vault shares. A selection rule uses those positions to choose between proposals: fund Project A, Project B, both or neither, subject to available capital and portfolio limits. Larger holdings matter only when more shares are risked; passive ownership carries no vote. The exact market format and selection rule still need to be designed.\nIf the business is funded, the committed shares remain locked until the agreed outcomes can be checked. An illustrative settlement for the customer forecast:\nYour position\nCustomer target met\nCustomer target missed\nYES\nGain shares from incorrect NO positions\nLose committed shares\nNO\nLose committed shares\nGain shares from incorrect YES positions\nPayouts follow the agreed rule and redistribute existing committed shares; they create no new shares or dilution for passive holders.\nSeparately, revenue paid by the business accrues to the vault and benefits the portfolio. Forecast winnings and investment returns are distinct: a correct customer forecast can earn shares even if the investment ultimately loses money.\nThe same evidence builds a public record of who forecast what and how it turned out. Across funded investments, that could help people recognise useful judgement and decide whose analysis deserves attention. Reputation starts as a track record, without extra market weight or authority. Getting a forecast right is evidence about that judgement, not proof that the investment was the best available choice.\nPositions on proposals that are not funded unlock without outcome payouts or accuracy records. We have not observed what those projects would have achieved with the proposed funding.\nWhy this could be a better investor\nThe opportunity is to build an investor owned by people who know and use the ecosystem it invests in.\nBuilders and operators close to Ethereum can recognise promising work, introduce teams and judge what founders need. The vault gives contributors shared ownership of the portfolio they help source and support. They have a financial interest in bringing good opportunities to the network and helping those ventures succeed.\nRawVentures competes as an Ethereum specialist: capital plus technical review and practical help from people who understand the protocol. That could include protocol introductions and help reaching customers. The ambition is to become a preferred source of capital for strong founders. Earning that preference could give the vault access to investments it would otherwise miss. Successful founders could then introduce further projects, talent and operating knowledge.\nRecurring rewards could give that network a continuing source of capital to invest. Within it, futarchy puts additional financial consequences behind individual investment judgements, and public forecasting records make those judgements easier to assess. The bet is that this combination can improve both which investments the vault secures and what it does with them.\nThe investment-performance test is better risk-adjusted ETH-denominated returns after costs than conventional VC. The wider ambition is to back ventures that strengthen ETH’s economic use. Good forecasting alone would not establish an investment advantage.\nDeveloping the idea\nThe next work is to design and test the reward route, markets and evidence process. Open questions include pricing new contributions into an illiquid portfolio, making informed forecasting worthwhile while resisting manipulation, and verifying project outcomes independently of those with money riding on them.\nThe combination also has to justify its costs and long forecast lock-ups against a simpler fund with expert allocation and advisory forecasts. We need to learn whether stakers want this exposure and whether founders value the capital and support enough to choose it.\nI’d like to hear what you make of the idea, and from anyone interested in helping develop it. Useful introductions welcome.\nrawventures-ethereum-research-footer 1536×1024 188 KB\nFritzDVL\nSeptember 29, 2026, 11:12pm\n2\nReally clean design. The best part is how cleanly you separate the market decision from the individual reputation that comes with being right. People constantly conflate those.\nStrip away the staking and vault shares, and this is essentially futarchy applied to an individual org. Which makes me wonder how far that extends. If it works for a VC vault, it works for guilds, research collectives, or cities. The mechanism just needs skin in the game and something to forecast.\nI’ve been thinking about what happens when this primitive (identity + history + risked judgment) becomes shared infrastructure. Portable reputation across multiple orgs with different value systems, tied to a single verifiable actor.\nThe open questions scale with it, though:\n-\nOracle verification gets harder, not easier.\n-\nValuing new contributions to illiquid assets is still tough.\n-\nGlobal reputation risks becoming a rigid caste system without decay.\nBut having a concrete benchmark—outperforming traditional VC on risk-adjusted ETH returns—is a huge win. Almost no governance designs have a measurable success condition like that.\nHow are you thinking about the line between RawVentures and the generalized case?\nI’m building along similar lines at Society Protocol, happy to share notes if you want, but mainly just wanted to drop a note saying “reputational futarchy” is a great framing.\n1 Like\nK1-R1\nOctober 1, 2026, 10:08pm\n3\nThanks, Fritz. I agree on those open questions.\nRawVentures is where I’d start, but I agree and I’d want to keep taking it into other assets and resource allocation settings. That could begin as other capital allocation scenarios with similar concrete benchmarks and similar decision making for easier shared reputation infra. But if this is successful I think it becomes a strong contender for most resource allocation governance scenarios where the necessary criteria is viable.\nThe key for me is whether we can meaningfully tie the decisions to outcomes we can forecast and verify.\nEthereum has builders and operators who could judge ventures they understand and help them succeed. That’s a big part of why I’d start here. The return benchmark you highlight also gives us something concrete to test. I suspect we’d discover a superset of necessary criteria required for an instance of reputational Futarchy to be successful, which can then be applied elsewhere.\nI’ve been doing a lot of work on reputation and credibility, and I’m exploring the shared infrastructure side too. The important question is what someone earned their reputation for . I’m sceptical of a universal score: being good at forecasting venture outcomes doesn’t automatically make someone good at judging a city’s budget. I’d want several measures attached to one account, with the questions, timing, odds, capital risked and outcomes behind each one still available.\nEach instance would choose its own goals and decide which parts of that history matter to it. As people participate across different organisations, those records could start to form the shared infrastructure. I’d keep the full history and give recent evidence more weight, so someone’s reputation can change as they learn and move into new areas.\nFor RawVentures, we need to verify outcomes independently and work out fair entry pricing for an illiquid portfolio. I’d add the question of how we reward useful forecasts on proposals we don’t fund. We don’t get to see what our funding would have achieved.\nI’d be very happy to DM and chat on all this.\n1 Like"}
{"url":"https://docs.anza.xyz/operations/setup-a-validator","domain":"docs.anza.xyz","title":"Setup an Agave Validator | Agave","hash":"025506074663359b0eced63da77362481531f82ff5f318c7ace7351e8a636658","tokens":4454,"chars":17813,"crawler":"crawler-f6nn","verified":"exact","ts":1791172002122,"text":"Skip to main content\nSetup an Agave Validator\nThis is a guide for getting your validator setup on the Solana testnet cluster\nfor the first time. Testnet is a Solana cluster used for performance\ntesting of the software before the software is used on mainnet. Since testnet is\nstress tested daily, it is a good cluster to practice validator operations.\nOnce you have a working validator on testnet, you will want to learn about\noperational best practices in the next section.\nAlthough the guide is specific to testnet, it can be adapted to mainnet or\ndevnet as well.\nRefer to the Available Clusters section of the\ndocumentation to see example commands for each cluster.\nNow let's get started.\nOpen The Terminal Program\nTo start this guide, you will be running commands on your trusted computer, not\non the remote machine that you plan to use for validator operations. First,\nlocate the terminal program on your trusted computer .\n- on Mac, you can search for the word terminal in spotlight.\n- on Ubuntu, you can type CTRL + Alt + T .\n- on Windows, you will have to open the command prompt as an Administrator.\nInstall The Solana CLI Locally\nValidator operators are required to install the tools included in the Solana CLI using the installation instructions .\nOnce the Solana CLI is installed, you can return to this document once you are\nable to run two commands and get an answer on your terminal.\nFirst, run the following command to verify that the Solana CLI is installed:\nsolana --version\nYou should see an output that looks similar to this (note your version number\nmay be higher):\nsolana-cli 1.14.17 (src:b29a37cf; feat:3488713414)\nNow, run the following command to verify that the agave-validator binary is\ninstalled:\nagave-validator --version\nYou should see an output that looks similar to this (note your version number\nmay be higher):\nagave-validator 2.3.1 (src:e3eca4c1; feat:3640012085, client:Agave)\nOnce you have successfully installed the cli and validator binary, the next step is to change your\nconfig so that it is making requests to the testnet cluster:\nsolana config set --url https://api.testnet.solana.com\nTo verify that your config has changed, run:\nsolana config get\nYou should see a line that says: RPC URL: https://api.testnet.solana.com\nCreate Keys\nOn your local computer, create the 3 keypairs that you will need to run your\nvalidator ( docs for reference ):\nNOTE Some operators choose to make vanity keypairs for their identity and\nvote account using the grind sub command\n( docs for reference ).\nsolana-keygen new -o validator-keypair.json\nsolana-keygen new -o vote-account-keypair.json\nsolana-keygen new -o authorized-withdrawer-keypair.json\nIMPORTANT the authorized-withdrawer-keypair.json should be considered\nvery sensitive information. Many operators choose to use a multisig, hardware\nwallet, or paper wallet for the authorized withdrawer keypair. A keypair is\ncreated on disk in this example for simplicity. Additionally, the withdrawer\nkeypair should always be stored safely. The authorized withdrawer keypair\nshould never be stored on the remote machine that the validator software\nruns on. For more information, see\nvalidator security best practices\nCreate a Vote Account\nBefore you can create your vote account, you need to configure the Solana\ncommand line tool a bit more.\nThe below command sets the default keypair that the Solana CLI uses to the\nvalidator-keypair.json file that you just created in the terminal:\nsolana config set --keypair ./validator-keypair.json\nNow verify your account balance of 0 :\nsolana balance\nNext, you need to deposit some SOL into that keypair account in order create a\ntransaction (in this case, making your vote account):\nsolana airdrop 1\nNOTE The airdrop sub command does not work on mainnet, so you will have\nto acquire SOL and transfer it into this keypair's account if you are setting\nup a mainnet validator.\nNow, use the Solana cluster to create a vote account.\nAs a reminder, all commands mentioned so far should be done on your trusted\ncomputer and NOT on a server where you intend to run your validator. It is\nespecially important that the following command is done on a trusted\ncomputer :\nsolana create-vote-account -ut \\\n--fee-payer ./validator-keypair.json \\\n./vote-account-keypair.json \\\n./validator-keypair.json \\\n./authorized-withdrawer-keypair.json\nNote -ut tells the cli command that we would like to use the testnet\ncluster. --fee-payer specifies the keypair that will be used to pay the\ntransaction fees. Both flags are not necessary if you configured the solana\ncli properly above but they are useful to ensure you're using the intended\ncluster and keypair.\nAfter SIMD-0387 has been activated on your cluster, set the BLS public key for\nyour vote account before starting the validator. Follow the\nBLS public key instructions .\nSave the Withdrawer Keypair Securely\nMake sure your authorized-withdrawer-keypair.json is stored in a safe place.\nIf you have chosen to create a keypair on disk, you should first backup the\nkeypair and then delete it from your local machine.\nIMPORTANT : If you lose your withdrawer key pair, you will lose control of\nyour vote account. You will not be able to withdraw tokens from the vote account\nor update the withdrawer. Make sure to store the\nauthorized-withdrawer-keypair.json securely before you move on.\nSSH To Your Validator\nConnect to your remote server. This is specific to your server but will look\nsomething like this:\nssh user@\nYou will have to check with your server provider to get the correct user account\nand hostname that you will ssh into.\nUpdate Your Ubuntu Packages\nMake sure you have the latest and greatest package versions on your server\nsudo apt update\nsudo apt upgrade\nSol User\nCreate a new Ubuntu user, named sol , for running the validator:\nsudo adduser sol\nIt is a best practice to always run your validator as a non-root user, like the\nsol user we just created.\nHard Drive Setup\nOn your Ubuntu computer make sure that you have at least 2TB of disk space\nmounted. You can check disk space using the df command:\ndf -h\nIf you have a drive that is not mounted/formatted, you will have to set up the\npartition and mount the drive.\nTo see the hard disk devices that you have available, use the list block devices\ncommand:\nlsblk -f\nYou may see some devices in the list that have a name but do not have a UUID.\nAny device without a UUID is unformatted.\nDrive Formatting: Ledger\nAssuming you have an nvme drive that is not formatted, you will have to format\nthe drive and then mount it.\nFor example, if your computer has a device located at /dev/nvme0n1 , then you\ncan format the drive with the command:\nsudo mkfs -t ext4 /dev/nvme0n1\nFor your computer, the device name and location may be different.\nNext, check that you now have a UUID for that device:\nlsblk -f\nIn the fourth column, next to your device name, you should see a string of\nletters and numbers that look like this: 6abd1aa5-8422-4b18-8058-11f821fd3967 .\nThat is the UUID for the device.\nMounting Your Drive: Ledger\nSo far we have created a formatted drive, but you do not have access to it until\nyou mount it. Make a directory for mounting your drive:\nsudo mkdir -p /mnt/ledger\nNext, change the ownership of the directory to your sol user:\nsudo chown -R sol:sol /mnt/ledger\nNow you can mount the drive:\nsudo mount /dev/nvme0n1 /mnt/ledger\nFormatting And Mounting Drive: AccountsDB\nYou will also want to mount the accounts db on a separate hard drive. The\nprocess will be similar to the ledger example above.\nAssuming you have a device at /dev/nvme1n1 , format the device and verify it\nexists:\nsudo mkfs -t ext4 /dev/nvme1n1\nThen verify the UUID for the device exists:\nlsblk -f\nCreate a directory for mounting:\nsudo mkdir -p /mnt/accounts\nChange the ownership of that directory:\nsudo chown -R sol:sol /mnt/accounts\nAnd lastly, mount the drive:\nsudo mount /dev/nvme1n1 /mnt/accounts\nSystem Tuning\nLinux\nYour system will need to be tuned to run properly. Your validator may\nnot start without the settings below.\nOptimize sysctl knobs\nsudo bash -c \"cat >/etc/sysctl.d/21-agave-validator.conf </etc/security/limits.d/90-solana-nofiles.conf <:\nscp vote-account-keypair.json sol@:\nNote : The vote-account-keypair.json does not have any function other\nthan identifying the vote account to potential delegators. Only the public key\nof the vote account is important once the account is created.\nSwitch to the sol User\nOn the validator server, switch to the sol user:\nsu - sol\nInstall agave-validator on Remote Machine\nYour remote machine will need agave-validator installed to run the Agave validator\nsoftware. For simplicity, install the application with user sol . Refer again to\nbuild from source .\nCreate A Validator Startup Script\nIn your sol home directory (e.g. /home/sol/ ), create a folder called bin .\nInside that folder create a file called validator.sh and make it executable:\nmkdir -p /home/sol/bin\ntouch /home/sol/bin/validator.sh\nchmod +x /home/sol/bin/validator.sh\nNext, open the validator.sh file for editing:\nnano /home/sol/bin/validator.sh\nCopy and paste the following contents into validator.sh then save the file:\n#!/bin/bash\nexec agave-validator \\\n--identity /home/sol/validator-keypair.json \\\n--vote-account /home/sol/vote-account-keypair.json \\\n--known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \\\n--known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \\\n--known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \\\n--known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \\\n--only-known-rpc \\\n--log /home/sol/agave-validator.log \\\n--ledger /mnt/ledger \\\n--accounts /mnt/accounts \\\n--rpc-port 8899 \\\n--dynamic-port-range 8000-8020 \\\n--entrypoint entrypoint.testnet.solana.com:8001 \\\n--entrypoint entrypoint2.testnet.solana.com:8001 \\\n--entrypoint entrypoint3.testnet.solana.com:8001 \\\n--expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \\\n--wal-recovery-mode skip_any_corrupted_record \\\n--limit-ledger-size\nRefer to agave-validator --help for more information on what each flag is\ndoing in this script. Also refer to the section on\nbest practices for operating a validator .\nThis startup script is specifically intended for testnet. For more startup script examples intended for other clusters, refer to the\nclusters section. .\nVerifying Your Validator Is Working\nTest that your validator.sh file is running properly by executing the\nvalidator.sh script:\n/home/sol/bin/validator.sh\nThe script should execute the agave-validator process. In a new terminal\nwindow, ssh into your server, then verify that the process is running:\nps aux | grep agave-validator\nYou should see a line in the output that includes agave-validator with all\nthe flags that were added to your validator.sh script.\nNext, we need to look at the logs to make sure everything is operating properly.\nTailing The Logs\nAs a spot check, you will want to make sure your validator is producing\nreasonable log output ( warning , there will be a lot of log output).\nIn a new terminal window, ssh into your validator machine, switch users to the\nsol user and tail the logs:\nsu - sol\ntail -f agave-validator.log\nThe tail command will continue to display the output of a file as the file\nchanges. You should see a continuous stream of log output as your validator\nruns. Keep an eye out for any lines that say _ERROR_ .\nAssuming you do not see any error messages, exit out of the command.\nGossip Protocol\nGossip is a protocol used in the Solana clusters to communicate between\nvalidator nodes. For more information on gossip, see\nGossip Service . To verify that your validator is\nrunning properly, make sure that the validator has registered itself with the\ngossip network.\nIn a new terminal window, connect to your server via ssh. Identify your\nvalidator's pubkey:\nsolana-keygen pubkey ~/validator-keypair.json\nThe command solana gossip lists all validators that have registered with the\nprotocol. To check that the newly setup validator is in gossip, we will grep\nfor our pubkey in the output:\nsolana gossip | grep \nAfter running the command, you should see a single line that looks like this:\n139.178.68.207 | 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on | 8001 | 8004 | 139.178.68.207:80 | 1.14.17 | 3488713414\nIf you do not see any output after grep-ing the output of gossip, your validator\nmay be having startup problems. If that is the case, start debugging by looking\nthrough the validator log output.\nSolana Validators\nAfter you have verified that your validator is in gossip, you should stake some\nSOL to your validator. Once the stake has activated (which happens at the start\nof the next epoch), you can verify that your validator is ready to be a voting\nparticipant of the network with the solana validators command. The command\nlists all validators in the network, but like before, we can grep the output\nfor the validator we care about:\nsolana validators | grep \nYou should see a line of output that looks like this:\n5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on FX6NNbS5GHc2kuzgTZetup6GZX6ReaWyki8Z8jC7rbNG 100% 197434166 ( 0) 197434133 ( 0) 2.11% 323614 1.14.17 2450110.588302720 SOL (1.74%)\nSolana Catchup\nThe solana catchup command is a useful tool for seeing how quickly your\nvalidator is processing blocks. The Solana network has the capability to produce\nmany transactions per second. Since your validator is new to the network, it has\nto ask another validator (listed as a --known-validator in your startup\nscript) for a recent snapshot of the ledger. By the time you receive the\nsnapshot, you may already be behind the network. Many transactions may have been\nprocessed and finalized in that time. In order for your validator to participate\nin consensus, it must catchup to the rest of the network by asking for the\nmore recent transactions that it does not have.\nThe solana catchup command is a tool that tells you how far behind the network\nyour validator is and how quickly you are catching up:\nsolana catchup \nIf you see a message about trying to connect, your validator may not be part of\nthe network yet. Make sure to check the logs and double check solana gossip\nand solana validators to make sure your validator is running properly.\nOnce you are happy that the validator can start up without errors, the next step\nis to create a system service to run the validator.sh file automatically. Stop\nthe currently running validator by pressing CTRL+C in the window where\nvalidator.sh is running.\nCreate a System Service\nFollow these instructions for\nrunning the validator as a system service\nMake sure to implement log rotate as well. Once you have the system service\nconfigured, start your validator using the newly configured service:\nsudo systemctl enable --now sol\nNow verify that the validator is running properly by tailing the logs and using\nthe commands mentioned earlier to check gossip and Solana validators:\ntail -f /home/sol/agave-validator*.log\nMonitoring\nagave-watchtower is a command you can run on a separate machine to monitor\nyour server. You can read more about handling\nautomatic restarts and monitoring\nusing Agave Watchtower here in the docs.\nCommon issues\nOut of disk space\nMake sure your ledger is on drive with at least 2TB of space.\nValidator not catching up\nThis could be a networking/hardware issue, or you may need to get the latest\nsnapshot from another validator node.\nPoH hashes/second rate is slower than the cluster target\nIf you are using agave-validator built from source, ensure that you are using a release build and not a debug build\nEnsure that your machine's CPU base clock speed is 2.8GHz or faster. Use lscpu to check your clock speed. CPU(s) scaling MHz can cause your clock speed to be underclocked. Some additional tuning:\nSet performance governor\necho performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor\nForce minimum frequency to maximum\n# Example if your maximum GHz is 2.8\necho 2850000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq\n- Open The Terminal Program\n- Install The Solana CLI Locally\n- Create Keys\n- Create a Vote Account\n- Save the Withdrawer Keypair Securely\n- SSH To Your Validator\n- Update Your Ubuntu Packages\n- Sol User\n- Hard Drive Setup\n- Drive Formatting: Ledger\n- Mounting Your Drive: Ledger\n- Formatting And Mounting Drive: AccountsDB\n- System Tuning\n- Linux\n- Copy Key Pairs\n- Switch to the sol User\n- Install agave-validator on Remote Machine\n- Create A Validator Startup Script\n- Verifying Your Validator Is Working\n- Tailing The Logs\n- Gossip Protocol\n- Solana Validators\n- Solana Catchup\n- Create a System Service\n- Monitoring\n- Common issues\n- Out of disk space\n- Validator not catching up\n- PoH hashes/second rate is slower than the cluster target"}
{"url":"https://bitcoin.org/fr/vocabulaire","domain":"bitcoin.org","title":"Vocabulaire - Bitcoin","hash":"105c5b62c0fa26e825cdda1ac0042b5861725b1e9ecc87c1e1cdaa746cd502d0","tokens":2747,"chars":10986,"crawler":"crawler-f6nn","verified":"exact","ts":1791172004080,"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- Particuliers\n- Entreprises\n- Développeurs\n- Débuter\n- Comment ça marche\n- Vous devez savoir\n- Ressources\n- Exchanges\n- Communauté\n- BIPs list\n- Vocabulaire\n- Bitcoin Core\n- Innovation\n- Participer\n- Soutenir Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Développement\n- FAQ\n- Français\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: fr\nQuelques mots que vous pourriez entendre\nBitcoin est une nouvelle approche des paiements, et ainsi certains mots nouveaux pourraient entrer dans votre dictionnaire. Ne vous en faites pas, même l'humble télévision a créé de nouveaux mots !\n- Bitcoin\n- BTC\n- Satoshi\n- Bit\n- Adresse\n- Portefeuille\n- Clé privée\n- Recovery Phrase\n- Signature\n- Cryptographie\n- P2P\n- Node\n- Chaine de blocs\n- Bloc\n- UTXO\n- Transaction Fee\n- Minage\n- Taux de hachage\n- Halving\n- Confirmation\n- Double dépense\n- SegWit\n- Taproot\n- Lightning Network\nBitcoin\nBitcoin - avec une majuscule, est utilisé pour décrire le concept du Bitcoin ou le réseau lui-même. Ex. \"Je me suis intéressé au protocole Bitcoin aujourd'hui\"\nbitcoin - sans majuscule, est utilisé pour désigner les bitcoins en tant qu'unité de compte. Ex. \"J'ai envoyé dix bitcoins aujourd'hui\". On le retrouve souvent sous sa forme abrégée BTC ou XBT.\nBTC\nBTC est une unité courante pour désigner un bitcoin (₿).\nSatoshi\nA satoshi is the smallest unit of bitcoin recorded on the blockchain. One bitcoin is equal to 100,000,000 satoshis, allowing very small payments to be expressed precisely. The unit is named after Bitcoin's pseudonymous creator, Satoshi Nakamoto.\nBit\nBit est une unité courante utilisée pour désigner une sous-unité d'un bitcoin - 1 000 000 bits est égal à 1 bitcoin (BTC or ₿). Cette unité est souvent plus pratique pour fixer les prix des pourboires, des biens et des services.\nAdresse\nUne adresse Bitcoin est similaire à une adresse physique ou une adresse courriel . Il s'agit de la seule information que vous avez besoin de fournir pour que quelqu'un vous paie avec Bitcoin. Une différence importante toutefois, est que chaque adresse Bitcoin ne devrait être utilisée que pour une seule transaction.\nPortefeuille\nUn portefeuille Bitcoin est vaguement l' équivalent d'un portefeuille physique sur le réseau Bitcoin . Un portefeuille contient en fait vos clés privées qui vous permettent de dépenser les bitcoins qui leurs sont associées dans la chaine de blocs . Chaque portefeuille Bitcoin peut afficher le solde de tous les bitcoins qu'il contrôle et vous permet de payer un montant spécifique à une personne spécifique, de la même façon qu'un vrai portefeuille. Ce qui est différent des cartes de crédit où le commerçant vous facture directement.\nClé privée\nUne clé privée est une information secrète qui prouve votre droit de dépenser des bitcoins à partir d'un portefeuille défini grâce à une signature cryptographique. Vos clés privées sont stockées dans votre ordinateur si vous utilisez un portefeuille logiciel, tandis qu'elles sont stockées sur quelques serveurs en ligne si vous utilisez un portefeuille Web. Les clés privées ne doivent jamais être révélées car elles permettent de dépenser les bitcoins de leur portefeuille respectif.\nRecovery Phrase\nA recovery phrase, also called a seed phrase or mnemonic, is a sequence of words from which a wallet can be fully restored . It allows the owner to back up and restore an entire wallet without copying individual keys. The recovery phrase must be stored securely, since anyone who obtains it can access the corresponding bitcoins.\nSignature\nUne signature cryptographique est un mécanisme mathématique qui permet à quelqu'un de prouver sa propriété . Dans le cas de Bitcoin, un portefeuille Bitcoin et ses clés privées sont liés par la magie des mathématiques. Quand votre logiciel Bitcoin signe une transaction avec la clé privée appropriée, le réseau entier peut voir que la signature correspond aux bitcoins dépensés. Cependant, il n'existe aucun moyen de deviner votre clé privée afin de voler vos bitcoins durement gagnés.\nCryptographie\nLa cryptographie est une branche des mathématiques qui permet de créer des preuves mathématiques qui offrent un haut niveau de sécurité . Les commerces et banques en ligne utilisent déjà la cryptographie. Avec Bitcoin, la cryptographie est utilisée pour empêcher quiconque de dépenser les fonds provenant du portefeuille d'un autre utilisateur et pour empêcher la corruption de la chaine de blocs . Elle peut aussi être utilisée pour chiffrer un portefeuille afin qu'il ne puisse être utilisé qu'avec un mot de passe.\nP2P\nPair à pair fait référence à des systèmes qui fonctionnent comme une collectivité organisée en permettant à chaque individu d'interagir directement avec les autres. Dans le cas de Bitcoin, le réseau est construit de manière à ce que chaque utilisateur diffuse les transactions des autres utilisateurs. Et, chose cruciale, aucune banque n'est requise en tant que tierce partie.\nNode\nA Bitcoin node is any computer that connects to the Bitcoin network . A full node independently downloads and verifies every block and transaction against the consensus rules, allowing its operator to use Bitcoin without trusting third parties. Running a full node is a key practice for verifying the Bitcoin protocol firsthand.\nChaine de blocs\nLa chaine de blocs est un journal public de toutes les transactions Bitcoin par ordre chronologique. Elle est partagée entre tous les utilisateurs du réseau Bitcoin. Elle est utilisée pour vérifier la permanence des transactions Bitcoin et empêcher la double dépense .\nBloc\nUn bloc est un enregistrement dans la chaine de blocs qui contient et confirme plusieurs transactions en attente . Toutes les 10 minutes, en moyenne, un nouveau bloc contenant des transactions est ajouté à la chaine de blocs par le minage .\nUTXO\nUTXO stands for Unspent Transaction Output . Bitcoin balances are not stored as account totals; instead, each wallet holds a set of UTXOs that can be spent in future transactions. Every transaction consumes existing UTXOs as inputs and creates new UTXOs as outputs.\nTransaction Fee\nA transaction fee is a small amount of bitcoin paid by the sender to incentivize miners to include the transaction in a block . Fees are not fixed; users can choose how much to pay, and transactions with higher fees tend to be confirmed faster, especially when the network is busy.\nMinage\nLe minage de bitcoins est l'utilisation de matériel informatique pour effectuer des calculs mathématiques pour le réseau Bitcoin afin de confirmer des transactions et d'augmenter la sécurité. Comme récompense pour leurs services, les mineurs de bitcoins peuvent recevoir les frais de transaction pour les transactions qu'ils confirment et pour les bitcoins nouvellement créés. Le minage est un marché spécialisé compétitif où les récompenses sont divisées en fonction du nombre de calculs effectués. Tous les utilisateurs de Bitcoin ne font pas de minage et il ne s'agit pas d'une manière facile pour faire de l'argent.\nTaux de hachage\nLe taux de hachage est l' unité de mesure de la puissance de traitement du réseau Bitcoin . Le réseau Bitcoin doit faire des calculs mathématiques intensifs pour des raisons de sécurité. Quand le réseau a atteint un taux de hachage de 10 Th/s, ceci signifiait que le réseau pouvait faire 10 billions de calculs par secondes.\nHalving\nThe halving is the scheduled reduction by half of the block subsidy , occurring every 210,000 blocks (roughly every four years). The block subsidy started at 50 BTC in 2009 and has halved at each event since. The halving enforces Bitcoin's predictable issuance schedule and its 21-million-coin supply cap.\nConfirmation\nUne confirmation signifie qu'une transaction a été traitée par le réseau et que ses chances d'être renversée sont quasiment inexistantes . Les transactions reçoivent une confirmation lorsqu'elles sont incluses dans un bloc et pour chaque bloc subséquent. Même une seule confirmation peut offrir une sécurité suffisante pour de petites transactions, alors que pour de plus grandes sommes telles que 1 000 $, il est prudent d'attendre 6 confirmations ou plus. Chaque confirmation diminue exponentiellement le risque d'un renversement de transaction.\nDouble dépense\nSi un utilisateur mal intentionné essaie de dépenser ses bitcoins auprès de deux destinataires différents au même moment , il s'agit d'une double dépense. Le minage et la chaine de blocs existent pour créer un consensus dans le réseau afin de décider laquelle des deux transactions sera confirmée et considérée valide.\nSegWit\nSegregated Witness (SegWit) is a protocol upgrade activated in 2017 that separates signature data from transaction data . It improves block space efficiency, fixes transaction malleability, and provides the foundation for second-layer protocols such as the Lightning Network. SegWit addresses commonly start with 3 (P2SH-wrapped) or bc1q (native SegWit).\nTaproot\nTaproot is a protocol upgrade activated in 2021 that improves Bitcoin's privacy, efficiency, and scripting flexibility . It introduces Schnorr signatures and enables more efficient and private transactions. Taproot addresses commonly start with bc1p .\nLightning Network\nThe Lightning Network is a second-layer payment protocol built on top of Bitcoin that enables fast, low-cost transactions through payment channels. Channels open and close on the Bitcoin blockchain, while payments between participants happen off-chain without each one being recorded individually.\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroduction:\n-\nParticuliers\n-\nEntreprises\n-\nDéveloppeurs\n-\nDébuter\n-\nComment ça marche\n-\nVous devez savoir\nRessources:\n-\nRessources\n-\nExchanges\n-\nCommunauté\n-\nBIPs list\n-\nVocabulaire\n-\nBitcoin Core\nParticiper:\n-\nSoutenir Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nDéveloppement\nOther:\nLégal\nPrivacy Policy\nPresse\nÀ propos de bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Publié sous la licence MIT\nNetwork Status\n- Français\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- 繁體中文\nfr"}
{"url":"https://bitcoin.org/ca/recursos","domain":"bitcoin.org","title":"Recursos - Bitcoin","hash":"e562ef5d16192c6a1ec2970d1ebec63ab0e474cd223383b63f528219bb34a8b7","tokens":688,"chars":2751,"crawler":"crawler-f6nn","verified":"exact","ts":1791172006208,"text":"Bitcoin.org necessita el teu suport!\nBitcoin.org és un projecte finançat per la comunitat, les donacions s'agraeixen i s'utilitzen per millorar el lloc web.\nFeu una donació a Bitcoin.org\nUtilitzeu aquest codi QR o adreça a continuació\nSend with Bitcoin\nBitcoin only · On-chain\nOpen in wallet\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nPrefill an amount (optional)\nBTC amount\nUSD amount\nAdd an optional wallet note\nDescripció opcional (per a la teva cartera)\n- Introducció\n- Persones\n- Empreses\n- Desenvolupadors\n- Inicia't\n- Com funciona\n- Necessites saber\n- Paper blanc\n- Recursos\n- Intercanvis\n- Comunitat\n- BIPs list\n- Vocabulari\n- Bitcoin Core\n- Innovació\n- Participa\n- Dóna suport a Bitcoin\n- Comprar Bitcoin\n- Sell Bitcoin\n- Desenvolupament\n- FAQ\n- Català\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: ca\nRecursos de Bitcoin\nLlocs web i recursos útils sobre Bitcoin.\nRecursos d'aprenentatge\nLearn Me A Bitcoin\nBitcoin Basics\nJameson Lopp's Bitcoin Resources\nBitcoin Resources by Gigi\nBennet.org\nWiki Bitcoin\nBitcoiner.Guide\nSatoshi Nakamoto Institute\nBitcoinProjects.net\nGràfics i estadístiques\nmempool.space\nBitbo\nCheckOnChain\nBitcoin Deaths\nLightning Network\nLightning Network whitepaper\nJameson Lopp's Lightning Resources\nMastering the Lightning Network\nLightning specifications (BOLTs)\nLND\nCore Lightning\nEclair\nLightning Dev Kit\nDocumentals\nGod Bless Bitcoin\nThe Bitcoin Phenomenon\nBitcoin: Beyond The Bubble\nMagic Money: The Bitcoin Revolution\nPodcasts\nBitcoin Audible\nBitcoin Collective Podcast\nCoin Stories Podcast\nStephan Livera Podcast\nWhat Bitcoin Did\nVals\nBitrefill\nGalaxy Mind\nBTCMap.org\nFor Developers\nBitcoin Optech\nBitcoin Core\nSuporta Bitcoin.org:\nDóna\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroducció:\n-\nPersones\n-\nEmpreses\n-\nDesenvolupadors\n-\nInicia't\n-\nCom funciona\n-\nNecessites saber\n-\nPaper blanc\nRecursos:\n-\nRecursos\n-\nIntercanvis\n-\nComunitat\n-\nBIPs list\n-\nVocabulari\n-\nBitcoin Core\nParticipa:\n-\nDóna suport a Bitcoin\n-\nComprar Bitcoin\n-\nSell Bitcoin\n-\nDesenvolupament\nAltres:\nLegal\nPrivacy Policy\nPremsa\nSobre bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 publicat sota la llicència MIT\nEstat de la xarxa\n- Català\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- 繁體中文\nca"}
{"url":"https://ethereum.org/wallets/find-wallet/","domain":"ethereum.org","title":"List of Ethereum wallets: compare by feature | ethereum.org","hash":"0111be560843f80a8c01ae76273ec8fd8bb21553ba984c6cc237414201868943","tokens":1562,"chars":6246,"crawler":"crawler-f6nn","verified":"exact","ts":1791172008937,"text":"Skip to main content\nList of Ethereum wallets: compare by feature\nWallets store and transact your ETH. You can choose from a variety of products that tailor to your needs.\nBrowse wallets by user type\n- New to crypto ( 5 ) 5 available First time user looking for beginner wallet.\n- Developer ( 13 ) 13 available Wallets that help develop and test dapps.\n- Finance ( 28 ) 28 available Wallets focusing on frequent usage of DeFi apps.\n- Hardware ( 9 ) 9 available Passive token holding with hardware wallets.\n- NFTs ( 35 ) 35 available Wallets with focus on NFT support.\nBrowse all wallets\nWallets found : 48 / 48\nClave\nMobile\nEnglish\nSwap fee: 0.5%\nEdge Wallet\nFinance\nDesktop · Mobile\nEnglish · Spanish\nSwap fee: 0.5% – 2%\nCoin Wallet\nFinance\nDesktop · Mobile\nEnglish · Indonesian\nSwap fee: 0%\nInfinex Wallet & Crypto Superapp\nNFTs\nBrowser\nEnglish\nSwap/bridge fee: 0.03% – 0.3%\nMEW wallet\nNew to crypto\nNFTs\nMobile\nEnglish · Russian\nSwap fee: variable\nReady Wallet\nFinance\nNFTs\nMobile · Browser\nEnglish\nSwap fee: 0.5%\n1inch Wallet\nFinance\nNFTs\nMobile\nEnglish · Russian\nSwap fee: variable\nBitget wallet\nFinance\nNFTs\nMobile · Browser\nEnglish · Chinese\nSwap fee: variable\nPhantom\nFinance\nMobile · Browser\nEnglish · Spanish\nSwap fee: 0.85%\nBridge wallet\nMobile\nEnglish · French\nSwap fee: 0.5%, Buy/sell fee: 0.6% – 3.8%\nOneKey\nNew to crypto\nDeveloper\nFinance\nHardware\nNFTs\nDesktop · Mobile · Browser · Hardware\nEnglish · Chinese\nSwap/bridge fee: 0.85%\nBlockWallet\nDeveloper\nFinance\nBrowser\nEnglish\nSwap/bridge fee: 0.5%\nSafe\nFinance\nNFTs\nMobile\nEnglish\nSwap fee: 0.05% – 0.7%, Staking fee: 20% of rewards\nimKey Pro Hardware Wallet\nDeveloper\nFinance\nHardware\nNFTs\nDesktop · Mobile · Browser · Hardware\nEnglish · Chinese\nDevice: $110, Swap fee: 0%\nTaho\nFinance\nNFTs\nBrowser\nEnglish\nSwap fee: 0.5%\nCoin98 Super Wallet\nFinance\nNFTs\nMobile · Browser\nEnglish · Vietnamese\nSwap fee: 0.5% (0.1% for stablecoins)\nExodus\nFinance\nDesktop · Mobile · Browser\nEnglish\nSwap fee: from 0.5%\nRailway Wallet\nDesktop · Mobile\nEnglish\nShield/unshield fee: 0.25%\nUniswap Wallet\nNFTs\nMobile · Browser\nEnglish · Spanish\nSwap fee: 0%\nFrame\nDeveloper\nFinance\nNFTs\nDesktop · Browser\nEnglish\nTrust Wallet\nDeveloper\nFinance\nNFTs\nMobile · Browser\nEnglish · Arabic\nBuy fee: set by the provider\nLoopring wallet\nNFTs\nMobile\nEnglish · Chinese\nSwap fee: 0.3%\nCoinbase Wallet\nNew to crypto\nFinance\nNFTs\nMobile · Browser\nEnglish · German\nSwap fee: 1%\nUnstoppable wallet\nDeveloper\nNFTs\nMobile\nEnglish · French\nSwap fee: 0%\nBurner\nHardware\nNFTs\nDesktop · Mobile · Browser · Hardware\nEnglish\nDevice: $19/card, Swap fee: not disclosed\nZerion Wallet\nNew to crypto\nDeveloper\nFinance\nNFTs\nDesktop · Mobile · Browser\nEnglish · Russian\nSwap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the provider\nio.finnet MPC wallet for Business\nNFTs\nMobile\nEnglish\nFree tier, paid plans from $399.99/month\nRabby Wallet\nDeveloper\nFinance\nNFTs\nDesktop · Mobile · Browser\nEnglish · German\nSwap fee: 0.25%\nGem Wallet\nDeveloper\nNFTs\nDesktop · Mobile\nEnglish · Spanish\nSwap fee: 0%, Buy fee: set by the provider\nRainbow\nNew to crypto\nFinance\nNFTs\nMobile · Browser\nEnglish · Spanish\nSwap fee: 0.85%\nAlphaWallet\nNFTs\nMobile\nEnglish · Chinese\nSwap fee: 0%\nGridPlus Lattice1\nHardware\nNFTs\nDesktop · Browser · Hardware\nEnglish\nDevice: $397\nCypherock X1\nHardware\nNFTs\nDesktop · Hardware\nEnglish · German\nDevice: $99 – $179\nPillarX\nNFTs\nMobile\nEnglish\nSwap fee: 1%\nFoxWallet\nNFTs\nMobile · Browser\nEnglish · Chinese\nSwap fee: 0%\nTrezor\nFinance\nHardware\nDesktop · Mobile · Hardware\nEnglish · Spanish\nDevice: $59 – $129, Swap fee: variable\nLedger\nFinance\nHardware\nNFTs\nDesktop · Mobile · Hardware\nEnglish · Arabic\nDevice: $79 – $399, Swap fee: variable\nShapeShift\nFinance\nMobile · Browser\nEnglish · Spanish\nSwap/bridge fee: 0.5% (free under $1,000, FOX-holder discounts)\nKeystone\nHardware\nEnglish · Chinese\nDevice: $149\nMetaMask\nFinance\nNFTs\nMobile · Browser\nEnglish · Amharic\nSwap/bridge fee: 0.875%, Buy/sell fee: 1%\nNuFi\nFinance\nNFTs\nBrowser\nEnglish\nSwap fee: 0.75%\nTokenPocket\nFinance\nHardware\nNFTs\nMobile · Browser · Hardware\nEnglish · Arabic\nSwap fee: not disclosed (TPT-holder discounts)\nimToken\nDeveloper\nFinance\nNFTs\nMobile\nEnglish · Chinese\nSwap fee: 0.3% (0.04% stablecoins, lower on L2s)\nClear Wallet\nDeveloper\nBrowser\nEnglish\nAmbire\nDeveloper\nFinance\nNFTs\nBrowser\nEnglish\nSwap/bridge fee: 0.5%\nBraavos\nNFTs\nMobile · Browser\nEnglish\nSwap fee: 0%\nEnkrypt\nNFTs\nBrowser\nEnglish\nSwap fee: variable\nCake Wallet\nDeveloper\nFinance\nDesktop · Mobile\nEnglish · Spanish\nSwap fee: variable\nHow we evaluate wallets\nEvery wallet on this page is reviewed by the ethereum.org team before being listed. We apply a published set of criteria focused on security, self-custody, and Ethereum-native support so users can navigate the ecosystem with greater confidence.\nRead the full listing criteria and removal policy\nCurated by the ethereum.org editorial team.\nMost recent listing update: July 8, 2026\nTo be listed, a wallet must meet the following requirements:\n- Security-tested through audit, an internal security team, or open-source code review.\n- Been live for at least six months, or built by a team with an established track record.\n- Actively maintained, with support available for users.\n- Provides honest, accurate listing information. Products that falsify details are removed.\n- Has a named point of contact so we can verify information when it changes.\n- Supports EIP-1559 (type 2) transactions on Ethereum Mainnet.\n- Offers a reviewable user experience. If our team finds a product difficult to use, we may request improvements before listing it.\n- Is Ethereum-focused, with Ethereum or a Layer 2 set as the default network.\nListings are not static. Wallet providers are required to resubmit information every six months. If a team does not respond, we remove the wallet. This keeps the directory accurate as products evolve.\nFilter toggles on this page (open source, self-custody, hardware wallet support, and others) reflect attributes tracked per wallet. Each listing also shows the date its information was last verified.\nWallets listed on this page are not official endorsements, and are provided for informational purposes only.\nTheir descriptions have been provided by the wallet projects themselves."}
{"url":"https://docs.ethena.fi/video-guides/how-to-stake-usde","domain":"docs.ethena.fi","title":"How to Stake USDe | Ethena","hash":"a6aed98fcaa83cad0f937d7965d71edd71b1487d3b35b5ef8ecb8fc24f60546a","tokens":664,"chars":2655,"crawler":"crawler-f6nn","verified":"exact","ts":1791172011711,"text":"⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nHow to Stake USDe\nStaking USDe enables holders to receive the protocol's generated rewards\nThe information contained in the following video or on this website is not directed at persons with their habitual residence or registered office in the European Union, European Economic Area, or United Kingdom.\nUsers in permitted jurisdictions can stake & unstake USDe / sUSDe via the UI.\nUsing the UI, the staking & unstaking USDe / sUSDe user workflow is:\n-\nThe user requests to stake/unstake USDe / sUSDe via the dApp interface by clicking \"Stake\"/\"Unstake\", which pops up their selected wallet to sign the requested transaction.\n-\nAfter the user signs the transaction with their wallet, the transaction is submit to the blockchain.\n-\nUpon successful confirmation of the transaction, the user receives sUSDe / USDe as their USDe / sUSDe is atomically swapped via autonomous smart contract.\nImportant to Note\n-\nUsers do NOT need to do anything but hold sUSDe to accrue rewards.\n-\nRewards aren’t earned directly by sUSDe holders; rather, they accumulate within the staking contract, which results in the \"value\" of sUSDe rising over time in USDe terms. Users are able to unstake their s USDe at any time, at which point they receive an amount USDe reflecting the staked amount plus any increase from the time the user staked until unstaking.\n-\nThe amount of sUSDe a user will receive when staking USDe will depend on the current value of sUSDe. At launch the value was 1 sUSDe = 1 USDe , and sUSDe is expected to slowly increase in value in USDe terms as protocol discretionary rewards are transferred into the Staking smart contract.\n-\nThis is because sUSDe was implemented using a token vault mechanism to provide protocol level incentive rewards to permitted users. This mechanic is similar to Rocketpool's rETH .\n-\nTherefore, while a staker might receive less sUSDe than USDe staked, the value of the sUSDe in USDe terms will always be equal to or greater than the USDe staked.\n-\nsUSDe is subject to a cooldown period before USDe can be withdrawn. The cooldown is dynamic (currently between 1 and 7 days) depending on reserve conditions; the current parameters are set by governance.\nUsers can only receive a positive or zero rewards holding sUSDe . The value of sUSDe will NOT decline, even in periods where the protocol is earning negative income, as the protocol does not and cannot remove assets from the staking contract. Such periods are expected to be covered by the Reserve Fund, to be discussed later.\nLast updated 2 months ago\nWas this helpful?"}
{"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":"crawler-f6nn","verified":"exact","ts":1791172014161,"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 / 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://docs.marinade.finance/marinade-protocol/protocol-overview","domain":"docs.marinade.finance","title":"Protocol Overview | Marinade Documentation","hash":"27688d053ea836ab6d8071232d1c03a194d182b86c25a3a19e6c20fe62096f0d","tokens":1115,"chars":4460,"crawler":"crawler-f6nn","verified":"exact","ts":1791172016679,"text":"Marinade Documentation\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nProtocol Overview\nMarinade Finance was built to bring to life a vision. A non-custodial liquid staking solution on Solana, decentralizing the network.\nWhat Can You Do on Marinade?\nMarinade offers flexible staking options and tools to manage your SOL across different formats:\nMarinade Native\nStake SOL or deposit a stake account directly into Marinade while retaining full control. Your stake stays entirely on-chain in stake accounts your own wallet owns, and is automatically delegated through Marinade's Stake Auction Marketplace , which matches stake with high-performing validators in a permissionless, market-driven process.\nYou can also migrate your existing native staked accounts into Marinade to benefit from automated delegation and performance optimization.\nMarinade Select\nA premium staking set powered by Marinade. It includes a vetted group of community-recognized validators that meet strict criteria for performance, compliance, and decentralization.\nMarinade Select is not currently available to stake to. Staking new SOL to Select is not offered in the app at the moment. Existing Select positions are unaffected: they keep earning and can still be unstaked at any time. To stake new SOL today, use Marinade Native .\nMarinade Liquid\nStake SOL or deposit a stake account to receive mSOL, a liquid staking token that can be used throughout the Solana DeFi ecosystem.\nYou can also swap other liquid staking tokens into mSOL, or convert mSOL and other staking positions back to SOL through immediate or delayed unstaking.\nMarinade Recipes\nStake SOL the Marinade Native way, but have your staking rewards paid out in a token of your choice instead of SOL. Your stake accounts stay in your own wallet.\nUSDC Earn Vault\nDeposit USDC into a curated lending vault and earn on stablecoins, with no lockup and instant withdrawal. Withdrawals depend on available liquidity in the underlying lending markets and can be limited when utilization is high.\nMarinade Borrow\nBorrow against your mSOL without unstaking or converting it first.\nInstant Unstake\nExit a staking position in a single transaction instead of waiting out the unlock period, at a market-set rate. On native stake, Instant Unstake needs a position of 1 SOL or more. mSOL has no such minimum.\nWhat's So Special About Marinade Native?\nMarinade Native provides a secure, non-custodial staking experience with:\n-\nFull ownership of your SOL at all times. Your wallet keeps the withdraw authority , so only you can move the SOL out\n-\nNo Marinade contract ever holds your SOL. Marinade takes only the stake authority , which can delegate, split and merge your stake accounts but can never withdraw from them\n-\nAutomatic validator delegation and rebalancing\n-\nRedelegate existing stake accounts without unstaking\n-\nUnstake anytime, with two exits. Instant Unstake returns SOL in a single transaction at a market-set rate and needs a position of 1 SOL or more on native stake. Delayed Unstake works at any size on Marinade Native and Select (mSOL has a 1.0043 SOL minimum) and becomes claimable after one epoch. Native has no start-time cut-off. For mSOL, starting in the last 2 hours of an epoch makes the claim one epoch later\n-\nCommunity-led governance through the Marinade DAO\nMarinade Native is non-custodial , not contract-free. Delegation is routed through Marinade's Native Staking Proxy program, which holds the stake authority through PDAs. See Marinade Native: API & SDK for the program and authority addresses.\nThere is no deposit fee and no ongoing management fee on Marinade Native. Exiting a position does carry a cost: see Fees and Pricing.\nWhat's So Special About Marinade Liquid?\nStaking with Marinade for mSOL offers several unique advantages:\n-\nStake SOL and receive mSOL, which grows in value with rewards\n-\nUse mSOL in DeFi for collateral, trading, or yield strategies, including Marinade Borrow\n-\nConvert an existing stake account into mSOL, if it is delegated to a validator in Marinade's validator set (otherwise migrate it to Marinade Native)\n-\nTrade mSOL on secondary markets at market rates\n-\nNo performance fee on staking rewards. Marinade takes 0% of the rewards the pool earns\nDelayed unstaking of mSOL carries a 0.2% protocol fee. See Fees and Pricing.\nPrevious Official Links\nNext Marinade Native\nLast updated 2 days ago\nWas this helpful?"}
{"url":"https://wormhole.com/docs/products/token-transfers/wrapped-token-transfers/concepts/transfer-flow/","domain":"wormhole.com","title":"Flow of Wrapped Token Transfers (WTT) | Wormhole Docs","hash":"ec33e540ded2d613bfcb0fce639372ed30c7e81cea57c02ee3a80ca6b9452939","tokens":2329,"chars":9316,"crawler":"crawler-f6nn","verified":"exact","ts":1791172018933,"text":"Skip to content\nInitializing search\n- Configuration\n- Concepts\n- FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\n- Tutorials\n- Concepts\n- WTT Relayer (TBR)\n- Next Steps\n- Payload Structure\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- WTT Relayer (TBR)\n- Next Steps\nFlow of a WTT Transfer ＃\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nThe Wormhole Wrapped Token Transfers (WTT) enables token transfers across blockchains by combining token-specific logic with Wormhole's core messaging layer . Each supported chain runs its own WTT contract, which manages actions such as locking, burning, minting, and releasing tokens. These contracts communicate directly with Wormhole's core message-passing layer to securely transmit messages between chains.\nThis guide provides a conceptual overview of WTT and its integration with the messaging layer. It outlines each step of the transfer flow and explains how different transfer types work in practice.\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.\nTransfer Flow ＃\nCross-chain token transfers using WTT follow these steps:\n-\nInitiation on the Source Chain\nThe transfer begins when a user calls the WTT contract on the source chain:\n- Wrapped tokens : The token is burned.\n- Original tokens : If the token is native to the source chain, the token is locked in the contract.\n-\nTransfer Message Publication\nThe WTT contract invokes the Wormhole Core Contract , which emits an on-chain message event describing the transfer.\n-\nMessage Observation and Signing\nGuardians —a decentralized network of validators—monitor the source chain for these message events. A supermajority (13 out of 19) signs the event to generate a Verified Action Approval (VAA) —a cryptographically signed attestation of the transfer.\nThe VAA is then published to the Wormhole network.\n-\nVAA Submission to the Destination Chain\nThe VAA must be submitted to the WTT contract on the destination chain to complete the transfer. The WTT contract then verifies the VAA by calling the Core Contract behind the scenes. This step can be handled in two ways:\n- Automatic : A relayer service detects the VAA and submits it to the WTT contract.\n- Manual : The user or dApp retrieves the VAA and submits it directly to the WTT contract.\n-\nFinalization of the Transfer on the Destination Chain\nAfter the VAA is verified on the destination chain, the WTT contract completes the transfer:\n- Wrapped tokens : A wrapped representation of the original token is minted.\n- Original tokens : If the token is native to the destination chain, the token is released to the recipient.\nConsider this example: Alice wants to send 5 ETH from Ethereum to Solana. The ETH is locked on Ethereum’s WTT, and an equivalent amount of wrapped ETH is minted on Solana. The diagram below illustrates this transfer flow.\nsequenceDiagram\nparticipant Alice as Alice\nparticipant WTTEth as WTT Ethereum
(Source Chain)\nparticipant CoreEth as Core Contract Ethereum
(Source Chain)\nparticipant Guardians\nparticipant WTTSol as WTT Solana
(Destination Chain)\nparticipant CoreSol as Core Contract Solana
(Destination Chain)\nAlice->>WTTEth: Initiate ETH transfer
(lock ETH)\nWTTEth->>CoreEth: Publish transfer message\nCoreEth-->>Guardians: Emit message event\nGuardians->>Guardians: Sign and publish VAA\nalt Automatic VAA submission\nGuardians->>WTTSol: Relayer submits VAA\nelse Manual VAA submission\nAlice->>Guardians: Retrieve VAA\nAlice->>WTTSol: Submit VAA\nend\nWTTSol->>CoreSol: Verify VAA\nCoreSol-->>WTTSol: VAA verified\nWTTSol-->>Alice: Mint wrapped ETH on Solana (complete transfer)\nMaybe Alice wants to transfer her wrapped ETH on Solana back to native ETH on Ethereum. The wrapped ETH is burned on Solana’s WTT, and the equivalent 5 ETH are released on Ethereum. The diagram below illustrates this transfer flow.\nsequenceDiagram\nparticipant User as Alice\nparticipant WTTSrc as WTT Solana
(Source Chain)\nparticipant CoreSrc as Core Contract Solana
(Source Chain)\nparticipant Guardians\nparticipant WTTDst as WTT Ethereum
(Destination Chain)\nparticipant CoreDst as Core Contract Ethereum
(Destination Chain)\nUser->>WTTSrc: Initiate transfer
(burn wrapped ETH)\nWTTSrc->>CoreSrc: Publish message\nCoreSrc-->>Guardians: Emit message event\nGuardians->>Guardians: Sign and publish VAA\nalt Automatic VAA submission\nGuardians->>WTTDst: Relayer submits VAA\nelse Manual VAA submission\nUser->>Guardians: Retrieve VAA\nUser->>WTTDst: User submits VAA directly\nend\nWTTDst->>CoreDst: Verify VAA\nCoreDst-->>WTTDst: VAA verified\nWTTDst-->>User: Release native ETH on Ethereum (Complete transfer)\nAutomatic vs. Manual Transfers ＃\nWTT supports two modes of transfer, depending on whether the VAA submission step is handled automatically or manually:\n- Automatic : A relayer service listens for new VAAs and automatically submits them to the destination chain.\n- Manual : The user (or dApp) must retrieve the VAA and manually submit it to the destination chain.\nHere's a quick breakdown of the key differences:\nFeature Automatic Transfer Manual Transfer\nWho submits the VAA? Relayer User or dApp\nUser Experience Seamless, one-step Requires manual intervention\nBest for End-users, simple UIs Custom dApps, advanced control\nDependency Requires relayer support None\nCompleting Manual Transfers ＃\nThe user who initiated the transfer must complete it within 24 hours for manual transfers. Guardian Sets are guaranteed to be valid for at least that long. If a user waits longer, the Guardian Set may have changed between initiation and redemption, causing the VAA to be rejected.\nIf this occurs, follow the Replace Outdated Signatures in VAAs tutorial to update the VAA with signatures from the current Guardian Set.\nWTT Relayer (TBR) ＃\nWhen completing an automatic transfer using WTT, either through Connect or programmatically via the Wormhole TypeScript SDK , the WTT Relayer (TBR) manages the interaction with the underlying WTT contracts on supported chains where the TBR is available .\nFlow of an Automatic Transfer via TBR ＃\nThe flow of an automatic transfer using the TBR looks like this:\n-\nInitiation on the Source Chain\nThe transfer begins when a user initiates a transfer on the source chain, which results in the TBR contract being called.\n-\nPrepare and Forward the Transfer\nThe TBR verifies the token, encodes transfer details (relayer fee, native gas request, recipient), and forwards the transfer to WTT.\n-\nCore Messaging Layer Processes the Transfer\nWTT emits a message to the Core Contract. Guardians observe the message and produce a signed VAA attesting to the transfer.\n-\nOff-Chain Relayer Observes the VAA\nAn off-chain relayer verifies the destination chain and token registration and then prepares to complete the transfer.\n-\nRelayer Computes Native Drop-Off and Submits the VAA\nThe relayer queries the destination TBR for the native gas amount, includes it in the transaction, and submits the signed VAA.\n-\nTBR Validates and Completes the Transfer\nThe destination TBR validates the VAA by invoking the WTT contract, confirms it's from a registered TBR, verifies the token and native gas request, and then takes custody of the tokens.\n-\nAsset Distribution on the Destination Chain\nThe TBR sends the remaining tokens and native gas to the user, pays the off-chain relayer fee, and refunds any excess native tokens.\nThe following diagram illustrates the key steps in the source chain during a transfer:\nsequenceDiagram\nparticipant User\nparticipant SourceTBR as Source Chain TBR\nparticipant SourceWTT as Source Chain WTT\nparticipant Messaging as Core Messaging Layer\nUser->>SourceTBR: Initiate transfer (token,
recipient, fees, native gas)\nSourceTBR->>SourceWTT: Forward transfer (burn or lock tokens)\nSourceWTT->>Messaging: Publish transfer message\nOnce the core messaging layer processes the transfer, the destination chain handles completion as shown below:\nsequenceDiagram\nparticipant Messaging as Core Messaging Layer\nparticipant Relayer as Off-chain Relayer\nparticipant DestTBR as Destination Chain TBR\nparticipant DestWTT as Destination Chain
WTT\nparticipant DestUser as User
(Destination Chain)\nMessaging->>Relayer: Emit signed VAA for transfer\nRelayer->>Relayer: Verifies destination chain and token registration\nRelayer->>DestTBR: Query native gas amount\nRelayer->>DestTBR: Submit signed VAA\nDestTBR->>DestWTT: Validate VAA\nDestTBR->>DestTBR: Take custody of tokens\nDestTBR->>DestUser: Send tokens (after fees & native gas)\nDestTBR->>Relayer: Pay relayer fee & refund excess\nNext Steps ＃\nNow that you’ve seen how a transfer works, try both types yourself to experience the full process.\n-\nGet Started with WTT\nPerform token transfers using WTT, including manual and automatic transfers.\nGet Started\nLast update: September 28, 2026\n| Created: September 28, 2026"} {"url":"https://docs.optimism.io/app-developers/quickstarts/get-started","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"bf723b4a58f7ae8ae448c4e6d40ab2bd1c82685fca622415607ff6d997d2a531","tokens":857,"chars":3428,"crawler":"crawler-f6nn","verified":"exact","ts":1791172021364,"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\nBuild an app\nApp developer quickstart\nGet testnet ETH, deploy your first contract to OP Sepolia, and bridge assets - your first steps on the Superchain.\nOP Stack chains are EVM equivalent : everything you know from Ethereum works here, and everything you build here works across the OP Stack ecosystem.\nThis quickstart takes you from zero to a deployed contract on the OP Sepolia testnet, using only free testnet funds.\nNo real funds are needed at any point — everything below runs on testnets.\nBefore you start\nYou’ll need:\n- A wallet you control (any EVM wallet works; you’ll export or generate a private key for testnet use only).\n- A terminal with curl available.\nUse a fresh, testnet-only private key for tutorials. Never paste a key that holds real funds into a terminal.\n1\nGet testnet ETH\nGrab free OP Sepolia ETH from the Superchain Faucet .\nOther options are listed on the testnet faucets page .\n2\nConnect to OP Sepolia\nOP Sepolia’s public RPC endpoint is https://sepolia.optimism.io and its chain ID is 11155420 .\nVerify you can reach it:\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n--data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_chainId\",\"params\":[],\"id\":1}' \\\nhttps://sepolia.optimism.io\nExpected result: {\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0xaa37dc\"} ( 0xaa37dc = 11155420).\nFor other networks and production-grade endpoints, see network information and RPC providers .\n3\nDeploy your first contract\nFollow the Deploy a contract to OP Sepolia tutorial.\nIt walks you through installing Foundry, deploying a small Greeter contract, and reading and writing to it from the command line — the same workflow you’d use on Ethereum.\n4\nBridge ETH between L1 and L2 (optional)\nApps often need to move assets between Ethereum and an OP Stack chain.\nStart with Bridging basics to understand the model, then follow the Bridging ETH with Viem tutorial to do a Sepolia → OP Sepolia deposit programmatically.\nWhere to go next\nBuild apps on OP Stack chains\nDevelopment workflow, tooling, and what (little) is different from Ethereum.\nTest your apps\nTest against OP Stack chains locally and in CI.\nGo cross-chain with interop\nBuild apps that span multiple Superchain chains.\nIntegrate DeFi with the Actions SDK\nLend, borrow, and swap with lightweight, type-safe modules (early preview — not production-ready).\nRunning your app in production A production application depends on infrastructure your team does not run: RPC endpoints that hold up under real traffic (the public endpoints are rate-limited and not built for production), bridges your users rely on, and a chain whose operator keeps sequencing, upgrades, and incident response going around the clock. These docs cover building and testing. If your application is growing toward dedicated blockspace of its own, OP Enterprise offers managed and supported paths to running a chain. These docs stay the reference for what you build either way. OP Enterprise is Optimism’s managed offering.\nNeed help?\n- Ask a question or report documentation issues on the Optimism monorepo issue tracker .\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."} {"url":"https://docs.anza.xyz/validator/blockstore","domain":"docs.anza.xyz","title":"Blockstore in a Solana Validator | Agave","hash":"5e552ebfff5dd7f90146ba8bb66a2068043e6299205ec42e2ed2ee95d72e407b","tokens":1608,"chars":6429,"crawler":"crawler-f6nn","verified":"exact","ts":1791172025435,"text":"Skip to main content\nBlockstore in a Solana Validator\nAfter a block reaches finality, all blocks from that one on down to the genesis block form a linear chain with the familiar name blockchain. Until that point, however, the validator must maintain all potentially valid chains, called forks . The process by which forks naturally form as a result of leader rotation is described in fork generation . The blockstore data structure described here is how a validator copes with those forks until blocks are finalized.\nThe blockstore allows a validator to record every shred it observes on the network, in any order, as long as the shred is signed by the expected leader for a given slot.\nShreds are moved to a fork-able key space the tuple of leader slot + shred index (within the slot). This permits the skip-list structure of the Solana protocol to be stored in its entirety, without a-priori choosing which fork to follow, which Entries to persist or when to persist them.\nRepair requests for recent shreds are served out of RAM or recent files and out of deeper storage for less recent shreds, as implemented by the store backing Blockstore.\nFunctionalities of Blockstore\n-\nPersistence: the Blockstore lives in the front of the nodes verification\npipeline, right behind network receive and signature verification. If the\nshred received is consistent with the leader schedule (i.e. was signed by the\nleader for the indicated slot), it is immediately stored.\n-\nRepair: repair is the same as window repair above, but able to serve any\nshred that's been received. Blockstore stores shreds with signatures,\npreserving the chain of origination.\n-\nForks: Blockstore supports random access of shreds, so can support a\nvalidator's need to rollback and replay from a Bank checkpoint.\n-\nRestart: with proper pruning/culling, the Blockstore can be replayed by\nordered enumeration of entries from slot 0. The logic of the replay stage\n(i.e. dealing with forks) will have to be used for the most recent entries in\nthe Blockstore.\nBlockstore Design\n-\nEntries in the Blockstore are stored as key-value pairs, where the key is the concatenated slot index and shred index for an entry, and the value is the entry data. Note shred indexes are zero-based for each slot (i.e. they're slot-relative).\n-\nThe Blockstore maintains metadata for each slot, in the SlotMeta struct containing:\n-\nslot_index - The index of this slot\n-\nnum_blocks - The number of blocks in the slot (used for chaining to a previous slot)\n-\nconsumed - The highest shred index n , such that for all m < n , there exists a shred in this slot with shred index equal to n (i.e. the highest consecutive shred index).\n-\nreceived - The highest received shred index for the slot\n-\nnext_slots - A list of future slots this slot could chain to. Used when rebuilding\nthe ledger to find possible fork points.\n-\nlast_index - The index of the shred that is flagged as the last shred for this slot. This flag on a shred will be set by the leader for a slot when they are transmitting the last shred for a slot.\n-\nis_connected - True iff every block from 0...slot forms a full sequence without any holes. We can derive is_connected for each slot with the following rules. Let slot(n) be the slot with index n , and slot(n).is_full() is true if the slot with index n has all the ticks expected for that slot. Let is_connected(n) be the statement that \"the slot(n).is_connected is true\". Then:\nis_connected(0) is_connected(n+1) iff (is_connected(n) and slot(n).is_full()\n-\nChaining - When a shred for a new slot x arrives, we check the number of blocks ( num_blocks ) for that new slot (this information is encoded in the shred). We then know that this new slot chains to slot x - num_blocks .\n-\nSubscriptions - The Blockstore records a set of slots that have been \"subscribed\" to. This means entries that chain to these slots will be sent on the Blockstore channel for consumption by the ReplayStage. See the Blockstore APIs for details.\n-\nUpdate notifications - The Blockstore notifies listeners when slot(n).is_connected is flipped from false to true for any n .\nBlockstore APIs\nThe Blockstore offers a subscription based API that ReplayStage uses to ask for entries it's interested in. These subscription API's are as follows:\n-\nfn get_slots_since(slots: &[u64]) -> Result>> : Returns slots that are connected to any of the elements of slots . This method enables the discovery of new children slots.\n-\nfn get_slot_entries(slot: Slot, shred_start_index: u64) -> Result> : For the specified slot , return a vector of the available, contiguous entries starting from shred_start_index . Shreds are fragments of serialized entries so the conversion from entry index to shred index is not one-to-one. However, there is a similar function get_slot_entries_with_shred_info() that returns the number of shreds that comprise the returned entry vector. This allows a caller to track progress through the slot.\nNote: Cumulatively, this means that the replay stage will now have to know when a slot is finished, and subscribe to the next slot it's interested in to get the next set of entries. Previously, the burden of chaining slots fell on the Blockstore.\nInterfacing with Bank\nThe bank exposes to replay stage:\n-\nprev_hash : which PoH chain it's working on as indicated by the hash of the last entry it processed\n-\ntick_height : the ticks in the PoH chain currently being verified by this bank\n-\nvotes : a stack of records that contains:\n- prev_hashes : what anything after this vote must chain to in PoH\n- tick_height : the tick height at which this vote was cast\n- lockout period : how long a chain must be observed to be in the ledger to be able to be chained below this vote\nReplay stage uses Blockstore APIs to find the longest chain of entries it can hang off a previous vote. If that chain of entries does not hang off the latest vote, the replay stage rolls back the bank to that vote and replays the chain from there.\nPruning Blockstore\nOnce Blockstore entries are old enough, representing all the possible forks becomes less useful, perhaps even problematic for replay upon restart. Once a validator's votes have reached max lockout, however, any Blockstore contents that are not on the PoH chain for that vote for can be pruned, expunged.\n- Functionalities of Blockstore\n- Blockstore Design\n- Blockstore APIs\n- Interfacing with Bank\n- Pruning Blockstore"}
{"url":"https://www.metaplex.com/founders","domain":"www.metaplex.com","title":"For Founders | Metaplex","hash":"7308d8e7ece7bf50164c4b2c6b25c5ec180884a32f6ba4f1da9894f1e6a746ae","tokens":2100,"chars":8397,"crawler":"crawler-f6nn","verified":"exact","ts":1791172028069,"text":"Metaplex\n- Home\n- Pulse\n- Trending\n- Watchlist\n- Agents Beta\n- Developers\n- Support\n- Twitter\n- Discord\nFor Founders For Founders\nFor founders\nLaunch your token the right way.\nThe leading launch protocol on Solana built for fair and customizable token sales. Proven and battle-tested across nine major launches with over $13M in primary sale value.\nApply for Spotlight Launch a Token\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\n$14B+\ncumulative trading volume\n$13M+\nprimary sale value\n9\nproject token sales\n$470M+\ncombined FDV\n1B+\ntransactions powered\n$10B+\ntransaction value\nWhy Metaplex\nM e t a p l e x i s w h e r e a s s e t s o n S o l a n a m o v e f r o m l a u n c h t o a c t i v e m a r k e t s , w i t h i s s u a n c e a n d l i v e t r a d i n g a l l i n o n e p l a t f o r m .\nBattle-tested token launches.\nOur infrastructure has supported near-instant sellouts, high-traffic launch pools, and dynamic pricing auctions. Proven across 9 launches with over $13M in primary sale value.\nApply for Spotlight Launch a Token\n$13.3B+\nCumulative trading volume\n9\nProject token sales\n$13M+\nPrimary sale value\n$470M+\nCombined FDV\nSpotlight is a hands-on launch path.\nAccepted projects get hands-on technical and go-to-market support from launch setup through go-live. Projects retain full control over their tokenomics and sale terms.\n-\n1\nMarketing and BD\nCo-marketing across the Metaplex ecosystem, GTM support, and partner introductions.\n-\n2\nDevelopment and integration\nTechnical support with sale configuration, custom launch pages, SDK integration, and liquidity migration using available Metaplex launch mechanics.\n-\n3\nLaunch mechanics\nGuidance on the launch mechanics available through Metaplex Genesis, including sale formats, allowlists, onchain configuration, and launch operations.\nLaunch Mechanics\nPick the sale that is right for you and your launch.\nLaunch Pool\nTime-based price discovery with an optional public cap.\n- Fixed deposit window with open deposits and withdrawals.\n- Pro-rata token allocation based on total SOL deposited.\n- Early-deposit bonus and late-withdrawal penalties to eliminate sniping.\n- Graduation minimum with refunds if the raise target is not met.\n- Raydium liquidity seeded and locked on graduation.\nCase study\nCollector Crypt\n“ Metaplex is a tremendous brand in the Solana ecosystem. Launching with them elevated our credibility and brought in thousands of new followers and users. ”\n$3.4M\nTotal raised\n$68M\nFDV at launch\n$1B+\nTrading volume (30d)\n20K+\nNew followers\n0\nSnipers\n0\nFront-runs\nFixed-Price Sale\nSet price, first-come allocation, optional allowlist.\n- Set a fixed price per token before the sale opens.\n- First-come, first-served until allocation sells out.\n- Optional allowlist phase for early access.\n- Claim period after deposits close.\n- Raydium LP seeded from raise proceeds.\nCase study\nDefiTuna and Portals\nFixed-price sales across DeFi infrastructure and onchain metaverse. Both cleared with full allocation and live markets today.\n$2.5M\nDefiTuna raised\n$50M\nDefiTuna FDV\n4 min\nDefiTuna sold out\n$600K\nPortals raised\n$87.5M\nPortals FDV\n~$900M\nPortals volume (30d)\nUnified Price Auction\nBid-based discovery. The market sets the clearing price.\n- Buyers submit bids over a defined auction window.\n- Market sets a single on-chain clearing price.\n- All winning bids fill at that clearing price.\n- Transparent bid history and allocation on-chain.\n- Live price discovery without a fixed sale price upfront.\nCase study\nExotic Markets\nSpotlight auction ran for 48 hours. Every winning bid cleared at one on-chain price.\n48h\nAuction window\n250K\nAuction supply\n2%\nMin bid step\nSingle\nClearing price\nOn-chain\nBid transparency\nLive bids\nPrice discovery\nBonding Curve\nConstant-product AMM until it sells out, then it graduates straight to a Raydium pool.\n- Constant-product AMM — trade immediately, no end date.\n- Price rises on buys and falls on sells along the curve.\n- Tokens settle instantly on each transaction.\n- Auto-graduates to Raydium when the curve sells out.\n- Permissionless launch path with creator fee revenue.\nCase study\nPermissionless bonding curves\nLaunch without a spotlight slot. The curve prices supply on a constant-product AMM, then graduates to Raydium when it sells out.\nRaydium\nGraduation target\nAMM\nUntil sellout\nPermissionless\nLaunch path\nCreator fees\nOn-curve revenue\nConstant product\nBonding model\nLive markets\nAfter graduation\nLaunch Pool\nTime-based price discovery with an optional public cap.\n- Fixed deposit window with open deposits and withdrawals.\n- Pro-rata token allocation based on total SOL deposited.\n- Early-deposit bonus and late-withdrawal penalties to eliminate sniping.\n- Graduation minimum with refunds if the raise target is not met.\n- Raydium liquidity seeded and locked on graduation.\nCase study\nCollector Crypt\n“ Metaplex is a tremendous brand in the Solana ecosystem. Launching with them elevated our credibility and brought in thousands of new followers and users. ”\n$3.4M\nTotal raised\n$68M\nFDV at launch\n$1B+\nTrading volume (30d)\n20K+\nNew followers\n0\nSnipers\n0\nFront-runs\nFixed-Price Sale\nSet price, first-come allocation, optional allowlist.\n- Set a fixed price per token before the sale opens.\n- First-come, first-served until allocation sells out.\n- Optional allowlist phase for early access.\n- Claim period after deposits close.\n- Raydium LP seeded from raise proceeds.\nCase study\nDefiTuna and Portals\nFixed-price sales across DeFi infrastructure and onchain metaverse. Both cleared with full allocation and live markets today.\n$2.5M\nDefiTuna raised\n$50M\nDefiTuna FDV\n4 min\nDefiTuna sold out\n$600K\nPortals raised\n$87.5M\nPortals FDV\n~$900M\nPortals volume (30d)\nUnified Price Auction\nBid-based discovery. The market sets the clearing price.\n- Buyers submit bids over a defined auction window.\n- Market sets a single on-chain clearing price.\n- All winning bids fill at that clearing price.\n- Transparent bid history and allocation on-chain.\n- Live price discovery without a fixed sale price upfront.\nCase study\nExotic Markets\nSpotlight auction ran for 48 hours. Every winning bid cleared at one on-chain price.\n48h\nAuction window\n250K\nAuction supply\n2%\nMin bid step\nSingle\nClearing price\nOn-chain\nBid transparency\nLive bids\nPrice discovery\nBonding Curve\nConstant-product AMM until it sells out, then it graduates straight to a Raydium pool.\n- Constant-product AMM — trade immediately, no end date.\n- Price rises on buys and falls on sells along the curve.\n- Tokens settle instantly on each transaction.\n- Auto-graduates to Raydium when the curve sells out.\n- Permissionless launch path with creator fee revenue.\nCase study\nPermissionless bonding curves\nLaunch without a spotlight slot. The curve prices supply on a constant-product AMM, then graduates to Raydium when it sells out.\nRaydium\nGraduation target\nAMM\nUntil sellout\nPermissionless\nLaunch path\nCreator fees\nOn-curve revenue\nConstant product\nBonding model\nLive markets\nAfter graduation\nApply for Spotlight\nPrior Launches.\nPrior Spotlight issuers with live markets today.\nCollector Crypt\nTCG trading cards platform\nSold\n$3.4M\nFDV\n$68M\n30d volume\n$3B+\nType\nLaunch Pool\nTrade CARDS\nDefiTuna\nAdvanced AMM + limit orders\nSold\n$2.5M\nFDV\n$50M\nSell out time\n4 min\nType\nFixed-Price\nTrade TUNA\nPlay Solana\nWeb3 gaming device\nSold\n$2.6M\nFDV\n$100M\nHolders\n20K+\nType\nFixed-Price\nTrade PLAY\nPortals\nOnchain metaverse\nSold\n$600K\nFDV\n$87.5M\n30d volume\n~$900M\nType\nFixed-Price\nTrade PORTALS\nInfrastructure the ecosystem already runs on.\nAccess the largest network in the ecosystem, with provenance and settlement the ecosystem already trusts.\nProven scale\n- 1B+ Transactions powered Solana\n- $13B+ Transaction volume Markets\n- 1B+ Digital assets created Issuance\nDEX partner\nToken sale liquidity auto-migrates from Metaplex to Raydium CPMM pools for liquidity depth and healthy trading. Spotlight customers are eligible to use CLMM pools and configure more advanced liquidity strategies.\nRaydium - DEX partner\n1B+\nTransactions powered\nElite Partners"}
{"url":"https://www.helius.dev/","domain":"www.helius.dev","title":"Helius: Solana's Leading RPC and API Platform","hash":"6f263ba5326d71496127e417e6392b2a5a6228bd7961d8c80159219fa09db30c","tokens":2045,"chars":8180,"crawler":"crawler-f6nn","verified":"exact","ts":1791172030238,"text":"---\ntitle: \"Helius: Solana's Leading RPC and API Platform\"\ndescription: \"Solana RPCs, APIs, gRPC, webhooks, and dedicated infrastructure to build and ship crypto apps, fast. Get started for free in 1 click.\"\ncanonical: \"https://www.helius.dev\"\nlast-updated: \"2026-03-20T15:12:12.296Z\"\n---\n# Helius: Solana's Leading RPC and API Platform\n> Solana RPCs, APIs, gRPC, webhooks, and dedicated infrastructure to build and ship crypto apps, fast. Get started for free in 1 click.\n## The engine behind Solana's best teams, traders, and tinkerers.\nSolana’s most reliable and low latency RPCs, transaction landing services, and data streaming tools.\n[Start for free](https://dashboard.helius.dev/signup) | [Documentation](https://www.helius.dev/docs)\n**THE COMPLETE STACK**\n## The API for Internet Markets\nRun your apps and trading strategies on a unified platform that combines low latency reads with optimized transaction delivery pipelines to detect onchain signals faster, fill more trades, and reduce engineering time.\n## LaserStream\nThe fastest, most reliable way of streaming Solana blocks, transactions, and account data via gRPC.\n- Extreme Redundancy — redundant node clusters with historical replay and persistence so you never miss data\n- Optimized ShredStream — receive data before anyone else without running your own dedicated nodes\n- Global Coverage — regional endpoints for FRA, AMS, TYO, SG, LAX, LON, EWR, PITT, and SLC\n[Get started](https://www.helius.dev/laserstream)\n**See also:**\n- [LaserStream WebSockets](https://www.helius.dev/solana-webhooks-websockets): Listen to onchain events and stream updates\n## Sender\nReliably land transactions even during the toughest market conditions with our ultra-low latency transaction sending service. 0 API credits. 7 global endpoints. 50 TPS (default). Optimized for traders.\n- Route txns across every available high-speed pathway\n- Submit transactions through 7 regional endpoints\n- Access staked bandwidth from [Solana's #1 validator](https://www.helius.dev/validator)\n[Get started](https://www.helius.dev/sender)\n**See also:**\n- [Preconfirmations (Preconfs)](https://www.helius.dev/preconfirmations): The earliest trading signal on Solana\n## Solana RPCs\nThe fastest path to Solana via globally distributed RPCs and our Gatekeeper edge gateway.\n- Sub-millisecond responses via [Gatekeeper](https://www.helius.dev/blog/introducing-gatekeeper), our Rust-based edge gateway\n- Helius-exclusive [archival methods](https://www.helius.dev/historical-data) with cursor-based pagination like getTransactionsForAddress\n- Send transactions via [staked connections](https://www.helius.dev/staked-connections) by default\n[Get started](https://www.helius.dev/solana-rpc-nodes)\n**See also:**\n- [Benchmark Solana RPC Providers](https://www.helius.dev/benchmarks): Test RPC latency across methods, regions, and infra\n## Enterprise-grade infrastructure and reliability\nWe detect your problems before you do. The biggest apps in crypto rely on our SOC 2 certified infrastructure and Solana-native experience to meet their every scaling challenge. When you choose us, everything just works.\n- **RPC success rate**: 99.99%\n- **Transaction confirmations**: 5x faster\n- **Continents covered**: 3\n- **Support available**: 24/7\n### Tailored solutions just for you\nNo two companies are the same. Book a meeting with our team, and we'll create a custom plan for your business.\n[Schedule a call](https://www.helius.dev/contact) | [Chat with us](https://t.me/dtalw)\n### SOC Compliant\nSOC 2 certified infrastructure\n## Solutions for any business\n- **Traders & Market Makers**: Combine the lowest latency shreds with the fastest transaction delivery service to find signals faster and win more trades.\n- **Crypto Exchanges**: Run your exchange on the most scalable and reliable Solana tech stack so you can handle even the most active trading days onchain.\n- **Searchers**: Discover opportunities and land bids faster than your competitors with a unified trading stack engineered for speed and simplicity.\n- **Wallets**: Create a wallet experience users love with the freshest account balances, real-time notifications, and industry-leading reliability.\n- **DeFi**: Build performant apps for internet capital markets on purpose-built infrastructure for low latency reads and writes.\n- **Fintech**: Launch new payments, banking, and stablecoin apps on a platform with unmatched availability and scale.\n## Trusted by Solana's best teams\n> \"Helius is super fast, reliable, and I'd recommend them to anyone looking for the best developer experience on Solana. They power a great portion of our infrastructure at Backpack.\"\n— **Armani Ferrante**, CO-FOUNDER & CEO, BACKPACK\n> \"The Helius team makes building on Solana smoother and easier. They've done an amazing job at streamlining and removing complexity from app development on the network.\"\n— **Anatoly Yakovenko**, CO-FOUNDER & CEO, SOLANA\n> \"The Helius team's deep technical expertise in Solana and node management was absolutely critical during one of our most challenging and busiest days. Thanks to their support, we handled extreme congestion and enabled our users to complete more than 10 million transactions in just one day.\"\n— **Jorge Valdeiglesias**, STAFF SOFTWARE ENGINEER, PHANTOM\n> \"The Helius team is the GOAT. They ship fast, intake product feedback overnight, and power a great deal of Crossmint infrastructure. A big percentage of Crossmint products couldn't exist without Helius.\"\n— **Alfonso Gomez Manas**, CO-FOUNDER, CROSSMINT\n> \"Having personally built our own in-house indexing and data pipelines at Zeta, I know how much of a headache it is for new teams. Being able to save countless hours of data engineering work and costly AWS bills is a big advantage for us.\"\n— **Tristan Frizza**, FOUNDER & CEO, ZETA MARKETS\n> \"Helius has been instrumental in kickstarting our Pythnet operations. Their seamless infrastructure management ensures everything runs smoothly, allowing us to focus on building and scaling our trading operations without worrying about the details of running Solana nodes.\"\n— **Jeremy De Groodt**, CO-FOUNDER & CTO, KEYROCK\n> \"As Solana activity continues to grow, Helius stands out as one of the leading Solana infrastructure providers, enabling our team to access reliable data that meets the demands of an enterprise-grade platform.\"\n— **Jonathan Levin**, CEO AND CO-FOUNDER, CHAINALYSIS\n> \"We tried every strategy to land transactions on Solana, but nothing was working. The moment we switched our RPCs to Helius and started sending transactions through staked connections, all of our problems disappeared. Now we can confidently scale our business on Solana without worrying about our customer's transactions getting dropped.\"\n— **Cody Lambert**, SOFTWARE ENGINEER, BRALE\n> \"When it comes to SOL staking, Helius is truly differentiated. Helius is the industry leader when it comes to running secure, reliable, and performant validators. Since launching in 2022, they have championed Solana's success, built world-class infrastructure, and stewarded the network to become what it is today - the foundation on which the new financial system will be built.\"\n— **Cosmo Jiang**, GENERAL PARTNER AT PANTERA CAPITAL AND BOARD OBSERVER AT HSDT\n> \"We're thrilled to partner with Helius in building our own Solana validator for the Bitwise Solana Staking ETF. Not only is Helius the standard bearer for Solana validators when it comes to areas like performance, reliability, and security, but their native understanding of Solana and its ecosystem is unmatched. They've helped us build the perfect high performance validator—one that meets our stringent needs around security and reporting as an ETF issuer.\"\n— **Hong Kim**, CTO, BITWISE ASSET MANAGEMENT\n> \"The number one thing we care about is safety for users. To give traders the best price and tightest spreads, we depend on LaserStream to feed our price engine with the freshest, fastest onchain data.\"\n— **Nitesh Nath**, CEO, DFLOW\n## Ready to build?\nGet started in less than 10 seconds. No credit cards or email required.\n[Start building](https://dashboard.helius.dev/)\n| [Learn more](https://www.helius.dev/docs)"}
{"url":"https://bitcoin.org/en/bitcoin-core/contribute/translations","domain":"bitcoin.org","title":"Translations - Contribute to Bitcoin Core","hash":"2bed34e12e8b6bdab69484df66d59333e60bcc31b0852454d574bfb1f62016d6","tokens":799,"chars":3194,"crawler":"crawler-f6nn","verified":"exact","ts":1791172034034,"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- Features\n- Overview\n- Validation\n- Privacy\n- Requirements\n- User Interface\n- Network Support\n- Get Help\n- Contribute\n- Bug reports\n- Code\n- Documentation\n- Translations\n- Tech Support\n- News\n- Download\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\nBitcoin\n>\nCore\n>\nContribute\n> Translations\nTranslating Bitcoin Core\nMultiple language support is critical to Bitcoin’s global adoption.\nThe Bitcoin Core translation project covers more than 150 languages,\nmaintained by thousands of volunteer contributors—but more help is\nalways needed, both to complete partial translations and to keep\nexisting ones current.\nTo contribute a translation, create a Transifex account\nand join the Bitcoin Core translation project .\nIf you’re new to Transifex, their getting started guide for\ntranslators walks through the basics of\njoining a project and translating strings.\nTranslators should also subscribe to the translators mailing\nlist , where announcements are posted around\npre-releases to notify translators of new strings to check.\nAfter saving a translation, it will be reviewed and (if accepted)\nincluded in an upcoming release of Bitcoin Core. Translated strings\nare pulled from Transifex periodically, primarily around pre-releases.\nFor details about how translations flow into the software, see the\ntranslation process documentation .\nIf you have any questions, please contact the translation maintainers\nlisted on Transifex or ask (in English) in the #bitcoin-core-dev IRC\nchatroom.\nPREV\nNEXT\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\nBitcoin Core pages on Bitcoin.org are\nmaintained separately from the rest of the site.\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://ethereum-magicians.org/t/erc-8004-trustless-agents/25098","domain":"ethereum-magicians.org","title":"ERC-8004: Trustless Agents - ERCs - Fellowship of Ethereum Magicians","hash":"eebb243cfaf4d11ada69e3f40f5eaaaad87c6ea60801dd1d8c24a6f7f861ba3c","tokens":4450,"chars":17797,"crawler":"crawler-f6nn","verified":"exact","ts":1791172039535,"text":"Fellowship of Ethereum Magicians\nERC-8004: Trustless Agents\nERCs\ndavidecrapis.eth\nAugust 14, 2025, 5:20am\n1\nThis standard extends the Agent‑to‑Agent (A2A) protocol with a trust layer that allows participants to discover, choose, and interact with agents across organizational boundaries without pre‑existing trust.\nIt introduces three lightweight, on‑chain registries —Identity, Reputation, and Validation—and leaves application‑specific logic to off‑chain components.\nhttps://github.com/ethereum/ERCs/pull/1170\nAs this ERC undergoes public discussion, we will work closely with the Linux Foundation and A2A ecosystem stakeholders to refine and improve the specifications of this extension.\nWe acknowledge Dayan Brunie (Consensys), Wilson Chen (TensorBlock), Sumeet Chougule (Nethermind), Jordan Ellis (Google), Nicola Greco (Deepcrypto), Austin Griffith (Ethereum Foundation), David Minarsch (Olas), Barnabé Monnot (Ethereum Foundation), Regan Peng (PIN AI), David Shi (Operator Labs), Pratyush Ranjan Tiwari (Freysa / Eternis), Nima Vaziri (Eigen Labs) for their technical feedback and contributions.\n70 Likes\nERC-8126: AI Agent Verification\nERC-8240: Trust Infrastructure for Agents and Assets\nERC-8412: Preregistered Acceptance Criteria\nTrustless Agents Plus (TAP) : Home for fragmented ERC8004 Agents\nERC-8196: AI Agent Authenticated Wallet\nleonprou\nAugust 17, 2025, 12:30pm\n2\nHey @davidecrapis.eth .\nGreat initiative! We are building a trusless layer for agent collaboration, and seek to be A2A compatible as well. Looking forward to learn how to addop it and happy to chat. Here’s out github repo - https://github.com/ensemble-codes/ensemble-framework\n11 Likes\nspengrah\nAugust 18, 2025, 7:57pm\n3\nIf I’m understanding correctly, this standard prioritizes offchain reads (via event emission) over onchain reads (eg by other smart contracts). If my understanding is correct, I think this is a big miss. A huge amount of the value that agents will create will involve permissioned onchain actions, and so creating primitives for onchain composability would be highly valuable.\nFor example, I don’t see a way in the current standard for an arbitrary smart contract to read the result of a validation response. But if that were required in the standard, then contracts could implement other logic conditioned on various responses. One big benefit would be decoupling validation from enforcement, ie validators would only need to implement validation logic, leaving other protocols to modularly innovate on slashing or other enforcement logic.\nGenerally speaking, if we’re going to anchor something onchain (which we should!), we should also ensure that onchain actors can utilize whatever we’re anchoring. I appreciate that including everything onchain is likely not cost-effective, but ensuring there is a way for contracts to read hashes, digests, identifiers, integers etc is valuable.\n18 Likes\nfelixnorden\nAugust 19, 2025, 4:38pm\n4\nI think you have some valid points to make here. I’m also thinking that the Reputation registry could use functions for multiple Reputation scores from one or multiple providers, which could act as a snapshot/proof of cumulative perceived reputation for an agent and provider.\nIndividual attestations are effective when evaluating the quality of work by an agent. However, for future work, having an aggregate metric to quantify who to work with or avoid becomes more important.\nThis would mean that the Reputation registry becomes a single point of entry for both on-chain and off-chain consumers, and we could leverage multiple providers’ scores of an agent to reduce the risk of biases, collusion, etc.\n2 Likes\nsbacha\nAugust 20, 2025, 11:35pm\n5\nReputons are a standard defined: RFC 7071 - A Media Type for Reputation Interchange\nSome attempts at using this for enriching token lists for curating against scam tokens were attempted.\nReputation here i think is less in “credibility” and more in “SLA/Uptime” kind of metric.\n1 Like\nmlegls\nAugust 21, 2025, 6:34am\n6\nAgreed. I’ve also been working on a set of smart contracts and interfaces for peer to peer escrowed exchange with pluggable validation mechanisms , where the validation mechanisms especially have a lot of intersection with this ERC, and our compromise between gas cost and on-chain usability was to have the interface for arbitration as a function checkObligation(obligation, demand) external view returns bool , to be called as needed, which can often be implemented ephemerally without using on-chain storage. Of course, this assumes that the primary use of validation is as a binary decision valid/invalid. We also chose to rely pretty heavily on EAS for on-chain attestations, e.g. for those representing obligations (in the context of the ERC, a task an agent does), or comments on obligations that should persist on-chain.\nI think it makes sense to keep the core ERC small and cheap to implement though, perhaps with standard interfaces for on-chain uses related to it as separate extension ERCs, or as optional interfaces. It’s easy to add functionality to a contract implementing a minimal spec, and much harder to subtract from a bloated spec.\n1 Like\ndaniel-ospina\nAugust 21, 2025, 9:28am\n7\nCreating a single (aggregate) reputation score is dangerous. We do need a baseline trust criterion but compressing too much into a single metric facilitates monopolistic behaviour.\nSlightly less efficient but I’d prefer to go more modular: have a way to index and reference reputation systems. So standards can organically emerge for as many or as few use cases as needed and each agent can choose.\nThis comes with other complications, so it needs to be thought through but my point is that the agent ID system shouldn’t enforce a single reputation score. That’s just too narrow\n9 Likes\ncomeToThinkOfEth\nAugust 21, 2025, 11:32am\n9\nI have 2 major points to get across:\n- Please elaborate: how would funds be escrowed in this scenario? I would think that we would want to provide maximal flexibility for ways to ensure payment is paid when it’s due:\nPossible mechanisms include time locks, predetermined arbitration, and staking by buyer or seller. Do these all fall under ‘crypto‑economics’?\nPlease explain how these mechanisms fit into the proposed ERC. I don’t understand how the ERC would enable or reference these escrow mechanisms. Probably Maybe this is already addressed and I’m missing the terminology. Could you please include a simple Solidity example (e.g., two agents ordering a pizza) showing how the ERC is used for escrowed payment? (for understandable historical reasons)?\n- I believe that we should not only focus on the infra, but that we need to create an ETH denominated economy in the AI agents space, just like we did with NFTs. I believe the best way forward is to create capable AI agents, who will perform valuable tasks and have them demand payment in ETH. If this takes off, we will get new agents entering the scene having to own ETH to pay other agents. This has the potential of being ETH’s next major, and possibly ultimate, network effect. We should be funding grants and bizdev to get AI agents accepting ETH for tasks.\nI know it is not directly pertains to this ERC but it directly relates to the matter. Please spread the idea of you agree.\n1 Like\nfelixnorden\nAugust 21, 2025, 12:38pm\n10\nYes, I completely agree, I think we’re trying to describe similar things when you say “index and reference” these reputation systems; I’m suggesting that those references can be made available on the registry itself through (agent, provider) pairs as an addition, not a replacement.\nThe history of independent pieces of work should be standalone, as is described already. However, we can amend the registry to enable multiple providers to provide their aggregate scores for on-chain applications to consume.\nE.g., Virtuals, Creatorbid, Base, etc. could each provide their scores for agents, which could be used for comparing overall performance (e.g., SLAs or QoW) and help identify the current best option.\n3 Likes\npcarranzav\nAugust 22, 2025, 3:07pm\n11\nGreat initiative. Some thoughts:\n- AFAICT, the use of a well known location for the agent card is optional in the A2A spec, and the spec mentions registries as an alternative. Won’t making it a requirement limit the possibilities of how people might host agents? For instance, I might want to host many agents at different URLs in the same domain. This would be possible in A2A, wouldn’t it? So my suggestion would be to use URLs rather than domains as the way to point to the agent.\n- The ERC mentions endpoints but not specific Solidity functions for the different contracts. It would be nice to specify the interface and behavior of the contracts a bit more. e.g. Should registration be free or require some kind of stake deposit? Could the ERC propose a singleton identity registry per chain, to prevent a proliferation of multiple slightly different registries?\n3 Likes\nazanux\nAugust 23, 2025, 1:40pm\n12\nHi ! ,\nI am not sure that it is mentioned in the specification how to handle payment between agents.\nThe crypto-economics part is related to how to manage the reputation of validators, meaning a way to give incentive to validators to be honest during validation.\nBut I agree with you that it should be something good to have in the specification as it is an important part, especially that agents will have to pay gas to work together and register collaboration.\notherwise great initiative\n1 Like\nKBryan\nAugust 23, 2025, 10:35pm\n13\nThis is pretty interesting. I’m currently working on a standard for Agent-to-Agent coordination ERC-8001. Would love your input. There are definitely synergies here.\n1 Like\nMarco-MetaMask\nAugust 24, 2025, 10:40am\n14\nIt seems ERC-8001 is focused on reaching consensus among agents (signing the same attestation), an area orthogonal to and not covered by ERC-8004. Am I understanding this correctly?\nMarco-MetaMask\nAugust 24, 2025, 11:08am\n15\n@felixnorden @mlegls and spengrah Yeah, it’s a very important point. The rationale for keeping “Rating” in Reputation completely off-chain and “Response” in Validation off-chain + only in an event parameter (so not accessible on-chain) was:\n- [Major] Single feedback or validation won’t be used to decide trust. People will always aggregate entries (including filtering or weighting based on the validator/feedback issuer’s reputation), which is hard to do on-chain anyway.\n- [Minor] Gas efficiency / keeping it simple without requiring the Agent Client to sign a transaction for each issued feedback. This can be mitigated by keeping it optional (I like this) or with an off-chain bundler that aggregates multiple feedback and signs transactions on behalf of issuers (which I don’t like because it adds significant overhead).\nAnyway, let’s challenge this rationale! So:\n- Which data would you save on-chain? Only the Rating and Response integers or other data structures too?\n- Where? Registry storage?\n- Can you provide use cases where single non-aggregated entries are useful? Or with basic on-chain aggregation? For example, “filtering” is easily implementable on-chain—like skipping all validations or feedback not emitted by whitelisted addresses. So you could calculate an average of filtered ratings, etc.\n5 Likes\nMarco-MetaMask\nAugust 24, 2025, 11:19am\n16\n(Also answering to @azanux ) The protocol doesn’t cover payments. We considered requiring payment proofs for giving feedback, but:\n- We didn’t want to couple our problem space (discoverability and trust) to a specific protocol. We preferred to remain unopinionated.\n- In some cases, payments will happen off-chain, not happen at all (free service), or be bundled, etc.\nThat said:\n- We encourage inserting proof of payment as an optional attribute in the off-chain schemas.\n- We know some groups are working on an A2A payment extension for agents, based on x402. We like this approach and are connecting with them to ensure that their extension and ours (ERC-8004) work perfectly together.\n4 Likes\nspengrah\nAugust 24, 2025, 2:55pm\n17\nJust chiming in to say that I agree completely here. Even the idea of multiple (modular) providers of reputation scores is likely misguided.\nTrust is not a universal value of Bob, but a vector from Alice to Bob. Charlie’s trust vector for Bob will almost certainly differ from Alice’s. Nor is there such a thing as a comprehensive Alice–>Bob trust vector! Alice’s trust for Bob is highly context-dependent; even ignoring environmental factors (which is appropriate in this case), Alice almost certainly trusts Bob differently based on the domain of their interaction.\nAll this is to say that a) modularity is critical here, and b) I absolutely acknowledge that any sane attempt to quantify reputation will be hard-pressed to happen fully onchain, given the complexity involved and lack of a universal score. We likely need some system of async trust-minimized oracles, eg CCIP-read out to an AVS or something.\n5 Likes\nspengrah\nAugust 24, 2025, 3:40pm\n18\nThis is a valid and important point (see my other post above for more detail on why I agree). That said, I don’t see a strong reason for making this choice on behalf of other developers. Perhaps somebody will create an efficient contract to aggregate across N pieces of feedback or validation, or perhaps there will be niche but valuable use cases for other contracts to read individual pieces on their own.\nOptional for the Client Agent definitely makes sense here.\nAt the very very least, I would make the event data available for contracts to read onchain, such as (in solidity):\n// IReputationRegistry\nfunction getAuthFeedback(uint256 agentClientID, uint256 agentServerID) external view returns (uint256 feedbackAuthId);\n// IValidationRegistry\nfunction getValidationResponse(uint256 agentValidatorID, uint256 agentServerID, bytes32 DataHash) external view returns (uint256 response);\nI would also strongly consider an optional onchain feedback record, something like the following:\nstruct FeedbackData {\nstring agentSkillId;\nstring taskId;\nstring contextId;\nuint256 rating;\nbytes proofOfPayment;\nbytes data;\n}\nmapping(string feedbackAuthId => FeedbackData feedback) public view feedback;\n/// @notice stores feedback data onchain\n/// @dev callable only by Server Agent\nfunction submitFeedback(uint256 agentClientID, uint256 agentServerID, FeedbackData feedback) external returns (string feedbackAuthId);\nWe could also get even more ambitious here and do an onchain index of the above by TaskId, ContextId, and AgentSkillId for maximum legibility and filtering.\nLikely, though, that should be left to helper contracts, similar to how EAS uses its Indexer contract . It’s possible that supporting something like that may require a small addition to the standard to ensure that writes can successfully hit both the contract specified by this standard and the indexer atomically without losing information.\nThe main point I was trying to express at the top of this post is that we don’t know what will emerge as useful, valuable, or feasible; and therefore we shouldn’t foreclose the possibility for permissionless innovation if we can do so without compromising other goals.\nI think the minimal suggestions I’ve made here (other than the more advance indexing stuff) meet that criterion. But I’m keen to hear what you think.\n3 Likes\nMarco-MetaMask\nAugust 25, 2025, 7:08am\n19\n- You are correct. We should make it clear that using ERC-8004, exposing AgentCard at the well-known location becomes mandatory.\n- Correct, you can’t have multiple agents at the same domain. Each agent should have its own N-level subdomain, which is what you usually get with modern CI/CDs. Do you see this as an issue?\n- In the ERC we have function names, inputs and (with one exception) outputs. But yes, we will specify types and be more precise in a future version of the ERC or directly in the reference implementation.\n- Yeah, the goal is to have just one singleton per chain (if we stay single-chain).\n2 Likes\ngpt3_eth\nAugust 25, 2025, 8:26am\n20\n- This ERC-8004 should not pick or embed any settlement flow (credits, x402, etc.). Payment belongs to the application layer, while 8004 stays focused on trust primitives.\n- But payment proofs should be referenceable in Reputation: what we can standardize is the hook: allow Feedback/Rating records to carry a lightweight reference to a payment proof so indexers can correlate economic activity with feedback.\n5 Likes\npcarranzav\nAugust 25, 2025, 2:54pm\n21\nIs there a reason to make it mandatory? I think some people might want to run multiple agents on the same domain… if there’s a specific reason to restrict it I’d understand, it just seems odd since it looks to me like the identity registry could work just as well using URLs instead of domains. Especially because the A2A spec specifies registries as an alternative to the well-known URI. My suggestion would be to specify the URL of the Agent Card when registering an agent and use that to resolve instead of domains.\nWhich brings me to something that seems missing in the current ERC: how would the contracts validate who owns a domain? That seems like it will require a trusted party or some form of consensus / verification mechanism (zkTLS?) to prove domain ownership. The alternative would be to allow anyone to claim they own a domain, but then the contract should allow multiple agents claiming they are at a specific domain, and then ResolveByDomain could have multiple results…\nre: function names, I guess I was confused by seeing names starting with uppercase, and not seeing the types for params and return values. I think this is important information to include in the ERC, rather than the reference implementation.\nGood to hear that the plan is a singleton per chain\n3 Likes\nnext page →"}
{"url":"https://governance.aave.com/t/temp-check-onboard-wstlink-to-aave-v3-core-instance/22007","domain":"governance.aave.com","title":"[TEMP-CHECK] Onboard wstLINK to Aave v3 Core Instance - New Asset - Aave","hash":"056f948ea1394ac375f4ab386e2df6ba51c5b7b809caf419b3b0ad4da5789618","tokens":1918,"chars":7672,"crawler":"crawler-f6nn","verified":"exact","ts":1791172042569,"text":"Aave\n[TEMP-CHECK] Onboard wstLINK to Aave v3 Core Instance\nGovernance\nNew Asset\nJonny\nMay 9, 2025, 2:40pm\n1\nDate: 2025-5-9\nAuthor: Jonny Huxtable (LinkPool)\nSummary\nstake.link ( https://www.stake.link ) proposes adding wstLINK as a collateral asset in Aave’s Ethereum V3 market. wstLINK is a wrapped liquid staking token that enables users to earn LINK staking rewards and additional returns through DeFi strategies for stLINK and wstLINK. Its growing adoption, deep liquidity, and robust security measures make wstLINK a strong candidate to enhance Aave’s asset offerings, increase utilization of existing LINK liquidity and attract additional liquidity.\nBackground\nwstLINK is the wrapped liquid staking token stLINK of stake.link, the only permissionless liquid staking protocol built for LINK staking. By leveraging stake.link users can participate in LINK staking and profit from a higher reward rate as well as composability and faster withdrawals.\nKey highlights of wstLINK, stLINK and stake.link include:\n- Secure: Audited by industry-leading experts, maintaining the high standards set by Chainlink Labs:\n- CodeHawks\n- Cyfrin\n- Sigma Prime\n- Trust Security\n- Decentralized: Powered by 15 major Chainlink Node Operators, handling over 57% of network activity ( https://prism.dextrac.com/chainlink )\n- Liquid - Instant Withdrawals, No Cooldown:\n- Priority Pool: Withdraw instantly as long as there’s LINK ( amount can be viewed here ) (The Priority Pool is a holding zone that users can deposit their LINK into that automatically stakes their LINK into Chainlink Staking Contracts whenever a LINK Staker withdraws their LINK).\n- Native Withdrawals: Withdraw LINK natively within at least 7 days. 25% of the entire LINK pool will be unbonded at any point via stake.link, there’s some edge cases but that’s generally what will be the norm. Withdrawal requests will run in a 7 day queue, if you send a withdrawal request 4 days into the queue it’ll only take 3 days etc.)\n- Ecosystem Participant:\n- Chainlink Labs as ecosystem participant owning roughly 7.7% of SDL supply\n- High Adoption and TVL:\n- stake.link holds over $74 million (~4.4m LINK) in total value locked (TVL) within its ecosystem integrated across DeFi platforms like Curve, Beefy, and Uniswap\n- stake.link has established approximately $5 million pool of stLINK on Curve.fi with an a-coefficient of 500 enabling liquidations on par or with significant upside for the liquidator\n- Another $3 million of liquidity is still to migrate to the new pool\n- The new pool features a very innovative incentive by using 3% of the generated fees by the protocol (stLINK) that are distributed as LP tokens ensuring a steady growth of the pool over time with sustainable reward rate.\nBenefits for Aave\nFirst-Mover Advantage: Aave would become the first lending protocol to offer LINK LST, securing its position as the leading DeFi platform for yield-generating staking assets.\nYield Opportunities: By listing wstLINK, Aave users can earn LINK staking rewards in addition to traditional borrowing and lending income. This enhances capital efficiency and provides a competitive advantage over other lending platforms\nIncrease aLINK Utilization: Currently, a significant amount of the LINK tokens on the Aave Core Instance (13 million <> $190m) is currently underutilized (5.61% Utilization) and could be staked via stake.link and wrapped for wstLINK due to the increased yield potential compared to low interest potential. This would entail a considerable benefit to Aave, Aave users and stake.link. At Yield Equilibrium (Borrow APY = Staking APY) the Revenue from Reserve Factor is roughly 11x compared to the Current Situation.\nCurrent Situation\nYield Equilibrium\nOptimal Utilization\nAave Borrow Reserve\n13,000,000 LINK\nAave Rewards\n42,900 LINK\n559,000 LINK\n910,000 LINK\nRevenue from Reserve Factor\n8,580 LINK\n111,800 LINK\n182,000 LINK\nRevenue from Reserve Factor\n$137,280\n$1,788,800\n$2,912,000\nAssumptions\nBorrow APY\n0.33%\n4.30%\n7%\nUtilization\n2.10%\n27%\n45%\nReserve Factor\n20%\nLINK Price\n$16\nSecurity and Transparency:\nstake.link’s advanced security measures and transparent on-chain operations ensure a high level of trust and reliability for borrowers and lenders.\nSpecification\nRisk Parameters and analysis will be provided by Risk Service Providers and ARFC will be updated accordingly.\nToken Contracts:\n- wstLINK on Ethereum: 0x911D86C72155c33993d594B0Ec7E6206B4C803da\nLiquidity Pools:\n- Curve stLINK-LINK stablepool: 0x7e13876b92f1a62c599c231f783f682e96b91761\n- LINK Priority Pool: 0xddc796a66e8b83d0bccd97df33a6ccfba8fd60ea\nDocs:\n- stake.link · GitHub\n- https://docs.stake.link/\nNext Steps\n- If consensus is reached on this TEMP CHECK, escalate this proposal to the Snapshot stage.\n- If the Snapshot outcome is YAE, escalate to ARFC stage, requesting ACI’s assistance to write the ARFC.\n- Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage.\n- If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.\nDisclaimer\nCurrent proposal has been created by the Lead Core Contributor of stake.link and the founder and CEO of LinkPool, and is involved in the management of wstLINK. No compensation has been received for this proposal.\nCopyright\nCopyright and related rights waived under CC0 .\n12 Likes\n[ARFC] Onboard wstLINK to Aave V3 Core Instance\nMichael_p3711\nMay 9, 2025, 4:10pm\n2\nI am in support of this proposal and would 100% use wstlink on AAVE\n5 Likes\nCubeOfCandor\nMay 9, 2025, 7:04pm\n3\nI believe this would be greatly beneficial for both the AAVE community as well as the Chainlink community as they are both closely connected in building the future of DEFI. Having stLINK/WstLINK, the premium staked version of the token for the Chainlink network, on AAVE would be a big step forward for the future of the protocol.\n5 Likes\n69420\nMay 9, 2025, 8:23pm\n4\nCommunity Rep for Stake.link, naturally you’d be in support of it :p\n2 Likes\nZDZ\nMay 10, 2025, 4:10am\n5\nStrongly in favor. This is the dominant LINK LST secured by a premier set of Chainlink nodes.\n5 Likes\ndoomi\nMay 14, 2025, 12:56am\n6\nStrongly support listing wstLINK on Aave. It brings yield opportunities to regular LINK deposits by creating a borrow/stake/wrap loop that increases utilisation. This improves capital efficiency, deepens liquidity, and aligns Aave with the growing DeFi staking ecosystem. Let’s make it happen.\n4 Likes\nGovernAvid\nMay 14, 2025, 5:54am\n7\nListing wstLINK could improve capital efficiency and increase protocol revenue through underutilized LINK. Support the proposal.\n2 Likes\nACI\nMay 22, 2025, 7:11am\n8\nThe current proposal has been escalated to TEMP CHECK Snapshot , under Skywards program.\nVote is already live, we encourage everyone to participate.\n4 Likes\nACI\nMay 26, 2025, 5:32am\n9\nAfter Snapshot monitoring, the current TEMP CHECK Snapshot ended, reaching out both Quorum and YAE as winning option, with 595.7K votes.\nTherefore [TEMP-CHECK] Onboard wstLINK to Aave v3 Core Instance has PASSED.\nClosing this thread to focus on ARFC that will be posted shortly, to continue gathering feedback from community and SP.\n3 Likes\nRelated topics\nTopic\nReplies\nViews\nActivity\n[ARFC] Onboard wstLINK to Aave V3 Core Instance\nNew Asset\n15\n3068\nOctober 4, 2026\nwstETH borrows enabled\nGovernance\n2\n115\nSeptember 24, 2026\n[ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\nGeneral\n2\n253\nSeptember 21, 2026\nWrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments\nAssessments\n1\n122\nJuly 1, 2026\n[ARFC] Low Adoption Asset Deprecation on Aave V3\nGovernance\n9\n2132\nSeptember 16, 2026"}
{"url":"https://developer.bitcoin.org/reference/rpc/index.html","domain":"developer.bitcoin.org","title":"RPC API Reference — Bitcoin","hash":"9310799770004c53b83a6668fbeefe07f530633d792981e3f74c0a18a68cdf49","tokens":793,"chars":3169,"crawler":"crawler-f6nn","verified":"exact","ts":1791172044662,"text":"-\nBitcoin\n-\nReference\n- RPC API Reference\n« P2P Network\ngetbestblockhash »\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\nNext topic\ngetbestblockhash\nContribute\nEdit Page\nRPC API Reference ¶\nBlockchain RPCs ¶\n- getbestblockhash\n- getblock\n- getblockchaininfo\n- getblockcount\n- getblockfilter\n- getblockhash\n- getblockheader\n- getblockstats\n- getchaintips\n- getchaintxstats\n- getdifficulty\n- getmempoolancestors\n- getmempooldescendants\n- getmempoolentry\n- getmempoolinfo\n- getrawmempool\n- gettxout\n- gettxoutproof\n- gettxoutsetinfo\n- preciousblock\n- pruneblockchain\n- savemempool\n- scantxoutset\n- verifychain\n- verifytxoutproof\nControl RPCs ¶\n- getmemoryinfo\n- getrpcinfo\n- help\n- logging\n- stop\n- uptime\nGenerating RPCs ¶\n- generateblock\n- generatetoaddress\n- generatetodescriptor\nMining RPCs ¶\n- getblocktemplate\n- getmininginfo\n- getnetworkhashps\n- prioritisetransaction\n- submitblock\n- submitheader\nNetwork RPCs ¶\n- addnode\n- clearbanned\n- disconnectnode\n- getaddednodeinfo\n- getconnectioncount\n- getnettotals\n- getnetworkinfo\n- getnodeaddresses\n- getpeerinfo\n- listbanned\n- ping\n- setban\n- setnetworkactive\nRawtransactions RPCs ¶\n- analyzepsbt\n- combinepsbt\n- combinerawtransaction\n- converttopsbt\n- createpsbt\n- createrawtransaction\n- decodepsbt\n- decoderawtransaction\n- decodescript\n- finalizepsbt\n- fundrawtransaction\n- getrawtransaction\n- joinpsbts\n- sendrawtransaction\n- signrawtransactionwithkey\n- testmempoolaccept\n- utxoupdatepsbt\nUtil RPCs ¶\n- createmultisig\n- deriveaddresses\n- estimatesmartfee\n- getdescriptorinfo\n- getindexinfo\n- signmessagewithprivkey\n- validateaddress\n- verifymessage\nWallet RPCs ¶\nNote: the wallet RPCs are only available if Bitcoin Core was built\nwith wallet support, which is the default.\n- abandontransaction\n- abortrescan\n- addmultisigaddress\n- backupwallet\n- bumpfee\n- createwallet\n- dumpprivkey\n- dumpwallet\n- encryptwallet\n- getaddressesbylabel\n- getaddressinfo\n- getbalance\n- getbalances\n- getnewaddress\n- getrawchangeaddress\n- getreceivedbyaddress\n- getreceivedbylabel\n- gettransaction\n- getunconfirmedbalance\n- getwalletinfo\n- importaddress\n- importdescriptors\n- importmulti\n- importprivkey\n- importprunedfunds\n- importpubkey\n- importwallet\n- keypoolrefill\n- listaddressgroupings\n- listlabels\n- listlockunspent\n- listreceivedbyaddress\n- listreceivedbylabel\n- listsinceblock\n- listtransactions\n- listunspent\n- listwalletdir\n- listwallets\n- loadwallet\n- lockunspent\n- psbtbumpfee\n- removeprunedfunds\n- rescanblockchain\n- send\n- sendmany\n- sendtoaddress\n- sethdseed\n- setlabel\n- settxfee\n- setwalletflag\n- signmessage\n- signrawtransactionwithwallet\n- unloadwallet\n- upgradewallet\n- walletcreatefundedpsbt\n- walletlock\n- walletpassphrase\n- walletpassphrasechange\n- walletprocesspsbt\n×\nDonate to Bitcoin.org\nUse this QR code or address below\n3E8ociqZa9mZUSwGdSmAEMAoAxBK3FNDcd"}
{"url":"https://docs.monad.xyz/developer-essentials/reserve-balance","domain":"docs.monad.xyz","title":"Reserve Balance - Monad Documentation","hash":"808c3928f9d07e5756a4e9ef7c5b15b8344eb9c3bdd99d4dd1c7d2f08bd7f3ce","tokens":5138,"chars":20552,"crawler":"crawler-f6nn","verified":"exact","ts":1791172047377,"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\nReserve Balance\nIntroduction\nThe Reserve Balance mechanism is a set of light constraints - at consensus time on which\ntransactions can be included , and at execution time on which transactions don’t revert - which\nallow Monad to simultaneously support asynchronous execution\nand EIP-7702 .\nThe Reserve Balance mechanism is designed to preserve safety under asynchronous execution\nwithout interfering with normal usage patterns. Most users and developers need not worry\nabout the Reserve Balance constraints , however we provide the details here for those\nencountering corner cases.\nSummary\nAsynchronous execution means that nodes achieve consensus on a block proposal prior to executing\nthe transactions in that block. Execution is required to be completed in the next k (delay\nfactor) blocks. (Currently k=3 . NOTE : In the context of discussing block states\nand asynchronous execution , letter D is\nusually used to denote the same parameter.)\nBecause consensus operates on a k -block delayed view of the global state, it is necessary\nto adjust the consensus and execution rules slightly to allow consensus to safely build\nand validate blocks that include only transactions whose gas costs can be paid for.\nMonad introduces the Reserve Balance mechanism to allow consensus and execution\nto collaborate across a multi-block lag to ensure that all EOAs must have enough MON\nin their account to pay for gas for any transaction included in the blockchain.\nThroughout this document, an inflight transaction refers to a transaction that has\nbeen included in a block less than k blocks ago.\nHere is a very brief summary of the rules:\n- From the perspective of a particular EOA, MON spent from that EOA in the course of a transaction\nis partitioned into two parts: gas spend and value spend .\n- In the case where the EOA was the sender:\n- gas spend is gas_price * gas_limit ;\n- value spend is the value parameter on that transaction.\n- In the case where the EOA wasn’t the sender (where they previously delegated via EIP-7702 and some other\nEOA submitted a transaction which called this EOA):\n- gas spend is 0;\n- value spend is whatever MON is sent out during the course of executing this EOA’s code.\n- Let user_reserve_balance = 10 MON\n- Execution time : during execution, transactions revert due to value spend when that\naccount’s ending balance (before refunds) dips below user_reserve_balance , except in certain circumstances described below.\n- Consensus time : For each account, consensus has a budget for the gas spend for all inflight\ntransactions; this budget is user_reserve_balance (or the account’s balance from the lagged\nexecution state, whichever is lower). The budget is further reduced if the first inflight\ntransaction earned the exception mentioned above, by that transaction’s value spend .\nWhen performing block validity checks for block n , consensus checks that the budget is not exceeded.\nSee also the formal definition in the\nMonad Initial Spec\nproposal from Category Labs.\nParameters\nParameter Value\nuser_reserve_balance 10 MON\nWhy is reserve balance needed?\nMonad has asynchronous execution: consensus is allowed to progress with building and\nvalidating blocks without waiting for execution to catch up. Specifically, proposing\nand validating consensus block n only requires knowledge of the state obtained after\napplying block n-k .\nWhile asynchronous execution has performance benefits, it introduces a novel challenge:\nhow is consensus supposed to know the validity of a block if it does not have the latest\nstate?\nLet’s illustrate this challenge with an example (for our examples, we will use k = 3 ):\nConsensus is validating block 4, which contains a transaction t from Alice with the\nrelevant fields as:\nsender=Alice, to=Bob, value=100, gas=1\nConsensus only has the state that was obtained by executing block 1:\nblock=1, balances={Alice: 110}\nIf consensus simply accepts block 4 as valid because Alice appears to have enough\nbalance, it risks a safety failure. For instance, Alice may have already spent her\nbalance in transaction t’ in block 2. This creates a denial-of-service (DoS)\nvector, as Alice could cause consensus to include many transactions for free.\nFirst attempt at a solution\nOne idea is for the consensus client to statically inspect transactions in blocks 2\nand later, checking if Alice has spent any value in her transactions. This would let\nconsensus reject block 4 as invalid if any transaction before t (such as t' ) in\nblocks 2, 3, or 4 originates from Alice and spends some value or gas.\nWhile this is a fine solution on the face of it, it suffers from two shortcomings:\n-\nSuppose, as part of smart contract execution in blocks 2 or 3, Alice received a lot\nof currency. She would have had enough balance to pay for transaction t despite\nt' existing, if only we had the latest state. So, rejecting transactions based\nsolely on static checks is overly restrictive.\n-\nIt is not only restrictive, it is also not safe with EIP-7702. With EIP-7702, Alice\ncould have her account delegated to a smart contract, which can transfer out currency\nfrom Alice’s account in a way that is not statically inspectable by consensus.\nConcretely in our example, Alice does not need to send a transaction like t' from\nher account in order to spend currency from her account, if her account is delegated.\nA spend could potentially be triggered by a transaction submitted by anyone else.\nSo our static check would not succeed and it may be unsafe to accept block 4 as valid\neven if we don’t see any other transaction from Alice in blocks 2, 3 and 4.\nReserve balance as the solution\nSimple version\nIntuitively, the core idea of reserve balance is as follows: if consensus and execution\nagree ahead of time that, for each EOA, execution will prevent the ending balance from\ndropping below a certain pre-determined threshold known to consensus ( user_reserve_balance ),\nup to the sender’s gas spend allowance, then consensus can safely include a series of transactions whose running\ngas spend stays below user_reserve_balance , without knowing the latest state and\nwithout being vulnerable to the DoS vector described above.\nThis concept can be generalized as follows:\n- Execution time : after execution (before gas refunds), a reserve-balance check is applied to\nthe ending balance. For a non-sender account, the ending balance must not be lower than\nmin(balance at transaction start, user_reserve_balance) . For the sender, the ending balance may be lower\nby at most the transaction’s gas spend (unless the emptying exception below applies).\nExcessive intermediate debits during execution are allowed as long as the ending balance is sufficient.\n- Consensus time : For each account, consensus has a budget for the gas spend for all inflight\ntransactions; this budget is user_reserve_balance (or the account’s balance from the lagged\nexecution state, whichever is lower).\nWhen performing block validity checks for block n , consensus checks that the budget is not exceeded.\nIn Monad, user_reserve_balance is currently set to 10 MON for each EOA.\nThe above rule is sufficient to ensure all transactions included in consensus can be paid\nfor, thus solving our problem. However, it has a drawback, which is that EOAs can’t spend\nall of their MON, and EOAs with balances below user_reserve_balance won’t be able to send\nany successful transactions.\nFor instance, the following behaviors might be desired, but are currently blocked\nby the above rule (with user_reserve_balance set to 10 MON ):\n- Alice has a balance of 5 MON and wants to send 4.99 MON to Bob (plus pay 0.01 MON\nin gas)\n- Alice has a balance of 20 MON and wants to swap 18 MON into a memecoin (plus pay\n0.01 MON in gas)\nTo address this, we add some additional conditions under which transactions are allowed.\nAddressing the drawback\nFirst let’s define an “emptying transaction”:\nA transaction is an “emptying transaction” iff\n- the sender is undelegated.\n- the sender has not sent any other transaction within the past k blocks.\n- nobody has sent a delegation or undelegation request for the sender within the past k blocks, including in this transaction.\nSuch transactions are eligible for the emptying exception (see rules below).\nNotice that if a user account is not EIP-7702-delegated, then consensus can simply\ninspect transactions statically in order to estimate the lowest a user’s balance can\npossibly go. (This is because an undelegated user’s account can only be debited due to value\ntransfers and gas fees specified in the transaction data).\nTherefore, we add the following exception to the reversion rule:\n- Execution policy : for each undelegated account sender:\n- if a transaction is an emptying transaction\n- then allow that transaction to proceed anyway (an “emptying transaction”).\n- Consensus policy : for each undelegated account sender:\n- if a transaction is an emptying transaction\n- then statically inspect that transaction’s total MON needs (i.e. gas_bid * gas_limit + value ),\nand take into account the fact that execution will still allow this transaction through. This\nmeans that for any subsequent transactions in the next k blocks, the reserve balance that\nconsensus is working with will be lower by value .\nThis rule lets execution allow consistently-undelegated accounts to dip below the reserve balance\nonce every k blocks. Since k blocks is 1.2 seconds, this policy should allow most small\naccounts to still interact with the blockchain normally.\nNote that an account is not eligible for the exception criteria if there was recent (within k blocks) undelegation request for the account even if it was already undelegated at that time.\nSee Full specification for details.\nThe additional policy allows both of the examples mentioned at the end of the previous section,\nas long as they are the first transaction sent by the sender in k blocks.\nDiscussion\nEIP-7702-delegated accounts\nIf an EOA is not EIP-7702-delegated, then the reserve balance is rarely invasive, even\nif the EOA’s balance is very low, because most transactions are the first transaction in k=3 blocks\nsent by that EOA.\nBut what if the EOA is EIP-7702-delegated? What is the impact?\n- The only transactions that will revert are ones in which the balance of an EIP-7702-delegated EOA dips below 10 MON.\n- ‘Dips below’ means ‘decrements and drops below’ .\n- Transactions where the EOA’s balance ends above or at 10 MON are fine.\n- Transactions where the EOA’s balance is unchanged or increases are fine.\n- Only transactions that decrement the balance and result in a final balance\nbelow 10 MON are reverted.\n- Delegated EOAs cannot use the emptying exception described above.\nFor example, many sponsored gas workflows have users set up EIP-7702-delegated EOAs that\ndon’t interact with MON at all (i.e. they start out empty, and only receive MON involuntarily).\nUnder a typical such workflow, a sponsor submits a transaction that calls into the EOA as\nsmart contract. This workflow works fine in Monad; it’s fine for the EOA in question to\nhave a zero or very small balance.\nThe only case where a sponsored gas workflow will be blocked is if the EOA’s balance is\n(say) 6 MON, and the sponsored transaction calls code that tries to transfer (say) 1 MON out of the EOA.\nTransactions that are included but revert\nBecause of the Reserve Balance rules, you may see transactions included in the chain whose\nexecution reverts , such as transactions trying to transfer out more MON than are in the account\nbalance.\nThese transactions are still valid transactions that pay for gas, but the\nresult of these transactions is nothing except for gas being decremented from the sender.\nThey are included because at the time of consensus, the proposer cannot be sure that the account\nisn’t going to receive more MON from someone else, and the sender has the budget to pay for gas.\nEthereum includes many transactions whose execution reverts, so this is not a protocol difference.\nHowever, in practice, Ethereum block builders may screen out transactions with insufficient balance\nto process a transfer out, so this behavior may be different from what you’re accustomed to seeing.\nDetecting a reserve balance dip\nA contract can check at execution time whether its current execution has dipped into the reserve\nbalance by calling the\nreserve balance precompile\nat 0x1001 . It exposes a single method, dippedIntoReserve() (selector 0x3a61584e , gas cost\n100 ), which returns a bool . It is specified in MIP-4 .\ndippedIntoReserve() must be invoked via CALL . Invoking it via STATICCALL - or via\nDELEGATECALL or CALLCODE - reverts. Although it reads state and returns a value, it is\nintentionally not a view function, so that a Solidity call site compiles to CALL rather than\nSTATICCALL .\nFull specification\nSee the\nreserve balance spec\nfor the formal set of Reserve Balance rules.\nAlgorithms 1 and 2 implement this check for consensus and execution, respectively.\nAlgorithm 3 implements the mechanism to detect the dipping into the reserve balance\n(Algorithm 2 uses Algorithm 3 to revert transactions that dip).\nAlgorithm 4 specifies the criteria for emptying transactions:\n- The sender account must be undelegated in the prior k blocks. This is checked\nstatically by verifying the account was undelegated in a known state in the past\nk blocks, and there have been no delegation or undelegation requests in the last\nk blocks (this can be inspected statically).\n- There must not be another transaction from the same sender in the prior k blocks.\nHere is a quick summary of the reserve balance rules at consensus time:\nIf the account is not delegated and there are no inflight transactions\nIf the account is not delegated, and there are no previous inflight transactions, then consensus\nchecks that the gas fee for this transaction is less than the balance from the lagged state.\ngas_fees ( tx ) ≤ balance\nIf the account is not delegated and has one emptying inflight transaction\nIf the account is not delegated, and there is one previous inflight transaction, then\nconsensus has to take into account the inflight transaction’s total MON expenditures\n(including value ):\nlet adjusted_balance = balance − ( first_tx.value + gas_fees ( first_tx ))\nlet reserve = min ( user_reserve_balance ( t . sender ) , adjusted_balance )\nA new transaction can only be included if the sum of all inflight transactions’ gas fees\n(excluding the first one) is less than the reserve:\nt x ∈ I [ 1 : ] ∑ gas_fees ( t x ) ≤ reserve\nAll other cases\nThe reserve is equal to minimum of systemwide reserve balance ( 10 MON ) or the\naccount’s balance at block n - k :\nreserve = min ( user_reserve_balance ( t . sender ) , balance )\nA new transaction can only be included if the sum of all inflight transactions’ gas fees\nis less than the reserve:\nt x ∈ I ∑ gas_fees ( t x ) ≤ reserve\nAdjusting the reserve balance\nThe reserve balance is currently the same for every account ( 10 MON ).\nIn a future version, the protocol could allow users, through a stateful precompile, to\ncustomize their reserve balance.\nCoq proofs\nThe safety of the reserve balance specification has been formally proved in Coq.\nThe full proofs documentation is available\nhere .\nThe consensus check is formalized in Coq as consensusAcceptableTxs . The predicate,\nconsensusAcceptableTxs s ltx , defines the criteria for the consensus module to accept\nthe list of transactions ltx on top of state s .\nThe proof shows that consensusAcceptableTxs s ltx implies that when the execution\nmodule executes all the transactions in ltx one by one on top of s, none of them will\nfail due to having insufficient balance to cover gas fees. The proof is by induction\non the list ltx : one can think of this as doing natural induction on the length of ltx .\nThe proof in the inductive step involves unfolding the definitions of the consensus\nand execution checks and considering all the cases. In each case, the estimates of\neffective reserve balance in consensus checks is shown to be conservative with respect\nto what happens in execution.\nAdditional examples\nTo test your understanding, here are some examples along with the expected outcome.\nEach example is independent.\nIn the following examples, we use start_block = 2 , meaning the initial balances\nand reserves are after block 1. We also specify the reserve balance parameter for\neach example, although it is a constant system wide parameter.\nFor each transaction, the expected result is indicated by a code:\n- 2 : Successfully executed\n- 1 : Included but reverted during execution (due to reserve balance dip)\n- 0 : Excluded by consensus\nExample 1: Basic transaction inclusion\nInitial state:\nAlice: balance = 100, reserve = 10\nBob: balance = 5, reserve = 10\nTransactions:\nBlock 2: [\nAlice: send 1 MON, fee 0.05 — Expected: 2\nBob: send 2 MON, fee 0.05 — Expected: 2\n]\nFinal balances:\nAlice: 98.95\nBob: 2.95\nExample 2: Low reserve balance but high balance\nInitial state:\nAlice: balance = 100, reserve = 1\nTransactions:\nBlock 2: [\nAlice: send 3 MON, fee 2 — Expected: 2 (emptying transaction)\nAlice: send 3 MON, fee 2 — Expected: 0 (excluded)\n]\nFinal balance:\nAlice: 95.0\nExample 3: Multi-block, low reserve but high balance\nInitial state:\nAlice: balance = 100, reserve = 1\nTransactions:\nBlock 2: [\nAlice: send 3 MON, fee 2 — Expected: 2\n]\nBlock 5: [\nAlice: send 3 MON, fee 2 — Expected: 2\n]\nFinal balance:\nAlice: 90.0\nExample 4: Comprehensive\nInitial state:\nAlice: balance = 100, reserve = 1\nTransactions:\nBlock 2: [\nAlice: send 99 MON, fee 0.1 — Expected: 2 (large emptying transaction)\n]\nBlock 3: [\nAlice: send 0.5 MON, fee 0.99 — Expected: 0 (excluded)\n]\nBlock 4: [\nAlice: send 0.8 MON, fee 0.1 — Expected: 1 (included but reverted)\n]\nBlock 5: [\nAlice: send 0 MON, fee 0.9 — Expected: 0 (excluded)\nAlice: send 5 MON, fee 0.1 — Expected: 1 (included but reverted)\nAlice: send 5 MON, fee 0.8 — Expected: 0 (excluded)\n]\nFinal balance:\nAlice: 0.70\nExample 5: Edge case — zero value transactions\nInitial state:\nAlice: balance = 2, reserve = 1\nTransactions:\nBlock 2: [\nAlice: send 0 MON, fee 0.5 — Expected: 2\nAlice: send 0 MON, fee 0.6 — Expected: 2\nAlice: send 0 MON, fee 0.5 — Expected: 0 (exceeds reserve)\n]\nFinal balance:\nAlice: 0.9\nExample 6: Reserve balance boundary\nInitial state:\nAlice: balance = 10, reserve = 2\nTransactions:\nBlock 2: [\nAlice: send 1 MON, fee 2 — Expected: 2 (matches reserve)\nAlice: send 0 MON, fee 0.01 — Expected: 2\n]\nFinal balance:\nAlice: 6.99\nExample 7: Account delegated in the interim\nInitial state:\nAlice: balance = 15, reserve = 10\nTransactions:\nBlock 1: []\nBlock 2: [\nAlice is delegated\nBob on behalf of Alice: send 5 MON, fee 0 — Expected: 2 (executed)\nAlice is undelegated\n]\nBlock 3: [\nAlice: send 3 MON, fee 0.1 — Expected: 1 (included but reverted)\n]\nBlock 4: []\nBlock 5: [\nAlice: send 0 MON, fee 8 - Expected: 2 (executed)\n]\nFinal balance:\nAlice: 1.9\nNOTE : If execution would not have reverted transaction in Block 3 (by checking delegation\nstatus in prior k blocks), consensus would include transaction in Block 5 which would later run\nout of MON for the fee.\nAlso, consider Block 2 is empty instead. Transaction in Block 3 is then an emptying transaction,\nwhich proceeds with execution, but transaction in Block 5 is excluded as not having enough reserve\nfor fee.\nExample 8: Account receives MON before second inflight tx\nInitial state:\nAlice: balance = 15, reserve = 10\nTransactions:\nBlock 1: []\nBlock 2: [\nAlice: send 6 MON, fee 0.1 - Expected: 2 (executed, emptying tx)\n]\nBlock 3: [\nAlice receives 6 MON from a smart contract\nAlice: send 7 MON, fee 0.1 — Expected: 1 (included but reverted, cannot be 2nd emptying so soon)\n]\nBlock 4: []\nBlock 5: [\nAlice: send 0 MON, fee 8 - Expected: 2 (executed)\n]\nFinal balance:\nAlice: 6.8\nNOTE : If execution would not have reverted the 2nd transaction in Block 3 (from Alice; by\nchecking existence of emptying transactions in prior k blocks), consensus would include\ntransaction in Block 5 which would later run out of MON for the fee.\nAlso, consider Block 2 is empty instead. Transaction in Block 3 (from Alice) is then an emptying\ntransaction, which proceeds with execution, but transaction in Block 5 is excluded as one\npotentially not having enough reserve for fee - consensus doesn’t see Alice being credited in\nBlock 3 .\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.metaplex.com/docs/tokens/create-a-token","domain":"www.metaplex.com","title":"Create a Fungible Token | Tokens","hash":"5c936e31275edbab70ffdd7f7e9ce5a63685acf64e88a8eca02270da2b18a382","tokens":1446,"chars":5783,"crawler":"crawler-f6nn","verified":"exact","ts":1791172049484,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nGetting Started\nCreate a Fungible Token\nLast updated November 25, 2025\nCreate a fungible token with metadata on Solana using the Token Metadata program.\nWhat You'll Learn\nThis guide shows you how to create and mint a fungible token with:\n- Custom name, symbol, and metadata\n- Token image and description\n- Configurable decimals (divisibility)\n- Initial token supply\nCreate a Token\nThe following code is a fully runnable example. Below the parameters that you might want to customize are shown. You can learn more about token creation details in the Token Metadata program pages.\n1 // npm install @metaplex-foundation/mpl-token-metadata @metaplex-foundation/mpl-toolbox @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n2 import {\n3 createFungible ,\n4 mplTokenMetadata ,\n5 } from '@metaplex-foundation/mpl-token-metadata'\n6 import {\n7 createTokenIfMissing ,\n8 findAssociatedTokenPda ,\n9 mintTokensTo ,\n10 } from '@metaplex-foundation/mpl-toolbox'\n11 import {\n12 generateSigner ,\n13 keypairIdentity ,\n14 percentAmount ,\n15 some ,\n16 } from '@metaplex-foundation/umi'\n17 import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'\n18 import { readFileSync } from 'fs'\n19\n20 // Initialize Umi with your RPC endpoint\n21 const umi = createUmi ( 'https://api.devnet.solana.com' ) . use ( mplTokenMetadata ( ) )\n22\n23 // Load your wallet keypair\n24 const wallet = ''\n25 const secretKey = JSON . parse ( readFileSync ( wallet , 'utf-8' ) )\n26 const keypair = umi . eddsa . createKeypairFromSecretKey ( new Uint8Array ( secretKey ) )\n27 umi . use ( keypairIdentity ( keypair ) )\n28\n29 // Generate a new mint account\n30 const mint = generateSigner ( umi )\n31\n32 // Step 1: Create the fungible token with metadata\n33 await createFungible ( umi , {\n34 mint ,\n35 name : 'My Fungible Token' ,\n36 symbol : 'MFT' ,\n37 uri : 'https://example.com/my-token-metadata.json' ,\n38 sellerFeeBasisPoints : percentAmount ( 0 ) ,\n39 decimals : some ( 9 ) ,\n40 } ) . sendAndConfirm ( umi )\n41\n42 // Step 2: Mint initial supply to your wallet\n43 await createTokenIfMissing ( umi , {\n44 mint : mint . publicKey ,\n45 owner : umi . identity . publicKey ,\n46 } )\n47 . add (\n48 mintTokensTo ( umi , {\n49 mint : mint . publicKey ,\n50 token : findAssociatedTokenPda ( umi , {\n51 mint : mint . publicKey ,\n52 owner : umi . identity . publicKey ,\n53 } ) ,\n54 amount : 1_000_000_000_000_000 , // 1,000,000 tokens with 9 decimals\n55 } )\n56 )\n57 . sendAndConfirm ( umi )\n58\n59 console . log ( 'Token created:' , mint . publicKey )\n60 console . log ( 'Metadata and mint account initialized' )\n61 console . log ( 'Initial supply minted to:' , umi . identity . publicKey )\n1 import { generateKeyPairSigner } from '@solana/kit' ;\n2 import { createFungible } from '@metaplex-foundation/mpl-token-metadata-kit' ;\n3\n4 // Assuming rpc, rpcSubscriptions, and sendAndConfirmInstructions are set up\n5 // See getting-started for full setup\n6\n7 const mint = await generateKeyPairSigner ( ) ;\n8 const authority = await generateKeyPairSigner ( ) ; // Your wallet\n9\n10 // Create a fungible token with metadata and mint initial supply\n11 const createAndMintIx = await createFungible ( {\n12 mint ,\n13 authority ,\n14 payer : authority ,\n15 name : 'My Fungible Token' ,\n16 symbol : 'MFT' ,\n17 uri : 'https://example.com/my-token-metadata.json' ,\n18 sellerFeeBasisPoints : 0 ,\n19 decimals : 9 ,\n20 tokenOwner : authority . address ,\n21 amount : 1_000_000_000_000_000n , // 1,000,000 tokens with 9 decimals\n22 } ) ;\n23\n24 // Send the instruction (createFungible returns a single combined instruction)\n25 await sendAndConfirm ( {\n26 instructions : [ createAndMintIx ] ,\n27 payer : authority ,\n28 } ) ;\n29\n30 console . log ( 'Fungible token created:' , mint . address ) ;\n31 console . log ( 'Initial supply minted to:' , authority . address ) ;\n1 # Create a Fungible Token using the Metaplex CLI\n2\n3 # Interactive wizard mode (recommended for beginners)\n4 mplx toolbox token create --wizard\n5\n6 # Basic token creation (required: --name, --symbol, --mint-amount)\n7 mplx toolbox token create \\\n8 --name \"My Token\" \\\n9 --symbol \"MYT\" \\\n10 --mint-amount 1000000\n11\n12 # Full token creation with all options\n13 mplx toolbox token create \\\n14 --name \"My Token\" \\\n15 --symbol \"MYT\" \\\n16 --description \"A fungible token on Solana\" \\\n17 --image ./token-image.png \\\n18 --decimals 9 \\\n19 --mint-amount 1000000000000000\n20\n21 # Create with a vanity mint address\n22 mplx toolbox token create \\\n23 --name \"Cool Token\" \\\n24 --symbol \"COOL\" \\\n25 --mint-amount 1000000 \\\n26 --mint-keypair ./vanity-mint.json\n27\n28 # Note: mint-amount is in smallest units\n29 # With --decimals 9, to mint 1,000,000 tokens: --mint-amount 1000000000000000\n30 # With --decimals 0 (default), to mint 1,000,000 tokens: --mint-amount 1000000\nParameters\nCustomize these parameters for your token:\nParameter Description\nname Token name (max 32 characters)\nsymbol Short name of your Token (max 6 characters)\nuri Link to off-chain metadata JSON\nsellerFeeBasisPoints Royalty percentage (550 = 5.5%)\ndecimals Decimal places ( some(9) is standard)\namount Number of tokens to mint\nMetadata and Images\nThe uri should point to a JSON file containing at least the following information. You can find more details on the Token Metadata Standard page . You need to upload the JSON and the image url so that they are accessible from everywhere. We recommend to use a web3 storage provider like Arweave. If you want to do so by code you can follow this guide on creating deterministic metadata with Turbo .\n{\n\"name\" : \"My Fungible Token\" ,\n\"symbol\" : \"MFT\" ,\n\"description\" : \"A fungible token on Solana\" ,\n\"image\" : \"https://arweave.net/tx-hash\"\n}\nPrevious\n← Overview\nNext\nLaunch a Token →"}
{"url":"https://bitcoinops.org/en/newsletters/2026/07/31/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #416 | Bitcoin Optech","hash":"b1bc0ccebfcd45cf2e93e401cd033f45faa0793c18f7fe9b590f6e0b4ef4d63f","tokens":4090,"chars":16359,"crawler":"crawler-f6nn","verified":"exact","ts":1791172052718,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #416\nJul 31, 2026\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.\nAction items\n- ● Move funds secured by COLDCARD-generated keys: if you used a\nCOLDCARD Mk3 to generate a wallet, any funds received by that wallet\nare at risk of theft and should be carefully moved to an unaffected\nwallet as soon as possible. Wallets generated by other COLDCARD\nmodels may also be affected. See the News section below for details.\nNews\n-\n● Wallets generated by COLDCARD at risk of theft :\nOn 30 July 2026, some Bitcoin users discovered that funds from their COLDCARD\nwallets had been stolen in a series of unexpected transactions on 29 July.\nOver the course of the day, a bug was identified in the firmware of the\nCOLDCARD Mk3 that causes wallets to be generated with insufficient\nentropy. As of this writing, estimated losses exceed 1,000 BTC, a figure\nthat may continue to rise as the situation develops.\nA security advisory by Coinkite identified wallets\ngenerated by COLDCARD Mk3 using firmware version 4.0.1 (March 2021) or later,\nincluding the latest released version, as vulnerable to theft, unless the\nseed was created with sufficient externally generated entropy (such as 50 or\nmore private dice rolls) or the wallet was additionally encumbered with a\nstrong passphrase. The advisory also identifies seeds generated by Mk4 and\nMk5 firmware before version 5.6.0 and Q firmware before version 1.5.0Q as\naffected.\nIn a follow-up technical backgrounder , Coinkite\nattributes the bug to a 2021 code change that unintentionally routed seed\ngeneration to a software PRNG, initialized from predictable device-unique\nvalues, instead of the device’s hardware RNG. Seeds generated by an\naffected Mk3 without supplemental dice rolls have roughly 40 bits of\neffective entropy instead of the intended 128. Seeds from affected Mk4,\nMk5, and Q devices are harder to attack because output from a secure\nelement is also mixed in, although an analysis by Block,\nperformed with anonymous researchers and disclosed in coordination with\nCoinkite, found that only 32 bits of that entropy reach the PRNG state,\nleaving those seeds still well below the intended security level.\nSeveral developers were able to immediately reproduce the attack with the\nassistance of frontier AI models, so the vulnerability should be assumed to\nbe under active exploitation. Block’s analysis additionally identifies the\nolder COLDCARD Mk2 running 4.x firmware as affected to the same degree as\nthe Mk3, and notes that other randomly generated secrets, such as\npaper-wallet private keys and ephemeral seeds, are also affected.\nThis is an evolving situation, and additional information is likely to\nemerge after this newsletter’s publication. Readers should monitor\nCoinkite’s blog and other sources for updates. Bitcoin Optech\nrecommends that COLDCARD users whose wallets may be affected\nmove their funds carefully to an unaffected wallet as soon as possible.\nSeeds generated on an affected device without supplemental dice rolls\nshould be treated as compromised. Users of Mk4, Mk5, and Q devices should\nupgrade to fixed firmware before generating any new wallets. Upgrading\nalone does not make an existing seed safe.\n-\n● Disclosure of two DoS vulnerabilities in Core Lightning : Chandra Pratap\nposted to Delving Bitcoin about two denial-of-service (DoS)\nvulnerabilities he found\nin Core Lightning during his internship for the Summer of Bitcoin\nprogram. Specifically, these vulnerabilities would have allowed an attacker to crash\na node by exhausting its memory. The bugs are related to the gossipd daemon\nstate machine, in particular to its interface with the connectd daemon.\nPratap was able to find the vulnerabilities thanks to his work on a new fuzz\ntarget, fuzz-gossipd-connectd , which aims to test the robustness of the\ncommunication between the two modules.\nThe first vulnerability was related to the inter-daemon message queue,\nshared between the two daemons, whose goal is to store all the channel_update\nmessages arriving from the network. An attacker would have been able to flood\nthe node with messages, causing the internal queue to grow indefinitely and leading\nto the consumption of all the available RAM. The bug was simply fixed in\nCore Lightning #8376 by allowing the queue to drop messages,\nadding a cutoff point at 500,000 messages.\nThe second vulnerability was found while trying to fix the first one.\nIn particular, this was related to the internal map used to track unknown short\nchannel IDs (SCIDs) to query peers for possible missing channels.\nAn attacker would have been able to flood the node with fake SCIDs, causing an\never-increasing memory consumption. Although the bug had not been previously\nreported, Rusty Russell was already working on a patch in\nCore Lightning #8903 , which introduced an improved garbage collection\nmechanism for the internal map.\n-\n● Proof of concept for a zero-knowledge proof of reserves : fabohax posted\nabout zkPoH (“zero-knowledge proof-of-hodl”), a proof of concept for a\nnon-custodial proof of reserves system for Bitcoin.\nThe prototype allows a user to prove that they control a set of UTXOs, whose combined\nvalue is at least 100,000,000 sats (1 BTC), without revealing any further information.\nThe proof of concept takes as input a UTXO snapshot generated off-chain, which is then\ncommitted into a merkle tree, whose root becomes the public commitment. The prover\nselects up to four UTXOs from the snapshot and generates the witness input for the\nNoir circuit, which verifies that the chosen UTXOs actually belong to\nthe snapshot, the merkle paths are valid, and the sum of the selected UTXOs is at\nleast the required amount. The verifier only learns that the prover satisfies the\n100,000,000 sats requirement.\nAs of this writing, an explicit ownership binding step is not available in the proof of\nconcept. This means that there is no way to prove that the chosen UTXOs actually\nbelong to the prover. The author is currently working on adding this feature, either\nthrough an off-circuit ownership check or directly inside it. The prototype is\ncurrently available in a dedicated repository .\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● What is Bitcoin’s objective definition of transaction neutrality?\nAva Chow frames neutrality as whether a change prevents anyone from\ncontinuing to use Bitcoin as they already do, such as making previously\nspendable scripts unspendable or breaking a deployed protocol.\n-\n● Why does BIP110’s decentralization benefit not outweigh its impact on transaction neutrality?\nPieter Wuille argues that invalidating data-carrying transaction patterns\nwould not reduce node costs because the block weight limit already bounds\nresource usage, data storage bytes are among the cheapest to process, and\noutlawed patterns would simply be replaced by other transactions.\n-\n● Why does BIP110 require a 55% signaling threshold if its nodes reject non-signaling blocks?\nVojtěch Strnad explains that the threshold applies to voluntary miner\nsignaling before the mandatory signaling period begins (see Newsletter\n#392 ). An early lock-in indicates wider buy-in and can\nactivate the soft fork sooner, but once mandatory signaling begins, enforcing\nnodes discard non-signaling blocks.\n-\n● Why use ElligatorSwift encoding in BIP324?\nPieter Wuille explains that encoding the handshake’s public keys as\nuniformly random bytes makes the entire v2 transport bytestream pseudorandom, preventing identification by pattern\nmatching and forcing a censoring firewall to either mount a full\nman-in-the-middle attack or operate an allowlist. It can also make it easier\nto mimic other protocols.\n-\n● Was the OP_SUCCESSx reservation in BIP342 designed with specific opcode families in mind?\nMurch describes the OP_SUCCESS opcodes as generic upgrade hooks. Since\nany OP_SUCCESS makes a tapscript unconditionally\nvalid, a future soft fork can redefine one with more restrictive\nbehavior, including stack manipulation that redefined OP_NOP opcodes\ncould never perform.\n-\n● What is the difference between the long-term feerate and the discard feerate?\nMurch clarifies that the two are not interchangeable. The discard feerate\nsets the dust limits below which a potential change output’s value is given\nto fees, while the long-term feerate sets the wallet’s boundary between\nconsolidatory and thrifty coin selection .\n-\n● What is the quickest method for migrating a legacy wallet to a descriptor wallet on a pruned node?\nPol Espinasa explains that migration attempts to load the migrated wallet,\nwhich fails on a node pruned below the wallet’s birthday. Bitcoin Core\n#35266 (see Newsletter #412 ), expected in\nversion 32.0, allows migrating without loading the wallet, although loading\nthe migrated descriptor wallet will still require a\nnode with the relevant blocks.\n-\n● Is there historical data on orphan/stale block rates during high-fee periods?\n0xB10C points to the stale-blocks dataset maintained by\nthe bitcoin-data project, which charts the stale block rate over time and\nprovides the raw data for deriving custom metrics.\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● BTCPay Server 2.4.1 is a maintenance release for this self-hosted payment\nprocessor. It adds BIP329 wallet label imports (see Newsletter\n#415 ), editable invoice comments, and several other\nimprovements and bug fixes.\n-\n● Eclair 0.14.1 is a maintenance release for this LN node implementation.\nIt now requires Bitcoin Core 31.x, disables an experimental BOLT12 blinded-path fee discount that did not correctly work with\nmultipath payments , and includes several bug fixes\nand performance improvements. Operators using custom offer-handler plugins\nshould review the release 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 #34628 replaces independent per-peer transaction relay\nbacklogs with global inbound and outbound backlogs controlled by count and\nserialized size token buckets. This reduces duplicate storage and sorting\nacross peers, which contributed to a CPU exhaustion problem (see Newsletter\n#324 ). Relay credit starts at 420 transaction tokens and 12 MB,\nreplenishing at a rate of 14 transactions and 20 kB/s for the inbound peer\nbacklog. The count balance is capped at 420 tokens, while the size balance can\naccumulate up to 50 MB. The outbound refill rate retains the 2.5-times\nmultiplier described in Newsletter #373 . When relay demand\nexceeds available credit, transactions are prioritized by mining score while\nrespecting dependencies. Selected transactions then enter small, randomized,\nper-peer queues. New getnetworkinfo fields expose each backlog and its token\nbalances, and the debug-only -txsendrate option allows testing different\ncount rates.\n-\n● Bitcoin Core #28463 increases the default maximum number of connections\nfrom 125 to 200 and adds the -inboundrelaypercent option (default 50), which\nsets the maximum percentage of inbound slots that transaction-relaying peers\ncan occupy. With eleven outbound slots by default, 189 slots remain available\nfor inbound connections, of which at most 94 may be occupied by\ntransaction-relaying peers under the default setting. This limit is enforced\nafter a peer announces its relay preference and is rechecked if the peer later\nenables transaction relay using BIP37 messages. This reserves capacity for\nlow-bandwidth block relay and prepares for the addition of more outbound\nblock-relay-only connections, to improve resistance to eclipse attacks .\n-\n● Bitcoin Core #32800 adds explicit BIP141 and policy-adjusted\ntransaction size fields to several RPCs. vsize_bip141 reports the virtual\nsize calculated from the transaction’s weight, while vsize_adjusted reports\nthe greater of that value or the size implied by the transaction’s sigops cost\nunder the configured -bytespersigop policy. The adjusted value is used for\nmempool policy and block template feerate calculations. getmempoolentry ,\nverbose getrawmempool , testmempoolaccept , and submitpackage now report\nboth fields. The existing vsize field, which was documented as the BIP141\nvirtual size but actually contained the policy-adjusted value, is retained but\nmarked as deprecated. Additionally, getrawtransaction reports\nvsize_adjusted when the transaction is in the mempool, while its existing\nvsize remains the BIP141 value. The verbose output of getorphantxs also\nadds the explicit vsize_bip141 field.\n-\n● Bitcoin Core #34683 adds an automatically generated OpenRPC 1.4.1\ndescription of the RPC interface. The new rpc.discover RPC returns the\npublic interface, while getopenrpcinfo can optionally include hidden\ncommands and arguments. The document is generated at runtime from the\nRPCHelpMan metadata for all registered RPCs, and describes method\nparameters, required and default values, result shapes, and other interface\ndetails.\n-\n● Bitcoin Core #33014 fixes how descriptorprocesspsbt (see Newsletter\n#253 ) handles a PSBT whose finalized\nscript fields are populated but contain invalid signatures. Previously, the\nRPC only checked for the presence of final scripts, marked the PSBT as\ncomplete, and returned an internal error when transaction extraction failed.\nNow, it verifies every input before reporting completion, so a PSBT with an\ninvalid signature returns complete: false without a serialized transaction\nin the hex field.\n-\n● Eclair #3325 accepts BOLT12 invoice onion messages that include a reply_path . A payee can attach a\nblinded reply path to an invoice so that the payer can\nreturn an invoice_error if it considers the invoice invalid. Eclair\npreviously rejected this combination, causing interoperability problems with\nLDK, which added reply paths to invoices (see Newsletter #321 ).\n-\n● BOLTs #1346 specifies BOLT12 payer proofs, a receipt format\nthat allows a payer to prove they paid an invoice\nusing the payment preimage, the invoicing node’s signature, and a payer\nsignature from invreq_payer_id , while allowing selected invoice fields to be\nomitted for privacy. The specification assigns the lnp human-readable\nprefix and adds generation and verification test vectors. Core Lightning\nexperimentally implemented an earlier draft (see Newsletter #405 ).\n-\n● BOLTs #1344 extends the attributable failures protocol to successful payments by adding an optional\nfulfillment_payload to update_fulfill_htlc , the message that returns the\npayment preimage and settles an HTLC . Only a padding field is\ndefined, so the PR establishes transport for future success-related data, such\nas signed keysend receipts, without yet\nstandardizing any application.\n-\n● BOLTs #1343 adds the option_onion_messages_only_channels feature bit for\nnodes that only accept onion messages from channel\npeers. Nodes that do not advertise this feature should accept onion messages\nfrom peers without channels, though they may still rate-limit or drop them.\nThis feature allows senders to avoid relay paths that are known to fail while\nenabling operators to reduce their exposure to denial-of-service attacks. See\nNewsletter #409 for an LDK workaround that addresses LND’s\nbehavior of receiving but not forwarding onion messages from non-channel\npeers."}
{"url":"https://bitcoinops.org/en/newsletters/2026/05/01/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #403 | Bitcoin Optech","hash":"86aad06e2e57531c83b4c43c1a798b348f07b3f7930e6842e239eb9307ca67a1","tokens":2818,"chars":11270,"crawler":"crawler-f6nn","verified":"exact","ts":1791172055089,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #403\nMay 1, 2026\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.\nNews\n-\n● Binary fuse filters as an alternative to BIP158’s GCS : Csaba Purszki\nposted to Delving Bitcoin his research on finding a better alternative\nto Golomb-Rice Coded Sets (GCS) used for compact block filters\nas defined in BIP158 .\nAccording to Purszki, a suitable alternative can be found in binary fuse\nfilters, a family of probabilistic data structures for approximate set\nmembership, and specifically the 16-bit variant, called Fuse16. The main\ncharacteristic of this type of algorithm is the ability to give O(1) query\ntime (for reference, GCS gives O(N)), which reduces the CPU power required to\nquery the filters. Moreover, these filters guarantee zero false negatives,\nwith a rate of false positives equal to 1/2^k , with k being the number of\nbits.\nPurszki provided the preliminary results of his research, which compare the current GCS\nperformance against binary fuse filters. Tests were performed on 10 different wallet\nuse cases (from 24 scripts up to 480), running filters on 50,000 mainnet blocks,\non two different CPUs, a desktop x86_64, and an ARM. Binary fuse filters were able to\nobtain a 6x-45x speedup on ARM, according to the different wallet use cases, and 9x-80x\non desktop at the cost of a slight increase in bandwidth, 0%-3%. For a full write up on\nthe methodology and full results, the reader can refer to Purszki’s website .\nKyoto developer Robert Netzke commented on the differences in false positive\nrates with respect to GCS and possible failures that could occur in the\nalgorithm.\nChanging consensus\nA monthly section summarizing proposals and discussion about changing\nBitcoin’s consensus rules.\n-\n● Post-quantum HD wallets with fallback SPHINCS keys: In a\npost on the Bitcoin-Dev mailing list, Conduition described\na design for post-quantum BIP32 congruent hierarchical deterministic\nwallets with fallback SPHINCS keys. The design replaces\nthe child key derivation functions of BIP32 to generate SPHINCS keys\nalongside secp256k1 keys. Due to the lack of an algebraic\nrelationship within SPHINCS keys, non-hardened child keys share the same\nSPHINCS keys as their parents and siblings. This requires wallets to insert\na nonce (or the secp256k1 key) into scripts spent using the SPHINCS key to\nretain privacy equivalent to BIP32 wallets. A benefit of this design choice\nis that the expensive full SPHINCS key derivation can be deferred to the\nfirst non-hardened derivation step and then cached for all non-hardened keys\nbelow that step. This wallet design is intended to be combined with\nBIP360 P2MR outputs and a future OP_CHECKSPHINCS (or similar) to\nenable migration to quantum-resistant wallets. Conduition suggests that such\na wallet structure might also be combined with future lower-cost\npost-quantum signature algorithms with SPHINCS providing a dependable\nfallback in case they are proven insecure.\n-\n● Discussion of a post-quantum output type : Antoine Poinsot wrote to\nthe Bitcoin-Dev mailing list defending a plain post-quantum output type (as\nopposed to a P2TR -like output type which allows\nquantum-vulnerable key spending to be disabled by a later soft fork). The\ncrux of the argument is that the decision of whether or when it makes sense\nto disable quantum-vulnerable spends should be separated from enabling users\nto migrate to post-quantum cryptography at their discretion. In the\nsubsequent conversation, the participants agreed on both adding\npost-quantum signing to tapscript and adding a plain post-quantum output\ntype. Several open questions remain, including whether and to what degree to\nincentivize migration and when / whether to disable quantum-vulnerable\nsignatures.\n-\n● Proposal to embed post-quantum keys in tapscript without consensus changes : Daniel\nBuchner sent a proposal to the Bitcoin-Dev mailing list\nwhich describes a potential path to enabling flexible post-quantum wallet\ndesigns without fully describing the signature validation parameters.\nBecause BIP342 signature checking opcodes treat all non-32-byte keys as\nunknown key types which are valid with any non-empty signature, other key\nlengths (in this case with an initial tag byte) can be used in scripts today\nas long as either the scripts are kept secret or they also require a secure\nBIP340 signature in addition to the unknown key or keys. If Buchner’s\nproposal were to be standardized, wallets could start building scripts with\nvarious post-quantum key types now while continuing to spend using\nquantum-vulnerable keys until such time as a soft fork enables secure\nspending with the post-quantum keys. Like many quantum migration proposals,\nthis proposal only retains security in the face of a quantum adversary if\nkey reuse is strictly prevented. Buchner is seeking feedback on the\nproposal.\n-\n● BIP54 demonstration of slow blocks on signet : On Delving Bitcoin,\nAntoine Poinsot wrote about a demonstration of the\ntypes of slow-to-validate blocks that BIP54\n( consensus cleanup ) prevents. Repeated three times over the course of a\nday, batches of slow-to-validate blocks were signed on the most popular\nBitcoin signet and then reorged away to enable testing of\npropagation and validation behavior of these blocks without forever slowing\nsignet initial block download. Many around the world watched the slow blocks\nhit their nodes and logged the validation and propagation behavior. As\nexpected, the slow-to-validate blocks propagated much more slowly through\nthe network and required significantly more time to be fully validated on\nindividual nodes compared to typical blocks. It should be noted that these\ndemonstration blocks were far from the worst case that is prevented by\nBIP54.\n-\n● Post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds :\nOlaoluwa Osuntokun (roasbeef) posted on the Bitcoin-Dev\nmailing list his project to demonstrate zk-STARK recovery of\nquantum-vulnerable coins secured by keys derived using BIP32 . This\npossible mechanism for coin recovery in the event that\nsecp256k1 is disabled in the face of a cryptographically\nrelevant quantum computer has long been discussed, but never fully\ndemonstrated. Osuntokun produced a fully working implementation of the\nrequired prover and verifier and provided benchmarks showing that recovery\nusing this method is, at least, possible. The original implementation was\nintentionally not optimized and several developers offered optimizations\nthat make the recovery less costly both to prove and to verify.\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 26.04.1 is a maintenance release that includes\ngossip protocol fixes, as well as build system\nfixes for environments that experienced problems immediately after the major\nrelease.\n-\n● BTCPay Server 2.3.8 is a minor release of this self-hosted payment\nsolution that includes subscription and point-of-sale updates, LUD21 LNURL-pay support, an additional API surface for managing subscription offerings,\nand other fixes and improvements.\n-\n● BTCPay Server 2.3.9 is a maintenance release that addresses server\nrecovery after a plugin crash and fixes an xpub parsing issue that was\nintroduced in v2.3.8.\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 #33671 adds a nonmempool field to the getbalances RPC\n(see Newsletter #46 ) for wallet UTXOs spent by\ntransactions that are neither confirmed nor in the node’s mempool, such as\nunbroadcasted, non-standard, evicted, or transactions that are part of\ntoo-long mempool chains. Previously, balance buckets could omit value tied\nto those in-flight spends even though the wallet still recorded the\ntransactions, so getbalances did not fully reflect how the wallet was\naccounting for those coins. The PR counts that value in the usual mine\nbuckets where it belongs and applies an offset via nonmempool so the\nfields sum to the wallet’s overall balance while making the mempool mismatch\nexplicit.\n-\n● Bitcoin Core #34885 adds btck_block_tree_entry_get_ancestor() to the\nlibbitcoinkernel C API (see Newsletter #380 ) for\nretrieving the ancestor of a block at a specified height on its chain branch.\nInstead of walking backward one block at a time with repeated calls to\nbtck_block_tree_entry_get_previous() , callers constructing block locators\nfrom a stale or forked tip can directly request ancestors at the needed\nheights.\n-\n● Bitcoin Core #33920 adds an exportasmap RPC that exports the node’s\nASMap data embedded at build time (see Newsletter #394 ) to a\nfile. This allows users to inspect, validate, and analyze the data using tools\nsuch as contrib/asmap-tool.py .\n-\n● Bitcoin Core #34911 removes deprecated RBF -related boolean\nfields from several mempool RPC responses unless they are explicitly requested\nusing the deprecatedrpc configuration option. The getmempoolinfo RPC no\nlonger returns the fullrbf field by default, as full-RBF behavior has been\nthe default since Bitcoin Core 28.0 and the mempoolfullrbf option was\nremoved in Bitcoin Core 29.0. The getrawmempool , getmempoolentry ,\ngetmempoolancestors , and getmempooldescendants RPCs no longer return the\ndeprecated bip125-replaceable field described in BIP125 by default.\n-\n● BIPs #1548 adds BIP391 , a specification for Binary Output Descriptors\n(BOD), an efficient container format for output script descriptors based on PSBT -style key-value maps. This BIP has a\nclosed status and lists BIP393 as a proposed replacement, noting that\nBIP391 was withdrawn after BIP393 proposed an alternative method for\nhandling wallet metadata such as descriptor annotations (see Newsletter\n#400 ).\n-\n● HWI #831 adds support for the Ledger Nano Gen5 hardware signing device.\n-\n● BDK #2188 starts verifying that a transaction returned by an Electrum\nserver matches the requested txid before caching or using it. Previously, a\nserver could respond to a fetch_tx() request with any transaction data and a\ndifferent txid, and BDK would accept it.\n-\n● BDK #2115 adds previous-block-hash awareness to CheckPoint by extending\nthe ToBlockHash trait with an optional prev_blockhash() method. This\nallows BDK to verify that adjacent checkpoints connect when their payloads\ncontain previous-block-hash information, such as in block headers. This also\nprevents merge_chains() from treating a conflicting height-0 checkpoint as a\nnormal reorg and replacing it. Now, if two checkpoint chains disagree on\ngenesis, the merge fails. See Newsletters #372 and\n#390 for previous work on CheckPoint ."}
{"url":"https://docs.sui.io/onchain-finance/asset-custody/","domain":"docs.sui.io","title":"Asset Custody","hash":"506e7dbba9f9dfe89fe2cb6df9b85a5ea41e273bc3913825d519e61fd8795561","tokens":315,"chars":1258,"crawler":"crawler-f6nn","verified":"exact","ts":1791172057611,"text":"# Asset Custody\n*[Documentation index](/llms.txt) · [Full index](/llms-full.txt)*\nLearn more about custody of digital assets on Sui.\nLearn about the tools and patterns available for managing custody of digital assets on Sui, including fungible tokens, closed-loop tokens, and tokenized assets.\n- [Address Aliases for Asset Custody](address-aliases) — Use address aliases to allow multiple keys to act as a single Sui address, enabling key rotation and account abstraction without asset migration.\n- [Address Balances](address-balances/) — Address balances introduce a canonical balance system for fungible assets tied to Sui addresses, replacing coin-selection complexity with a single per-address accumulator value.\n- [Fiat Off-Ramps](fiat-off-ramps) — Convert Sui-native tokens to fiat currency using third-party off-ramp providers integrated with the Sui network.\n- [Fiat On-Ramps](fiat-on-ramps) — Accept fiat payments and deliver Sui-native tokens to user wallets using third-party on-ramp providers integrated with the Sui network.\n- [Wallets](wallets/) — Understand how Sui wallets work, explore available wallet types including Slush, self-custodial, and zkLogin wallets, integrate wallets into your app, and connect wallets across apps with SuiLink."}
{"url":"https://docs.ens.domains/ensv2/tutorial-app-developers","domain":"docs.ens.domains","title":"For App Developers | ENS Docs","hash":"ce83789571bbdaf63a9168147aa7e181e94e92e308f13b8fd843d34616244e4b","tokens":3022,"chars":12088,"crawler":"crawler-f6nn","verified":"exact","ts":1791172060243,"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\nFor App Developers\nThis guide walks through integrating ENSv2 into an application: resolving names like nick.eth to addresses, reading profile records, displaying primary names, and letting users update their own records.\nWhat Changes for Apps\nThe short answer: very little, by design. Forward resolution, text records, avatars, and primary names all work through the same library calls you use today; for read-only integrations, a library update is the entire migration. The ENSv2-specific parts of this page start at Writing Records : letting users update their records touches the new permission model.\nWhat changes underneath:\n- One entry point, new address. All resolution goes through the Universal Resolver , which walks the new hierarchical registries and orchestrates CCIP-Read (the actual gateway HTTP requests are made by your client library, as in ENSv1; a contract cannot fetch offchain data itself). Updated libraries target it automatically.\n- Records move to per-account resolvers. In ENSv1 most names shared a single Public Resolver contract. In the standard ENSv2 flow each account gets its own Permissioned Resolver instance. Reading records is unchanged (the Universal Resolver finds the right contract for you), but writing records means calling whatever resolver the name actually uses instead of a well-known shared one.\n- Names are ERC1155 tokens in per-name registries. Each parent name can have its own registry contract, so subnames form separate NFT collections. Token IDs are mutable , which matters if you index or cache them.\n- ENSv1 names keep working. Names that have not migrated resolve through a mirror resolver that forwards lookups into the v1 registry, so your integration does not need to distinguish between migrated and unmigrated names.\nSupported Libraries\nThe examples in this guide show four libraries side by side: viem, wagmi (which inherits ENS support from its installed viem), ethers, and ENSjs. Everything below assumes an ENSv2-ready version of your library; the ENSv2 readiness page tracks which versions those are, both for these four and for the wider ecosystem (web3.py, web3j, and others). ENSjs stands out for write flows: among the four shown here, it is the only one with purpose-built helpers for updating records.\nProject Setup\nENSv2 is currently deployed on Sepolia for testing. The Universal Resolver is an upgradeable proxy that lives at the same address on mainnet and Sepolia , and supported libraries ship that address for both networks. Targeting the ENSv2 test deployment is therefore nothing more than selecting the Sepolia chain; no address configuration is needed, and the same code runs against mainnet by switching the chain back.\nviem\nimport { createPublicClient, http } from 'viem'\nimport { sepolia } from 'viem/chains'\nconst client = createPublicClient ({\nchain: sepolia,\ntransport: http (),\n})\nThe client , config , and provider objects created here are reused by every snippet below. Write snippets additionally assume a connected wallet client ( wallet in viem/ENSjs, signer in ethers).\nResolving Names\nForward resolution (name to address) is one call. Always normalize user input first:\nviem\nimport { normalize } from 'viem/ens'\nconst address = await client. getEnsAddress ({\nname: normalize ( 'nick.eth' ),\n})\nUnder the hood, the Universal Resolver starts at the root registry and walks down one label at a time, asking each registry for the next one ( sub.nick.eth : root to eth to nick to sub ). Along the way it remembers the nearest resolver it has seen and calls it. When a name's data lives offchain or on an L2, the Universal Resolver drives the CCIP-Read protocol by telling your library which gateway to query; the library performs the HTTP request and feeds the response back for onchain verification. Your app never touches this machinery directly, but one consequence is worth knowing:\n- A subname without its own resolver is served by the closest ancestor resolver. Registration alone is enough for a subname to resolve if its parent's resolver has records for it.\nFor chain-specific addresses (resolving a name for use on an L2), pass a coinType . See Multichain Considerations for the full pattern, including why resolution always runs against L1 even for L2 apps.\nReading Records\nText records and avatars follow the same shape:\nviem\nimport { normalize } from 'viem/ens'\nconst twitter = await client. getEnsText ({\nname: normalize ( 'nick.eth' ),\nkey: 'com.twitter' ,\n})\nconst avatar = await client. getEnsAvatar ({\nname: normalize ( 'nick.eth' ),\n})\nThe standard record keys ( avatar , description , com.twitter , and so on) are unchanged from ENSv1; see Text Records for the list.\nPrimary Names\nDisplaying a primary name (reverse resolution: address to name) is also unchanged at the library level:\nviem\nconst name = await client. getEnsName ({\naddress: '0x1111111111111111111111111111111111111111' ,\n})\nA primary name must never be displayed without verifying that it forward-resolves back to the address. In ENSv2 the Universal Resolver enforces this onchain: during reverse resolution it forward-resolves the returned name and reverts with ReverseAddressMismatch if the addresses differ, so any result your library hands you has already passed the check. How primary names are set is evolving in ENSv2, including multi-chain primary names; see Reverse Resolution for the current state.\nWriting Records\nThis is the one place where ENSv2 changes your app's write path. The setter functions themselves are unchanged from ENSv1's public resolver interface, but there is no longer one well-known shared resolver your app can assume every name uses. In the standard flow, each account's records live on its own resolver instance, and records are keyed by the namehash of the full name. What is new is where records live and who is authorized to write them, not how they are written.\nThe flow: find the resolver the name actually uses, then call its setters as the name owner.\nFind the Resolver\nviem\nimport { normalize } from 'viem/ens'\nconst resolverAddress = await client. getEnsResolver ({\nname: normalize ( 'nick.eth' ),\n})\nSet Records\nENSjs is the only library in this guide with dedicated record-writing helpers ( setRecords , setTextRecord , setAddressRecord , and friends); it computes the namehash and batches multiple updates into a single resolver multicall for you. With the other libraries you call the resolver contract directly: the setters take the name's namehash as their first parameter, and the signatures below are the resolver's actual interface.\nviem\nimport { parseAbi } from 'viem'\nimport { namehash, normalize } from 'viem/ens'\nconst resolverAbi = parseAbi ([\n'function setAddr(bytes32 node, address addr_)' ,\n'function setText(bytes32 node, string key, string value)' ,\n'function multicall(bytes[] data) returns (bytes[])' ,\n])\nconst node = namehash ( normalize ( 'nick.eth' ))\n// wallet is a viem wallet client connected to the name owner's account\n// resolverAddress: from \"Find the Resolver\" above\nawait wallet. writeContract ({\naddress: resolverAddress,\nabi: resolverAbi,\nfunctionName: 'setText' ,\nargs: [node, 'com.twitter' , 'nicksdjohnson' ],\n})\nTo update several records in one transaction with viem, wagmi, or ethers, encode the individual calls and batch them through the resolver's multicall (ENSjs's setRecords does this automatically whenever you pass more than one record; wagmi's writeContract takes the same arguments as the viem call below):\nviem\nimport { encodeFunctionData, parseAbi } from 'viem'\nimport { namehash, normalize } from 'viem/ens'\nconst resolverAbi = parseAbi ([\n'function setAddr(bytes32 node, address addr_)' ,\n'function setText(bytes32 node, string key, string value)' ,\n'function multicall(bytes[] data) returns (bytes[])' ,\n])\nconst node = namehash ( normalize ( 'nick.eth' ))\n// userAddress: the address the name should resolve to\nawait wallet. writeContract ({\naddress: resolverAddress,\nabi: resolverAbi,\nfunctionName: 'multicall' ,\nargs: [[\nencodeFunctionData ({\nabi: resolverAbi,\nfunctionName: 'setAddr' ,\nargs: [node, userAddress],\n}),\nencodeFunctionData ({\nabi: resolverAbi,\nfunctionName: 'setText' ,\nargs: [node, 'com.twitter' , 'nicksdjohnson' ],\n}),\n]],\n})\nWho Can Write\nWrites are permissioned through Enhanced Access Control roles on the resolver. In the common case this is invisible to your app: an account that registers a name and deploys its resolver typically holds every role, so its setter calls simply succeed.\nThe case to be aware of is subnames. A subname owner typically uses the parent's resolver and holds no roles on it, so a setText from their wallet reverts with EACUnauthorizedAccountRoles . Depending on the setup, records for such names are managed by the parent owner, delegated per name or per record key via the resolver's authorize*Roles functions, or moved fully under the subname owner's control by pointing the subname at a resolver of their own. See Permissioned Resolver for the delegation model.\nListing a User's Names\nEnumerating all names an account owns is an indexed-data problem in ENSv2, same as in ENSv1: onchain lookups alone cannot enumerate names. Two v2-specific points if you build or consume an index:\n- Names are ERC1155 tokens, but each registry is its own contract and collection, and token IDs change when roles change. Key any cache by labelhash, never by token ID; see Mutable Token IDs .\n- See Indexing ENSv2 for the event-level details needed to index registries and resolvers yourself.\nFor the general patterns (and ENSv1 options that keep working), see Listing Names .\nTesting Your Integration\n- Resolution path : the readiness page provides test names (like ur.integration-tests.eth ) that verify your app reaches the correct Universal Resolver and handles CCIP-Read.\n- End to end on Sepolia : register a test name on the Sepolia deployment, set records with the snippets above, and confirm the resolution calls return them. The protocol contract addresses are in the Deployments table .\n- DNS names : make sure your name detection does not assume .eth ; see name detection .\nGetting Test Funds\nRegistering a name on the Sepolia deployment costs two things: Sepolia ETH for gas (any public faucet works) and the registration fee, which the ETH Registrar collects in an ERC20 token. On Sepolia that token is MockUSDC (address in the Deployments table ), and it is free: its mint function has no access control, so anyone can mint themselves a balance.\nimport { parseAbi } from 'viem'\n// MockUSDC, from the Deployments table\nawait wallet. writeContract ({\naddress: mockUsdcAddress,\nabi: parseAbi ([ 'function mint(address to, uint256 amount)' ]),\nfunctionName: 'mint' ,\nargs: [account, 100_000_000 n ], // 100 USDC (6 decimals)\n})\nBefore registering, approve the ETH Registrar to spend the minted balance; the registration flow itself is described on the ETH Registrar page.\nTroubleshooting\nSymptom Likely cause\nNames that resolve in other apps return null in yours Library version predates ENSv2 support; check the readiness page minimums\nA name your user just registered resolves to null No address record set yet; registration and records are separate steps\nRecord writes revert with EACUnauthorizedAccountRoles The connected account holds no roles on that resolver, most commonly a subname owner writing to the parent's resolver (see Who Can Write )\nRecord writes succeed but reads return old values The write went to a resolver the name no longer points at; look up the resolver again instead of caching it\nResolution works in scripts but fails in the app The app's environment blocks the HTTP requests CCIP-Read needs; see CCIP Read\nNext Steps\n- Track library support and test names on the ENSv2 readiness page\n- Understand the resolution machinery in Universal Resolver V2\n- Go deeper on record permissions and delegation in Permissioned Resolver\n- Building a subname product on top of your integration? Continue with the contract developers guide"}
{"url":"https://docs.sei.io/node/validators","domain":"docs.sei.io","title":"Sei Validator Operations Guide - Sei Docs","hash":"520ad2166081310f1b9bab63bdc22f582009b7e35509cf68893a44ed6275ff90","tokens":2268,"chars":9069,"crawler":"crawler-f6nn","verified":"exact","ts":1791172062900,"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 Validator Operations Guide\nLearn how to set up and maintain a validator node on Sei Network, including hardware security configuration, key management, monitoring practices, and governance participation requirements.\nThis document covers the complete lifecycle of a validator node, from initial setup through ongoing operations and maintenance. To run a reliable and secure validator, you need to understand these concepts.\nUnderstanding validator responsibilities\nA validator on the Sei network has several critical functions. As a validator, you are responsible for:\n- Participating in consensus by proposing and validating blocks\n- Maintaining high uptime and performance to avoid slashing\n- Managing delegator relationships and maintaining transparent operations\n- Participating in governance and network upgrades\nInitial setup\nInitialize node\nBefore key management and registration, initialize your node in validator mode. In this mode, RPC and P2P bind to localhost, which is recommended for validator security:\nseid init < monike r > --chain-id < chain-i d > --mode validator\nThe default init mode is full , which binds RPC and P2P to all interfaces ( 0.0.0.0 ). For validator (and seed) nodes, use --mode validator or --mode seed . RPC and P2P then listen on localhost only. Genesis is written automatically for known networks. You do not need to download it separately.\n--chain-id is required. Pass a value such as pacific-1 or atlantic-2 . For recognized public networks ( pacific-1 , atlantic-2 ), seid init automatically writes the Sei Labs seed nodes into the bootstrap-peers field of config.toml . As a result, a newly initialized node bootstraps peer discovery with no other configuration. Devnets ( arctic-1 ) and unknown or private chains receive no seeds. An existing bootstrap-peers value is never overwritten.\nKey management\nValidator security starts with correct key management. Your validator needs several separate keys:\n# Validator consensus key - Used for signing blocks\nseid tendermint show-validator\n# Operator key - Used for managing validator operations\nseid keys add operator\nThese keys have different purposes, and you should manage them with appropriate security measures. The consensus key is stored in priv_validator_key.json . It is particularly critical because the validator uses it to sign blocks. A compromised or mishandled consensus key could result in slashing.\nHardware security module (HSM) integration\nFor production validators, an HSM is strongly recommended to protect your consensus key. To configure an HSM for your validator, use these steps:\nHSM configuration steps\n# Install required libraries\nsudo apt-get install opensc pkcs11-utils\n# Configure YubiHSM2\nyubihsm-connector -d\n# Generate key in HSM\nyubihsm-shell\n# Configure seid to use HSM\ntee \" $HOME /.sei/config/priv_validator_config.json\" << EOF\n{\n\"chain_id\": \"pacific-1\",\n\"key_type\": \"yubihsm\",\n\"state_file\": \" $HOME /.sei/data/priv_validator_state.json\",\n\"hsm_serial\": \"YOUR_HSM_SERIAL\",\n\"hsm_key_id\": \"YOUR_KEY_ID\"\n}\nEOF\nValidator registration\nBefore you register your validator, make sure that your node is fully synced with the network. Validator creation is a crucial step that needs careful thought about the commission parameters.\nThe examples below use pacific-1 (Sei Mainnet). For Sei Testnet, use atlantic-2 .\nseid tx staking create-validator \\\n--amount=1000000usei \\\n--pubkey=$( seid tendermint show-validator ) \\\n--moniker= \"choose_moniker\" \\\n--chain-id=pacific-1 \\\n--commission-rate= \"0.10\" \\\n--commission-max-rate= \"0.20\" \\\n--commission-max-change-rate= \"0.01\" \\\n--min-self-delegation= \"1\" \\\n--gas= \"auto\" \\\n--gas-adjustment= \"1.5\" \\\n--gas-prices= \"0.02usei\" \\\n--from=operator\nPlan the commission parameters carefully:\n- commission-rate : Your initial commission rate. It should be competitive and still keep your operation sustainable.\n- commission-max-rate : An upper limit that can never be exceeded. It sets a permanent cap on your commission.\n- commission-max-change-rate : The maximum daily commission change. It limits how quickly you can adjust rates.\nMonitoring and alerting\nFor details about monitoring and alerting for your validator, price feeder, and other nodes, see the Advanced Operations section.\nSecurity practices\nNetwork security\nValidators may use a sentry node architecture to protect the block-signing node (the validator). This setup adds a layer of defensive proxies, which helps prevent DDoS attacks on your validator node:\n# Validator node config.toml\n[p2p]\npex = false\npersistent-peers = \"sentry_node_id@sentry_node_ip:26656\"\nprivate-peer-ids = \"\"\n# Sentry node config.toml\n[p2p]\npex = true\npersistent-peers = \"validator_node_id@ip:port\"\nprivate-peer-ids = \"validator_node_id\"\n#optional\nunconditional-peer-ids = \"validator_node_id\"\nKey management practices\nSet up secure procedures to back up your keys. Choose the storage media carefully. Mechanical or flash-based storage can fail unexpectedly. Never use cloud storage.\nThe consensus (signer) key is stored in $HOME/.sei/config/priv_validator_key.json . With the file keyring backend, the wallet key files ( .info and .address ) are stored in $HOME/.sei/keyring-file . Back up both locations.\nThis example script encrypts backups of the key files:\nKey backup script\n#!/bin/bash\n# Create encrypted backup of validator keys\nBACKUP_DIR = \"/secure/validator/backup\"\nDATE =$( date +%Y%m%d )\n# Backup validator key\ntar czf - $HOME /.sei/config/priv_validator_key.json | \\\ngpg --symmetric --cipher-algo AES256 \\\n-o $BACKUP_DIR /validator_key_ $DATE .tar.gz.gpg\n# Backup keyring\ntar czf - $HOME /.sei/keyring-file | \\\ngpg --symmetric --cipher-algo AES256 \\\n-o $BACKUP_DIR /keyring_ $DATE .tar.gz.gpg\n# Create SHA256 checksums\nsha256sum $BACKUP_DIR / * .gpg > $BACKUP_DIR /checksums_ $DATE .txt\nMaintenance procedures\nPlanned maintenance\nTo minimize the potential impact of planned maintenance:\n- Notify delegators, preferably at least 24 hours in advance\nConsider posting to:\n- Shared communication channels for the development team and validators\n- Social media channels\n- Validator website\nMake sure that you stop the service:\n# Gracefully stop the node\nsudo systemctl stop seid\n# Perform maintenance tasks\n# Restart services\nsudo systemctl start seid\nEmergency procedures\nCreate and maintain an emergency response plan for different scenarios:\nConsult with your fellow validators or a member of the Sei Labs or Foundation team directly for advice\nGovernance participation\nAs a validator, you must participate actively in governance. Governance is the primary tool to adjust various chain parameters.\nAnother critical role for validators is to review proposed software upgrades to the network, and finally approve or reject them.\nAnyone who pays the mandatory (refundable) deposit may submit a governance proposal. Any network user can vote on a proposal. Only votes from accounts that delegate $SEI at the end of a proposal’s voting period are given weight.\nYou can query the proposals that are currently on chain at any time:\n# List active proposals\nseid query gov proposals --status voting_period\n# Vote on a proposal\nseid tx gov vote 1 yes \\\n--from operator \\\n--chain-id pacific-1 \\\n--gas auto \\\n--gas-prices 0.02usei\nRecovery procedures\nCritical warning: Double-signing prevention\nDouble-signing is a severe violation that results in permanent validator tombstoning (irreversible jailing).\nNever run your validator keys on more than one machine at the same time. If your primary validator goes offline:\n- DO NOT start another validator with the same keys\n- Either recover the original machine, or migrate the keys properly. Migrate them only when you are absolutely certain that the original is offline\n- If you are unsure about the state of your original validator, get support before you continue\nThe safe approach to recovery is:\n- Diagnose why the original validator is offline\n- If the original validator cannot be recovered, verify that it is offline and powered down\n- Only then migrate the keys to a new machine\nValidator recovery\nTo recover your validator on a new machine, follow these steps carefully:\n# 1. Set up new machine with Sei node\n# 2. Copy secured backup files\n# 3. Restore validator key\ngpg -d validator_key_backup.tar.gz.gpg | tar xzf -\n# 4. Restore keyring\ngpg -d keyring_backup.tar.gz.gpg | tar xzf -\n# 5. Start services\nsudo systemctl start seid\nAfter recovery, verify your validator’s status and performance:\n# Check validator status\nseid status\n# Verify signing is working\nseid query slashing signing-info $( seid tendermint show-validator )\nValidator operation requires constant attention to security, performance, and network participation. Stay engaged with the Sei community, and keep up to date with network developments.\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://bitcoin.org/ro/cum-functioneaza","domain":"bitcoin.org","title":"Cum funcționează Bitcoin? - Bitcoin","hash":"af56e8ad08f9d441f06b5bff1caea424979cdc130c465d9c49abb19859f009e8","tokens":1191,"chars":4761,"crawler":"crawler-f6nn","verified":"exact","ts":1791172065093,"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- Introducere\n- Persoane fizice\n- Companii\n- Dezvoltatori\n- Noțiuni de bază\n- Cum funcționează\n- Trebuie să știi\n- Resurse\n- Exchanges\n- Comunitate\n- BIPs list\n- Vocabular\n- Bitcoin Core\n- Inovaţie\n- Participă\n- Susţine Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Dezvoltare\n- Întrebări Frecvente\n- Română\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: ro\nCum funcționează Bitcoin?\nAceasta este o întrebare ce de multe ori creează confuzie. Uite o explicaţie rapidă!\nElemente de bază pentru un utilizator nou\nCa utilizator nou, poți începe să folosești Bitcoin fără să înţelegi detaliile tehnice. Odată instalat un portofel Bitcoin pe calculator sau telefonul mobil, îţi va genera prima adresă Bitcoin și poți crea una de fiecare dată când ai nevoie. Această adresă poate fi arătată prietenilor pentru a te putea plăti sau viceversa. De fapt, este destul de similar cu modul în care funcționează emailul, cu excepția că adresele Bitcoin ar trebui folosite doar o dată.\nSolduri - lanţul de blocuri\nLanţul de blocuri este un registru public comun pe care se bazează întreaga reţea Bitcoin. Toate tranzacţiile confirmate sunt incluse în lanţul de blocuri. În acest fel, portofelele Bitcoin pot calcula soldurile ce pot fi cheltuite şi tranzacţiile noi pot fi verificate că implică bitcoini ce într-adevăr sunt deţinuţi de plătitor. Integritatea şi ordinea cronologică a lanţului de blocuri sunt împuternicite de criptografie .\nTranzacții - chei private\nO tranzacţie reprezintă un transfer de valoare între portofele Bitcoin ce este inclus în lanţul de blocuri. Portofelele Bitcoin păstrează o parte secretă de date numită cheie privată sau sămânţă, ce este folosită pentru a semna tranzacţii, oferind o dovadă matematică că provine de la deţinătorul portofelului. Semnătura de asemenea previne alterarea tranzacţiei de către altcineva după ce a fost emisă. Toate tranzacţiile sunt emise între utilizatori şi de obicei încep să fie confirmate de către reţea în următoarele 10 minute, printr-un proces numit minat .\nProcesare - minerit\nMinatul este un sistem consensual distribuit folosit pentru a confirma tranzacţiile în aşteptare prin includerea lor în lanţul de blocuri. Minatul impune o ordine cronologică în lanţul de blocuri, protejează neutralitatea reţelei şi de asemenea permite diferitelor calculatoare din reţea să cadă de acord asupra condiţiei sistemului. Pentru a fi confirmate, tranzacţiile trebuie să fie incluse într-un bloc ce respectă reguli criptografice foarte stricte ce va fi verificat de reţeaua Bitcoin. Aceste reguli previn blocurile anterioare să fie modificate pentru că astfel s-ar invalida toate blocurile următoare. Minatul de asemenea este echivalentul unei loterii competitive ce previne un caz în care un individ poate să adauge cu uşurinţă blocuri noi în mod consecutiv în lanţul de blocuri. În acest fel, niciun individ nu poate controla ce este inclus în lanţul de blocuri sau să înlocuiască părţi din lanţul de blocuri pentru a retrage tranzacţiile proprii.\nMai adânc în viziuna iupurelui\nAcesta este doar un sumar foarte scurt şi concis al sistemului. Dacă doreşti să intri în detalii, poţi citi lucrarea originală ce descrie designul sistemului, să citeşti documentaţia pentru dezvoltatori şi să explorezi Bitcoin Wiki .\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroducere:\n-\nPersoane fizice\n-\nCompanii\n-\nDezvoltatori\n-\nNoțiuni de bază\n-\nCum funcționează\n-\nTrebuie să știi\nResurse:\n-\nResurse\n-\nExchanges\n-\nComunitate\n-\nBIPs list\n-\nVocabular\n-\nBitcoin Core\nParticipă:\n-\nSusţine Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nDezvoltare\nOther:\nLegal\nPrivacy Policy\nPresă\nDespre bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Lansat sub licența MIT\nNetwork Status\n- Română\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- 繁體中文\nro"}
{"url":"https://bitcoinops.org/en/newsletters/2026/08/07/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #417 | Bitcoin Optech","hash":"cd575be3a45d21919524d0a1bfa3b08fc40e58d9bcc34553d2a88a8af70da2db","tokens":4406,"chars":17622,"crawler":"crawler-f6nn","verified":"exact","ts":1791172069569,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #417\nAug 7, 2026\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.\nNews\n-\n● Draft BIP for stale tip relay : Ram and w0xlt posted\nto the Bitcoin-Dev mailing list about the proposal for an opt-in P2P\nmessage for relaying stale tips between peers. Currently, the stale block rate\nis a difficult metric to monitor, since stale blocks stop propagating\nas soon as the winning chain is relayed. However, it is a useful signal\nto check the network health. Changes in the stale block rate may expose validation\nor relay bottlenecks, network partitions, or selfish mining behavior.\nThe proposed BIP defines a new message, called\nstaletip , for announcing recent stale chain tips to peers. The message\nitself contains the block height at which a stale branch diverges (the\nfork point), a vector containing the block headers belonging to the stale\nbranch, and a flag signaling willingness to serve that block data. A node\nshould only send the message after BIP434 negotiation with its peers\n(see Newsletter #386 ).\nThe authors are waiting for feedback from other developers.\nIn the meantime, a proof of concept for the proposal\nis already available.\nChanging consensus\nA monthly section summarizing proposals and discussion about changing\nBitcoin’s consensus rules.\n-\n● CISA for taproot keypath spends (BIP460) : Fabian Jahr\nposted to the Bitcoin-Dev mailing list a draft of BIP460\n( BIPs #2212 ) for transaction-wide cross-input signature aggregation\n(CISA) of taproot -style keypath spends. The\nproposal introduces a new witness version (v2) whose keypath spends mirror\nBIP341 except that each input’s witness begins with a marker byte\nselecting half-aggregation (BIP458/ BIPs #2205 ), full-aggregation\n(BIP459/ BIPs #2210 ), or an explicit opt-out that carries a standard\nBIP340 schnorr signature. Half-aggregation\nnon-interactively compresses many 64-byte signatures to 32 bytes each plus a\nsingle 32-byte aggregate part (see Newsletter #208 );\nfull-aggregation reduces them to a single 64-byte aggregate signature with\ninteractive signing (see Newsletter #415 ). Scriptpath\nspends follow BIP341/BIP342 unchanged and are not aggregated, preserving\nthe OP_SUCCESS upgrade path. Signatures\nin the proposed scheme commit to the aggregation mode so aggregation is\nopt-in: third parties cannot fold an opted-out signature into a\nhalf-aggregation group. Jahr notes the witness version collides with\nBIP360 (P2MR); reviewers (including Mark Erhardt) expect whichever\nproposal activates first to take the next free version.\nConduition asked how CISA dovetails with post-quantum migration: aggregation needs bare EC public keys for\nverification, so pairing CISA with P2TRv2 maximizes fee\nsavings (as little as 1 witness byte per full-aggregated input) but inherits\nP2TRv2’s EC-disabling timing problem, whereas hashing the key (P2MR or\nP2TRH) costs roughly 32-65 weight units per input and weakens the savings.\nJahr replied that the transaction-level marker/group\nframework should generalize to future aggregatable schemes and that a\nhash-hidden CISA variant could be specified as a separate output type\nsharing most of the logic. Adam Gibson (waxwing) questioned\nthe single-group-per-scheme limit when several users each want\nfull-aggregation of only their own inputs inside a shared transaction. Jahr\nreplied that multiple groups remain open if reviewers\nsee concrete use cases.\n-\n● Segwit commitment to post-quantum witness data : Pieter Wuille\nposted to Delving Bitcoin a design for attaching\npost-quantum witness data without repeating all\nof segwit ’s deployment costs. A naive second witness area\nwould need a new transaction identifier (pqwtxid), a coinbase commitment to\nthose IDs, mining stack changes, and P2P logic tracking three identifiers.\nWuille’s alternative commits to each input’s extended witness data from\nthe input’s current witness, so wtxid covers the additional data. A\nworked-out version introduces per-input witness “styles” (0 = segwit, 1 =\npqdata, 2+ for future extensions), each with its own P2P extension and\nweight function. Unsupported styles can be represented by a valid style-0\ncommitment for compatibility with unupgraded nodes. Anthony Towns compared\nstyles to distinct authorization weight formulas, suggested annex-based\ncommitments so locktime-like assertions remain available without the\nadditional data, and argued that capacity reserved for post-quantum\nsignatures should stay unusable for ordinary data so pre-Q-day blocks do not\nbloat toward a larger target. Wuille agreed that introducing a style is\nstill a combined soft fork, storage, and P2P upgrade, but without a\nnew transaction ID.\n-\n● PQC output type discussion : Pieter Wuille opened a\nDelving Bitcoin thread to centralize discussion of post-quantum output types. He tabulated candidates including\nBIP360 (P2MR), P2TRv2 , P2TRH (taproot-like with a hashed\noutput key and public-key recovery, see Newsletter #412 ), and\nP2QR (P2MR with EC opcodes disabled from the start), and variations of\nthose. His current preference is to deploy both P2TRv2 (with tripwire/miner\nlockdown and a hash-based PQC opcode ) for\neasy pre-Q-day migration that keeps today’s fee profile, and a longer-term\nP2MR-based type with a new witness style so EC and PQC costs can be priced\nindependently after migration. Regtest measurements by jeanpablojp\nshowed BIP360 spends requiring ~96 lines of consensus\ndelta over existing taproot machinery, with a depth-1 schnorr leaf about\n32 bytes lighter than the equivalent P2TR scriptpath. Conduition noted that Jahr’s CISA\nproposal (above) makes P2TRv2+CISA extremely attractive for voluntary\nmigration, but raises the stakes of a later EC-disabling soft fork, and\npointed to block-wide PQ-SNARK aggregation of hash-based signatures as a\nresearch path that could make post-quantum spends competitive on fees.\n-\n● Input-triggered transaction expiry : Josh Doman posted to Delving Bitcoin a construction for expiring HTLCs without free relay , then generalized it in a\nfollow-up on input-triggered transaction expiry .\nAbsolute expiry proposals such as Peter Todd’s OP_EXPIRE\nmake a valid transaction later invalid, enabling cheap relay spam unless\npolicy demands near-next-block fees. Doman’s approach instead expires a\nspend when the transaction creating the UTXO it’s spending was\nconfirmed too late: if BIP68 nSequence enforces a height-based relative\nlocktime R and bit 21 is set, the input fails validation unless nLockTime\nis height-based and at least the BIP68 minimum inclusion height. Because a\nmined parent cannot become invalid without a deep reorg, a once-valid child\ncannot expire under ordinary progress, eliminating free relay. Use cases\ninclude mempool-free HTLC forwarding (preimage monitoring via the chainstate\nrather than the local mempool, useful for low-bandwidth or\nUtreexo-style nodes) and pseudo contract-level relative\ntimelocks for LN-Symmetry . Optional companion changes enforce\nbit 21 in OP_CSV and add a tapscript OP_LOCKTIME introspection opcode so\nscripts can require a maximum locktime. Anthony Towns compared the idea to\ncoin-height introspection via OP_TX and questioned whether the 100-block\nminimum delay (chosen to match coinbase maturity and Todd’s proposal) is\nnecessary; Doman later agreed that a much smaller delay may suffice and reframed\nthe primitive as users asserting “now” (input confirmations by nLockTime )\nin a way that can also raise the cost of deep reorgs post-subsidy.\n-\n● Layered quantum recovery of hashed addresses : Shinobi posted to the Bitcoin-Dev mailing list and cross-posted to Delving Bitcoin a layered recovery plan for coins secured by hashed\naddress types (P2PKH, P2SH, P2WPKH, P2WSH, and analogous constructions) if\nsecp256k1 spending is later restricted due to the existence of a\ncryptographically relevant quantum computer . No\nsingle recovery mechanism covers every key-generation method: BIP32\nhierarchical proofs (recently demonstrated by\nOsuntokun) miss non-hierarchical keys; stateful pre-deadline timestamped\nattestations miss inactive users; and commit-reveal migration fails when\npublic keys are already exposed. Allowing any recovery method to authorize a\nspend after secp256k1 is disabled would, under the assumption that public\nkeys and internal scriptpaths stay secret, cover essentially all\nhashed-address holders who still control their keys. To facilitate this in\nthe future, Shinobi suggests wallets use new derivation paths and\nElectrum-style per-address balance queries to avoid leaking xpubs to service\nproviders. Conduition reframed recovery as authenticating existing knowledge\nasymmetries that a quantum attacker lacks: hashed scripts and BIP32\nseeds are such asymmetries. He stressed that some UTXOs (notably many\nearly P2PK coins) have no such asymmetry, so only pre-deadline action to\ncreate one can distinguish their owners from an attacker. He also noted\nthat taproot internal keys can serve as a knowledge asymmetry for P2TR\nkeypath recovery, separate from the hashed-address layering.\n-\n● Segregated Data (SegData) BIP draft : MrHash posted\nto Delving Bitcoin companion BIP drafts for Segregated Data, a soft fork\nthat would add a prunable, script-isolated block region for arbitrary data\ncarriage. Entries would be committed via a coinbase merkle root ( BIP141 -\nstyle), counted at the witness discount, and bound to transactions by\nunspendable value-zero witness v2 reference outputs excluded from the UTXO\nset. No opcode may read entry contents, keeping entries prunable and unable\nto gate spends, and beyond a retention window nodes could validate from the\nbase serialization alone. The goal is to give data that scripts need not\nevaluate (application blobs, attestations) a structural home so it can leave\nOP_RETURN and witness stuffing, without changing those existing vectors.\nAntoine Poinsot and Pieter Wuille argued that if full nodes need not retain\nthe payload to accept a block, the data is not part of Bitcoin consensus in\nany meaningful sense and is equivalent to paying fees to inflate weight.\nMark Erhardt questioned why embedders would prefer reduced availability at\nthe same cost as witness data. After Anthony Towns described reorg risks\nfrom depth-dependent presence rules, MrHash pivoted toward consensus\nchecking only committed weight/length with payload validation as policy. The\ndraft remains open; witness version allocation also collides with BIP360 and\nBIP460 discussions above.\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- ● Libsecp256k1 0.8.0 is a release of this library for Bitcoin-related\ncryptographic operations. It adds the BIP352 silent payments module described in Newsletter #415 ,\nallows applications to provide hardware-optimized SHA256 compression\nimplementations as described in Newsletter #396 , and\nimproves 64-bit field arithmetic, producing signature verification speedups\nof up to approximately 11% in some GCC and MSVC builds. It also removes the\ndeprecated secp256k1_schnorrsig_sign and\nsecp256k1_context_no_precomp symbols.\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 #35501 updates the wallet to store multiple witness variants\nof the same transaction. Previously, once the wallet knew a transaction with\na given txid, it would generally ignore another transaction with the same\ntxid but a different wtxid. Now, the wallet stores each variant in a separate\nwtxvariant database record and selects one as canonical. Preference is\ngiven to a confirmed variant, otherwise to a variant containing witness data\nand then to a variant with the lowest weight. The canonical variant remains\nin the existing tx record. The gettransaction , listtransactions , and\nlistsinceblock RPCs now report noncanonical variants in a new\nalternate_wtxids field. See Newsletters #193 and\n#304 for previous references to transactions having the\nsame txid but different wtxids.\n-\n● Core Lightning #9298 advances the migration to bwatch , an experimental\nblockchain-watching plugin intended to move block polling and transaction\nfiltering out of lightningd . This PR moves wallet transaction and UTXO\ntracking to that system by adding our_outputs and our_txs tables,\nbackfilling them from the existing wallet tables, and switching wallet reads\nto the new tables. With --experimental-bwatch enabled, the scriptPubKey\nwatches detect when funds are received and the outpoint watches detect when\nwallet outputs are spent, including handling reorgs. Writes are temporarily\nmirrored to the legacy outputs and transactions tables to enable users to\ndowngrade without needing to rescan.\n-\n● Core Lightning #9353 makes sendpay return an RPC error when the combined\nper-hop payload for a supplied route cannot fit in the 1,300-byte\nhop_payloads field of an onion packet defined by BOLT4 . Previously,\nonion construction returned a null result that sendpay passed unchecked to\nthe sending code, causing lightningd to crash. This issue was observed with\na 25-hop route generated by a rebalancing plugin. However, the actual route\nlimit depends on the size of the encoded payloads for each hop rather than\nsolely on the number of hops.\n-\n● Eclair #3336 prevents duplicate HTLC settlement messages\nreceived from a peer from being added multiple times to the proposed remote\ncommitment changes. Previously, a peer or local message queue could deliver\nthe same update_fulfill_htlc , update_fail_htlc , or\nupdate_fail_malformed_htlc message more than once, causing Eclair to store\nduplicate commitment changes and potentially force close the channel when\nthe peers later exchanged commit_sig messages.\n-\n● LND #10942 adds support for forwarding an HTLC on a\nblinded payment path when the encrypted recipient data\nidentifies the next hop using next_node_id rather than short_channel_id\n(SCID). This issue was observed in a Core Lightning BOLT12\npayment, where LND was the introduction node in the receiver’s blinded path.\nCLN used the BOLT4 -permitted next_node_id form, but LND’s HTLC\nforwarding code required an SCID, resulting in the payment failing. LND now\nresolves the node id to one of its usable channels with that peer using its\nexisting non-strict forwarding logic, which also supports private and alias\nchannels.\n-\n● LND #10992 bounds the memory used when synchronizing channel\nannouncements by limiting the number of short\nchannel IDs (SCIDs) accepted in the BOLT7 reply_channel_range response\nto a query_channel_range request. Previously, compressed responses could\ncause LND to decode and buffer an unpredictable number of SCIDs across one\nor more reply_channel_range messages. Now, LND accepts a maximum of 100,000\nSCIDs per message and 100,000 SCIDs in aggregate for a single query.\n-\n● Rust Bitcoin #6364 adds P2P encoding and decoding support for BIP434\nfeature messages (see Newsletters #386 and\n#390 ), following Bitcoin Core’s earlier implementation\n(see Newsletter #410 ). It adds protocol version 70017 ,\nthe feature NetworkMessage variant, while enforcing BIP434’s size limits\non feature identifiers and data. This update provides the message\ninfrastructure, but does not implement the peer feature negotiation logic.\n-\n● Rust Bitcoin #6642 applies a 4 MB size limit to each transaction witness\nelement. This limit is derived from BIP141 ’s four-million-weight-unit\nblock limit, as a witness element larger than this size would not fit in a\nvalid block. Previously, when decoding a transaction, Rust Bitcoin only\napplied the limit to the first witness element, resetting to a larger default\nlimit of 32 MiB for subsequent elements. This could allow an oversized element\nto be accepted during decoding, leaving the witness in an inconsistent state\nthat could cause a panic when later interpreted as a taproot\nspend. This follows earlier witness-decoding memory-allocation hardening\ndescribed in Newsletter #410 .\n-\n● BTCPay Server #7491 fixes a two-factor authentication (2FA) bypass in the\nGreenfield API authentication handler. While the authentication handler\nchecked for FIDO2 2FA (see Newsletter #146 ), it did not\ncheck for time-based one-time password (TOTP) 2FA. This allowed TOTP-protected\naccounts to access the API without providing their 2FA. The handler now\nrejects this form of authentication whenever any second factor is enabled.\n-\n● BTCPay Server #7488 improves PSBT signing compatibility by\nadding witness_utxo to segwit inputs when the PSBT already\ncontains the corresponding previous transaction in non_witness_utxo . This\nresolves an issue with signing devices such as the Blockstream Jade when used\nwith newer HWI versions, while retaining the existing\nnon_witness_utxo . The PR also fixes an issue with pending multisig\ntransactions whose stored signing status became stale. BTCPay Server now\nrecalculates their signing progress when they are loaded and marks them as\nSigned when enough signatures are present and the PSBT can be finalized\nsuccessfully."}
{"url":"https://bitcoin.org/hu/amit-tudnia-erdemes","domain":"bitcoin.org","title":"Néhány dolog, amelyet érdemes tudnia - Bitcoin","hash":"36043c03d03b29073a0048e094a1ad4f5d650156d74e99427f9c276a6d5d668c","tokens":1764,"chars":7053,"crawler":"crawler-f6nn","verified":"exact","ts":1791172071824,"text":"A Bitcoin.org-nak szüksége van a támogatásodra!\nA Bitcoin.org egy közösség finanszírozta projekt, nagyra értékeljük az adományokat és segítségével fejleszteni tudjuk a honlapot.\nAdományozz a Bitcoin.org-nak\nHasználd a lenti QR kódot vagy címet\nSend with Bitcoin\nBitcoin only · On-chain\nOpen in wallet\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nPrefill an amount (optional)\nBTC amount\nUSD amount\nAdd an optional wallet note\nOpcionális leírás (a tárcádhoz)\n- Bevezetés\n- Magánszemélyek\n- Vállalkozások\n- Fejlesztők\n- Vágjon bele\n- Hogyan működik\n- Érdemes tudnia\n- Fehérkönyv\n- Információs anyagok\n- Tőzsdék\n- Közösség\n- BIPs list\n- Szótár\n- Bitcoin Core\n- Innováció\n- Vegyél részt\n- Támogasd a Bitcoint\n- Vásárolj bitcoint\n- Sell Bitcoin\n- Fejlesztés\n- GYIK\n- Magyar\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: hu\nNéhány dolog, amelyet érdemes tudnia\nAmennyiben most kezded felfedezni a Bitcoint, néhány dolgot érdemes tudnod. A Bitcoin segítségével a normálistól eltérő módon tudsz pénzt váltani és utalni. Ezért érdemes időt szánnod a tájékozódásra, mielőtt bármilyen komoly tranzakcióra használnád a Bitcoint. A Bitcoin a rendes tárcához hasonló bánásmódot igényel - bizonyos esetekben akár még nagyobb odafigyelést is!\nVédje meg pénztárcáját\nMint a valós életben, a tárcádat védeni kell. A Bitcoin lehetővé teszi az értéktranszfert bárhova egy nagyon egyszerű módon, és lehetővé teszi, hogy ellenőrzést gyakorolj a pénzed fölött. Ugyanakkor az ilyen nagyszerű funkciók óriási biztonsági kockázatokkal járnak. Ugyanazon időben a Bitcoin magas szintű védelmet biztosít, ha helyesen használják. Sose feledd, hogy a te felelősséged a jó gyakorlatok kialakítása a pénzed védelme érdekében. Tudj meg többet arról, hogyan tudod védeni a tárcádat .\nThere is no undo button\nBitcoin has no central authority to reverse a mistake. If you permanently lose access to your wallet—for example by losing your recovery phrase—your funds are gone permanently. No one—not developers, miners, wallet providers, or exchanges—can recover funds that you permanently lose from a self-custodied wallet. Always back up your wallet and keep your recovery information safe and private.\nYou are your own bank\nWhen you hold your own private keys, you control your bitcoin—but you are also responsible for keeping it secure. If you leave your coins with an exchange or another custodian, you rely on that third party to safeguard them and to honor withdrawals. That reliance introduces counterparty risk: the custodian's own security, solvency, and policies now stand between you and your funds. Holding your own keys removes that risk, but requires you to secure your wallet and backups yourself.\nA Bitcoin nem anonim\nNémi erőfeszítést igényel, hogy megvédd a személyes adataid a Bitcoinnal. Az összes Bitcoin tranzakció nyilvánosan és azonnal tárolódik a hálózaton, ami azt jelenti, hogy bárki láthatja bármely Bitcoin cím tranzakcióegyenlegét. Ugyanakkor a cím mögött lévő felhasználó személyazonossága rejtett marad mindaddig, amíg az információkra fény nem derül egy vásárlás vagy más körülmények folytán. Ez az oka annak, hogy a Bitcoin címeket célszerű csak egyszer használni. Soha ne feledd, hogy a te felelősséged, hogy jó gyakorlatok elsajátításával megvédd személyes adataid. Tudj meg többet a személyes adataid védelméről .\nA Bitcoin-kifizetések visszavonhatatlanok\nA bitcoin tranzakciók visszavonhatatlanok, mindössze arra van lehetőség, hogy a kifizetést fogadó fél visszatérítse a kifizetett összeget. Ez azt jelenti, hogy célszerű olyan emberekkel és vállalkozásokkal üzletelni, akikben és amikben megbízol vagy megalapozott, jó hírnevük van. A vállalkozások feladata a fogyasztók felé közvetített fizetési igények kontrollja. A Bitcoin képes az elütéseket jelezni, és általában nem engedi, hogy egy hiba folytán érvénytelen címre küldj pénzt, de fontos, hogy legyenek kontrollok a kiegészítő biztonság és redundancia miatt. A jövőbeni kiegészítő szolgáltatások lesznek olyan szolgáltatások, amelyek nagyobb választási szabadságot és védelmet fognak nyújtani mind a vállalkozások, mind a fogyasztók számára.\nA visszaigazolatlan tranzakciók nem biztonságosak\nA tranzakciók a kezdetben nem visszavonhatatlanok. Helyette kapnak egy konfirmációs értéket ami azt indukálja, hogy milyen nehéz visszavonni azokat (lásd a táblázatot). Minden egyes konfirmáció pár másodperc és 90 perc között változik, és ahol 10 perc az átlagos. Ha egy tranzakció túlságosan alacsony díjat fizet vagy másképp szokatlan, akkor az első konfirmáció sokkal tovább tarthat.\nA Bitcoin árfolyama volatilis\nA bitcoin árfolyama fiatal piac lévén, újdonságából fakadóan, illetve néha a likviditáshiánnyal küzdő piacok miatt kiszámíthatatlanul emelkedhet és eshet rövid időn belül. Ebből következően megtakarításai bitcoinban való tartása jelenleg nem javasolt. A bitcoin nagy kockázatú eszköznek tekinthető, ezért soha ne tartson olyan pénzt bitcoinban, amelynek elvesztését nem engedheti meg magának. Amennyiben kifizetéseket kap kézhez Bitcoin segítségével, számos szolgáltató képes helyi pénznemre váltani a bitcoinokat.\nA Bitcoin továbbra is a fejlesztés fázisában van\nA bitcoin egy új, kísérleti pénznem, amely aktív fejlesztés alatt áll. Minden fejlesztés egyre vonzóbbá teszi, de közben új kihívásokat is tartogat a Bitcoin elfogadottság növekedésével. Ezen növekvő időszakok alatt magasabb díjakat, lassabb visszaigazolást vagy még komolyabb problémákat tapasztalhatsz. Készülj fel a problémákra és tárgyalj egy technikai szakértővel mielőtt komolyabb befektetést eszközölnél, de ne felejtsd, senki sem tudja a Bitcoin jövőjét megjósolni.\nKormányzati adók és szabályozások\nA bitcoin nem hivatalos pénznem. Mindemellett a legtöbb törvényalkotó elvárja, hogy személyi, forgalmi, jövedelem és nyereségadót fizess. A te felelősséged, hogy pontosan betartsd a kormányod és/vagy helyi önkormányzatod által kibocsátott adó- és egyéb jogi rendelkezéseket .\nTámogasd a Bitcoin.org-ot:\nAdományozás\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nBevezetés:\n-\nMagánszemélyek\n-\nVállalkozások\n-\nFejlesztők\n-\nVágjon bele\n-\nHogyan működik\n-\nÉrdemes tudnia\n-\nFehérkönyv\nInformációs anyagok:\n-\nInformációs anyagok\n-\nTőzsdék\n-\nKözösség\n-\nBIPs list\n-\nSzótár\n-\nBitcoin Core\nVegyél részt:\n-\nTámogasd a Bitcoint\n-\nVásárolj bitcoint\n-\nSell Bitcoin\n-\nFejlesztés\nEgyéb:\nJogi vonatkozások\nPrivacy Policy\nSajtó\nA bitcoin.org-ról\nBlog\n© Bitcoin Project 2009-2026 Az MIT licence alatt közzétéve\nHálózat státusza\n- Magyar\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- 繁體中文\nhu"}
{"url":"https://docs.getmonero.org/technical-specs/","domain":"docs.getmonero.org","title":"Monero Technical Specification - Monero Docs","hash":"0874cbd24eaf78269148c1cca4a1a220bec57eef728781db5447f8485384e850","tokens":842,"chars":3368,"crawler":"crawler-f6nn","verified":"exact","ts":1791172076297,"text":"Skip to content\nInitializing search\nmonero-project/monero-docs\n- Max supply\n- Divisibility\n- Sender privacy\n- Recipient privacy\n- Amount privacy\n- IP address privacy\n- Networks\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\n- Max supply\n- Divisibility\n- Sender privacy\n- Recipient privacy\n- Amount privacy\n- IP address privacy\nMonero Technical Specs ¶\nLive ¶\n- Monero blockchain is live since 18 April 2014\nNo premine, no instamine, no ICO, no token ¶\n- Monero had no premine or instamine\n- Monero did not sell any token\n- Monero had no presale of any kind\nProof of Work ¶\n- CryptoNight\n- v0 since block height 0\n- v1 since block height 1546000 (forked on 2018-04-06)\n- v2 since block height 1685555 (forked on 2018-10-18)\n- v3 since block height 1788000 (forked on 2019-03-09); \"CryptonightR\"\n- RandomX\n- v0 since block height 1978433 (forked on 2019-11-30)\nDifficulty retarget ¶\n- every block\n- based on the last 720 blocks (24h), excluding 20% of the timestamp outliers\nBlock time ¶\n- 2 minutes (was 1 minute before hardfork v1)\n- may change in the future as long as emission curve is preserved\nBlock reward ¶\n- smoothly decreasing and subject to penalties for blocks greater than median size of the last 100 blocks (M100)\n- 0.6 XMR as of June 2023; for the current reward check the coinbase transaction of the latest block\nBlock size ¶\n- dynamic\n- maximum of two times the median size of the last 100 blocks (2 * M100)\n- ~90KB as of June 2026; check the latest block size\nCurrent blockchain size ¶\n- Pruned node: ~100 GiB as of 2026-01-20\n- Full node: ~250 GiB as of 2026-01-20\nEmission curve ¶\nMain emission ¶\n- first, the main emission is about to produce ~18.132 million coins by the end of May 2022\n- as of June 2023 the emission is about 3 XMR per 10 minutes\n- see charts and details\nTail emission ¶\n- the tail emission kicked in after main emission is done\n- it will produce 0.6 XMR per 2-minute block\n- this translates to <1% inflation decreasing over time\nMax supply ¶\n- ~18.293 million XMR + 0.6 XMR per 2 minutes\n- technically infinite but practically deflationary if accounted for lost coins\nDivisibility ¶\n- Monero is divisible up to 12 digits\n- The smallest unit is called piconero and equals 1e-12 XMR, or 0.000000000001 XMR\nSender privacy ¶\n- ring signatures\n- the ring size is 16 (15 decoys)\n- assurance: probabilistic / plausible deniability\nRecipient privacy ¶\n- stealth addresses\n- assurance: strong\nAmount privacy ¶\n- ring confidential transactions\n- assurance: strong\nIP address privacy ¶\nFor the full node ( monerod ):\n- Dandelion++ makes transaction propagation less traceable over public networks\n- Assurance: won't protect against ISP/VPN provider, won't protect against the very first remote node in Dandelion++ protocol\n- For full protection, the user must manually wrap monerod with Tor\nFor the wallet ( monero-wallet-gui or monero-wallet-cli ):\n- Typically, the wallet runs on the same machine as a full node so there is no risk\n- If the wallet is using a remote node, there is no IP protection by default\n- The user must manually the wrap the wallet with Tor or I2P"}
{"url":"https://docs.monad.xyz/tooling-and-infra/oracles","domain":"docs.monad.xyz","title":"Oracles - Monad Documentation","hash":"f4f9f265a4a9a4f0c920f3ddaa01568b0fbbb338e9d9ee7c06b7cf89548f0efe","tokens":1698,"chars":6791,"crawler":"crawler-f6nn","verified":"exact","ts":1791172079128,"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\nOracles\nOracles make off-chain data accessible on chain.\nDefinitions\nTerm Description\nPush oracle Provider regularly pushes price data to the oracle contract on chain\nPull (on-demand) oracle User triggers price data update while calling a smart contract\nCustom oracle A custom calculator\nVRF (Verifiable Random Function) Provides random numbers on chain\nProvider Summary\n-\nMainnet\n-\nTestnet\nProvider Docs Contract addresses Live data Support notes\nChainlink Docs See contract addresses Live data\n- Push oracle ( Price Feeds )\n- Pull oracle ( Data Streams )\nChronicle Docs See contract addresses Push oracle; custom oracles\nPyth Docs See contract addresses Live data Pull oracle ;\nVRF\nRedstone Docs See contract addresses Live data Push oracle ;\npull oracle\nStork Docs\n- See contract addresses\n- Addresses ; APIs ; Asset ID Registry\nLive Data Push oracle ;\nPull oracle\nSupra Docs See contract addresses Live data Push oracle ;\nPull oracle ;\ndVRF\nProvider Docs Contract addresses Live data Support notes\nChainlink Docs Price Feeds [push oracle]:\n- general reference\nLive data\n- Push oracle ( Price Feeds )\n- Pull oracle ( Data Streams )\nChronicle Docs Address reference Dashboard Push oracle; custom oracles\nGelato VRF Examples VRF\nPyth Docs\n- Price feeds (incl MON/USD): 0x2880aB155794e7179c9eE2e38200202908C17B43\n- Entropy: 0x36825bf3Fbdf5a29E2d5148bfe7Dcf7B5639e320\nLive data Pull oracle ;\nVRF\nRedstone Docs\n- Push oracle addresses\n- Update conditions for all: 0.5% deviation & 6h heartbeat\nLive data Push oracle ;\npull oracle\nStork Docs\n- Pull oracle (includes MON/USD): 0xacC0a0cF13571d30B4b8637996F5D6D774d4fd62\n- Addresses ; APIs ; Asset ID Registry\nLive Data Pull oracle\nSupra Docs\n- Storage: 0xf0e852BC3F940447862D6b67e5B9807E64B433F6\n- Pull: 0xF8522B7fcE37439b98A2be282d413A44269028bE\n- Router: 0x5CbC3Dfa33223884E7752a833Fa6aD28Ee015FC4\n- Deposit: 0x95bfe6e94D5ff9e9d087647bc589acC9E3D31619\nLive data Push oracle ;\nPull oracle ;\ndVRF\nProvider Details\nChainlink\nChainlink Data Streams\nChainlink Data Streams deliver low-latency market data offchain, which can be verified onchain. This approach provides decentralized applications (dApps) with on-demand access to high-frequency market data backed by decentralized, fault-tolerant, and transparent infrastructure.\nTraditional push-based oracles update onchain data at set intervals or when certain price thresholds are met. In contrast, Chainlink Data Streams uses a pull-based design that preserves trust-minimization with onchain verification.\nTo get started, check out the documentation .\nChainlink Price Feeds\nChainlink Price Feeds are the quickest way to connect your smart contracts to real-world data such as asset prices.\nData Feeds aggregate many data sources and publish them onchain using a combination of the Decentralized Data Model and Offchain Reporting .\nTo get started, check out the documentation .\nChronicle\nChronicle’s decentralized oracle network was originally built within MakerDAO for the development of DAI and is now available to builders on Monad.\n- Data Feeds : Builders can choose from 90+ data feeds, including crypto assets, yield rates, and RWAs. Chronicle’s data is sourced via custom-built data models, only utilizing Tier 1 sources.\n- Transparency & Integrity : Chronicle’s oracle network is fully transparent and verifiable via the Chronicle dashboard . Users can cryptographically challenge the integrity of every oracle update using the ‘verify’ feature. Data is independently sourced by a community of Validators including Gitcoin, Etherscan, Infura, DeFi Saver, and MakerDAO.\n- Gas Efficiency : Pioneering the Schnorr-based oracle architecture, Chronicle’s oracles use 60-80% less gas per update than other oracle providers. This lowest cost per update allows Push oracle updates to be made more frequently, enabling granular data reporting.\n- Every oracle implementation is customized to fit your needs. Implement one of our existing data models or contact Chronicle to develop custom oracle data feeds via Discord .\nDevelopers can dive deeper into Chronicle Protocol’s architecture and unique design choices via the docs .\nPyth\nThe Pyth Network is one of the largest first-party oracle networks, delivering real-time data across a number of chains. Pyth introduces a low-latency pull oracle design. Data providers push price updates to Pythnet every 400 ms. Users pull aggregated prices from Pythnet onto Monad when needed, enabling everyone in the onchain environment to access that data point most efficiently.\nPyth Price Feeds features:\n- 400ms latency\n- First-party data sourced directly from financial institutions\n- Price feeds ranging from crypto, stocks, FX, and metals\n- Available on many major chains\nContract Addresses for Monad Testnet:\n- Price feeds: 0x2880aB155794e7179c9eE2e38200202908C17B43\n- Entropy: 0x36825bf3Fbdf5a29E2d5148bfe7Dcf7B5639e320\nThe MON/USD price feed has graduated from Pyth’s beta program and is served by the primary price feed contract on both testnet and mainnet, under feed id 0x31491744e2dbf6df7fcf4ac0820d18a609b49076d45066d3568424e62f686cd1 . To get the MON/USD price feed offchain, follow the Hermes guide for the current API endpoint and authentication requirements. If you previously integrated the beta price feed contract ( 0xad2B52D2af1a9bD5c561894Cdd84f7505e1CD0B5 ) for MON/USD, migrate to the primary contract: the beta contract no longer serves this feed.\nRedstone\nRedStone is the fastest-growing modular oracle, specializing in yield-bearing collateral for lending markets, such as LSTs, LRTs and BTCFi.\nTo get started, visit the Redstone documentation .\nStork\nStork is an oracle protocol that enables ultra low latency connections between data providers and both on and off-chain applications. The most common use-case for Stork is pulling and consuming market data in the form of real time price feeds for DeFi.\nStork is implemented as a pull oracle . Stork continuously aggregates, verifies, and audits data from trusted publishers, and makes that aggregated data available at sub-second latency and frequency. This data can then be pulled into any on or off-chain application as often as needed.\nTo learn more about how Stork works, visit Core Concepts and How It Works .\nSupra\nSupra provides VRF and decentralized oracle price feeds (push and pull based) that can be used for onchain and offchain use-cases such as spot and perpetual DEXes, lending protocols, and payments protocols.\nTo get started, visit the Supra documentation\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.base.org/get-started/issue-rwa","domain":"docs.base.org","title":"Tokenize Assets - Base Documentation","hash":"c0a8ddf01ef29a0342203e93a39f2c140da70787c5c6df24f9d7ae236676b781","tokens":553,"chars":2212,"crawler":"crawler-f6nn","verified":"exact","ts":1791172081715,"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\nSolutions\nTokenize Assets\nRepresent and operate real-world assets on Base with the B20 Asset standard: configurable precision, issuer roles, holder controls, and distributions through one ERC-20-compatible surface.\nRepresent a real-world asset with the B20 Asset standard . Configure precision and issuer roles, distribute units, restrict eligible holders, and run distributions through one ERC-20-compatible surface built into Base. The guides below use a stock token as the worked example; the same flows apply to other asset types.\nReal-world asset (RWA) tokenization is one of many use cases for the B20 Asset standard . The examples on this page use a stock token for illustration; the same flows apply to other asset types. Tokenized securities examples shown for illustration. Base is a general-purpose blockchain; issuance and compliance are the responsibility of the issuer under applicable law.\nDemo\nThe demo uses a local browser-generated account to submit real transactions on Base Vibenet . If Vibenet or its B20 features are unavailable, it automatically switches to an illustrative offline version.\nGuides\nCreate an Asset Token\nConfigure a B20 Asset token for one class of units.\nIssue Units to Holders\nDistribute units to multiple approved holders in one batch.\nRestrict Eligible Holders\nGate issuance and transfers with a shared allowlist.\nRestrict Who Can Initiate Transfers\nRequire a designated initiator, such as a transfer agent, for every transfer.\nSeize and Cancel Units\nMove units from an ineligible holder to safekeeping, then cancel them.\nAnnounce a Change to Holders\nPublish an onchain disclosure with the issuance, multiplier update, or burn it describes.\nApply a Multiplier\nUpdate displayed balances without migrating holders.\nPause Transfers\nHalt transfers during an incident while issuance stays available.\nWas this page helpful?\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ton.org/start-here","domain":"docs.ton.org","title":"Start here","hash":"a1bd54ab127571d2c2260dd7b99e8e2b4bfb4529fa6a670984c06f285fd87562","tokens":4906,"chars":19623,"crawler":"crawler-f6nn","verified":"exact","ts":1791172084453,"text":"Onboarding Nodes Applications APIs Contracts Smart contracts Tolk Tolk language TVM TON Virtual Machine Foundations Blockchain foundations\nStart here\nCondensed overview of documentation and TON blockchain\nThe documentation is organized by layers of detail, with lower-level details appearing later on the sidebar on the left.\nOnboarding Overview of the basic tools to onboard in TON: from AI and wallets to explorers and analytics.\nNodes Guides for running TON infrastructure: nodes, validators, staking setups, and related tooling.\nApplications Tools and guides for building user-facing dApps: SDKs, TON Connect, and guides on monitoring and processing blockchain transactions in business applications.\nAPIs Options for reading TON data and interacting with it from the off-chain world.\nSmart contracts Working with the most popular standardized contracts and guides on developing new smart contracts.\nTolk language Reference documentation for the official TON smart contract language.\nTON Virtual Machine Description of the low-level language that runs smart-contracts, and details of the runtime.\nBlockchain foundations Comprehensive description of the blockchain. Includes web version of whitepapers.\nLegacy languages Documentation for older TON languages kept for maintaining older contracts and understanding historical tooling.\nContributing Documentation on writing this documentation.\nThis is a condensed description of TON. The rest of the documentation may assume that all of this is already known to the reader.\nTON overview\nTON is a blockchain . It provides a distributed platform for storing data and code, as well as running computations, all the ingredients to host applications. Roughly speaking, it works as if it were a single server executing all the code. The hosted applications are called smart-contracts .\nThe platform runs on a set of servers, called nodes . Most important type of nodes, validators , are owned by individuals or organizations with a large stake in TON and great interest in keeping the platform safe, fair, and operational. Validators have to reach consensus on the state of the blockchain. Typically, the process takes below a second to reach transaction finality , a time to mint a new block.\nNetwork communication\nThe nodes that run the blockchain interact via the ADNL protocol. User-facing applications usually use servers that proxy JSON HTTP requests into the ADNL network. The official version of such a proxy server is provided by the liteserver software. There are public instances of liteserver, so developers are not required to host one on their own servers.\nGram and fees\nGram (GRAM) is the TON's primary cryptocurrency . It is used to pay for the execution of smart contracts, the storage of their data, and network traffic. Such payments are called fees .\nMainnet and testnet\nThere are two instances of TON blockchain: mainnet and testnet.\nMainnet is the \"real\" network. It's where actual payments in Gram are made. Applications use the mainnet by default.\nThe other network is testnet , and it is used by TON developers to check that their applications work correctly before deploying them to mainnet. It uses \"test coins\" that barely have any value.\nUsually, when the TON blockchain gets an update, it is first deployed to testnet, and then to mainnet after a brief period of testing, so sometimes they may run different software. Also, their configuration , availability, and throughput might be different.\nWorkchains and shards\nKey term: workchain\nA workchain is a TON blockchain with its own rules and account space. The masterchain holds global configuration and system smart contracts, while the basechain host most accounts and user space smart contracts and can be split into shardchains for scalability. In future there might be new workchains with there own set of rules and logic. Practical note: addresses include the workchain ID, and most apps use workchain 0 (basechain).\nEach network is split into workchains that can freely interact with each other, but their implementations may differ significantly.\nAt the moment, there are two workchains: basechain ( workchain_id = 0 ) for regular use, and a very similar masterchain ( workchain_id = -1 ) for TON's internal bookkeeping . The masterchain follows mostly the same rules, except that using it is more expensive to limit the amount of traffic that interferes with TON's internals.\nTo be freely scalable, each workchain is split into shards . The number of shards is determined dynamically based on the current network load. Internally, every shard is implemented as a separate blockchain. Except for increased latency, the effect on the user-facing code is minimal.\nAccounts\nIt's easiest to visualize the blockchain as a set of accounts . Each account has an address and a status.\nAccount statuses\nOver its lifetime, an account changes its status among four values:\n- nonexist : There wasn't a single operation with the account, or it was removed. It has neither a balance, nor code.\n- uninit : If some Gram is transferred to an account, it now exists, but there is still no smart contract code on it. It now has a balance.\n- active : After a deploy message (see below) with code and initial data is sent to an account, it becomes active and can process other messages. It now has a balance, code, and internal state.\n- frozen : If an account is overdue on its storage fees , it will be frozen until the fees are paid. If the overdue amount reaches a maximum limit specified by the blockchain, the account goes completely bankrupt, is removed, and ceases to exist.\nSmart contracts\nThe code on an active account is a smart contract. The term contract is often used for an account that holds the code.\nAccount addresses\nThe internal address of an account is a pair of two numbers: its workchain ID and a 256-bit number. It may be displayed in the raw format (e.g., 0:4098805d2272a61b375350c6b2f5faaaf27c8267d8e7521ff2045104fdc7de76 ), but is usually shown in a user-friendly format (e.g., UQBKgXCNLPexWhs2L79kiARR1phGH1LwXxRbNsCFF9doczSI ).\nMessages\nAddresses specify where messages should be delivered. There are three types of messages:\n- internal messages are sent between accounts;\n- incoming external messages are sent from code outside the blockchain to a contract;\n- outgoing external messages are broadcast to the external network; somewhat similar to adding them into the globally available list of all outgoing external messages that ever happened.\nEvery internal message should have some Gram attached to it so that it can pay for the cost of handling it. External messages cannot have Gram attached to them because they come from or go to \"outside\" the blockchain, where Gram does not exist.\nIncoming external messages come from an external address, and outgoing external messages go to an external address.\nStateInit\nThe state of the account changes only when it handles messages. Messages also change the account's balance. An account is active when it has a state and a balance.\nA message might also be a deploy message if it has a StateInit structure attached with its initial code and data. When such a message is sent to a destination address derived from the StateInit hash, the code and data are stored in the account at that address, and the account becomes active. Both the code and data stored in the account may change in the future, but its address will remain the same as when it was originally deployed.\nTransactions\nFormally, a message is only an intent: it has a destination, possibly some Gram, and data. After the message is handled and all the necessary changes are applied to the blockchain, the message is packed, along with a description of those changes, into a single packet of data, called a transaction . A transaction records the state changes on an account. Some transactions might happen without any message.\nTON Virtual Machine\nInternal and incoming external messages execute the account's code. The code is interpreted by TON Virtual Machine (TVM). It is written in bitcode , a binary format specific to TVM. In the future, TVM might support multiple binary languages, codepages , but at the moment there is only codepage 0 ( CP0 ).\nPhases\nWhen execution starts , the message and current account state are provided to the code. By the end of execution, the account might change its state or code, or send internal or outgoing external messages.\nThe execution follows a process whose steps are called phases . Fees are deducted during this process. Fees might be deducted from the account's balance or from the Gram the message carries, depending on the mode of the message, or by explicit choice made in the contract's code.\nGas\nExecution cost is first measured in gas units, then converted to Gram. This unit is separate so that if code execution becomes computationally cheaper (or more expensive), validators can vote to change the price of gas in Gram.\nExit codes\nIf something goes wrong, a non-zero exit code might be returned, no changes to state or code are saved, and no further messages are sent. If the message that resulted in a failed transaction is marked as bounceable , a bounce message is sent back to the sender. Bounce messages are used to inform the sender that handling of their message failed. They can carry either truncated or full body of the original message.\nTraces\nThe most common reason a code is executed is when some account has received a message. Internal messages can only be sent by another contract executing some code, and that contract must have received a message from somewhere too. In the end, every message can be considered part of some trace : a tree of messages between accounts that starts with an incoming external message, continues with internal messages, and possibly ends with some outgoing external messages.\nAsynchronous execution\nWhen some interaction with the blockchain involves multiple contracts, their code may not be executed in the same block. Contracts have to exchange messages with each other, and two such concurrent traces may interleave their messages. This fact is usually referred to as \" asynchronous message handling.\" This feature of TON allows a limit to be placed on the maximum complexity of atomic computation and aids its scalability, but it is important to keep it in mind because it might create race conditions .\nLanguages\nMost development is done in Tolk , a high-level programming language. Its compiler is included in the Acton development environment.\nOriginally, Fift , a Forth-like assembly language, and FunC , a C-like intermediate-level language, were the first languages for TON smart contract development.\nGet methods\nIf an external service needs to extract data from the blockchain, it can call a get method : an arbitrary function implemented in the code deployed to an account. Every call of a get method spawns a separate instance of TVM. Any changes to the blockchain made during the execution of a get method are not committed to the blockchain.\nUnlike in other blockchains , get methods cannot be called by other contracts. It is intentional for several reasons:\n- by the time another contract receives the result of such a call, other messages may have been processed and may have changed the result;\n- get methods are executed completely separately, and changes from the blockchain are not guaranteed to be propagated to the server running the code of a get method.\nWallets\nThe main user of incoming external messages is a wallet . A wallet is an account with a specific kind of smart contract deployed on it, which can handle incoming external messages, specifically transfer messages. A transfer message is a request to send an internal message to another account. Thus, a wallet transforms incoming external messages to internal messages.\nWallet contract types\nThere are several implementations of wallets, with varying extra functionality and protection. V5R1 is the latest official general-purpose wallet. The text below describes only the functionality common to most wallets.\nHow wallets work\nA transfer message consists of a destination address and, optionally, an internal message, both serialized and signed with a private key . The wallet stores a public key and uses it to check that a transfer message was signed with the corresponding private key. If the check succeeds, it sends that internal message to the destination address. This ensures only the user (or a service) who knows the private key can use the wallet.\nPrivate and public keys are generated in a program or service outside the blockchain. Public key is used in a StateInit during the deploy, and determines the address of the wallet account. Keypair is usually derived from a set of 24 random words called a mnemonic .\nBefore the code of the wallet can be deployed on an account with an incoming external message, some other account has to transfer Gram to the wallet account. As external messages cannot have any Gram attached to them, if no funds are in the account when it handles an external message, it cannot pay for the message that deploys a wallet. The transfer of Gram to a wallet account usually comes from an exchange or another user. In testnet, there is a bot that sends test coins to an account for free.\nUsually, a transfer message is sent without an additional payload and only instructs the wallet to transfer some Gram to a destination address. This is the reason this type of smart contract is called a wallet.\nAn internal message might be a request to some other contract or even a deploy message that deploys code on other accounts. In this way, a wallet acts as a proxy between a user (or an external service) and the rest of the blockchain.\nWallet apps\nEnd users usually use wallet apps to create and use wallets. An exchange will usually create a wallet for a user as well.\nStandard contracts\nThe other important types of contracts are\n- Jetton tokens roughly correspond to coins and allow developers to mint their own currency;\n- NFT tokens are similar to tickets: unique items that can be sold;\n- SBT tokens are like medals: unique items that can be given to someone but can never be sold or transferred.\nMany popular contract types have been standardized in TON Enhancement Proposals ( TEP ), mostly describing expected contract interfaces with TL-B schemas. This allows tooling to be reused between similar contracts. For example, explorers detect TEP-standardized contracts and display their binary messages in a user-friendly format, and provide an interface to call their get methods.\nExplorers\nAn explorer is a type of web app that displays information about the current state of accounts (including wallets, Jettons, and NFTs) and the history of transactions. Discover popular TON explorers .\nAPIs and SDKs\nTo interact with wallets, Jettons, and other contracts, data has to be sent through an ADNL or HTTP API into the network. There are several ways to connect:\n- directly call the API , or\n- use an SDK that simplifies working with an API by wrapping its methods in a more user-friendly interface; the most popular TypeScript SDK for this is @ton/ton .\nTON Connect\nWhen an application has to use a wallet to prove the user's identity, it needs access to the wallet's private key. Giving arbitrary applications access to the private key is insecure, as they could perform arbitrary actions with the wallet. To address this, there is the TON Connect set of SDKs that provide interfaces\n- for an application to perform an action through the wallet app;\n- for a wallet app to handle these requests.\nFor example, Telegram apps use TON Connect to access a wallet that is integrated into Telegram.\nData storage model\nAll data on TON is stored as trees of cells : the state of contracts, their code, and messages. Each cell stores up to 1023 bits of data and can have up to 4 refs to other cells. Each cell has a hash computed from its bits and refs. Because the hash of a cell that directly or indirectly references itself would require knowing the same hash, creating cyclic data structures is impossible.\nStandard serialization of such a data structure into a single binary string is the bag of cells ( BoC ). When cells need to be stored in a file or sent over the network, they are commonly serialized into a BoC. Smart contract code is also compiled into BoC files.\nBinary representation\nTo tell other developers how a certain type of data is stored in cells, a TL-B schema language is used. Its purpose is similar to that of protocol buffers or binary templates , but it provides more features for structuring data at the bit level.\nThere are libraries for assembling data structures out of cells. For TypeScript, the most popular one is @ton/core .\nThe TL-B schemas for binary representations of messages, transactions, initial contract state, and most other data structures used by the blockchain can be found in the block.tlb file in the TON monorepo . TypeScript functions for serializing and deserializing them are provided by the @ton/core and @ton/ton libraries.\nIn general, a library that converts data structures between cells and the format native to a programming language, or allows calling contract methods as native functions of the language, is called a wrapper or binding . For example, functions that deserialize Jetton-related cell data into TypeScript objects can be found in the assets-sdk library. Acton toolchain can generate bindings from the Tolk contract's source code. The \"rule of thumb\" is that production-grade code should not include low-level manipulation of binary data, and should instead rely on a library with bindings. This reduces the chance of mistakes and ensures the code has more users. With widely reused code, there are more opportunities to detect mistakes, and they are more likely to be fixed quickly.\nBlockchain interaction\nSo, to interact with the blockchain, a couple of libraries are usually used: one that handles the connection to the blockchain and another that works with the specific type of data sent over that connection.\nNot all computation has to be done on-chain , i.e., executed inside TVM and paid for with Gram. Computing and storing data on the blockchain is significantly more expensive than doing so on a regular CPU. Instead, much of the work can be done in off-chain code, in a regular programming language, before or after sending a request to the blockchain. The recommended development practice is to write a TypeScript library that calls contracts implemented in Tolk.\nNext steps\n- Coming from Ethereum or similar synchronous blockchains? — compare the differences in execution model and ecosystem.\n- Want to host nodes or get involved in staking? — pick the right TON node setup and understand the required operational work.\n- Aiming to build a new dApp or integrate existing one with TON? — use the rich toolset of the TON application layer.\n- Aspire to write new or audit existing smart contracts? — set up the toolchain and editor plugins , work with standard contracts , learn the techniques to write new contracts, master the Tolk language and the TVM runtime .\nGet support\nNext Page\nOn this page\nTON overview Network communication Gram and fees Mainnet and testnet Workchains and shards Accounts Account statuses Smart contracts Account addresses Messages StateInit Transactions TON Virtual Machine Phases Gas Exit codes Traces Asynchronous execution Languages Get methods Wallets Wallet contract types How wallets work Wallet apps Standard contracts Explorers APIs and SDKs TON Connect Data storage model Binary representation Blockchain interaction Next steps"}
{"url":"https://docs.polkadot.com/apps/quick-start/","domain":"docs.polkadot.com","title":"Quick Start with the CLI | Polkadot Developer Docs","hash":"a4708088afb9c9958aa39c46cfeeae68c5ef87e273e282ee3056a17bf0a69365","tokens":4335,"chars":17337,"crawler":"crawler-f6nn","verified":"exact","ts":1791172086583,"text":"Skip to content\nInitializing search\n- Get Started\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\nQuick Start with the CLI ¶\nQuick Start with RevX ¶\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nDeploy a Polkadot Product from your terminal with playground-cli. The pg command pairs with your Polkadot App , builds your Product , uploads the bundle, and publishes it to a dotNS name. No local host setup is required to reach a live deployment.\nThe CLI is the command-line counterpart to Polkadot Desktop : Desktop runs published Products by their dotNS names; pg takes a project on disk and turns it into one. By the end of this guide, you will have a Product live at its own name, reachable in any browser through the dotNS web gateway.\nTestNet names end in .paseo , not .dot\ndotNS top-level domains are per network. On Paseo Next v2, the TestNet the Apps tooling targets by default, names are minted under .paseo : publish myproject57 and you get myproject57.paseo , served at https://myproject57.paseo.li . Whether you supply the bare label or the full name depends on the tool; see Choose a Name .\nBuilding with an AI agent?\nPoint your coding agent at the right skills, repos, and docs first, so it writes idiomatic Product code instead of generic boilerplate. See Set Up Your AI Agent for a paste-ready setup prompt.\nBefore You Start ¶\nGet these in order before your first deploy. The last two are easy to skip and fail silently later, so do not leave them out:\n- Install the Polkadot App on your phone and create an account. It pairs with pg and signs your deploy.\n- Have a terminal with curl available and permission to install CLI tools in your user shell.\n- Have a Product project on disk with a package-manager build command.\n- Fund your account with PAS from the faucet . PAS pays transaction fees and the name deposit.\n- Get a Bulletin Chain storage authorization for the account that will sign. Without it, uploads are rejected at deploy time even when your balance is fine — a prerequisite that surfaces only as a failed publish. See Get TestNet Tokens .\nFund the account that actually signs\nThe PAS balance and the storage authorization are both per account, and the account that signs your deploy may not be the one you expect. If a deploy fails with no allowance set for account , see Accounts and Signing and the troubleshooting entry . Account mapping to an EVM address is handled for you for the product account you deploy with; a smart contract needs its signing account mapped explicitly, covered in Add a Smart Contract to Your Product .\nWhat a first deploy costs\nIn one test run, taking an app live cost about 10.4 PAS : roughly 10 PAS for the name and about 0.4 PAS for a 2.6 KB upload, with each on-chain step taking around a minute. Name cost depends on length and tier, so treat these as a ballpark. On TestNet, funding is rarely the constraint.\nCLI version\nThe CLI is in active development, and breaking changes between versions are expected. If a command below no longer matches, check this page's last update against the latest playground-cli release .\nInstall the CLI ¶\nThe installer supports Linux and macOS. On Windows, work inside WSL and follow the Debian/Ubuntu steps there.\n-\nInstall the base prerequisites. macOS needs no preparation: curl ships with the OS, and the Xcode Command Line Tools cover the rest. On a fresh Debian or Ubuntu system:\nsudo apt update && sudo apt install -y build-essential curl\n-\nRun the installer:\ncurl -fsSL https://raw.githubusercontent.com/paritytech/playground-cli/main/install.sh | bash\nThe binary lands in ~/.polkadot/bin/ , with both commands symlinked into ~/.local/bin/ and that path appended to your shell RC file.\n-\nOpen a new shell, or source your RC file, and verify the install:\npg --version\nCommand aliases\nThe installer registers two interchangeable commands: playground (canonical) and pg (short alias). This guide uses pg throughout.\nPinning a version\nPass VERSION to install a specific release, for example curl -fsSL … | VERSION=v0.47.0 bash . Later, pg update moves you to the newest release.\nLog In ¶\npg login is the first-run setup: it pairs the CLI with your signer, installs the toolchain, and requests your service allowances. It is safe to re-run; existing installs and sessions are detected and skipped. Do not reach for pg init here — that scaffolds a project from the starter template and pairs nothing.\npg login\npg login ✔ logged in 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY ✔ account in use playground.dot/0 — 0x90b5ab205c6974c9ea841be688864633dc9ca8a3 · 5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty\nThree things happen, and the first two run concurrently:\n- Login : A QR code is printed to the terminal. Scan it with the Polkadot App to pair. Skipped if you already have a session under ~/.polkadot-apps/ .\n- Toolchain install : git , curl , a C linker, rustup with nightly and rust-src , cargo-pvm-contract , wget , and the ipfs CLI (Kubo). Existing installs are detected and skipped.\n- Account setup : Once a session exists, your phone shows a single approval dialog requesting the BulletInAllowance (Bulletin uploads at deploy time) and SmartContractAllowance (which mints PGAS to your playground.dot/0 product account and account-maps it on chain).\npg deploy needs the ipfs CLI, and pg login is what installs it\nDo not skip this step. pg deploy requires the Kubo ipfs binary on your PATH ; if you never log in, install it yourself with brew install ipfs or from docs.ipfs.tech/install . This is a temporary requirement while the pure-JS merkleizer is being fixed.\nSigner modes\nSigner choice is made at deploy time, not at login, through pg deploy --signer :\n- Mobile signer ( --signer phone ): Signs with the account you paired here, approving each on-chain step on your phone. Recommended for any deploy you intend to keep.\n- Dev-only signer ( --signer dev ): No phone needed; uses shared development keys (pair it with --suri //Alice to pin a known keypair). The deployed Product will be owned by the shared dev account, not by you.\nFunding is opt-in\npg login never sends tokens. If your product account needs a testnet balance, run pg drip to top it up (1 PAS per run, up to 10 PAS , from a shared dev funder), or use the faucet . Run pg status at any time to see your product account address, its balances, and your allowance state.\nBuild ¶\npg build auto-detects and runs your project build.\npg build\npg build ✔ Build succeeded → dist/\nDeploy ¶\npg deploy runs the full pipeline: build the frontend, upload artifacts to the Polkadot Bulletin Chain , and register a dotNS domain under the environment's TLD ( .paseo on Paseo Next v2). Before building, it always runs your package manager's install step to keep dependencies in sync.\n# Interactive - pg prompts for signer, domain, and build directory\npg deploy\n# Dev signer - no phone needed (the deployed Product is owned by the shared dev account)\npg deploy --signer dev --suri //Alice --domain my-product\nPass the bare label to --domain . The CLI appends the environment's TLD, so my-product becomes my-product.paseo on Paseo Next v2. Name availability depends on the label's length, counted as written; see Choose a Name for the rules the prompt enforces.\npg deploy --signer dev --suri //Alice --domain my-product ✔ my-product.paseo is available ✔ Deploy complete URL https://my-product.paseo.li Domain my-product.paseo App CID bafybeihvru3e6ojhopxj7xxwtafrpyvsha6kylzklryon5k67u4clr26re\nYour phone will prompt — check it\nWith the phone signer, each on-chain step waits for you to approve it in the Polkadot App , and no push notification announces the prompt. If the deploy seems to pause (including a deliberate ~60-second wait while your name is registered), open the app and approve the pending request. See Troubleshooting .\nNote\npg deploy includes a memory watchdog that aborts the deploy if the process exceeds 4 GB RSS. If you hit this limit, set DOT_MEMORY_TRACE=1 alongside DOT_DEPLOY_VERBOSE=1 to capture per-second RSS and heap samples.\nFor the full interactive deploy walkthrough, including the domain-name rules, contract redeploys, and the confirmation summary, see Deploy Your App .\nMore CLI commands\nAccount and session\n-\npg status : Prints your signed-in product account in both encodings (SS58 and H160), its PAS and PGAS balances, and the state of your Bulletin and smart-contract allowances. Read-only: it signs nothing and submits nothing, so it is safe to run at any time. With no session paired it prints a \"log in first\" notice and exits cleanly.\npg status\n-\npg drip : Tops up your product account with a little TestNet PAS : 1 PAS per run, up to a 10 PAS cap, from a shared dev funder rather than the public faucet. It only ever funds the caller's own account, resolved from the active session, so there is no address flag. Login never calls it for you.\npg drip\n-\npg logout : Signs out of the paired account, tells the paired phone to drop its side of the connection, and clears session files under ~/.polkadot-apps/ . A no-op if you are not signed in.\npg logout\nProjects and deploys\n-\npg init : Scaffolds a new project from the playground starter template. A shorthand for pg mod playground-template .\npg init\n-\npg mod : Clones a moddable app from the Playground registry so you can customize and redeploy it as your own Product . Only apps that opted into --moddable at deploy time are listed. Pass a domain label, such as my-product or my-product.paseo , to clone directly, or omit it to open an interactive picker showing every moddable app. Source is fetched as a tarball over HTTPS, so neither git nor gh is required.\npg mod [ domain ]\n-\npg decentralize : Takes a static site you already have — a live URL to mirror, or a local build directory — uploads it to the Bulletin Chain , and registers a dotNS name pointing at it. The counterpart to pg deploy , which builds your project first.\npg decentralize --site https://example.com\npg decentralize --path ./dist\n-\npg deploy-all : Deploys several apps listed in a JSON manifest in one invocation. Builds run in parallel, while all on-chain work is serialized per signing account so concurrent deploys never collide on a nonce. Non-interactive by design.\npg deploy-all --manifest apps.json --signer dev --playground\n-\npg contract : The playground-native path to contracts, backed by cdm . pg contract deploy builds, deploys, and registers your contracts signed by your logged-in account; pg contract install writes cdm.json and the generated type outputs. See Add a Smart Contract to Your Product for the workflow, including when to call cdm directly instead.\npg contract deploy\npg contract install [ libraries... ]\n-\npg update : Updates pg to the latest version from the GitHub releases page.\npg update\nScripting a deploy, or handing one to an agent\npg deploy -y runs non-interactively using defaults, skipping every prompt. It requires --domain , and --signer defaults to dev . For full control in CI, pass --signer , --domain , --buildDir , and --playground explicitly; add --suri //Alice with --signer dev so the dev signer uses a known keypair. See Set Up Your AI Agent for orienting a coding agent around this toolchain.\nYou have deployed a Polkadot Product . To keep building it with your own editor and toolchain, head to the Build guides; they open with project setup so Polkadot Desktop can load your Product from localhost while you iterate with live reload.\nWhere to Go Next ¶\n-\nLearn Product SDK\nUnderstand the SDK that powers your Product: what each package does and how the pieces fit together.\nProduct SDK\n-\nGuide Build Guides\nSet up the local dev loop, then add capabilities to your Product: signing, on-chain reads, decentralized storage, off-chain pub/sub, local persistence, and smart contracts.\nOpen Build Guides\n-\nGuide Deploy Your App\nThe full deploy flow in depth: build the bundle, register a dotNS name, publish to the playground, and go live on the Bulletin Chain.\nDeploy Your App\nGenerate and publish a Polkadot Product in the browser with RevX App Builder. RevX gives you a browser-based IDE, scaffolds a Product from a natural-language prompt, and publishes it to a .dot name after you sign the final step with the Polkadot App .\nThis route does not require a local development environment. By the end, you will have configured an AI provider in App Builder, generated a Polkadot Product from a prompt, inspected the generated code, and published it to .dot .\nTestNet names end in .paseo , not .dot\ndotNS top-level domains are per network. On Paseo Next v2, the TestNet the Apps tooling targets by default, names are minted under .paseo : publish myproject57 and you get myproject57.paseo , served at https://myproject57.paseo.li . Whether you supply the bare label or the full name depends on the tool; see Choose a Name .\nPrerequisites ¶\nBefore starting, make sure you have:\n- The Polkadot App installed on your phone with an account created; it signs the final publish step.\n- An API key for an AI provider supported by App Builder, such as OpenAI or Anthropic.\nOpen RevX ¶\nOpen RevX in your browser. RevX is a browser-based IDE; you will use the App Builder track to scaffold a Polkadot Product end to end.\nOpen App Builder ¶\nFrom the sidebar, select App Builder . App Builder is RevX's track for generating Polkadot Products using AI-assisted workflows.\nCreate a New App ¶\nClick Create App to start a new project. RevX automatically installs the required dependencies and initializes the project environment so you can move straight into configuration and prompting.\nAfter clicking Create App , you will see a loading screen while the IDE initializes the project environment.\nNote\nInitial setup may take a moment while dependencies install. Wait for the environment to finish initializing before configuring the builder.\nOnce the environment is initialized, you will see a minimal app scaffolded in the editor and running in the terminal.\nConfigure the Builder ¶\nFrom the App Builder view, click the Settings icon to open the AI configuration panel.\nConfigure the following:\n- AI provider : The backend service that powers code generation.\n- API key : The credential for your AI provider.\n- Model : The specific model to use from the selected provider.\nThese settings let the IDE generate applications using the selected AI backend. You can change them at any time if you want to switch providers or models.\nGenerate an App ¶\nUse the chat interface to describe the app you want to build. RevX generates the application structure and code automatically based on your prompt.\nExample prompt\nBuild a Product that shows the balance of Alice (a standard Substrate dev account)\nAfter you submit the prompt, the IDE produces the project files and scaffolds the app for you to review.\nTip\nKeep prompts concrete and scoped. Short, specific prompts tend to produce app structures that are easier to review and iterate on.\nInspect the Generated Code ¶\nOnce generation completes, open the generated files in the editor to review what was produced. You can continue iterating on the application from within RevX: refine the prompt, edit code directly, or layer additional changes through the chat interface.\nPublish to .dot ¶\nWhen your app is ready, click Publish to .dot to deploy the application to the Polkadot ecosystem. The publish action takes the app you generated in RevX and makes it available under a .dot name.\nAfter clicking Start Deploy , you will be asked to sign the transaction with your Polkadot App .\nAfter signing the transaction, you will see the deployment progress in the terminal. The action is labeled Publish to .dot , but the name you receive carries the network's TLD, so on Paseo Next v2 your Product is live under its .paseo name. Open it in Polkadot Desktop , or on Polkadot Web at https://.paseo.li in any browser.\nWhere to Go Next ¶\n-\nGuide Build Guides\nSet up the local dev loop, then add capabilities to your Product: signing, on-chain reads, decentralized storage, off-chain pub/sub, and local persistence.\nOpen Build Guides\nLast update: September 18, 2026\n| Created: June 16, 2026"}
{"url":"https://docs.squads.so/main/additional-resources/key-aspects-of-using-a-multisig","domain":"docs.squads.so","title":"Key aspects of using a multisig | Squads Docs","hash":"748474681b389d55242f9f33bed957feed33d9f434e43fb139f534e2b4c0b164","tokens":533,"chars":2130,"crawler":"crawler-f6nn","verified":"exact","ts":1791172089668,"text":"Squads Docs\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nKey aspects of using a multisig\nBy using a multisig, it is important to acknowledge certain concepts. Here are some points to have in mind when using a multisig:\n-\nLoss of Private Keys . Always keep a backup of your private keys added as members to your multisig. If a key is lost, it could impact the multisig operations if a specific number of signatures are needed to reach the threshold.\n-\nSingle Point of Failure with Keys . For added security, consider storing keys in different secure locations. Otherwise a single breach can compromise the whole set up.\n-\nThreshold. Be sure everyone in the multisig understands the number of signatures required for transactions, so you always have the needed approvals.\n-\nNo Succession Planning. If keyholders become unavailable (e.g., due to accident, death), without a plan for transition, funds may be locked forever.\n-\nTransfer of Funds to Wrong Address. Funds should always be sent to the multisig vault account, and not the multisig account address. Due to the design of the Squads Protocol program, funds deposited to the multisig account may not be recovered.\n-\nConfig Authority . If the config_authority of a multisig is compromised, an attacker can change multisig settings, potentially reducing the required threshold for transaction execution or instantly being able to remove and add new members (changing config_authority ownership is only possible programatically and is subject to threshold requirements).\n-\nSVM Forks . If the underlying SVM compatible blockchain undergoes a fork and a user had sent funds to the orphaned chain, the state of the blockchain may not interpret the owner of funds to be original one.\n-\nTime Locks . While setting time locks be certain of the duration you are comfortable with so your funds remain accessible when needed.\n-\nSOL for Network Fees . Always ensure multisig participants maintain a minimum balance of the native token needed for transaction fees.\nPrevious What if the Squads app goes down\nLast updated 2 years ago"}
{"url":"https://vitalik.eth.limo/general/2022/07/13/networkstates.html","domain":"vitalik.eth.limo","title":"What do I think about network states?","hash":"5636c621d4e03e790a8d97663b0e60d3c0cdfecf2bb6fe51318c2ad25d8ed0ae","tokens":9995,"chars":39977,"crawler":"crawler-f6nn","verified":"exact","ts":1791172092389,"text":"Dark Mode Toggle\nWhat do I think about network states?\n2022 Jul 13\nSee all posts\nWhat do I think about network states?\nOn July 4, Balaji Srinivasan released the first version of his\nlong-awaited new book describing his vision for \" network\nstates \": communities organized around a particular vision of\nhow to run their own society that start off as online clubs, but then\nbuild up more and more of a presence over time and eventually become\nlarge enough to seek political autonomy or even diplomatic\nrecognition.\nNetwork states can be viewed as an attempt at an ideological\nsuccessor to libertarianism: Balaji repeatedly praises The\nSovereign Individual (see my mini-review here )\nas important reading and inspiration, but also departs from its thinking\nin key ways, centering in his new work many non-individualistic and\nnon-monetary aspects of social relations like morals and community.\nNetwork states can also be viewed as an attempt to sketch out a possible\nbroader political narrative for the crypto space. Rather than staying in\ntheir own corner of the internet disconnected from the wider world,\nblockchains could serve as a centerpiece for a new way of organizing\nlarge chunks of human society.\nThese are high promises. Can network states live up to them? Do\nnetwork states actually provide enough benefits to be worth getting\nexcited about? Regardless of the merits of network states, does it\nactually make sense to tie the idea together with blockchains and\ncryptocurrency? And on the other hand, is there anything crucially\nimportant that this vision of the world misses? This post represents my\nattempt to try to understand these questions.\nTable of contents\n- What is a network state?\n- So what\nkinds of network states could we build?\n- What is\nBalaji's megapolitical case for network states?\n- Do\nyou have to like Balaji's megapolitics to like network states?\n- What\ndoes cryptocurrency have to do with network states?\n- What aspects of\nBalaji's vision do I like?\n- What\naspects of Balaji's vision do I take issue with?\n- Non-Balajian network\nstates\n- Is there a middle way?\nWhat is a network state?\nBalaji helpfully gives multiple short definitions of what a network\nstate is. First, his definition in one sentence:\nA network state is a highly aligned online community with a capacity\nfor collective action that crowdfunds territory around the world and\neventually gains diplomatic recognition from pre-existing states.\nThis so far seems uncontroversial. Create a new internet community\nonline, once it grows big enough materialize it offline, and eventually\ntry to negotiate for some kind of status. Someone of almost any\npolitical ideology could find some form of network state under\nthis definition that they could get behind. But now, we get to his\ndefinition in a longer sentence:\nA network state is a social network with a moral innovation, a sense\nof national consciousness, a recognized founder, a capacity for\ncollective action, an in-person level of civility, an integrated\ncryptocurrency, a consensual government limited by a social smart\ncontract, an archipelago of crowdfunded physical territories, a virtual\ncapital, and an on-chain census that proves a large enough population,\nincome, and real-estate footprint to attain a measure of diplomatic\nrecognition.\nHere, the concept starts to get opinionated: we're not just talking\nabout the general concept of online communities that have collective\nagency and eventually try to materialize on land, we're talking about a\nspecific Balajian vision of what network states should look\nlike. It's completely possible to support network states in general, but\nhave disagreements with the Balajian view of what properties network\nstates should have. If you're not already a \"crypto convert\", it's hard\nto see why an \"integrated cryptocurrency\" is such a fundamental part of\nthe network state concept, for example - though Balaji does later on in\nthe book defend his choices.\nFinally, Balaji expands on this conception of a Balajian network\nstate in longer-form, first in \"a\nthousand words\" (apparently, Balajian network states use base 8 , as the actual\nword count is exactly \\(512 = 8^3\\) )\nand then an\nessay , and at the very end of the book a whole\nchapter .\nAnd, of course,\nan\nimage .\nOne key point that Balaji stresses across many chapters and\npages is the\nunavoidable moral ingredient required for any successful new\ncommunity. As Balaji writes:\nThe quick answer comes from Paul Johnson at the 11:00 mark of this talk , where he notes\nthat early America's religious colonies succeeded at a higher rate than\nits for-profit colonies, because the former had a purpose. The slightly\nlonger answer is that in a startup society, you're not asking people to\nbuy a product (which is an economic, individualistic pitch) but to join\na community (which is a cultural, collective pitch).\nThe commitment\nparadox of religious communes is key here: counterintuitively, it's\nthe religious communes that demand the most of their members\nthat are the most long-lasting.\nThis is where Balajism explicitly diverges from the more traditional\nneoliberal-capitalist ideal of the defanged, apolitical and passion-free\nconsumerist \"last\nman\" . Unlike the strawman libertarian, Balaji does not believe that\neverything can \"merely be a consumer product\". Rather, he stresses\ngreatly the importance of social norms for cohesion, and a literally\nreligious attachment to the values that make a particular network state\ndistinct from the world outside. As Balaji says in\nthis podcast at 18:20, most current libertarian attempts at\nmicronations are like \"Zionism without Judaism\", and this is a key part\nof why they fail.\nThis recognition is not a new one. Indeed, it's at the core of\nAntonio Garcia Martinez's criticism of Balaji's earlier\nsovereign-individual ideas (see this\npodcast at ~27:00 ), praising the tenacity of Cuban exiles in Miami\nwho \"perhaps irrationally, said this is our new homeland, this is our\nlast stand\". And in Fukuyama's The End of History :\nThis city, like any city, has foreign enemies and needs to be\ndefended from outside attack. It therefore needs a class of guardians\nwho are courageous and public-spirited, who are willing to sacrifice\ntheir material desires and wants for the sake of the common good.\nSocrates does not believe that courage and public-spiritedness can arise\nout of a calculation of enlightened self-interest. Rather, they must be\nrooted in thymos, in the just pride of the guardian class in themselves\nand in their own city, and their potentially irrational anger against\nthose who threaten it.\nBalaji's argument in The Network State , as I am\ninterpreting it, is as follows. While we do need political collectives\nbound not just by economic interest but also by moral force, we don't\nneed to stick with the specific political collectives we have\ntoday , which are highly flawed and increasingly unrepresentative of\npeople's values. Rather, we can, and should, create new and better\ncollectives - and his seven-step\nprogram tells us how.\nSo what kinds of\nnetwork states could we build?\nBalaji outlines a few ideas for network states, which I will condense\ninto two key directions: lifestyle immersion and\npro-tech regulatory innovation .\nBalaji's go-to example for lifestyle immersion is a network state\norganized around health:\nNext, let's do an example which requires a network archipelago (with\na physical footprint) but not a full network state (with diplomatic\nrecognition). This is Keto Kosher, the sugar-free\nsociety .\nStart with a history of the horrible USDA Food Pyramid, the\ngrain-heavy monstrosity that gave cover to the corporate sugarification\nof the globe and the obesity epidemic. ... Organize a community online\nthat crowdfunds properties around the world, like apartment buildings\nand gyms, and perhaps eventually even culdesacs and small towns. You\nmight take an extreme sugar teeotaler approach, literally banning\nprocessed foods and sugar at the border, thereby implementing a kind of\n\"Keto Kosher\".\nYou can imagine variants of this startup society that are like\n\"Carnivory Communities\" or \"Paleo People\". These would be competing\nstartup societies in the same broad area, iterations on a theme. If\nsuccessful, such a society might not stop at sugar. It could get into\nsetting cultural defaults for fitness and exercise. Or perhaps it could\nbulk purchase continuous glucose meters for all members, or orders of\nmetformin.\nThis, strictly speaking, does not require any diplomatic recognition\nor even political autonomy - though perhaps, in the longer-term future,\nsuch enclaves could negotiate for lower health insurance fees and\nmedicare taxes for their members. What does require autonomy? Well, how\nabout a free zone for medical innovation?\nNow let's do a more difficult example, which will require a full\nnetwork state with diplomatic recognition. This is the medical\nsovereignty zone, the FDA-free society .\nYou begin your startup society with Henninger's history of FDA-caused\ndrug lag\nand Tabarrok's history of FDA interference with so-called \"off\nlabel\" prescription . You point out how many millions were killed by\nits policies, hand out t-shirts like ACT-UP did, show Dallas Buyers Club\nto all prospective residents, and make clear to all new members why your\ncause of medical sovereignty is righteous ...\nFor the case of doing it outside the US, your startup society would\nride behind, say, the support of the Malta's FDA for a new biomedical\nregime. For the case of doing it within the US, you'd need a governor\nwho'd declare a sanctuary state for biomedicine. That is, just like a\nsanctuary city declares that it won't enforce federal immigration law, a\nsanctuary state for biomedicine would not enforce FDA writ.\nOne can think up of many more examples for both categories. One could\nhave a zone where it's okay to walk around naked, both securing your\nlegal right to do so and helping you feel comfortable by\ncreating an environment where many other people are naked too.\nAlternatively, you could have a zone where everyone can only wear basic\nplain-colored clothing, to discourage what's perceived as a zero-sum\nstatus competition of expending huge effort to look better than everyone\nelse. One could have an intentional community zone for cryptocurrency\nusers, requiring every store to accept it and demanding an NFT to get in\nthe zone at all. Or one could build an enclave that legalizes radical\nexperiments in transit and drone delivery, accepting higher risks to\npersonal safety in exchange for the privilege of participating in a\ntechnological frontier that will hopefully set examples for the world as\na whole.\nWhat is common about all of these examples is the value of having a\nphysical region, at least of a few hectares, where the network state's\nunique rules are enforced. Sure, you could individually insist on only\neating at healthy restaurants, and research each restaurant carefully\nbefore you go there. But it's just so much easier to have a\ndefined plot of land where you have an assurance that anywhere you go\nwithin that plot of land will meet your standards. Of course, you could\nlobby your local government to tighten health and safety regulations.\nBut if you do that, you risk friction with people who have radically\ndifferent preferences on tradeoffs, and you risk shutting\npoor people out of the economy . A network state offers a moderate\napproach.\nWhat is\nBalaji's megapolitical case for network states?\nOne of the curious features of the book that a reader will notice\nalmost immediately is that it sometimes feels like two books in one:\nsometimes, it's a book about the concept of network states, and at other\ntimes it's an exposition of Balaji's grand megapolitical theory.\nBalaji's grand megapolitical theory is pretty out-there and fun in a\nbunch of ways. Near the beginning of the book, he entices readers with\ntidbits like... ok fine, I'll just quote:\n- Germany sent\nVladimir\nLenin into Russia, potentially as part of a\nstrategy\nto destabilize their then-rival in war. Antony Sutton's books document\nhow some\nWall\nStreet bankers apparently funded the Russian Revolution (and how\nother Wall Street bankers\nfunded\nthe Nazis years later). Leon Trotsky spent\ntime\nin New York prior to the revolution, and propagandistic reporting\nfrom Americans like\nJohn\nReed aided Lenin and Trotsky in their revolution. Indeed, Reed was\nso useful to the Soviets — and so misleading as to the nature of the\nrevolution — that he was\nburied\nat the base of the Kremlin Wall . Surprise: the Russian Revolution\nwasn't done wholly by Russians, but had significant foreign involvement\nfrom Germans and Americans.\n- The Ochs-Sulzberger family, which owns The New York Times Company,\nowned\nslaves but didn't report that fact in their 1619\ncoverage .\n- New York Times correspondent Walter\nDuranty won a Pulitzer\nPrize for helping the Soviet Union starve Ukraine into submission,\n90 years before the Times decided to instead \" stand\nwith Ukraine \".\nYou can find a bunch more juicy examples in the chapter titled,\nappropriately, \" If\nthe News is Fake, Imagine History \". These examples seem haphazard,\nand indeed, to some extent they are so intentionally: the goal is first\nand foremost to shock the reader out of their existing world model so\nthey can start downloading Balaji's own.\nBut pretty soon, Balaji's examples do start to point to some\nparticular themes: a deep dislike of the \"woke\" US left, exemplified by\nthe New York Times, a combination of strong discomfort with the Chinese\nCommunist Party's authoritarianism with an understanding of why the CCP\noften justifiably fears the United States, and an appreciation of the\nlove of freedom of the US right (exemplified by Bitcoin maximalists)\ncombined with a dislike of their hostility toward cooperation and\norder.\nNext, we get Balaji's overview of the\npolitical realignments in recent history , and finally we get to his\ncore model of politics in the present day: NYT, CCP, BTC .\nTeam NYT basically runs the US, and its total lack of competence\nmeans that the US is collapsing. Team BTC (meaning, both actual Bitcoin\nmaximalists and US rightists in general) has some positive values, but\ntheir outright hostility to collective action and order means that they\nare incapable of building anything. Team CCP can build, but they are\nbuilding a dystopian surveillance state that much of the world would not\nwant to live in. And all three teams are waaay too nationalist: they\nview things from the perspective of their own country, and ignore or\nexploit everyone else. Even when the teams are internationalist in\ntheory, their specific ways of interpreting their values make them\nunpalatable outside of a small part of the world.\nNetwork states, in Balaji's view, are a \" de-centralized\ncenter \" that could create a better alternative. They combine the\nlove of freedom of team BTC with the moral energy of team NYT and the\norganization of team CCP, and give us the best benefits of all three\n(plus a level of international appeal greater than any of the\nthree) and avoid the worst parts.\nThis is Balajian megapolitics in a nutshell. It is not trying to\njustify network states using some abstract theory (eg. some Dunbar's\nnumber or concentrated-incentive argument that the optimal size of a\npolitical body is actually in the low tens of thousands). Rather, it is\nan argument that situates network states as a response to the particular\npolitical situation of the world at its current place and time.\nBalaji's helical theory of history: yes, there are cycles,\nbut there is also ongoing progress. Right now, we're at the part of the\ncycle where we need to help the sclerotic old order die, but also seed a\nnew and better one.\nDo\nyou have to agree with Balaji's megapolitics to like network\nstates?\nMany aspects of Balajian megapolitics will not be convincing to many\nreaders. If you believe that \"wokeness\" is an important movement that\nprotects the vulnerable, you may not appreciate the almost off-handed\ndismissal that it is basically just a mask for a professional elite's\nwill-to-power. If you are worried about the plight of smaller countries\nsuch as Ukraine who are threatened by aggressive neighbors and\ndesperately need outside support, you will not be convinced by Balaji's\nplea that \"it may instead be best for countries to rearm, and take\non their own defense\".\nI do think that you can support network states while disagreeing with\nsome of Balaji's reasoning for them (and vice versa). But first, I\nshould explain why I think Balaji feels that his view of the\nproblem and his view of the solution are connected. Balaji has been\npassionate about roughly the same problem for a long time; you can see a\nsimilar narrative outline of defeating US institutional sclerosis\nthrough a technological and exit-driven approach in his speech on \"the\nultimate exit\" from 2013 . Network states are the latest iteration of\nhis proposed solution.\nThere are a few reasons why talking about the problem is\nimportant:\n- To show that network states are the only way to protect\nfreedom and capitalism, one must show why the US cannot. If the\nUS, or the \"democratic liberal order\", is just fine, then there is no\nneed for alternatives; we should just double down on global coordination\nand rule of law. But if the US is in an irreversible decline, and its\nrivals are ascending, then things look quite different. Network states\ncan \"maintain liberal values in an illiberal world\"; hegemony thinking\nthat assumes \"the good guys are in charge\" cannot.\n- Many of Balaji's intended readers are not in the US, and a\nworld of network states would inherently be globally distributed - and\nthat includes lots of people who are suspicious of\nAmerica . Balaji himself is Indian, and has a large Indian fan\nbase. Many people in India, and elsewhere, view the US not as a\n\"guardian of the liberal world order\", but as something much more\nhypocritical at best and sinister at worst. Balaji wants to make it\nclear that you do not have to be pro-American to be a liberal (or at\nleast a Balaji-liberal).\n- Many parts of US left-leaning media are increasingly hostile\nto both cryptocurrency and the tech sector . Balaji expects that\nthe \"authoritarian left\" parts of \"team NYT\" will be hostile to network\nstates, and he explains this by pointing out that the media are not\nangels and their attacks are often self-interested.\nBut this is not the only way of looking at the broader picture. What\nif you do believe in the importance of role of social justice\nvalues, the New York Times, or America? What if you value governance\ninnovation, but have more moderate views on politics? Then, there are\ntwo ways you could look at the issue:\n- Network states as a synergistic strategy, or at least as a\nbackup . Anything that happens in US politics in terms of\nimproving equality , for example, only benefits the ~4% of the\nworld's population that lives in the United States. The First Amendment\ndoes not apply outside US borders. The governance of many wealthy\ncountries is sclerotic, and we do need some way to try\nmore governance innovation. Network states could fill in the gaps.\nCountries like the United States could host network states that attract\npeople from all over the world. Successful network states could even\nserve as a policy model for countries to adopt. Alternatively, what\nif the Republicans win and secure a decades-long majority in 2024,\nor the United States breaks down? You want there to be an\nalternative.\n- Exit to network states as a distraction, or even a\nthreat . If everyone's first instinct when faced with a large\nproblem within their country is to exit to an enclave elsewhere, there\nwill be no one left to protect and maintain the countries themselves.\nGlobal infrastructure that ultimately network states depend on will\nsuffer.\nBoth perspectives are compatible with a lot of disagreement with\nBalajian megapolitics. Hence, to argue for or against Balajian network\nstates, we will ultimately have to talk about network states. My own\nview is friendly to network states, though with a lot of caveats and\ndifferent ideas about how network states could work.\nWhat\ndoes cryptocurrency have to do with network states?\nThere are two kinds of alignment here: there is the\nspiritual alignment, the idea that \"Bitcoin\nbecomes the flag of technology\" , and there is the practical\nalignment, the specific ways in which network states could use\nblockchains and cryptographic tokens. In general, I agree with both of\nthese arguments - though I think Balaji's book could do much more to\nspell them out more explicitly.\nThe spiritual alignment\nCryptocurrency in 2022 is a key standard-bearer for internationalist\nliberal values that are difficult to find in any other social force that\nstill stands strong today. Blockchains and cryptocurrencies are\ninherently global. Most Ethereum developers are outside the US, living\nin far-flung places like Europe, Taiwan and Australia. NFTs have given\nunique opportunities to artists\nin Africa and elsewhere\nin the Global South . Argentinians punch above their weight in\nprojects like Proof of Humanity, Kleros and Nomic Labs.\nBlockchain communities continue to stand for openness, freedom,\ncensorship resistance and credible\nneutrality , at a time where many geopolitical actors are\nincreasingly only serving their own interests. This enhances their\ninternational appeal further: you don't have to love US hegemony to love\nblockchains and the values that they stand for. And this all makes\nblockchains an ideal spiritual companion for the network state vision\nthat Balaji wants to see.\nThe practical alignment\nBut spiritual alignment means little without practical use value for\nblockchains to go along with it. Balaji gives plenty of blockchain use\ncases. One of Balaji's favorite concepts is the idea of the blockchain\nas a \"ledger of record\": people can timestamp events on-chain, creating\na global provable log of humanity's \"microhistory\". He continues with\nother examples:\n- Zero-knowledge\ntechnology like ZCash , Ironfish , and Tornado Cash allow on-chain attestation\nof exactly what people want to make public and nothing more.\n- Naming systems like the Ethereum Name\nService (ENS) and Solana Name\nService (SNS) attach identity to on-chain transactions.\n- Incorporation systems allow the on-chain representation of corporate\nabstractions above the level of a mere transaction, like financial\nstatements or even full programmable company-equivalents like DAOs.\n- Cryptocredentials ,\nNon-Fungible\nTokens (NFTs), Non-Transferable\nFungibles (NTFs), and Soulbounds allow the\nrepresentation of non-financial data on chain, like diplomas or\nendorsements.\nBut how does this all relate to network states? I could go into\nspecific examples in the vein of crypto cities : issuing\ntokens, issuing CityDAO -style\ncitizen NFTs, combining blockchains with zero-knowledge cryptography to\ndo secure privacy-preserving\nvoting , and a lot more. Blockchains are the\nLego of crypto-finance and crypto-governance: they are a very\neffective tool for implementing transparent in-protocol rules to govern\ncommon resources, assets and incentives.\nBut we also need to go a level deeper. Blockchains and\nnetwork states have the shared property that they are both trying to\n\"create a new root\" . A corporation is not a root: if there is a\ndispute inside a corporation, it ultimately gets resolved by a national\ncourt system. Blockchains and network states, on the other hand,\nare trying to be new roots. This does not mean some absolute\n\"na na no one can catch me\" ideal of sovereignty that is perhaps only\ntruly accessible to the ~5 countries that have highly self-sufficient\nnational economies and/or nuclear weapons. Individual blockchain\nparticipants are of course vulnerable to national regulation, and\nenclaves of network states even more so. But blockchains are the only\ninfrastructure system that at least attempts to do ultimate\ndispute resolution at the non-state level (either through on-chain smart\ncontract logic or through the freedom\nto fork ). This makes them an ideal base infrastructure for network\nstates.\nWhat aspects of\nBalaji's vision do I like?\nGiven that a purist \" private\nproperty rights only \" libertarianism inevitably runs into large\nproblems like its inability to fund public goods, any successful\npro-freedom program in the 21st century has to be a hybrid containing at\nleast one Big Compromise Idea that solves at least 80% of the problems,\nso that independent individual initiative can take care of the rest.\nThis could be some stringent measures against economic power and wealth\nconcentration (maybe charge annual Harberger\ntaxes on everything), it could be an 85% Georgist\nland tax , it could be a UBI, it could be mandating that sufficiently\nlarge companies become democratic internally, or one of any other\nproposals. Not all of these work, but you need something that\ndrastic to have any shot at all.\nGenerally, I am used to the Big Compromise Idea being a leftist one:\nsome form of equality and democracy. Balaji, on the other hand, has Big\nCompromise Ideas that feel more rightist: local communities with shared\nvalues, loyalty, religion, physical environments structured to encourage\npersonal discipline (\"keto kosher\") and hard work. These values are\nimplemented in a very libertarian and tech-forward way, organizing not\naround land, history, ethnicity and country, but around the cloud and\npersonal choice, but they are rightist values nonetheless. This style of\nthinking is foreign to me, but I find it fascinating, and important.\nStereotypical \" wealthy\nwhite liberals \" ignore this at their peril: these more \"traditional\"\nvalues are actually quite popular even among some\nethnic minorities in the United States , and even more so in places\nlike Africa and India, which is exactly where Balaji is trying to build\nup his base.\nBut\nwhat about this particular baizuo that's currently writing this review?\nDo network states actually interest me?\nThe \"Keto Kosher\" health-focused lifestyle immersion network state is\ncertainly one that I would want to live in. Sure, I could just spend\ntime in cities with lots of healthy stuff that I can seek out\nintentionally, but a concentrated physical environment makes it so much\neasier. Even the motivational aspect of being around other people who\nshare a similar goal sounds very appealing.\nBut the truly interesting stuff is the governance innovation: using\nnetwork states to organize in ways that would actually not be possible\nunder existing regulations. There are three ways that you can interpret\nthe underlying goal here:\n- Creating new regulatory environments that let their\nresidents have different priorities from the priorities\npreferred by the mainstream: for example, the \"anyone can walk around\nnaked\" zone, or a zone that implements different tradeoffs between\nsafety and convenience, or a zone that legalizes more psychoactive\nsubstances.\n- Creating new regulatory institutions that might be more\nefficient at serving the same priorities as the status quo. For\nexample, instead of improving environmental friendliness by regulating\nspecific behaviors, you could just have a Pigovian tax .\nInstead of requiring licenses and regulatory pre-approval for many\nactions, you could require mandatory\nliability insurance . You could use quadratic voting for\ngovernance and quadratic funding to fund local public goods.\n- Pushing against regulatory conservatism in general ,\nby increasing the chance that there's some jurisdiction that\nwill let you do any particular thing. Institutionalized bioethics, for\nexample, is a notoriously conservative enterprise, where 20 people dead\nin a medical experiment gone wrong is a tragedy, but 200000 people dead\nfrom life-saving\nmedicines and vaccines not being approved quickly enough is a\nstatistic. Allowing people to opt into network states that accept higher\nlevels of risk could be a successful strategy for pushing against\nthis.\nIn general, I see value in all three. A large-scale\ninstitutionalization of [1] could make the word simultaneously more free\nwhile making people comfortable with higher levels of restriction of\ncertain things, because they know that if they want to do something\ndisallowed there are other zones they could go to do it. More generally,\nI think there is an important idea hidden in [1]: while the\n\"social technology\" community has come up with many good ideas around\nbetter governance , and many good ideas around better public discussion , there is a\nmissing emphasis on better social technology for\nsorting . We don't just want to take existing maps of\nsocial connections as given and find better ways to come to consensus\nwithin them. We also want to reform the webs of social connections\nthemselves, and put people closer to other people that are more\ncompatible with them to better allow different ways of life to maintain\ntheir own distinctiveness.\n[2] is exciting because it fixes a major problem in politics: unlike\nstartups, where the early stage of the process looks somewhat like a\nmini version of the later stage, in politics the early stage is a public\ndiscourse game that often selects for very different things than what\nactually work in practice. If governance ideas are regularly implemented\nin network states, then we would move from an\nextrovert-privileging \"talker liberalism\" to a more balanced \"doer\nliberalism\" where ideas rise and fall based on how well they actually do\non a small scale . We could even combine [1] and [2]: have a\nzone for people who want to automatically participate in a new\ngovernance experiment every year as a lifestyle.\n[3] is of course a more complicated moral question: whether you view\nparalysis and creep toward de-facto authoritarian global government as a\nbigger problem or someone inventing an evil technology that dooms us all\nas a bigger problem. I'm generally in the first camp; I am concerned\nabout the prospect of both\nthe West and China settling into a kind of low-growth conservatism ,\nI love how imperfect coordination between nation states limits\nthe enforceability of things like global copyright law, and I'm\nconcerned about the possibility that, with future surveillance\ntechnology, the world as a whole will enter a highly self-enforcing but\nterrible political equilibrium that it cannot get out of. But there are\nspecific areas (cough cough, unfriendly\nAI risk ) where I am in the risk-averse camp ... but here we're already\ngetting into the second part of my reaction.\nWhat\naspects of Balaji's vision do I take issue with?\nThere are four aspects that I am worried about the most:\n- The \"founder\" thing - why do network states need a recognized\nfounder to be so central?\n- What if network states end up only serving the wealthy?\n- \"Exit\" alone is not sufficient to stabilize global politics. So if\nexit is everyone's first choice, what happens?\n- What about global negative externalities more generally?\nThe \"founder\" thing\nThroughout the book, Balaji is insistent on the importance of\n\"founders\" in a network state (or rather, a startup society :\nyou found a startup society, and become a network state if you are\nsuccessful enough to get diplomatic recognition). Balaji explicitly\ndescribes startup society founders as being \"moral entrepreneurs\":\nThese presentations are similar to startup pitch decks. But as the\nfounder of a startup society, you aren't a technology entrepreneur\ntelling investors why this new innovation is better, faster, and\ncheaper. You are a moral entrepreneur telling potential future citizens\nabout a better way of life, about a single thing that the broader world\nhas gotten wrong that your community is setting right.\nFounders crystallize moral intuitions and learnings\nfrom history into a concrete philosophy, and people whose moral\nintuitions are compatible with that philosophy coalesce around the\nproject. This is all very reasonable at an early stage - though it is\ndefinitely not the only approach for how a startup society\ncould emerge. But what happens at later stages? Mark Zuckerberg being\nthe centralized founder of facebook the startup was perhaps necessary.\nBut Mark Zuckerberg being in charge of a multibillion-dollar (in fact,\nmultibillion- user ) company is something quite different. Or,\nfor that matter, what about Balaji's nemesis: the fifth-generation\nhereditary white Ochs-Sulzberger dynasty running the New York Times?\nSmall things being centralized is great, extremely large things being\ncentralized is terrifying. And given the reality of network effects, the\nfreedom to exit again is not sufficient. In my view, the problem of how\nto settle into something other than founder control is important, and\nBalaji spends too little effort on it. \"Recognized founder\" is baked\ninto the definition of what a Balajian network state is, but a roadmap\ntoward wider participation in governance is not. It should be.\nWhat about everyone who\nis not wealthy?\nOver the last few years, we've seen many instances of governments\naround the world becoming explicitly more open to \"tech talent\". There\nare 42\ncountries offering digital nomad visas , there is a French\ntech visa , a similar\nprogram in Singapore , golden visas for Taiwan , a\nprogram for Dubai ,\nand many others. This is all great for skilled professionals and rich\npeople. Multimillionaires fleeing China's tech crackdowns and covid\nlockdowns (or, for that matter, moral disagreements with China's other\npolicies ) can often escape the\nworld's systemic discrimination against Chinese and other\nlow-income-country citizens by spending a few hundred thousand\ndollars on buying\nanother passport . But what about regular people? What about the Rohingya minority\nfacing extreme conditions in Myanmar , most of whom do not have a way\nto enter the US or Europe, much less buy another passport?\nHere, we see a potential tragedy of the network state concept. On the\none hand, I can really see how exit can be the most viable strategy for\nglobal human rights protection in the twenty first century. What do you\ndo if another country is oppressing an ethnic minority? You could do\nnothing. You could sanction them (often ineffective\nand ruinous\nto the very people you're trying to help). You could try to invade (same\ncriticism but even worse). Exit is a more humane option. People\nsuffering human rights atrocities could just pack up and leave for\nfriendlier pastures, and coordinating to do it in a group would mean\nthat they could leave without sacrificing the communities they depend on\nfor friendship and economic livelihood. And if you're wrong and the\ngovernment you're criticizing is actually not that oppressive, then\npeople won't leave and all is fine, no starvation or bombs required.\nThis is all beautiful and good. Except... the whole thing breaks down\nbecause when the people try to exit, nobody is there to take them.\nWhat is the answer? Honestly, I don't see one. One point in favor of\nnetwork states is that they could be based in poor countries,\nand attract wealthy people from abroad who would then help the local\neconomy. But this does nothing for people in poor countries who want\nto get out . Good old-fashioned political action within existing\nstates to liberalize immigration laws seems like the only option.\nNowhere to run\nIn the wake of Russia's invasion of Ukraine on Feb 24, Noah Smith\nwrote an important\npost on the moral clarity that the invasion should bring to our\nthought. A particularly striking section is titled \"nowhere to run\".\nQuoting:\nBut while exit works on a local level — if San Francisco is too\ndysfunctional, you can probably move to Austin or another tech town — it\nsimply won't work at the level of nations. In fact, it never really did\n— rich crypto guys who moved to countries like Singapore or territories\nlike Puerto Rico still depended crucially on the infrastructure and\ninstitutions of highly functional states. But Russia is making it even\nclearer that this strategy is doomed, because eventually there is\nnowhere to run. Unlike in previous eras, the arm of the great powers is\nlong enough to reach anywhere in the world.\nIf the U.S. collapses, you can't just move to Singapore, because in a\nfew years you'll be bowing to your new Chinese masters. If the U.S.\ncollapses, you can't just move to Estonia, because in a few years\n(months?) you'll be bowing to your new Russian masters. And those\nmasters will have extremely little incentive to allow you to remain a\nfree individual with your personal fortune intact ... Thus it is very very\nimportant to every libertarian that the U.S. not collapse.\nOne possible counter-argument is: sure, if Ukraine was full of people\nwhose first instinct was exit, Ukraine would have collapsed. But if\nRussia was also more exit-oriented , everyone in Russia would\nhave pulled out of the country within a week of the invasion. Putin\nwould be left standing alone in the fields of the Luhansk oblast facing\nZelensky a hundred meters away, and when Putin shouts his demand for\nsurrender, Zelensky would reply: \"you and what army\"? (Zelensky would of\ncourse win a fair one-on-one fight)\nBut things could go a different way. The risk is that exitocracy\nbecomes recognized as the primary way you do the \"freedom\"\nthing , and societies that value freedom will become exitocratic,\nbut centralized states will censor and suppress these impulses, adopt a\nmilitaristic attitude of national unconditional loyalty, and run\nroughshod over everyone else.\nSo what about those\nnegative externalities?\nIf we have a hundred much-less-regulated innovation labs everywhere\naround the world, this could lead to a world where harmful things are\nmore difficult to prevent. This raises a question: does\nbelieving in Balajism require believing in a world where\nnegative externalities are not too big a deal? Such a\nviewpoint would be the opposite of the Vulnerable\nWorld Hypothesis (VWH) , which suggests that are technology\nprogresses, it gets easier and easier for one or a few crazy people to\nkill millions, and global authoritarian surveillance might be\nrequired to prevent extreme suffering or even extinction.\nOne way out might be to focus on self-defense technology. Sure, in a\nnetwork state world, we could not feasibly ban gain-of-function\nresearch, but we could use network states to help the world along a path\nto adopting really good HEPA air\nfiltering , far-UVC\nlight , early detection infrastructure and a very rapid\nvaccine development and deployment pipeline that could defeat not only\ncovid, but far worse viruses too. This\n80,000 hours episode outlines the bull case for bioweapons being a\nsolvable problem. But this is not a universal solution for all\ntechnological risks: at the very least, there is no self-defense against\na super-intelligent unfriendly AI that kills us all.\nSelf-defense technology is good, and is probably an undervalued\nfunding focus area. But it's not realistic to rely on that alone.\nTransnational cooperation to, for example, ban\nslaughterbots , would be required. And so we do want a world where,\neven if network states have more sovereignty than intentional\ncommunities today, their sovereignty is not absolute .\nNon-Balajian network states\nReading The Network State reminded me of a different book\nthat I read ten years ago: David de Ugarte's Phyles: Economic Democracy\nin the Twenty First Century . Phyles talks about\nsimilar ideas of transnational communities organized around values, but\nit has a much more left-leaning emphasis: it assumes that these\ncommunities will be democratic, inspired by a combination of 2000s-era\nonline communities and nineteenth and twentieth-century ideas of\ncooperatives and workplace democracy.\nWe can see the differences most clearly by looking at de Ugarte's\ntheory of formation. Since I've already spent a lot of time quoting\nBalaji, I'll give de Ugarte a fair hearing with a longer quote:\nThe very blogosphere is an ocean of identities and conversation in\nperpetual cross-breeding and change from among which the great social"}
{"url":"https://docs.squads.so/main/basics/welcome-to-squads-multisig.md","domain":"docs.squads.so","title":"Welcome to Squads Multisig","hash":"e0d8b8246752ce22178ef0301e5fb2fdcdb8fe52e495f01a5e5fd0370103b444","tokens":971,"chars":3882,"crawler":"crawler-f6nn","verified":"exact","ts":1791172094804,"text":"> For the complete documentation index, see [llms.txt](https://docs.squads.so/main/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.squads.so/main/basics/welcome-to-squads-multisig.md).\n# Welcome to Squads Multisig\nLearn more about Squads and Squads Protocol.\n### About 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* Treasury;\n* Program upgrade authorities;\n* Admin keys;\n* Tokens;\n* and 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* User 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* Security - 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* Transparency - 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.\n### Squads 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.\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.squads.so/main/basics/welcome-to-squads-multisig.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://bitcoinops.org/en/newsletters/2026/06/19/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #410 | Bitcoin Optech","hash":"57fcb287d402a141bf6cdf716ac47eec6f093017e4ee31c74c81457e52c33abd","tokens":1783,"chars":7131,"crawler":"crawler-f6nn","verified":"exact","ts":1791172096970,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #410\nJun 19, 2026\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.\nNews\n-\n● Discussion of removing RBF signaling from wallet transactions : rkrux\nposted to the Bitcoin-Dev mailing list proposing that wallets\nstop signaling opt-in RBF in the transactions they create. A\ntransaction signals replaceability under BIP125 when at least one of its\ninputs sets nSequence below MAX-1 (where MAX is 0xffffffff ). That\nsignal no longer affects whether a transaction can be replaced since full RBF\nbecame the default (see Newsletter #315 ) and the\nmempoolfullrbf opt-out was removed (see Newsletter #329 ).\nNodes using Bitcoin Core’s default policy will replace any transaction\nregardless of its nSequence values. Signaling now serves mainly to\nfingerprint the wallet that created the transaction, so the post argued that\nwallets should converge on a single value.\nrkrux opened Bitcoin Core #35405 to stop the Bitcoin Core wallet from\nsignaling by default, using nSequence = MAX-1 , and asked other wallet\nauthors which value they could standardize on. Murch and Electrum Wallet\ncontributor SomberNight pointed out that MAX-2 is already the dominant\nvalue, used by about 75% of transactions according to\nmainnet-observer and by nearly all Electrum Wallet\ntransactions. Because most transactions still signal, moving Bitcoin Core to a\nnon-signaling MAX-1 would make its transactions stand out rather than blend\nin, so both favored converging on MAX-2 instead. rkrux closed the PR in\nlight of that feedback.\nChanges to services and client software\nIn this monthly feature, we highlight interesting updates to Bitcoin\nwallets and services.\n-\n● Sparrow Wallet 2.5.0 adds silent payments receiving:\nSparrow 2.5.0 adds silent payments\nreceiving wallets, including airgapped hardware wallet signers, building on\nthe send support added in 2.3.0 (see Newsletter #377 ).\n-\n● Bark live on Bitcoin mainnet:\nSecond announced that Bark, its Ark protocol\nimplementation, is now running on Bitcoin mainnet, with a public Ark server\nplus the Bark SDK and barkd daemon for developers. Bark previously launched\non signet (see Newsletter #346 ).\n-\n● Arké Ark wallet announced:\nArké is a native iOS wallet integrating the Ark protocol\nwith onchain ( BDK ) and Lightning payments, displaying transactions\nfrom all three layers in a single combined history. It currently runs on\nsignet with mainnet pending.\n-\n● Noah Ark wallet announced:\nNoah is a cross-platform mobile wallet built on the Ark\nprotocol with Lightning support and a trust-minimized design. It is currently\nin beta.\n-\n● Alby Hub v1.23.0 released:\nAlby Hub v1.23.0 adds just-in-time channels that open automatically to accept incoming payments and an\nexperimental Ark payment backend, among other improvements.\n-\n● JoinMarket NG 0.32.0 released:\nJoinMarket-NG, a community-maintained fork of the coinjoin\nimplementation, released mempool support for the\nNeutrino backend so takers can verify maker\nbroadcasts, among other fidelity bond and reliability improvements.\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 #35221 adds support for the BIP434 peer feature\nnegotiation framework (see Newsletters #386 and\n#390 ). It adds a feature P2P message that may be\nexchanged between version and verack to advertise optional peer\nfeatures, and bumps the P2P protocol version number to 70017 . Bitcoin\nCore currently implements the negotiation mechanism, ignores unknown valid\nfeature IDs, and disconnects peers that send malformed feature messages,\nsend them after verack , or send them without negotiating a compatible\nprotocol version. It does not yet advertise any specific optional feature.\n-\n● Bitcoin Core #35254 wipes additional key-derivation material from memory\nafter use. CHMAC_SHA256 and CHMAC_SHA512 now cleanse their temporary\nrkey and inner-hash temp stack buffers, which may contain data derived\nfrom BIP32 chain codes or BIP324\nHKDF key material. The type of ChainCode has been changed from a uint256\ntypedef to a type with a memory_cleanse() destructor, wiping BIP32\nchain codes in extended keys and local variables when those objects are\ndestroyed.\n-\n● Bitcoin Core #35498 fixes a race condition in the FetchBlock RPC path\nwhen requesting a block from a peer that is disconnecting. FetchBlock could\nobtain a valid peer reference before locking cs_main , but peer cleanup\ncould remove the peer’s CNodeState before BlockRequested() recorded the\nrequest, causing an assertion failure. The fix locks cs_main before looking\nup the peer, ensuring that the peer’s state cannot be removed while the block\nrequest is registered.\n-\n● Eclair #3318 fixes a splicing reconnection edge case\nwhere Eclair could update its local state for a newly locked splice funding\ntransaction without sending splice_locked . This could happen after Eclair\nsent channel_reestablish but before it received the peer’s\nchannel_reestablish , leaving the peers out of sync about which funding\nstates require commit_sig messages and causing a force-close. Eclair now\nhandles funding lock events while reconnecting and sends splice_locked when\nneeded.\n-\n● LND #10789 lays the groundwork for implementing BOLT12 offers : a daemon-independent bolt12 codec package with an Offer message\ntype and supporting lnwire TLV infrastructure. The new codec validates\nmessages before encoding, keeps low-level decoding permissive for diagnostics\nand fuzzing, and preserves unknown signed-range TLVs so offer_id remains\nstable across decode and re-encode.\n-\n● Rust Bitcoin #6321 hardens segwit witness decoding to\nprevent attacker-controlled element counts from causing excessive memory\nallocation. Previously, a few bytes of input could claim a large witness\nstack and force an allocation of about 16 MB for witness index space. The new\ndecoder appends the received witness bytes to its content buffer and builds\nthe element index in end() after decoding the witness data, removing the\nold batched allocation path.\n-\n● LDK #4685 moves the nonce used for BOLT12 invoice\nverification back into payer metadata of the invoice request or refund. The\nnonce had previously been removed because it was also stored in the blinded\nreply-path OffersContext , but that made verifying an\ninvoice depend on state outside the invoice request or refund itself, which\nis incompatible with upcoming BOLT12 payment proofs (see Newsletter #405 ). Outbound offer and refund\nreply-path contexts now only store the expected PaymentId , which is checked\nagainst the payment ID recovered from the payer metadata of the received\ninvoice."}
{"url":"https://docs.ens.domains/ensv2/indexing","domain":"docs.ens.domains","title":"Indexing ENSv2 | ENS Docs","hash":"d420872cc1028b0ba6e95b96f828f6fbdb7ab5d05456b5bdd3a90119e7af2706","tokens":5813,"chars":23250,"crawler":"crawler-f6nn","verified":"exact","ts":1791172099705,"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\nIndexing ENSv2\nThis page describes the ENSv2 contract events and functions relevant to building an indexer. It covers the full lifecycle of names - registration, transfer, renewal, subname creation, resolver record changes, record linking, and role management.\nContract Hierarchy\nENSv2 uses a hierarchical registry model. There is no single registry contract that holds all names. Instead:\nRootRegistry (PermissionedRegistry)\n└── ETHRegistry (PermissionedRegistry) — manages *.eth\n├── name.eth (token in ETHRegistry)\n│ └── UserRegistry — manages *.name.eth\n│ ├── sub.name.eth (token in UserRegistry)\n│ │ └── UserRegistry — manages *.sub.name.eth\n│ │ └── ...\n│ └── ...\n└── ...\nEach registry is a Permissioned Registry (or UserRegistry for subnames), implementing IRegistry , IStandardRegistry , IPermissionedRegistry , and IEnhancedAccessControl . Tokens are ERC1155Singleton (one token per name).\nResolvers are separate contracts ( Permissioned Resolver ) deployed per-account as UUPS proxies. All names owned by the same account share one resolver. Names on the same resolver can also share records via record links ( linkToNode / linkToRecord ).\nRegistry Events\nThese events are emitted by any registry contract (PermissionedRegistry / UserRegistry).\nRegistryCreated\nevent RegistryCreated ();\nEmitted once per registry: by PermissionedRegistry in the constructor, and by UserRegistry / WrapperRegistry on initialize() . Allows indexers to discover new registry deployments on-chain.\nLabelRegistered\nevent LabelRegistered (\nuint256 indexed tokenId ,\nbytes32 indexed labelHash ,\nstring label ,\naddress owner ,\nuint64 expiry ,\naddress indexed sender\n);\nEmitted by: IRegistryEvents (on PermissionedRegistry, UserRegistry)\nWhen: a new name is registered via register() . The full name is constructed by appending the parent name (e.g., label \"test\" under ETHRegistry = \"test.eth\" ). The registry contract address that emitted this event identifies which level of the hierarchy this name belongs to.\nThe sender parameter is the account that called register() . For normal .eth registrations this is the ETHRegistrar; for names migrated from ENSv1 it is a migration controller, since migration bypasses the registrar and calls register() on the ETHRegistry directly. Checking sender against the known migration controller addresses is how an indexer distinguishes migrated names from fresh registrations.\nLabelReserved\nevent LabelReserved (\nuint256 indexed tokenId ,\nbytes32 indexed labelHash ,\nstring label ,\nuint64 expiry ,\naddress indexed sender\n);\nEmitted by: IRegistryEvents (on PermissionedRegistry)\nWhen: a name is reserved via register() with owner = address(0) and roleBitmap = 0 . No token is minted and no owner is set. A reserved name can be promoted to REGISTERED by calling register() again with a real owner, which requires ROLE_REGISTER_RESERVED .\nLabelUnregistered\nevent LabelUnregistered ( uint256 indexed tokenId , address indexed sender );\nEmitted by: IRegistryEvents (on PermissionedRegistry, UserRegistry)\nWhen: a name is explicitly deleted via unregister() , which works on both REGISTERED and RESERVED names. The expiry is set to block.timestamp , and if a token exists it is burned. Unregistering a RESERVED name burns nothing, since no token was ever minted.\nExpiryUpdated\nevent ExpiryUpdated ( uint256 indexed tokenId , uint64 indexed newExpiry , address indexed sender );\nEmitted by: IRegistryEvents (on PermissionedRegistry, UserRegistry)\nWhen: a name's expiry is extended via renew() on the registry.\nSubregistryUpdated\nevent SubregistryUpdated (\nuint256 indexed tokenId ,\nIRegistry indexed subregistry ,\naddress indexed sender\n);\nEmitted by: IRegistryEvents (on PermissionedRegistry, UserRegistry)\nWhen: a name's child registry is set or changed via setSubregistry() . This also fires during register() if a subregistry is provided. New subregistry addresses indicate dynamically deployed UserRegistry contracts for subnames.\nResolverUpdated\nevent ResolverUpdated ( uint256 indexed tokenId , address indexed resolver , address indexed sender );\nEmitted by: IRegistryEvents (on PermissionedRegistry, UserRegistry)\nWhen: a name's resolver is set or changed via setResolver() . Also fires during register() if a resolver is provided. New resolver addresses indicate dynamically deployed PermissionedResolver contracts.\nTokenRegenerated\nevent TokenRegenerated ( uint256 indexed oldTokenId , uint256 indexed newTokenId );\nEmitted by: IRegistryEvents (on PermissionedRegistry, UserRegistry)\nWhen: a name's EAC roles are modified via grantRoles() or revokeRoles() . The ERC1155 token ID changes (its version counter increments), while the underlying name (canonical ID / resource) remains the same. Always accompanied by ERC1155 TransferSingle events (burn old + mint new). See Mutable Token IDs for details.\nParentUpdated\nevent ParentUpdated ( IRegistry indexed parent , string label , address indexed sender );\nEmitted by: IRegistryEvents (on PermissionedRegistry, UserRegistry)\nWhen: a registry's parent reference is set via setParent() . This establishes the upward link in the registry hierarchy, complementing SubregistryUpdated (which links parent → child) by establishing the child → parent direction.\nsetParent() is an optional, separately-permissioned call ( ROLE_SET_PARENT ), so this event is not emitted for every child registry and getParent() may return empty for registries where it was never called. Treat SubregistryUpdated (emitted by the parent) as the authoritative parent → child link, and use ParentUpdated / getParent() only as a supplementary child → parent hint when present.\nTokenResource\nevent TokenResource ( uint256 indexed tokenId , uint256 indexed resource );\nEmitted by: IPermissionedRegistry\nWhen: a token is created during registration ( register() ). Maps a tokenId to its corresponding resource . It is not re-emitted on token regeneration: the resource is derived from the labelHash and eacVersionId , so it stays stable across role-change regenerations (which only bump the tokenVersionId ), and you should carry it onto the new tokenId by following TokenRegenerated rather than expecting a fresh TokenResource . The resource does change on re-registration (which increments eacVersionId ), at which point the new register() emits a fresh TokenResource . See Mutable Token IDs for details.\nURIUpdated\nevent URIUpdated ( string uri , address renderer , address indexed sender );\nEmitted by: IRegistryEvents\nWhen: the registry's ERC1155 metadata configuration changes via setURI(uri, renderer) (requires ROLE_SET_URI on ROOT_RESOURCE ). This is registry-wide token metadata, not per-name state.\nERC1155 Transfer Events\nThese standard ERC1155 events are emitted by all registries (which extend ERC1155Singleton).\nTransferSingle\nevent TransferSingle (\naddress indexed operator ,\naddress indexed from ,\naddress indexed to ,\nuint256 id ,\nuint256 value\n);\nWhen:\n- Registration (mint): from = address(0) , to = owner - a new name token is minted\n- Transfer: from = previousOwner , to = newOwner - ownership changes via safeTransferFrom()\n- Unregistration (burn): from = owner , to = address(0) - name token is burned\n- Token regeneration: two events fire - burn old tokenId + mint new tokenId. Correlate with TokenRegenerated to avoid treating it as a separate domain.\nTransferBatch\nevent TransferBatch (\naddress indexed operator ,\naddress indexed from ,\naddress indexed to ,\nuint256 [] ids ,\nuint256 [] values\n);\nWhen: batch transfers of multiple name tokens. Same semantics as TransferSingle but for multiple tokens at once.\nRegistrar Events\nThese events are emitted by the ETH Registrar contract, which is the user-facing entry point for .eth name registration (with commit-reveal and pricing).\nCommitmentMade\nevent CommitmentMade ( bytes32 commitment );\nEmitted by: IETHRegistrar\nWhen: step 1 of the commit-reveal registration via commit() . The commitment hash can be matched to the subsequent registration.\nNameRegistered (Registrar)\nevent NameRegistered (\nuint256 indexed tokenId ,\nstring label ,\naddress owner ,\nIRegistry subregistry ,\naddress resolver ,\nuint64 duration ,\nIERC20 paymentToken ,\nbytes32 indexed referrer ,\nuint256 base ,\nuint256 premium\n);\nEmitted by: IETHRegistrar\nWhen: step 2 of the commit-reveal registration via register() . This is distinct from the registry's LabelRegistered event. The registrar emits its own event with pricing information, and the underlying ETHRegistry also emits LabelRegistered .\nNameRenewed\nevent NameRenewed (\nuint256 indexed tokenId ,\nstring label ,\nuint64 duration ,\nuint64 newExpiry ,\nIERC20 paymentToken ,\nbytes32 indexed referrer ,\nuint256 amount\n);\nEmitted by: IETHRenewer , implemented by both the ETH Registrar and ETHRenewerV1 (which renews not-yet-migrated names during the migration and emits this event from its own address)\nWhen: a .eth name is renewed via renew() or renewBatch() (one event per name). The renewer also calls renew() on the ETHRegistry, which emits ExpiryUpdated .\nResolver Events\nThese events are emitted by Permissioned Resolver contracts. Record values live in numbered record bundles , so the record events are keyed by recordId , not by name. Which names a record serves is a separate event stream: Linked associates a node (namehash) with a recordId . An indexer therefore maintains two tables, record contents (from the *Updated events) and name-to-record links (from Linked ), and joins them at query time.\nLinked\nevent Linked ( uint256 indexed recordId , bytes32 indexed node , bytes name );\nWhen: a name is associated with a record: on the first write to a name (the resolver auto-creates a record and links it) and on explicit linkToNode / linkToRecord calls. name is DNS-encoded and node is its namehash. recordId = 0 means the name was unlinked. The record linked to the root name (node bytes32(0) ) serves as the default record for names without a link of their own.\nResolverCreated\nevent ResolverCreated ();\nWhen: the resolver proxy is initialized, marking a new resolver instance (see Dynamic Contract Discovery ).\nAddressUpdated\nevent AddressUpdated ( uint256 indexed recordId , uint256 coinType , bytes addressBytes );\nWhen: an address record is set via setAddress(name, coinType, addressBytes) . coinType = 60 is ETH. Other coin types follow SLIP-44 (e.g., 0 = BTC, 501 = SOL).\nTextUpdated\nevent TextUpdated ( uint256 indexed recordId , string indexed keyHash , string key , string value );\nWhen: a text record is set via setText(name, key, value) . keyHash is an indexed copy of key (the topic holds its keccak hash), so specific keys can be filtered without decoding the data. Common keys: avatar , url , description , com.twitter , com.github , email , etc.\nDataUpdated\nevent DataUpdated ( uint256 indexed recordId , string indexed keyHash , string key , bytes value );\nWhen: a raw data record is set via setData(name, key, value) , the byte-valued counterpart of text records.\nContenthashUpdated\nevent ContenthashUpdated ( uint256 indexed recordId , bytes hash );\nWhen: a content hash is set via setContenthash(name, hash) . Supports IPFS, Arweave, Swarm, etc.\nABIUpdated\nevent ABIUpdated ( uint256 indexed recordId , uint256 indexed contentType );\nWhen: an ABI record is set via setABI(name, contentType, data) . The data itself is not in the event.\nNameUpdated\nevent NameUpdated ( uint256 indexed recordId , string primaryName );\nWhen: a primary (reverse) name record is set via setName(name, primaryName) .\nInterfaceUpdated\nevent InterfaceUpdated ( uint256 indexed recordId , bytes4 indexed interfaceId , address implementer );\nWhen: an EIP-165 interface implementer is set via setInterface(name, interfaceId, implementer) .\nResourceArgument\nevent ResourceArgument ( uint256 indexed resource , bytes arg );\nWhen: a role is granted on an argument-scoped EAC resource that currently has no assignees. It publishes the preimage ( arg , e.g. the text key or coin type) of the resource hash, letting indexers label resources. It can fire more than once for the same resource.\nThe resolver interface also declares Cleared(uint256 indexed recordId) , which the current implementation never emits.\nRole Events\nEACRolesChanged\nevent EACRolesChanged (\nuint256 indexed resource ,\naddress indexed account ,\nuint256 oldRoleBitmap ,\nuint256 newRoleBitmap\n);\nEmitted by: every contract inheriting Enhanced Access Control , which includes both registries and resolvers .\nWhen: the roles of account on resource change. On registries this fires:\n- at creation, for each initial root grant (in the constructor , or in initialize() for proxy-deployed registries)\n- on every registration that passes a nonzero role bitmap, when the new owner's roles are granted (always the case for ETH Registrar registrations)\n- on grantRoles() / revokeRoles() , which also trigger TokenRegenerated\n- on grantRootRoles() / revokeRootRoles() , which never regenerate\n- twice per token transfer, when all roles move from the old owner to the new owner (a revoke followed by a grant, no regeneration)\nOnly grantRoles() / revokeRoles() regenerate the token, so an EACRolesChanged cannot be assumed to pair with a TokenRegenerated . On resolvers the event fires via initialize() , grantSetterRoles() , and the inherited revokeRoles() / grantRootRoles() / revokeRootRoles() (plain grantRoles() is disabled on resolvers and always reverts).\nKey Concepts for Indexers\nDynamic Contract Discovery\nAn indexer cannot know all contract addresses at startup. The core pattern is:\n- Start by watching the RootRegistry and ETHRegistry (known addresses from deployment).\n- When a SubregistryUpdated event fires with a new subregistry address, add that address to the watch list.\n- When a ResolverUpdated event fires with a new resolver address, add that address to the watch list for resolver events.\nThis creates a self-expanding set of monitored contracts.\nLink-time discovery has a blind spot: anything a registry or resolver emits before it is linked (its RegistryCreated or ResolverCreated , the initial EACRolesChanged root grant from initialize() , or records set before linking) predates the discovery point. Since registries and resolvers are deployed as proxies through the Verifiable Factory , which emits ProxyDeployed(sender, proxy, salt, implementation) , watching the factory address discovers contracts at deployment time instead and closes that gap.\nNote the log order inside a deployment transaction: deployProxy() calls initialize() on the new proxy before emitting ProxyDeployed . For a UserRegistry deployment the sequence is Upgraded → RegistryCreated → EACRolesChanged → ProxyDeployed . An indexer that discovers a contract from ProxyDeployed must therefore also process the earlier logs of that same transaction.\nThe implementation contracts behind the proxies ( UserRegistryImpl , WrapperRegistryImpl , PermissionedResolverImpl ) each also emitted one of these events, from their constructors at deployment. They are shared logic targets, not usable instances, so a registry/resolver list built purely from creation events contains these three extra addresses. Discovery via ProxyDeployed is unaffected.\nTokenId vs Resource (Canonical ID)\n- tokenId : the ERC1155 token ID. Changes when roles are modified ( TokenRegenerated ), because it embeds a version counter that increments on each change.\n- resource : the EAC permission key for a name within a registry. Derived from the labelHash and eacVersionId . Stable across role modifications, but changes on re-registration (when eacVersionId increments).\nUse the TokenResource event (emitted at registration) to establish the tokenId → resource mapping, and follow TokenRegenerated to move that mapping onto the new tokenId when roles change, since no new TokenResource is emitted then. The resource should be the primary key for domain lookups, as it stays stable across regenerations.\nName Construction\nThe indexer must track the registry hierarchy to construct full names:\n- ETHRegistry emits LabelRegistered with label = \"test\" → full name is \"test.eth\"\n- A SubregistryUpdated on test.eth points to a UserRegistry at address 0xABC\n- That UserRegistry emits LabelRegistered with label = \"sub\" → full name is \"sub.test.eth\"\nThe indexer must map each registry address to its parent name to build the complete DNS name.\nShared Subregistries\nMultiple parent names can point to the same subregistry via setSubregistry() . For example:\n- sub1.sub2.parent.eth has subregistry at 0xABC\n- linked.parent.eth also has subregistry at 0xABC\nChildren registered in 0xABC appear under both parents. The token wallet in registry 0xABC is simultaneously wallet.sub1.sub2.parent.eth and wallet.linked.parent.eth - they share the same tokenId.\nRecords and Linking\nRecord storage is a resolver-level concept, decoupled from names:\n- Values live in numbered record bundles, and record events fire under recordId\n- Linked(recordId, node, name) associates names with records, and one record can be linked from any number of names\n- A name with no record link of its own resolves via the default record , the one linked to the root name (node bytes32(0) )\n- Linked with recordId = 0 unlinks a name\nTwo consequences for record indexing: a single *Updated event can change the effective records of many names at once (every name linked to that record, and every unlinked name if it is the default record), and resolving a name requires the join: node to recordId (latest Linked , falling back to the default record), then recordId to values. Indexed record rows are per-record, not per-name; apply the link mapping before treating them as what a name resolves to.\nRegistration Status\nNames can be in one of three states (from IPermissionedRegistry.Status ):\nStatus Value Description\nAVAILABLE 0 Name can be registered\nRESERVED 1 Name is reserved (cannot be registered until expiry, unless caller has ROLE_REGISTER_RESERVED )\nREGISTERED 2 Name is actively registered with an owner\nAfter expiry, names return to AVAILABLE . Re-registration creates both a new tokenId and a new resource (both version counters increment).\nFor .eth names, the ETH Registrar adds a grace period on top of the registry status: GRACE_PERIOD is an immutable constructor parameter, and while it runs an expired name cannot be re-registered but can still be renewed. No event marks entering or leaving grace (or the premium window that follows), so .eth availability must be computed client-side from the expiry, the grace constant, and the current time. A plain \"expired means available\" check is wrong for .eth names in grace.\nEvent Processing Order\nFor a single registration via ETHRegistrar.register() , events fire in this order. The registrar calls ETHRegistry.register() first (which emits all the registry events) and only then emits its own event, so NameRegistered comes last , not first:\n- IRegistryEvents.LabelRegistered - registry-level event with registration details\n- TransferSingle (mint) - ERC1155 token creation\n- TokenResource - tokenId-to-resource mapping\n- EACRolesChanged - the owner's initial roles on the name (always fires on this path)\n- SubregistryUpdated - if a subregistry was provided\n- ResolverUpdated - if a resolver was provided\n- IETHRegistrar.NameRegistered - registrar-level event with pricing\nFor a direct IStandardRegistry.register() call (e.g., on a UserRegistry):\n- IRegistryEvents.LabelRegistered\n- TransferSingle (mint)\n- TokenResource\n- EACRolesChanged - if a nonzero role bitmap was passed\n- SubregistryUpdated - if a subregistry was provided\n- ResolverUpdated - if a resolver was provided\nFor a name migrated from ENSv1 , the migration controllers call register() on the ETHRegistry directly, so only the registry sequence fires: there is no CommitmentMade and no registrar NameRegistered , and LabelRegistered.sender is the migration controller.\nOne more same-transaction caveat: re-registering an expired name whose token was never unregistered emits a burn TransferSingle for the old token ID before LabelRegistered , so a burn does not always mean unregistration or regeneration.\nContract Address Summary\nContract Role Events to Watch\nPermissionedRegistry (ETHRegistry) Manages .eth names All IRegistry events, TokenResource , ERC1155 transfers, EACRolesChanged\nPermissionedRegistry (RootRegistry) Manages TLDs Same as above\nUserRegistry Manages subnames (dynamically deployed) Same as above\nETHRegistrar User-facing .eth registration CommitmentMade , NameRegistered , NameRenewed\nPermissionedResolver Stores resolver records (dynamically deployed) Linked , ResolverCreated , AddressUpdated , TextUpdated , DataUpdated , ContenthashUpdated , ABIUpdated , NameUpdated , InterfaceUpdated , ResourceArgument , EACRolesChanged\nVerifiableFactory Deploys registry/resolver proxies ProxyDeployed\nRead Functions for State Verification\nThese view functions are useful for verifying indexed state or backfilling data:\nRegistry State\n// Get full state of a name (status, expiry, owner, tokenId, resource)\nfunction getState ( uint256 anyId ) external view returns ( State memory );\n// Get the subregistry for a label\nfunction getSubregistry ( string calldata label ) external view returns ( IRegistry );\n// Get the resolver for a label\nfunction getResolver ( string calldata label ) external view returns ( address );\n// Get the owner of a token\nfunction ownerOf ( uint256 tokenId ) external view returns ( address );\n// Get the owner of a name by any of its IDs\nfunction getOwner ( uint256 anyId ) external view returns ( address );\n// Get the stable resource ID\nfunction getResource ( uint256 anyId ) external view returns ( uint256 );\n// Get the current tokenId (may change after role modifications)\nfunction getTokenId ( uint256 anyId ) external view returns ( uint256 );\n// Get the expiry\nfunction getExpiry ( uint256 anyId ) external view returns ( uint64 );\nRegistrar State\n// Check if a name is available for registration\nfunction isAvailable ( string memory label ) external view returns ( bool );\n// Get the registration price\n// (reverts NameNotAvailable if the name is not registerable)\nfunction getRegisterPrice (\nstring memory label ,\nuint64 duration ,\nIERC20 paymentToken\n) external view returns ( uint256 base , uint256 premium );\n// Get the renewal price, the total amount of paymentToken\n// (reverts NameNotRenewable if the name is not renewable)\nfunction getRenewPrice (\nstring memory label ,\nuint64 duration ,\nIERC20 paymentToken\n) external view returns ( uint256 );\nResolver State\n// Read any record (ENSIP-10): data carries the ABI-encoded profile call,\n// e.g. addr(node, coinType) or text(node, key)\nfunction resolve ( bytes calldata name , bytes calldata data ) external view returns ( bytes memory );\n// Record linked to a node (0 = no link; the name falls back to the default record)\nfunction getRecordId ( bytes32 node ) external view returns ( uint256 );\n// Number of records created on this resolver\nfunction getRecordCount () external view returns ( uint256 );\nThe resolver has no per-profile getters: all record reads go through resolve() . The name determines which record is read, and the node inside the profile calldata is ignored."}
{"url":"https://bitcoin.org/en/bitcoin-core/features/validation","domain":"bitcoin.org","title":"Validation - Bitcoin Core Features","hash":"c7118e8578302dbbb5fae1bb9d1176d7b298e8744283601e62f37f385066809b","tokens":3867,"chars":15465,"crawler":"crawler-f6nn","verified":"exact","ts":1791172104038,"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- Features\n- Overview\n- Validation\n- Privacy\n- Requirements\n- User Interface\n- Network Support\n- Get Help\n- Contribute\n- Bug reports\n- Code\n- Documentation\n- Translations\n- Tech Support\n- News\n- Download\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\nBitcoin\n>\nCore\n>\nFeatures\n> Validation\nBitcoin Core Validation\nDownload Bitcoin Core\nBitcoin Core 31.0\nImagine a scientist reading about an experimental result and then\nrepeating the experiment for herself. Doing so allows her to trust\nthe result without having to trust the original scientists.\nBitcoin Core checks each block of transactions it receives to ensure\nthat everything in that block is fully valid—allowing it to trust the\nblock without trusting the miner who created it.\nThis prevents miners from tricking Bitcoin Core users into accepting\nblocks that violate the 21 million bitcoin limit or which break other\nimportant rules.\nUsers of other wallets don’t get this level of security, so miners can\ntrick them into accepting fabricated transactions or hijacked blockchains.\nWhy take that risk if you don’t have to? Bitcoin Core provides\nthe best possible security against dishonest miners along\nwith additional security against other easier attacks (see below\nfor details).\nHow Validation Protects Your Bitcoins\nand\nput your bitcoins at\nincreased risk of being stolen. That risk may be acceptable for small\nvalues of bitcoin on mobile wallets, but is it what you want for your\nreal wallet?\nClick any row below for more details about that attack\nAttack\nBank Wallet\nSPV Wallet\nBitcoin Core\nDirect theft\nAlice deposits 100 bitcoins to Bank.Example.com. The next day, the\nowners of the site disappear with Alice’s money.\n-\nBitcoin bank users are vulnerable to direct theft because\nthey don’t control their own private keys.\n-\nLightweight (SPV) wallet users and Bitcoin\nCore users are not vulnerable because they control their\nown private keys.\nDirect theft is likely the leading cause of stolen bitcoins so far.\nReal Example\nBitcoin exchange Mt Gox reportedly had 650,000 bitcoins (worth $347\nmillion USD) stolen from their customer deposits and their own operating\nfunds. They declared bankruptcy on 28 February 2014.\nEven when the bankruptcy proceeding is complete, customers are unlikely to\nrecover more than a small fraction of the bitcoins they had on deposit.\nLearn More: Collapse of Mt\nGox\nBait and switch\nAlice installs Example Wallet, whose open source code has been\naudited. The next day, the authors of Example Wallet push new code to\nAlice’s device and steal all her bitcoins.\n-\nBitcoin bank users are vulnerable because they can only\nspend their bitcoins when they use the bank’s approved software.\n-\nLightweight (SPV) wallet users are vulnerable with\nmost software because auditors can’t easily verify the software you\nrun (the executable) is the same as the program source code, called a\ndeterministic build. However, some lightweight wallets are moving to\ndeterministic builds.\n-\nBitcoin Core is built deterministically. Cryptographic\nsignatures from build auditors—many of whom are well known to the\ncommunity—are released publicly .\nBitcoin.org’s Choose Your Wallet page tells you whether or not\nwallet builds are audited in the Transparency score for each wallet.\nReal Example\nIn April 2013, the OzCoin mining pool was hacked. The thief stole 923\nbitcoins (worth $135,000 USD), but online wallet StrongCoin modified\ntheir wallet code to ‘steal back’ 569 of those bitcoins ($83,000)\nfrom one of their users who was suspected of the theft.\nAlthough this attack was done with good intentions, it illustrated\nthat the operators of StrongCoin could steal bitcoins from their users\nat any time even though the users supposedly controlled their own\nprivate keys.\nLearn More: OzCoin Hacked, Stolen Funds Seized and Returned by StrongCoin\nFabricated transactions\nMallory creates a transaction giving Alice 1,000 bitcoins, so Alice\ngives Mallory some cash. Later Alice discovers the transaction Mallory\ncreated was fake.\n-\nBitcoin bank users depend on the information reported by the\nbank, so they can easily be fooled into accepting fabricated\ntransactions.\n-\nLightweight (SPV) wallet users depend on full nodes and\nminers to validate transactions for them. It costs nothing for\ndishonest full nodes to send unconfirmed fabricated transactions to an\nSPV wallet. Getting one or more confirmations of those fabricated\ntransactions is also possible with help from a dishonest miner.\n-\nBitcoin Core users don’t have to worry about fabricated\ntransactions because Bitcoin Core validates every transaction before\ndisplaying it.\nCurrently the best defense against fabricated transactions, besides\nusing Bitcoin Core, is to wait for as many confirmations as possible.\nReal Example\nOn 4 August 2015, web wallet BlockChain.info began indicating that a\ntransaction had spent the earliest mined 250 bitcoins, coins that some\npeople believed were owned by Bitcoin creator Satoshi Nakamoto.\nIt was soon discovered that the transaction was invalid. BlockChain.info\nwas not validating transactions with Bitcoin Core and that transaction\nhad been created by a security researcher .\nLearn more: BitcoinJ documentation about pending transaction\nsafety\nChain hijacking\nAlice believes that there should never be more than 21 million\nbitcoins—but one day she’s tricked into buying “bitcoins” that\nare only valid on a blockchain with permanent 10% inflation.\n-\nBitcoin bank users have to use whatever blockchain the\nbank uses. Banks can even profit from switching their users to a new\nchain and selling their users’ bitcoins from the old chain.\n-\nLightweight (SPV) wallet users accept the blockchain\nthey know about with the most proof of work. This lets the hash rate\nmajority of miners force SPV wallet users off of Bitcoin.\n-\nBitcoin Core users don’t have to worry about chain\nhijacking because Bitcoin Core validates every block using all of\nBitcoin’s consensus rules.\nPreventing chain hijacking is one of Bitcoin Core’s most important jobs.\nThe alternative is to allow miners to do whatever they want.\nReal Example\nIn July 2015, several large Bitcoin miners accidentally produced an\ninvalid blockchain several blocks longer than the correct blockchain.\nSome bank wallets and many SPV wallets accepted this longer chain,\nputting their users’ bitcoins at risk.\nRecent versions of Bitcoin Core never accepted any of the blocks from\nthe invalid chain and never put any bitcoins at risk.\nIt is believed that the miners at fault controlled more than 50% of the\nnetwork hash rate, so they could have continued to fool SPV wallets\nindefinitely. It was only their desire to remain compatible with\nBitcoin Core users that forced them to abandon over $37,500 USD worth of\nmining income.\nLearn more: July 2015 chain forks\nTransaction withholding\nMallory shows Alice $1,000 USD that he will pay her if she sends him some\nbitcoins. Alice sends the bitcoins but the transaction never seems to\nconfirm. After waiting a long time, Alice returns Mallory’s cash. It\nturns out the transaction did confirm, so Alice gave away her bitcoins\nfor nothing.\n-\nBitcoin bank users only see the transactions the bank\nchoose to show them.\n-\nLightweight (SPV) wallets users only see the\ntransactions their full node peers choose to send them, even if those\ntransactions were included in a block the SPV wallet knows about.\n-\nBitcoin Core users see all transactions included in\nreceived blocks. If Bitcoin Core hasn’t received a block for too long,\nit displays a catching-up progress bar in the graphical user\ninterface or a warning message in the CLI/API user\ninterface.\nUnless you use Bitcoin Core, you can never be sure that your bitcoin balance\nis correct according to the blockchain.\nReal Example\nIn March 2015, spy nodes run by the company Chainalysis accidentally\nprevented some users of the lightweight BreadWallet from connecting to\nhonest nodes. Since the spy nodes didn’t relay transactions, BreadWallet\nusers stopped receiving notification of new transactions.\nLearn more: Chainalysis CEO Denies ‘Sybil Attack’ on Bitcoin’s Network\nChain rewrites\nMallory gives Alice 1,000 bitcoins. When Alice’s wallet says the\ntransaction is confirmed, Alice gives Mallory some cash. Later Alice\ndiscovers that Mallory has managed to steal back the bitcoins.\nThis attack applies to all Bitcoin wallets.\nThe attack works because powerful miners have the ability to rewrite the\nblockchain and replace their own transactions, allowing them to take\nback previous payments.\nThe cost of this attack depends on the percentage of total network hash\nrate the attacking miner controls. The more centralized mining becomes,\nthe less expensive the attack for a powerful miner.\nReal Example\nIn September 2013, someone used centralized mining pool GHash.io to\nsteal an estimated 1,000 bitcoins (worth $124,000 USD) from the gambling\nsite BetCoin.\nThe attacker would spend bitcoins to make a bet. If he won, he would\nconfirm the transaction. If he lost, he would create a transaction\nreturning the bitcoins to himself and confirm that, invalidating the\ntransaction that lost the bet.\nBy doing so, he gained bitcoins from his winning bets without losing\nbitcoins on his losing bets.\nAlthough this attack was performed on unconfirmed transactions, the\nattacker had enough hash rate (about 30%) to have profited from\nattacking transactions with one, two, or even more confirmations.\nLearn more: GHash.IO and double-spending against BetCoin\nDice\nNote that although all programs—including Bitcoin Core—are\nvulnerable to chain rewrites, Bitcoin provides a defense mechanism: the\nmore confirmations your transactions have, the safer you are. There is\nno known decentralized defense better than that.\nHelp Protect Decentralization\nThe bitcoin currency only works when people accept bitcoins in exchange\nfor other valuable things. That means it’s the people accepting\nbitcoins who give it value and who get to decide how Bitcoin should work.\nWhen you accept bitcoins, you have the power to enforce Bitcoin’s rules,\nsuch as preventing confiscation of any person’s bitcoins without access\nto that person’s private keys.\nUnfortunately, many users outsource their enforcement power . This\nleaves Bitcoin’s decentralization in a weakened state where a handful of\nminers can collude with a handful of banks and free services to change\nBitcoin’s rules for all those non-verifying users who outsourced their power.\nUsers of Bitcoin banks\nTrust bankers\nUsers of P2P lightweight wallets\nTrust miners\nUsers of client lightweight wallets\nTrust “free” services\nUsers of Bitcoin Core\nEnforce the rules\nUnlike other wallets, Bitcoin Core does enforce the rules —so\nif the miners and banks change the rules for their non-verifying\nusers, those users will be unable to pay full validation Bitcoin Core\nusers like you.\nAs long as there are many non-verifying users who want to be able to\npay Bitcoin Core users, miners and others know they can’t effectively\nchange Bitcoin’s rules.\nBut what if not enough non-verifying users care about paying Bitcoin\nCore users? Then it becomes easy for miners and banks to take control of\nBitcoin, likely bringing to an end this 17 year experiment\nin decentralized currency.\nIf you think Bitcoin should remain decentralized, the best thing you\ncan do is validate every payment you receive using your own personal\nfull node such as Bitcoin Core.\nWe don’t know how many full validation users and business are needed,\nbut it’s possible that for each person or business who validates their\nown transactions, Bitcoin can remain decentralized even if there are ten\nor a hundred other non-verifying users. If this is the case, your\nsmall contribution can have a large impact towards keeping Bitcoin\ndecentralized.\nDo You Validate Your Transactions?\nSome people confuse supporting the network with\nhelping to protect Bitcoin’s decentralization .\nTo improve your security and help\nprotect decentralization, you must use a wallet that fully validates\nreceived transactions. There are three ways to do that with Bitcoin\nCore right now:\n-\nUse the built-in wallet’s graphical mode. If you request payment\nusing the following screen in Bitcoin Core, your received\ntransactions will be fully validated.\n-\nUse Bitcoin Core as a trusted peer for certain lightweight\nwallets. Learn more on the user interface page. If you use a secure connection to your personal\ntrusted peer every time you use the wallet, your received\ntransactions will be fully validated.\n-\nUse the built-in wallet’s CLI/API interface. This is meant for\npower users, businesses, and programmers. The user interface page provides an overview, the installation\ninstructions can help you get started, and\nthe RPC documentation can help you find specific\ncommands. If you’re using getnewaddress to\ncreate receiving addresses, your received transactions will be fully\nvalidated.\nIf you have any questions, please ask on the forums or\nchatrooms .\nPREV\nNEXT\nBitcoin banks and exchanges are organizations that control your\nbitcoins on your behalf similar to the way traditional banks control\nyour fiat deposits on your behalf.\nSimplified Payment Verification (SPV) wallets are lightweight\nwallets that can verify whether or not a transaction is part of a block\nwithout downloading the 740 GB blockchain. However,\nthey cannot verify whether or not the transaction is actually valid.\n(Only full validation nodes like Bitcoin Core can do that.)\nHonest miners who only create blocks with valid transactions currently\nreceive a 3.125 bitcoin subsidy.\nDishonest miners who create blocks with invalid transactions don’t\nreceive that subsidy, but they might still attempt to trick SPV\nwallets if they can steal more bitcoins than they would make honestly (or\nsteal any amount of bitcoins from people they don’t like).\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\nBitcoin Core pages on Bitcoin.org are\nmaintained separately from the rest of the site.\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://forum.skyeco.com/t/technical-scope-sentora-x-spark-rlusd-wbtc-relative-supply-cap-reduction/28280","domain":"forum.skyeco.com","title":"Technical Scope: Sentora x Spark RLUSD WBTC Relative Supply Cap Reduction - Spark Prime - Sky Forum","hash":"07f8b4701f6eb1d86c8b71c12eda7e3c66ee92d1d9d5f846212479d7921bfd39","tokens":4076,"chars":16302,"crawler":"crawler-f6nn","verified":"exact","ts":1791172106380,"text":"Sky Forum\nTechnical Scope: Sentora x Spark RLUSD WBTC Relative Supply Cap Reduction\nSpark Prime\nPhoenixLabs\nOctober 4, 2026, 11:43pm\n1\nTechnical Scope: Sentora x Spark RLUSD WBTC Relative Supply Cap Reduction\nIntroduction\nGoal of this update\n- [Ethereum] Spark Liquidity Layer: Reduce the WBTC market’s relative supply cap in the Sentora x Spark RLUSD vault from 100% to 10% .\nRequired context\nThe Sentora x Spark RLUSD vault is an existing Morpho Vaults V2 deployment. The September onboarding scope documents its deployment and Spark integration. This standalone update changes the vault’s cap for the existing RLUSD loan market collateralized by WBTC at 86% LLTV. It uses the joint Soter Labs/Sentora curator Safe identified in the Atlas delegated instance .\nThe native cap-reduction function is callable immediately by the curator or a sentinel. This proposal uses the curator. It has no on-chain scheduling step or cancellation window and is not permissionless.\nThe reason(s) behind this update\nSentora requests a reduction in the WBTC market’s relative supply cap from 100% to 10% to limit concentration risk by restricting how much of the vault’s assets can be allocated to this single collateral market. The allocation and liquidity implications are specified in Proposed actions.\nTiming of this update (in stages, if needed)\nAll dates below are planned targets, subject to the Pre-requirements.\nStage\nTarget timing\nResponsible party / condition\nPublication\nSunday, October 4, 2026\nSpark publishes the proposal\nGovernance poll\nMonday, October 5, 2026 at 16:00 UTC through Thursday, October 8, 2026 at 16:00 UTC\nSky Operational Facilitator schedules the SPK poll and records its result.\nExecution\nThursday, October 8, 2026, after the poll closes at 16:00 UTC\nAfter the poll closes and an approving result is confirmed, GovOps submits the joint curator Safe transaction and Sentora approves/executes it, subject to all Pre-requirements. This transaction is submitted after the vote outcome is known, so the additional 24-hour wait for transactions queued before the outcome is known does not apply.\nRelevant audits\nNo contract is deployed or upgraded for this change.\n- Morpho Vault V2, ChainSecurity.\n- External report: auditor-hosted assessment , section 2.1.\n- Final audited commit: 6f2af6602e05d9e123a87c1067712a4566608044 .\n- Relevant scope: VaultV2.sol , including relative cap setters, allocation enforcement, deposits/withdrawals and timelocked recovery.\n- Coverage of the existing deployment: the onboarding deployment verification identifies release 2b139002feaf4631f1c63d880380ca2278df7aec . The relevant function bodies and signatures match the final audited revision after stripping comments/whitespace. This bounded source comparison is not a new deployment-bytecode rebuild or an audit of the proposed risk limit.\n- Diff with another independent audit: no differential audit is needed for this parameter-only update; no new audit coverage is asserted.\nTrusted addresses\nAll current-state values below and in Proposed actions were read on September 25, 2026 at Ethereum block 26,053,966 . Registry permalinks use commit 231a6ac6cecbcbf650128fbdf989687c71b5b7b1 . Each listed address has deployed bytecode at that block. Native vault getters establish roles; the vault does not implement AccessControl role hashes or hasRole for these permissions.\nContract name\nAddress with URL\nSource URL / verification\nSentora x Spark RLUSD vault\neth:0xFC8C624B6080a0a780583799f2A862DE936F6E22\nregistry SENTORA_RLUSD_MORPHO_VAULT_V2 ; name() , asset() , curator()\nMorphoMarketV1AdapterV2\neth:0x743C8eb5dE31E41dEF9048DA268EBd036567cd4e\nonboarding scope ; vault adapters(0) , adapter parentVault()\nCurator Safe, 2-of-2\neth:0xff070333654aaE76A0A77465E4F0fd101C57c03F\nAtlas instance ; vault curator() , Safe getOwners() / getThreshold()\nGovOps curator signer Safe, 1-of-2\neth:0xAB5710211458FC8d7E0Be628202F47DdbD3F38Eb\nCurator getOwners() and nested Safe getters; signer attribution confirmed by the proposal sponsor on September 25, 2026\nSentora curator signer / sentinel Safe, 1-of-1\neth:0x9e396dE3312D373b87F9BD8763fb48184b42aac0\nAtlas instance ; curator getOwners() , nested Safe getters, vault isSentinel()\nSoter Labs / GovOps sentinel Safe, 2-of-3\neth:0xb5bFd4883256089Dc58D962b80ab7068e71E7c80\nAtlas instance ; Safe getters and vault isSentinel()\nSpark Foundation sentinel Safe, 3-of-5\neth:0xf5748bBeFa17505b2F7222B23ae11584932C908B\nregistry MORPHO_GUARDIAN_MULTISIG ; Atlas instance ; Safe getters and vault isSentinel()\nSpark SubDAO Proxy, vault owner\neth:0x3300f198988e4C9C63F75dF86De36421f06af8c4\nregistry SPARK_PROXY ; vault owner()\nRLUSD, loan asset, 18 decimals\neth:0x8292Bb45bf1Ee4d140127049757C2E0fF06317eD\nregistry RLUSD ; vault asset() , Morpho idToMarketParams() , token getters; Ripple canonical addresses\nWBTC, collateral, 8 decimals\neth:0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599\nregistry WBTC ; Morpho idToMarketParams() , token getters; WBTC canonical Ethereum token\nExisting WBTC/RLUSD oracle\neth:0xF58725eb213161E9054C97F970DC80b2d0327E8d\nMorpho idToMarketParams(marketId).oracle ; existing market configuration, unchanged\nAdaptiveCurveIrm\neth:0x870aC11D48B15DB9a138Cf899d20F13F79Ba00BC\nregistry MORPHO_DEFAULT_IRM ; Morpho idToMarketParams() , adapter adaptiveCurveIrm() ; Morpho canonical addresses\nMorpho Blue\neth:0xBBBBBbbBBb9cC5e90e3b3Af64bdAF62C37EEFFCb\nregistry MORPHO ; adapter morpho() ; Morpho canonical addresses\nThe GovOps curator signer and GovOps sentinel are distinct Safes. Sentora’s signer Safe is controlled by one EOA; the joint curator still requires both owner seats. The proposal sponsor confirmed the specified signer assignments and thresholds on September 25, 2026. Transaction preparation and the operating handover remain covered by Pre-requirement 2.\nPre-deployed contracts\nNot applicable. This update uses the existing vault, adapter, market and curator Safe; no deployment is prepared for it.\nPre-configurations\nNot applicable. No preparatory contract setting or role change is proposed. Safe transaction preparation is covered by Pre-requirement 2.\nPre-requirements\n-\nObtain review, publication and governance approval.\n- Intended end goal: the exact market, cap and execution route receive the guide’s GovOps/Core Council Risk Advisor review, public proposal and an approving SPK poll.\n- Why required in advance: Atlas A.6.1.1.1.3.9.4.1, Polling Requirement requires approval before implementation. Its conditional pre-poll queuing permission does not make an immediate setter safe to execute before approval.\n- Proof: [TBD: review approval, forum proposal and approving poll result, from GovOps, the Sky Core Council Risk Advisor, the Sky forum and sparkfi.eth Snapshot]. If the poll rejects the change or has no valid approval result, do not execute.\n-\nPrepare and verify the joint curator Safe transaction.\n- Intended end goal: both signer teams verify the chain, Safe, nonce, transaction hash, target, zero ETH value, CALL operation, complete idData and target cap; reread state and reconcile pending cap increases before signing/executing. Confirm relativeCap(capId) == 1000000000000000000 (100%). If it is already 100000000000000000 (10%), verify the prior execution and do not execute a duplicate. For any other value, pause and reconcile the changed state before proceeding.\n- Why required in advance: validate the payload before using the execution route described in Required context. Recheck the exposure against the new cap and confirm the deposit/withdrawal route remains acceptable at execution time.\n- Proof: [TBD: staged curator Safe transaction link, from GovOps and Sentora]. [TBD: accepted monitoring coverage and escalation contact, from GovOps and Sentora’s operational handover]. Staging is a future operational action.\nProposed actions\n1. Reduce the WBTC/RLUSD market relative supply cap\n- Business reason: implement Sentora’s requested concentration limit.\n- Who performs it: GovOps initiates the joint curator Safe transaction; Sentora approves and executes after both owner seats authorize it. The vault’s caller must be curator Safe eth:0xff070333654aaE76A0A77465E4F0fd101C57c03F . No caller substitution to a sentinel is proposed.\n- Target: vault eth:0xFC8C624B6080a0a780583799f2A862DE936F6E22 , Ethereum chain ID 1 , ETH value 0 , Safe operation CALL ( 0 ).\n- Function: decreaseRelativeCap(bytes idData, uint256 newRelativeCap) , selector 0x57975270 . One direct call, with no submit(bytes) wrapper.\n- Staged transaction: the Safe transaction link is supplied under Pre-requirement 2.\nMarket and cap identifier\nMorpho idToMarketParams(marketId) returns the following tuple. Address fields refer to the corresponding entries in Trusted addresses; these fields identify the existing market and are not being changed.\nField\nValue\nSource\nloanToken\nRLUSD\nVault asset() and Morpho market tuple; Trusted addresses\ncollateralToken\nWBTC\nMorpho market tuple; Trusted addresses\noracle\nExisting WBTC/RLUSD oracle\nMorpho market tuple; Trusted addresses\nirm\nAdaptiveCurveIrm\nMorpho market tuple and adapter adaptiveCurveIrm() ; Trusted addresses\nlltv\n860000000000000000 ( 0.86e18 , 86%)\nMorpho market tuple\nThe Morpho market ID is 0xa128dddc761075df9a9a60689f3a41a989b245aad506352c509c0c3a76a9ec6b , recomputed as keccak256(abi.encode(marketParams)) . The vault cap ID is different : 0x0524a9b8f56cccef62810680f4fcce8f6659cdefb04493cb4b6de5640f3b9ec5 . It is the third entry returned by adapter ids(marketParams) , independently recomputed from the following ABI encoding:\nbytes memory idData = abi.encode(\n\"this/marketParams\",\naddress(0x743C8eb5dE31E41dEF9048DA268EBd036567cd4e),\nMarketParams({\nloanToken: 0x8292Bb45bf1Ee4d140127049757C2E0fF06317eD,\ncollateralToken: 0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599,\noracle: 0xF58725eb213161E9054C97F970DC80b2d0327E8d,\nirm: 0x870aC11D48B15DB9a138Cf899d20F13F79Ba00BC,\nlltv: uint256(860000000000000000)\n})\n);\n// keccak256(idData) == 0x0524a9b8f56cccef62810680f4fcce8f6659cdefb04493cb4b6de5640f3b9ec5\nvault.decreaseRelativeCap(idData, uint256(100000000000000000));\nThe deployed adapter’s ids() getter and verified source establish this encoding. Use abi.encode , not abi.encodePacked ; pass the complete bytes, not either bytes32 identifier alone.\nParameter change and effect\nParameter\nCurrent\nProposed\nSource / units\nVault relativeCap(capId)\n1000000000000000000 ( 1e18 , 100%)\n100000000000000000 ( 1e17 , 10%)\nCurrent vault getter; target supplied by Sentora’s request through the proposal sponsor. Dimensionless WAD: 10 / 100 * 1e18 .\nVault absoluteCap(capId)\n250000000000000000000000000 (250,000,000 RLUSD)\nUnchanged\nVault getter; RLUSD has 18 decimals.\nOnly this market-specific relative cap changes. The adapter-wide and collateral-wide relative caps remain 100%. Their cap IDs are 0xf6e5057c42acb4bde69a10462b58405ca3df7bfa2f54fb53cf8c261768e590c5 and 0x7e50b2d1a555e26ad34679567e2d319a7fdafeabb38b0957566156a1c9369ae4 respectively. The oracle, LLTV, roles, fees and other settings remain unchanged.\nThe allocation check requires updated allocation to be at most floor(firstTotalAssets * relativeCap / 1e18) and within the absolute cap. firstTotalAssets is the transaction’s first accrued total-assets snapshot. A relative cap is not a continuous guarantee that exposure stays below that percentage: interest or withdrawals can increase the fraction, and reducing the cap does not automatically rebalance, liquidate borrowers or reject a setter because existing exposure is above it. Subsequent allocations that fail the cap check revert.\nAt the verification block, totalAssets() was 250001004746755110602041675 (250,001,004.746755110602041675 RLUSD). Stored allocation(capId) was 3050003885271116891042969 (3,050,003.885271116891042969 RLUSD); adapter expectedSupplyAssets(marketId) was 3052331235329137017488966 (3,052,331.235329137017488966 RLUSD), approximately 1.221% of total assets. Both are below 10%; the latter includes expected accrued market interest. Refresh these block-specific exposure and asset values before execution.\nliquidityAdapter() is address(0) and liquidityData() is empty ( 0x ) at that block. Deposits therefore remain idle rather than automatically supplying WBTC. This update preserves that configuration. Recheck it before execution: if an automatic liquidity adapter is later configured to this market, its deposit allocation can revert at the tighter cap. With the liquidity adapter disabled, ordinary withdrawals use idle vault assets and do not automatically deallocate market supply when idle liquidity is insufficient. Withdrawal and deallocation paths do not check the relative cap; their existing liquidity, ownership, allowance and gate restrictions still apply. The cap setter makes no token transfer.\nExact calldata\nThe following calldata encodes the single vault call above ( 388 bytes):\n0x579752700000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000016345785d8a0000000000000000000000000000000000000000000000000000000000000000012000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000743c8eb5de31e41def9048da268ebd036567cd4e0000000000000000000000008292bb45bf1ee4d140127049757c2e0ff06317ed0000000000000000000000002260fac5e5542a773aa44fbcfedf7c193bc2c599000000000000000000000000f58725eb213161e9054c97f970dc80b2d0327e8d000000000000000000000000870ac11d48b15db9a138cf899d20f13f79ba00bc0000000000000000000000000000000000000000000000000bef55718ad600000000000000000000000000000000000000000000000000000000000000000011746869732f6d61726b6574506172616d73000000000000000000000000000000\nRead-only eth_call with these bytes succeeded from the curator at the verification block and reverted for an unauthorized caller.\nPost-checks\n-\nConfirm the cap update.\n- What / how: GovOps and Sentora check the successful Safe and vault execution receipt, including Safe execution success rather than transaction status alone. Decode the exact target/calldata and DecreaseRelativeCap(sender, id, idData, newRelativeCap) event.\n- Expected outcome: sender is the curator Safe; id and idData match Proposed action 1; relativeCap(capId) == 100000000000000000 at the execution block.\n- Who: GovOps and Sentora, with the receipt and block recorded.\n-\nCheck unchanged configuration and operations.\n- What / how: compare the execution transaction’s pre/post state, or equivalent fork trace, for the absolute cap, adapter/collateral caps, owner, curator, sentinel membership, adapter registration and liquidity routing. Reread WBTC exposure and total assets at the execution block and reconcile intervening legitimate operations separately.\n- Expected outcome: this call modifies only the specified relative cap. It transfers no asset and performs no rebalance. Allocation simulations must enforce the new cap. Deposit simulations must follow the configured idle-liquidity route. Withdrawal simulations must respect available idle liquidity and existing access restrictions, without a relative-cap check. The setter must not automatically reduce WBTC supply to 10%.\n- Who: GovOps and Sentora.\n-\nRecord the outcome and report the curator action.\n- What / how: publish the execution hash, cap change, proposal/poll links and outcome in Spark-Prime within 24 hours, following Atlas A.6.1.1.1.3.9.3.3, Reporting of Curator Actions . Record when the cap decrease took effect.\n- Expected outcome: [TBD: successful execution receipt, post-check results and curator report, from Ethereum and the Spark-Prime forum].\n- Who: curator operators, GovOps and Sentora.\nResearch and additional notes\nA scan of vault Submit/Accept/Revoke events from deployment block 25,884,177 through block 26,053,966, reconciled with executableAt for every submitted payload, found no pending cap change. Recheck before execution.\nA local Ethereum fork at block 26,053,966 confirmed that the curator call changes only the target cap, with one storage write and no changes to the checked roles, other caps or token balances. An unauthorized caller was rejected; a subsequent 30 million RLUSD allocation reverted with RelativeCapExceeded() . The read-only calls and local fork test the vault call and its effects; they do not verify Safe signature execution, governance approval or an actual Ethereum execution."}
{"url":"https://docs.ton.org/foundations/overview","domain":"docs.ton.org","title":"Blockchain foundations overview","hash":"d32bfcf08b2244ec271ad67b14d7628d24cfdc59b0f86fcb71b110d9a0c18f40","tokens":807,"chars":3225,"crawler":"crawler-f6nn","verified":"exact","ts":1791172111312,"text":"Onboarding Nodes Applications APIs Contracts Smart contracts Tolk Tolk language TVM TON Virtual Machine Foundations Blockchain foundations\nBlockchain foundations overview\nCore TON concepts, data formats, transaction mechanics, network internals, and reference materials\nData and serialization\nTON stores data as graphs of cells and serializes those graphs for messages, blocks, account state, proofs, and storage.\n- TL-B : how TON data structures are defined and serialized.\n- Cells : basic storage units used by TVM, persistent storage, and smart contract code.\n- Library references : cells that point to published library cells by hash.\n- Merkle proofs : exotic cells that prove selected data belongs to a larger cell tree.\n- Merkle updates : exotic cells that describe a verified transition between two cell trees.\n- Pruned branches : compact replacements for deleted subtrees.\n- Bag of Cells : the standard format for transferring or storing cell graphs.\nRead about using Merkle cells for the verification of selected blockchain data in smart contracts and off-chain software: Proofs overview .\nAccounts and transactions\nWhat happens to accounts before, during, and after transaction execution.\n- Addresses : how accounts are identified and how smart contracts exchange messages.\n- Messages and transactions : contract execution triggers and records of the resulting account state changes.\n- Actions : how smart contracts queue operations to be performed during the action phase.\n- Account status : whether an account can store balance, hold code, or process transactions.\n- Execution phases : the storage, credit, compute, action, and bounce phases that can make up a transaction.\n- Transaction fees : storage, compute, import, forward, and action costs during transaction processing.\n- Traces : causally related messages and transactions grouped into one operation flow.\nNetwork and configuration\nHow TON scales, enforces limits, and stores network parameters.\n- Blockchain sharding : how workchains split into shardchains that process account activity in parallel.\n- Blockchain limits : maximum sizes, depths, gas values, and other network constraints.\n- Blockchain configuration : values that influence validator behavior, fees, capabilities, and system contracts.\n- Web3 services : TON Network, TON Storage, TON Proxy, TON DNS, and TON Sites.\n- System contracts : contracts that manage validator elections and blockchain configuration.\n- Precompiled contracts : contracts with native implementations in validator nodes.\nConsensus\nHow validators propose blocks and vote on them to reach a consensus: Catchain 2.0: Simplex Consensus in TON .\nTo read about the previous version of the consensus mechanism, see:\n- Catchain 1.0 consensus\n- Catchain 1.0 and BCP visualizer\nWhitepapers\nOriginal and modern TON whitepapers:\n- Overview\n- The Open Network (TON)\n- TON Virtual Machine (TON)\n- TON Blockchain\n- Catchain consensus (legacy) — previous version of the consensus mechanism in TON\n- Catchain 2.0: Simplex Consensus in TON — currently employed consensus mechanism\nGet methods\nPrevious Page\nOverview\nNext Page\nOn this page\nData and serialization Accounts and transactions Network and configuration Consensus Whitepapers"}
{"url":"https://docs.jup.ag/user-docs/earn/rewards-hub","domain":"docs.jup.ag","title":"Jupiter Rewards Hub Overview - Jupiter Documentation","hash":"c347e6a4704142b1b7beb49f166cab0c7909358ccfd8dfc42e565c5d4474f526","tokens":375,"chars":1498,"crawler":"crawler-f6nn","verified":"exact","ts":1791172114111,"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\nJupiter Rewards Hub\nJupiter Rewards Hub Overview\nOverview of the Jupiter Rewards Hub and its campaign system.\nThe Jupiter Rewards Hub is a platform that hosts trading and referral campaigns across the Jupiter ecosystem.\nEach campaign runs for a fixed period, with its own rules, eligible trading pairs, reward currency, and distribution method. Campaigns are independent from one another: eligibility, points, and rewards do not carry over between campaigns.\nWhat is a campaign?\nA campaign is a time-limited program where users earn rewards by trading eligible pairs on Jupiter and/or referring other users. Each campaign defines:\n- Which platforms and trading modes are eligible\n- Which token pairs earn rewards, and at what rate\n- How rewards are earned (trading points, cards, lootboxes)\n- The reward currency and total pool\n- How rewards are delivered: a claim window after the campaign ends, or an automatic airdrop for some campaigns\nTrading Card Game\nThe Rewards Hub currently hosts the Trading Card Game (TCG) , a recurring campaign with multiple seasons.\nHow the TCG works\nCore mechanics: points, cards, referrals, eligibility, and season details.\nFAQ\nCommon questions about the Rewards Hub, the TCG, and how rewards work.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://bitcoinops.org/en/newsletters/2026/02/13/","domain":"bitcoinops.org","title":"Bitcoin Optech Newsletter #392 | Bitcoin Optech","hash":"0c98aeb039c230a170cef4d39032b9fa0d7bedd007d315878fbfeb8300295ba6","tokens":2449,"chars":9796,"crawler":"crawler-f6nn","verified":"exact","ts":1791172116681,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nBitcoin Optech Newsletter #392\nFeb 13, 2026\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.\nNews\n-\n● Proposal to limit the number of per-group silent payment recipients : Sebastian\nFalbesoner posted to the Bitcoin-Dev mailing list the discovery and\nmitigation of a theoretical attack on silent\npayment recipients. The attack occurs when an adversary\nconstructs a transaction with a large number of taproot outputs (23255 max outputs per\nblock according to current consensus rules) that all target the same entity.\nIf there were no limit on group size, it would take several minutes\nto process, rather than tens of seconds.\nThis motivated a mitigation to add a new parameter, K_max , that limits the\nnumber of per-group recipients within a single transaction. In theory, this\nchange would not be backward-compatible, but in practice, none of the\nexisting silent payment wallets should be affected\nfor a sufficiently high K_max . Falbesoner is proposing K_max=1000 .\nFalbesoner is seeking feedback or concerns about the proposed restriction. He\nalso notes that most silent payment wallet developers have been notified and\nare aware of the issue.\n-\n● BLISK, Boolean circuit Logic Integrated into the Single Key : Oleksandr\nKurbatov posted to Delving Bitcoin about BLISK, a protocol\ndesigned to express complex authorization policies using boolean logic.\nBLISK tries to address the limitations of current spending policies. For example,\nprotocols like MuSig2 , though efficient and privacy-preserving,\ncan only express cardinality (k-of-n) but cannot identify “who” can spend.\nBLISK creates a simple AND/OR boolean circuit, mapping logical gates to\nwell-known cryptographic techniques. In particular, AND gates are obtained by\napplying an n-of-n multisignature setup, in which each participant must contribute a\nvalid signature. On the other end, OR gates are obtained by leveraging key agreement\nprotocols, such as ECDH , in which any participant can derive a shared\nsecret using their private key and the other participant’s public key. It also applies\na Non-interactive Zero Knowledge proof to make circuit resolution\nverifiable and to prevent cheating.\nBLISK resolves the circuit to a single signature verification key. This means\nthat only a single Schnorr signature must be verified\nagainst one public key.\nAnother important advantage of BLISK with respect to other approaches is\neliminating the need to generate a fresh key pair. In fact, it allows connecting an\nexisting key to the specific signature instance.\nKurbatov provided a proof-of-concept for the protocol, although he stated\nthat the framework has not reached production maturity yet.\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 29.3 is a maintenance release for the previous major\nrelease series that includes several wallet migration fixes (see\nNewsletter #387 ), a per-input sighash midstate cache\nthat reduces the impact of quadratic sighashing in legacy scripts (see\nNewsletter #367 ), and removal of peer discouragement\nfor consensus-invalid transactions (see Newsletter #367 ). See the release notes for all details.\n-\n● LDK 0.2.2 is a maintenance release of this library for building\nLN-enabled applications. It updates the SplicePrototype feature flag\nto the production feature bit (63), fixes an issue where async\nChannelMonitorUpdate persistence operations could hang after restarts\nand lead to force-closures, and fixes a debug assertion failure that\noccurred when receiving invalid splicing messages from a peer.\n-\n● HWI 3.2.0 is a release of this package providing a common interface\nto multiple hardware signing devices. The new release adds\nsupport for the Jade Plus and BitBox02 Nova devices, testnet4 , native PSBT signing for Jade, and MuSig2 PSBT fields as specified in BIP373 .\n-\n● Bitcoin Inquisition 29.2 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.3r2, this release\nimplements the BIP54 ( consensus cleanup )\nproposal and disables testnet4 .\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 #32420 updates the Mining IPC interface (see\nNewsletter #310 ) to stop including a dummy\nextraNonce in the coinbase scriptSig . A new\ninclude_dummy_extranonce option is added to CreateNewBlock() , and\nthe IPC codepath sets it to false . Stratum v2\nclients receive only the consensus-required BIP34 height in the\nscriptSig and no longer need to strip or ignore the extra data.\n-\n● Core Lightning #8772 removes support for the legacy onion payment\nformat. While CLN had stopped creating legacy onions in 2022 (see\nNewsletter #193 ), it added a translation layer in\nv24.05 to handle the few remaining legacy onions produced by older LND\nversions. These have not been created since LND v0.18.3, so support is\nno longer needed. The legacy format was removed from the BOLTs\nspecification in 2022 (see Newsletter #220 ).\n-\n● LND #10507 adds a new wallet_synced boolean field to the\nGetInfo RPC response, which indicates whether the wallet has finished\ncatching up to the current chain tip. Unlike the existing\nsynced_to_chain boolean field, this new field does not require the\nchannel graph router (which validates channel announcements ) or the blockbeat dispatcher (a subsystem that\ncoordinates block-driven events) to be synced before returning true.\n-\n● LDK #4387 switches the splicing feature flag from\nthe provisional bit 155 to the production bit 63. LDK v0.2 used bit\n155, which Eclair also uses for a custom, Phoenix-specific splice\nimplementation that predates and is incompatible with the current draft\nspecification. This caused Eclair nodes to attempt splices using their\nprotocol when connecting to LDK nodes, resulting in deserialization\nfailures and reconnections.\n-\n● LDK #4355 adds support for async signing of commitment signatures\nexchanged during splicing and dual-funded channel negotiations. When receiving\nEcdsaChannelSigner::sign_counterparty_commitment , the async signer\nimmediately returns and calls back via\nChannelManager::signer_unblocked once the signature is ready.\nDual-funded channels still require additional work to fully support\nasync signing.\n-\n● LDK #4354 makes channels with anchor outputs\nthe default by setting the config option of\nnegotiate_anchors_zero_fee_htlc_tx to true by default. Automatic\nchannel acceptance has been removed, so all inbound channel requests\nmust be manually accepted. This ensures that the wallet has enough\non-chain funds to cover fees in the event of a force close.\n-\n● LDK #4303 fixes two bugs where HTLCs could be\ndouble-forwarded after a ChannelManager restart: one where the\noutbound HTLC was still in a holding cell (internal queue) but it was\nmissed, and another where it had already been forwarded, settled, and\nremoved from the outbound channel, but the inbound side’s holding cell\nstill had a resolution for it. This PR also prunes inbound HTLC onions\nonce they are irrevocably forwarded.\n-\n● HWI #784 adds PSBT serialization and deserialization\nsupport for MuSig2 fields, including participant public\nkeys, public nonces, and partial signatures for both inputs and\noutputs, as specified in BIP327 .\n-\n● BIPs #2092 assigns a one-byte v2 P2P transport message type ID to the feature message from BIP434 ,\nand adds an auxiliary file to BIP324 tracking one-byte ID\nassignments across BIPs to help developers avoid conflicts. The file\nalso records Utreexo ’s proposed assignments from\nBIP183.\n-\n● BIPs #2004 adds BIP89 for Chain Code Delegation (see\nNewsletter #364 ), a collaborative custody\ntechnique where a delegatee withholds BIP32 chain codes from a\ndelegator, sharing only enough information with the delegator to\nproduce signatures without learning which addresses received funds.\n-\n● BIPs #2017 adds BIP110 , which specifies the Reduced Data\nTemporary Softfork (RDTS), a proposal to temporarily restrict\ndata-carrying transaction fields at the consensus level for\napproximately one year. The rules would invalidate scriptPubKeys\nexceeding 34 bytes (except OP_RETURN up to 83 bytes), pushdata and\nwitness stack elements exceeding 256 bytes, spending of undefined\nwitness versions, taproot annexes, control blocks\nexceeding 257 bytes, OP_SUCCESS opcodes, and OP_IF / OP_NOTIF in\ntapscripts . Inputs spending UTXOs created before\nactivation are exempt. Activation uses a modified BIP9 deployment\nwith a reduced 55% miner signaling threshold and mandatory lock-in by\napproximately September 2026. See Newsletter #379 for\nearlier coverage of this proposal.\n-\n● Bitcoin Inquisition #99 adds an implementation of the BIP54\nconsensus cleanup soft fork rules on\nsignet . The four implemented mitigations are: limits on\nthe number of potentially executed legacy sigops per transaction,\nprevention of timewarp attacks with a two-hour grace period (plus\nprevention of negative difficulty adjustment intervals), mandatory\ntimelocking of coinbase transactions to the block height, and\ninvalidation of 64-byte transactions."}
{"url":"https://docs.polkadot.com/apps/product-sdk/signer/","domain":"docs.polkadot.com","title":"Signer | Polkadot Developer Docs","hash":"b3711cf47fc6b3a59766091871bf3a7de83f5ff4c359dc3207a809dfe070c00b","tokens":1908,"chars":7630,"crawler":"crawler-f6nn","verified":"exact","ts":1791172119279,"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- Transactions\n- Cloud Storage\n- Statement Store\n- Local Storage\n- Contracts\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\nSigner ¶\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nIntroduction ¶\n@parity/product-sdk-signer handles account discovery, selection, and signing, decoupled from where the keys actually live. Your Product talks to one class, SignerManager , and the same call sites work whether signing routes to the user's Polkadot App in production or to local dev accounts in a test.\nEvery fallible method returns a typed Result , so you check .ok before reading .value rather than wrapping calls in try / catch .\nWhen to Use It ¶\n- Whenever your Product needs to discover accounts, select one, and obtain a PolkadotSigner to sign transactions or raw bytes.\n- To manage the connection lifecycle: connect, disconnect, subscribe to state changes, and run once-per-session setup through the onConnect hook (for example, requesting permissions).\n- Use the host provider for real signing on Polkadot Desktop and the Polkadot App; use the dev provider for tests with well-known accounts such as Alice and Bob.\n- The product-account and Ring-VRF methods are Host-only; they return HostUnavailableError under the dev provider.\nCore Concepts ¶\n- SignerManager : The central class. It wraps one or more providers behind a Result -typed API and holds a SignerState that it pushes to subscribers.\n- Result , ok , err : The return idiom across the package. Branch on res.ok , then read res.value or res.error ; only unexpected internal failures throw.\n- SignerAccount : A signing-capable account. It exposes the SS58 address , the EVM-derived h160Address (for pallet-revive ), the publicKey , an optional name , and getSigner() .\n- Host vs dev providers : connect() defaults to the Host; connect('dev') loads well-known dev accounts locally, so no Host is needed for tests.\n- onConnect and subscribe : subscribe fires on every state change; onConnect fires exactly once per transition into the connected state (and again after an auto-reconnect), which is where you request resources up front.\n- Product accounts : getProductAccount(dotNsIdentifier, derivationIndex) returns a per-Product account the Host derives, so different Products get different addresses for the same user. This is a Host-only API.\nConnect and Sign Raw Bytes ¶\nConstruct the manager once, connect, select an account, and sign. Each step returns a Result :\nimport { SignerManager } from '@parity/product-sdk-signer' ;\nasync function signHello () {\nconst manager = new SignerManager ({ ss58Prefix : 0 , dappName : 'my-product' });\nconst connectResult = await manager . connect ();\nif ( ! connectResult . ok ) return ; // HostUnavailableError outside a Host\nconst [ account ] = connectResult . value ;\nif ( ! account ) return ; // connected, but the Host returned no accounts\nmanager . selectAccount ( account . address );\nconst signature = await manager . signRaw ( new TextEncoder (). encode ( 'hello' ));\nif ( signature . ok ) {\nconsole . log ( signature . value ); // Uint8Array\n}\nA successful connect can still yield zero accounts\nconnect() resolves with ok([]) — not an error — when dappName is unset or the Host rejects the derivation, typically because the .dot identifier is not registered for that user. Destructure and check before indexing, or value[0].address throws on a path the SDK documents as normal. A Product in that state can still drive the explicit signing paths, such as getLegacyAccountSigner .\nRequest Permissions Once Per Session ¶\nUse the onConnect hook to request resource allocations as soon as the connection is established, before any signing call. Unlike the rest of the package, requestResourceAllocation throws rather than returning a Result , so guard it:\nimport { SignerManager } from '@parity/product-sdk-signer' ;\nconst manager = new SignerManager ({\nss58Prefix : 0 ,\ndappName : 'my-product' ,\nonConnect : async ( _account , { requestResourceAllocation , signal }) => {\ntry {\nconst outcomes = await requestResourceAllocation ([\n{ tag : 'BulletinAllowance' , value : undefined },\n]);\nif ( signal . aborted ) return ; // user disconnected mid-request\nif ( outcomes . some (( outcome ) => outcome !== 'Allocated' )) {\n// Degrade gracefully: treat the capability as unavailable, not fatal.\n}\n} catch ( cause ) {\n// Typed host error — the connection itself is unaffected.\n}\n},\n});\nThree things that example is doing deliberately:\n- try / catch : requestResourceAllocation adapts the Host's Result -returning call into a throwing one, so an unguarded await can throw inside onConnect . Errors thrown here are logged and do not break the connected state, but you lose the chance to react.\n- signal.aborted : The AbortSignal fires if the user disconnects or the manager is destroyed while the request is still in flight. Check it before acting on the outcomes.\n- Checking the outcomes : Each is 'Allocated' , 'Rejected' , or 'NotAvailable' — bare strings here, unlike the tagged objects the auth package returns. See Allowances and Permissions for what each resource authorizes.\nWhy not AutoSigning in this example\nAutoSigning is the most interesting resource to request and the one you cannot rely on: it returns NotAvailable on both the Android and iOS wallets today. Request it if you want, but treat per-transaction signing as the real path and do not build a flow that depends on the grant landing.\nLimitations ¶\n- Most methods return a Result ; branch on .ok . Only terminal conditions such as calling a destroyed manager surface as thrown errors.\n- destroy() is terminal: later calls return DestroyedError . Use disconnect() for a reversible reset.\n- subscribe does not prime with the current state; call getState() for the initial read, and use onConnect for once-per-connect logic.\n- getProductAccount , getProductAccountAlias , createRingVRFProof , and getUserId are Host-only.\nWhere to Go Next ¶\n-\nGuide Sign and Submit Transactions\nThe task-focused recipe: derive a product account, sign, and submit a transaction end to end.\nSign and Submit Transactions\n-\nLearn Transactions\nTake the signer this package produces and submit and track a transaction to finality.\nTransactions\n-\nExternal API Reference\nThe complete signer surface: SignerManager , SignerAccount , providers, and the error hierarchy.\nVisit Site\nLast update: September 2, 2026\n| Created: September 2, 2026"}
{"url":"https://docs.velocity.exchange/protocol/how-it-works/oracles","domain":"docs.velocity.exchange","title":"Oracles | Velocity Protocol","hash":"c9a5641bea3eb45ccb3fc995c8798ca05ad5cf38f1b297c9876f99e40505d7ed","tokens":1561,"chars":6243,"crawler":"crawler-f6nn","verified":"exact","ts":1791172121229,"text":"Velocity Protocol Developers\nMechanics\nView as Markdown\nOracles\nWhy a perpetual exchange has to import a price it does not set, the grades the protocol assigns to an incoming price, and what a trader sees while a feed is degraded.\nA perpetual has no expiry and no delivery, so nothing about the contract itself forces its price to track the asset it names. The two things that do are funding, sized off the gap between the market's mark price and an outside reference, and margin, which values every position against that reference. Both need a price the exchange does not produce.\nWhy not just use the exchange's own price\nThe exchange's own last traded price is the one number a trader can move. An account that pushes the mark price up by trading against itself marks its own long into profit, borrows against that profit, and liquidates the shorts on the other side, without the underlying asset having moved a cent.\nSo every market carries an oracle: an account, written by somebody other than the trader, holding a price, a confidence interval, and a timestamp. The source is set per market.\nWhat breaks when the oracle is wrong\nMargin, liquidation, funding, and the AMM's quote are all measured against the oracle, so a bad print liquidates solvent accounts and pays out on positions that were never in profit. An oracle fails in four ways: a wrong price, a stale price, a confidence band so wide that treating its midpoint as exact understates the error in every margin number, and a data fault such as a zero or a price five times the running average.\nThe protocol does not decide which is happening. It grades each incoming sample, and each action decides which grades it will accept.\nThe six grades\nEvery read is classified into one of six failure grades, or Valid. The default thresholds:\nGrade What it means Default threshold\nNon-positive Any price field at or below zero Fixed, not configurable\nToo volatile The price and the running oracle TWAP differ by a large factor 5x up, or down to one fifth\nToo uncertain The reported confidence is too wide relative to price 2% of price, times the market's tier multiplier\nStale for margin The sample is too old to value a position against 48 seconds\nInsufficient data points Too few publishers were quoting Pyth push only\nStale for AMM The sample is too old for the AMM to quote against 4 seconds\nStablecoin feeds get three times the margin staleness window, 144 seconds rather than 48. The 2% confidence threshold is scaled by the market's contract tier , from 1x on tier A up to 50x on Highly Speculative and Isolated, so the tail tiers tolerate a band up to 100% of price before a sample is too uncertain.\nGrades do not block everything equally\nEach action asks separately whether the current grade is good enough for what it is about to do, and one that can lose money on a stale price is stricter than one that cannot.\nAction Accepts\nAuction-skipping AMM fill Valid only\nLow-risk AMM fill Valid, or stale for the AMM within the low-risk threshold\nMargin calculation, orderbook fill Anything except non-positive, too volatile, too uncertain, stale for margin\nLiquidation, trigger order Anything except non-positive and too volatile\nTWAP update, AMM curve update Anything except non-positive\nFunding update, P&L settlement Valid, stale for the AMM, insufficient data points, stale for margin\nSo a feed that goes 10 seconds without an update stops the AMM quoting while orderbook matching, margin, and liquidation carry on. At 50 seconds margin calculations and orderbook fills stop too, but liquidation and trigger orders still run: a position that is genuinely underwater should not become unliquidatable because the price is old.\nWhat a trader actually sees\nFills get worse before they stop. The AMM is the first thing to withdraw. On a market where it was supplying most of the depth, a degraded feed shows up as an order filling only against resting orders, or not filling at all. Nothing errors; the order waits.\nMargin numbers can freeze. Once a feed is stale for margin, anything requiring a margin check, including opening a position and withdrawing collateral, reverts rather than proceeding on a price the protocol will not stand behind. This is why a withdrawal can fail during an outage on a market the account is not even trading.\nLiquidation still runs. A stale feed does not protect an underwater account. The reverse is less obvious: during a genuine oracle dislocation, wide bands can leave a position that neither its owner can close nor anyone else can liquidate until the price comes back. See Guard rails for the two divergence bands that produce that state.\nFunding is damped, not skipped. While a feed is invalid its TWAP stops updating while the mark TWAP keeps moving. On recovery the price is interpolated toward the mark TWAP, weighted by how long the outage lasted, so a market does not settle a large funding payment because its oracle was absent.\nSources\nTwo sources are supported: Pyth Lazer and Pyth push. The Switchboard and Pyth pull variants are deprecated and rejected onchain. The source is set per market, so read the market account for the one a given market decodes. A Pyth Lazer price is not written by Pyth's own crank: a keeper relays a signed message onchain and the program verifies the publisher's signature before it is used.\nA market that has not listed on either feed can use a prelaunch oracle, which is self-referential: the price is the market's own mark TWAP, clamped to an admin-configured maximum. Such a market has no outside anchor, which is why prelaunch markets sit in the tiers with no insurance coverage and the widest confidence tolerance.\nEdit on GitHub\nKeeper incentives\nWhat a keeper is paid for filling, triggering, cancelling and cranking, why the fill reward is a function of order age rather than order size, and which jobs pay nothing at all.\nWhere the money sits\nOne balance per user fails on the first winning trade. The vaults that hold real tokens, the pools that are only accounting balances, and how value moves between them.\nOn this page\nWhy not just use the exchange's own price\nWhat breaks when the oracle is wrong\nThe six grades\nGrades do not block everything equally\nWhat a trader actually sees\nSources"}
{"url":"https://forum.arbitrum.foundation/guidelines","domain":"forum.arbitrum.foundation","title":"Guidelines - Arbitrum","hash":"d99a700dd4020c3826e0016d69c25df8a5d640490016c7ae52938b3fb6bb4dcc","tokens":1275,"chars":5099,"crawler":"crawler-f6nn","verified":"exact","ts":1791172123198,"text":"Arbitrum\n- About\n- Guidelines\n- Terms of Service\nThis is a Civilized Place for Public Discussion\nPlease treat this discussion forum with the same respect you would a public park. We, too, are a shared community resource — a place to share skills, knowledge and interests through ongoing conversation.\nThese are not hard and fast rules. They are guidelines to aid the human judgment of our community and keep this a kind, friendly place for civilized public discourse.\nImprove the Discussion\nHelp us make this a great place for discussion by always adding something positive to the discussion, however small. If you are not sure your post adds to the conversation, think over what you want to say and try again later.\nOne way to improve the discussion is by discovering ones that are already happening. Spend time browsing the topics here before replying or starting your own, and you’ll have a better chance of meeting others who share your interests.\nThe topics discussed here matter to us, and we want you to act as if they matter to you, too. Be respectful of the topics and the people discussing them, even if you disagree with some of what is being said.\nBe Agreeable, Even When You Disagree\nYou may wish to respond by disagreeing. That’s fine. But remember to criticize ideas, not people . Please avoid:\n- Name-calling\n- Ad hominem attacks\n- Responding to a post’s tone instead of its actual content\n- Knee-jerk contradiction\nInstead, provide thoughtful insights that improve the conversation.\nYour Participation Counts\nThe conversations we have here set the tone for every new arrival. Help us influence the future of this community by choosing to engage in discussions that make this forum an interesting place to be — and avoiding those that do not.\nDiscourse provides tools that enable the community to collectively identify the best (and worst) contributions: bookmarks, likes, flags, replies, edits, watching, muting and so forth. Use these tools to improve your own experience, and everyone else’s, too.\nLet’s leave our community better than we found it.\nIf You See a Problem, Flag It\nModerators have special authority; they are responsible for this forum. But so are you. With your help, moderators can be community facilitators, not just janitors or police.\nWhen you see bad behavior, don’t reply. Replying encourages bad behavior by acknowledging it, consumes your energy, and wastes everyone’s time. Just flag it . If enough flags accrue, action will be taken, either automatically or by moderator intervention.\nIn order to maintain our community, moderators reserve the right to remove any content and any user account for any reason at any time. Moderators do not preview new posts; the moderators and site operators take no responsibility for any content posted by the community.\nAlways Be Civil\nNothing sabotages a healthy conversation like rudeness:\n- Be civil. Don’t post anything that a reasonable person would consider offensive, abusive, or hate speech.\n- Keep it clean. Don’t post anything obscene or sexually explicit.\n- Respect each other. Don’t harass or grief anyone, impersonate people, or expose their private information.\n- Respect our forum. Don’t post spam or otherwise vandalize the forum.\nThese are not concrete terms with precise definitions — avoid even the appearance of any of these things. If you’re unsure, ask yourself how you would feel if your post was featured on the front page of a major news site.\nThis is a public forum, and search engines index these discussions. Keep the language, links, and images safe for family and friends.\nKeep It Tidy\nMake the effort to put things in the right place, so that we can spend more time discussing and less cleaning up. So:\n- Don’t start a topic in the wrong category; please read the category definitions.\n- Don’t cross-post the same thing in multiple topics.\n- Don’t post no-content replies.\n- Don’t divert a topic by changing it midstream.\n- Don’t sign your posts — every post has your profile information attached to it.\nRather than posting “+1” or “Agreed”, use the Like button. Rather than taking an existing topic in a radically different direction, use Reply as a Linked Topic.\nPost Only Your Own Stuff\nYou may not post anything digital that belongs to someone else without permission. You may not post descriptions of, links to, or methods for stealing someone’s intellectual property (software, video, audio, images), or for breaking any other law.\nPowered by You\nThis site is operated by your friendly local staff and you , the community. If you have any further questions about how things should work here, open a new topic in the site feedback category and let’s discuss! If there’s a critical or urgent issue that can’t be handled by a meta topic or flag, contact us via the staff page .\nTerms of Service\nYes, legalese is boring, but we must protect ourselves – and by extension, you and your data – against unfriendly folks. We have a Terms of Service describing your (and our) behavior and rights related to content, privacy, and laws. To use this service, you must agree to abide by our TOS ."}
{"url":"https://eips.ethereum.org/EIPS/eip-7749","domain":"eips.ethereum.org","title":"EIP-7749: Add wallet_signIntendedValidatorData method","hash":"5f99ed23249d0450eda4349bd01459d597d4d5dc4cbdda4560129d4f302b5f53","tokens":1492,"chars":5968,"crawler":"crawler-f6nn","verified":"exact","ts":1791172125468,"text":"Ethereum Improvement Proposals\n⚠️ Draft\nStandards Track: Interface\nEIP-7749: Add wallet_signIntendedValidatorData method\nA new RPC method to sign data with an intended validator address according to ERC-191 version 0x00.\nAuthors\nYamen Merhi ( @YamenMerhi ), Patronum Labs ( @Patronum-Labs )\nCreated\n2024-06-21\nDiscussion Link\nhttps://ethereum-magicians.org/t/eip-7749-add-wallet-signintendedvalidatordata-method/20693\nRequires\nEIP-191 ,\nEIP-712\nTable of Contents\n- Abstract\n- Motivation\n- Specification\n- wallet_signIntendedValidatorData\n- Rationale\n- Backwards Compatibility\n- Test Cases\n- Example\n- Security Considerations\n- Copyright\nAbstract\nThis EIP introduces a new JSON-RPC method, wallet_signIntendedValidatorData , which allows signing data with an intended validator address using ERC-191 version 0x00 with this format:\n0x19 <0x00> \nMotivation\nCurrently, signing messages relies heavily on ERC-191 version 0x45 ( eth_sign ) and EIP-712 ( eth_signTypedData ). While EIP-712 provides a more structured approach, it is often seen as complex. On the other hand, ERC-191 version 0x45 is widely used but poses significant phishing risks due to the lack of data parsing.\nERC-191 defines three versions: 0x45, 0x01, and 0x00. This proposal aims to fully support ERC-191 by introducing the rpc call for 0x00 version, which enables signing data with an intended validator address. This new method will:\n- Enable more dApps to use ERC-191 version 0x00 without using raw signing methods which might be dangerous and restricted in few wallets.\n- Enhance security by parsing data and displaying the intended validator address, reducing phishing risks.\n- Provide a simpler alternative to EIP-712, offering a balance between usability and security.\n- Be particularly relevant for smart contract accounts, allowing signing with a specific intended validator address.\nWith the rise of smart contract accounts and the reliance on signatures to improve UX, the need for supporting ERC-191 version 0x00 increases, especially given the prevalence of verifier smart contracts, such as Entry Points, Smart Contract Accounts, Key Managers, etc.\nSpecification\nThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.\nwallet_signIntendedValidatorData\nMUST calculate an Ethereum signature using sign(keccak256(\"\\x19\\x00\")) .\nThis method adds a prefix to the message to prevent malicious dApps from signing arbitrary data (e.g., a transaction) and using the signature to impersonate the victim.\nParameters\ninterface WalletSignIntendedValidatorDataParams {\nsignerAddress : string ;\nvalidatorAddress : string ;\ndataToSign : string ;\n}\n- signerAddress - 20-byte account address: The address signing the constructed message.\n- validatorAddress - 20-byte account address: The intended validator address included in the message to sign.\n- dataToSign - Data string: The data to sign.\nReturns\nSignature - The Ethereum Signature generated.\nRationale\nThe wallet_signIntendedValidatorData method aims to bridge the gap between the simplicity of ERC-191 version 0x45 and the structured approach of EIP-712. By specifying the intended validator address, it reduces phishing risks and provides a more secure signing method for smart contract accounts and other use cases requiring a specific validator address.\nBackwards Compatibility\nNo backward compatibility issues found.\nTest Cases\nExample\n-\nSigner Address ( 0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0 ): This is the address of the account that will be used to sign the constructed message. We have access to the private key of this address, which allows us to generate the signature securely.\n-\nVerifier Address ( 0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4 ): This address represents the address verifying the signature, could be an EOA or smart contract. For example, it could be a contract that performs specific actions based on the validity of the signature. By including this address in the data to be signed, we ensure that the signature cannot be reused by malicious actors for unintended purposes.\n-\nData to Sign ( 0x59616d656e ): This is the hex-encoded string representing the actual content to be signed. In this example, it is the hex encoding for the ASCII string “Yamen”. The data, combined with the verifier address, is hashed and signed to generate a unique signature that cannot be used for any other purpose.\nRequest:\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"wallet_signIntendedValidatorData\",\"params\":[\"0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0\", \"0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4\", \"0x59616d656e\"], \"id\":1}'\n{\n\"jsonrpc\" : \"2.0\" ,\n\"method\" : \"wallet_signIntendedValidatorData\" ,\n\"params\" : [\n\"0x6aFbBC5e6AFcB251371711a6551E60ead2779Dc0\" ,\n\"0x345B918b9E06fAa7B0e56bd71Ba418F31F47FED4\" ,\n\"0x59616d656e\"\n],\n\"id\" : 1\n}\nResult:\n{\n\"jsonrpc\" : \"2.0\" ,\n\"id\" : 1 ,\n\"result\" : \"0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c\"\n}\nThe result field contains the Ethereum signature generated by signing the hashed message according to version 0 of ERC-191.\nSecurity Considerations\nUsers should exercise caution when signing messages. Double-check the address of the verifier and ensure trust in the dApp triggering the sign request.\nTo protect against replay attacks and cross-chain replay attacks, include chainId and nonce in the validator data to sign.\nCopyright\nCopyright and related rights waived via CC0 .\nCitation\nPlease cite this document as:\nYamen Merhi ( @YamenMerhi ), Patronum Labs ( @Patronum-Labs ), \"EIP-7749: Add wallet_signIntendedValidatorData method [DRAFT],\" Ethereum Improvement Proposals , no. 7749, June 2024. Available: https://eips.ethereum.org/EIPS/eip-7749."}
{"url":"https://discuss.ens.domains/t/namespace-quarterly-reports/19057","domain":"discuss.ens.domains","title":"Namespace - Quarterly Reports - Reports - ENS DAO Governance Forum","hash":"6e7e200a16204d56902917dd611b511c71695a49bd18386db47b4c70800c57f7","tokens":9970,"chars":39878,"crawler":"crawler-f6nn","verified":"exact","ts":1791172129414,"text":"ENS DAO Governance Forum\nNamespace - Quarterly Reports\nService Provider Program\nReports\nservice-providers\ncap\nApril 4, 2024, 1:31pm\n1\nQ1 Namespace Service Provider Report\nUpdates\nNot sure if this is required, but it is my understanding that we need to keep everyone updated every quarter about our progress so I’m posting our Q1 report here.\nSharing what we did each quarter will keep us accountable and transparent to the ENS DAO and everyone who voted for us and supported us to become Service Providers.\nAlso, this is a good opportunity to keep everyone in the loop with what we are doing, share our strategies and plans, and possibly get feedback, help, advice, and learn new things so feel free to comment or ask questions.\nWe want to work together towards improving and growing ENS.\nSummary of Updates:\n-\nPlatform\n-\nTechnical documentation\n-\nPartnerships / integrations\n-\nOther updates / improvements\n1. Platform\nLoom video demo of the Namespace platform with ensdao.eth name used as an example.\nMainnet launched!\nNamespace v2 officially launched on the Mainnet, see the announcement for details: https://twitter.com/namespace_eth/status/1768647652609229147\n*.GotID.eth subnames\nTo celebrate the mainnet launch we issued free offchain Subnames from gotID.eth to our users.\n- Minting offchain subnames\n- Fully resolvable in Metamask\n- You can see them in the ENS App\n- Sets minters address record\n- 30 subnames minted\nFeel free to mint a free Subname for yourself in celebration of the Namespace launch: Namespace\nSearch and Register\nAnyone can search and register available ENS names and unruggable surnames through the Namespace platform.\nWe improved the ENS name registration process - users can now close the ENS registration modal and continue where they left off. We added notifications for pending registrations/transactions.\nAdded options to set address record and primary name for Name registrations.\nFeel free to register any ENS name or subname to test it: https://app.namespace.ninja/\nWidget\nENS Widget is used by ENS Name owners who want to mint unruggable subnames from their own websites or blogs.\n- Widget is live on Mainnet.\n- Integrated with the platform’s front end\n- Configurable and customizable from the platform (no technical skills required)\n- Supporting 4 different widget types\n- Support for ENS second-level name registrations (allowing anyone to sell ENS registration service from their websites)\n- Can be easily integrated with HTML, WordPress, Webflow, or anything else.\nSee more about the widget and how to implement it on your website: https://docs.namespace.ninja/\nTest it yourself here: ENS Widget - Namespace\nManager\nThe manager is responsible for configuring and listing ENS names so people can mint subnames from them.\n- Reduced gas fees by migrating configuration set up offchain\n- Added token-gated minting for communities, allowing people to mint Subname from some ENS name only if they hold certain NFTs\n- Supports ERC 20/721/1155 token standards\n- Improved user experience.\nCurrently, through the Manager, you can:\n- Find and Register ENS Name or Subname\n- List ENS Names and start issuing/selling Subnames\n- Customize Subname minting price based on length\n- Reserve subnames for yourself\n- List specific Subnames for a different minting price\n- Whitelist wallets to either mint or mint for free\n- Token-gate list so that only people with specific NFTs can mint subnames\n- Use the ENS Widget to sell Subnames and provide ENS registration service directly from your website.\nSee more about the Manager in our docs: Overview - Namespace\nOr test it yourself on Mainnet or Sepolia: https://app.namespace.ninja/\n2. Technical Documentation\nOffchain Subnames API\nOffchain subname API support with detailed technical documentation.\nWe offer offchain subname support from now on as well. As we see our mission to grow ENS and integrate it everywhere, it’s hard to deny the interest people and projects have for offchain subnames due to their lack of use and flexibility for the owners in terms of maintaining a certain degree of control over what happens with subnames.\nNamespace offchain subname support includes:\n-\nMinting offchain subname\n1.1. Ability to mint subnames to multichain addresses and associate them to different coin types as per ENSIP-9\n1.2. By default subname minted for coin type 60 (Ethereum)\n-\nSubname data management\n2.1. Check subname availability (if available for minting)\n2.2. Subname address resolution – 1) Subname address resolution through OffchainResolver and CCIP read gateway and 2) Multichain address resolution as per ENSIP-9\n2.3. Data management – Stores and retrieves all data associated with the subname: addresses with coin types, text records, and custom data.\n-\nText record management\n3.1. Create, update, and delete subname text records\n3.2. Retrieve single or all subname text records\n3.3. Text record resolution\n-\nCustom data support\n4.1. Besides text records, the API allows for the storage of custom data JSON objects\n4.2. Create, update, and delete custom subname data\n4.3. Retrieve single or all custom subname data\nAnd we keep updating it and adding more support with each new client we get and per their request.\nFull tech docs can be found on our official docs.namespace.ninja page.\nBack-end API and Smart contracts\nReworked our backend API and Smart Contracts. The backend now handles the creation of listing configuration and gives verification for minting subnames. Listing configurations are now stored offchain so that ENS name owners don’t have to pay high gas fees for listing names and updating listings.\nOverview of our backend infrastructure and listing/minting process\nENS Name Listing process:\n1277×1223 69.5 KB\nMinting process:\n1280×1112 59.3 KB\nHow-to Guides\nEasy to follow tutorials on how to implement ENS Name and Subname for different purposes.\nCurrently, we have a how-to guide on How-To Mint Subnames on L1 from start to finish.\n3. Partnerships / Integrations\nOne of our goals is to integrate ENS everywhere and also to make it easily accessible everywhere, especially for as many developers and teams as possible. That said, we are constantly working on adding ENS to as many different apps, wallets, games, and other products, and also, adding it into a foundational layer to all blockchain tools and infrastructure provider companies, enabling developers quick access and easy integration of ENS.\nUnicorn.eth – smart wallet\nUnicorn uses Namespace’s Offchain implementation for integrating ENS subnames. Unicorn will gift its wallet users subnames from *.unicorn.eth and give them a brandable wallet name.\nWeb3js – JavaScript library for building on Ethereum\nWe built a Web3js Plugin that extends the ENS functionality, by providing the latest ENS features such as:\n- ENS name registration\n- Setting and retrieving text records\n- Setting and retrieving addresses\n- Reverses name resolution\nAnnouncement post: https://twitter.com/namespace_eth/status/1770461554800247166\nTatum – All-in-one blockchain development platform for Web3 builders\nWe built a custom extension that plugs into Tatum SDK helps their developers use ENS easily. Currently supports:\n- ENS name registration\n- Setting and retrieving text records\n- Setting and retrieving addresses\n- Reverses name resolution\nUnlike Web3js, Tatum doesn’t offer any ENS native integration and support so there is a lot we can do to further develop and improve this.\nEverything is ready and deployed, and is pending review and will go live soon. Follow Namespace on Twitter or join /namespace channel on Warpcast to stay updated.\nQuickNode – Blockchain infrastructure provider\nNamespace is the official QuickNode Partner. We built and deployed our own Offchain Subname API as their marketplace add-on. Immediately providing access to easy ENS Offchain integration, allowing smooth ENS Subname issuance and management to more than 125k active developers using QuickNode.\n- Created QuickNOde add-on for Offchain Subnames API\n- Created integration and registration process to allow QuickNOde developers to register and use the API\n- Created support for Payment Plans within the registration process\nShoutout to Evan for the intro <3\nEverything is ready and deployed, and is pending review and will go live soon. Follow Namespace on Twitter or join /namespace channel on Warpcast to stay updated.\nImportant Note\nWe need to meet the developers where they are already building and using the services from existing development providers. Therefore, the Namespace team will continuously support, upgrade, and maintain all custom-built add-ons, plugins, and extensions that make it easy for other developers to integrate and use ENS.\n4. Other stuff\nAs we want to establish ourselves long-term as one of the thought leaders and core teams building around digital identity, we launched a Digital Identity channel on Farcaster with 360+ members already now: Farcaster - join us!\n- New landing page: https://www.namespace.ninja/\n- Removed Goerli references and switched to Sepolia testnet entirely.\n- Infrastructure:\n-\n- Moved our infrastructure to DigitalOcean?\n-\n- Integrated Kibana/Elasticsearch as our monitoring infrastructure\n-\n- Integrated HashcorpsVault as a secrets manager\n-\n- Integrated DigitalOcean mongo managed database\n- And other overall platform improvements, optimizations, and about 12 million bugs fixed.\nOnce again, thanks to everyone who voted for us and supported us so far. We are excited, happy, and honored to be here.\n10 Likes\nSPP2 Namespace Application\nENS DAO Newsletter #66 — 07/30/24\nENS DAO Newsletter #65 — 07/16/24\ncap\nJune 18, 2024, 2:07pm\n2\nQ2 Namespace Service Provider Report\nI apologize for being late with our Q2 report - hungry and foolish.\nSummary\n-\nL2 Subnames:\n- Base Subnames (proof-of-concept which allows minting subnames on Base)\n- OP Subnames (soon with Fault proofs)\n- Dev Docs updates\n-\nOffchain subnames: registration page + stripe integration\n-\nRedesigning and improving the UI/UX of our platform.\n-\nMarketplace functionality (buy, sell, trade, offer, bulk list, bulk buy, etc.) implement (on Testnet)\n-\nPlatform improvements: more features added based on community feedback\n-\nFarcaster + Frames: anyone can mint Subnames through Frames and it’s super easy to set up (no tech skills required)\n-\nPartnerships and Integration: did some more partnerships\n-\nENS during ETH Belgrade: organized an ESN side even during ETH Belgrade and talked about scaling ENS to 1B users\n-\nDevelopment updates: L2 subnames (OP, Base, etc.), Offchain subname improvements, Dev Docs, etc.\nL2 Subnames\nIn Q2, most of our work and focus was centered around L2 infrastructure for subnames on Base and OP, EVM gateway, Fault proof research, and now implementation.\nBase Subnames\nSubnames are live on Base https://app.namespace.ninja - fully open source ( GitHub Link ), built this widget-style proof of concept for everyone to test it.\nImprovements in progress:\n- Proof of concept currently uses a simple CCIP-read resolution, and next, we integrate the EVM gateway for resolution.\n- The subname NFTs are stored in a single registry contract on Base, we plan to have a separate NFT registry contract for each ENS name\n- Developing an indexer/subgraph for l2 subnames\n- Develop a metadata service for L2 subname NFTs\n- Integrate L2 subname functionality with the Namespace platform\nOP Subnames\nBegan integration work on OP fault proofs.\nYou can see and track the progress on our GitHub OP .\nIt’s based on the work done by @chomtana Optimism Dispute Game Support .\nThis will be used to provide the EVM Gateway solution for resolving subnames minted on chains running on the OP stack.\nSimilar work is being done for Arbitrum as well - GitHub ARB .\nThe idea is, to allow any ENS name owner, to list and allow subname minting on any L2 chain with ease and no technical skills required (starting with Base and OP).\nDev Docs\nDocs are getting updated with everything we build including more features around 1) Widget 2) Frames and 3) L2 Subnams.\n- Docs link: https://docs.namespace.ninja/\n- Tutorials: How-to Guides and Demos - Namespace\nOffchain Subnames\nFor Offchain Subnames we built the Registration portal and integrated Stripe but we give the service for free to everyone for now. Users can now generate an API key for their ENS name without our involvement.\nThe registration page used for Quicknode signup has been extended to support direct signups on the platform using Stripe: https://offchain-signup.namespace.ninja/registration/signup\nThe testing with the Stripe test account has been completed, and registration will go live after verifying signups through an actual Stripe account.\n(re)Design\nThe Figma design is finished. Starting to work on it in soon. Screenshots here .\nMarketplace\nNamespace will soon become a fully functional marketplace where people can buy, sell, trade, make offers, etc. on ENS names and subnames.\n- MVP is live at Namespace Marketplace .\n- Currently, you can: buy, sell, make an offer, accept offer, watchlist, bulk list, bulk buy. typical marketplace functionality.\n- Built using OpenSea’s SeaPort.\nThe MVP design is not very good but it won’t go live for another month or so before we have the entire design ready and implemented.\n“GotBase.eth Yet” Campaign for Onchain Summer\nInvite people to get based by minting an ENS Subname on the Base chain. All event participants got a fresh new ENS subname fully stored and managed on the Base chain. We’re only getting started with Base’s Onchain Summer campaign…\nGo and get based yourself GotBased.eth Yet?\n2024-06-17 18.26.57 1280×853 70.2 KB\nPlatform improvements\nBased on the community feedback and request we implemented:\n- Setting prices based on special characters - emojis, numbers, and letters, can now be customized to have different minting prices.\nFarcaster Frames for minting subnames\n- Built an easy way to launch a Frame through which people can mint subnames.\n- The Setup process takes only a few minutes.\n- It requires no technical skills, making it widely available for everyone!\n- Announcement post received quite the love from the community <3: https://twitter.com/namespace_eth/status/1785318762377580787\nStats\nBuilt a Namespace dashboard with live stats: Namespace Dashboard\nScreenshot 2024-06-18 at 16.06.52 1920×800 38.2 KB\n- Unique minter addresses are only showing minter addresses for L1 subnames.\n- The data doesn’t yet reflect L2 and Offchain subnames mints and minter addresses from there.\n- All of these numbers are generated during Q2 only.\nFrames\nSome of the frames we built for the community (which you can test, they are pretty cool):\n1. gotframed.eth\n- Frame: Farcaster\n- Stats: 2500 subnames minted in the first 24 hours\n2. crowned.eth\n- Frame: Farcaster\n- Stats: ~4,500 minted subnames in total\nEverything frames-related is open sourced and anyone can use it and build on top of it however they want - Namespace Frames GitHub .\nPartnerships and Integrations\nTatum integration - finalized\n- Link: https://extensions.tatum.io/extension/namespace-ens-extension\n- Announcement: https://x.com/namespace_eth/status/1786348690522939818\n- Stats: ~56 downloads so far.\nWeb3js integration - finalized\n- Link: https://www.npmjs.com/package/@namespace-ens/web3-plugin-ens\n- Announcement: https://x.com/namespace_eth/status/1770461554800247166\n- Stats: ~440 downloads so far!\nQuickNode (live in Beta) - launching publicly soon, took unnecessarily long…\n- Link: https://marketplace.quicknode.com/add-on/namespace-offchain-subnames\n- Ann Tweet and Stats: soon\nWebHash - anyone can easily add an ENS widget to their website built on Webhash\n- Announcement: https://x.com/namespace_eth/status/1801624177658474997\n- Demo: WidgetID for WebHash Website | Loom\nAdLand ( https://www.adland.space/ )\n- Using ENS offchain subnames to onboard advertising distributors on Farcaster through Frames.\nMany more are in the works. Most of the partnerships and integrations initiated in Q2 are taking longer to finalize given the nature of collaboration and bigger scope of work.\nENS event\nTogether with Blockful ( @netto.eth and Dani), we organized the ENS+Chainlink event during ETH Belgrade and Belgrade Blockchain Week!\nAlex talked about EIP-3668 and how ENS and Chainlink are working\n- Presentation: What do ENS and Chainlink share? The story of EIP-3668 .\nI talked about strategies for scaling ENS, what works, what’s needed, and what the future holds.\n- Presentation: Scaling ENS to 1B users - Strategies for mass adoption .\nMore about the event:\n- Pics: Gallery\n- Video: https://x.com/namespace_eth/status/1800103361070629064\n- Merch: https://x.com/TheCapHimself/status/1798350636788125798\nSome sketches that might be helpful\nL2 Minting Infrastructure: details\nL2SubsDiagram 2766×1794 294 KB\nFetching and verifying L2 data on L1 using EVM Gateway - details\nScreenshot 2024-06-18 at 15.35.55 1920×1097 60.7 KB\nThat’s all.\nIf you’re going to ethCC , I look forward to meeting you! And, feel free to join our “ethCC domain/identity” TG group .\n5 Likes\n☎️ ENS Ecosystem – Weekly Meeting: 12pm ET, Thursday – Term 5\nENS DAO Newsletter #72 — 10/22/24\ncap\nOctober 7, 2024, 2:15pm\n3\nQ3 Namespace Service Provider Report\nAs we move forward with building, experimenting, researching, testing, measuring, tracking results, seeing what are the market needs, demands and trends, how Subnames are being used, figuring out what we do best, and getting to know what other Service Providers are building and getting in sync with each other to maximize our collective output, our direction and path forward is becoming clearer every day. Each Service Provider, tasked to improve, scale, or contribute to ENS in any way, is finding its position relative to how they can best help ENS, and it’s amazing to see it and be part of it!\nUpdates\nL2 chains\n- L2 contracts for minting subnames on Base are available at our GitHub\n- Soon to be updated to support minting subs on Optimism with Fault proofs.\n- Listing ENS names and minting subname on Base chain is available on our platform and you can try it here: Namespace\n- Built an Indexer and Metadata Service for L2 subnames to help us with fetching subnames and records faster.\n- High-level architecture overview:\n2024-10-02 19.42.25 1280×987 65.3 KB\n2024-10-02 19.42.31 1280×1069 69.6 KB\nNamespace SDK\n- Introduced a namespace-sdk , a typescript library built to grow ENS subname registration front-end. It’s used to easily integrate with Namespace contracts and backend API and allows for easy implementation of subname minting in any dapp.\n- Created dev docs for the SDK: How-to Guides and Demos - Namespace\n- Create a “ how-to guide ” for minting L2 subnames using the SDK and the entire mint flow overview .\nOther tech updates\n- Added health checks on our backend services, error handling, and notification system for issues.\n- End-to-end testing (in progress): using Synpress to test the application flow whenever we push new updates.\n- Created a Namespace Builders TG group for anyone implementing our SDK for minting subnames on L2s. Feel free to join if you’re interested in testing and giving us feedback!\n- Added a notification service for minting subnames\n- Added functionality for tracking the source of minting L2 subnames\n- Since subs can be minted from 1) platform, 2) widget, or 3) SDK\n- Marketplace functionality finished: buy, sell, make offer, accept offers, bulk list, bulk buy. Last quarter we implemented and tested everything on Sepolia, now audited and waiting to be merged on the new platform.\nNamespace stats (since last quarter)\nL1 subs\n- Listed names: up 44%\n- Minted L1 subnames: up 71%\n- Unique lister addresses: up 41%\n- Unique minter addresses: up 125%\n- Frames created: up 14%\n- Widgets created: up 60%\nL2 subs\n- Base subnames minted this quarter: 1,786\nOffchain Subnames\n- Total of 7,869\nNew design\n- Started implementing the new design\n- Old app GotBased.eth page\n- New app GotBased.eth page\n- Minting supported on both. The new app is being actively worked on and will be ready for public launch in the next few weeks.\nTeam\n- One of our core team members left which left us with a lot of work for one month until we found replacements.\n- We were fortunate to find (fairly quickly) two new amazing developers who joined Namespace part-time.\nExpenses\n- Namespace is receiving a streaming grant of 200k (16,666$ per month) and has 3 team members full-time, 2 contributors working part-time, and 1 designer on a monthly retainer. Therefore, our biggest expense is the team salaries, but we managed to build an amazing team and fully maximize our monthly grant.\nAudit\n- Namespace L2 contracts are getting audited by a team at Code Arena, with hand-picked members who have worked on all ENS audits in the past.\nBase(d) stuff + Onchain Summer\n-\nTo avoid spam and lots of links, a summary of all Base-related activities we did can be seen here .\n-\nMusicaW3.eth - a community of indie Latin America musicians, together with @estmcmxci , mint Base subnames to their fans! Try it now .\n-\nENSkeychain.eth : a campgain in which minting subnames gets you a personalized ENS keychain with your avatar.\n-\n1449 gotbased.eth subnames minted:\n- Announcement: https://x.com/namespace_eth/status/1810796963899789499\n- Jesse Pollak, founder of Base, got based too: https://x.com/jessepollak/status/1810840908772036773\n-\nENS on Base – artwork dedicated to celebrating ENS expansion to Base\n- Collaboration with onchain reputation protocol Orange Protocol .\nEcosystem\nPrivy wallet\n- Assisted devs and ecosystem project builders to get direct access to ENS name registrations and resolution using our Web3js plugin: https://www.npmjs.com/package/@namespace-ens/web3-plugin-ens and got a shoutout on https://x.com/privy_io/status/1805965470782419103\n- Exploring more stuff…\nWebHash partnership\n- Integrated Namespace Widget that not only supports Subname minting but also allows people to mint ENS names directly from their websites. Currently, the widget is implemented on 74 websites .\nETH Antwerp\n- Subnames for all attendees of the ETH Antwerp conference\nWeb3js Hackathon for West African countries\n- Web3js hosted a hackathon workshop for devs in West Africa and Namespace was very happy to participate and spread the knowledge about ENS and reward the best products built using ENS.\nENS Twitter space : https://x.com/ensdomains/status/1800951149995962829 950 people joined to hear us talk about Subnames.\nLots of other things in the works.\n4 Likes\n☎️ ENS Ecosystem – Weekly Meeting: 12pm ET, Thursday – Term 5\nENS DAO Newsletter #71 — 10/08/24\ncap\nJanuary 29, 2025, 10:57am\n4\nSorry we’re late. We took time off in the first half of Jan. And in the last 2 weeks, we were swamped with work.\nQ4 Namespace Service Provider Report\nTL;DR\n- Integrated Optimism subnames in our app – easy gifting, selling, and management of subnames on Optimism\n- Released Subpages – a template for quick and customizable subname-minting pages\n- Adopted by 5 websites.\n- Enhanced Offchain Subnames with SDK integration and API improvements\n- 10,000+ registrations via ETH Denver Wallet.\n- Started advancing our GitHub organization, to build a developer community of contributors - profile restructuring, issue templates, and release automation.\n- Made major progress on the V2 app with improved ENS profile management and new listing functionalities.\n- Created a new architecture for the backend, which is now split into multiple scalable microservices, boosting performance, scalability, and reliability.\n- Revamped our infrastructure, migrating from virtual machines and managed apps, into a distributed Kubernetes-based setup.\n- ENS Widget is live on WordPress.\n- Published a Domain Tokenization Tutorial to inspire and streamline subname issuance through Web2 domains.\n- Many ongoing convos about partnerships and integrations – wallets, AI agents, protocols…\nUpdates\nOptimism\nOfficially launched Optimism subnames on the Namespace dapp, enabling anyone to gift, sell, and manage subnames directly on Optimism.\nScreenshot 2025-01-29 at 01.23.38 1670×468 20.2 KB\n- Announcement: on X announcement .\n- 260 Subnames minted on OP and onboarding 4 OP communities at the moment to launch OP Subnames.\n- Launched oppunks.eth, an experimental subname minting and management page, allowing users to mint subnames with a cool ENS name and PFP on OP.\n- Ran giveaways and livestreams to increase Subname awareness for ENS and OP.\nOp punks, which started as an experiment, led to the creation of Subpages, based on people’s demand for custom good-looking subname-minting pages.\nProduct launch: Subpages\nSubpages are a GitHub repo with a web page template with built-in subname minting and wallet integration service.\n- Key Benefits: Reduces the time required to launch a functional subname minting page to mere minutes.\n- Ideal for brands, communities, or anyone needing a custom-designed ENS subname page.\n- Adoption: 5 projects already launched using the template, with more in development (e.g., PizzaDAO , Nectar , StayOnEth , OP Punk ).\nI encourage people to try it. It’ll take you 15-20 min to deploy a fully customized Subname minting page. If you need some assistance, join our Builder chat on Telegram.\nOffchain Subnames\nWe continue to refine our Offchain subname offering based on our clients’ needs which leads to fine-tuning and perfecting it making it increasingly easier and more intuitive to implement in other dapps, but primarily wallets.\n- Started migrating the Offchain API to be fully integrated into the Namespace SDK for quicker and simpler implementation.\n- Introduced an alpha version of namespacesdk/offchain-manager (TypeScript library).\n- Updated the backend API to support dynamic API key generation.\nTotal Offchain Subnames: ~17,800!\nMore stats here . A new and improved backend will help us to have more detailed stats about ENS usage, primarily subname registration and where they are coming from.\nSuccess stories: ETH Denver hits 10k subnames\nETH Denver wallet issued 10,000 Offchain subnames from .ethdenver.com .\nIf you’re going to ETH Denver this year and used their wallet to get a free ticket, congrats, you used the Namespace platform for subname minting\nIf not, what are you waiting for: ethdenver.com\nWe made this Domain Tokenization Tutorial to help them onboard more clients in the future.\nGitHub\nOur long-term goal is to cultivate a developer community of ENS Subname and onchain identity enthusiasts who want to contribute to spreading the adoption of ENS by doing more integrations and submitting PRs to our existing SDK with potential improvements and add-ons. Therefore, we’ve started making organizational changes to our GitHub to accommodate for these upcoming changes and allow anyone to participate in making Subnames better and more widespread.\n- Restructured our public GitHub profile\n- Added issue template for public (and internal) contributors\n- Added template CONTRIBUTORS, LICENCE, etc. publicly facing files for open-source contributors to adhere to\n- Created project structure for GitHub issues\n- Created release automation for the Namespace SDK\nInfrastructure\nRebuilt our infrastructure. Previous VMs and managed apps are now swapped for a Kubernetes-based infrastructure. We are now utilizing open-source solutions to provide a platform for all our services. We are aiming for <5min deployments for new static websites, and <30min deployments of stateful applications.\nFurthermore, we started working on a detailed monitoring solution, which will allow us to track every detail of our services, with a possibility to open source it for other teams to be able to track stats for their own subnames.\nV2 app\nProgress report: Created a staging environment for the v2 app where everyone can keep track of our progress: app-stage.namespace.ninja\nImproved ENS name profile pages for both names and subnames\n- You can now update records on L1s and L2s\n- Update and upload the avatar and cover page\n- Manage subnames (mint or optionally delete subs, and edit records)\n- Manage and update the listing\nAdded additional functionality to our listing\n- Token gating now works on any chain\n- Select listing currency (ETH / USD)\n- Select a wallet that will receive funds from minting\nBackend\nDesigned a new architecture and started the implementation of our new backend. The old monolith is now split into multiple microservices, with strict separation of concerns and logical isolation between components.\nThe Kubernetes infrastructure accompanies the 3 new microservices to provide us with a plenary setup for the workloads.\nNewly designed services are:\n- Mint Manager\n- List Manager\n- Utility Manager\nENS Widget – live on WordPress\nENS Widget lets people start issuing subnames from their websites. They can add it in 5 minutes by embedding a minting script generated once they list .eth name on Namespace.\nWe added ENS Widget to WordPress, making it easily accessible to millions of users who use WordPress to build websites!\nDocs and a guide on how to use it will soon be published. We’re working on an official WordPress listing to be discovered through their plugin store.\nStats: integrated into 105 websites\nOther than that, we like to keep busy as usual. Lots of ongoing conversation about integration primarily with wallets, and communities. Did some work on the AI agent side of things that I cannot wait to tell you more about. Overall, starting strong in 2025 with no plans to stop any time soon.\nHappy New Year!\n1 Like\nENS DAO Newsletter #80 — 2/11/2025\n☎️ ENS Ecosystem – Weekly Meeting: 11am ET, Thursday – Term 6\ncap\nApril 16, 2025, 9:56pm\n5\nQ1 (2025) Namespace Service Provider Report\nGoq0-SxWQAUCaar 1024×1024 200 KB\n(thanks to @blockful team for the pic <3)\nHighlights & Launches\n- New landing page launched + small branding tweaks.\n- ETH Belgrade Partnership – ongoing for custom impelementation.\n- Subpages Launched – a white-label, open-source solution for brands, developers, and communities to quickly spin up custom websites with subname minting embedded.\n- Some features:\nScreenshot 2025-04-16 234108 772×321 23.7 KB\n- SheFi Partnership (to be announced officially) – Subname minting live at shefi.namespace.ninja\n- Built-in sponsored wallet to cover gas fees\n- Set as primary name function enabled\n- Subnames minted on Base\n- ~ 350 .shefi.eth active primary subnames set\n- 10-20 daily subname mints, expecting 10k mints.\n- PizzaDAO Subnames – Launching soon, see preview: https://pizzadao.namespace.ninja/\n- Mini Campaign – StaysOn.eth – Ethereum alignment campaign + stress-test for Subpages\n- New Milestone hit this quarter: 30,000 SUBNAMES (and counting…)\nScreenshot 2025-04-16 233106 594×524 147 KB\nProduct Updates\nBiggest update – finally complete entire infra migration from Digital Ocean to Google Cloud.\nNamespace V2 App\n- Current version under testing: staging.dapp.namespace.ninja (feedback welcome)\n- The new listing process has recently been added and is being tested\n- Separated Listing and Minting services\n- Backend upgraded for scalability\n- Live on Sepolia\nDev Portal Launched\nwqeqweqweqweqwe 1200×624 93.4 KB\n- Announcement + thread .\n- Dev-focused app.\n- Currently supports Offchain Subnames\n- 69 API keys created\n- 22 names listed\n- Features :\n- Quickly create subnames\n- Edit, update, manage records\n- API key to plug into your app\n- Crispy clean docs\n- Scalable infrastructure\n- Clean and simple UI/UX\nSDK + Dev Docs\n- Updating Developer documentation\n- Deprecated Namespace Client – everything is running using SDK now\n- Rebuilt the SDK with clearer module separation:\n- @namespacesdk / offchain-manager → managing offchain subnames\n- @namespace / indexer → indexing data\n- @namespacesdk /mint-manager → minting subnames\nAgents.Domains\n- Ongoing improvements, backend refactor, and new site (in design – Figma ready )\nNamespace Blog (live)\n- A bit of focus on SEO, long-term content, and educational efforts.\nQuickNode ENS Plugin\n- Adopted by 50+ clients (all organic growth)\n- Offers Subname services\n- Need to update it to use our new infra\nReal-time Subname Minting Alerts\n- Tracking live subname mints in Discord.\nOther updates\nENS-related articles (published this quarter):\n- ENS lessons from the tranches ( Link )\n- ENS Service Providers (‘24) ( Link )\n- .eth stays on ( Link )\n- Namechain Ecosystem: Late night thoughts ( Link )\n- ENS: To a Billion and Beyond ( Link ) (December 5, 2024 but still noteworthy)\nOngoing BD Efforts – For partnership updates, see our ENS SPP2 Application .\nSubname-as-a-Service – Pitching, testing, and pioneering SaaS-style ENS implementations where companies would enable and offer Subname registrations as a service along with their core service offering.\nDomain Tokenization Research – Seeing a lot of interest in domain tokenization for subname usage!!! Hence, early research is underway to explore tokenized domains and streamlining their tokenization, adoption, and growth.\nNamespace Rewind: A year of ENS Success ( Livestream )\n- Hosted a livestream highlighting ENS success in 2024\n- Guests: @AvsA , @Griff , @don.nie , @Coltron.eth , and @jamesbeck .\n- Covered key ENS milestones, DAO highlights, and Ecosystem wins\n- 500 live livestream viewers (X + YouTube)\nENS Metamask magic in action .\n3 Likes\n☎️ ENS Ecosystem – Weekly Meeting: 11am ET, Thursday – Term 6\nENS DAO Newsletter #85 — 4/22/2025\ncap\nJuly 14, 2025, 9:35am\n6\nQ2 (2025) Namespace Service Provider Report\nIt’s been a packed month behind the scenes – heavy on product and infra work, and with traveling and attending events, and a lot of energy dedicated to hiring and team expansion. We also spent time engaging with the broader ENS ecosystem during the service provider voting period, while continuing to build and support integrations in the background and plan accordingly. So this quarterly report will focus just on some highlights only.\nHighlights\nStats\n- 90k total subnames issued\n- 1.4M total resolutions (since the migration to Google Cloud 2 months ago)\n- 200+ ENS names ‘activated’ (i.e., issuing subnames on our platform)\nEvents\nETHPrague\n- Meeting with potential clients and partners\n- Briefly spoke to Vitalik about ENS\nETHBelgrade\n- Participated as an official event partner\n- Met with wallet providers, payment apps, etc.\nethCC\n- Met with ENS folks, representing ENS\n- Engaged with projects exploring ENS integration\nEcosystem:\nPinMe / PinIt:\n- Issued 65k subnames used as decentralized websites (via IPFS and Glitter protocol)\n- Generated over 1.2M monthly contenthash resolutions in a month (showing real usage)\nSheFi :\n- Hit a 500 Base subnames milestone: https://x.com/namespace_eth/status/1922278663460159964\nEFP :\n- Added EFP support in for our App.\n- https://x.com/BrantlyMillegan/status/1930321643437732039\n- https://x.com/namespace_eth/status/1930313618522026252\nTech\nScreenshot 2025-07-14 at 11.29.16 2608×774 155 KB\n- New stats dashboard .\n- Migrated Subpages to Google Cloud\n- Docs improvements\n- Overall improvements\n- Added open API endpoints\n- Added Userback (allowing app users to submit feedback, bugs, feature requests)\n- Soft-launched v2 version of the dapp\n- Features:\n- Subname search\n- Subname minting with the ability to set the profile in 1 tx\n- Account page with primary name profile\n- EFP support\n- Profile pages for ens names and subnames\n- Profiles support regular and CCIP-read names\n- Ability to update texts/addresses/contenthash for both L1 and L2 subnames\n- L1 and L2 Listing implemented\n- ENS Widget creation\n- Shoutout for Namespace SDK .\n1179×592 116 KB\nOther:\n- Hiring completed : 📢 Namespace is Hiring! - Namespace\n- Received >500 applications\n- Did >30 interviews\n- Hired 3 amazing people!\n- Harpreet , Pedro , Usman .\n- Did one Podcast episode talking about ENS, use cases, subnames, TLDs, etc.\n- Link here .\n- Exploring TLDs.\n9 Likes\n☎️ ENS Ecosystem – Weekly Meeting: 11am ET, Thursday – Term 6\nENS DAO Newsletter #92 — 07/29/25\nService Provider Program Watch\ncap\nNovember 3, 2025, 10:59am\n7\nQ3 (2025) Namespace Service Provider Report\nApologies for the delay in our report.\nTechnical updates\nOur work remains centered around offchain and onchain subnames, developer tooling, and frontend apps for them, AI agent-related work, along with working on custom solutions for high-value partners.\nOffchain Subnames (prev. Dev Portal)\nKept improving our Offchain manager. Now has more granular access control and production-grade reliability, making it easier for large partners to issue subnames safely and at scale with different permission levels.\n- Added a scope-based authentication service to our Offchain manager that allows API keys to be created with different permission levels for:\n-\n- individual domain name or\n-\n- wallet address containing a lot of domain names.\n- Enhanced security and reliability by refining integration and E2E tests.\n- Introduced enhanced API rate-limiting and monitoring dashboards for partner projects (in testing).\nOnchain Subnames (prev. Namespace App)\nThe V2 app was initially planned for release earlier, but we decided to undertake a full rebrand ( early view ) to better align with Namespace’s mission and direction. This decision extended the launch timeline slightly but will result in a more cohesive and long-term product identity.\n- The V2 app is closely connected to the UI Component Library below.\n- Working on the new most requested features, such as revenue sharing, gas sponsorship, multi-token payouts, etc.\n- Launch expected this quarter.\nUI Component library\nWe continue building modular UI components which will be used for the V2 app, and launched the initial version of our component library to further decentralize the usability of our front-end app and make the subname UIs reusable by other teams working with names/subnames.\n- There are 3 main Modals we use internally and could/will be used by others:\n-\n- ENSRecordsForm\n-\n- OnchainRegistrationForm (coming soon)\n-\n- OffchainRegistrationForm (coming soon)\nDevX (SDK/API)\nSignifant effort has gone in the last 3 months to improve developer experience.\n- Published New Docs – Announcement .\n- Published at: https://docs.namespace.ninja/\n- Major updates to SDK and API .\n- Introduced How-To Guides\n- LLM-friendly – Build with AI .\n- Launched Integrations page : Ready-to-use integration examples and starter kits to simplify subname registration implementation.\n- RainbowKit starter kit announcement .\n- Privy and Openfort are launched.\n- More coming soon.\n- SDK updates:\n- Moved under our organization @thenamespace / and improved the DX.\n- Deployed and improved:\n- @ thenamespace/mint-manager\n- @ thenamespace/offchain-manager\n- @ thenamespace/ens-components\n- @ thenamespace/indexer\n- Check the Changelog for activity and all updates.\n- Deployed an improved Metadata service .\nInfra/DevOps\n- Implemented an alerting system for component failure.\n- Introduced a mature observability (monitoring and logging) system-wide.\n- Built a disaster recovery system around most sensitive system components.\n- Major tooling upgrades to the latest version.\nBD / Partnership / Integrations\nNamespace team has been actively engaged in business development and partnership discussions throughout the past quarter. We’ve explored new strategic opportunities, refined outreach strategies, and collaborated on several promising leads with the ENS ecosystem. Our BD efforts represent a mix of long-term prospects we’ve nurtured over the past few years and newly emerging ones.\nThe most significant (and biggest) ongoing collaboration and initiatives are with a major L2 network, where we developed (and launching soon) a custom chain-wide identity solution, similar in nature to Basenames . In parallel, we’re in early discussions with the Pakistan Crypto Council, a government-led initiative exploring how to strengthen their participation in the Ethereum ecosystem, and under our advisory, considering ENS as the starting point of onchain identity."}
{"url":"https://docs.cosmos.network/evm/latest/documentation/getting-started/tooling-and-resources","domain":"docs.cosmos.network","title":"Tooling & Resources - Cosmos Docs","hash":"8cd6a2b106649c07b46e0510b96b77eac65ebe7528ea9ae37d553c463745cf0c","tokens":709,"chars":2835,"crawler":"crawler-f6nn","verified":"exact","ts":1791172131856,"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\nDocumentation\nAPI Reference\nChangelog\nBuild\nTooling & Resources\nTools, libraries, wallets, and explorers for building on Cosmos EVM.\nCosmos EVM implements a complete Ethereum execution environment, so the standard development toolchain carries over without modification. You can use any of the EVM tools you already know; just point them at your chain’s RPC endpoint and chain ID.\nDevelopment Tools\nThe following tools are a few examples of the many tools that are available for development on Cosmos EVM:\nTool Description\nHardhat JavaScript/TypeScript-based framework with a flexible plugin system and Ethers.js integration.\nFoundry Rust-based toolkit with Solidity-native tests and fast execution. Includes forge , cast , anvil , and chisel .\nOpenZeppelin Contracts Audited implementations of common standards — ERC-20, ERC-721, access control, and more.\nClient Libraries\nLibrary Description\nEthers.js JS/TS library for contract interaction, transaction signing, and provider management.\nViem TypeScript-first, tree-shakeable library for RPC calls, ABI encoding, and contract access. Used by Wagmi.\nWagmi React hooks for wallet connection, chain state, and contract reads/writes. Built on Viem.\nRainbowKit React component library for wallet connection UI. Integrates with Wagmi.\nWallets\nSee the quick-start guide for a walkthrough of connecting MetaMask to a local chain. The following are a few examples of the many wallets that are available for development on Cosmos EVM:\nWallet Notes\nMetaMask Add network via Settings → Networks\nRabby Add network via Settings → Networks\nWalletConnect Standard WalletConnect integration\nKeplr Supports both Cosmos and Ethereum transaction formats\nLeap Supports both Cosmos and Ethereum transaction formats\nLedger Compatible via MetaMask or other wallet interfaces\nTo add a chain manually, you’ll need: the network name, RPC URL (port 8545), chain ID, and currency symbol.\nBlock Explorers\nCosmos EVM chains support two types of explorer: EVM explorers for Ethereum-formatted data and Cosmos explorers for Cosmos and IBC data. Mintscan supports both but requires a custom integration.\nExplorer Type Link\nBlockscout EVM GitHub\nPing.pub Cosmos GitHub\nBigDipper Cosmos GitHub\nTesting & Analysis\nTool Purpose\nSlither Static analysis — detects common vulnerability patterns in Solidity.\nsolidity-coverage Reports untested code branches. Works with Hardhat and Foundry.\nEchidna Property-based fuzzer for Solidity contracts.\nOpenZeppelin Test Helpers Time manipulation, event assertions, and revert testing for Hardhat/Mocha.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://ethereum.org/payments/","domain":"ethereum.org","title":"Payments on Ethereum | ethereum.org","hash":"25b342961d5bfe7617a6cd276b7bf4c0d741d1e4c666e33a684344986213e80f","tokens":3312,"chars":13245,"crawler":"crawler-f6nn","verified":"exact","ts":1791172134399,"text":"Skip to main content\nEthereum Payments\n- A world where money moves as freely as information\n- Open and global, enabling borderless transactions for everyone\n- Payments received within a minute\nEdit page (opens in a new tab)\nEvery day, millions of people face the same challenge: moving money across borders is slow, expensive, and often frustrating. A freelancer in Bali waits days for payment to clear from their New York client. This particularly affects people in regions with limited banking infrastructure, making it difficult to participate in the global economy.\nThis isn't a far-off dream—it's happening today on Ethereum. While traditional financial institutions have built robust payment systems over decades, they often remain constrained by borders, working hours, and legacy infrastructure. Ethereum offers a new paradigm: a global, 24/7 financial platform that enables near-instant, programmable transactions for anyone with internet access.\nRemittances: cheaper international transfers\nFor millions of people working abroad, sending money back home is a regular necessity. Traditional remittance services often come with high fees and slow processing times. Ethereum offers a compelling alternative.\nCheaper Fees\nRemittance services charge up to $14 fees on average. Ethereum transactions can often be completed under $0.01.\nFaster Transfers\nInternational wire transfers take several days to process. Ethereum transactions are settled in minutes.\nOpen to anyone\nYou only need an internet connection and a wallet app to send or receive Ether.\nAccess to global currencies\nIn many countries, inflation is a pressing concern, often accompanied by limited access to foreign currencies. People in these situations struggle to preserve their wealth as they are forced to hold rapidly depreciating savings.\nThe Ethereum community has created a robust alternative financial system that is independent of any nation’s monetary policies or control.\nEthereum users can use stablecoins—tokens typically tied to strong currencies like the US Dollar . By earning and saving in cryptocurrency, people can protect themselves from high inflation in their country, helping to preserve or even grow their purchasing power. This also enables easier payments for goods and services, both locally and globally.\nMore on stablecoins\nBuying goods and payment for services\nMany businesses are beginning to accept ether (ETH) and other cryptocurrencies as payment. For example:\n- Newegg: The popular electronics retailer accepts Ethereum for purchases in select countries.\n- Travala.com: This travel booking platform allows users to pay for hotels and flights using Ethereum.\n- Shopify: This popular E-commerce platform which serves as a platform for hosting businesses also accepts payments for goods and services using Ethereum.\n- Sotheby's: This organization trade fine and decorative art, jewelry, and collectibles and allows for payments using Ethereum and other cryptocurrencies.\nCountries like El Salvador and the Central African Republic have even adopted cryptocurrencies as legal tender, paving the way for wider acceptance of Ethereum payments in everyday transactions.\nIn countries where their means of payment have been disconnected from the rest of the world, crypto-integrated payment solutions have been a huge relief. Payments of subscriptions for platforms like Netflix, Spotify, and educational courses have now been made easy through crypto payment platforms like Gnosis Pay and Paypal.\nCreate your Ethereum account with a wallet app today.\nGet started\nPay with self-custodial crypto cards\nSelf-custodial crypto cards work like using your own backpack instead of locking your money in someone else’s vault. With a traditional card, a bank or custodian holds your funds and releases them when you spend. With self-custodial cards, you stay in control of your assets the whole time—no middleman—while still being able to tap or swipe to pay for coffee, groceries, or even a flight.\nThese cards link directly to non-custodial wallets or smart contract accounts, allowing users to spend ETH and stablecoins in everyday settings without giving up ownership. Unlike custodial cards, which require users to deposit funds with a third party, self-custodial cards enable real-world payments such as Visa and Mastercard while preserving onchain control.\nExamples\n-\nMetaMask Card: Linked to the MetaMask wallet, this Mastercard debit card lets users spend ETH, stablecoins, and other supported tokens. It supports Apple Pay and Google Pay, includes crypto cashback rewards, and offers yield-earning options.\n-\nTuyo Card: A smart contract–based Visa card that auto-converts crypto to USDC for spending anywhere Visa is accepted. Users keep custody of their assets, with access to yield, trading, and spending features.\n-\nGnosis Pay: The first self-custodial Visa card tied to a Gnosis Safe smart account. Users spend crypto directly from their wallet with no gas, FX, or off-ramping fees. Card personalization via Ethereum Name Service (ENS) is also supported.\n-\nEther.Fi Cash card: Integrated with ether.fi’s staking protocol, this card lets users spend while their ETH remains staked. Payments are handled via smart contracts, maintaining self-custody even while spending.\nSelf-custodial crypto card comparison\nCrypto card Self-custodial Non-custodial Key notes\nMetaMask Card ✅ ✅ Wallet stays in MetaMask; auto off-ramp at payment\nTuyo Card ✅ ✅ Smart wallet converts to USDC; user retains control\nGnosis Pay ✅ ✅ Linked to user’s Gnosis Safe; no custody shift during use\nEther.Fi Cash ✅ ✅ ETH remains staked; smart contract controls spending access.\nNote: \"Self-custodial\" refers to user-controlled wallets where the user has full access and control over their funds.\n\"Non-custodial\" refers to wallets where funds are managed without third-party custody, often through smart contracts.\nWhile all self-custodial cards are non-custodial, not all non-custodial cards are self-custodial.\nMicro-payments for websites & agents (x402)\nx402 (opens in a new tab) is an open payment standard that brings native per-use payments to the web. By using stablecoins on low-cost Ethereum layer 2 networks , the x402 standard makes it economical for humans and machines to pay directly for a single action, such as reading a news article or calling an API, rather than managing API keys, subscriptions, or “paying” by giving attention to advertising.\n- Removing paywalls and logins: Instead of creating an account and sharing personal information to read one news article, your wallet can pay the few cents required to unlock it.\n- Payments for AI agents: x402 enables autonomous software (\"AI Agents\") to pay for the data and API calls they need to function, without human intervention.\nHow the x402 payment standard works\nWhen a client requests a resource, the server sends a 402 Payment Required error code along with payment instructions (price, account, and what tokens and chains are supported).\n- Your wallet detects the request and handles the payment (often with a single click to approve, or automatically using a pre-approved allowance)\n- AI agents with access to pre-approved wallet balances can automatically detect the price and pay instantly to access data or services\n- The client needs to have one of the supported stablecoins in their wallet, but does not need to have any ETH for gas expenses\nThis unlocks a new \"machine to machine\" economy where AI agents can buy resources on their own, and where API services can be accessed more efficiently.\nThe signed message is then delivered to the server. Servers typically use an x402 facilitator (opens in a new tab) to handle the blockchain complexity (sending the transaction, obtaining the payment, facilitating gas fees, etc.), which means that developers can easily accept crypto micropayments without managing payment infrastructure.\nSalary payments\nMany forward-thinking companies are now offering employees the option to receive their salaries, or a portion of them, in cryptocurrencies like ether (ETH):\n- Gipsybee: is an organization that deals in electronics, robotics, game creation and other services. They give employees the option to get paid in Ethereum.\n- SC5: This Finnish company was one of the first to offer salaries in Bitcoin, paving the way for similar arrangements with Ethereum.\n- Blockchain startups: Many companies in the blockchain space naturally offer cryptocurrency salary options to their employees.\n- DAOs: Due to the peculiarity and diversity of contributors to DAOs, most contributions and salaries are rewarded in cryptocurrency.\nThis trend particularly appeals to remote workers and digital nomads who can benefit from borderless payments and potentially favorable exchange rates.\nGlobal relief efforts\nIn February 2023, when devastating earthquakes struck Turkey and Syria, the global crypto community sprang into action. Various campaigns were launched to collect funds for relief efforts, showcasing the power of Ethereum in times of crisis. Despite crypto not being a recognized form (opens in a new tab) of payment in Turkey, authorities made exceptions (opens in a new tab) for some organizations to collect donations. Some examples are:\n- Refik Anadol (opens in a new tab) : is a renowned digital artist who initiated a fundraising campaign.\n- DAO Power: Anka Relief DAO (opens in a new tab) and Bankless DAO (opens in a new tab) joined forces with Giveth (opens in a new tab) to raise funds.\n- Pak (opens in a new tab) , a prominent NFT artist, also contributed to the cause.\n- Even Ethereum co-founder Vitalik Buterin (opens in a new tab) made personal donations to multiple campaigns.\nThe result of this? Over $6 million was raised in a matter of days, as tracked by a Dune (opens in a new tab) Analytics dashboard.\nThere were also similar response times for tragedies that happened in India and Ukraine. This rapid response highlights a crucial advantage of Ethereum payments, which is the ability to quickly mobilize global support without the hurdles of currency conversion, lengthy bank transfers, or exorbitant fees.\nCrypto payments on Ethereum vs. fiat payments\nTo truly appreciate the impact of Ethereum payments, it's worth comparing them to traditional fiat currencies:\nEthereum Traditional banks\nSpeed Seconds to minutes Hours to days\nGlobal Reach Borderless, 24/7 Subject to international banking restrictions and work hours\nTransparency Fully transparent Varies by institution\nProgrammability Smart contracts enabled Limited to basic transactions\nInflation Control Predictable issuance Subject to central bank policies\nAccessibility Anyone with internet Subject to national and international restrictions\nAt its core, Ethereum is a decentralized platform that allows for secure, fast, and transparent transactions. However, many components set it apart from traditional payment methods. Let's dive into the benefits that make Ethereum payments a game-changer:\nProgrammability\nOne of Ethereum's unique features is its ability to support smart contracts. Smart contracts are self-executing agreements with the terms directly written into code. This opens up a world of possibilities for automated, condition-based payments that can greatly improve transactions like:\n- Escrow services\n- Recurring payments\n- Performance-based compensation\nSpeed\nDo you remember the last time you waited days for an international bank transfer to clear? The long queue? And the multiple forms you had to fill? With Ethereum, those days are long gone. Transactions on the Ethereum network settle in minutes, regardless of where the sender and recipient are located. Due to Ethereum being permissionless, there is no regulatory bureaucracy when sending money. This speed is particularly crucial in time-sensitive situations, such as emergency relief efforts.\nLower fees\nTraditional international money transfers fees sometimes eat up a significant portion of the amount sent, especially when dealing with transactions in the hundreds of dollars. Ethereum transactions, while not free, often come with lower fees. This means more of your money goes where you intend it to, rather than lining the pockets of intermediaries.\nTransparency\nEvery transaction on the Ethereum blockchain is recorded on a public ledger. This means anyone can verify the movement of funds, making it an excellent tool for:\n- Charitable organizations to demonstrate how donations are used\n- Businesses to prove payments to suppliers or employees\n- Individuals to keep track of their financial activities\nWith Ethereum, everyone can see how money moves and how costs are implemented, unlike traditional organizations where most of these remain unknown.\nWhile fiat currencies have the advantage of widespread acceptance and stability, Ethereum offers unique benefits that make it an attractive option for certain types of transactions.\nFrom facilitating rapid disaster relief to empowering global workers, Ethereum payments are writing a new chapter in the long history of money. While challenges remain, the unique advantages offered by this technology make it an attractive option for a wide range of use cases.\nTime to get your own Ethereum account.\nGet started!\nTest your Ethereum knowledge"}
{"url":"https://docs.base.org/get-started/connect-to-base","domain":"docs.base.org","title":"Connect to Base - Base Documentation","hash":"63bb7d656d42d303ca26be2e4afeca460ad205352d27d89e1871cb536bf4ce5a","tokens":288,"chars":1152,"crawler":"crawler-f6nn","verified":"exact","ts":1791172136906,"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\nConnect to Base\nNetwork details for Base Mainnet and Base Sepolia: RPC endpoints, chain IDs, and block explorers.\nBase is a standard EVM chain, so any Ethereum tool, wallet, or library works unchanged. Just point it at the network details below.\nNetwork Details\nBase Mainnet Base Sepolia (testnet)\nRPC endpoint https://mainnet.base.org https://sepolia.base.org\nTransaction submission https://mainnet-sequencer.base.org https://sepolia-sequencer.base.org\nChain ID 8453 84532\nCurrency ETH ETH\nBlock explorer basescan.org sepolia.basescan.org\nUse the transaction submission endpoint only to send transactions. Use the RPC endpoint for all other requests.\nNext Steps\nGet Funds\nFund an address to start transacting.\nMake a Transaction\nSend your first transaction on Base.\nWas this page helpful?\nSuggest edits Raise issue\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.openzeppelin.com/contracts/5.x/learn/webauthn-smart-accounts","domain":"docs.openzeppelin.com","title":"WebAuthn Smart Accounts | OpenZeppelin Docs","hash":"650af7030d0bdc870be49215758ba407e773d8182bbff81428efee35576f8df8","tokens":9992,"chars":39968,"crawler":"crawler-f6nn","verified":"exact","ts":1791172139536,"text":"Home Forum Website Impact\nLearn\nWebAuthn Smart Accounts\nOpen in Claude\nAccount abstraction is becoming a vital tool to advance onchain technology for everyday users, making it easier to create and use a wallet without needing to handle a private key. One of the most popular forms of this is through Passkeys , which use the WebAuthn standard to create cryptographic Authentication Assertions across multiple devices and ecosystems.\nOpenZeppelin's WebAuthn.sol contract enables smart accounts to verify these WebAuthn assertions onchain. This creates a powerful and secure user experience that leverages biometrics and industry-standard cryptography for wallet interactions.\nIn this tutorial we'll show you how you can build fullstack application that allows users to create smart accounts with WebAuthn passkeys and conduct an example user operation like minting an NFT.\nPrerequisites\nBefore we get started make sure you have the following installed\n- Node.js\n- pnpm\n- Foundry\nOnce you have confirmed those are all installed, let's make sure we have a wallet setup with Foundry. If you already have one setup and funded with testnet eth, you can skip this part.\nWallet Setup\nTo make a new wallet run the following command:\nShell\ncast wallet new -p ~/.foundry/keystores sepolia\nThis will prompt you for a password and then create a new keypair and encrypt the private key locally, which is much safer than working with plain text private keys. The public address should be printed when you create the wallet but you can retrieve it at any time with the following command:\nShell\ncast wallet address --account sepolia\nMake sure to only use this wallet for testnet funds!\nProject Structure\nFor context our final project will look something like this\n.\n└── contracts // Smart contracts\n└── server // Secure server environment\n└── shared // Shared addresses and ABIs\n└── client // Web UI\nLet's make an empty directory that will store all of this and then cd into it.\nShell\nmkdir webauthn-tutorial\ncd webauthn-tutorial\nWith the initial structure setup we can move on to initializing the different projects.\nContracts\nWhile inside webauthn-tutorial run the command below to setup a new foundry project for our contracts, then move into it.\nShell\nforge init contracts\ncd contracts\nInside the contracts project go ahead and delete the default Counter files like so:\nShell\nrm src/ * test/ * script/ *\nSetup\nNext we'll install the OpenZeppelin contracts library which will include everything else we need to setup a WebAuthn account and factory.\nShell\nfoundry install OpenZeppelin/ [email protected]\nFor our contracts we need to make three files inside of src :\n- AccountWebAuthn.sol - Account implementation using WebAuthn signatures\n- AccountFactory.sol - Account factory\n- MyNFT.sol - Example NFT contract for testing User Operations\nInside AccountWebAuthn.sol paste in the following code:\nAccountWebAuthn.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.27 ;\nimport { Account } from \"@openzeppelin/contracts/account/Account.sol\" ;\nimport { EIP712 } from \"@openzeppelin/contracts/utils/cryptography/EIP712.sol\" ;\nimport { ERC1155Holder } from \"@openzeppelin/contracts/token/ERC1155/utils/ERC1155Holder.sol\" ;\nimport { ERC721Holder } from \"@openzeppelin/contracts/token/ERC721/utils/ERC721Holder.sol\" ;\nimport { ERC7739 } from \"@openzeppelin/contracts/utils/cryptography/signers/draft-ERC7739.sol\" ;\nimport { ERC7821 } from \"@openzeppelin/contracts/account/extensions/draft-ERC7821.sol\" ;\nimport { Initializable } from \"@openzeppelin/contracts/proxy/utils/Initializable.sol\" ;\nimport { SignerWebAuthn } from \"@openzeppelin/contracts/utils/cryptography/signers/SignerWebAuthn.sol\" ;\nimport { SignerP256 } from \"@openzeppelin/contracts/utils/cryptography/signers/SignerP256.sol\" ;\ncontract AccountWebAuthn is\nInitializable ,\nAccount ,\nEIP712 ,\nERC7739 ,\nERC7821 ,\nSignerWebAuthn ,\nERC721Holder ,\nERC1155Holder\n{\nconstructor ()\nEIP712 (\"AccountWebAuthn\", \"1\")\nSignerP256 (\n0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296,\n0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5\n)\n{}\nfunction initializeWebAuthn ( bytes32 qx , bytes32 qy ) public initializer {\n_setSigner (qx, qy); // Set the P256 public key\n}\n/**\n* @dev Override to allow EntryPoint to execute transactions\n*/\nfunction _erc7821AuthorizedExecutor (\naddress caller ,\nbytes32 mode ,\nbytes calldata executionData\n) internal view override returns ( bool ) {\nreturn\ncaller == address ( entryPoint ()) ||\nsuper . _erc7821AuthorizedExecutor (caller, mode, executionData);\n}\nLet's break down the key components of our WebAuthn account implementation:\nOur contract inherits from Account.sol , which provides the core ERC-4337 functionality, along with EIP712.sol for typed data signatures. We also include ERC721Holder.sol and ERC1155Holder.sol to enable the account to receive NFTs and multi-tokens. The ERC7739.sol extension enables readable typed signatures that prevent replay attacks, while ERC7821.sol provides the minimal batch executor interface for transaction batching.\nThe account uses a factory pattern with minimal proxies (like Clones.sol ) for gas-efficient deployment. Since each account is deployed as a proxy, we use an initializer function instead of a constructor to set up the account's state after deployment.\nWebAuthn verification relies on P256.sol elliptic curve operations, which require a valid public key during contract construction. To work around this factory pattern constraint, we provide a dummy public key in the constructor and set the real WebAuthn public key through the initializeWebAuthn function. Once initialized, the signer cannot be changed.\nNow paste the following code into AccountFactory.sol :\nAccountFactory.sol\n// contracts/AccountFactory.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.27 ;\nimport { Clones } from \"@openzeppelin/contracts/proxy/Clones.sol\" ;\nimport { Address } from \"@openzeppelin/contracts/utils/Address.sol\" ;\n/**\n* @dev A factory contract to create accounts on demand.\n*/\ncontract AccountFactory {\nusing Clones for address ;\nusing Address for address ;\naddress private immutable _impl;\nconstructor ( address impl_ ) {\nrequire (impl_.code.length > 0 );\n_impl = impl_;\n}\n/// @dev Predict the address of the account\nfunction predictAddress ( bytes calldata callData ) public view returns ( address ) {\nreturn _impl. predictDeterministicAddress ( keccak256 (callData), address ( this ));\n}\n/// @dev Create clone accounts on demand\nfunction cloneAndInitialize ( bytes calldata callData ) public returns ( address ) {\naddress predicted = predictAddress (callData);\nif (predicted.code.length == 0 ) {\n_impl. cloneDeterministic ( keccak256 (callData));\npredicted. functionCall (callData);\n}\nreturn predicted;\n}\nThe factory will take an implementation address which it will use for creating new accounts. There are two public functions; one is to predictAddress so we could fund the account before creating if we wanted to, and the second is cloneAndInitialize which will create the new account from our implementation address.\nFinally we'll add the code for MyNFT.sol :\nMyNFT.sol\n// SPDX-License-Identifier: MIT\n// Compatible with OpenZeppelin Contracts ^5.4.0\npragma solidity ^0.8.27 ;\nimport { ERC721 } from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\" ;\nimport { Ownable } from \"@openzeppelin/contracts/access/Ownable.sol\" ;\ncontract MyNFT is ERC721 , Ownable {\nuint256 private _nextTokenId;\nconstructor ( address initialOwner )\nERC721 (\"MyNFT\", \"MYNFT\")\nOwnable (initialOwner)\n{}\nfunction safeMint ( address to ) public returns ( uint256 ) {\nuint256 tokenId = _nextTokenId ++ ;\n_safeMint (to, tokenId);\nreturn tokenId;\n}\nThis is a really simple NFT contract that has minting enabled, with the small exception that we've removed the onlyOwner modifier from the safeMint function to make it simpler for our smart account to interact with it.\nDeployment\nWith all of our contracts put together we can make a new file under the script directory called Deploy.s.sol and put the following code inside:\nDeploy.s.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.27 ;\nimport \"forge-std/Script.sol\" ;\nimport \"../src/AccountWebAuthn.sol\" ;\nimport \"../src/AccountFactory.sol\" ;\nimport \"../src/MyNFT.sol\" ;\ncontract Deploy is Script {\nfunction run () external {\nuint256 deployerPrivateKey;\n// Use Anvil's first default account if no private key is provided\n// Anvil account #0: 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80\nif (vm. envOr ( \"PRIVATE_KEY\" , uint256 ( 0 )) == 0 ) {\ndeployerPrivateKey = 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 ;\nconsole. log ( \"Using Anvil default account\" );\n} else {\ndeployerPrivateKey = vm. envUint ( \"PRIVATE_KEY\" );\nconsole. log ( \"Using provided private key\" );\n}\nvm. startBroadcast (deployerPrivateKey);\n// Deploy AccountWebAuthn implementation\nAccountWebAuthn accountImpl = new AccountWebAuthn ();\nconsole. log ( \"AccountWebAuthn implementation deployed at:\" , address (accountImpl));\n// Deploy AccountFactory with the implementation address\nAccountFactory accountFactory = new AccountFactory ( address (accountImpl));\nconsole. log ( \"AccountFactory deployed at:\" , address (accountFactory));\n// Deploy test NFT\nMyNFT nftContract = new MyNFT (vm. addr (deployerPrivateKey));\nconsole. log ( \"AccountWebAuthn implementation deployed at:\" , address (nftContract));\nconsole. log ( \"Deployed by:\" , vm. addr (deployerPrivateKey));\nvm. stopBroadcast ();\n}\nThis deployment script will do the following:\n- Setup the broadcast with our PRIVATE_KEY\n- Deploy the AccountWebAuthn implementation contract\n- Deploy the AccountFactory and pass in the recently deployed AccountWebAuthn implementation address\n- Deploy the MyNFT contract with our deployer address as the owner\nBefore we can run this script we need to create a .env file with the following content:\nexport RPC_URL = https://sepolia.drpc.org\nexport PRIVATE_KEY = $( cast wallet private-key --account sepolia )\nThanks to cast we can use our wallet private key without keeping it in plain text and instead make it a shell environment variable that can be accessed by Foundry. We're using a public RPC url here but you may want to use one from Alchemy or your DRPC account that won't have rate limits. With that we can go ahead and run the deployment:\nShell\nsource .env\nforge script script/Deploy.s.sol:Deploy --rpc-url $RPC_URL --broadcast --verify\nThis should deploy all three contracts and print the addresses for each in the terminal, as well as save them to broadcast .\nSetup Shared Directory\nBy compiling and deploying these contracts we've created the ABI's and Addresses we need across the other pieces of our app. To make it easier to access these constants, let's make make a new directory called shared .\nShell\ncd .. # Move out of contracts\nmkdir shared\ncd shared\nInside the folder create two files and put in the following content:\nShell\ntouch index.ts\nindex.ts\nexport * from \"./EntrypointV08\" ;\nexport const FACTORY_ADDRESS = \"0xf403e5e9230a233dde99d1c6adffa9d1e81dbd98\" ;\nexport const NFT_ADDRESS = \"0x1936494b8444aF8585873F478dc826C6Ab76582e\" ;\nexport const ENTRYPOINT_ADDRESS = \"0x4337084d9e255ff0702461cf8895ce9e3b5ff108\" ;\nexport { abi as accountWebAuthnAbi } from \"../contracts/out/AccountWebAuthn.sol/AccountWebAuthn.json\" ;\nexport { abi as accountFactoryAbi } from \"../contracts/out/AccountFactory.sol/AccountFactory.json\" ;\nexport { abi as myNftAbi } from \"../contracts/out/MyNFT.sol/MyNFT.json\" ;\nOne of the pieces we need to use Account Abstraction is the Entrypoint contract. This is a contract that has the same address across every chain and allows us to submit user operations and have them conducted to our smart accounts. You can create a new file inside shared called EntrypointV08.ts and paste in the contents below:\nEntrypointV08.ts\nexport const entryPointAbi = [\n{ inputs: [], stateMutability: \"nonpayable\" , type: \"constructor\" },\n{\ninputs: [\n{ internalType: \"bool\" , name: \"success\" , type: \"bool\" },\n{ internalType: \"bytes\" , name: \"ret\" , type: \"bytes\" },\n],\nname: \"DelegateAndRevert\" ,\ntype: \"error\" ,\n},\n{\ninputs: [\n{ internalType: \"uint256\" , name: \"opIndex\" , type: \"uint256\" },\n{ internalType: \"string\" , name: \"reason\" , type: \"string\" },\n],\nname: \"FailedOp\" ,\ntype: \"error\" ,\n},\n{\ninputs: [\n{ internalType: \"uint256\" , name: \"opIndex\" , type: \"uint256\" },\n{ internalType: \"string\" , name: \"reason\" , type: \"string\" },\n{ internalType: \"bytes\" , name: \"inner\" , type: \"bytes\" },\n],\nname: \"FailedOpWithRevert\" ,\ntype: \"error\" ,\n},\n{ inputs: [], name: \"InvalidShortString\" , type: \"error\" },\n{\ninputs: [{ internalType: \"bytes\" , name: \"returnData\" , type: \"bytes\" }],\nname: \"PostOpReverted\" ,\ntype: \"error\" ,\n},\n{ inputs: [], name: \"ReentrancyGuardReentrantCall\" , type: \"error\" },\n{\ninputs: [{ internalType: \"address\" , name: \"sender\" , type: \"address\" }],\nname: \"SenderAddressResult\" ,\ntype: \"error\" ,\n},\n{\ninputs: [{ internalType: \"address\" , name: \"aggregator\" , type: \"address\" }],\nname: \"SignatureValidationFailed\" ,\ntype: \"error\" ,\n},\n{\ninputs: [{ internalType: \"string\" , name: \"str\" , type: \"string\" }],\nname: \"StringTooLong\" ,\ntype: \"error\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"bytes32\" ,\nname: \"userOpHash\" ,\ntype: \"bytes32\" ,\n},\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"sender\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"address\" ,\nname: \"factory\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"address\" ,\nname: \"paymaster\" ,\ntype: \"address\" ,\n},\n],\nname: \"AccountDeployed\" ,\ntype: \"event\" ,\n},\n{ anonymous: false , inputs: [], name: \"BeforeExecution\" , type: \"event\" },\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"account\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"totalDeposit\" ,\ntype: \"uint256\" ,\n},\n],\nname: \"Deposited\" ,\ntype: \"event\" ,\n},\n{ anonymous: false , inputs: [], name: \"EIP712DomainChanged\" , type: \"event\" },\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"bytes32\" ,\nname: \"userOpHash\" ,\ntype: \"bytes32\" ,\n},\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"sender\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"nonce\" ,\ntype: \"uint256\" ,\n},\n{\nindexed: false ,\ninternalType: \"bytes\" ,\nname: \"revertReason\" ,\ntype: \"bytes\" ,\n},\n],\nname: \"PostOpRevertReason\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"aggregator\" ,\ntype: \"address\" ,\n},\n],\nname: \"SignatureAggregatorChanged\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"account\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"totalStaked\" ,\ntype: \"uint256\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"unstakeDelaySec\" ,\ntype: \"uint256\" ,\n},\n],\nname: \"StakeLocked\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"account\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"withdrawTime\" ,\ntype: \"uint256\" ,\n},\n],\nname: \"StakeUnlocked\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"account\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"address\" ,\nname: \"withdrawAddress\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"amount\" ,\ntype: \"uint256\" ,\n},\n],\nname: \"StakeWithdrawn\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"bytes32\" ,\nname: \"userOpHash\" ,\ntype: \"bytes32\" ,\n},\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"sender\" ,\ntype: \"address\" ,\n},\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"paymaster\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"nonce\" ,\ntype: \"uint256\" ,\n},\n{ indexed: false , internalType: \"bool\" , name: \"success\" , type: \"bool\" },\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"actualGasCost\" ,\ntype: \"uint256\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"actualGasUsed\" ,\ntype: \"uint256\" ,\n},\n],\nname: \"UserOperationEvent\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"bytes32\" ,\nname: \"userOpHash\" ,\ntype: \"bytes32\" ,\n},\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"sender\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"nonce\" ,\ntype: \"uint256\" ,\n},\n],\nname: \"UserOperationPrefundTooLow\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"bytes32\" ,\nname: \"userOpHash\" ,\ntype: \"bytes32\" ,\n},\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"sender\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"nonce\" ,\ntype: \"uint256\" ,\n},\n{\nindexed: false ,\ninternalType: \"bytes\" ,\nname: \"revertReason\" ,\ntype: \"bytes\" ,\n},\n],\nname: \"UserOperationRevertReason\" ,\ntype: \"event\" ,\n},\n{\nanonymous: false ,\ninputs: [\n{\nindexed: true ,\ninternalType: \"address\" ,\nname: \"account\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"address\" ,\nname: \"withdrawAddress\" ,\ntype: \"address\" ,\n},\n{\nindexed: false ,\ninternalType: \"uint256\" ,\nname: \"amount\" ,\ntype: \"uint256\" ,\n},\n],\nname: \"Withdrawn\" ,\ntype: \"event\" ,\n},\n{\ninputs: [\n{ internalType: \"uint32\" , name: \"unstakeDelaySec\" , type: \"uint32\" },\n],\nname: \"addStake\" ,\noutputs: [],\nstateMutability: \"payable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [{ internalType: \"address\" , name: \"account\" , type: \"address\" }],\nname: \"balanceOf\" ,\noutputs: [{ internalType: \"uint256\" , name: \"\" , type: \"uint256\" }],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{ internalType: \"address\" , name: \"target\" , type: \"address\" },\n{ internalType: \"bytes\" , name: \"data\" , type: \"bytes\" },\n],\nname: \"delegateAndRevert\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [{ internalType: \"address\" , name: \"account\" , type: \"address\" }],\nname: \"depositTo\" ,\noutputs: [],\nstateMutability: \"payable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [],\nname: \"eip712Domain\" ,\noutputs: [\n{ internalType: \"bytes1\" , name: \"fields\" , type: \"bytes1\" },\n{ internalType: \"string\" , name: \"name\" , type: \"string\" },\n{ internalType: \"string\" , name: \"version\" , type: \"string\" },\n{ internalType: \"uint256\" , name: \"chainId\" , type: \"uint256\" },\n{ internalType: \"address\" , name: \"verifyingContract\" , type: \"address\" },\n{ internalType: \"bytes32\" , name: \"salt\" , type: \"bytes32\" },\n{ internalType: \"uint256[]\" , name: \"extensions\" , type: \"uint256[]\" },\n],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [{ internalType: \"address\" , name: \"account\" , type: \"address\" }],\nname: \"getDepositInfo\" ,\noutputs: [\n{\ncomponents: [\n{ internalType: \"uint256\" , name: \"deposit\" , type: \"uint256\" },\n{ internalType: \"bool\" , name: \"staked\" , type: \"bool\" },\n{ internalType: \"uint112\" , name: \"stake\" , type: \"uint112\" },\n{ internalType: \"uint32\" , name: \"unstakeDelaySec\" , type: \"uint32\" },\n{ internalType: \"uint48\" , name: \"withdrawTime\" , type: \"uint48\" },\n],\ninternalType: \"struct IStakeManager.DepositInfo\" ,\nname: \"info\" ,\ntype: \"tuple\" ,\n},\n],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [],\nname: \"getDomainSeparatorV4\" ,\noutputs: [{ internalType: \"bytes32\" , name: \"\" , type: \"bytes32\" }],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{ internalType: \"address\" , name: \"sender\" , type: \"address\" },\n{ internalType: \"uint192\" , name: \"key\" , type: \"uint192\" },\n],\nname: \"getNonce\" ,\noutputs: [{ internalType: \"uint256\" , name: \"nonce\" , type: \"uint256\" }],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [],\nname: \"getPackedUserOpTypeHash\" ,\noutputs: [{ internalType: \"bytes32\" , name: \"\" , type: \"bytes32\" }],\nstateMutability: \"pure\" ,\ntype: \"function\" ,\n},\n{\ninputs: [{ internalType: \"bytes\" , name: \"initCode\" , type: \"bytes\" }],\nname: \"getSenderAddress\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{\ncomponents: [\n{ internalType: \"address\" , name: \"sender\" , type: \"address\" },\n{ internalType: \"uint256\" , name: \"nonce\" , type: \"uint256\" },\n{ internalType: \"bytes\" , name: \"initCode\" , type: \"bytes\" },\n{ internalType: \"bytes\" , name: \"callData\" , type: \"bytes\" },\n{\ninternalType: \"bytes32\" ,\nname: \"accountGasLimits\" ,\ntype: \"bytes32\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"preVerificationGas\" ,\ntype: \"uint256\" ,\n},\n{ internalType: \"bytes32\" , name: \"gasFees\" , type: \"bytes32\" },\n{ internalType: \"bytes\" , name: \"paymasterAndData\" , type: \"bytes\" },\n{ internalType: \"bytes\" , name: \"signature\" , type: \"bytes\" },\n],\ninternalType: \"struct PackedUserOperation\" ,\nname: \"userOp\" ,\ntype: \"tuple\" ,\n},\n],\nname: \"getUserOpHash\" ,\noutputs: [{ internalType: \"bytes32\" , name: \"\" , type: \"bytes32\" }],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{\ncomponents: [\n{\ncomponents: [\n{ internalType: \"address\" , name: \"sender\" , type: \"address\" },\n{ internalType: \"uint256\" , name: \"nonce\" , type: \"uint256\" },\n{ internalType: \"bytes\" , name: \"initCode\" , type: \"bytes\" },\n{ internalType: \"bytes\" , name: \"callData\" , type: \"bytes\" },\n{\ninternalType: \"bytes32\" ,\nname: \"accountGasLimits\" ,\ntype: \"bytes32\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"preVerificationGas\" ,\ntype: \"uint256\" ,\n},\n{ internalType: \"bytes32\" , name: \"gasFees\" , type: \"bytes32\" },\n{\ninternalType: \"bytes\" ,\nname: \"paymasterAndData\" ,\ntype: \"bytes\" ,\n},\n{ internalType: \"bytes\" , name: \"signature\" , type: \"bytes\" },\n],\ninternalType: \"struct PackedUserOperation[]\" ,\nname: \"userOps\" ,\ntype: \"tuple[]\" ,\n},\n{\ninternalType: \"contract IAggregator\" ,\nname: \"aggregator\" ,\ntype: \"address\" ,\n},\n{ internalType: \"bytes\" , name: \"signature\" , type: \"bytes\" },\n],\ninternalType: \"struct IEntryPoint.UserOpsPerAggregator[]\" ,\nname: \"opsPerAggregator\" ,\ntype: \"tuple[]\" ,\n},\n{ internalType: \"address payable\" , name: \"beneficiary\" , type: \"address\" },\n],\nname: \"handleAggregatedOps\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{\ncomponents: [\n{ internalType: \"address\" , name: \"sender\" , type: \"address\" },\n{ internalType: \"uint256\" , name: \"nonce\" , type: \"uint256\" },\n{ internalType: \"bytes\" , name: \"initCode\" , type: \"bytes\" },\n{ internalType: \"bytes\" , name: \"callData\" , type: \"bytes\" },\n{\ninternalType: \"bytes32\" ,\nname: \"accountGasLimits\" ,\ntype: \"bytes32\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"preVerificationGas\" ,\ntype: \"uint256\" ,\n},\n{ internalType: \"bytes32\" , name: \"gasFees\" , type: \"bytes32\" },\n{ internalType: \"bytes\" , name: \"paymasterAndData\" , type: \"bytes\" },\n{ internalType: \"bytes\" , name: \"signature\" , type: \"bytes\" },\n],\ninternalType: \"struct PackedUserOperation[]\" ,\nname: \"ops\" ,\ntype: \"tuple[]\" ,\n},\n{ internalType: \"address payable\" , name: \"beneficiary\" , type: \"address\" },\n],\nname: \"handleOps\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [{ internalType: \"uint192\" , name: \"key\" , type: \"uint192\" }],\nname: \"incrementNonce\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{ internalType: \"bytes\" , name: \"callData\" , type: \"bytes\" },\n{\ncomponents: [\n{\ncomponents: [\n{ internalType: \"address\" , name: \"sender\" , type: \"address\" },\n{ internalType: \"uint256\" , name: \"nonce\" , type: \"uint256\" },\n{\ninternalType: \"uint256\" ,\nname: \"verificationGasLimit\" ,\ntype: \"uint256\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"callGasLimit\" ,\ntype: \"uint256\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"paymasterVerificationGasLimit\" ,\ntype: \"uint256\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"paymasterPostOpGasLimit\" ,\ntype: \"uint256\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"preVerificationGas\" ,\ntype: \"uint256\" ,\n},\n{ internalType: \"address\" , name: \"paymaster\" , type: \"address\" },\n{\ninternalType: \"uint256\" ,\nname: \"maxFeePerGas\" ,\ntype: \"uint256\" ,\n},\n{\ninternalType: \"uint256\" ,\nname: \"maxPriorityFeePerGas\" ,\ntype: \"uint256\" ,\n},\n],\ninternalType: \"struct EntryPoint.MemoryUserOp\" ,\nname: \"mUserOp\" ,\ntype: \"tuple\" ,\n},\n{ internalType: \"bytes32\" , name: \"userOpHash\" , type: \"bytes32\" },\n{ internalType: \"uint256\" , name: \"prefund\" , type: \"uint256\" },\n{ internalType: \"uint256\" , name: \"contextOffset\" , type: \"uint256\" },\n{ internalType: \"uint256\" , name: \"preOpGas\" , type: \"uint256\" },\n],\ninternalType: \"struct EntryPoint.UserOpInfo\" ,\nname: \"opInfo\" ,\ntype: \"tuple\" ,\n},\n{ internalType: \"bytes\" , name: \"context\" , type: \"bytes\" },\n],\nname: \"innerHandleOp\" ,\noutputs: [\n{ internalType: \"uint256\" , name: \"actualGasCost\" , type: \"uint256\" },\n],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{ internalType: \"address\" , name: \"\" , type: \"address\" },\n{ internalType: \"uint192\" , name: \"\" , type: \"uint192\" },\n],\nname: \"nonceSequenceNumber\" ,\noutputs: [{ internalType: \"uint256\" , name: \"\" , type: \"uint256\" }],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [],\nname: \"senderCreator\" ,\noutputs: [\n{ internalType: \"contract ISenderCreator\" , name: \"\" , type: \"address\" },\n],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [{ internalType: \"bytes4\" , name: \"interfaceId\" , type: \"bytes4\" }],\nname: \"supportsInterface\" ,\noutputs: [{ internalType: \"bool\" , name: \"\" , type: \"bool\" }],\nstateMutability: \"view\" ,\ntype: \"function\" ,\n},\n{\ninputs: [],\nname: \"unlockStake\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{\ninternalType: \"address payable\" ,\nname: \"withdrawAddress\" ,\ntype: \"address\" ,\n},\n],\nname: \"withdrawStake\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{\ninputs: [\n{\ninternalType: \"address payable\" ,\nname: \"withdrawAddress\" ,\ntype: \"address\" ,\n},\n{ internalType: \"uint256\" , name: \"withdrawAmount\" , type: \"uint256\" },\n],\nname: \"withdrawTo\" ,\noutputs: [],\nstateMutability: \"nonpayable\" ,\ntype: \"function\" ,\n},\n{ stateMutability: \"payable\" , type: \"receive\" },\n] as const ;\nWith that our contracts are all set to go!\nClient and Server\nIn our smart account app we want to have the following flow:\n- User clicks on UI button to create an account\n- User is prompted to create a passkey\n- Passkey is used to create and fund smart account on on our server by our server wallet interacting with the account factory\n- Client prepares operation to mint an NFT from the NFT contract, then prompts the user to sign the transaction with their passkey\n- Signature and operation info is sent to the server to be processed through the Entrypoint contract by our server wallet\n- Server sends a response back to the client with the transaction info\nIn a real world application you might use a bundler instead of a server like we are to process the transactions, but it's helpful to see how it all works end-to-end. With that said we need to setup the client and server repos inside our main project directory.\nSetup Client\nMake sure you are in the root directory and run the following command\npnpm create vite@latest client\nGo ahead and select the React and Typescript options, and the defaults that follow. Then move into that client directory and install our other dependencies.\nShell\ncd client\npnpm install viem ox\nWhile we are here go ahead and create a new file called utils.ts inside the src directory and put in the following code:\nutils.ts\nexport function serializeBigInts ( obj : any ) : any {\nif ( typeof obj === \"bigint\" ) {\nreturn obj. toString ();\n}\nif (Array. isArray (obj)) {\nreturn obj. map (serializeBigInts);\n}\nif (obj !== null && typeof obj === \"object\" ) {\nreturn Object. fromEntries (\nObject. entries (obj). map (([ key , value ]) => [key, serializeBigInts (value)]),\n);\n}\nreturn obj;\n}\nThis will be a helper function to help process BigInt types that can't be serialized by JSON when we send data to our server.\nSetup Server\nMove back out into the main root directory of the tutorial and then run the following command to create a Hono app:\npnpm create hono@latest server\nSelect the cloudflare-worker option from the templates, then move into the project and install the other dependencies.\nShell\npnpm install viem\npnpm install -D @types/node\nThis server is going to use our same foundry wallet from before to handle transactions that need to be processed on the backend. Let's make another .env file with the following contents:\nexport CLOUDFLARE_INCLUDE_PROCESS_ENV = true\nexport RPC_URL = https://sepolia.drpc.org\nexport PRIVATE_KEY = $( cast wallet private-key --account sepolia )\nIt is highly recommended to use an RPC URL that will be performant and not rate limited. Make a free one at DRPC.org or Alchemy!\nOne last thing we need to do is edit the server/wrangler.jsonc file by uncommenting the \"compatibility_flags\" field like so:\n{\n\"$schema\" : \"node_modules/wrangler/config-schema.json\" ,\n\"name\" : \"server\" ,\n\"main\" : \"src/index.ts\" ,\n\"compatibility_date\" : \"2025-10-10\" ,\n\"compatibility_flags\" : [ \"nodejs_compat\" ]\n}\nClient & Server Code\nNow it's time to start putting code into our client app and server to start the flow we want to achieve. Go ahead and open the client/src/App.tsx file and put in the following code:\nApp.tsx\nimport { useState } from \"react\" ;\nimport \"./App.css\" ;\nimport { WebAuthnP256 } from \"ox\" ;\nimport {\nencodeAbiParameters,\ncreatePublicClient,\nhttp,\nencodeFunctionData,\nencodePacked,\ntype Hex,\n} from \"viem\" ;\nimport { sepolia } from \"viem/chains\" ;\nimport {\nENTRYPOINT_ADDRESS,\nNFT_ADDRESS,\nentryPointAbi,\nmyNftAbi,\naccountWebAuthnAbi,\n} from \"../../shared\" ;\nimport type { PackedUserOperation } from \"viem/account-abstraction\" ;\nimport { serializeBigInts } from \"./utils\" ;\nconst SERVER_URL = \"http://localhost:8787\" ;\nconst publicClient = createPublicClient ({\ntransport: http (),\nchain: sepolia,\n});\nfunction App () {\nconst [ isLoading , setIsLoading ] = useState ( false );\nconst [ statusMessage , setStatusMessage ] = useState ( \"\" );\nconst [ accountAddress , setAccountAddress ] = useState < string | null >( null );\nconst [ mintTxHash , setMintTxHash ] = useState < string | null >( null );\nasync function createAccount () {\ntry {\nsetIsLoading ( true );\nsetStatusMessage ( \"Creating WebAuthn credential...\" );\n// Create WebAuthn credential\nconst credential = await WebAuthnP256. createCredential ({\nname: \"wallet-user\" ,\n});\n// Convert BigInt values to hex strings for serialization (with proper padding)\nconst publicKey = {\nprefix: credential.publicKey.prefix,\nx: `0x${ credential . publicKey . x . toString ( 16 ). padStart ( 64 , \"0\" ) }` ,\ny: `0x${ credential . publicKey . y . toString ( 16 ). padStart ( 64 , \"0\" ) }` ,\n};\nsetStatusMessage ( \"Deploying WebAuthn account...\" );\n// Send credential to server for account deployment\nconst response = await fetch ( `${ SERVER_URL }/account/create` , {\nmethod: \"POST\" ,\nheaders: { \"Content-Type\" : \"application/json\" },\nbody: JSON . stringify ({\ncredentialId: credential.id,\npublicKey,\n}),\n});\nif ( ! response.ok) {\nconst error = await response. json ();\nthrow new Error (error.error || \"Failed to create account\" );\n}\nconst result = await response. json ();\nconst deployedAddress = result.accountAddress;\nsetAccountAddress (deployedAddress);\nsetStatusMessage ( \"Account deployed! Preparing NFT mint transaction...\" );\nconst nonce = await publicClient. readContract ({\naddress: ENTRYPOINT_ADDRESS ,\nabi: entryPointAbi,\nfunctionName: \"getNonce\" ,\nargs: [deployedAddress, 0 n ],\n});\nconst incrementCallData = encodeFunctionData ({\nabi: myNftAbi,\nfunctionName: \"safeMint\" ,\nargs: [deployedAddress],\n});\nconst mode = encodePacked (\n[ \"bytes1\" , \"bytes1\" , \"bytes4\" , \"bytes4\" , \"bytes22\" ],\n[\n\"0x01\" ,\n\"0x00\" ,\n\"0x00000000\" ,\n\"0x00000000000000000000000000000000000000000000\" ,\n],\n);\n// Encode execution data as array of (address, uint256, bytes)[]\nconst executionData = encodeAbiParameters (\n[\n{\ntype: \"tuple[]\" ,\ncomponents: [\n{ type: \"address\" },\n{ type: \"uint256\" },\n{ type: \"bytes\" },\n],\n},\n],\n[[[ NFT_ADDRESS , 0 n , incrementCallData]]],\n);\n// Encode the execute call on the account using ERC7821 format\nconst callData = encodeFunctionData ({\nabi: accountWebAuthnAbi,\nfunctionName: \"execute\" ,\nargs: [mode, executionData],\n});\nconst feeData = await publicClient. estimateFeesPerGas ();\nconst userOp : PackedUserOperation = {\nsender: deployedAddress,\nnonce, // Already a BigInt from readContract\ninitCode: \"0x\" ,\ncallData,\naccountGasLimits: encodePacked (\n[ \"uint128\" , \"uint128\" ],\n[\n1_000_000 n , // verificationGasLimit (high for P256 verification)\n300_000 n , // callGasLimit\n],\n),\npreVerificationGas: 100_000 n ,\ngasFees: encodePacked (\n[ \"uint128\" , \"uint128\" ],\n[\nfeeData.maxPriorityFeePerGas, // maxPriorityFeePerGas (1 gwei)\nfeeData.maxFeePerGas, // maxFeePerGas (2 gwei)\n],\n),\npaymasterAndData: \"0x\" ,\nsignature: \"0x\" as Hex , // Placeholder, will be replaced\n};\nconst userOpHash = await publicClient. readContract ({\naddress: ENTRYPOINT_ADDRESS ,\nabi: entryPointAbi,\nfunctionName: \"getUserOpHash\" ,\nargs: [userOp],\n});\nsetStatusMessage ( \"Signing transaction with WebAuthn...\" );\nconst { signature , metadata } = await WebAuthnP256. sign ({\nchallenge: userOpHash,\ncredentialId: credential.id,\n});\n// Encode the signature in the format expected by OpenZeppelin SignerWebAuthn\n// The contract expects an ABI-encoded WebAuthnAuth struct:\n// struct WebAuthnAuth {\n// bytes32 r;\n// bytes32 s;\n// uint256 challengeIndex;\n// uint256 typeIndex;\n// bytes authenticatorData;\n// string clientDataJSON;\n// }\n// Prepare signature components\nconst rHex = `0x${ signature . r . toString ( 16 ). padStart ( 64 , \"0\" ) }` as Hex ;\nconst sHex = `0x${ signature . s . toString ( 16 ). padStart ( 64 , \"0\" ) }` as Hex ;\nsetStatusMessage ( \"Submitting UserOperation to mint NFT...\" );\nconst mintRequest = await fetch ( `${ SERVER_URL }/account/mint` , {\nmethod: \"POST\" ,\nheaders: {\n\"Content-Type\" : \"application/json\" ,\n},\nbody: JSON . stringify ({\nrHex,\nsHex,\nmetadata,\nuserOp: serializeBigInts (userOp),\nnonce: nonce. toString (),\n}),\n});\nconst mintResponse = await mintRequest. json ();\nconsole. log (mintResponse);\nif (mintResponse.hash) {\nsetMintTxHash (mintResponse.hash);\n}\nsetStatusMessage ( \"Success! NFT minted to your account.\" );\nsetIsLoading ( false );\n} catch (err) {\nconsole. error ( \"Error creating account:\" , err);\nsetStatusMessage (\n`Error: ${ err instanceof Error ? err . message : \"Unknown error occurred\"}` ,\n);\nsetIsLoading ( false );\n}\nreturn (\n<>\n< h1 >WebAuthn Account Abstraction\n< div className = \"card\" >\n< button type = \"button\" onClick = {createAccount} disabled = {isLoading}>\n{isLoading ? \"Processing...\" : \"Create Account\" }\n\n{statusMessage && (\n< div\nclassName = { `status-message ${ statusMessage . startsWith ( \"Error\" ) ? \"error\" : statusMessage . startsWith ( \"Success\" ) ? \"success\" : \"\"}` }\n>\n{isLoading && < div className = \"spinner\" />}\n< p >{statusMessage}\n\n)}\n{accountAddress && (\n< div className = \"account-details\" >\n< h3 >Account Details\n< div className = \"detail-row\" >\n< span className = \"label\" >Address:\n< code className = \"value\" >{accountAddress}\n\n{mintTxHash && (\n< div className = \"detail-row\" >\n< span className = \"label\" >NFT Mint Transaction:\n< a\nhref = { `https://sepolia.etherscan.io/tx/${ mintTxHash }` }\ntarget = \"_blank\"\nrel = \"noopener noreferrer\"\nclassName = \"tx-link\"\n>\nView on Etherscan ↗\n\n\n)}\n\n)}\n\n\n);\n}\nexport default App;\nNow inside server/src/index.ts paste in the code below:\nindex.ts\nimport { Hono } from \"hono\" ;\nimport { cors } from \"hono/cors\" ;\nimport { logger } from \"hono/logger\" ;\nimport {\ntype Hex,\nencodeFunctionData,\ncreatePublicClient,\ncreateWalletClient,\nhttp,\nencodeAbiParameters,\n} from \"viem\" ;\nimport {\naccountWebAuthnAbi,\nFACTORY_ADDRESS,\naccountFactoryAbi,\nENTRYPOINT_ADDRESS,\nentryPointAbi,\n} from \"../../shared\" ;\nimport { privateKeyToAccount } from \"viem/accounts\" ;\nimport { sepolia } from \"viem/chains\" ;\ntype Bindings = {\nRPC_URL : string ;\nPRIVATE_KEY : string ;\n};\nconst app = new Hono <{ Bindings : Bindings }>();\napp. use ( cors ());\napp. use ( logger ());\napp. get ( \"/\" , ( c ) => {\nreturn c. text ( \"Hello Hono!\" );\n});\napp. post ( \"/account/create\" , async ( c ) => {\ntry {\nconst publicClient = createPublicClient ({\nchain: sepolia,\ntransport: http (c.env. RPC_URL ),\n});\nconst account = privateKeyToAccount (c.env. PRIVATE_KEY as `0x${ string }` );\nconst walletClient = createWalletClient ({\nchain: sepolia,\ntransport: http (c.env. RPC_URL ),\naccount,\n});\nconst {\ncredentialId , // Can be used to store accounts for future logins\npublicKey ,\n} = await c.req. json ();\n// Extract qx and qy from the public key (ensure proper padding)\nconst qx = publicKey.x as Hex ;\nconst qy = publicKey.y as Hex ;\n// Encode the initialization call\nconst initCallData = encodeFunctionData ({\nabi: accountWebAuthnAbi,\nfunctionName: \"initializeWebAuthn\" ,\nargs: [qx, qy],\n});\n// Predict account address\nconst [ predictedAddress ] = await publicClient. readContract ({\naddress: FACTORY_ADDRESS ,\nabi: accountFactoryAbi,\nfunctionName: \"predictAddress\" ,\nargs: [initCallData],\n});\n// Deploy the account\nconst hash = await walletClient. writeContract ({\naddress: FACTORY_ADDRESS ,\nabi: accountFactoryAbi,\nfunctionName: \"cloneAndInitialize\" ,\nargs: [initCallData],\n});\n// Wait for transaction\nawait publicClient. waitForTransactionReceipt ({ hash });\n// Fund the account with 0.005 ETH from deployer wallet\nconst fundHash = await walletClient. sendTransaction ({\nto: predictedAddress,\nvalue: 5000000000000000 n , // 0.005 ETH in wei\n});\n// Wait for funding transaction\nawait publicClient. waitForTransactionReceipt ({ hash: fundHash });\nreturn c. json ({\nsuccess: true ,\naccountAddress: predictedAddress,\ntransactionHash: hash,\nfundingTransactionHash: fundHash,\npublicKey: { qx, qy },\n});\n} catch (error) {\nreturn c. json ({ error: ` Failed to create account: ${ error } ` }, 500 );\n}\n});\napp. post ( \"/account/mint\" , async ( c ) => {\nconst publicClient = createPublicClient ({\nchain: sepolia,\ntransport: http (c.env. RPC_URL ),\n});\nconst account = privateKeyToAccount (c.env. PRIVATE_KEY as `0x${ string }` );\nconst walletClient = createWalletClient ({\nchain: sepolia,\ntransport: http (c.env. RPC_URL ),\naccount,\n});\ntry {\nconst {\nmetadata ,\nrHex ,\nsHex ,\nuserOp ,\nnonce : serializedNonce ,\n} = await c.req. json ();\nconst challengeIndex = BigInt (metadata.challengeIndex);\nconst typeIndex = BigInt (metadata.typeIndex);\nconst authenticatorDataHex = metadata.authenticatorData;\nconst clientDataJSON = metadata.clientDataJSON;\nconst nonce = BigInt (serializedNonce);\nconst encodedSignature = encodeAbiParameters (\n[\n{ name: \"r\" , type: \"bytes32\" },\n{ name: \"s\" , type: \"bytes32\" },\n{ name: \"challengeIndex\" , type: \"uint256\" },\n{ name: \"typeIndex\" , type: \"uint256\" },\n{ name: \"authenticatorData\" , type: \"bytes\" },\n{ name: \"clientDataJSON\" , type: \"string\" },\n],\n[\nrHex,\nsHex,\nchallengeIndex,\ntypeIndex,\nauthenticatorDataHex,\nclientDataJSON,\n],\n);\nconst fullUserOp = {\n... userOp,\nnonce,\npreVerificationGas: BigInt (userOp.preVerificationGas),\nsignature: encodedSignature,\n};\nconst { request } = await publicClient. simulateContract ({\naddress: ENTRYPOINT_ADDRESS ,\nabi: entryPointAbi,\nfunctionName: \"handleOps\" ,\nargs: [[fullUserOp], walletClient.account.address],\naccount: walletClient.account,\n});\nconst hash = await walletClient. writeContract (request);\nconst receipt = await publicClient. waitForTransactionReceipt ({\nhash: hash,\n});\nif (receipt.status === \"reverted\" ) {\nreturn c. json ({ error: ` Failed to Mint: Reverted ` }, 500 );\n}\nreturn c. json ({\nstatus: \"success\" ,\nhash,\n});\n} catch (error) {\nreturn c. json ({ error: ` Failed to Mint: ${ error } ` }, 500 );\n}\n});\nexport default app;\nNow that's a fair bit of code, so let's do a breakdown of each step and what's happening.\nBreakdown\nCreate and Fund Account\nThe flow starts in the client code where the user clicks on the button and it kicks off createAccount() .\nasync function createAccount () {\ntry {\nsetIsLoading ( true );\nsetStatusMessage ( \"Creating WebAuthn credential...\" );\n// Create WebAuthn credential"}
{"url":"https://forum.solana.com/t/about-the-research-category/315","domain":"forum.solana.com","title":"About the Research category - Research - Solana Developer Forums","hash":"b9d591422ccaac578d4002ebefedc5cf27bdeb22171a1bd5a523bcffb582288c","tokens":125,"chars":499,"crawler":"crawler-f6nn","verified":"exact","ts":1791172141709,"text":"Solana Developer Forums\nAbout the Research category\nResearch\njacobcreech\nJune 19, 2023, 2:47pm\n1\nResearch on potential future core protocol changes\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nAbout the SIMD category\nSIMD\n0\n549\nFebruary 23, 2023\nAbout the Releases category\nReleases\n0\n523\nFebruary 23, 2023\nSolana Improvement Documents Info\nSIMD\n0\n1758\nFebruary 23, 2023\nAbout the sRFC category\nsRFC\n0\n524\nFebruary 23, 2023\nSRFCs have moved to Github\nsRFC\n0\n243\nAugust 5, 2025\nDiscourse Footer"}
{"url":"https://developers.skyeco.com/guides/sky/token-governance-upgrade/token-holders/","domain":"developers.skyeco.com","title":"Token Holders | Sky Protocol Docs","hash":"c91d2632c38ebcfcae8136342dabc0c2238cf320f3d1177a280f96b05a416aef","tokens":1085,"chars":4338,"crawler":"crawler-f6nn","verified":"exact","ts":1791172143725,"text":"Skip to content\nSky Protocol Docs\nGitHub\nSelect theme\nToken Holders\nSky Protocol’s MkrSky Converter contracts enable MKR holders to convert MKR to SKY through an on-chain mechanism at a protocol-defined fixed rate. Converter V1 will stay active until the governance upgrade spell is executed, and Converter V2 will activate following the passage of the MKR/SKY governance upgrade.\nAll conversions in the upgrade process are executed unidirectionally via the mkrToSky function, with fees applied according to the Delayed Upgrade Penalty schedule post-upgrade. Note that reverse conversion from SKY back to MKR requires utilizing an exchange and will not be possible through the Sky protocol.\nFor critical dates regarding the upgrade process, consult the upgrade timeline , which specifies when Converter V2 activates and when the Delayed Upgrade Penalties take effect.\nmkrToSky Conversion Function\nSection titled “mkrToSky Conversion Function”\nThe mkrToSky function within the Converter contract (MkrSky.sol) facilitates on-chain MKR→SKY conversions at the protocol-defined rate.\nSignature\nfunction mkrToSky ( address usr , uint256 mkrAmt ) external ;\nInput Parameters\n- usr (address): Destination address for receiving SKY tokens.\n- mkrAmt (uint256): Quantity of MKR tokens (18-decimal precision) to convert.\nFee Parameter\n- fee (uint256, WAD): Protocol-wide conversion fee rate (scaled by 1e18) configurable by governance through the file(\"fee\", newFee) admin operation. When non-zero, this fee is deducted from the calculated SKY output.\nEvent Log\nEach mkrToSky execution emits an event containing (caller, usr, mkrAmt, skyAmt, skyFee) .\nevent MkrToSky(\naddress indexed caller ,\naddress indexed usr ,\nuint256 mkrAmt ,\nuint256 skyAmt ,\nuint256 skyFee\n);\nSKY Conversion Calculation\nSection titled “SKY Conversion Calculation”\nFollow this procedure to calculate the expected SKY output from your MKR conversion:\n-\nQuery the current fee rate\n- Call the public getter on the Converter contract: fee() returns the current fee (WAD-scaled, where 1 WAD = 1e18).\n- Example: a 1% fee is represented as 0.01 × 1e18 = 1e16 .\n-\nCalculate gross SKY amount\n- The protocol conversion rate is fixed at 1 MKR → 24,000 SKY .\n- grossSky = mkrAmt × 24,000\n-\nCalculate fee amount in SKY\n- skyFee = grossSky × fee ÷ 1e18\n-\nCalculate net SKY received\n- netSky = grossSky - skyFee\n-\nCalculation example (100 MKR, 1% fee)\ngrossSky = 100 × 24,000 = 2,400,000 SKY\nskyFee = 2,400,000 × 0.01 = 24,000 SKY\nnetSky = 2,400,000 - 24,000 = 2,376,000 SKY\nConverter Versions\nSection titled “Converter Versions”\nConverter V1 is currently operational. Upon approval of the governance upgrade proposal, Converter V1 will be deactivated and Converter V2 will become operational. Conversions are irreversible within the protocol; converting SKY back to MKR requires executing a swap on an external exchange.\nSKY Token Supply\nSection titled “SKY Token Supply”\nSky governance allocates the required amount of SKY tokens to the Converter V2 contract to accommodate the conversion of the entire outstanding MKR supply. During conversion, the Converter transfers these SKY tokens directly to your specified address rather than minting new tokens—you will observe a transfer event from the Converter, not a mint event on the SKY token contract. Simultaneously, Converter V2 burns the corresponding MKR tokens as part of the upgrade transaction. Please note that Converter V1 previously minted new SKY tokens on-demand unlike Converter V2.\nFee Collection Mechanism\nSection titled “Fee Collection Mechanism”\nFees collected during conversions accumulate within the Converter contract and are tracked by the internal take variable. Governance can extract these accumulated fees by executing the collect(to) function at its discretion.\nDelayed Upgrade Penalty Schedule\nSection titled “Delayed Upgrade Penalty Schedule”\nThe MKR:SKY conversion ratio is fixed at 1:24,000. In the future, Sky protocol governance may activate a Delayed Upgrade Penalty that will reduce this conversion ratio by a specified percentage. Refer to the upgrade timeline for details regarding the anticipated activation date of the Delayed Upgrade Penalty and its future schedule of increases.\nReleased into the public domain (CC0 1.0 Universal) – trademarks remain with their owners; no warranty. See full license ."}
{"url":"https://www.anchor-lang.com/docs/references/security-exploits","domain":"www.anchor-lang.com","title":"Sealevel Attacks","hash":"24213785510271ad1a9f0c912d169cacdb48553b4f701647d9f8fd5d24b793f8","tokens":193,"chars":770,"crawler":"crawler-f6nn","verified":"exact","ts":1791172146088,"text":"Anchor Docs\nGithub Discord Stack Exchange\nProgram Development\nSealevel Attacks\nAnchor - Sealevel Attacks\nAnchor uses a lot of magic to help eliminate footguns, but if you're shipping\nanything to mainnet, it's important you understand every bit of that magic and\nthe motivation behind it. A list of common attacks can be found\nhere , providing three different\nexamples for each example attack\n- insecure - represents flawed code that may be insecure\n- secure - represents a fix\n- recommended - represents a fix with idiomatic Anchor code\nNote that none of these examples are not necessarily secure, but they are meant\nto showcase a specific issue and a recommended fix in isolation.\nPrevious\nVerifiable Builds\nNext\nExample Programs\nOn this page\nNo Headings\nEdit on GitHub"}
{"url":"https://kamino.com/docs/resources/brand","domain":"kamino.com","title":"Brand Resources - Kamino Docs","hash":"9bff9d806d31eab952767e27e6897c690f01cc823c322946989aef5298cb4d86","tokens":301,"chars":1203,"crawler":"crawler-f6nn","verified":"exact","ts":1791172148769,"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\nBrand Resources\nOfficial assets for partners, press, and collaborators. Use these resources to represent Kamino consistently across any medium.\nV1.1\nWordmark\nWordmark Black\nWordmark White\nMark / Icon\nIcon Black\nIcon White\nToken Icon\nKMNO Token / Primary\nLight Version\nColor Palette\nPaper\nBackgrounds\n#FCFCFC\nKamino Blue\nBackgrounds / Highlights\n#C6F4FF\nBlack\nBackgrounds / Text\n#000000\nThe content on this website is provided “as-is” and should not be considered legal, tax, investment, financial, or other professional advice. Users assume all risk in relying on this information, and Kamino disclaims all liability for any loss or damage resulting from such reliance. Kamino makes no representations or warranties regarding the accuracy, completeness, or reliability of the content and reserves the right to update or modify it at any time.\n© 2026 Kamino Finance. All rights reserved.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-hybrid","domain":"www.metaplex.com","title":"Overview | MPL-Hybrid","hash":"878114a19d95b99976817d38b8e533532a8147245b165f4dbd1c51f3ecaf3855","tokens":457,"chars":1825,"crawler":"crawler-f6nn","verified":"exact","ts":1791172151350,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nIntroduction\nOverview\nMPL-404 is a new model for digital assets, web3 games, and onchain communities. At the core of the model is a swap program ( mpl-hybrid ) that trades a fixed number of fungible assets for a non-fungible asset and vice versa. The swap is a dual escrow system, ensuring that all available non-fungible assets are backed by escrowed fungibles and vice versa.\nPlease note that certain MPL-Hybrid instructions will require protocol fees. Please review the Protocol Fees page for up-to-date information.\nSwapping\nThe ability to freely move between fungible and non-fungible assets in a predictable way allows this new asset class (often called hybrids ) to take advantage of the best aspects of both asset types. Non-fungible assets can now benefit from the liquidity, distribution, and DeFi opportunities associated with fungible assets. Conversely, fungible assets can now benefit from the improved utility, collectability, and identity that come from the non-fungible world.\nRe-Rolling\nthe mpl-hybrid program includes the option to \"re-roll\" the asset each time its swapped. For example, every non-fungible asset can have its metadata blanked as it enters the escrow wallet and randomly reassigned (rerolled) as it leaves escrow. The creator has the ability to both manage available traits as well as to charge a small fee during the swap (typically when swapping into an NFT). MPL-Hybrid can add “loot box” gamification to every 404 project and can serve as an alternative source of revenue (e.g. unique limited time traits for an NFT community or randomized in-game rewards). It also offers the ability to craft more dynamic collections that can evolve to better suit the needs of the project and community over time.\nNext\nPreparation →"}
{"url":"https://docs.marinade.finance/partnerships","domain":"docs.marinade.finance","title":"Become our Partner | Marinade Documentation","hash":"fa1368a28837a77fed08f8f698a70f298ce6de6cb55718eba4fe6bcadaac5d2b","tokens":1934,"chars":7735,"crawler":"crawler-f6nn","verified":"exact","ts":1791172154485,"text":"Marinade Documentation\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nBecome our Partner\nMarinade's mission is to empower users with the best tools to stake, secure and participate in the Solana ecosystem. We invite DeFi protocols, NFT projects and marketplaces who share a similar vision to join us.\nMarinade's mSOL collateral token is permissionless , which means any project can integrate and utilize it for their own benefit. Projects may also collaborate with Marinade on the installation and promotion of the shared value of mSOL and greater benefit to Solana.\nHow to team up with Marinade?\nMarinade created the mSOL token in a way to be easy to integrate no matter the type of project throughout the Solana ecosystem. It can be added to their project and provide the safest liquid staking solution on Solana with incentives aligned for all participants. Projects can simply integrate mSOL, a permissionless token, without assistance from Marinade. Or, they can use mSOL as a minting or payment option or stake their treasury to Marinade. Creative, long-lasting partnerships benefiting both parties and Solana can also be explored. To get started, please fill out this form and our team will be in contact soon.\n-\nIntegrate mSOL in your protocol . Marinade ranks among the highest TVLs on Solana that can engage with DeFi protocols. By integrating mSOL, your project offers holders an easy on-ramp to your service.\n-\nStake your treasury to Marinade . If your project generates revenues in SOL, you have the possibility to hold a part of your treasury in mSOL instead of SOL, allowing the treasury to passively earn staking rewards and engage in yield farming activities in DeFi.\n-\nAccept mSOL as a payment option . mSOL is a standard SPL token, so any mint or checkout that supports SPL token payments can accept it. See the Marinade Ts/Js SDK to integrate, or reach out to us.\n-\nMarinade Recipes . Your users stake SOL and receive their rewards in a token you choose, with the principal staying in SOL. Partner-funded incentive economics are supported here today. Read more about Marinade Recipes.\n-\nCustodian and institutional integrations . If you route institutional flow through a custodian such as Fireblocks, BitGo, Anchorage, Copper or Komainu, we support the technical integration into Marinade Native. Commercial terms are negotiated case by case. Marinade Select is not currently available to stake to , so it is not an option for new flow; existing Select positions are unaffected.\nThe Marinade referral program is currently paused. While it is paused, partners do not earn referral fees on any Marinade product , whether mSOL, Marinade Native or Marinade Select, and referred users receive no APY boost. That applies to every partner, including those holding an agreement signed before the pause . The program is paused rather than retired and a relaunch is expected, but relaunch terms are not yet defined. See Marinade Referral Program for the detail, and use the partnership form above for anything you were planning to run through it.\nPlease know that Marinade is willing to help and bring support to projects that express the desire to integrate into our ecosystem. If you require assistance in order to make this idea a reality, please contact us and we will do our best to help.\nNonetheless, mSOL is permissionless and can be integrated without contacting us or formalizing any agreement. Simply integrating mSOL in a project is by no means an endorsement of its security or credibility by Marinade .\nThe mSOL Advantage\nBy choosing to integrate and utilize mSOL, a project gains significant advantages. Collaborating with Marinade opens the opportunity for additional benefits. In order to be eligible for these added value enhancements, Marinade reserves the right to request additional information and perform due diligence about your project in order to confirm both parties share similar values.\n-\nExposure from shared marketing.\n-\nMake your project accessible to Marinade community (and its TVL).\n-\nDifferentiate from other projects by actively supporting decentralization.\n-\nIntegrate mSOL easily with the tools we provide without adding more work.\nThere are also specific advantages related to the nature of your project or of the mSOL integration.\nIf you integrate mSOL :\n-\nHelp secure and decentralize Solana. The more SOL staked using Marinade's stake distribution and decentralization rules, the more secure the network is for all the participants.\n-\nGain access to liquid capital designed to explore DeFi protocols across Solana.\n-\nReceive the best collateral available, increasing in price against SOL each epoch.\n-\nJoin the conversation in Marinade DAO: where the ecosystem and Solana users meet the security layer.\nIf you integrate mSOL staking/unstaking :\n-\nGive your users a chance to jump in and out of mSOL and earn APY on their SOL holdings.\n-\nHelp secure and decentralize Solana.\n-\nOffer staking directly inside your own product, without sending users elsewhere.\nIf you stake your treasury in mSOL:\n-\nEarn staking rewards passively and make your treasury grow each epoch.\n-\nGet mSOL in return that you can use in DeFi, unlocking investment strategies for your treasury.\n-\nSplit your stake across Marinade's full validator set, reducing the risk of a single-validator failure making you miss out on significant rewards. The current set is visible in the validator explorer .\n-\nActively participate to the decentralization of Solana.\nBest practices\nIf you are a project ambassador contacting us, you can use this form to introduce your project. Once contact is established, we may need information such as:\n-\nA brief introduction to your project and the team behind it. If your team is not doxxed, please let us know in this introduction.\n-\nAn overview of the relevant stats that we may need.\n-\nA link to your audits if there are some.\n-\nA link to your GitHub repo.\n-\nA list of contacts (Telegram, Discord, etc.) to join you.\nMarinade partnership process\nMarinade is always eager to partner with projects that share their vision of a secure and decentralized Solana that empowers users to unlock the potential of DeFi. Depending on your project, integration of mSOL may be very simple or require more collaboration with the Marinade team.\nHere is an example of what our typical setup process looks like. This is not set in stone and will be adapted to the nature of the partnership and the different needs, but it allows a first overview of the process.\n-\nFirst contact - We usually regroup all information needed and set up a meeting between our two teams.\n-\nDiscovery call - First call to get to know each other, introduce the respective projects, and have a sense of what the partnership might look like.\n-\nMutual proposal validation - Both teams agree on the terms of the partnership.\n-\nIntegration/Implementation - Marinade offers the assistance needed in order to smoothly integrate with your project.\n-\nMarketing call - Both teams agree on how and when to announce the partnership and the different news.\n-\nPublic launch - Launch is coordinated and announced to respective channels.\n-\nFollow-up and monitoring of the partnership - Parties share and analyze community sentiment and metrics and refine if needed.\nReminder: use this form to get in contact with our Partnerships team. It is the only official intake route. Marinade will never arrange a partnership through an unsolicited direct message.\nPrevious Stake to Marinade via Fireblocks\nNext Marinade Press Kit\nLast updated 2 days ago\nWas this helpful?\n- How to team up with Marinade?\n- The mSOL Advantage\n- Best practices\n- Marinade partnership process\nWas this helpful?"}
{"url":"https://www.anchor-lang.com/docs/references/verifiable-builds","domain":"www.anchor-lang.com","title":"Verifiable Builds","hash":"8ef6fe4f845e236630f327ec275c3b32f73edacc7aef1f1268bbfd06b6fdcc24","tokens":397,"chars":1588,"crawler":"crawler-f6nn","verified":"exact","ts":1791172156764,"text":"Anchor Docs\nGithub Discord Stack Exchange\nProgram Development\nVerifiable Builds\nAnchor - Verifiable Builds\nBuilding programs with the Solana CLI may embed machine specific code into the\nresulting binary. As a result, building the same program on different machines\nmay produce different executables. To get around this problem, one can build\ninside a docker image with pinned dependencies to produce a verifiable build.\nAnchor makes this easy by providing CLI commands to build and take care of\ndocker for you. To get started, first make sure you\ninstall docker on your local machine.\nBuilding\nTo produce a verifiable build, run\nanchor build --verifiable\nVerifying\nTo verify a build against a program deployed on mainnet, run\nanchor verify -p < lib-nam e > < program-i d >\nwhere the is defined by your program's Cargo.toml.\nIf the program has an IDL, it will also check the IDL deployed on chain matches.\nImages\nA docker image for each version of Anchor is published on\nQuay.io . They are tagged\nin the form quay.io/ottersec/anchor: . For example, to get the image\nfor Anchor v1.2.0 one can run\ndocker pull quay.io/ottersec/anchor:v1.2.0\nRemoving an Image\nIn the event you run a verifiable build from the CLI and exit prematurely, it's\npossible the docker image may still be building in the background.\nTo remove, run\ndocker rm -f anchor-program\nwhere anchor-program is the name of the image created by default from within\nthe Anchor CLI.\nPrevious\nRust to JS Type Conversion\nNext\nSealevel Attacks\nOn this page\nBuilding Verifying Images Removing an Image\nEdit on GitHub"}
{"url":"https://docs.ens.domains/ensv2/eth-registrar","domain":"docs.ens.domains","title":"ETH Registrar | ENS Docs","hash":"7b4a7358337af4f74ce17da9d13a26f7880bd01a1cd006766f8872ed38f5860a","tokens":3255,"chars":13018,"crawler":"crawler-f6nn","verified":"exact","ts":1791172159266,"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\nETH Registrar\nThe ETH Registrar manages the registration and renewal of .eth names in ENSv2. It retains the proven commit-reveal pattern from ENSv1 while adding multi-year registration discounts, ERC20 payment support, and integration with the Permissioned Registry .\nWhat Changed from ENSv1\nFeature ENSv1 ENSv2\nGrace period 90-day grace period after expiry 28-day grace period\nPayment ETH only ERC20 tokens via safeTransferFrom\nPricing USD-denominated, no duration discounts USD-denominated, multi-year duration discounts\nName ownership ERC721 on BaseRegistrar (optionally wrapped to ERC1155 via NameWrapper ) ERC1155Singleton token on Permissioned Registry\nPermissions Owner has full control; no granular roles Registrant receives a fixed set of EAC roles\nPricing\nBase Rate\nNames are priced annually by character count:\nName Length Annual Price\n3 characters $640/yr\n4 characters $160/yr\n5+ characters $8/yr\nMulti-Year Discounts\nLonger registrations (and renewals) receive a discount applied to the entire duration. The discount is determined by the total term in a single transaction:\nTerm Discount 5+ char /yr 5+ char total 4-char /yr 4-char total 3-char /yr 3-char total\n1 yr 0% $8.00 $8.00 $160 $160 $640 $640\n2 yr 12.5% $7.00 $14.00 $140 $280 $560 $1,120\n3 yr ~31% $5.50 $16.50 $110 $330 $440 $1,320\n4 yr ~31% $5.50 $22.00 $110 $440 $440 $1,760\n5 yr ~31% $5.50 $27.50 $110 $550 $440 $2,200\n6 yr ~44% $4.50 $27.00 $90 $540 $360 $2,160\nBecause the discount rate increases at six years, the total cost for six years is lower than for five. For example, renewing a 5+ character name for one year always costs $8 regardless of the existing expiration; renewing the same name for six years costs $27 ($4.50/yr).\nPricing parameters (base rates and discount tiers) are immutable per oracle deployment. Changing them requires deploying a new oracle and calling setRentPriceOracle() .\nExpiry Premium\nAfter the 28-day grace period, recently-expired names enter a 21-day temporary premium period to prevent sniping. The premium starts at ~$100M and decays exponentially (halving every day), reaching zero at the end of the window.\nQuerying Prices\nBoth the registrar and the oracle expose getRegisterPrice and getRenewPrice , but they serve different purposes:\n- Registrar (stateful): getRegisterPrice(label, duration, paymentToken) returns the actual cost for a specific name right now. It reads registry state to determine how long the name has been available, then forwards to the oracle. Reverts if the name is not available or the duration is below the minimum.\n- Oracle (stateless): getRegisterPrice(label, available, duration, paymentToken) takes a fully parameterized available duration and returns what the price would be for any hypothetical scenario. It has no knowledge of registry state or minimums.\nMulti-Token Payments\nUnlike ENSv1 which only accepted ETH, the ENSv2 registrar supports payment in multiple ERC20 tokens. The StandardRentPriceOracle maintains exchange rate ratios for each accepted token. Check accepted tokens via isPaymentToken(token) on the StandardRentPriceOracle .\nPayment is collected via safeTransferFrom to an immutable beneficiary address. The caller must approve the registrar for the payment token before calling register() or renew() .\nRegistering a Name\nLike ENSv1 , the ETH Registrar uses a commit-reveal scheme to prevent front-running registrations. You first call commit with an opaque commitment hash, wait at least MIN_COMMITMENT_AGE (60 seconds), then call register to reveal the parameters and complete registration.\nCommit-Reveal\nGenerate a commitment hash using makeCommitment :\nETHRegistrar. makeCommitment (\nlabel string , // \"alice\" for alice.eth (label only, not full name)\nowner address , // The address that will own the name\nsecret bytes32 , // A randomly generated 32-byte secret\nsubregistry IRegistry, // Child registry to set (or address(0) for none)\nresolver address , // Resolver contract to set\nduration uint64 , // Registration duration in seconds\nreferrer bytes32 // Referral identifier (or bytes32(0))\n)\n// For example\nmakeCommitment (\n\"alice\" ,\n0x1234 ...,\n0xabcd ..., // Random secret, generate off-chain\naddress ( 0 ), // No subregistry\n0x5678 ..., // Resolver address\n31536000 , // 1 year in seconds\nbytes32 ( 0 ) // No referrer\n);\nOnce you have calculated the commitment hash, submit it on-chain:\nETHRegistrar. commit (commitment bytes32 )\nAfter committing, wait at least MIN_COMMITMENT_AGE (60 seconds) before calling register . The commitment expires after MAX_COMMITMENT_AGE (typically 24 hours).\nRegistering\nBefore initiating registration, ensure that:\n- isAvailable(label) returns true\n- duration >= MIN_REGISTER_DURATION\n- The commitment is between MIN_COMMITMENT_AGE and MAX_COMMITMENT_AGE old\n- The payment token is approved for base + premium (query via getRegisterPrice )\nETHRegistrar. register (\nlabel string , // Same label used in makeCommitment\nowner address , // Same owner used in makeCommitment\nsecret bytes32 , // Same secret used in makeCommitment\nsubregistry IRegistry, // Same subregistry used in makeCommitment\nresolver address , // Same resolver used in makeCommitment\nduration uint64 , // Same duration used in makeCommitment\npaymentToken IERC20, // ERC20 token to pay with (must be approved)\nreferrer bytes32 // Same referrer used in makeCommitment\n) returns ( uint256 tokenId )\n// For example\nregister (\n\"alice\" ,\n0x1234 ...,\n0xabcd ..., // Same secret as in commit step\naddress ( 0 ),\n0x5678 ...,\n31536000 ,\n0x9abc ..., // USDC token address\nbytes32 ( 0 )\n);\nRoles Granted at Registration\nThe registration grants the owner a fixed set of roles defined by REGISTRATION_ROLE_BITMAP :\n- ROLE_SET_SUBREGISTRY : change the name's child registry\n- ROLE_SET_SUBREGISTRY_ADMIN : delegate ROLE_SET_SUBREGISTRY to others\n- ROLE_SET_RESOLVER : change the name's resolver\n- ROLE_SET_RESOLVER_ADMIN : delegate ROLE_SET_RESOLVER to others\n- ROLE_CAN_TRANSFER_ADMIN : controls whether the token owner can transfer the name (admin-only; there is no non-admin ROLE_CAN_TRANSFER )\nUnlike ENSv1, the role set is not configurable per registration; it is hardcoded in the registrar. See Enhanced Access Control for details on the role system.\nRenewing a Name\nAny account can renew any name, not just the owner. Renewal extends the expiry without changing ownership or permissions. Only the base rate is charged (no premium).\nstruct RenewData {\nstring label; // The label to renew\nuint64 duration; // Duration to extend by (in seconds)\nbytes32 referrer; // Referral identifier\n}\nETHRegistrar. renew (\nrd RenewData, // The renewal data\npaymentToken IERC20 // ERC20 token to pay with (must be approved)\n)\nBatch Renewals\nMultiple names can be renewed in a single transaction via renewBatch(RenewData[] rds, IERC20 paymentToken) . Every renewal in the batch is paid with the same payment token.\nBatchRegistrar\nThe BatchRegistrar is a companion contract used during migration from ENSv1. It has a single owner-only function, batchRegister(registry, resolver, labels, expires) :\n- AVAILABLE names: registered as RESERVED (no owner, no payment)\n- RESERVED names where the target expiry exceeds the current expiry: extended via ETH_REGISTRY.renew() directly (no payment, absolute timestamp)\n- REGISTERED names: silently skipped\nThis contract is intended for pre-migration use, not for general public registration.\nEAC Integration\nRegistrar Governance\nThe ETH Registrar uses OpenZeppelin Ownable for its own governance. The owner can call setRentPriceOracle() to replace the pricing oracle. Ownership is transferable via transferOwnership() .\nRoles on the ETH Registry\nTo register and renew names, the ETH Registrar needs roles on the .eth Permissioned Registry . At deployment it is granted two registry roles on ROOT_RESOURCE :\nRole Purpose\nROLE_REGISTRAR Allows calling register() to create new .eth names\nROLE_RENEW Allows calling renew() on any .eth name\nBecause these are granted at ROOT_RESOURCE , they apply to all names (the EAC checks both root and token-level roles ). The registrar does not hold admin variants of these roles, so it cannot delegate its own authority to other contracts.\nCode Examples\nFull Registration Flow\nViem\nimport {\ncreatePublicClient,\ncreateWalletClient,\nerc20Abi,\nhttp,\nkeccak256,\ntoHex,\n} from 'viem'\nimport { mainnet } from 'viem/chains'\nconst client = createPublicClient ({ chain: mainnet, transport: http () })\nconst wallet = createWalletClient ({ chain: mainnet, transport: http () })\nconst label = 'alice'\nconst owner = '0x...' // Your address\nconst duration = 31536000 n // 1 year in seconds\nconst secret = keccak256 ( toHex (crypto. randomUUID ())) // Random secret\nconst resolver = '0x...' // Resolver address\nconst subregistry = '0x0000000000000000000000000000000000000000'\nconst paymentToken = '0x...' // ERC20 token address\nconst referrer = '0x0000000000000000000000000000000000000000000000000000000000000000'\n// 1. Check availability\nconst available = await client. readContract ({\naddress: ethRegistrarAddress,\nabi: ethRegistrarAbi,\nfunctionName: 'isAvailable' ,\nargs: [label],\n})\nif ( ! available) throw new Error ( 'Name not available' )\n// 2. Get the price\nconst [ base , premium ] = await client. readContract ({\naddress: ethRegistrarAddress,\nabi: ethRegistrarAbi,\nfunctionName: 'getRegisterPrice' ,\nargs: [label, duration, paymentToken],\n})\n// 3. Approve the registrar to spend the payment token\nconst totalCost = base + premium\nawait wallet. writeContract ({\naddress: paymentToken,\nabi: erc20Abi,\nfunctionName: 'approve' ,\nargs: [ethRegistrarAddress, totalCost],\n})\n// 4. Create and submit commitment\nconst commitment = await client. readContract ({\naddress: ethRegistrarAddress,\nabi: ethRegistrarAbi,\nfunctionName: 'makeCommitment' ,\nargs: [label, owner, secret, subregistry, resolver, duration, referrer],\n})\nawait wallet. writeContract ({\naddress: ethRegistrarAddress,\nabi: ethRegistrarAbi,\nfunctionName: 'commit' ,\nargs: [commitment],\n})\n// 5. Wait at least MIN_COMMITMENT_AGE (e.g., 60 seconds)\n// ... wait ...\n// 6. Register\nawait wallet. writeContract ({\naddress: ethRegistrarAddress,\nabi: ethRegistrarAbi,\nfunctionName: 'register' ,\nargs: [\nlabel,\nowner,\nsecret,\nsubregistry,\nresolver,\nduration,\npaymentToken,\nreferrer,\n],\n})\nRenewing a Name\nViem\nconst renewPrice = await client. readContract ({\naddress: ethRegistrarAddress,\nabi: ethRegistrarAbi,\nfunctionName: 'getRenewPrice' ,\nargs: [label, duration, paymentToken],\n})\n// Approve the registrar to spend the payment token\nawait wallet. writeContract ({\naddress: paymentToken,\nabi: erc20Abi,\nfunctionName: 'approve' ,\nargs: [ethRegistrarAddress, renewPrice],\n})\nawait wallet. writeContract ({\naddress: ethRegistrarAddress,\nabi: ethRegistrarAbi,\nfunctionName: 'renew' ,\nargs: [{ label, duration, referrer }, paymentToken],\n})\nReference\nWrite Functions\ncommit(commitment) Record a commitment hash on-chain.\nregister(label, owner, secret, subregistry, resolver, duration, paymentToken, referrer) Register a name (consumes a prior commitment).\nrenew(rd, paymentToken) Extend a name's expiry. Any account can renew any name.\nrenewBatch(rds, paymentToken) Renew multiple names in one transaction, paid with a single token.\nsetRentPriceOracle(oracle) Change the pricing oracle. Callable by the contract owner only.\nView Functions\nmakeCommitment(label, owner, secret, subregistry, resolver, duration, referrer) Compute a commitment hash for the given parameters (pure, no state read).\ngetRegisterPrice(label, duration, paymentToken) Get the registration price for a name.\nisAvailable(label) Check whether a name can be registered.\ncommitmentAt(commitment) Get the timestamp when a commitment was recorded.\ngetRenewPrice(label, duration, paymentToken) Get the renewal price for a name (base rate only, no premium). Reverts NameNotRenewable if the name is not currently renewable.\nisRenewable(label) Check whether a name can be renewed (registered or within grace period).\ngetRemainingGracePeriod(label) Get the remaining grace period for an expired name.\nConstants\nETH_REGISTRY The Permissioned Registry this registrar writes to.\nBENEFICIARY Address that receives all registration and renewal payments.\nMIN_COMMITMENT_AGE Minimum seconds before a commitment can be used.\nMAX_COMMITMENT_AGE Maximum seconds before a commitment expires.\nMIN_REGISTER_DURATION Shortest allowed registration duration.\nMIN_RENEW_DURATION Shortest allowed renewal duration (1 second).\nGRACE_PERIOD Post-expiry window (in seconds) during which a name is renewable but not re-registerable.\nrentPriceOracle Current pricing oracle.\nEvents\nCommitmentMade(commitment) Commitment submitted.\nNameRegistered(tokenId, label, owner, subregistry, resolver, duration, paymentToken, referrer, base, premium) Name registered.\nNameRenewed(tokenId, label, duration, newExpiry, paymentToken, referrer, amount) Name renewed.\nRentPriceOracleUpdated(oracle) Pricing oracle updated."}
{"url":"https://discuss.ens.domains/t/ens-dao-newsletter-80-2-11-2025/20236","domain":"discuss.ens.domains","title":"ENS DAO Newsletter #80 — 2/11/2025 - Newsletter - ENS DAO Governance Forum","hash":"7f7e265acd72428ea5d41eb286518bfb345878de655c69f2be33841cff672542","tokens":4684,"chars":18733,"crawler":"crawler-f6nn","verified":"exact","ts":1791172161889,"text":"ENS DAO Governance Forum\nENS DAO Newsletter #80 — 2/11/2025\nDAO-Wide\nNewsletter\nnewsletter\nestmcmxci\nFebruary 11, 2025, 1:42pm\n1\nENS DAO Newsletter #80 - 02/11/2025\nnews 4500×1500 69.4 KB\nWelcome\n- New editions — Bi-weekly on Tuesdays\n- Previous editions — Archived on the Forum\n- New proposals — Updates via Telegram\n- ENS DAO Dashboard — Available for public review\nNewsletter Roundup\n- ENS Labs : New hires, Linea After Dark, MetaMask adds L2 support.\n- Community : World Liberty Financial endorses ENS, 10,000+ subnames registered for ETHDenver.\n- Meta-Gov : Voting period results, delegation guide.\n- Ecosystem : Q4 service provider updates, project highlights, ecosystem news.\n- Public Goods : Giveth round update, builder grants, bug reports.\nCalendar\nRefer to the official ENS DAO Calendar for meeting links and times. Any other sources are not guaranteed to be accurate. Access the ENS Calendar here .\nENS DAO Term 6 Dashboard\nThe ENS DAO Term 6 Dashboard is a comprehensive guide to ENS DAO’s governance and activities. It includes key resources such as the ENS DAO Constitution, meeting schedules via the ENS DAO Calendar, and updates through the bi-weekly ENS DAO Newsletter.\nThe dashboard outlines proposal processes, thresholds for social and executable proposals, governance environments, working group schedules, and details on Requests for Proposal (RFPs) for compensated tasks. It aims to enhance transparency, understanding, and participation within the ENS ecosystem.\nTerm 6 Proposals\nProposal Bulletin\nDetails of current proposals will be provided here. For backdated proposals, refer to the the Forum’s Proposal Bulletin for updates and detailed information on each proposal. For detailed governance information, refer to the Governance Documentation .\nAbout Proposals\nProposals are how changes are made to the DAO’s status quo. They can be submitted by anyone meeting the required $ENS thresholds and are voted on by delegates based on their token holdings. If a proposal reaches quorum and passes, it is ratified and implemented.\nProposal Thresholds:\n- 10k ENS: Required for a social proposal — an agreement of the DAO on matters that cannot be enforced on-chain.\n- 100k ENS: Required for an executable proposal — involves smart contract operations executed by DAO-controlled accounts.\nENS DAO Basics: Your Gateway to Governance\nNew to the ENS DAO or curious about how it works? basics.ensdao.org is your go-to resource for learning about governance, proposals, and ways to get involved in the ENS ecosystem.\nWhether you’re exploring ENS for the first time or looking to deepen your participation, this guide provides all the essentials.\nStart your journey today: Visit ENS DAO Basics .\nENS Labs Updates\nENS at Linea After Dark\nJoin Linea, ENS, and Trusta Labs at ETHDenver for live music, swag, pizza, and face painting. Celebrate the growing ecosystem with Namechain builders, partners, and frENS.\n→ Feb 28th, 6 PM MST.\n→ RSVP here: Linea After Dark\nENS x Linea Partnership Announcement\nENS has partnered with Linea to launch Namechain , leveraging Linea’s Type 2 zkEVM for scalability, cost efficiency, and Ethereum compatibility. This collaboration will enhance decentralized naming, profiles, and hosting.\n→ Learn more: Read here\n→ Watch the announcement: ENS x Linea – Namechain\nENS Labs Hiring\nENS is shaping the future of decentralized identity and is hiring to help build the next generation of the web.\n→ Explore open roles: Apply Now .\nENS Supports Based and Native Rollups for Namechain\nNamechain plans to implement credible forced inclusion, based sequencing, and native execution as Ethereum evolves. The Linea Stack team is working towards compatibility with both rollup standards, reinforcing ENS’s commitment to scalable, decentralized solutions.\nMetaMask Adds L2 Support for ENS Names\nMetaMask now resolves ENS names on L2s , enabling seamless multichain transactions. A major UX upgrade, this feature simplifies sending to L2 addresses via ENS records.\nENS Updates on Linea’s Weekly Roll-up\nGregskril.eth from ENS Labs joined Linea’s livestream to share the latest ENS developments, including scaling solutions and new integrations.\nMissed it? Catch the replay here: Watch Now\nENS Labs Welcomes Erni.eth to the ENS Labs Design Team\nErni.eth joins ENS Labs, bringing her incredible brand and product skills to the team. She’ll play a key role in advancing Namechain this year.\nENS and Farcaster: A Shared Vision for Ethereum\nENS has reaffirmed its alignment with @farcaster , leveraging Ethereum’s onchain context and network effects. Farcaster has supported ENS names since day one, ensuring seamless compatibility.\nMore collaboration is on the way. Stay tuned.\nEthereum App Builders and Core Devs Roundtable #2\nHosted by chaskin.eth of the Ethereum Foundation, Gregskril.eth shared ENS updates, including key developments and integrations, with the Ethereum community.\n→ Listen to the replay: Here\nCommunity Updates\nNewsletter Contributions\nSubmissions for the ENS newsletter are open! Share updates on projects, events, achievements, or community changes for inclusion. Submit your segment here and leaving a comment.\nWorld Liberty Financial Endorses ENS\nWorld Liberty Financial now recommends registering a .eth domain as part of their Web3 wallet guide, highlighting ENS as the key to simplified and memorable blockchain addresses.\n→ Explore: World Liberty Financial\n10,000+ ENS Subnames Registered for ETHDenver 2025\nETHDenver attendees are embracing ENS subnames, with 10K+ registered via ens.ethdenver.com —powered by Unicorn.eth & Namespace. These subnames simplify onchain interactions as wallet addresses & URLs.\n→ Register Now: ens.ethdenver.com/login\nAmbire Wallet Enhances ENS Integration\nAmbire Wallet now allows users to personalize their accounts with ENS names , improving user experience and on-chain identity management. This feature is part of Ambire’s 2024 roadmap, which also includes a browser extension launch and hardware wallet support.\nBuilding the Verified Web with ENS—Unruggable.eth shares insights at ETH Zurich\nAt Ethereum Zurich, Unruggable CEO Premm.eth explored the future of ENS profiles and trustless user data resolution. The talk covered advancements in ENS profiles as dynamic, verifiable identities for the Web3 era. Watch the full talk here .\nENS Governance Meets Rotki\nLefteris.eth has committed the upcoming Rotki update to include full support for vesting, claiming, delegating, and automatic vesting balance detection events—helping users stay informed and in control of their onchain activities.\nENS Gains a Congressional Advocate\nENS Delegate Brantly.eth has onboarded Congressman William Timmons to ENS . Now displaying his ENS name, wrtiv.eth , on X , Rep. Timmons brings decentralized identity closer to mainstream adoption. Follow the Congressman on EFP .\nVerify Your ENS Name on X with Dentity\nENS records + Dentity verification now let you prove ownership of your ENS name displayed on X. Tie your X account to your ENS name easily using the ENS Manager App. Enhance trust and transparency in your digital identity. Verify Now .\nIntroducing Subpages by Namespace\nLaunch custom ENS subname minting pages with Subpages—a white-label solution for brands, DAOs, and communities. Fully customizable with referral systems & L1/L2 support.\n→ Join the builders: Telegram\n→ Explore: GitHub\nTokenize Your Domains with ENS\n@cap created a walkthrough on how to turn your traditional domains into ENS names and use them as your wallet name and Web3 identity.\nFollow this easy step-by-step tutorial to get started: Watch Here .\nXMTP Testnet is Live\nThe XMTP Testnet is live ! Supported by ENS, it enables secure, decentralized messaging tied to ENS names. Your communications are now censorship-resistant and truly yours.\n→ Learn more: xmtp.com\nENS-Powered AI Agents\nAIWS DeAgents now integrate ENS identities for RAG-powered chats, accessing decentralized Web3 content like Farcaster, Mirror, and ENS archives. Build personalized AI assistants or on-chain historians with ENS support.\n→ Try it now: AIWS.eth.limo\nPulse Domains Integrates CCIP-Read for Cross-Chain Interoperability\nPulse Domains (PNS) has implemented CCIP-Read, bridging PulseChain to every EVM-compatible chain. This move enhances decentralization and interoperability, aligning with Ethereum’s vision.\n→ Explore more: Pulse Domains\nWorking Group Bulletin\nTerm 6 Lead Working Group Stewards + Secretary Appointment\n- Meta-Governance – @5pence.eth\n- ENS Ecosystem – @slobo.eth\n- Public Goods – @simona_pop\n- DAO Secretary - @dylanb\nThe responsibilities of the Lead Stewards & Secretary are set out in Rule 9.8 and Rule 9.9 of the Working Group Rules .\n—\nENS Revenue Report: Q4 2024\nENS DAO’s Q4 2024 revenue totaled $6.22M, comprising $4.49M from registration fees, $675K from temporary premium fees, and $1.05M from endowment DeFi returns. This brings the 2024 annual revenue to $28.77M. Read more .\n—\nENS DAO Working Group Budgets for H1 2025\nThe ENS DAO has outlined its H1 2025 budgets:\n- Meta-Governance Working Group : Allocated $544,000 USDC and 5 ETH for steward compensation, DAO tooling (including $50,000 for Agora), contract audits, discretionary spending, and governance initiatives.\n- Ecosystem Working Group : Budgeted $832,000 USDC and 10 ETH, focusing on hackathons, grants, bug bounty programs, audit support, and other initiatives like IRL events and the newsletter.\n- Public Goods Working Group : Set aside $343,480 USDC and 23 ETH for builder grants, a Giveth Round partnership, strategic grants, event support, and discretionary funds.\nThese allocations underscore the DAO’s commitment to governance, ecosystem development, and public goods within the Ethereum community. Read more .\nENS DAO Working Group Schedule (2025)\nWorking Group\nTime\nSchedule\nLocation\nMeta-Governance\n2pm UTC\nTuesday\nGoogle Meet\nEcosystem\n5pm UTC\nThursday\nGoogle Meet\nPublic Goods\n6pm UTC\nThursday\nGoogle Meet\nMeta-Governance\nThe Meta-Governance Working Group provides governance oversight and support for working group operations through DAO tooling and governance initiatives.\nTerm 6 Meta-Governance Stewards:\n- 5pence.eth\n- daostrat.eth\n- netto.eth\nMeeting Minutes:\n- Minutes for Weekly Meta-Gov Meeting — January 28\n- Minutes for Weekly Meta-Gov Meeting — February 4\nJanuary Voting Period Results\nThe first voting period of Term 6 has concluded. EP 6.2 expands the ENS Endowment by 5,000 ETH to reinforce financial self-sufficiency, while EP 6.1 swaps 6,000 ETH for USDC to fund DAO operations for 12 months. Both proposals are now executed onchain.\n→ Read the Proposal Bulletin: Bulletin Here\nDecember 2024 Financial Report\nFinancial Overview\n- Total funds in the endowment: $98.7m\n- Capital utilization: 99.9%\n- Monthly DeFi results: $395k\nReview the full report prepared by @kpk here .\nKarpatkey’s 2024 Review of ENS Endowment\nIn 2024, the ENS Endowment, managed by Karpatkey, achieved a net revenue of $2.97M with a 3.7% APY. The DAO’s reserves stand at $134M, covering 8 years of operations. Plans for 2025 include expanding the Endowment and enhancing risk management. Read more\nAgora ENS Enhances Voting Accessibility\nAgora ENS has introduced two key features to improve governance participation:\n- Gasless Voting : Users can now delegate and vote without incurring gas fees by signing a message, with transactions relayed on-chain at no cost.\n- Email Notifications : Stay informed with opt-in email alerts for new and ending onchain proposals.\nParticipate seamlessly and stay engaged in ENS DAO governance. Learn more:\n- Gasless Voting\n- Email Notifications\nENS Delegation Guide\nThe “Managing Delegation and Submitting a Delegate Statement” guide, prepared by estmcmxci.eth, helps $ENS holders delegate voting power or become delegates. It explains delegation processes, crafting delegate statements, and key governance aspects.\n→ Read the Guide Here .\nENS Governance Distribution Pilot Update\nAs of January 2025, the ENS DAO has distributed approximately 27,000 ENS tokens (90% of the authorized amount) via Hedgey vesting contracts to nearly 100 recipients. Recipients can find their ERC721 vesting contracts in their wallets. For guidance on managing these contracts, refer to this comprehensive guide .\nThe Meta-Governance Working Group is actively resolving technical issues to complete the remaining distributions. Read more\nDelegate Your $ENS Voting Power\nDid you know? $ENS holders can delegate their voting power to trusted delegates to shape the future of the ENS protocol. Use ENS Agora to explore and track governance activity.\nLearn how to manage delegation: Guide Here .\nEcosystem\nThe Ecosystem Working Group strengthens the ENS Protocol by facilitating developer relations, identifying and funding high-potential projects that enhance ENS, and supporting ENS-aligned initiatives.\nTerm 6 Ecosystem Stewards:\n- Slobo.eth\n- Limes.eth\n- daemon.eth\nMeeting Minutes:\n- Minutes for Weekly Ecosystem Meeting — January 30\n- Minutes for Weekly Ecosystem Meeting — February 6\nENS Labs Updates\n- Workshops & Focus : Gregskril.eth attended a workshop in the UK with Linea and Ethereum Foundation, focusing on ENSv2, Namechain, and Ethereum-aligned rollups.\n- Protocol Updates : L2 primary names to launch near ETH Denver; supporting smart contract signatures with a new ERC.\n- Engineering Progress : Manager app improvements underway—feedback welcomed!\n- New Team Members : Two developers, along with Erni.eth and Jamesbeck.eth, joined the team.\n- Hackathons : 5 ETHGlobal hackathons planned, starting in Taipei.\nService Provider Q4 Updates\neth.limo - Q4 Updates\n- DNS Resolver : Cloudflare’s DoH dWeb resolver deprecated; now using dns.eth.limo/dns-query as the default ENS resolver for Kubo.\n- Partnerships : Collaborating with Unruggable Labs to support dataUri contentHash records.\n- AIWS Integration : 70 autonomous onchain ENS/IPFS-based agents live. Learn More\n- Legal Update : ENS DAO reimbursed eth.limo’s legal fees.\n- DAO Security Report : Released research with Tally and DAOstar to enhance DAO security.\n- Performance Tuning : Continuous improvements for dWeb/Web3 communities.\n→ View the full report here .\n—\nQ4 Namespace Service Provider Report\n- Optimism Subnames : Launched gifting, selling, and managing subnames on Optimism; 260 minted so far.\n- Subpages : Introduced customizable minting templates; adopted by 5 projects (e.g., PizzaDAO, Nectar).\n- Offchain Subnames : Enhanced SDK/API; ~17,800 subnames issued.\n- ETHDenver Success : 10k subnames minted through ETHDenver wallet.\n- GitHub Updates : Restructured profiles and added automation for developer contributions.\n- Infrastructure Overhaul : Moved to Kubernetes-based setup, improving scalability and deployment.\n- V2 App : Added L1/L2 record updates, avatar uploads, token gating, and minting management.\n- ENS Widget : Integrated with WordPress; live on 105 websites for streamlined subname minting.\n- Backend Improvements : Split into microservices for better performance and isolation.\n→ View the full report here .\nProject Highlights\nAIWS : Decentralized AI Agents\n- Upgraded to sync data from sources like Mirror, Farcaster, and Lens.\n- Users can create AI agents using ENS domains and chat systems.\n- Agents are aware of ENS DAO discussions and index community data for better context.\nFuture Plans :\n- ENS agents with Telegram/Discord integration for direct answers.\n- AI metadata integration with ENS records.\n- Standards for onchain identity and metadata verification.\n- Indexing data from sources like Filecoin, IPFS, and Arweave.\n→ Explore AIWS\nWeb3 Compass: Decentralized Search Engine\n- Introduced as a search engine for decentralized web pages.\n- Aims to fill gaps where Chrome and Brave don’t index dWeb pages.\n- Emphasized ENS’s importance in domain name services.\n→ Follow Web3Compass\nService Provider Updates\nNamespace Updates\nSubpages\n- Introduced “Subpages” for customizable subname minting websites.\n- Features: wallet connection, referral systems, and step-by-step guides.\n- 5 websites launched; easy setup in 10-20 minutes.\n- ETHDenver wallet minted 10k subnames using Subpages.\nUnicorn Updates\nETHDenver Infrastructure\n- Provided ticketing via ENS names/subnames.\n- Focused on wallet security and user experience.\n- Users onboard with Google and create ENS-based smart accounts.\nUser Stats\n- 12,000 ENS users onboarded (~50% new to crypto).\n- Monetization tools for brands included.\n- Web3 tools like Snapshot and Giveth integrated.\nNamehash Labs Updates\nName AI\n- Enhances name discovery with tokenization and AI ranking.\n- Open-source availability on Vision IO.\n- Features: accurate name splitting, quality scoring, and security checks.\n- Explore Name AI\nPublic Goods\nThe Public Goods Working Group supports the Ethereum ecosystem by identifying and funding open-source development.\nTerm 6 Public Goods Stewards:\n- Simona.eth\n- Coltron.eth\n- sovereignsignal.eth\nMeeting Minutes\n- Minutes for Weekly Public Goods Meeting — January 30\n- Minutes for Weekly Public Goods Meeting — February 6\nGiveth Round Announced for March 2025\nThe Public Goods Working Group will run the Giveth round with Octant matching its $80K USDC donation pool. Launch is tentatively set for mid-March, the week of the 10th. Community feedback on eligibility and curation will be gathered on the forum.\nBuilder Grants Updates\nThe Builder Grants platform has launched a new FAQ to streamline applications. Efforts are underway to route proposals to Public Goods or Ecosystem grants as appropriate. The USDC payment issue is also being resolved.\n→ Apply here: Builder Grants\nDiscussion on Strategic Grants and Advocacy\nThe Public Goods Working Group is exploring larger strategic grants and advocacy funding, including partnerships with Ethereum Foundation and groups like DRC. Suggestions include inviting advocacy groups to weekly calls and collaborating with Coinbase.\nBuilder Grants Bug Report Summary\nA security audit on Builder Grants found exposed PII. The issue was resolved in 12 hours. Immunefi rejected the bounty claim as out of scope. The Public Goods Working Group awarded 2,500 USDC as a discretionary reward.\nResources\nENS DAO offers several resources for understanding and participating in its ecosystem:\n- ENS DAO Basics : Learn about the ENS DAO, including voting and governance.\n- Support Docs : Guidance on registration, renewals, and development aspects.\n- Governance Docs : Insights into governance structure.\n- ENS Agora : Governance hub for proposal review and voting.\n- ENS Repository : The ENS Protocol’s main GitHub repository.\nNote : Posts older than 4 weeks are archival—browse cautiously, as links may be outdated or compromised.\nThank you for reading! Goodbye.\n3 Likes"}
{"url":"https://docs.soliditylang.org/en/latest/internals/optimizer.html","domain":"docs.soliditylang.org","title":"The Optimizer — Solidity 0.8.38-develop documentation","hash":"842ffd12bc581b934dee3f68cf6c93e7cd3826fc57022c6a6e7570f1145d649a","tokens":9991,"chars":39964,"crawler":"crawler-f6nn","verified":"exact","ts":1791172164534,"text":"-\n- The Optimizer\n-\nEdit on GitHub\nThe Optimizer \nThe Solidity compiler involves optimizations at three different levels (in order of execution):\n-\nOptimizations during code generation based on a direct analysis of Solidity code.\n-\nOptimizing transformations on the Yul IR code.\n-\nOptimizations at the opcode level.\nThe opcode-based optimizer applies a set of simplification rules\nto opcodes. It also combines equal code sets and removes unused code.\nThe Yul-based optimizer is much more powerful, because it can work across function\ncalls. For example, arbitrary jumps are not possible in Yul, so it is\npossible to compute the side-effects of each function. Consider two function calls,\nwhere the first does not modify storage and the second does modify storage.\nIf their arguments and return values do not depend on each other, we can reorder\nthe function calls. Similarly, if a function is\nside-effect free and its result is multiplied by zero, you can remove the function\ncall completely.\nThe codegen-based optimizer affects the initial low-level code produced from the Solidity input.\nIn the legacy pipeline, the bytecode is generated immediately and most of the optimizations of this\nkind are implicit and not configurable, the only exception being an optimization which changes the\norder of literals in binary operations.\nThe IR-based pipeline takes a different approach and produces Yul IR closely matching the structure\nof the Solidity code, with nearly all optimizations deferred to the Yul optimizer module.\nIn that case codegen-level optimization is done only in very limited cases which are difficult to\nhandle in Yul IR, but are straightforward with the high-level information from analysis phase at hand.\nAn example of such an optimization is the bypass of checked arithmetic when incrementing the counter\nin certain idiomatic for loops.\nCurrently, the parameter --optimize activates the opcode-based optimizer for the\ngenerated bytecode and the Yul optimizer for the Yul code generated internally, for example for ABI coder v2.\nOne can use solc --ir-optimized --optimize to produce an\noptimized Yul IR for a Solidity source. Similarly, one can use solc --strict-assembly --optimize\nfor a stand-alone Yul mode.\nNote\nSome optimizer steps, such as, for example, the peephole optimizer\nand the unchecked loop increment optimizer are always\nenabled by default and can only be turned off via the Standard JSON .\nNote\nAn empty optimizer sequence, i.e : , is accepted even without --optimize in order to fully disable\nthe user-supplied portion of the Yul optimizer sequence , as by default,\neven when the optimizer is not turned on, the unused pruner step will be run.\nYou can find more details on both optimizer modules and their optimization steps below.\nBenefits of Optimizing Solidity Code \nOverall, the optimizer tries to simplify complicated expressions, which reduces both code\nsize and execution cost, i.e., it can reduce gas needed for contract deployment as well as for external calls made to the contract.\nIt also specializes or inlines functions. Especially\nfunction inlining is an operation that can cause much bigger code, but it is\noften done because it results in opportunities for more simplifications.\nDifferences between Optimized and Non-Optimized Code \nGenerally, the most visible difference is that constant expressions are evaluated at compile time.\nWhen it comes to the ASM output, one can also notice a reduction of equivalent or duplicate\ncode blocks (compare the output of the flags --asm and --asm --optimize ). However,\nwhen it comes to the Yul/intermediate-representation, there can be significant\ndifferences, for example, functions may be inlined, combined, or rewritten to eliminate\nredundancies, etc. (compare the output between the flags --ir and\n--optimize --ir-optimized ).\nOptimizer Parameter Runs \nThe number of runs ( --optimize-runs ) specifies roughly how often each opcode of the\ndeployed code will be executed across the life-time of the contract. This means it is a\ntrade-off parameter between code size (deploy cost) and code execution cost (cost after deployment).\nA “runs” parameter of “1” will produce short but expensive code. In contrast, a larger “runs”\nparameter will produce longer but more gas efficient code. The maximum value of the parameter\nis 2**32-1 .\nNote\nA common misconception is that this parameter specifies the number of iterations of the optimizer.\nThis is not true: The optimizer will always run as many times as it can still improve the code.\nOpcode-Based Optimizer Module \nThe opcode-based optimizer module operates on assembly code. It splits the\nsequence of instructions into basic blocks at JUMPs and JUMPDESTs .\nInside these blocks, the optimizer analyzes the instructions and records every modification to the stack,\nmemory, or storage as an expression which consists of an instruction and\na list of arguments which are pointers to other expressions.\nAdditionally, the opcode-based optimizer\nuses a component called “CommonSubexpressionEliminator” that, amongst other\ntasks, finds expressions that are always equal (on every input) and combines\nthem into an expression class. It first tries to find each new\nexpression in a list of already known expressions. If no such matches are found,\nit simplifies the expression according to rules like\nconstant + constant = sum_of_constants or X * 1 = X . Since this is\na recursive process, we can also apply the latter rule if the second factor\nis a more complex expression which we know always evaluates to one.\nCertain optimizer steps symbolically track the storage and memory locations. For example, this\ninformation is used to compute Keccak-256 hashes that can be evaluated during compile time. Consider\nthe sequence:\nPUSH 32\nPUSH 0\nCALLDATALOAD\nPUSH 100\nDUP2\nMSTORE\nKECCAK256\nor the equivalent Yul\nopen in Remix\nlet x := calldataload ( 0 )\nmstore ( x , 100 )\nlet value := keccak256 ( x , 32 )\nIn this case, the optimizer tracks the value at a memory location calldataload(0) and then\nrealizes that the Keccak-256 hash can be evaluated at compile time. This only works if there is no\nother instruction that modifies memory between the mstore and keccak256 . So if there is an\ninstruction that writes to memory (or storage), then we need to erase the knowledge of the current\nmemory (or storage). There is, however, an exception to this erasing, when we can easily see that\nthe instruction doesn’t write to a certain location.\nFor example,\nopen in Remix\nlet x := calldataload ( 0 )\nmstore ( x , 100 )\n// Current knowledge memory location x -> 100\nlet y := add ( x , 32 )\n// Does not clear the knowledge that x -> 100, since y does not write to [x, x + 32)\nmstore ( y , 200 )\n// This Keccak-256 can now be evaluated\nlet value := keccak256 ( x , 32 )\nTherefore, modifications to storage and memory locations, of say location l , must erase\nknowledge about storage or memory locations which may be equal to l . More specifically, for\nstorage, the optimizer has to erase all knowledge of symbolic locations, that may be equal to l\nand for memory, the optimizer has to erase all knowledge of symbolic locations that may not be at\nleast 32 bytes away. If m denotes an arbitrary location, then this decision on erasure is done\nby computing the value sub(l, m) . For storage, if this value evaluates to a literal that is\nnon-zero, then the knowledge about m will be kept. For memory, if the value evaluates to a\nliteral that is between 32 and 2**256 - 32 , then the knowledge about m will be kept. In\nall other cases, the knowledge about m will be erased.\nAfter this process, we know which expressions have to be on the stack at\nthe end, and have a list of modifications to memory and storage. This information\nis stored together with the basic blocks and is used to link them. Furthermore,\nknowledge about the stack, storage and memory configuration is forwarded to\nthe next block(s).\nIf we know the targets of all JUMP and JUMPI instructions,\nwe can build a complete control flow graph of the program. If there is only\none target we do not know (this can happen as in principle, jump targets can\nbe computed from inputs), we have to erase all knowledge about the input state\nof a block as it can be the target of the unknown JUMP . If the opcode-based\noptimizer module finds a JUMPI whose condition evaluates to a constant, it transforms it\nto an unconditional jump.\nAs the last step, the code in each block is re-generated. The optimizer creates\na dependency graph from the expressions on the stack at the end of the block,\nand it drops every operation that is not part of this graph. It generates code\nthat applies the modifications to memory and storage in the order they were\nmade in the original code (dropping modifications which were found not to be\nneeded). Finally, it generates all values that are required to be on the\nstack in the correct place.\nThese steps are applied to each basic block and the newly generated code\nis used as replacement if it is smaller. If a basic block is split at a\nJUMPI and during the analysis, the condition evaluates to a constant,\nthe JUMPI is replaced based on the value of the constant. Thus code like\nopen in Remix\nuint x = 7 ;\ndata [ 7 ] = 9 ;\nif ( data [ x ] != x + 2 ) // this condition is never true\nreturn 2 ;\nelse\nreturn 1 ;\nsimplifies to this:\nopen in Remix\ndata [ 7 ] = 9 ;\nreturn 1 ;\nSimple Inlining \nSince Solidity version 0.8.2, there is another optimizer step that replaces certain\njumps to blocks containing “simple” instructions ending with a “jump” by a copy of these instructions.\nThis corresponds to inlining of simple, small Solidity or Yul functions. In particular, the sequence\nPUSHTAG(tag) JUMP may be replaced, whenever the JUMP is marked as jump “into” a\nfunction and behind tag there is a basic block (as described above for the\n“CommonSubexpressionEliminator”) that ends in another JUMP which is marked as a jump\n“out of” a function.\nIn particular, consider the following prototypical example of assembly generated for a\ncall to an internal Solidity function:\ntag_return\ntag_f\njump // in\ntag_return:\n...opcodes after call to f...\ntag_f:\n...body of function f...\njump // out\nAs long as the body of the function is a continuous basic block, the “Inliner” can replace tag_f jump by\nthe block at tag_f resulting in:\ntag_return\n...body of function f...\njump\ntag_return:\n...opcodes after call to f...\ntag_f:\n...body of function f...\njump // out\nNow ideally, the other optimizer steps described above will result in the return tag push being moved\ntowards the remaining jump resulting in:\n...body of function f...\ntag_return\njump\ntag_return:\n...opcodes after call to f...\ntag_f:\n...body of function f...\njump // out\nIn this situation the “PeepholeOptimizer” will remove the return jump. Ideally, all of this can be done\nfor all references to tag_f leaving it unused, s.t. it can be removed, yielding:\n...body of function f...\n...opcodes after call to f...\nSo the call to function f is inlined and the original definition of f can be removed.\nInlining like this is attempted, whenever a heuristics suggests that inlining is cheaper over the lifetime of a\ncontract than not inlining. This heuristics depends on the size of the function body, the\nnumber of other references to its tag (approximating the number of calls to the function) and\nthe expected number of executions of the contract (the global optimizer parameter “runs”).\nYul-Based Optimizer Module \nThe Yul-based optimizer consists of several stages and components that all transform\nthe AST in a semantically equivalent way. The goal is to end up either with code\nthat is shorter or at least only marginally longer but will allow further\noptimization steps.\nWarning\nSince the optimizer is under heavy development, the information here might be outdated.\nIf you rely on a certain functionality, please reach out to the team directly.\nThe optimizer currently follows a purely greedy strategy and does not do any\nbacktracking.\nAll components of the Yul-based optimizer module are explained below.\nThe following transformation steps are the main components:\n-\nSSATransform\n-\nCommonSubexpressionEliminator\n-\nExpressionSimplifier\n-\nUnusedAssignEliminator\n-\nFullInliner\nOptimizer Steps \nThis is a list of all steps the Yul-based optimizer sorted alphabetically. You can find more information\non the individual steps and their sequence below.\nAbbreviation\nFull name\nf\nBlockFlattener\nl\nCircularReferencesPruner\nc\nCommonSubexpressionEliminator\nC\nConditionalSimplifier\nU\nConditionalUnsimplifier\nn\nControlFlowSimplifier\nD\nDeadCodeEliminator\nE\nEqualStoreEliminator\nv\nEquivalentFunctionCombiner\ne\nExpressionInliner\nj\nExpressionJoiner\ns\nExpressionSimplifier\nx\nExpressionSplitter\nI\nForLoopConditionIntoBody\nO\nForLoopConditionOutOfBody\no\nForLoopInitRewriter\ni\nFullInliner\ng\nFunctionGrouper\nh\nFunctionHoister\nF\nFunctionSpecializer\nT\nLiteralRematerialiser\nL\nLoadResolver\nM\nLoopInvariantCodeMotion\nm\nRematerialiser\nV\nSSAReverser\na\nSSATransform\nt\nStructuralSimplifier\nr\nUnusedAssignEliminator\np\nUnusedFunctionParameterPruner\nS\nUnusedStoreEliminator\nu\nUnusedPruner\nd\nVarDeclInitializer\nSome steps depend on properties ensured by BlockFlattener , FunctionGrouper , ForLoopInitRewriter .\nFor this reason the Yul optimizer always applies them before applying any steps supplied by the user.\nSelecting Optimizations \nBy default the optimizer applies its predefined sequence of optimization steps to the generated assembly.\nYou can override this sequence and supply your own using the --yul-optimizations option:\nsolc --optimize --ir-optimized --yul-optimizations 'dhfoD[xarrscLMcCTU]uljmul:fDnTOcmu'\nThe order of steps is significant and affects the quality of the output.\nMoreover, applying a step may uncover new optimization opportunities for others that were already applied,\nso repeating steps is often beneficial.\nThe sequence inside [...] will be applied multiple times in a loop until the Yul code\nremains unchanged or until the maximum number of rounds (currently 12) has been reached.\nBrackets ( [] ) may be used multiple times in a sequence, but can not be nested.\nAn important thing to note, is that there are some hardcoded steps that are always run before and after the\nuser-supplied sequence, or the default sequence if one was not supplied by the user.\nThe cleanup sequence delimiter : is optional, and is used to supply a custom cleanup sequence\nin order to replace the default one. If omitted, the optimizer will simply apply the default cleanup\nsequence. In addition, the delimiter may be placed at the beginning of the user-supplied sequence,\nwhich will result in the optimization sequence being empty, whereas conversely, if placed at the end of\nthe sequence, will be treated as an empty cleanup sequence.\nPreprocessing \nThe preprocessing components perform transformations to get the program\ninto a certain normal form that is easier to work with. This normal\nform is kept during the rest of the optimization process.\nDisambiguator \nThe disambiguator takes an AST and returns a fresh copy where all identifiers have\nunique names in the input AST. This is a prerequisite for all other optimizer stages.\nOne of the benefits is that identifier lookup does not need to take scopes into account\nwhich simplifies the analysis needed for other steps.\nAll subsequent stages have the property that all names stay unique. This means if\na new identifier needs to be introduced, a new unique name is generated.\nFunctionHoister \nThe function hoister moves all function definitions to the end of the topmost block. This is\na semantically equivalent transformation as long as it is performed after the\ndisambiguation stage. The reason is that moving a definition to a higher-level block cannot decrease\nits visibility and it is impossible to reference variables defined in a different function.\nThe benefit of this stage is that function definitions can be looked up more easily\nand functions can be optimized in isolation without having to traverse the AST completely.\nFunctionGrouper \nThe function grouper has to be applied after the Disambiguator and the FunctionHoister.\nIts effect is that all topmost elements that are not function definitions are moved\ninto a single block which is the first statement of the root block.\nAfter this step, a program has the following normal form:\n{ I F... }\nWhere I is a (potentially empty) block that does not contain any function definitions (not even recursively)\nand F is a list of function definitions such that no function contains a function definition.\nThe benefit of this stage is that we always know where the list of functions begins.\nForLoopConditionIntoBody \nThis transformation moves the loop-iteration condition of a for loop into loop body.\nWe need this transformation because ExpressionSplitter will not\napply to iteration condition expressions (the C in the following example).\nfor { Init... } C { Post... } {\nBody...\n}\nis transformed to\nfor { Init... } 1 { Post... } {\nif iszero(C) { break }\nBody...\n}\nThis transformation can also be useful when paired with LoopInvariantCodeMotion, since\ninvariants in the loop-invariant conditions can then be taken outside the loop.\nForLoopInitRewriter \nThis transformation moves the initialization part of a for loop to before\nthe loop:\nfor { Init... } C { Post... } {\nBody...\n}\nis transformed to\nInit...\nfor {} C { Post... } {\nBody...\n}\nThis eases the rest of the optimization process because we can ignore\nthe complicated scoping rules of the for loop initialization block.\nVarDeclInitializer \nThis step rewrites variable declarations so that all of them are initialized.\nDeclarations like let x, y are split into multiple declaration statements.\nOnly supports initializing with the zero literal for now.\nPseudo-SSA Transformation \nThe purpose of this components is to get the program into a longer form,\nso that other components can more easily work with it. The final representation\nwill be similar to a static-single-assignment (SSA) form, with the difference\nthat it does not make use of explicit “phi” functions which combines the values\nfrom different branches of control flow because such a feature does not exist\nin the Yul language. Instead, when control flow merges, if a variable is re-assigned\nin one of the branches, a new SSA variable is declared to hold its current value,\nso that the following expressions still only need to reference SSA variables.\nAn example transformation is the following:\nopen in Remix\n{\nlet a := calldataload ( 0 )\nlet b := calldataload ( 0x20 )\nif gt ( a , 0 ) {\nb := mul ( b , 0x20 )\n}\na := add ( a , 1 )\nsstore ( a , add ( b , 0x20 ))\n}\nWhen all the following transformation steps are applied, the program will look\nas follows:\nopen in Remix\n{\nlet _1 := 0\nlet a_9 := calldataload ( _1 )\nlet a := a_9\nlet _2 := 0x20\nlet b_10 := calldataload ( _2 )\nlet b := b_10\nlet _3 := 0\nlet _4 := gt ( a_9 , _3 )\nif _4\n{\nlet _5 := 0x20\nlet b_11 := mul ( b_10 , _5 )\nb := b_11\n}\nlet b_12 := b\nlet _6 := 1\nlet a_13 := add ( a_9 , _6 )\nlet _7 := 0x20\nlet _8 := add ( b_12 , _7 )\nsstore ( a_13 , _8 )\n}\nNote that the only variable that is re-assigned in this snippet is b .\nThis re-assignment cannot be avoided because b has different values\ndepending on the control flow. All other variables never change their\nvalue once they are defined. The advantage of this property is that\nvariables can be freely moved around and references to them\ncan be exchanged by their initial value (and vice-versa),\nas long as these values are still valid in the new context.\nOf course, the code here is far from being optimized. To the contrary, it is much\nlonger. The hope is that this code will be easier to work with and furthermore,\nthere are optimizer steps that undo these changes and make the code more\ncompact again at the end.\nExpressionSplitter \nThe expression splitter turns expressions like add(mload(0x123), mul(mload(0x456), 0x20))\ninto a sequence of declarations of unique variables that are assigned sub-expressions\nof that expression so that each function call has only variables\nas arguments.\nThe above would be transformed into\nopen in Remix\n{\nlet _1 := 0x20\nlet _2 := 0x456\nlet _3 := mload ( _2 )\nlet _4 := mul ( _3 , _1 )\nlet _5 := 0x123\nlet _6 := mload ( _5 )\nlet z := add ( _6 , _4 )\n}\nNote that this transformation does not change the order of opcodes or function calls.\nIt is not applied to loop iteration-condition, because the loop control flow does not allow\nthis “outlining” of the inner expressions in all cases. We can sidestep this limitation by applying\nForLoopConditionIntoBody to move the iteration condition into loop body.\nThe final program should be in an expression-split form , where (with the exception of loop conditions)\nfunction calls cannot appear nested inside expressions\nand all function call arguments have to be variables.\nThe benefits of this form are that it is much easier to re-order the sequence of opcodes\nand it is also easier to perform function call inlining. Furthermore, it is simpler\nto replace individual parts of expressions or re-organize the “expression tree”.\nThe drawback is that such code is much harder to read for humans.\nSSATransform \nThis stage tries to replace repeated assignments to\nexisting variables by declarations of new variables as much as\npossible.\nThe reassignments are still there, but all references to the\nreassigned variables are replaced by the newly declared variables.\nExample:\nopen in Remix\n{\nlet a := 1\nmstore ( a , 2 )\na := 3\n}\nis transformed to\nopen in Remix\n{\nlet a_1 := 1\nlet a := a_1\nmstore ( a_1 , 2 )\nlet a_3 := 3\na := a_3\n}\nExact semantics:\nFor any variable a that is assigned to somewhere in the code\n(variables that are declared with value and never re-assigned\nare not modified) perform the following transforms:\n-\nreplace let a := v by let a_i := v let a := a_i\n-\nreplace a := v by let a_i := v a := a_i where i is a number such that a_i is yet unused.\nFurthermore, always record the current value of i used for a and replace each\nreference to a by a_i .\nThe current value mapping is cleared for a variable a at the end of each block\nin which it was assigned to and at the end of the for loop init block if it is assigned\ninside the for loop body or post block.\nIf a variable’s value is cleared according to the rule above and the variable is declared outside\nthe block, a new SSA variable will be created at the location where control flow joins,\nthis includes the beginning of loop post/body block and the location right after\nif / switch / for /block statement.\nAfter this stage, the UnusedAssignEliminator is recommended to remove the unnecessary\nintermediate assignments.\nThis stage provides best results if the ExpressionSplitter and the CommonSubexpressionEliminator\nare run right before it, because then it does not generate excessive amounts of variables.\nOn the other hand, the CommonSubexpressionEliminator could be more efficient if run after the\nSSA transform.\nUnusedAssignEliminator \nThe SSA transform always generates an assignment of the form a := a_i , even though\nthese might be unnecessary in many cases, like the following example:\nopen in Remix\n{\nlet a := 1\na := mload ( a )\na := sload ( a )\nsstore ( a , 1 )\n}\nThe SSA transform converts this snippet to the following:\nopen in Remix\n{\nlet a_1 := 1\nlet a := a_1\nlet a_2 := mload ( a_1 )\na := a_2\nlet a_3 := sload ( a_2 )\na := a_3\nsstore ( a_3 , 1 )\n}\nThe UnusedAssignEliminator removes all the three assignments to a , because\nthe value of a is not used and thus turn this\nsnippet into strict SSA form:\nopen in Remix\n{\nlet a_1 := 1\nlet a_2 := mload ( a_1 )\nlet a_3 := sload ( a_2 )\nsstore ( a_3 , 1 )\n}\nOf course the intricate parts of determining whether an assignment is unused or not\nare connected to joining control flow.\nThe component works as follows in detail:\nThe AST is traversed twice: in an information gathering step and in the\nactual removal step. During information gathering, we maintain a\nmapping from assignment statements to the three states\n“unused”, “undecided” and “used” which signifies whether the assigned\nvalue will be used later by a reference to the variable.\nWhen an assignment is visited, it is added to the mapping in the “undecided” state\n(see remark about for loops below) and every other assignment to the same variable\nthat is still in the “undecided” state is changed to “unused”.\nWhen a variable is referenced, the state of any assignment to that variable still\nin the “undecided” state is changed to “used”.\nAt points where control flow splits, a copy\nof the mapping is handed over to each branch. At points where control flow\njoins, the two mappings coming from the two branches are combined in the following way:\nStatements that are only in one mapping or have the same state are used unchanged.\nConflicting values are resolved in the following way:\n-\n“unused”, “undecided” -> “undecided”\n-\n“unused”, “used” -> “used”\n-\n“undecided”, “used” -> “used”\nFor for loops, the condition, body and post-part are visited twice, taking\nthe joining control-flow at the condition into account.\nIn other words, we create three control flow paths: Zero runs of the loop,\none run and two runs and then combine them at the end.\nSimulating a third run or even more is unnecessary, which can be seen as follows:\nA state of an assignment at the beginning of the iteration will deterministically\nresult in a state of that assignment at the end of the iteration. Let this\nstate mapping function be called f . The combination of the three different\nstates unused , undecided and used as explained above is the max\noperation where unused = 0 , undecided = 1 and used = 2 .\nThe proper way would be to compute\nmax(s, f(s), f(f(s)), f(f(f(s))), ...)\nas state after the loop. Since f just has a range of three different values,\niterating it has to reach a cycle after at most three iterations,\nand thus f(f(f(s))) has to equal one of s , f(s) , or f(f(s))\nand thus\nmax(s, f(s), f(f(s))) = max(s, f(s), f(f(s)), f(f(f(s))), ...)\nIn summary, running the loop at most twice is enough because there are only three\ndifferent states.\nFor switch statements that have a default case, there is no control-flow\npart that skips the switch .\nWhen a variable goes out of scope, all statements still in the “undecided”\nstate are changed to “unused”, unless the variable is the return\nparameter of a function - there, the state changes to “used”.\nIn the second traversal, all assignments that are in the “unused” state are removed.\nThis step is usually run right after the SSA transform to complete\nthe generation of the pseudo-SSA.\nTools \nMovability \nMovability is a property of an expression. It roughly means that the expression\nis side-effect free and its evaluation only depends on the values of variables\nand the call-constant state of the environment. Most expressions are movable.\nThe following parts make an expression non-movable:\n-\nfunction calls (might be relaxed in the future if all statements in the function are movable)\n-\nopcodes that (can) have side-effects (like call or selfdestruct )\n-\nopcodes that read or write memory, storage or external state information\n-\nopcodes that depend on the current PC, memory size or returndata size\nDataflowAnalyzer \nThe DataflowAnalyzer is not an optimizer step itself but is used as a tool\nby other components. While traversing the AST, it tracks the current value of\neach variable, as long as that value is a movable expression.\nIt records the variables that are part of the expression\nthat is currently assigned to each other variable. Upon each assignment to\na variable a , the current stored value of a is updated and\nall stored values of all variables b are cleared whenever a is part\nof the currently stored expression for b .\nAt control-flow joins, knowledge about variables is cleared if they have or would be assigned\nin any of the control-flow paths. For instance, upon entering a\nfor loop, all variables are cleared that will be assigned during the\nbody or the post block.\nExpression-Scale Simplifications \nThese simplification passes change expressions and replace them by equivalent\nand hopefully simpler expressions.\nCommonSubexpressionEliminator \nThis step uses the DataflowAnalyzer and replaces subexpressions that\nsyntactically match the current value of a variable by a reference to\nthat variable. This is an equivalence transform because such subexpressions have\nto be movable.\nAll subexpressions that are identifiers themselves are replaced by their\ncurrent value if the value is an identifier.\nThe combination of the two rules above allow to compute a local value\nnumbering, which means that if two variables have the same\nvalue, one of them will always be unused. The UnusedPruner or the\nUnusedAssignEliminator will then be able to fully eliminate such\nvariables.\nThis step is especially efficient if the ExpressionSplitter is run\nbefore. If the code is in pseudo-SSA form,\nthe values of variables are available for a longer time and thus we\nhave a higher chance of expressions to be replaceable.\nThe ExpressionSimplifier will be able to perform better replacements\nif the CommonSubexpressionEliminator was run right before it.\nExpressionSimplifier \nThe ExpressionSimplifier uses the DataflowAnalyzer and makes use\nof a list of equivalence transforms on expressions like X + 0 -> X\nto simplify the code.\nIt tries to match patterns like X + 0 on each subexpression.\nDuring the matching procedure, it resolves variables to their currently\nassigned expressions to be able to match more deeply nested patterns\neven when the code is in pseudo-SSA form.\nSome of the patterns like X - X -> 0 can only be applied as long\nas the expression X is movable, because otherwise it would remove its potential side-effects.\nSince variable references are always movable, even if their current\nvalue might not be, the ExpressionSimplifier is again more powerful\nin split or pseudo-SSA form.\nLiteralRematerialiser \nTo be documented.\nLoadResolver \nOptimisation stage that replaces expressions of type sload(x) and mload(x) by the value\ncurrently stored in storage resp. memory, if known.\nWorks best if the code is in SSA form.\nPrerequisites: Disambiguator, ForLoopInitRewriter.\nStatement-Scale Simplifications \nCircularReferencesPruner \nThis stage removes functions that call each other but are\nneither externally referenced nor referenced from the outermost context.\nConditionalSimplifier \nThe ConditionalSimplifier inserts assignments to condition variables if the value can be determined\nfrom the control-flow.\nDestroys SSA form.\nCurrently, this tool is very limited, mostly because we do not yet have support\nfor boolean types. Since conditions only check for expressions being nonzero,\nwe cannot assign a specific value.\nCurrent features:\n-\nswitch cases: insert := \n-\nafter if statement with terminating control-flow, insert := 0\nFuture features:\n-\nallow replacements by 1\n-\ntake termination of user-defined functions into account\nWorks best with SSA form and if dead code removal has run before.\nPrerequisite: Disambiguator.\nConditionalUnsimplifier \nReverse of ConditionalSimplifier.\nControlFlowSimplifier \nSimplifies several control-flow structures:\n-\nreplace if with empty body with pop(condition)\n-\nremove empty default switch case\n-\nremove empty switch case if no default case exists\n-\nreplace switch with no cases with pop(expression)\n-\nturn switch with single case into if\n-\nreplace switch with only default case with pop(expression) and body\n-\nreplace switch with const expr with matching case body\n-\nreplace for with terminating control flow and without other break / continue by if\n-\nremove leave at the end of a function.\nNone of these operations depend on the data flow. The StructuralSimplifier\nperforms similar tasks that do depend on data flow.\nThe ControlFlowSimplifier does record the presence or absence of break\nand continue statements during its traversal.\nPrerequisite: Disambiguator, FunctionHoister, ForLoopInitRewriter.\nImportant: Introduces EVM opcodes and thus can only be used on EVM code for now.\nDeadCodeEliminator \nThis optimization stage removes unreachable code.\nUnreachable code is any code within a block which is preceded by a\nleave , return , invalid , break , continue , selfdestruct , revert or by\na call to a user-defined function that recurses infinitely.\nFunction definitions are retained as they might be called by earlier\ncode and thus are considered reachable.\nBecause variables declared in a for loop’s init block have their scope extended to the loop body,\nwe require ForLoopInitRewriter to run before this step.\nPrerequisites: ForLoopInitRewriter, FunctionHoister, FunctionGrouper.\nEqualStoreEliminator \nThis steps removes mstore(k, v) and sstore(k, v) calls if\nthere was a previous call to mstore(k, v) / sstore(k, v) ,\nno other store in between and the values of k and v did not change.\nThis simple step is effective if run after the SSATransform and the\nCommonSubexpressionEliminator, because SSA will make sure that the variables\nwill not change and the CommonSubexpressionEliminator reuses exactly the same\nvariable if the value is known to be the same.\nPrerequisites: Disambiguator, ForLoopInitRewriter.\nUnusedPruner \nThis step removes the definitions of all functions that are never referenced.\nIt also removes declarations of variables that are never referenced.\nIf a declaration assigns a value that is not movable, the expression is retained,\nbut its value is discarded.\nAll movable expression statements (expressions that are not assigned) are removed.\nStructuralSimplifier \nThis is a general step that performs various kinds of simplifications on\na structural level:\n-\nreplace if statement with empty body by pop(condition)\n-\nreplace if statement with true condition by its body\n-\nremove if statement with false condition\n-\nturn switch with single case into if\n-\nreplace switch with only default case by pop(expression) and body\n-\nreplace switch with literal expression by matching case body\n-\nreplace for loop with false condition by its initialization part\nThis component uses the DataflowAnalyzer.\nBlockFlattener \nThis stage eliminates nested blocks by inserting the statements in the\ninner block at the appropriate place in the outer block. It depends on the\nFunctionGrouper and does not flatten the outermost block to keep the form\nproduced by the FunctionGrouper.\nopen in Remix\n{\nlet x := 2\n{\nlet y := 3\nmstore ( x , y )\n}\nis transformed to\nopen in Remix\n{\nlet x := 2\nlet y := 3\nmstore ( x , y )\n}\nAs long as the code is disambiguated, this does not cause a problem because\nthe scopes of variables can only grow.\nLoopInvariantCodeMotion \nThis optimization moves movable SSA variable declarations outside the loop.\nOnly statements at the top level in a loop’s body or post block are considered, i.e variable\ndeclarations inside conditional branches will not be moved out of the loop.\nExpressionSplitter and SSATransform should be run upfront to obtain better results.\nPrerequisites: Disambiguator, ForLoopInitRewriter, FunctionHoister.\nFunction-Level Optimizations \nFunctionSpecializer \nThis step specializes the function with its literal arguments.\nIf a function, say, function f(a, b) { sstore (a, b) } , is called with literal arguments, for\nexample, f(x, 5) , where x is an identifier, it could be specialized by creating a new\nfunction f_1 that takes only one argument, i.e.,\nopen in Remix\nfunction f_1 ( a_1 ) {\nlet b_1 := 5\nsstore ( a_1 , b_1 )\n}\nOther optimization steps will be able to make more simplifications to the function. The\noptimization step is mainly useful for functions that would not be inlined.\nPrerequisites: Disambiguator, FunctionHoister.\nLiteralRematerialiser is recommended as a prerequisite, even though it’s not required for\ncorrectness.\nUnusedFunctionParameterPruner \nThis step removes unused parameters in a function.\nIf a parameter is unused, like c and y in, function f(a,b,c) -> x, y { x := div(a,b) } , we\nremove the parameter and create a new “linking” function as follows:\nopen in Remix\nfunction f ( a , b ) -> x { x := div ( a , b ) }\nfunction f2 ( a , b , c ) -> x , y { x := f ( a , b ) }\nand replace all references to f by f2 .\nThe inliner should be run afterwards to make sure that all references to f2 are replaced by\nf .\nPrerequisites: Disambiguator, FunctionHoister, LiteralRematerialiser.\nThe step LiteralRematerialiser is not required for correctness. It helps deal with cases such as:\nfunction f(x) -> y { revert(y, y} } where the literal y will be replaced by its value 0 ,\nallowing us to rewrite the function.\nUnusedStoreEliminator \nOptimizer component that removes redundant sstore and memory store statements.\nIn case of an sstore , if all outgoing code paths revert (due to an explicit revert() , invalid() , or infinite recursion) or\nlead to another sstore for which the optimizer can tell that it will overwrite the first store, the statement will be removed.\nHowever, if there is a read operation between the initial sstore and the revert, or the overwriting sstore , the statement\nwill not be removed.\nSuch read operations include: external calls, user-defined functions with any storage access, and sload of a slot that cannot be\nproven to differ from the slot written by the initial sstore .\nFor example, the following code\nopen in Remix\n{\nlet c := calldataload ( 0 )\nsstore ( c , 1 )\nif c {\nsstore ( c , 2 )\n}\nsstore ( c , 3 )\n}\nwill be transformed into the code below after the UnusedStoreEliminator step is run\nopen in Remix\n{\nlet c := calldataload ( 0 )\nif c { }\nsstore ( c , 3 )\n}\nFor memory store operations, things are generally simpler, at least in the outermost Yul block as all such\nstatements will be removed if they are never read from in any code path.\nAt function analysis level, however, the approach is similar to sstore , as we do not know whether the memory location will\nbe read once we leave the function’s scope, so the statement will be removed only if all code paths lead to a memory overwrite.\nBest run in SSA form.\nPrerequisites: Disambiguator, ForLoopInitRewriter.\nEquivalentFunctionCombiner \nIf two functions are syntactically equivalent, while allowing variable\nrenaming but not any re-ordering, then any reference to one of the\nfunctions is replaced by the other.\nThe actual removal of the function is performed by the UnusedPruner.\nFunction Inlining \nExpressionInliner \nThis component of the optimizer performs restricted function inlining by inlining functions that can be\ninlined inside functional expressions, i.e. functions that:\n-\nreturn a single value.\n-\nhave a body like r := .\n-\nneither reference themselves nor r in the right hand side.\nFurthermore, for all parameters, all of the following need to be true:\n-\nThe argument is movable.\n-\nThe parameter is either referenced less than twice in the function body, or the argument is rather cheap\n(“cost” of at most 1, like a constant up to 0xff ).\nExample: The function to be inlined has the form of function f(...) -> r { r := E } where\nE is an expression that does not reference r and all arguments in the function call are movable expressions.\nThe result of this inlining is always a single expression.\nThis component can only be used on sources with unique names.\nFullInliner \nThe FullInliner replaces certain calls of certain functions\nby the function’s body. This is not very helpful in most cases, because\nit just increases the code size but does not have a benefit. Furthermore,\ncode is usually very expensive and we would often rather have shorter\ncode than more efficient code. In some cases, though, inlining a function\ncan have positive effects on subsequent optimizer steps. This is the case\nif one of the function arguments is a constant, for example.\nDuring inlining, a heuristic is used to tell if the function call\nshould be inlined or not.\nThe current heuristic does not inline into “large” functions unless\nthe called function is tiny. Functions that are only used once"}
{"url":"https://docs.layerzero.network/v2/concepts/workers","domain":"docs.layerzero.network","title":"Workers in LayerZero V2 - LayerZero","hash":"28ad1869de8a228133ecec6625805a857aa0340147cf177137cd45832a1fcb61","tokens":797,"chars":3186,"crawler":"crawler-f6nn","verified":"exact","ts":1791172167701,"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\nWorkers\nWorkers in LayerZero V2\nIn the LayerZero V2 protocol, Workers serve as the umbrella term for two key types of service providers: Decentralized Verifier Networks (DVNs) and…\nIn the LayerZero V2 protocol, Workers serve as the umbrella term for two key types of service providers: Decentralized Verifier Networks (DVNs) and Executors .\nBoth play crucial roles in facilitating crosschain messaging and execution by providing verification and execution services. By abstracting these roles under the common interface known as a worker , LayerZero ensures a consistent and secure method to interact with both service types.\nWhat Are Workers?\nWorkers are specialized entities that interact with the protocol to perform essential functions:\n-\nVerification as a Service: Decentralized Verifier Networks (DVNs), verify the authenticity and correctness of messages or transactions across chains.\n-\nExecution as a Service: Executors are responsible for carrying out actions requiring gas or compute units (transactions) on behalf of applications once verification is complete.\nThese roles are unified under the Worker interface, meaning that whether a service provider is a DVN or an Executor, it interacts with the protocol using a standardized set of methods.\nCommon Responsibilities\nBoth DVNs and Executors share several common responsibilities managed through the Worker contract:\n-\nPrice Feeds: Maintaining up-to-date pricing information relevant to transaction fees or service costs.\n-\nFee Management: Handling fees associated with using the service, ensuring that both service providers and application owners have clear, consistent cost structures.\nBy consolidating these responsibilities, the protocol simplifies the integration of different types of service providers while maintaining security and performance standards.\nThe Role of the Protocol\nEndpointV2 uses a MessageLibManager.sol contract, responsible for the configuration and management of off-chain workers. Key features include:\n-\nApplication-specific configurations: Applications can select specific message libraries, allowing them to tailor the protocol’s behavior to meet their unique security and trust requirements.\n-\nCustomizable settings: Developers can set configurations for how messages are processed within each library, determine which off-chain entities are responsible for handling message delivery, and handle payment for these services.\n-\nDecentralization and flexibility: Instead of forcing every application into a one-size-fits-all approach,LayerZero V2 provides the flexibility needed to configure off-chain workers in a way that best fits the application’s design and security model.\nThis architecture allows LayerZero V2 to provide robust, decentralized crosschain communication while giving application developers the tools needed to fine-tune their security and operational parameters.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://discuss.ens.domains/c/service-provider-program/75","domain":"discuss.ens.domains","title":"Latest Service Provider Program topics - ENS DAO Governance Forum","hash":"5b957b27679fcb5cd5d6d61f507e33a475751780657c65d676b75f7d80b72627","tokens":787,"chars":3146,"crawler":"crawler-f6nn","verified":"exact","ts":1791172170033,"text":"ENS DAO Governance Forum\nService Provider Program\nReports\nService provider reports, typically submitted quarterly, covering progress, milestones, budget use, blockers, and other updates relevant to funded ENS DAO service provider work.\nProgram Discussion and Admin\nCurrent SPP applications and discussions.\nSP Applications\nApplications for programs\nTopic\nReplies\nViews\nActivity\nNamespace - Quarterly Reports\nReports\nservice-providers\n10\n2083\nOctober 2, 2026\nNamespace: SPP3 Quarterly Reports\nReports\nservice-providers\n1\n94\nOctober 2, 2026\nBlockful - service provider reports and updates\nReports\nservice-providers\n11\n1020\nSeptember 8, 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\nFluidkey: SPP3 Quarterly Reports\nReports\nservice-providers\n0\n59\nAugust 19, 2026\nUnruggable: SPP3 Quarterly Reports\nReports\nservice-providers\n0\n47\nAugust 19, 2026\nJustaName - Quarterly Reports\nReports\nservice-providers\n4\n476\nAugust 3, 2026\nUnruggable Quarterly Report, Q2 2026\nReports\nservice-providers\n0\n61\nJuly 28, 2026\nEth.limo Q2 2026 - Update\nReports\n0\n77\nJuly 23, 2026\nMarketplace RFP: Submission Timeline and Artifacts\nProgram Discussion and Admin\n1\n398\nJuly 22, 2026\nSPP3: Submission Timeline and Artifacts\nProgram Discussion and Admin\n10\n1064\nJune 26, 2026\nSPP3: Applications Now Open\nProgram Discussion and Admin\n9\n778\nJune 4, 2026\nUnruggable: SPP2 Q1 2026 Quarterly Report\nReports\nservice-providers\n0\n93\nJune 3, 2026\nUnruggable: Update and SPP2 Q4 2025 Quarterly Report\nReports\nservice-providers\n0\n102\nApril 28, 2026\nSPP2: ZK Email Application\nSP Applications\n15\n1217\nApril 28, 2026\nNameHash Labs - Service Provider Reports\nReports\nservice-providers\n3\n400\nApril 16, 2026\nProposal: Committee Model for SPP3 Funding Allocation\nProgram Discussion and Admin\n34\n1043\nApril 14, 2026\nENS Service Provider Accountability\nService Provider Program\nservice-providers\n5\n268\nApril 7, 2026\nEthID/EFP: SPP financial and progress reports\nReports\nservice-providers\n5\n904\nApril 7, 2026\nUnruggable: Update and SPP2 Q3 2025 Quarterly Report\nReports\nservice-providers\n0\n137\nDecember 4, 2025\nTemp Check: Rethinking SPP Voting—Selection First, Allocation Second\nProgram Discussion and Admin\nservice-providers\n2\n272\nNovember 12, 2025\nWhy are Service Providers Presenting Less?\nProgram Discussion and Admin\n6\n319\nNovember 9, 2025\nSPP2 Stream Reactivation - Backpay Calculations\nProgram Discussion and Admin\n0\n105\nSeptember 13, 2025\nUnruggable: SPP2 Q2 2025 Quarterly Report\nReports\nservice-providers\n5\n382\nAugust 19, 2025\nToward Accountable and Strategic Funding in ENS\nProgram Discussion and Admin\n12\n790\nJuly 12, 2025\nSPP2 Stream Implementation - Preparing the Executable Proposal\nService Provider Program\n7\n392\nJune 23, 2025\nOpt-in streams in sUSDS: More resources with no additional cost\nProgram Discussion and Admin\n6\n224\nJune 20, 2025\nSPP2 Retroactive Grant - Custom Voting Interface Contributors\nProgram Discussion and Admin\n4\n209\nJune 12, 2025\nVoting Report (slobo.eth)\nProgram Discussion and Admin\n0\n177\nMay 11, 2025\nnext page →"}
{"url":"https://docs.lightning.engineering/the-lightning-network/multihop-payments/instant-submarine-swaps","domain":"docs.lightning.engineering","title":"Instant Submarine Swaps | Builder's Guide","hash":"4c061c425d2a95b523e746a611e8854e6a0faf649df8c7765a01ead1ed79e8db","tokens":521,"chars":2084,"crawler":"crawler-f6nn","verified":"exact","ts":1791172172946,"text":"Builder's Guide\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nInstant Submarine Swaps\nInstant submarine swaps are a form of atomic swap that makes onchain funds immediately available without needing to wait for block confirmations.\nA submarine swap is a type of atomic swap that describes the trustless interchange of onchain and offchain funds. The swap either completes in full, or fails.\nRead more: Understanding submarine swaps\nTraditional submarine swaps, such as those used by Loop, require the recipient of the onchain funds to wait for block confirmations before they can take control over their funds.\nInstant submarine swaps are more chain efficient and make funds available immediately once the Lightning payment has been completed and the preimage obtained. This can be still be accomplished without introducing trust into the procedure.\nThis is done by making a reservation ahead of time of the desired amount to be swapped. This gives the submarine swap provider more time to batch reservations and get the transaction confirmed at a lower fee. Each reservation is an output similar to an ordinary submarine HTLC.\nThe provider is able to retrieve their funds after a certain timeout has been reached, limiting their risk to the costs of the onchain transaction and the opportunity costs of funds locked.\nThe user is able to retrieve their funds using the preimage, which they can obtain through an invoice created at the time of the Instant Loop Out.\nTo make the process more efficient, the output of the reservation can be made spendable with a two-of-two MuSig2 schnorr signature. Both the provider and the user originally hold their own unique keys. Upon successful completion of the swap, the provider can co-sign transactions initiated by the user, allowing the user to spend their funds without publicly revealing the preimage or paying more than the minimal onchain fees.\nLearn: How to make Instant Loop Outs\nPrevious Understanding Submarine Swaps\nNext Liquidity\nLast updated 2 years ago\nWas this helpful?"}
{"url":"https://docs.ens.domains/web/reverse","domain":"docs.ens.domains","title":"Primary Names | ENS Docs","hash":"b601af295a275fa6de13139373d3cec5b343207102b7f0416f3e2128b9661f2e","tokens":1406,"chars":5624,"crawler":"crawler-f6nn","verified":"exact","ts":1791172175288,"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\nPrimary Names\nA \"primary name\" is the result of a bi-directional relationship between an EVM address and a human-readable ENS name. The two directions are:\n- Name -> Address (forward resolution)\n- Address -> Name (reverse resolution)\nThe outcome of this relationship makes it safe for applications to display ENS names instead of EVM addresses, leading to a better user experience.\n0xb8c...67d5 to\nnick.eth\nWhile forward resolution is configured in Resolvers , reverse records are typically set via smart contracts called Reverse Registrars which you can read more about below .\nL2 Primary Names\nBefore we dive into code examples, let's first understand why things work the way they do.\nPrior to August 2025, ENS users had to make a transaction on Ethereum Mainnet (L1) to set a primary name. More specifically, they had to set a reverse record on the Reverse Registrar contract which was only available on L1.\nWhat is the difference between a reverse record and a primary name?\nA reverse record is a mapping from an EVM address to an ENS name, which is only part of a primary name. In order for a primary name to be valid, the name must also forward resolve to the same address on the respective chain.\nSince a majority of user activity is now on L2s, we've added the ability to set a reverse record on the following Ethereum Rollups:\n- Arbitrum\n- Base\n- Linea\n- OP Mainnet\n- Scroll\nIn addition to these chains, we've also added the ability to set a default reverse record on Ethereum Mainnet (L1) that serves as a fallback when no chain-specific primary name is set. This is the simplest way to set a universal primary name for users who have a wallet that supports all EVM chains.\nWhile this may sound simple in theory, it's easy to get tripped on the details in practice. Let's look at an example.\nUnderstanding the Verification Process\nThe key thing to understand is that the forward address for a given chain must match the reverse record on the respective chain's reverse registrar.\nSay I own nick.eth . The name resolves to 0x1234...5678 because I've set the ETH address for that name. I call setName(\"nick.eth\") on the Base reverse registrar, and I expect that my primary name is now nick.eth on Base. But that's actually not the case.\nENS names can resolve to different addresses on different chains , and since nick.eth in the example above has only specified an Ethereum Mainnet address, the verification process will fail. In order to fix this, I need to set the Base address for nick.eth which is on L1 in this case. This is done by calling the following function on the resolver for the name.\nsetAddr (\nnamehash ( \"nick.eth\" ), // node (see Name Processing)\nconvertEVMChainIdToCoinType ( 8453 ), // coinType (see ENSIP-11)\n0x1234 ... 5678 // the address to set\n)\nNow that nick.eth resolves to 0x1234...5678 via the Base cointype, and name(0x1234...5678) on the Base reverse registrar returns nick.eth , my primary name is fully set.\nAn alternative approach, which would be more efficient in this case, is to set the default EVM address for nick.eth on the latest public resolver , and the default reverse record to nick.eth on the default reverse registrar. This would allow the name to resolve to the correct address on all chains.\nGetting a Primary Name\nLooking up a users L1 primary name is very simple. In most web3 libraries (wagmi, viem, ethers, web3py, etc.), you will find a built-in function to do a lookup by address as shown below. In most cases, the library will handle the verification for you.\nRemember that in all cases, ENS resolution always starts from Ethereum Mainnet.\nWagmi\n// https://wagmi.sh/react/hooks/useEnsName\nimport { useEnsName } from 'wagmi'\nimport { mainnet } from 'wagmi/chains'\nexport const Name = () => {\nconst { data : name } = useEnsName ({\naddress: '0xb8c2C29ee19D8307cb7255e1Cd9CbDE883A267d5' ,\nchainId: mainnet.id, // resolution always starts from L1\n})\nreturn < div >Name: { name } \n}\nAs of September 2025, Wagmi and Viem are the only libraries that support L2 Primary Names, and they can be used like this:\nWagmi\n// https://wagmi.sh/react/hooks/useEnsName\nimport { toCoinType } from 'viem'\nimport { useEnsName } from 'wagmi'\nimport { base, mainnet } from 'wagmi/chains'\nexport const Name = () => {\nconst { data : name } = useEnsName ({\naddress: '0xb8c2C29ee19D8307cb7255e1Cd9CbDE883A267d5' ,\nchainId: mainnet.id, // resolution always starts from L1\ncoinType: toCoinType (base.id),\n})\nreturn < div >Name: { name } \n}\n🎉 And that's it! Now you can turn all your pages from this, to this:\n0xb8c2...67d5\nsent 0.1 ETH to\n0xd8dA....6045\nturns into\nnick.eth\nsent 0.1 ETH to\nvitalik.eth\nSetting Primary Names\nSince primary names require two-way resolution, there are technically two steps to setting it up. Let's say that user 0x1234...5678 wants to set their primary name on Base to nick.eth .\nFirst, the user would need to set the Base address for nick.eth to 0x1234...5678 . Read more about multichain addresses to understand how this works.\nNext, the user would need to set the reverse record for 0x1234...5678 to nick.eth in the Base Reverse Registrar. Read more about reverse records to understand how this works.\nIn order to avoid doing this manually for multiple chains, the user can set their default reverse record to nick.eth on the default reverse registrar, and their default EVM address to 0x1234...5678 on the latest public resolver .\nReverse Registrars Learn more about the smart contracts that manage reverse records on L1 and L2s."}
{"url":"https://docs.monad.xyz/tooling-and-infra/earn-yield","domain":"docs.monad.xyz","title":"Earn/Yield Infrastructure - Monad Documentation","hash":"145a7f1ddab032a99f590d6adb1d79807338aabaaa1ae4b1b57a28c3419b8f63","tokens":779,"chars":3114,"crawler":"crawler-f6nn","verified":"exact","ts":1791172177288,"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\nEarn/Yield Infrastructure\nEarn/yield infrastructure providers offer vaults, strategies, and APIs that let builders embed\nyield-generating products — staking, lending, and DeFi strategies — directly into their apps,\nwithout integrating each underlying protocol individually.\nProvider Summary\nProvider Docs Description\nBlend Docs Compliance-first account layer that lets platforms offer non-custodial yield, routing stablecoin and DeFi yields across sources like Morpho and Aave.\nPods Finance Docs Yield aggregation platform that routes deposits into strategies across DeFi protocols such as Aave, Morpho, and Lido, with cross-chain and same-chain swaps.\nVaults.fyi Docs Yield-data API that normalizes yields across 1,000+ vaults and 80+ protocols, exposing market data, transaction payloads, and portfolio tracking.\nVeda Docs Institutional-grade vault infrastructure that lets partners embed customizable onchain yield with built-in risk and compliance controls.\nYield.xyz Docs Non-custodial yield API powering wallets, custodians, and AI agents across 80+ networks, with a unified interface for staking, DeFi lending, and restaking.\nProvider details\nBlend\nBlend is a compliance-first account layer that lets platforms offer non-custodial yield products to their users. It routes stablecoin and DeFi yields across sources like Morpho and Aave through individual user accounts, with built-in screening and reporting.\nTo get started, visit the documentation .\nPods Finance\nPods Finance is a DeFi yield aggregation platform that routes deposits into yield strategies across protocols such as Aave, Morpho, and Lido. It also supports cross-chain and same-chain token swaps, helping users discover optimal yield opportunities and manage positions from a single interface.\nTo get started, visit the documentation .\nVaults.fyi\nVaults.fyi is a REST API that normalizes yield data across 1,000+ vaults and 80+ protocols, letting builders integrate DeFi earning features without protocol-by-protocol development. It provides market data, transaction payloads, portfolio tracking, and an MCP server for AI agents to query and compare yields across networks.\nTo get started, visit the documentation .\nVeda\nVeda is a DeFi infrastructure platform that provides institutional-grade vaults, enabling organizations to offer onchain yield products with built-in risk and compliance controls. Partners can embed customizable earn features directly into their own platforms.\nTo get started, visit the documentation .\nYield.xyz\nYield.xyz is a non-custodial yield API that powers wallets, custodians, and AI agents across 80+ networks. It provides a unified interface for staking, DeFi lending, restaking, and other onchain yield opportunities, with self-custodial transaction construction.\nTo get started, visit the documentation .\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.anza.xyz/cli/examples/offline-signing","domain":"docs.anza.xyz","title":"Offline Transaction Signing with the Solana CLI | Agave","hash":"81488ea9e3d64d401dc1ebeb89cfc1b5bfab1100c15a9e85fffa14df60c0b5db","tokens":1471,"chars":5882,"crawler":"crawler-f6nn","verified":"exact","ts":1791172179587,"text":"Skip to main content\nOffline Transaction Signing with the Solana CLI\nSome security models require keeping signing keys, and thus the signing\nprocess, separated from transaction creation and network broadcast. Examples\ninclude:\n- Collecting signatures from geographically disparate signers in a\nmulti-signature scheme\n- Signing transactions using an air-gapped\nsigning device\nThis document describes using Solana's CLI to separately sign and submit a\ntransaction.\nCommands Supporting Offline Signing\nAt present, the following commands support offline signing:\n-\ncreate-stake-account\n-\ncreate-stake-account-checked\n-\ndeactivate-stake\n-\ndelegate-stake\n-\nsplit-stake\n-\nstake-authorize\n-\nstake-authorize-checked\n-\nstake-set-lockup\n-\nstake-set-lockup-checked\n-\ntransfer\n-\nwithdraw-stake\n-\ncreate-vote-account\n-\nvote-authorize-voter\n-\nvote-authorize-voter-checked\n-\nvote-authorize-withdrawer\n-\nvote-authorize-withdrawer-checked\n-\nvote-update-commission\n-\nvote-update-validator\n-\nwithdraw-from-vote-account\nSigning Transactions Offline\nTo sign a transaction offline, pass the following arguments on the command line\n- --sign-only , prevents the client from submitting the signed transaction\nto the network. Instead, the pubkey/signature pairs are printed to stdout.\n- --blockhash BASE58_HASH , allows the caller to specify the value used to\nfill the transaction's recent_blockhash field. This serves a number of\npurposes, namely:\n_ Eliminates the need to connect to the network and query a recent blockhash\nvia RPC\n_ Enables the signers to coordinate the blockhash in a multiple-signature\nscheme\nExample: Offline Signing a Payment\nCommand\nsolana@offline$ solana transfer --sign-only --blockhash 5Tx8F3jgSHx21CbtjwmdaKPLM5tWmreWAnPrbqHomSJF \\\nrecipient-keypair.json 1\nOutput\nBlockhash: 5Tx8F3jgSHx21CbtjwmdaKPLM5tWmreWAnPrbqHomSJF\nSigners (Pubkey=Signature):\nFhtzLVsmcV7S5XqGD79ErgoseCLhZYmEZnz9kQg1Rp7j=4vC38p4bz7XyiXrk6HtaooUqwxTWKocf45cstASGtmrD398biNJnmTcUCVEojE7wVQvgdYbjHJqRFZPpzfCQpmUN\n{\"blockhash\":\"5Tx8F3jgSHx21CbtjwmdaKPLM5tWmreWAnPrbqHomSJF\",\"signers\":[\"FhtzLVsmcV7S5XqGD79ErgoseCLhZYmEZnz9kQg1Rp7j=4vC38p4bz7XyiXrk6HtaooUqwxTWKocf45cstASGtmrD398biNJnmTcUCVEojE7wVQvgdYbjHJqRFZPpzfCQpmUN\"]}'\nSubmitting Offline Signed Transactions to the Network\nTo submit a transaction that has been signed offline to the network, pass the\nfollowing arguments on the command line\n- --blockhash BASE58_HASH , must be the same blockhash as was used to sign\n- --signer BASE58_PUBKEY=BASE58_SIGNATURE , one for each offline signer. This\nincludes the pubkey/signature pairs directly in the transaction rather than\nsigning it with any local keypair(s)\nExample: Submitting an Offline Signed Payment\nCommand\nsolana@online$ solana transfer --blockhash 5Tx8F3jgSHx21CbtjwmdaKPLM5tWmreWAnPrbqHomSJF \\\n--signer FhtzLVsmcV7S5XqGD79ErgoseCLhZYmEZnz9kQg1Rp7j=4vC38p4bz7XyiXrk6HtaooUqwxTWKocf45cstASGtmrD398biNJnmTcUCVEojE7wVQvgdYbjHJqRFZPpzfCQpmUN\nrecipient-keypair.json 1\nOutput\n4vC38p4bz7XyiXrk6HtaooUqwxTWKocf45cstASGtmrD398biNJnmTcUCVEojE7wVQvgdYbjHJqRFZPpzfCQpmUN\nOffline Signing Over Multiple Sessions\nOffline signing can also take place over multiple sessions. In this scenario,\npass the absent signer's public key for each role. All pubkeys that were specified,\nbut no signature was generated for will be listed as absent in the offline signing\noutput\nExample: Transfer with Two Offline Signing Sessions\nCommand (Offline Session #1)\nsolana@offline1$ solana transfer Fdri24WUGtrCXZ55nXiewAj6RM18hRHPGAjZk3o6vBut 10 \\\n--blockhash 7ALDjLv56a8f6sH6upAZALQKkXyjAwwENH9GomyM8Dbc \\\n--sign-only \\\n--keypair fee_payer.json \\\n--from 674RgFMgdqdRoVtMqSBg7mHFbrrNm1h1r721H1ZMquHL\nOutput (Offline Session #1)\nBlockhash: 7ALDjLv56a8f6sH6upAZALQKkXyjAwwENH9GomyM8Dbc\nSigners (Pubkey=Signature):\n3bo5YiRagwmRikuH6H1d2gkKef5nFZXE3gJeoHxJbPjy=ohGKvpRC46jAduwU9NW8tP91JkCT5r8Mo67Ysnid4zc76tiiV1Ho6jv3BKFSbBcr2NcPPCarmfTLSkTHsJCtdYi\nAbsent Signers (Pubkey):\n674RgFMgdqdRoVtMqSBg7mHFbrrNm1h1r721H1ZMquHL\nCommand (Offline Session #2)\nsolana@offline2$ solana transfer Fdri24WUGtrCXZ55nXiewAj6RM18hRHPGAjZk3o6vBut 10 \\\n--blockhash 7ALDjLv56a8f6sH6upAZALQKkXyjAwwENH9GomyM8Dbc \\\n--sign-only \\\n--keypair from.json \\\n--fee-payer 3bo5YiRagwmRikuH6H1d2gkKef5nFZXE3gJeoHxJbPjy\nOutput (Offline Session #2)\nBlockhash: 7ALDjLv56a8f6sH6upAZALQKkXyjAwwENH9GomyM8Dbc\nSigners (Pubkey=Signature):\n674RgFMgdqdRoVtMqSBg7mHFbrrNm1h1r721H1ZMquHL=3vJtnba4dKQmEAieAekC1rJnPUndBcpvqRPRMoPWqhLEMCty2SdUxt2yvC1wQW6wVUa5putZMt6kdwCaTv8gk7sQ\nAbsent Signers (Pubkey):\n3bo5YiRagwmRikuH6H1d2gkKef5nFZXE3gJeoHxJbPjy\nCommand (Online Submission)\nsolana@online$ solana transfer Fdri24WUGtrCXZ55nXiewAj6RM18hRHPGAjZk3o6vBut 10 \\\n--blockhash 7ALDjLv56a8f6sH6upAZALQKkXyjAwwENH9GomyM8Dbc \\\n--from 674RgFMgdqdRoVtMqSBg7mHFbrrNm1h1r721H1ZMquHL \\\n--signer 674RgFMgdqdRoVtMqSBg7mHFbrrNm1h1r721H1ZMquHL=3vJtnba4dKQmEAieAekC1rJnPUndBcpvqRPRMoPWqhLEMCty2SdUxt2yvC1wQW6wVUa5putZMt6kdwCaTv8gk7sQ \\\n--fee-payer 3bo5YiRagwmRikuH6H1d2gkKef5nFZXE3gJeoHxJbPjy \\\n--signer 3bo5YiRagwmRikuH6H1d2gkKef5nFZXE3gJeoHxJbPjy=ohGKvpRC46jAduwU9NW8tP91JkCT5r8Mo67Ysnid4zc76tiiV1Ho6jv3BKFSbBcr2NcPPCarmfTLSkTHsJCtdYi\nOutput (Online Submission)\nohGKvpRC46jAduwU9NW8tP91JkCT5r8Mo67Ysnid4zc76tiiV1Ho6jv3BKFSbBcr2NcPPCarmfTLSkTHsJCtdYi\nBuying More Time to Sign\nTypically a Solana transaction must be signed and accepted by the network within\na number of slots from the blockhash in its recent_blockhash field (~1min at\nthe time of this writing). If your signing procedure takes longer than this, a\nDurable Transaction Nonce can give you the extra time you\nneed.\n- Commands Supporting Offline Signing\n- Signing Transactions Offline\n- Example: Offline Signing a Payment\n- Submitting Offline Signed Transactions to the Network\n- Example: Submitting an Offline Signed Payment\n- Offline Signing Over Multiple Sessions\n- Example: Transfer with Two Offline Signing Sessions\n- Buying More Time to Sign"}
{"url":"https://docs.ethena.fi/backing-custody-and-security/real-time-dashboards","domain":"docs.ethena.fi","title":"Real-Time Dashboards | Ethena","hash":"213a9c52e4b029bc4c5c60994ac13d1494bcda27e99cc51b04a1e78be118adf5","tokens":177,"chars":705,"crawler":"crawler-f6nn","verified":"exact","ts":1791172182457,"text":"⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nReal-Time Dashboards\nBelow is the main Ethena dashboard highlighting Ethena's positions across different exchanges and assets.\nPositions Dashboard\nCopper & Ceffu operate omnibus solutions with hot/warm/cold wallets wherein all of their users' funds are co-mingled. This does not break or compromise the protocol's ownership or claim on the backing in either solution.\nAs a result, the Copper omnibus & Ceffu deposit addresses don't represent the value of assets held by the protocol, but show the initial deposit upon direct mints of USDe with the protocol.\nLast updated 3 months ago\nWas this helpful?"}
{"url":"https://wormhole.com/docs/products/token-transfers/wrapped-token-transfers/guides/attest-tokens/","domain":"wormhole.com","title":"Token Attestation | Wormhole Docs","hash":"02220c3e8095f345f697b9f65464353f4d4b8f557bad4a43d97aef26c60816e4","tokens":4562,"chars":18246,"crawler":"crawler-f6nn","verified":"exact","ts":1791172185341,"text":"Skip to content\nInitializing search\n- Configuration\n- Concepts\n- FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\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\nToken Attestation ＃\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nThis guide demonstrates token attestation for registering a token for transfer using the Wrapped Token Transfers (WTT) protocol. An attestation of the token's metadata (e.g., symbol, name, decimals) ensures consistent handling by the destination chain for ease of multichain interoperability. These steps are only required the first time a token is sent to a particular destination chain.\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 and submit a token attestation to register a wrapped version of a token on a destination chain.\n- Check for the wrapped version to become available on the destination chain and return the wrapped token address.\nThe example will register an arbitrary ERC-20 token deployed to Moonbase Alpha for transfer to Solana, but can be adapted for any supported chains .\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 contract address for the token you wish to register.\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.\nSet Up Your Development Environment ＃\nFollow these steps to initialize your project, install dependencies, and prepare your developer environment for token attestation.\n-\nCreate a new directory and initialize a Node.js project using the following commands:\nmkdir attest-token\ncd attest-token\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 helper.ts to hold signer functions:\ntouch helper.ts\n-\nOpen helper.ts and add the following code:\nhelper.ts\nimport {\nChain ,\nChainAddress ,\nChainContext ,\nWormhole ,\nNetwork ,\nSigner ,\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 >\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. Be sure\n// to import the necessary packages for the platforms you want to support\nswitch ( platform ) {\ncase 'Evm' :\nsigner = await (\nawait evm ()\n). getSigner ( await chain . getRpc (), EVM_PRIVATE_KEY ! );\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}\nYou can view the list of supported platform constants in the Wormhole SDK GitHub repo.\nCheck for a Wrapped Version of a Token ＃\nIf you are working with a newly created token that you know has never been transferred to the destination chain, you can continue to the Create Attestation on the Source Chain section.\nSince attestation is a one-time process, it is good practice when working with existing tokens to incorporate a check for wrapped versions into your WTT flow. Follow these steps to check for a wrapped version of a token:\n-\nCreate a new file called attest.ts to hold the wrapped version check and attestation logic:\ntouch attest.ts\n-\nOpen attest.ts and add the following code:\nattest.ts\nimport {\nwormhole ,\nWormhole ,\nTokenId ,\nTokenAddress ,\n} from '@wormhole-foundation/sdk' ;\nimport { signSendWait , toNative } from '@wormhole-foundation/sdk-connect' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport { getSigner } from './helper' ;\nasync function attestToken () {\n// Initialize wormhole instance, define the network, platforms, and chains\nconst wh = await wormhole ( 'Testnet' , [ evm , solana ]);\nconst sourceChain = wh . getChain ( 'Moonbeam' );\nconst destinationChain = wh . getChain ( 'Solana' );\n// Define the token to check for a wrapped version\nconst tokenId : TokenId = Wormhole . tokenId (\nsourceChain . chain ,\n'INSERT_TOKEN_CONTRACT_ADDRESS'\n);\n// Check if the token is registered with the destination chain WTT (Token Bridge) contract\n// Registered = returns the wrapped token ID\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 ) {\n// Attestation on the source chain flow code\nconsole . log (\n'⚠️ Token is NOT registered on destination. Running attestation flow...'\n);\n}\nattestToken (). catch (( e ) => {\nconsole . error ( '❌ Error in attestToken' , e );\nprocess . exit ( 1 );\n});\nAfter initializing a Wormhole instance and defining the source and destination chains, this code does the following:\n- Defines the token to check : Use the contract address on the source chain for this value.\n- Calls getWrappedAsset : Part of the Wormhole class, the method does the following:\n- Accepts a TokenId representing a token on the source chain.\n- Checks for a corresponding wrapped version of the destination chain's WTT contract.\n- Returns the TokenId for the wrapped token on the destination chain if a wrapped version exists.\n-\nRun the script using the following command:\nnpx tsx attest.ts\n-\nIf the token has a wrapped version registered with the destination chain WTT contract, you will see terminal output similar to the following:\nnpx tsx attest.ts ✅ Token already registered on destination: SolanaAddress { type: 'Native', address: PublicKey [PublicKey(2qjSAGrpT2eTb673KuGAR5s6AJfQ1X5Sg177Qzuqt7yB)] { _bn: BN: 1b578bb9b7a04a1aab3b5b64b550d8fc4f73ab343c9cf8532d2976b77ec4a8ca } }\nYou can safely use WTT to transfer this token to the destination chain.\nIf a wrapped version isn't found on the destination chain, your terminal output will be similar to the following, and you must attest the token before transfer:\nnpx tsx attest.ts ⚠️ Token is NOT registered on destination. Running attestation flow...\nCreate Attestation on the Source Chain ＃\nTo create the attestation transaction on the source chain, open attest.ts and replace the // Attestation flow code comment with the following code:\nattest.ts\n// Retrieve the WTT (Token Bridge) contract text for the source chain\nconst tb = await sourceChain . getTokenBridge ();\n// Get the signer for the source chain\nconst sourceSigner = await getSigner ( sourceChain );\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// Create a new attestation 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);\n// Attestation on the destination chain flow code\nconsole . log ( '✅ Attestation transaction sent:' , txids );\nThis code does the following:\n- Gets the source chain WTT context : This is where the transaction is sent to create the attestation.\n- Defines the token to attest and the payer.\n- Calls createAttestation : Defined in the TokenBridge interface, the createAttestation method does the following:\n- Accepts a TokenAddress representing the token on its native chain.\n- Accepts an optional payer address to cover the transaction fees for the attestation transaction.\n- Prepares an attestation for the token, including metadata such as address, symbol, and decimals.\n- Returns an AsyncGenerator that yields unsigned transactions, which are then signed and sent to initiate the attestation process on the source chain.\nSubmit Attestation on Destination Chain ＃\nThe attestation flow finishes with the following:\n- Using the transaction ID returned from the createAttestation transaction on the source chain to retrieve the associated signed TokenBridge:AttestMeta VAA.\n- Submitting the signed VAA to the destination chain to provide Guardian-backed verification of the attestation transaction on the source chain.\n- The destination chain uses the attested metadata to create the wrapped version of the token and register it with its WTT contract.\nFollow these steps to complete your attestation flow logic:\n-\nAdd the following code to attest.ts :\nattest.ts\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) contract text for the destination chain\n// and submit the attestation VAA\nconst destTb = await destinationChain . getTokenBridge ();\n// Get the signer for the destination chain\nconst destinationSigner = await getSigner ( destinationChain );\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\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 (\ndestinationChain . chain ,\ntokenId\n);\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 (\n`🚀 Token attestation complete! Token registered with ${ destinationChain . chain } .`\n);\n-\nRun the script using the following command:\nnpx tsx attest.ts\n-\nYou will see terminal output similar to the following:\nnpx tsx attest.ts ⚠️ Token is NOT registered on destination. Running attestation flow... ✅ Attestation transaction sent: [ { chain: 'Moonbeam', txid: '0xbaf7429e1099cac6f39ef7e3c30e38776cfb5b6be837dcd8793374c8ee491799' } ] ✅ Attestation messages: [ { chain: 'Moonbeam', emitter: UniversalAddress { address: [Uint8Array] }, sequence: 1507n } ] Retrying Wormholescan:GetVaaBytes, attempt 0/750 Retrying Wormholescan:GetVaaBytes, attempt 1/750 ..... Retrying Wormholescan:GetVaaBytes, attempt 10/750 📨 Submitting attestation VAA to Solana... ✅ Attestation submitted on destination: [ { chain: 'Solana', txid: '3R4oF5P85jK3wKgkRs5jmE8BBLoM4wo2hWSgXXL6kA8efbj2Vj9vfuFSb53xALqYZuv3FnXDwJNuJfiKKDwpDH1r' } ] ✅ Wrapped token is now available on Solana: SolanaAddress { type: 'Native', address: PublicKey [PublicKey(2qjSAGrpT2eTb673KuGAR5s6AJfQ1X5Sg177Qzuqt7yB)] { _bn: BN: 1b578bb9b7a04a1aab3b5b64b550d8fc4f73ab343c9cf8532d2976b77ec4a8ca } } 🚀 Token attestation complete!\nView complete script\nattest.ts\nimport {\nwormhole ,\nWormhole ,\nTokenId ,\nTokenAddress ,\n} from '@wormhole-foundation/sdk' ;\nimport { signSendWait , toNative } from '@wormhole-foundation/sdk-connect' ;\nimport evm from '@wormhole-foundation/sdk/evm' ;\nimport solana from '@wormhole-foundation/sdk/solana' ;\nimport { getSigner } from './helper' ;\nasync function attestToken () {\n// Initialize wormhole instance, define the network, platforms, and chains\nconst wh = await wormhole ( 'Testnet' , [ evm , solana ]);\nconst sourceChain = wh . getChain ( 'Moonbeam' );\nconst destinationChain = wh . getChain ( 'Solana' );\n// Define the token to check for a wrapped version\nconst tokenId : TokenId = Wormhole . tokenId (\nsourceChain . chain ,\n'INSERT_TOKEN_CONTRACT_ADDRESS'\n);\n// Check if the token is registered with the destination chain WTT (Token Bridge) contract\n// Registered = returns the wrapped token ID\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 ) {\n// Attestation on the source chain flow code\nconsole . log (\n'⚠️ Token is NOT registered on destination. Running attestation flow...'\n);\n// Retrieve the WTT (Token Bridge) contract text for the source chain\nconst tb = await sourceChain . getTokenBridge ();\n// Get the signer for the source chain\nconst sourceSigner = await getSigner ( sourceChain );\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// Create a new attestation 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);\n// Attestation on the destination chain flow code\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) contract text for the destination chain\n// and submit the attestation VAA\nconst destTb = await destinationChain . getTokenBridge ();\n// Get the signer for the destination chain\nconst destinationSigner = await getSigner ( destinationChain );\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\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 (\ndestinationChain . chain ,\ntokenId\n);\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 (\n`🚀 Token attestation complete! Token registered with ${ destinationChain . chain } .`\n);\n}\nattestToken (). catch (( e ) => {\nconsole . error ( '❌ Error in attestToken' , e );\nprocess . exit ( 1 );\n});\nCongratulations! You've successfully created and submitted an attestation to register a token for transfer via WTT.\nNext Steps ＃\n-\nTransfer Wrapped Assets\nFollow this guide to incorporate token attestation and registration into an end-to-end WTT flow.\nGet Started\nLast update: September 28, 2026\n| Created: September 28, 2026"}
{"url":"https://bitcoin.org/bg/you-need-to-know","domain":"bitcoin.org","title":"Някои неща, които трябва да знаете - Биткойн","hash":"d8f26f0095ae13731c6a896908c2d07ad810ad25d98b7d440dcca37989214bfc","tokens":1757,"chars":7025,"crawler":"crawler-f6nn","verified":"exact","ts":1791172187482,"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- Въведение\n- Частни лица\n- Фирми\n- Разработчици\n- Първи стъпки\n- Как работи\n- Трябва да знаете\n- Ресурси\n- Exchanges\n- Общност\n- BIPs list\n- Речник\n- Bitcoin Core\n- Иновация\n- Участвайте\n- Допринесете към Биткойн\n- Buy Bitcoin\n- Sell Bitcoin\n- Развитие\n- ЧЗВ\n- български\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: bg\nНякои неща, които трябва да знаете\nАко сте решили да разучавате Биткойн, има няколко неща, които трябва да знаете. Биткойн ви дава възможност да обменяте пари по различен начин, в сравнение с обичайните банки. По този повод трябва да отделите време, за да се информирате преди да използвате Биткойн за всяка сериозна транзакция. Усилията, които полагате, за да се грижите за Биткойн трябва да са същите, както за парите в портфейла ви, а в някои случаи и по-големи!\nЗащитете портфейла си\nКакто и в реалния живот, вашият портфейл трябва да бъде на сигурно място. Биткойн дава възможност за прехвърляне на средства навсякъде и по много лесен начин, като същевременно ви позволява да контролирате парите си. Такива възможности обикновено идват и с големи опасения за сигурността. В същото време, Биткойн може да осигури много високи нива на сигурност, ако се използва правилно. Винаги помнете, че да се приемат добрите практики е ваша отговорност, която ще ви помогне да защитите парите си. Прочетете повече за сигурността на портфейла си .\nThere is no undo button\nBitcoin has no central authority to reverse a mistake. If you permanently lose access to your wallet—for example by losing your recovery phrase—your funds are gone permanently. No one—not developers, miners, wallet providers, or exchanges—can recover funds that you permanently lose from a self-custodied wallet. Always back up your wallet and keep your recovery information safe and private.\nYou are your own bank\nWhen you hold your own private keys, you control your bitcoin—but you are also responsible for keeping it secure. If you leave your coins with an exchange or another custodian, you rely on that third party to safeguard them and to honor withdrawals. That reliance introduces counterparty risk: the custodian's own security, solvency, and policies now stand between you and your funds. Holding your own keys removes that risk, but requires you to secure your wallet and backups yourself.\nБиткойн не е анонимен\nИзисква се известно усилие, за да защитите личните си данни в Биткойн. Всички транзакции са публични и се запазват в мрежата на Биткойн. Това означава, че всеки може да види баланса и транзакциите, извършени от всеки Биткойн адрес. Идентичността на потребителя зад адреса остава неизвестна, докато не се разкрие информация по време на покупка или в други условия. Ето я една от причините защо Биткойн адресите се използват само веднъж. Винаги помнете, че е ваша отговорност да придобиете добри навици за опазване на личните си данни. Прочетете повече за защитата на личните данни .\nБиткойн плащнията са необратими\nВсяка транзакция, издадена с Биткойн, не може да бъде отменена и средствата могат да бъдат възстановени, единствено със съгласието на получателя. Това означава, че вие трябва да се стараете да правите бизнес с хора и организации, които познавате, имате им доверие или те имат установена добра репутация. От своя страна, фирмите трябва да контролират исканията за плащания на своите клиенти. Биткойн може да открие правописни грешки и обикновено няма да ви позволи да изпратите пари на невалиден адрес по погрешка. Допълнителни услуги могат да бъдат въведени в бъдеще, за да се осигури по-голям избор и защита на потребителя.\nМоменталните транзакции са по-малко сигурни\nТранзакцията в Биткойн се изпраща в рамките на няколко секунди, но започва да се потвърждава в рамките на следващите 10 минути. През това време тя може да се счита за автентична, но все още обратима. Непочтени потребители могат да се опитат да извършат измама. Ако не може да изчакате за потвърждение, заплащането на малка такса за транзакцията или използването на система за откриване на опасни операции могат да увеличат сигурността. За по-големи суми като $1000 е логично да се чака около шест или дори повече потвърждения. Всяко потвърждение експоненциално намалява риска от обратна транзакция.\nЦената на Биткойн е нестабилна\nЦената на биткойн може непредсказуемо да се увеличи или намалее за кратък период от време, поради скорошното си начало, новаторският си характер, а понякога и от неликвидни пазари. Следователно, държането на вашите спестявания в Биткойн, не се препоръчва в този момент. Биткойн трябва да се разглежда като актив с висок риск и никога не трябва да съхранявате пари, които не може да си позволите да загубите с Биткойн. Ако получавате плащания с Биткойн, много доставчици на услуги могат да ги обменят във вашата местна валута.\nБиткойн все още е в експериментален период\nБиткойн е нова експериментална валута, която активно се развива. Въпреки, че тя непрекъснато се подобрява и популяризира трябва да имате предвид, че Биткойн е ново изобретение, което проучва идеи, които никога не са били използвани в миналото и никой не може да прогнозира бъдещето му.\nПравителствени данъци и регулации\nБиткойн не е официална валута. Повечето юрисдикции все още изискват от вас да платите данъци върху доходите, продажбите, заплатите и капиталовите печалби на всичко, което има стойност, включително биткойни. Ваша е отговорността да се гарантира, че се придържате към данъчните и други законови или подзаконови разпоредби издадени от вашето правителство и/или местните общини.\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nВъведение:\n-\nЧастни лица\n-\nФирми\n-\nРазработчици\n-\nПърви стъпки\n-\nКак работи\n-\nТрябва да знаете\nРесурси:\n-\nРесурси\n-\nExchanges\n-\nОбщност\n-\nBIPs list\n-\nРечник\n-\nBitcoin Core\nУчаствайте:\n-\nДопринесете към Биткойн\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nРазвитие\nOther:\nПравни\nPrivacy Policy\nПреса\nОтносно bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 разпространен под лиценза на Масачузетския технологичен институт\nNetwork Status\n- български\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- 繁體中文\nbg"}
{"url":"https://gov.optimism.io/t/exploring-execution-time-authorization-for-superchain-applications/10882","domain":"gov.optimism.io","title":"Exploring execution-time authorization for Superchain applications - ✨ General - Optimism Collective","hash":"d47bca238a88ed401ddd2096fa59bb2c2609873b8c411a33962bc70be16ef1f3","tokens":5268,"chars":21070,"crawler":"crawler-f6nn","verified":"exact","ts":1791172190342,"text":"Optimism Collective\nExploring execution-time authorization for Superchain applications\n✨ General\nGomez\nSeptember 24, 2026, 7:31am\n1\nI’d like to get feedback from Optimism builders and the broader Superchain community on a potential infrastructure primitive for applications, payment flows, smart accounts and autonomous transaction systems.\nThe problem\nAuthorization can happen upstream of execution. Between that authorization decision and the point where an action is actually released, the executable payload can potentially become stale, altered, replayed, or otherwise no longer correspond to what was originally authorized.\nA2SPA addresses that specific boundary.\nIt is an execution-time authorization layer that cryptographically binds the exact executable payload and relevant constraints — such as destination, amount, parameters, permissions and freshness/nonce — to a signed authorization artifact.\nImmediately before execution, the actual payload is verified against that authorization.\nIf the action reaching execution is not the action that was authorized, verification fails.\nIn simplified terms:\nAuthorize → bind exact payload + constraints → sign → verify at execution → release only if it matches.\nA2SPA is not intended to replace wallets, account abstraction, policy engines, fraud controls, transaction simulation or existing security mechanisms. It provides a different assurance boundary: cryptographic evidence that the action authorized upstream is the same action that reaches execution.\nI’m interested in whether this has a meaningful place within the Superchain ecosystem — whether at the application layer, middleware, an OP Stack integration point, or elsewhere in the transaction lifecycle.\nWould builders/delegates see value in exploring this as an open technical integration, and if so, where would the most appropriate integration boundary be?\nI can share a short technical flow and interoperability sketch if there is interest.\n1 Like\nMconnectDAO\nSeptember 24, 2026, 7:45pm\n2\nThe idea is directionally useful, but execution time authorization appears much harder than the post suggests. Matching an approved payload with executed calldata can protect integrity, yet it does not guarantee that the action remains safe or economically correct under changed onchain state.\nFor example, a swap can execute with the exact approved calldata while price, liquidity, oracle conditions, transaction ordering or proxy implementation have changed. In cross chain flows, delay, message ordering, replay and destination state add further complexity.\nIt would be useful to clarify the threat model, trust assumptions, verification layer, handling of dynamic state, revocation, upgrades, partial execution, replay protection, gas overhead and cross chain semantics. Without these details, this looks more like a promising authorization primitive than a complete execution security solution. @Gomez\nMconnectDAO\nSeptember 24, 2026, 7:46pm\n3\nOP should not treat this as a protocol level security solution before an application layer prototype proves a unique gap. The proposal should first define a precise threat model and demonstrate why smart account modules, session keys, multisig policy controls and existing intent constraints cannot achieve the same protection. If the value is validated, an optional Superchain compatible standard or SDK may be more suitable than mandatory OP Stack enforcement.\n@Gomez\nGomez\nSeptember 24, 2026, 10:45pm\n4\nThanks, this is exactly the kind of technical distinction I was hoping to surface.\nI agree that payload integrity alone should not be presented as execution safety or economic correctness . A2SPA’s intended scope is narrower: proving that the specific executable action reaching the execution boundary is the action that was authorized, under the constraints defined by the authorization.\nYour swap example is a useful illustration. If calldata remains identical while price, liquidity or other relevant state changes, A2SPA should not claim that the transaction is therefore economically correct. Those conditions need to be represented as explicit execution constraints or handled by the surrounding application/policy layer.\nI also agree that the next step should be application-layer validation rather than proposing an OP Stack-level security mechanism.\nIn particular, I’ll work through:\n- a precise threat model and trust assumptions;\n- replay, nonce, freshness and revocation semantics;\n- dynamic-state and constraint handling;\n- upgrade/proxy and partial-execution cases;\n- cross-chain/domain binding and message ordering;\n- verification location and bypass resistance;\n- gas/latency considerations; and\n- a direct comparison with smart-account modules, session keys, multisig policies and intent constraints.\nThe key question I want to test is therefore narrower:\nIs there a distinct execution-integrity gap that remains when those mechanisms authorize or constrain an action, but the actual executable payload is produced, delegated, delayed, transformed or handed off before the final execution boundary?\nIf that gap can be demonstrated with an application-level prototype, I agree that an optional Superchain-compatible SDK/standard would be a more appropriate direction than mandatory OP Stack enforcement.\nI’ll put together the threat model and a concrete application-level flow so the distinction can be evaluated technically rather than as a product claim.\n1 Like\nGomez\nSeptember 24, 2026, 10:52pm\n5\nA2SPA — Execution-Time Authorization\nThreat Model & Superchain Interoperability Note\nIndependent technical working note • Optimism / Superchain context • September 2026\nPurpose\nThis note responds to technical feedback on whether A2SPA can provide a distinct execution-integrity primitive for Superchain applications. It deliberately narrows the claim: A2SPA is not presented as a complete transaction-security, economic-correctness, or OP Stack protocol-security solution.\nCore claim under test: when an application authorizes a specific executable action upstream of execution, can a verifier establish immediately before release that the exact action reaching the execution boundary is the action that was authorized, subject to explicit constraints, freshness, domain and policy conditions?\nThe recommended next step is validation through an application-layer prototype and adversarial testing before any consideration of an optional Superchain-compatible SDK or standard.\n1. Scope and Non-Goals\nA2SPA is an execution-time authorization model for structured execution requests. The current independent technical working draft describes deterministic cryptographic validation at the execution boundary. Its stated scope excludes natural-language prompt validation, model alignment, semantic correctness, business correctness, legality and desirability of an upstream decision.\nIn scope\n- Binding a concrete executable payload to an authorization artifact.\n- Authenticating the authorization source under the deployment’s defined trust model.\n- Binding relevant target, parameters, constraints, domain, nonce and freshness data.\n- Detecting unauthorized payload mutation, stale authorization and replay where the corresponding controls are implemented and enforced.\n- Fail-closed verification at the designated release/execution boundary when required conditions are not met.\nNot claimed\n- A guarantee that an authorized transaction is economically beneficial or semantically correct.\n- Protection against every compromised signer, malicious contract, oracle failure, chain reorganization or adverse market movement.\n- A replacement for smart accounts, session keys, multisig, intent systems, simulation, fraud detection, wallet controls or application policy.\n- Mandatory changes to the OP Stack or Superchain protocol.\n2. Threat Model\nThe relevant adversary is assumed capable of influencing or modifying an execution request after an upstream authorization decision, or replaying a previously authorized request, without possessing the cryptographic authority required to create a valid new authorization. The exact trust boundary must be specified by each deployment.\nThreat / failure mode\nA2SPA control to test\nResidual limitation / responsibility\nPayload mutation\nCanonical representation + signed payload binding; mismatch → reject\nOnly protects fields actually included in the signed/bound representation.\nWrong target / function\nBind destination, function and domain data\nDoes not make the target contract trustworthy.\nWrong amount / parameters\nBind relevant parameters and explicit limits\nEconomic suitability still depends on policy/state conditions.\nReplay\nNonce, freshness/expiry and domain binding\nNonce lifecycle and state management remain deployment responsibilities.\nStale authorization\nExpiry/freshness constraints\nPolicy must define what “fresh enough” means.\nCross-domain replay\nChain/domain/destination binding\nCross-chain systems add ordering, delay and destination-state assumptions.\nRevocation\nExplicit revocation/status mechanism where required\nRevocation authority and availability must be defined.\nUpgradeable implementation\nOptional implementation/version/policy binding\nDoes not independently establish that an upgrade is safe.\nPartial execution\nExplicit atomicity/completion semantics\nA2SPA cannot infer business-level completion.\nDynamic state\nExplicit state-dependent constraints evaluated by the relevant layer\nA2SPA does not itself determine market/business correctness.\nVerifier bypass\nVerifier must be on the enforced release path\nIf execution bypasses the verifier, its guarantee does not apply.\nIssuer compromise\nSignature proves authorization, not honesty of issuer\nKey management and policy authority remain external assumptions.\n3. Dynamic-State Boundary\nThe key distinction is between authorization integrity and state-dependent correctness. A transaction can reproduce the exact authorized calldata while external state has changed. A2SPA should therefore not equate an exact payload match with economic safety.\nFor state-sensitive actions such as swaps, an application can define explicit constraints where appropriate—for example minimum received amount, maximum spend, deadline, permitted venue, asset pair, oracle bound or another deterministic condition. The responsible policy/execution layer must evaluate those conditions against relevant state. A2SPA can bind the resulting authorization and enforce the execution-time match, but should not claim to independently judge economic correctness.\nExample: if an authorized swap specifies “sell no more than X and receive at least Y before deadline T on the specified venue,” an execution request violating those explicit constraints should not satisfy the authorization. If no price/slippage condition was authorized, A2SPA cannot infer one.\n4. Trust Assumptions\nA credible implementation needs a defined authorization issuer, key-management model, canonicalization/signing profile, nonce/freshness source, verifier, enforcement point and executor. Cross-chain deployments additionally require explicit assumptions about source/destination domains, message authenticity, ordering/finality and replay domains.\nThe security property is conditional: if the verifier is bypassable, the authorization authority is compromised, or the signed representation omits security-relevant execution fields, the intended guarantee does not hold.\n5. Verification Layer and Bypass Resistance\nThe prototype should test both (a) application/middleware verification immediately before release and (b) smart-account/module enforcement where the account itself rejects execution that fails authorization verification.\nThe critical requirement is not merely that a verifier exists; it must be on an enforcement path the executor cannot silently bypass. The prototype should enumerate every execution path and identify which are covered.\n6. Revocation, Expiry, Nonces and Replay\nEach authorization needs an explicit validity model: unique nonce or equivalent replay identifier, expiry/freshness condition, domain identifier, and lifecycle of consumed/invalidated authorizations. Revocation should specify its source and behavior when that source is unavailable.\nCross-chain deployments must prevent an authorization valid for one domain from being accepted unintentionally on another. Domain separation should cover the relevant chain/application/executor context according to actual protocol semantics.\n7. Upgrades and Partial Execution\nUpgradeable contracts create a separate trust problem. If an authorization assumes a particular implementation, the application may bind an implementation identifier, version, policy hash or other explicit condition. This does not establish that the implementation is safe; it prevents silent substitution from being treated as the same authorized execution when the deployment chooses to make implementation identity part of authorization.\nFor multi-step workflows, authorization must define whether it covers one atomic transaction, an ordered set of steps, or separately authorized actions. A2SPA should not infer business-level completion from a partial receipt.\n8. Comparison with Existing Controls\nThe objective is complementarity, not replacement. This comparison identifies the boundary to test; it does not claim that existing mechanisms are insufficient in every deployment.\nMechanism\nPrimary capability\nQuestion A2SPA tests in addition\nSmart-account modules\nProgrammable account-level authorization/policy\nCan the concrete payload released after policy authorization be bound to and re-verified against the authorization artifact?\nSession keys\nDelegated authority with scope/time/policy\nCan a specific delegated execution be bound to an exact payload and freshness/domain context?\nMultisig\nMultiple-party approval\nCan the exact action approved by signers be distinguished from a later/transformed execution request?\nIntent constraints\nDesired outcomes / execution conditions\nCan the concrete execution request be bound to the authorized conditions without conflating integrity with economic correctness?\nSimulation / pre-flight\nEstimate or validate likely outcome before submission\nDoes the final released action remain bound to what was authorized after intermediate processing?\nFraud / monitoring\nDetect suspicious behavior\nCan a deterministic cryptographic authorization check occur at the execution boundary?\n9. Proposed Application-Layer Prototype\nBefore proposing OP Stack-level integration, the recommended experiment is a narrow, reproducible application-layer prototype with an adversarial test suite.\nPrototype flow\n- Application/policy layer defines an executable action and explicit constraints.\n- Canonicalizer produces a deterministic representation of security-relevant fields.\n- Authorization artifact binds payload hash, target/domain, nonce/freshness and selected constraints; issuer signs it.\n- Executor receives the executable action and authorization artifact.\n- Verifier recomputes the representation and checks signature, domain, nonce/freshness and constraints.\n- Only successful verification may release execution.\n- Adversarial tests mutate payload fields, replay artifacts, alter domain/chain identifiers, change deadlines/limits, modify intermediary outputs and attempt verifier bypass.\n- State-sensitive tests separately demonstrate the difference between exact-payload integrity and explicit dynamic-state constraints.\nInitial test cases\n- ERC-20 transfer: mutate recipient and amount after authorization.\n- Contract call: mutate target/function/arguments.\n- Swap-like action: preserve calldata while changing market state; demonstrate that payload matching alone does not assert economic correctness.\n- Replay: submit the same authorization twice.\n- Stale execution: execute after expiry.\n- Cross-domain replay: submit valid authorization under a different chain/domain context.\n- Delegated workflow: modify the action after an agent/intermediary produces the final request.\n- Verifier bypass: attempt an alternate path that does not invoke the required verifier.\n- Upgradeable target: change implementation identity where the application has chosen to bind it.\n10. Validation Metrics\nThe prototype should measure technical properties rather than claim ecosystem-wide security impact.\n- Verification correctness: authorized requests accepted; modified/invalid requests rejected.\n- Replay resistance under the defined nonce/domain model.\n- Bypass coverage across known execution paths.\n- Constraint correctness for explicit limits.\n- Additional gas and latency on representative flows.\n- Deterministic failure behavior and fail-closed enforcement where required.\n- Developer integration cost and interface complexity.\n11. Potential Superchain Integration — Only If Validated\nIf the prototype demonstrates a distinct gap not adequately covered by existing account, session-key, multisig, intent or policy mechanisms, the least invasive Superchain path should be evaluated first.\n- Optional SDK/reference implementation for Superchain applications.\n- Standardized authorization-artifact format or interoperability profile.\n- Smart-account/module adapters where applications choose execution enforcement.\n- Application/middleware adapters for transaction or intent pipelines.\n- Only later, if there is demonstrated ecosystem-wide value and a clearly defined protocol requirement, consider deeper OP Stack integration.\nNo mandatory OP Stack enforcement is proposed at this stage.\n12. Open Technical Questions\n- What exact execution boundary is authoritative for a Superchain application?\n- Which existing smart-account, session-key, multisig or intent mechanisms already provide the proposed property, and where do they stop?\n- Which fields must be canonicalized and bound for representative transaction types?\n- Which dynamic-state conditions belong in the authorization artifact versus the application/policy layer?\n- What is the appropriate revocation and freshness model for delayed and cross-chain execution?\n- What cross-chain semantics must be bound to prevent unintended replay or message substitution?\n- What verifier placement provides meaningful bypass resistance without protocol-level changes?\n- What gas and latency overhead is acceptable?\n- Which parts, if any, merit standardization rather than remaining application-specific?\n13. Current Status\nA2SPA currently exists as an independent technical working draft rather than an adopted standard, IETF document, certification or security audit. The public repository identifies specification v0.9.2 and explicitly requests external review of security assumptions, canonicalization, replay/nonce/timestamp handling, deployment/bypass risks, conformance and implementation edge cases.\nThis note is therefore a technical-validation document, not a claim that the protocol has already established these security properties in production.\n14. Recommended Next Step\nBuild and test the application-layer prototype, publish the adversarial test results, and document the comparison against existing authorization mechanisms. Only after that evidence exists should a Superchain proposal be considered. If the gap is validated, an optional SDK, interoperability profile or application integration is the more proportionate first target than mandatory OP Stack enforcement.\nThe resulting proposal should define scope, deliverables, security review, maintenance responsibility, adoption targets and measurable success criteria.\nAppendix — Positioning in One Sentence\nA2SPA does not determine whether an action is safe or economically correct; it is intended to provide cryptographic evidence, at the execution boundary, that the concrete action being released is the action that was authorized under the defined authorization constraints.\nThis distinction is the central hypothesis to validate with the Optimism/Superchain community.\nSources consulted\n- Optimism Collective: “Exploring execution-time authorization for Superchain applications” (September 24, 2026).\n- Optimism Collective: “Grant Application: superchain-guard” and associated governance review (May 2026).\n- Optimism Collective: “Superchain accounts: Mission updates” (2024–2025).\n- AI Blockchain Ventures: A2SPA Core Protocol, independent technical working draft v0.9.2.\nClaims are intentionally scoped; this document does not imply Optimism endorsement.\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nGrant Application: superchain-guard\nGrants Updates\nseason-8\n,\nseason-9\n6\n213\nMay 19, 2026\n[FINAL] Superchain Governance Deep Dive\nARCHIVED & OLD Missions\nseason-4\n37\n6412\nOctober 4, 2023\nSeason 5 Cycle 19 Intent 1 Developer Advisory Board finalists review\nGrants Updates\nseason-5\n,\ncycle-19\n2\n858\nApril 5, 2024\n[CLOSED] Governance Fund Mission Request: Cross-Chain Key Management for Safe\nGovernance Fund Missions\nseason-8\n11\n520\nNovember 27, 2025\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"}
{"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":"b2fd93a5b848985372b78942202bac62e5e01f850f61b89c2fa0d10f7849bbdd","tokens":6313,"chars":25252,"crawler":"crawler-f6nn","verified":"exact","ts":1791172193211,"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\n7453\nMarch 14, 2025\nProposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta\nGovernance\nfeature\n,\ncore\n76\n12929\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\n3581\nMarch 14, 2025\nProposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet\nGovernance\nfeature\n,\ncore\n25\n5616\nOctober 4, 2025\nDiscourse Footer"}
{"url":"https://aave.com/docs/aave-v3/overview","domain":"aave.com","title":"Aave V3 Overview | Aave Protocol Documentation","hash":"be34e19aa1cb40b5774b50bbea14f4007caaca67b65281b1cc10cf00514c0360","tokens":1264,"chars":5055,"crawler":"crawler-f6nn","verified":"exact","ts":1791172195857,"text":"Docs\nAave v3 # Copy\nAave v3 is a non-custodial liquidity protocol on Ethereum and other major networks. It provides onchain infrastructure to integrate supply and borrow into applications via battle-tested smart contracts and AaveKit.\nDevelopers can use AaveKit React , AaveKit TypeScript , or AaveKit API to integrate core protocol operations and data for wallets, exchanges, fintech platforms, and DeFi-native products.\nSupply # Copy\nSupplying assets to Aave lets users earn interest and, optionally, use supplied tokens as collateral for borrowing. When an asset is supplied, aTokens (e.g., aUSDC, aWETH) are minted as interest-bearing ERC-20 tokens whose balance increases over time from borrowing activity in the pool.\nWithdrawing redeems aTokens for the underlying asset, including accrued interest, subject to available unborrowed liquidity and the collateralization of any active borrow positions.\nBorrow # Copy\nBorrowing lets users access liquidity by posting supplied assets as collateral. Positions are always over-collateralized, meaning the collateral value must exceed the borrowed amount. Risk is tracked with a Health Factor and per-reserve liquidation thresholds; when the Health Factor drops below the threshold, collateral can be liquidated. When a user borrows, their debt is represented by variableDebtTokens (e.g., variableDebtUSDC), ERC-20 tokens that track the outstanding borrow balance and accrue interest over time.\nBorrowers can repay at any time, and positions remain open as long as over-collateralization is maintained. The Health Factor moves with collateral and debt values (prices from oracles and accrued interest). When it falls below 1, the position becomes eligible for liquidation and external liquidators can repay part of the debt in exchange for collateral.\nInterest Rates # Copy\nInterest rates adjust with utilization. v3 uses an interest rate model based on two slopes with an optimal utilization point: below the optimal point, borrow rates rise with the first slope; above it, they rise faster with the second slope.\nSupplier yields are funded by borrower interest net of the reserve factor.\nLiquidations # Copy\nPositions become eligible for liquidation when a position's Health Factor falls below 1. A liquidator repays part of the debt and receives collateral at a discount (liquidation bonus). Liquidation threshold and bonus are defined per reserve and surfaced via onchain views.\nAave Earn Vaults # Copy\nAave Earn Vaults are ERC-4626 compliant yield-bearing vaults that enable Aave supply positions to be managed with customizable ownership and fee structure. By depositing supported tokens, users receive vault shares that represent their proportional claim on the underlying assets and any yield earned. Shares can be withdrawn at any time for the underlying assets plus accrued yield subject to available liquidity, providing a simple and efficient way to grow holdings.\nFor vault managers, Aave Earn Vaults offer a customizable framework to deploy and manage yield strategies while earning fees on the yield generated by user deposits. The standardized ERC-4626 interface provides compatibility with a wide range of DeFi protocols and applications, making it easy to integrate vaults into broader strategies or platforms. This structure benefits both users seeking passive income and managers looking to build scalable, revenue-generating products on Aave. See the Vaults Overview for guides to deploy and manage instances of Aave Earn Vaults.\nAave v3 Key Features # Copy\nAave v3 introduces significant enhancements over previous protocol iterations, focusing on improving capital efficiency, mitigating risk, and establishing Aave as a leading liquidity protocol across 14+ blockchain networks.\nEfficiency Mode (E-Mode) # Copy\nEfficiency Mode maximizes capital efficiency for correlated assets. When a user supplies and borrows assets within the same E-Mode category (e.g., USD-pegged stablecoins), they benefit from a higher loan-to-value (LTV) ratio. This enables low-slippage, high-leverage strategies like yield farming with staked ETH derivatives or efficient forex trading.\nIsolation Mode # Copy\nIsolation Mode allows for the secure listing of new or more volatile assets without introducing systemic risk to the entire protocol. When an asset is listed in Isolation Mode, it can be used as collateral to borrow only a specific basket of assets (typically stablecoins), up to a designated debt ceiling. This contains risk while expanding the number of supported assets.\nView debt ceiling and borrowable in isolation mode parameters on the\nparameter dashboard .\nSiloed Borrowing # Copy\nSiloed borrowing is a reserve-level flag that restricts users who borrow a given asset to borrowing only that asset, preventing them from having any other active borrows in the same pool.\nView debt ceiling and siloed assets parameters on the parameter\ndashboard .\nNext Steps # Copy\n-\nLearn how to interact with Aave Markets .\n-\nLearn how to interact with Aave Earn Vaults .\nPrevious\nReact Hooks\nNext\nConcepts"}
{"url":"https://docs.ens.domains/ensv2/permissioned-registry","domain":"docs.ens.domains","title":"Permissioned Registry | ENS Docs","hash":"19c744d46d61a5cefa417a544a1fe4f42cdc9d147d34f61ad5a162e5dc120dd8","tokens":5599,"chars":22393,"crawler":"crawler-f6nn","verified":"exact","ts":1791172198382,"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\nPermissioned Registry\nThe Permissioned Registry is the tokenized registry at the heart of ENSv2 name management. Each registered name becomes an ERC1155Singleton token with exactly one owner, and all permissions are managed through Enhanced Access Control .\nWhat Changed from ENSv1\nIn ENSv1, name management was split across three separate contracts: the ENS Registry (flat mapping of all names), the BaseRegistrar (ERC721 tokens for .eth), and the Name Wrapper (ERC1155 wrapping + fuses). ENSv2 replaces all three with a single unified contract. The table below summarizes the key differences; each concept is explained in the sections that follow.\nFeature ENSv1 ENSv2 Permissioned Registry\nArchitecture Single flat registry for all names Hierarchical : each name can have its own registry\nToken standard ERC721 (BaseRegistrar) or ERC1155 (Name Wrapper) ERC1155Singleton with single ownership\nPermissions One-way fuse burning (Name Wrapper) Reversible role-based EAC\nToken IDs Fixed (derived from namehash/labelhash) Mutable : change on role updates and re-registration\nSubname control Requires Name Wrapper + fuse configuration Built-in via subregistry pointer + per-name roles\nUpgradeability Not upgradeable UUPS proxy pattern (for UserRegistry )\nName states Registered or not Three-state lifecycle (see Name Lifecycle )\nNames\nEach name in the registry is identified by its labelhash (the keccak256 hash of the label string). The on-chain data for a name is stored in an Entry struct:\nField Type Purpose\neacVersionId uint32 Isolates permissions across registrations (see Mutable Token IDs )\ntokenVersionId uint32 Invalidates marketplace approvals on role changes (see Mutable Token IDs )\nsubregistry IRegistry Pointer to a subregistry for managing subnames\nexpiry uint64 Timestamp after which the name is considered expired ( block.timestamp >= expiry )\nresolver address Resolver contract that holds this name's records\nEntries are stored in a mapping keyed by the canonical ID , the labelhash with its lower 32 bits zeroed.\nName Lifecycle\nNames exist in one of three states:\n- AVAILABLE : never registered or expired. Open for registration.\n- RESERVED : placeholder with no owner and no token. Useful for pre-allocating names before assigning them.\n- REGISTERED : has an owner, a token, and active permissions.\nState transitions: each transition requires a specific EAC role with the indicated scope.\nFrom To Required role Scope\nAVAILABLE REGISTERED ROLE_REGISTRAR root\nAVAILABLE RESERVED ROLE_REGISTRAR root\nAVAILABLE (expired) REGISTERED / RESERVED ROLE_RENEW root\nRESERVED REGISTERED ROLE_REGISTER_RESERVED root\nREGISTERED / RESERVED AVAILABLE ROLE_UNREGISTER root or name\nRegistration\nregister() accepts a label (string), owner , registry (subregistry), resolver , roleBitmap (initial roles granted to the owner), and expiry . Labels are validated for size before registration. If owner is address(0) , the name is reserved instead of registered, and roleBitmap must be 0 .\n- A non-expired registered name cannot be re-registered; it must be unregistered first.\n- A reserved name cannot be re-reserved; it can only be promoted to registered.\n- When promoting a RESERVED name to REGISTERED , if expiry is 0 the current expiry is preserved.\n- Re-registering an expired name that had a previous owner burns the old token and increments both version counters. This ensures stale permissions and token approvals don't carry over.\nUnregistration\nunregister() sets the name's expiry to block.timestamp , making it immediately available. If the name was REGISTERED (has an owner), the token is burned and both version counters are incremented.\nRenewal\nrenew() extends a name's expiry but cannot reduce it. Both REGISTERED and RESERVED names can be renewed. An expired name can also be revived by calling renew() on it, restoring it with its previous owner, token, and roles; re-registering the expired name instead starts fresh, with a new token and whatever owner and roles the new registration assigns. Reviving requires ROLE_RENEW on ROOT_RESOURCE ; a name-scoped ROLE_RENEW grant works only while the name is unexpired. Names that were never registered cannot be renewed.\nanyId Polymorphism\nMost functions accept an anyId parameter that can be a labelhash , token ID , or resource interchangeably. Internally, _entry() zeroes the version bits to find the canonical storage slot for the name. This means you can pass whichever identifier you have on hand, and the registry resolves it to the same underlying entry.\nSee Mutable Token IDs for the full explanation and diagram.\nOwnership\nThe token ID for a name changes when it is re-registered or when roles change (see Mutable Token IDs ).\nownerOf() returns address(0) for:\n- Expired names (ownership is time-bounded)\n- Stale token IDs (after versioning changes, old token IDs are no longer valid)\nlatestOwnerOf() returns the recorded owner of a token even after the name has expired. Burned token IDs, including stale IDs from earlier versions, return the zero address.\nEAC Integration\nAll permissions are managed through Enhanced Access Control .\nRoles\nRole Value Scope Purpose\nROLE_REGISTRAR 1 << 0 root Register or reserve names\nROLE_REGISTER_RESERVED 1 << 4 root Promote reserved names to registered\nROLE_SET_PARENT 1 << 8 root Set parent registry\nROLE_UNREGISTER 1 << 12 root or name Unregister names\nROLE_RENEW 1 << 16 root or name Extend expiry\nROLE_SET_SUBREGISTRY 1 << 20 root or name Set subregistry\nROLE_SET_RESOLVER 1 << 24 root or name Set resolver\nROLE_CAN_TRANSFER_ADMIN (1 << 28) << 128 root or name Authorize ERC1155 token transfers\nROLE_SET_URI 1 << 36 root Set metadata URI and renderer\nROLE_UPGRADE 1 << 124 root Authorize proxy upgrades\nEach role has a corresponding admin role at role << 128 (e.g., ROLE_SET_RESOLVER_ADMIN = (1 << 24) << 128 ), except ROLE_CAN_TRANSFER_ADMIN which exists only as an admin role. In TypeScript, use 1n << 24n for the bigint equivalent.\nROLE_CAN_TRANSFER_ADMIN has no regular (non-admin) variant and is checked against the token owner, not the operator. See Transfers for details.\n\"Root\" scope means the role only works on ROOT_RESOURCE . \"Root or name\" means it can be granted on either scope, and the two compose: a root grant applies to all names.\nAdmin roles on individual names are restricted to registration time (see EAC Hook Overrides ).\nRole Bitmap Composer\nRegular roles\nAdmin roles\nGranting and Revoking Roles\nThe registry uses the standard EAC grantRoles and revokeRoles functions with anyId polymorphism . See Code Examples for usage.\nEAC Hook Overrides\nThe Permissioned Registry overrides several EAC callback hooks to enforce registry-specific invariants:\nToken regeneration on role changes : when roles are granted or revoked via grantRoles() / revokeRoles() , the _onRolesGranted and _onRolesRevoked hooks trigger a token regeneration (burn + mint with a new token ID). This invalidates any pending ERC1155 transfer approvals tied to the old token ID, preventing an attacker from racing to transfer a token after their roles have been revoked.\nAdmin role restriction on names : _getSettableRoles is overridden so that admin roles on individual names can only be assigned at registration time. After registration, only regular (non-admin) roles can be granted on a name, but admin roles can still be revoked (including by the holder revoking their own). On ROOT_RESOURCE , admin roles work normally. This prevents a name owner from escalating their own permissions after registration.\nResource Scheme\nThe registry derives each EAC resource from the name's labelhash and its current eacVersionId , so permissions are scoped per-name and automatically invalidated on re-registration:\n255 32 31 0\n┌──────────────────────────────────────┬─────────────────┐\n│ labelhash upper bits │ eacVersionId │\n│ (224 bits) │ (32 bits) │\n└──────────────────────────────────────┴─────────────────┘\nRegistry resources participate in anyId polymorphism . See Mutable Token IDs for how resources, token IDs, and canonical IDs relate.\nTransfers\nTransferring a name's token requires ROLE_CAN_TRANSFER_ADMIN on the current owner of the token (the transfer reverts with TransferDisallowed otherwise). It does not matter who initiates the transfer, the role is always checked against the owner.\nWhen a token transfers, all roles are atomically moved from the old owner to the new owner: the old owner's roles are revoked first (freeing assignee slots), then granted to the new owner. Roles granted to other accounts on the same name are unaffected.\nsafeTransferFrom additionally protects the receiver in two situations:\n- The transfer reverts with TransferUnsafeUntilRegistryIsEmancipated if the registry is not emancipated , meaning an account with dangerous root roles could override the new owner.\n- The transfer reverts with TransferUnsafeWithMultipleAssignees if an account other than the owner holds roles on the token, meaning the name would arrive with third parties still in control of parts of it.\nTo transfer without these two checks, the registry implements unsafeTransfer and unsafeBatchTransfer .\nOperator Approval\nThe owner of a name can call setApprovalForAll(operator, true) to approve an operator. An approved operator inherits the owner's EAC roles on every name the owner holds, allowing them to perform any role-gated action (set resolver, set subregistry, transfer, etc.) on the owner's behalf. This is an all-or-nothing delegation: an approved operator can act on every name the owner holds, with the owner's full set of roles. There is no way to scope operator approval to specific names or roles.\nToken Metadata\nThe registry's uri(tokenId) function returns token metadata following the EIP-1155 standard. It supports two modes:\n- Static URI: a single string returned for all tokens. Clients substitute {id} with the hex token ID per the EIP-1155 metadata spec . Suitable when an off-chain service resolves per-token data from the URL template.\n- Dynamic renderer: an IRegistryURIRenderer contract that generates metadata per token. The registry calls renderURI(registry, tokenId) , passing itself so the renderer can query on-chain state (owner, expiry, records) to compose SVGs or JSON.\nThe renderer takes precedence: if set, the static URI is ignored. If neither is set, uri() returns an empty string.\nsetURI(uri_, renderer) sets both atomically and requires ROLE_SET_URI on ROOT_RESOURCE .\nBuilding a Custom Renderer\nImplement IRegistryURIRenderer :\ninterface IRegistryURIRenderer {\nfunction renderURI ( IRegistry registry , uint256 tokenId )\nexternal view returns ( string memory );\n}\nThe registry passes itself as the first argument, so the renderer can call getExpiry() , latestOwnerOf() , etc. to build metadata from on-chain state.\nParent Pointer\nEach name's subregistry field creates a forward pointer from parent to child. The registry also stores a backward pointer to its own parent via setParent() / getParent() , creating a two-way link at every level:\n.eth\nparent\n⇄\nnick.eth\nchild\n⇄\nsub.nick.eth\ngrandchild\nThe backward pointer records both the parent registry's address and the label this registry is known by in the parent. The UniversalHelper's findCanonicalName() uses these backward pointers to walk up the tree, verifying at each step that parent.getSubregistry(label) points back to the current registry, and reconstructing the full name along the way.\nOnce this pointer is set, the registry has committed to its position in the hierarchy:\nHowever, as long as ROLE_SET_PARENT is still held on ROOT_RESOURCE , the pointer can be changed, effectively remounting the registry at a different position (e.g. moving from nick.eth to nick.xyz ). To prevent this, the owner revokes ROLE_SET_PARENT and ROLE_SET_PARENT_ADMIN on ROOT_RESOURCE :\nViem\nimport { createWalletClient, http } from 'viem'\nimport { mainnet } from 'viem/chains'\nconst wallet = createWalletClient ({ chain: mainnet, transport: http () })\nconst ROLE_SET_PARENT = 1 n << 8 n\nconst ROLE_SET_PARENT_ADMIN = ROLE_SET_PARENT << 128 n\n// Set the canonical parent: this registry is \"sub\" under the nick.eth registry\nawait wallet. writeContract ({\naddress: subRegistryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'setParent' ,\nargs: [parentRegistryAddress, 'sub' ],\n})\n// Lock the parent pointer permanently by revoking both the role and its admin\nawait wallet. writeContract ({\naddress: subRegistryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'revokeRootRoles' ,\nargs: [ ROLE_SET_PARENT | ROLE_SET_PARENT_ADMIN , ownerAddress],\n})\nEmancipation\nRoles in a registry are normally scoped to a single name, but a role granted on ROOT_RESOURCE applies to every name in the registry. That reach is what makes some roles dangerous: ROLE_SET_RESOLVER on ROOT_RESOURCE can change the resolver of every name, ROLE_SET_SUBREGISTRY can swap any name's subregistry, ROLE_UNREGISTER can delete any name, and ROLE_UPGRADE can replace the registry implementation entirely. These four roles and their admin counterparts are the dangerous roles : isEmancipated() returns true once none of them has an assignee on ROOT_RESOURCE .\nOperational roles are not dangerous and do not affect emancipation: ROLE_REGISTRAR can only register available names and ROLE_RENEW only extends expiry. This is how the .eth registry works: the ETH Registrar holds both on ROOT_RESOURCE , while each name owner holds the roles defined by REGISTRATION_ROLE_BITMAP . Emancipation is irreversible: re-granting a dangerous role requires its admin counterpart, which is itself a dangerous role that no account holds anymore.\nTo see which roles still block emancipation, inspect the per-role assignee counts with roleCount(ROOT_RESOURCE) . And rely on isEmancipated() only after verifying which implementation the registry runs: an arbitrary contract can simply always return true . The migration-specific WrapperRegistry hardcodes the flag to true , with its root roles derived at migration time from the name's Name Wrapper fuses .\nEmancipation Across the Hierarchy\nEmancipation at one level is not sufficient if a higher level can still interfere. If the .eth registry is emancipated but the root registry is not, an account with ROLE_SET_SUBREGISTRY on the root registry's ROOT_RESOURCE could swap the .eth subregistry pointer. True emancipation requires the entire chain from root down to be secured:\n- Root registry : governed by ENS governance (trusted by design)\n- .eth registry : emancipated (only ROLE_REGISTRAR + ROLE_RENEW granted on ROOT_RESOURCE )\n- 2LD registries (e.g., alice.eth): depends on the 2LD owner's configuration\nFor a subname like sub.alice.eth to be fully emancipated, the alice.eth owner must emancipate their registry (revoke the dangerous roles on ROOT_RESOURCE ).\nCode Examples\nSubname registries are deployed as UserRegistry proxies through the Verifiable Factory. See Deploying a Registry Proxy for a code example. The examples below use the ETHRegistry, but the same functions are available on any PermissionedRegistry instance.\nQuerying Name State\ngetState returns the full state of a name in a single call: its registration status, expiry, current owner, token ID, and EAC resource. Both getState and getStatus accept any of a name's three identifiers (labelhash, tokenId, or resource) thanks to anyId polymorphism :\nViem\nimport { createPublicClient, http, keccak256, toHex } from 'viem'\nimport { mainnet } from 'viem/chains'\nconst client = createPublicClient ({ chain: mainnet, transport: http () })\nconst labelhash = BigInt ( keccak256 ( toHex ( 'alice' )))\n// Query the full state of a name\nconst state = await client. readContract ({\naddress: registryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'getState' ,\nargs: [labelhash],\n})\n// state: { status, expiry, latestOwner, tokenId, resource }\nconst STATUS = [ 'AVAILABLE' , 'RESERVED' , 'REGISTERED' ] as const\nconsole. log ( STATUS [state.status]) // \"REGISTERED\"\nconsole. log (state.latestOwner) // \"0x...\"\nconsole. log (state.expiry) // expiry as unix timestamp\n// anyId polymorphism: labelhash, tokenId, and resource all resolve\n// to the same name, so this returns the same result\nconst sameState = await client. readContract ({\naddress: registryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'getState' ,\nargs: [state.tokenId],\n})\nIf you only need to check whether a name is available, getStatus is a lighter alternative that returns just the status enum:\nViem\nconst status = await client. readContract ({\naddress: registryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'getStatus' ,\nargs: [labelhash],\n})\n// 0 = AVAILABLE, 1 = RESERVED, 2 = REGISTERED\nGranting and Revoking Roles\nA name owner can delegate specific capabilities to other accounts by granting roles on the name's labelhash. Multiple roles can be combined into a single call using bitwise OR:\nViem\nimport { createWalletClient, http, keccak256, toHex } from 'viem'\nimport { mainnet } from 'viem/chains'\nconst wallet = createWalletClient ({ chain: mainnet, transport: http () })\nconst ROLE_SET_RESOLVER = 1 n << 24 n\nconst ROLE_SET_SUBREGISTRY = 1 n << 20 n\nconst labelhash = BigInt ( keccak256 ( toHex ( 'alice' )))\n// Grant a single role\nawait wallet. writeContract ({\naddress: registryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'grantRoles' ,\nargs: [labelhash, ROLE_SET_RESOLVER , operatorAddress],\n})\n// Grant multiple roles at once using bitwise OR\nawait wallet. writeContract ({\naddress: registryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'grantRoles' ,\nargs: [labelhash, ROLE_SET_RESOLVER | ROLE_SET_SUBREGISTRY , operatorAddress],\n})\nTo revoke a role, call revokeRoles with the same arguments. Only the specified role is removed; other grants on the same name remain active:\nViem\nawait wallet. writeContract ({\naddress: registryAddress,\nabi: permissionedRegistryAbi,\nfunctionName: 'revokeRoles' ,\nargs: [labelhash, ROLE_SET_RESOLVER , operatorAddress],\n})\n// ROLE_SET_SUBREGISTRY remains active\nReference\nWrite Functions\nregister(label, owner, registry, resolver, roleBitmap, expiry) Register or reserve a name. Pass owner as address(0) to reserve without an owner.\nunregister(anyId) Unregister a name, making it available. Requires ROLE_UNREGISTER.\nrenew(anyId, newExpiry) Extend a name's expiry. Cannot reduce the current expiry. Requires ROLE_RENEW (root or name scope) while the name is unexpired; reviving an expired name requires ROLE_RENEW on ROOT_RESOURCE.\nsetSubregistry(anyId, registry) Set the subregistry for a name. Pointing two names to the same registry creates a namespace alias.\nsetResolver(anyId, resolver) Set the resolver for a name. Requires ROLE_SET_RESOLVER.\nsetParent(parent, label) Set this registry's canonical parent. Requires ROLE_SET_PARENT on ROOT_RESOURCE.\nsetURI(uri_, renderer) Set the metadata URI and optional renderer. Requires ROLE_SET_URI on ROOT_RESOURCE.\nunsafeTransfer(to, tokenId, data) Transfer a token without the two safe-transfer checks (emancipation and sole assignee). The owner must hold ROLE_CAN_TRANSFER_ADMIN, and the caller must be the owner or an approved operator.\nunsafeBatchTransfer(to, tokenIds, data) Batch variant of unsafeTransfer. All tokens must belong to the same owner.\ngrantRoles(anyId, roleBitmap, account) Grant roles on a name. Triggers token regeneration.\nrevokeRoles(anyId, roleBitmap, account) Revoke roles on a name. Triggers token regeneration.\ngrantRootRoles(roleBitmap, account) Grant contract-wide roles on ROOT_RESOURCE.\nrevokeRootRoles(roleBitmap, account) Revoke contract-wide roles on ROOT_RESOURCE.\nView Functions\ngetState(anyId) Complete state for a name: status, expiry, latestOwner, tokenId, resource.\ngetStatus(anyId) Get the registration status of a name.\nisEmancipated True when no dangerous role has an assignee on ROOT_RESOURCE. See Emancipation.\ngetExpiry(anyId) Get the expiry timestamp of a name.\ngetTokenId(anyId) Get the current token ID of a name.\ngetResource(anyId) Get the current EAC resource ID of a name.\nlatestOwnerOf(tokenId) Get the recorded owner of a token, ignoring expiry. Burned or stale token IDs return the zero address.\nownerOf(tokenId) Get the owner of a token, or address(0) if expired or stale token ID.\ngetSubregistry(label) Get the subregistry for a label. Returns address(0) if expired.\ngetResolver(label) Get the resolver for a label. Returns address(0) if expired.\ngetParent Get this registry's canonical parent registry and label.\nhasRoles(anyId, roleBitmap, account) Check whether an account holds the specified roles on a name.\nroles(anyId, account) Get the full role bitmap for an account on a name.\nroleCount(anyId) Get the packed assignee counts for all 64 roles on a name. Each nybble (4 bits) holds the count of accounts holding that role.\nhasAssignees(anyId, roleBitmap) Check whether any accounts hold the specified roles on a name.\ngetAssigneeCount(anyId, roleBitmap) Get per-role assignee counts for the specified roles on a name.\nhasRootRoles(roleBitmap, account) Check whether an account holds all specified roles on ROOT_RESOURCE only (does not check token-level roles).\nuri(tokenId) ERC1155 metadata URI. Delegates to the renderer if set, otherwise returns the static URI.\nfindOwner(label) Get the current owner of a name by label. Returns address(0) if expired.\nfindExpiry(label) Get the expiry timestamp of a name by label.\nfindTokenId(label) Get the current token ID of a name by label.\nEvents\nRegistryCreated() Emitted once in the constructor when the registry is deployed.\nLabelRegistered(tokenId, labelHash, label, owner, expiry, sender) Name registered with an owner.\nTokenResource(tokenId, resource) Associates a token ID with its EAC resource ID. Emitted during registration.\nLabelReserved(tokenId, labelHash, label, expiry, sender) Name reserved without an owner.\nLabelUnregistered(tokenId, sender) Name unregistered.\nExpiryUpdated(tokenId, newExpiry, sender) Expiry extended via renew().\nSubregistryUpdated(tokenId, subregistry, sender) Subregistry changed.\nResolverUpdated(tokenId, resolver, sender) Resolver address changed.\nTokenRegenerated(oldTokenId, newTokenId) Token ID changed due to role update.\nParentUpdated(parent, label, sender) Canonical parent reference changed.\nURIUpdated(uri, renderer, sender) Emitted when metadata URI or renderer is changed."}
{"url":"https://docs.ethena.fi/technical-design/minting-usde","domain":"docs.ethena.fi","title":"Minting USDe | Ethena","hash":"94b58f5c2ed35adb0c2714477d04d59626e840b2723e0d32bd3740c3fefcd602","tokens":991,"chars":3962,"crawler":"crawler-f6nn","verified":"exact","ts":1791172200784,"text":"⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nMinting USDe\nThe genesis of USDe\n\"Minting\" USDe refers to the creation of new synthetic dollars. \"Redeeming\" USDe is the reversal process, of exchanging synthetic dollars for the assets that collateralize them.\nThe methods of minting vary depending on the type of stablecoin/synthetic dollar. Here we will explore the novel Ethena synthetic dollar minting process.\nThe Ethena synthetic dollar minting system encompasses the following design principles:\nHow does it work?\n-\nUsers request a price from the Ethena Pricing API.\n-\nUsers can generate a signed EIP712 order and optionally submit it to Ethena's minting server.\n-\nNote : at this stage, users have complete control over their assets - they have the freedom to create, hold, and sign the price at their discretion. The approval to transfer assets only happens when the user willingly signs the order.\n-\nOnce the signed order is received, Ethena's server checks that the user has the required asset balance and signed approvals and that the dynamic hedging server can currently handle the order. Part of this involves communicating with the OES solution to prepare for the incoming mint or redemption request.\n-\nNote : Ethena does have the ability to reject an order based on these conditions. However, even in this centralized part of the process, the protocol could never alter the contents of the signed order due to the immutability of blockchain cryptographic signatures. This design ensures that the user's order - the backing asset, its size, any included slippage, and the synthetic dollars to be minted - remains as the user intended.\n-\nThe order is sent to the blockchain with the atomic mint function called when these checks are passed. As above both the transfer of the user's assets and the minted synthetic dollars happen in a single transaction.\n-\nUpon success the hedging system actions the mint events to ensure the delta neutrality of the protocol's overall backing. Read more about these concepts in the Hedging System and Backing Asset Custody sections.\nBy blending centralized and decentralized elements in this way, Ethena achieves a relatively high level of trustlessness. Users always retain control over their assets prior to mint and their orders will be processed exactly as specified. And while Ethena has some control over order acceptance, the blockchain's transparency and cryptographic guarantees mean users can confidently engage with the protocol, knowing their transactions are secure and unalterable.\nSlippage\nSlippage occurs when the price at which a trade is executed differs from the expected price, usually due to market volatility or trade size.\nEthena has designed its minting process to minimize slippage for users. Before submitting a minting transaction, users receive a \"price\" from the Ethena Pricing API that includes a predefined slippage range. The user then signs this price, confirming their acceptance of the potential variation within the specified range.\nWhen the transaction is executed, the smart contract logic ensures that the final minting settlement price falls within the signed slippage range. This approach provides users with a level of certainty about the price they will receive and makes the transaction predictable.\nSlippage management is a key part of Ethena's minting design strategy, aiming to provide users with a more stable and transparent transaction experience.\nAudit\nThe Ethena Minting Contracts are regularly audited. See the section for up-to-date information.\nQuick Answers\nQ: Am I only able to get USDe via minting USDe with Ethena?\nNo, you can acquire USDe initially via decentralized protocols such as Curve and Uniswap as well as buy & sell USDe on Centralized Exchanges such as Binance, OKX and Bybit.\nLast updated 1 year ago\nWas this helpful?\n- How does it work?\n- Slippage\n- Audit\n- Quick Answers\nWas this helpful?"}
{"url":"https://developers.skyeco.com/guides/sky/token-governance-upgrade/protocol-participants/","domain":"developers.skyeco.com","title":"Protocol Participants | Sky Protocol Docs","hash":"323005dd130b770fd987770d5bc408f2b34f97a9fa3cc375a59c0a216bcf7eab","tokens":2037,"chars":8146,"crawler":"crawler-f6nn","verified":"exact","ts":1791172203061,"text":"Skip to content\nSky Protocol Docs\nGitHub\nSelect theme\nProtocol Participants\nGovernance Delegates\nSection titled “Governance Delegates”\nAll current Governance Delegates must deploy a new Vote Delegate V3 contract using the Vote Delegate Factory V3 0x4Cf3DaeFA2683Cd18df00f7AFF5169C00a9EccD5 . To do this, call the create() function on the factory. After deployment, verify that the delegate’s chief() field points to the upgraded Chief contract. Migrate any self-staked MKR to SKY, and inform all MKR or SKY holders who delegate to you that they must re-delegate to your new address. Old V2 delegate contracts will stop counting votes once the new Chief is ratified.\nSteps for Governance Delegates\nSection titled “Steps for Governance Delegates”\n-\nDeploy a V3 Delegate:\nCall create() on Vote Delegate Factory V3. The factory will deploy a new your new Vote Delegate contract which will be linked to the upgraded Chief and Polling contracts.\n-\nVerify the Link:\nCall chief() on your new delegate contract. It must return the new Chief address, confirming V3 compatibility.\n-\nMigrate Your Own Stake:\nConvert any MKR you have locked to SKY, then call lock() in your V3 delegate contract to stake your SKY.\n-\nUpdate Public References:\nUpdate your Governance Portal profile, delegate registry repositories, forum threads, dashboards, and ENS records to show your new delegate address.\n-\nAnnounce the Change:\nShare the update via forum posts, X/Twitter, Discord, newsletters, and Governance & Risk calls. Provide a direct link to the Voting Portal’s “Re-Delegate” flow, pre-filled with your new address.\n-\nDeprecate the Old Contract:\nOnce all delegations have moved, label the old delegate contract as deprecated wherever possible.\nBroadcast Message for Delegators\nFeel free to use or adapt the following message:\nAction required: Our new Vote Delegate V3 contract is live at 0xAB...34 . Please open the Voting Portal and re-delegate your SKY balance to the new delegate address to keep your voting weight active under the upgraded Chief.\nGovernance Participants\nSection titled “Governance Participants”\nAs a governance participant, you currently either deposit MKR directly in the Chief contract to vote yourself or delegate your voting weight through a Vote Delegate contract managed by a Governance Delegate. With the Sky Ecosystem governance upgrade, MKR and DSChief are replaced by SKY and the new Chief, and new Vote Delegate V3 contracts are introduced. After the new Chief is ratified, DSChief and all Delegate V2 contracts will stop accruing voting weight. You must move your MKR from the current Chief to your new SKY token balance in the upgraded Chief. MKR can be upgraded to SKY without incurring any Delayed Upgrade Penalties for a limited time.\nDirect Self-Voting with SKY\nSection titled “Direct Self-Voting with SKY”\n-\nWithdraw MKR from DSChief:\nIn the current Voting Portal, choose Withdraw , approve the IOU, then execute free() . DSChief requires two transactions because it burns an IOU token first.\n-\nUpgrade MKR to SKY:\nUse the official converter (or any interface that calls the published MkrSky contract). One MKR mints 24,000 SKY until Sky Ecosystem governance activates the Delayed Upgrade Penalty on all upgrade conversions.\n-\nDeposit SKY into the New Chief:\nlock(uint256) function deposits your SKY token balance into the new Chief.\n-\nVote:\nUse prepareSlate and vote(bytes32[]) as before; the only difference is the token.\n-\nWithdraw Later:\nUse free() to withdraw SKY from Chief back to your wallet; IOU approval is no longer needed.\nDelegated Voting through Delegate V3\nSection titled “Delegated Voting through Delegate V3”\n-\nWithdraw MKR from the V2 Delegate:\nUse free() to withdraw. V2 delegates will be ignored once the new Chief is live.\n-\nUpgrade MKR to SKY:\nOnly SKY counts in the new Chief.\n-\nFind Your Delegate’s New Address:\nEvery active Governance Delegate will publish a V3 contract. Look for the new address on the Delegates page or their forum thread, or select a new Governance Delegate.\n-\nVerify the Delegate Contract:\nCall chief() on the contract; it must return the new Chief address, confirming V3 compatibility.\n-\nConfirm Official Deployment:\nEnsure the Vote Delegate V3 contract was deployed using the official Vote Delegate Factory V3 by calling the created getter function, which returns 1 for a valid contract.\n-\nDeposit SKY into the V3 Delegate:\nUse the Voting Portal to deposit SKY into the V3 Vote Delegate contract or use the lock() function on the Vote Delegate V3 contract.\nSeal Engine Stakers\nSection titled “Seal Engine Stakers”\nIf you have a position in the Seal Engine (also known as LockStake Engine V1), you must close it and migrate to the Staking Engine (LockStake Engine V2).\nThis applies to current vaults that:\n- Are earning farming rewards (lsMKR)\n- Have an active vote delegate\n- May or may not have USDS debt\n1. Collect Your Position Data\nSection titled “1. Collect Your Position Data”\nCheck the following before starting the migration:\nWhat to Check\nWhy It Matters During Shutdown\nUSDS debt (drawn balance)\nMust be zero before you can unlock collateral in V1.\nCollateral locked (MKR)\nEnsure your receiving wallet has enough gas for the conversion.\nlsMKR farm rewards\nClaim any outstanding rewards; unclaimed lsMKR is burned at close.\nVote delegate address\nYou’ll need to re-delegate after opening your V2 vault.\n2. Close the V1 Position\nSection titled “2. Close the V1 Position”\nAll actions are performed using the V1 UI or contract.\n-\nHarvest lsMKR rewards:\nCall harvest() to claim any outstanding lsMKR.\n-\nRepay USDS debt (if any):\nCall wipe(uint wad) to bring your USDS debt to exactly zero. Include stability fees in the wipe.\n-\nRemove the vote delegate (optional):\nCall delegate(0x000...00) to clear the delegate address.\n-\nUnlock collateral:\nCall free(uint wad) to release MKR to your wallet.\n-\nRevoke unlimited approvals (optional):\nIn your wallet UI, remove infinite MKR and lsMKR spend approvals for LockStake Engine V1.\n3. Upgrade MKR to SKY\nSection titled “3. Upgrade MKR to SKY”\nLockStake Engine V2 accepts SKY, not MKR. If you already hold SKY from another source, you can skip this conversion for that portion.\n-\nConvert MKR to SKY:\nCall mkrToSky() on the Converter V2 contract.\n-\nReceive SKY:\nYou now hold SKY. When you lock SKY in V2, lsSKY is minted automatically.\n4. Open a New V2 “Staking Engine” Vault\nSection titled “4. Open a New V2 “Staking Engine” Vault”\n-\nApprove SKY for V2:\nCall sky.approve(lockstakeEngineV2, type(uint256).max) once.\n-\nLock collateral:\nCall lock(uint wadSKY) .\n-\n(Optional) Draw USDS:\nCall draw(uint wadDai) . The per-vault fee is now immutable; check the UI for the set value.\n-\nSet your vote delegate:\nCall delegate() .\n-\nConfirm farming has started:\nV2 emits Lock() and DelegateChanged() events. Farming rewards accrue in lsSKY.\n5. What You Get Back When Closing V1\nSection titled “5. What You Get Back When Closing V1”\nAsset\nReturned?\nNotes\nMKR collateral\nYes\nAll locked MKR is returned to your wallet.\nlsMKR farming rewards\nOnly if claimed\nUnclaimed lsMKR is burned when the vault is closed.\nVote power\nRemoved\nYou must re-delegate in V2.\nAny fees\nNo refund\nStability fees are consumed on wipe.\nYou cannot lock MKR directly in V2—convert to SKY first.\nOn-Chain Migration with LockstakeMigrator\nSection titled “On-Chain Migration with LockstakeMigrator”\nIf you want to migrate a Seal Engine position with USDS debt without repaying the debt manually, use the on-chain migrator (if the new Staking Engine has enough debt ceiling).\nLockstakeMigrator (flash-loan helper):\n- Use the LockstakeMigrator contract instead of steps 2–4 for zero-debt-repayment migration.\n- The migrator will:\n- Take a short-lived USDS flash loan.\n- Repay your V1 debt, unlock MKR, and convert it to SKY.\n- Lock SKY into a new V2 vault.\n- Draw USDS from the new vault to repay the flash loan.\nYour vault will end up in V2 with the same debt and collateralization ratio, but with the new fee schedule and SKY collateral.\nReleased into the public domain (CC0 1.0 Universal) – trademarks remain with their owners; no warranty. See full license ."}
{"url":"https://docs.layerzero.network/v2/concepts/protocol/message-library","domain":"docs.layerzero.network","title":"Message Library Overview - LayerZero","hash":"fe324e5a5745bdc958f55ae10d9b58e42636f9f69ac90e646872a63708e40f60","tokens":1280,"chars":5118,"crawler":"crawler-f6nn","verified":"exact","ts":1791172205699,"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\nMessage Libraries\nMessage Library Overview\nLearn about Message Library Overview in LayerZero V2. Understand the architecture, core concepts, and how it enables omnichain interoperability. Architecture…\nThe Message Library is a fundamental concept in the LayerZero protocol that encompasses how the protocol can both send and receive messages. These libraries are responsible for processing, encoding / decoding, and verifying messages as they traverse between blockchains.\nWhy Do Message Libraries Exist?\nWhile specific implementations may vary to accommodate different use cases (e.g., push-based messaging versus pull-based queries), several common themes form the backbone of all Message Libraries.\nModularity & Separation of Concerns\nMessage Libraries are designed to abstract and isolate the core functions of crosschain messaging. By separating tasks (e.g., encoding / decoding packets, fee calculation and management, configuration enforcement) from higher-level application logic and the LayerZero Endpoint, each library can be independently developed, optimized, and updated. This modularity enables:\n-\nIndependent Optimization: Specialized libraries (like the Ultra Light Node) can be created without affecting how other parts of the protocol operate.\n-\nEasier Maintenance: The well-defined boundaries between components result in a cleaner, more maintainable architecture.\nImmutable and Append-Only Design\nOnce deployed, Message Libraries are immutable and act as append-only components. This means that:\n-\nPredictability: The behavior of a library remains consistent over time, ensuring that applications can rely on its functionality.\n-\nBackward Compatibility: New libraries can be added to the ecosystem without affecting existing applications. This allows the protocol to evolve; integrating innovations and optimizations, while preserving the performance and security of the deployed components.\nCustomizability and Flexibility\nEach Message Library supports a range of configurations, which applications set via the LayerZero Endpoint. These configurations determine critical aspects of message processing:\n-\nSend Libraries: Custom configurations define how packets are encoded and how fees are computed for routing messages outbound from a source chain.\n-\nReceive Libraries: Configurations specify the required verification parameters that must be met before a message is accepted and routed inbound to the destination receiver.\nThis flexibility allows the system to support various messaging paradigms, such as push-based messaging (e.g., Ultra Light Node ) or pull-based queries (e.g., Read Library ).\nSecurity and Integrity\nSecurity is embedded at every layer of the message lifecycle:\n-\nEncoding Integrity: On the send side, messages are wrapped in a standardized Packet that includes unique identifiers, nonces, and routing metadata to prevent replay attacks and misrouting.\n-\nRigorous Verification: On the receive side, libraries perform stringent checks to ensure the message has not been tampered with.\n-\nConfiguration Enforcement: Receive libraries enforce that only the preconfigured, authorized workers can validate and process the incoming message, adding an extra layer of security.\nEfficiency and Decoupling\nEfficiency is achieved by:\n-\nStreamlined Processing: Specialized libraries focus on only transmitting and processing the essential data needed for a specific messaging workflow, reducing overhead.\n-\nDecoupled Logic: By decoupling message processing from the Endpoint and application code, the protocol supports rapid processing and efficient scaling without compromising on security or flexibility.\nBenefits for Developers and Users\n-\nReliability: Immutable, well-defined libraries ensure that crosschain messaging remains consistent and dependable.\n-\nSecurity: Robust verification and configuration enforcement guard against unauthorized access or tampering.\n-\nFlexibility: Developers can choose from different library implementations that best match their application’s needs, with the assurance that new capabilities will be seamlessly added.\n-\nScalability: The append-only nature of these libraries enables the protocol to integrate new innovations without disrupting existing deployments.\nIn summary, the Message Library is a key building block in the LayerZero protocol that unifies the processes of message encoding, transmission, decoding, and verification. Its modular, immutable, and flexible design ensures that the protocol can adapt over time while delivering secure, efficient, and reliable crosschain communication.\nFurther Reading\n-\nFor details on how messages are processed on the sending side, see the Message Send Library page.\n-\nFor details on how inbound messages are decoded and verified on the receiving side, see the Message Receive Library page.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.anchor-lang.com/docs/references/examples","domain":"www.anchor-lang.com","title":"Example Programs","hash":"ffdacfd3a0d929a9f0709d76057af9e613ac65b2033b62f9ab40a61df2985b06","tokens":616,"chars":2463,"crawler":"crawler-f6nn","verified":"exact","ts":1791172207896,"text":"Anchor Docs\nGithub Discord Stack Exchange\nProgram Development\nExample Programs\nExample Anchor programs references\nThere are extensive examples for individual Anchor features on the Solana Foundation Program Examples repo .\nAdditionally, the Quicknode Solana Program Examples repo includes Anchor examples of larger programs, like order books, loan markets, betting markets, and so on. The current Anchor stack, including Anchor 1.x, the multiple files layout, and LiteSVM for tests is used throughout.\nBasics\nExample Description\nchecking-accounts Checking account example with Anchor\nclose-account Close account example with Anchor\ncounter Counter program using Anchor\ncreate-account Create accounts with Anchor\ncross-program-invocation Cross program invocation with Anchor\nfavorites Store user \"favorites\" with Anchor\nhello-solana Basic \"Hello, Solana!\" program with Anchor\npda-rent-payer PDA rent payer example with Anchor\nprocessing-instructions Process instructions using Anchor\nprogram-derived-addresses Program-derived addresses with Anchor\nrealloc Reallocate account data with Anchor\nrent Calculate account SOL rent with Anchor\ntransfer-sol Transfer SOL tokens with Anchor\nTokens\nExample Description\ncreate-token Create an SPL token with Anchor\nescrow Escrow program using Anchor\nnft-minter Mint NFTs using Anchor\nnft-operations NFT operations with Anchor\npda-mint-authority PDA as mint authority with Anchor\nspl-token-minter SPL token minting with Anchor\ntoken-fundraiser Token fundraiser using Anchor\ntoken-swap Swap tokens with Anchor\ntransfer-tokens Transfer SPL tokens using Anchor\nToken Extensions\nExample Description\nbasics Basics of Token 2022 with Anchor\ncpi-guard CPI guard example with Anchor\ndefault-account-state Default account state setup with Anchor\ngroup Token grouping example with Anchor\nimmutable-owner Immutable owner setup with Anchor\ninterest-bearing Interest-bearing tokens using Anchor\nmemo-transfer Memo transfer with Anchor\nmetadata Token metadata with Anchor\nmint-close-authority Mint close authority with Anchor\nmultiple-extensions Multiple extensions example with Anchor\nnft-meta-data-pointer NFT metadata pointer with Anchor\nnon-transferable Non-transferable tokens using Anchor\npermanent-delegate Permanent delegate setup with Anchor\ntransfer-fee Transfer fees example with Anchor\ntransfer-hook Transfer hook example with Anchor\nPrevious\nSealevel Attacks\nNext\n1.2.0\nOn this page\nBasics Tokens Token Extensions\nEdit on GitHub"}
{"url":"https://docs.marinade.finance/marinade-protocol/protocol-overview/staking-rewards-report","domain":"docs.marinade.finance","title":"Staking Rewards Report | Marinade Documentation","hash":"bf64677207b5c982afa1733a89b3e07d12fa9f682fccc4bcf4fdb3b32eab1551","tokens":1742,"chars":6966,"crawler":"crawler-f6nn","verified":"exact","ts":1791172210662,"text":"Marinade Documentation\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nStaking Rewards Report\nLearn how to use the Staking Rewards Report to view and export your Marinade native staking rewards by epoch, and understand what the data represents.\nOverview\nThe Staking Rewards Report is a self-service tool that provides a summary of staking rewards earned through Marinade's native staking .\nIt is designed to help users better understand rewards earned over time by presenting staking activity in a structured, historical view.\nThe report is intended for reference and transparency , and reflects indexed staking reward data rather than wallet balance changes.\nNot covered: Marinade Recipes / Customized Rewards. Although Recipes use native staking, the report only tracks rewards paid in SOL. If your position pays out in another token (USDG, USDC, cbBTC, etc.), those payouts are airdropped to your wallet each epoch and no report is generated for them. Track them in your wallet's transaction history or on a Solana explorer such as Solscan . See Marinade Recipes for details.\nWhat the Staking Rewards Report Shows\nThe report displays staking-related rewards and activity from Marinade native staking in a filterable view.\nYou can customize the report using the following options:\nType\n-\nInflation Reward\n-\nMEV Reward\n-\nMarinade Settlement\n-\nDeposit\n-\nWithdrawal\nDate Range\n-\nCurrent month, Last month\n-\nThis year, Last year\n-\nAll time, Custom range\nGroup By\n-\nDay, Week, Month\n-\nEpoch, Year\nAll values shown represent earned rewards , displayed in both SOL and USD (where applicable), and are aggregated based on the selected grouping.\nWhat's Included vs. Excluded\nIncluded\n-\nSOL-denominated rewards earned from Marinade native staking with SOL rewards, and existing Marinade Select positions\n-\nEarned reward amounts displayed in SOL and USD\n-\nAggregated staking reward records based on the selected grouping\nNot Included\n-\nWallet transfers unrelated to staking\n-\nLiquid staking (mSOL) rewards\n-\nThe amount of SOL staked for each reward entry\n-\nValidator-level performance or commission breakdowns\n-\nIntraday or real-time reward accrual\n-\nMarinade Recipes (Customized Rewards) payouts, meaning rewards paid in a non-SOL token such as USDG, USDC, or cbBTC. These are airdropped to your wallet each epoch; no report is generated for them.\nHow to Request Your Staking Rewards Report\nStep 1: Connect Your Wallet\n-\nGo to https://app.marinade.finance/ and connect your wallet.\n-\nOpen the Portfolio tab.\nUnder Positions , you should see any staking positions associated with the connected wallet. This may include stake accounts not created directly through Marinade.\nIf no positions are found, you may see:\n\"It looks like you don't have any positions yet. You can start staking with Marinade and earn rewards!\"\nNotes:\n-\nOnly positions associated with the connected wallet can be displayed\n-\nAssets deposited into DeFi protocols or not held directly in the wallet may not appear\n-\nThis applies to other liquid staking tokens (LSTs) as well\nStep 2: Request Your Rewards Data\n-\nOpen the Rewards tab.\n-\nIf this is your first time using the tool, you'll see an option to Request data .\n-\nClick Request data .\nYou'll be prompted to optionally enter an email address with the message:\n\"Data are usually generated within 24 hours. Enter your email, and we'll notify you as soon as it's ready.\"\nProviding an email is optional but recommended.\nSecurity note: We only send notifications from @marinade.finance .\n-\nClick Confirm .\nYour request will typically complete within 24 hours .\nStep 3: View Your Report\nOnce ready:\n-\nYou'll receive an email notification if you provided an address, or\n-\nYou can reconnect your wallet and return to the Rewards tab\nFrom there, you can:\n-\nView and sort rewards\n-\nGroup data by your preferred timeframe\n-\nExport the report if needed\nIf you see \"No rewards found\" , it means no eligible records were found for the connected wallet.\nCurrently supported: Marinade Native staking with SOL rewards, and existing Marinade Select positions.\nNot supported: Marinade Recipes / Customized Rewards (non-SOL reward tokens) and Marinade Liquid (mSOL).\nData Refresh & Updates\nThe Staking Rewards Report does not automatically refresh every epoch.\nThe report shows the most recently indexed data, along with a timestamp indicating when it was last updated. To fetch the latest data, click \"Request latest data\" in the report. After requesting, reload the Marinade app in your browser (Ctrl+R, or Cmd+R on Mac) and reopen the Rewards tab. The reload shows the current state. Check the timestamp: if it has not moved, the refresh is still running and can take up to 24 hours.\nAfter requesting a refresh:\n-\nStaking activity is re-indexed\n-\nThe process typically takes up to 24 hours\n-\nRequest latest data is greyed out for about 4 hours after a request, so you cannot queue another refresh straight away\n-\nYour existing report stays on screen while the new one is prepared, so you can keep using the previous figures until the refresh lands\n-\nUpdated data will appear once indexing completes\nProviding an email allows us to notify you when the report is ready.\nUnderstanding Small or Zero Rewards\nSeeing very small, infrequent, or zero rewards for a given period is usually expected.\nCommon reasons include:\n-\nYour stake was activated partway through an epoch\n-\nRewards are still pending finalization or indexing\n-\nRewards are aggregated by epoch rather than continuously\n-\nSolana staking rewards accrue per epoch (about a day and a half ), so when grouping by Day , some days will show no rewards at all\n-\nSmall reward amounts may round down when displayed\n-\nDisplayed USD values are estimates based on historical pricing and may differ slightly due to rounding\nExporting Your Report\nThe Staking Rewards Report can be exported for offline review.\nExport Format\n-\nCSV\n-\nPDF\n-\nXLSX\nExport Scope\n-\nSelected data reflects current filters and grouping\n-\nRaw data exports the underlying ungrouped dataset\nExports are provided for convenience and reference.\nGetting Help\nIf something looks incorrect or unclear, please contact Marinade Support .\nTo help us assist you faster, include:\n-\nYour wallet address\n-\nApproximate staking timeframe and amount\n-\nYour email address\n-\nAny relevant transaction links (if available)\nThis report is provided for informational purposes only. Users are responsible for determining how staking rewards should be reported for tax purposes under their local laws. Marinade is not responsible for tax outcomes resulting from the use of this report.\nPrevious SAM Resources\nNext Fees and Pricing\nLast updated 2 days ago\nWas this helpful?\n- Overview\n- What the Staking Rewards Report Shows\n- What's Included vs. Excluded\n- How to Request Your Staking Rewards Report\n- Data Refresh & Updates\n- Understanding Small or Zero Rewards\n- Exporting Your Report\n- Getting Help\nWas this helpful?"}
{"url":"https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"57309cf1d62d5e953e04cb62c976348129be1a7f78ab1fb019d5bb28ca05d571","tokens":2008,"chars":8031,"crawler":"crawler-f6nn","verified":"exact","ts":1791172213426,"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\nCreate L2 Rollup\nCreating your own L2 rollup testnet\nLearn how to deploy and orchestrate all OP Stack components for a complete testnet deployment.\nLearn the OP Stack — stop 6 of 14.\nYou’ve covered the foundations: what the stack is, how it differs from\nEthereum, and which components make it up. In this first project you\ndeploy a rollup testnet with op-deployer and start each component\nyourself. Work through every part of the series, then continue to\nTransaction flow .\nWelcome to the complete guide for deploying your own OP Stack L2 rollup testnet. This multi-part tutorial will walk you through each component step-by-step, from initial setup to a fully functioning rollup.\nThis tutorial requires intermediate-level experience working with EVM chains .\nYou should be comfortable with concepts like smart contracts, private keys, RPC endpoints, gas fees, and command-line operations.\nBasic familiarity with Docker is also recommended.\nWhat you’ll build\nBy the end of this tutorial, you’ll have a complete OP Stack testnet with:\n- L1 Smart Contracts deployed on Sepolia testnet\n- Execution Client (op-reth) processing transactions\n- Consensus Client (op-node) managing rollup consensus\n- Batcher (op-batcher) publishing transaction data to L1\n- Proposer (op-proposer) submitting state root proposals\n- Challenger (op-challenger) monitoring for disputes\nBefore you start\nSet up the following before you pick a setup path below. Both the automated and manual paths need these dependencies and resources.\nSoftware dependencies\nDependency Version Version check command\ngit ^2 git --version\ngo ^1.26 go version\nrust (source builds only) pinned by rust/rust-toolchain.toml rustc --version\njust (source builds only) ^1 just --version\nzip (source builds only) ^3 zip --version\nnode ^20 node --version\npnpm ^8 pnpm --version\nfoundry ^0.2.0 forge --version\nmake ^3 make --version\njq ^1.6 jq --version\ndirenv ^2 direnv --version\nDocker ^24 docker --version\nNotes on specific dependencies\nExpand each dependency below for details\nnode\nWe recommend using the latest LTS version of Node.js (currently v20).\nnvm is a useful tool that can help you manage multiple versions of Node.js on your machine.\nYou may experience unexpected errors on older versions of Node.js.\nfoundry\nWe will use cast to generate wallet addresses in this guide.\ndirenv\nParts of this tutorial use direnv as a way of loading environment variables from .envrc files into your shell.\nThis means you won’t have to manually export environment variables every time you want to use them.\ndirenv only ever has access to files that you explicitly allow it to see. After installing direnv , you will need to make sure that direnv is hooked into your shell .\nMake sure you’ve followed the guide on the direnv website , then close your terminal and reopen it so that the changes take effect (or source your config file if you know how to do that).\nMake sure that you have correctly hooked direnv into your shell by modifying your shell configuration file (like ~/.bashrc or ~/.zshrc ).\nIf you haven’t edited a config file then you probably haven’t configured direnv properly (and things might not work later).\nDocker\nDocker is used extensively in this tutorial for running various OP Stack components.\nMake sure you have both Docker and Docker Compose installed and running on your system.\nOn Linux, you may need to configure Docker to run without sudo .\nIf you’re using Docker Desktop, ensure it’s running before starting the tutorial.\nYou can verify your installation with:\ndocker run hello-world\nGet access to a sepolia node\nSince you’re deploying your OP Stack chain to Sepolia, you’ll need to have access to a Sepolia node.\nYou can either use a node provider like Alchemy (easier) or run your own Sepolia node (harder).\nRequired resources\n-\nSepolia ETH - You’ll need about 2-3 ETH:\n- Start with Superchain Faucet (gives 0.05 ETH)\n- Get more from:\n- Alchemy Faucet\n- Infura Faucet\n- Paradigm Faucet\n-\nL1 RPC URL - An RPC endpoint to connect to the Sepolia network. You can get this from node providers like Alchemy , Infura . This is required so op-deployer and other services can read from and send transactions to L1.\nTestnet Only : This guide is for testnet deployment only .\nChoose your path\nWith your dependencies and resources in place, pick the path that fits how you want to work:\n- Automated setup — the fastest way to a running rollup. Uses the complete working implementation in this repository and handles all configuration and deployment for you.\n- Manual setup — walks through each component step-by-step. Choose this if you want to understand each component in detail or need custom configurations.\nAutomated setup\nIf you want to get started quickly, you can use the complete working implementation provided in this repository. This automated setup handles all the configuration and deployment steps for you.\nComplete working example A complete, working implementation is available in the create-l2-rollup-example/ directory. This includes all necessary scripts, Docker Compose configuration, and example environment files.\nAutomated setup steps\n-\nClone and navigate to the code directory:\ngit clone https://github.com/ethereum-optimism/optimism.git\ncd optimism/docs/public-docs/create-l2-rollup-example\n-\nConfigure your environment:\ncp .example.env .env\n# Edit .env with your L1_RPC_URL, PRIVATE_KEY, and other settings\n-\nRun the automated setup:\nmake init # Download op-deployer\nmake setup # Deploy contracts and generate configs\nmake up # Start all services\nmake test-l1 # Verify L1 connectivity\nmake test-l2 # Verify L2 functionality\n-\nMonitor your rollup:\nmake logs # View all service logs\nmake status # Check service health\nThe automated setup uses the standard OP Stack environment variable conventions (prefixed with OP_* ) and handles all the complex configuration automatically.\nManual setup\nIf you prefer to understand each component in detail or need custom configurations, follow the step-by-step guide below. Each step builds on the previous one, so complete them in order for the best experience.\nDirectory structure\nTo keep your rollup deployment organized, we’ll create a dedicated directory structure. All components will be set up within this structure:\nrollup/\n├── deployer/ # op-deployer files and contracts\n├── sequencer/ # op-reth and op-node\n├── batcher/ # op-batcher configuration\n├── proposer/ # op-proposer setup\n└── challenger/ # op-challenger files\nEach component’s documentation will show you how the directory structure evolves as you add files and configurations.\nThroughout this tutorial, all file paths will be relative to this rollup directory structure. Make sure to adjust any commands if you use different directory names.\nManual setup steps\nThe manual path is organized into sequential steps that build upon each other:\n1\nSpin up op-deployer\nInstall op-deployer, deploy L1 contracts, and prepare your environment Go to op-deployer setup →\n2\nSpin up sequencer\nSet up and run op-reth and op-node (the execution and consensus layers) Go to sequencer setup →\n3\nSpin up batcher\nConfigure and start op-batcher for L1 data publishing Go to batcher setup →\n4\nSpin up proposer\nSet up op-proposer for state root submissions Go to proposer setup →\n5\nSpin up challenger\nConfigure op-challenger for dispute resolution monitoring Go to challenger setup →\nSpin up op-deployer\nAlready have your dependencies? Get started and spin up op-deployer\nNeed help?\n- Questions or issues : Ask questions or report bugs and docs problems on the Optimism monorepo issue tracker\n- Code examples : Browse the complete working example that accompanies this tutorial\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.phantom.com/sdks/browser-sdk/sign-and-send-transaction","domain":"docs.phantom.com","title":"Sign and send transactions - Phantom developer documentation","hash":"1e287cddb95af16975eb20902d9bc687879a94e217af2cd984732ecaab0e2421","tokens":2606,"chars":10423,"crawler":"crawler-f6nn","verified":"exact","ts":1791172216091,"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\nBrowser SDK\nSign and send transactions\nSign and send transactions on Solana and Ethereum using the Phantom Connect Browser SDK.\nThe Phantom Connect Browser SDK provides chain-specific transaction methods through dedicated interfaces ( sdk.solana and sdk.ethereum ) for optimal transaction handling.\nEmbedded wallet limitations : The signTransaction and signAllTransactions methods aren’t supported for embedded wallets. For embedded wallets, use only signAndSendTransaction that signs and broadcasts the transaction in a single step.\nTransaction security for embedded wallets : All transactions signed for embedded wallets pass through Phantom’s advanced simulation system before execution. This security layer automatically blocks malicious transactions and transactions from origins that have been reported as malicious, providing an additional layer of protection for your users’ assets.\nChain-specific transaction methods\nSolana transactions (sdk.solana)\n// Sign and send transaction\nconst result = await sdk . solana . signAndSendTransaction ( transaction );\n// Just sign (without sending) - Note: Not supported for embedded wallets\nconst signedTx = await sdk . solana . signTransaction ( transaction );\nEthereum transactions (sdk.ethereum)\n// Send transaction\nconst result = await sdk . ethereum . sendTransaction ({\nto: \"0x...\" ,\nvalue: \"1000000000000000000\" ,\ngas: \"21000\" ,\n});\nDapp-sponsored transactions\nPass a presignTransaction callback to signAndSendTransaction for Solana transactions that need double signing, such as dapp fee payer flows. Calls without it proceed normally — it is never applied globally.\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer (for example, your app as the fee payer), that signing must happen via this callback, after Phantom has constructed and validated the transaction. This restriction does not apply to injected providers (Phantom browser extension).\npresignTransaction only fires for Solana transactions via the embedded provider. EVM transactions and injected providers are unaffected.\nTransaction format\nThe transaction string passed to the callback is base64url-encoded (URL-safe base64 without = padding, using - and _ instead of + and / ). The SDK exports base64urlDecode and base64urlEncode utilities:\nimport { base64urlDecode , base64urlEncode } from \"@phantom/browser-sdk\" ;\nExample: dapp fee payer\nimport { base64urlDecode , base64urlEncode } from \"@phantom/browser-sdk\" ;\nimport { VersionedTransaction } from \"@solana/web3.js\" ;\n// This call co-signs as fee payer\nconst result = await sdk . solana . signAndSendTransaction ( transaction , {\npresignTransaction : async ( tx , context ) => {\n// Send the transaction to your backend for fee payer signing\nconst response = await fetch ( \"/api/presign\" , {\nmethod: \"POST\" ,\nbody: JSON . stringify ({ transaction: tx , networkId: context . networkId }),\nheaders: { \"Content-Type\" : \"application/json\" },\n});\nconst { transaction : signedTx } = await response . json ();\nreturn signedTx ; // base64url-encoded, partially signed by the fee payer\n},\n});\n// This call has no co-signer\nconst result2 = await sdk . solana . signAndSendTransaction ( otherTransaction );\nNever hold a fee payer keypair in frontend code. The presignTransaction callback runs in the browser — use it to call your own backend, which holds the keypair securely and returns the partially-signed transaction.\nTransaction examples\nSolana transaction examples\nThe SDK supports multiple Solana transaction libraries. Here are examples using both @solana/web3.js and @solana/kit :\nSolana with @solana/web3.js\nimport {\nVersionedTransaction ,\nTransactionMessage ,\nSystemProgram ,\nPublicKey ,\nLAMPORTS_PER_SOL ,\nConnection ,\n} from \"@solana/web3.js\" ;\nimport { BrowserSDK , AddressType } from \"@phantom/browser-sdk\" ;\nconst sdk = new BrowserSDK ({\nproviders: [ \"injected\" ],\naddressTypes: [ AddressType . solana ],\n});\nawait sdk . connect ({ provider: \"injected\" });\n// Get recent blockhash\nconst connection = new Connection ( \"https://api.mainnet-beta.solana.com\" );\nconst { blockhash } = await connection . getLatestBlockhash ();\n// Create transfer instruction\nconst fromAddress = await sdk . solana . getPublicKey ();\nconst transferInstruction = SystemProgram . transfer ({\nfromPubkey: new PublicKey ( fromAddress ),\ntoPubkey: new PublicKey ( toAddress ),\nlamports: 0.001 * LAMPORTS_PER_SOL ,\n});\n// Create VersionedTransaction\nconst messageV0 = new TransactionMessage ({\npayerKey: new PublicKey ( fromAddress ),\nrecentBlockhash: blockhash ,\ninstructions: [ transferInstruction ],\n}). compileToV0Message ();\nconst transaction = new VersionedTransaction ( messageV0 );\n// Send transaction using chain-specific API\nconst result = await sdk . solana . signAndSendTransaction ( transaction );\nconsole . log ( \"Transaction signature:\" , result . hash );\nSolana with @solana/kit\nimport {\ncreateSolanaRpc ,\npipe ,\ncreateTransactionMessage ,\nsetTransactionMessageFeePayer ,\nsetTransactionMessageLifetimeUsingBlockhash ,\naddress ,\ncompileTransaction ,\n} from \"@solana/kit\" ;\nimport { BrowserSDK , AddressType } from \"@phantom/browser-sdk\" ;\nconst sdk = new BrowserSDK ({\nproviders: [ \"injected\" ],\naddressTypes: [ AddressType . solana ],\n});\nawait sdk . connect ({ provider: \"injected\" });\n// Create transaction with @solana/kit\nconst rpc = createSolanaRpc ( \"https://api.mainnet-beta.solana.com\" );\nconst { value : latestBlockhash } = await rpc . getLatestBlockhash (). send ();\nconst userPublicKey = await sdk . solana . getPublicKey ();\nconst transactionMessage = pipe (\ncreateTransactionMessage ({ version: 0 }),\ntx => setTransactionMessageFeePayer ( address ( userPublicKey ), tx ),\ntx => setTransactionMessageLifetimeUsingBlockhash ( latestBlockhash , tx ),\n);\nconst transaction = compileTransaction ( transactionMessage );\n// Send using chain-specific API\nconst result = await sdk . solana . signAndSendTransaction ( transaction );\nconsole . log ( \"Transaction signature:\" , result . hash );\nDapp-sponsored transactions\nBy default, the user’s embedded wallet is the fee payer for all Solana transactions. The presignTransaction hook lets your app co-sign the transaction before the wallet signs it, enabling use cases like:\n- Dapp-as-fee-payer — your app covers the transaction fee so users don’t need SOL\n- Platform fees — add a fee instruction signed by your app’s keypair\n- Multi-signer flows — any scenario where the app needs to sign alongside the user’s wallet\nPhantom embedded wallets do not accept pre-signed transactions. If your use case requires a second signer, this hook is the only supported approach — your app’s signing must happen after Phantom has constructed and validated the transaction. This restriction does not apply to injected providers (e.g. the Phantom browser extension).\nPass presignTransaction directly to signAndSendTransaction for the specific calls that need it. Calls without it proceed normally — the function is never applied globally.\nExample: app as fee payer\nimport { base64urlDecode , base64urlEncode } from \"@phantom/browser-sdk\" ;\nimport { Keypair , VersionedTransaction } from \"@solana/web3.js\" ;\n// Your app's fee payer keypair (keep this on your backend in production)\nconst feePayerKeypair = Keypair . fromSecretKey ( /* your fee payer secret key */ );\n// This call co-signs as fee payer\nconst result = await sdk . solana . signAndSendTransaction ( transaction , {\npresignTransaction : async ( tx , context ) => {\n// tx: base64url-encoded Solana transaction bytes\n// context: { networkId: string, walletId: string }\n// 1. Decode base64url → raw bytes\nconst txBytes = base64urlDecode ( tx );\n// 2. Deserialize\nconst versionedTx = VersionedTransaction . deserialize ( txBytes );\n// 3. Partially sign as fee payer — the user's wallet will sign next\nversionedTx . sign ([ feePayerKeypair ]);\n// 4. Re-serialize → encode back to base64url\nreturn base64urlEncode ( versionedTx . serialize ());\n},\n});\n// This call has no presignTransaction — proceeds without any co-signing\nconst result2 = await sdk . solana . signAndSendTransaction ( otherTransaction );\nThe hook only fires for Solana transactions via the embedded provider. EVM transactions and injected providers are unaffected.\nEthereum transaction examples\nimport { BrowserSDK , AddressType } from \"@phantom/browser-sdk\" ;\nconst sdk = new BrowserSDK ({\nproviders: [ \"injected\" ],\naddressTypes: [ AddressType . ethereum ],\n});\nawait sdk . connect ({ provider: \"injected\" });\n// Simple ETH transfer\nconst result = await sdk . ethereum . sendTransaction ({\nto: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\" ,\nvalue: \"1000000000000000000\" , // 1 ETH in wei\ngas: \"21000\" ,\ngasPrice: \"20000000000\" , // 20 gwei\n});\n// EIP-1559 transaction with maxFeePerGas\nconst result2 = await sdk . ethereum . sendTransaction ({\nto: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\" ,\nvalue: \"1000000000000000000\" , // 1 ETH in wei\ndata: \"0x...\" , // contract call data\ngas: \"50000\" ,\nmaxFeePerGas: \"30000000000\" , // 30 gwei\nmaxPriorityFeePerGas: \"2000000000\" , // 2 gwei\n});\nconsole . log ( \"Transaction hash:\" , result . hash );\nEthereum with viem\nimport { parseEther , parseGwei , encodeFunctionData } from \"viem\" ;\nimport { BrowserSDK , AddressType } from \"@phantom/browser-sdk\" ;\nconst sdk = new BrowserSDK ({\nproviders: [ \"injected\" ],\naddressTypes: [ AddressType . ethereum ],\n});\n// Simple transfer with viem utilities\nconst result = await sdk . ethereum . sendTransaction ({\nto: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\" ,\nvalue: parseEther ( \"1\" ). toString (), // 1 ETH\ngas: \"21000\" ,\ngasPrice: parseGwei ( \"20\" ). toString (), // 20 gwei\n});\n// Contract interaction\nconst result2 = await sdk . ethereum . sendTransaction ({\nto: tokenContractAddress ,\ndata: encodeFunctionData ({\nabi: tokenAbi ,\nfunctionName: \"transfer\" ,\nargs: [ recipientAddress , parseEther ( \"100\" )],\n}),\ngas: \"50000\" ,\nmaxFeePerGas: parseGwei ( \"30\" ). toString (),\nmaxPriorityFeePerGas: parseGwei ( \"2\" ). toString (),\n});\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.optimism.io/llms.txt","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"c006e6c7e872e4cff5be13341984974fb9f11299f41fd45abe6e2e975f694e4a","tokens":9959,"chars":39834,"crawler":"crawler-f6nn","verified":"exact","ts":1791172218661,"text":"# Optimism Documentation\n- [OP Stack documentation](https://docs.optimism.io/index.md): Build apps on the OP Stack, deploy your own OP Stack chain, run a node, or learn how the protocol works.\n- [Use the Docs with AI](https://docs.optimism.io/ai-docs.md): Read the Optimism docs as an agent with llms.txt and per-page markdown, connect the hosted MCP server, and start from curated prompts.\n- [Chain operator quickstart](https://docs.optimism.io/chain-operators/quickstart.md): Launch a scalable and customizable Layer 2 Rollup blockchain with Ethereum-grade security - powered by Optimism.\n- [Choose how to run your chain](https://docs.optimism.io/chain-operators/launch-paths.md): The spectrum between running an OP Stack chain yourself and having it operated for you, and what your team owns at each point on it.\n- [Solution guides](https://docs.optimism.io/use-cases/index.md): Solution guides that sequence the OP Stack documentation into one paved path per real operator or developer goal.\n- [Tune batcher costs](https://docs.optimism.io/use-cases/tune-batcher-costs.md): Reduce what your OP Stack chain spends posting data to L1, and recover what you do spend, without breaking batch-submission safety limits.\n- [Run a fault-proof challenger](https://docs.optimism.io/use-cases/run-a-fault-proof-challenger.md): Stand up an op-challenger that defends your OP Stack chain, from bond budgeting and prestate selection through infrastructure, configuration, and monitoring.\n- [Implement a custom deposit flow](https://docs.optimism.io/use-cases/implement-a-custom-deposit-flow.md): Build an L1 to L2 deposit path for your application, choosing the right contract entry point and handling gas, aliasing, and failed messages.\n- [Launch a chain with fault proofs and HA sequencing](https://docs.optimism.io/use-cases/launch-a-chain-with-fault-proofs-and-ha-sequencing.md): Take an OP Stack chain to production with a working fault-proof system and a high-availability sequencer cluster, from contract deployment through failover drills.\n- [Choose your node stack](https://docs.optimism.io/use-cases/choose-your-node-stack.md): Pick the consensus and execution clients for an OP Stack node based on what the node is for, with review-dated support facts.\n- [Contribute to the docs](https://docs.optimism.io/op-stack/contribute/index.md): The contributor policies and content-type contracts for docs.optimism.io, routed by the task you came to do.\n- [Content guide](https://docs.optimism.io/op-stack/contribute/content-guide.md): What content belongs on docs.optimism.io, the canonical home for each content type, and how to mark third-party content.\n- [Cross-repo link policy](https://docs.optimism.io/op-stack/contribute/link-policy.md): The canonical form for every link from docs.optimism.io into the specs, source repositories, and other pages — and the linter that enforces it.\n- [Curation review policy](https://docs.optimism.io/op-stack/contribute/curation-policy.md): The review cadence for curated pages, the last-reviewed frontmatter contract, the sweep that keeps curated content fresh, and the rule for delisting what rots.\n- [Learn track syllabus](https://docs.optimism.io/op-stack/contribute/learn-track-syllabus.md): The governance artifact for the \"Learn the OP Stack\" track, including its scope contract, curriculum owner, stop list with rationale, design rules, and changelog.\n- [Style guide](https://docs.optimism.io/op-stack/contribute/style-guide.md): How to write technical content for Optimism Docs with a consistent voice, tone, and style.\n- [Choose a content type](https://docs.optimism.io/op-stack/contribute/choose-a-content-type.md): A maintainer-facing decision table for picking the right documentation type, composition, and operational metadata.\n- [Content type: solution guide](https://docs.optimism.io/op-stack/contribute/solution-guide.md): The published contract for solution guides — purpose, tone, required components, title grammar, and a copy-paste template.\n- [Content type: learning unit](https://docs.optimism.io/op-stack/contribute/learning-unit.md): The published contract for learning units — purpose, tone, required components, title grammar, and copy-paste templates for both forms.\n- [Content type: curriculum hub](https://docs.optimism.io/op-stack/contribute/curriculum-hub.md): The published contract for curriculum hubs — purpose, tone, required components, title grammar, and a copy-paste template.\n- [Content type: router/landing](https://docs.optimism.io/op-stack/contribute/router-landing.md): The published contract for router and landing pages — purpose, tone, required components, title grammar, and a copy-paste template.\n- [Content type: notice](https://docs.optimism.io/op-stack/contribute/notice.md): The published contract for time-bound network notices, including required persona impacts, actions, timing, and a copy-paste template.\n- [Component hub template](https://docs.optimism.io/op-stack/contribute/component-hub-template.md): The uniform skeleton every OP Stack component hub page follows, with guidance for each section.\n- [Chain operators](https://docs.optimism.io/chain-operators/index.md): Routes chain operators to the quickstart, guides, tutorials, tools, and reference for launching and running an OP Stack chain.\n- [Chain Operator Configurations](https://docs.optimism.io/chain-operators/guides/configuration/getting-started.md): Learn how to configure an OP Stack chain.\n- [Configure the batcher](https://docs.optimism.io/chain-operators/guides/configuration/batcher.md): Learn how to configure the op-batcher for your chain, covering the batcher policy, cost tuning, multi-blob transactions, and sequencer throttling.\n- [Proposer Configuration](https://docs.optimism.io/chain-operators/guides/configuration/proposer.md): Reference for the op-proposer configuration options and the proposer policy constraints.\n- [How to configure challenger for your chain](https://docs.optimism.io/chain-operators/guides/configuration/op-challenger-config-guide.md): Learn how to configure challenger for your OP Stack chain.\n- [Deploy a Custom Gas Token chain](https://docs.optimism.io/chain-operators/guides/features/custom-gas-token-guide.md): Learn how to deploy a Custom Gas Token chain using OP Deployer.\n- [Switch to Kona Proofs](https://docs.optimism.io/chain-operators/guides/features/switching-to-kona-proofs.md): Learn how to switch your OP Stack chain to use Kona-based fault proofs as the respected game type.\n- [Set the Minimum Base Fee](https://docs.optimism.io/chain-operators/guides/features/setting-min-base-fee.md): Learn how to set a minimum base fee on your OP-Stack Chain\n- [Set the Operator Fee](https://docs.optimism.io/chain-operators/guides/features/setting-operator-fee.md): Learn how to configure the operator fee on your OP Stack Chain\n- [Set the DA Footprint Gas Scalar](https://docs.optimism.io/chain-operators/guides/features/setting-da-footprint.md): Learn how to set a Data Availability (DA) Footprint on your OP-Stack Chain\n- [Enabling Subblocks](https://docs.optimism.io/chain-operators/guides/features/subblocks-guide.md): Learn about enabling Subblocks on an OP Stack chain.\n- [Enabling Sequencer Defined Metering](https://docs.optimism.io/chain-operators/guides/features/sequencer-defined-metering.md): Turn Sequencer Defined Metering on or off on an OP Stack sequencer, and confirm which gate is holding it back.\n- [How to run an Alt-DA mode chain](https://docs.optimism.io/chain-operators/guides/features/alt-da-mode-guide.md): Learn how to configure and run an Alt-DA mode chain within the OP Stack.\n- [Post batch data as blobs](https://docs.optimism.io/chain-operators/guides/features/blobs.md): Learn how to switch your chain's batcher to posting batch data as blobs.\n- [Enable span batches](https://docs.optimism.io/chain-operators/guides/features/enable-span-batches.md): Learn how to enable span batches on your OP Stack chain by confirming Delta activation and configuring the batch type on op-batcher.\n- [Using snap sync for chain operators](https://docs.optimism.io/chain-operators/guides/features/snap-sync.md): Learn how to enable snap sync on your OP Stack chain.\n- [Chain operator best practices](https://docs.optimism.io/chain-operators/guides/management/best-practices.md): Learn some best practices for managing the OP Stack's off-chain components.\n- [Network Design Example](https://docs.optimism.io/chain-operators/guides/management/network-architecture.md): This document describes an example network configuration for an OP Stack chain deployment.\n- [Changing gas target/limit](https://docs.optimism.io/chain-operators/guides/management/gas-target-limit.md): Learn how to change the gas target and limit on your OP Stack chain.\n- [Key management](https://docs.optimism.io/chain-operators/guides/management/key-management.md): Understand the key management considerations for a chain's privileged roles: which keys must stay online as hot wallets, which belong in cold wallets, and where HSMs and multisigs fit.\n- [Rollup operations](https://docs.optimism.io/chain-operators/guides/management/operations.md): Learn basics of rollup operations, such as how to start and stop your rollup, get your rollup config, and how to add nodes.\n- [Transaction Fees 101](https://docs.optimism.io/chain-operators/guides/management/transaction-fees-101.md): How to check and tune the fee parameters on your OP Stack chain, with example scenarios for common situations.\n- [Fee vault operations](https://docs.optimism.io/chain-operators/guides/management/fee-vaults.md): How to configure, monitor, and withdraw from fee vaults on your OP Stack chain.\n- [Troubleshooting chain operations](https://docs.optimism.io/chain-operators/guides/management/troubleshooting.md): Learn solutions to common problems when troubleshooting chain operations.\n- [Join the Superchain Registry](https://docs.optimism.io/chain-operators/guides/join-superchain-registry.md): How to add your OP Stack chain to the Superchain Registry — prerequisites, config generation, and the pull-request process.\n- [Creating your own L2 rollup testnet](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/index.md): Learn how to deploy and orchestrate all OP Stack components for a complete testnet deployment.\n- [Deploy L1 contracts with op-deployer](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-deployer-setup.md): Install op-deployer, prepare your environment, and deploy the L1 smart contracts for your rollup.\n- [Spin up sequencer](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-reth-setup.md): Set up and run op-reth and op-node, the execution and consensus layers for your rollup.\n- [Spin up batcher](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-batcher-setup.md): Learn how to set up and configure an OP Stack batcher to submit L2 transaction batches to L1.\n- [Spin up proposer](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-proposer-setup.md): Learn how to set up and configure an OP Stack proposer to post L2 state roots.\n- [Spin up challenger](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.md): Learn how to configure challenger for your OP Stack chain.\n- [L2 Rollup Code Examples](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/code-setup.md): Complete working code examples for the Create L2 Rollup tutorial\n- [Upgrade L1 contracts using op-deployer](https://docs.optimism.io/chain-operators/tutorials/l1-contract-upgrades/op-deployer-upgrade.md): Version availability and migration paths for the op-deployer upgrade command, which supports L1 contract upgrades up to op-contracts/v5.0.0.\n- [Upgrade using superchain-ops](https://docs.optimism.io/chain-operators/tutorials/l1-contract-upgrades/superchain-ops-guide.md): Upgrade your chain's L1 contracts with superchain-ops by creating a task from a template, configuring and simulating it, then executing it or submitting it for review.\n- [Upgrading Smart Contracts from v1.3.0 to v1.8.0](https://docs.optimism.io/chain-operators/tutorials/l1-contract-upgrades/upgrade-op-contracts-1-3-1-8.md): Upgrade your OP Stack chain's L1 contracts from op-contracts/v1.3.0 to v1.8.0, moving from the L2 Output Oracle to the permissioned Fault Proof System.\n- [Adding a precompile](https://docs.optimism.io/chain-operators/tutorials/adding-precompiles.md): Learn how to run an EVM with a new precompile for OP Stack chain operations to speed up calculations that are not currently supported.\n- [Modifying predeployed contracts](https://docs.optimism.io/chain-operators/tutorials/modifying-predeploys.md): Learn how to modify predeployed contracts for an OP Stack chain by upgrading the proxy.\n- [Adding attributes to the derivation function](https://docs.optimism.io/chain-operators/tutorials/adding-derivation-attributes.md): Learn how to modify the derivation function for an OP Stack chain to track the amount of ETH being burned on L1.\n- [Integrating a new DA layer with Alt-DA](https://docs.optimism.io/chain-operators/tutorials/integrating-da-layer.md): Learn how to add support for a new DA Layer within the OP Stack.\n- [Generating absolute prestate and preimage files](https://docs.optimism.io/chain-operators/tutorials/absolute-prestate.md): Generate, verify, and configure the kona-client absolute prestate for permissionless fault proofs.\n- [Generating a custom kona-client absolute prestate](https://docs.optimism.io/chain-operators/tutorials/kona-custom-prestate.md): How to build a kona-client absolute prestate that embeds a chain configuration not yet in the public Superchain Registry.\n- [Deploying new dispute games with OPCM](https://docs.optimism.io/chain-operators/tutorials/dispute-games.md): Learn how to deploy new dispute games to an OP Stack chain using OPCM\n- [Migrating to permissionless fault proofs on OP Stack](https://docs.optimism.io/chain-operators/tutorials/migrating-permissionless.md): Migrate your OP Stack chain from permissioned to permissionless fault proofs: configure the dispute components, deploy the contracts with OPCM, test the off-chain agents, and switch the respected game type.\n- [Merging Two Chains Into a Shared Dispute Game](https://docs.optimism.io/chain-operators/tutorials/merge-shared-dispute-game.md): Merge two pre-interop OP Stack chains into a shared DisputeGameFactory and AnchorStateRegistry with opcm.migrate, then cut over op-proposer, op-challenger, and op-dispute-mon to the shared factory.\n- [How to rewind op-geth](https://docs.optimism.io/chain-operators/tutorials/rewind-op-geth.md): Learn how to rewind an op-geth node to a previous chain head.\n- [Upgrading a Chain From Output Roots to Super Roots](https://docs.optimism.io/chain-operators/tutorials/upgrade-chain-to-super-roots.md): Upgrade an OP Stack chain from output-root dispute games to super-root dispute games with a single opcm.upgrade call, then cut op-proposer, op-challenger, and op-dispute-mon over to super roots.\n- [Chain monitoring options](https://docs.optimism.io/chain-operators/tools/chain-monitoring.md): Learn about onchain and offchain monitoring options for your OP Stack chain.\n- [Blockscout block explorer](https://docs.optimism.io/chain-operators/tools/explorer.md): Blockscout an open source block explorer for the OP Stack.\n- [OP Conductor](https://docs.optimism.io/chain-operators/tools/op-conductor.md): Understand how op-conductor keeps an OP Stack sequencer highly available, the guarantees it provides, and how its Raft-based design works.\n- [Setup](https://docs.optimism.io/chain-operators/tools/op-conductor/setup.md): Add op-conductor to an existing multi-sequencer OP Stack network without downtime.\n- [Configuration and RPCs](https://docs.optimism.io/chain-operators/tools/op-conductor/reference.md): Reference for op-conductor configuration flags, environment variables, and conductor namespace RPC methods.\n- [OP Deployer](https://docs.optimism.io/chain-operators/tools/op-deployer/overview.md): A CLI tool for deploying and upgrading smart contracts for OP Stack chains.\n- [Install op-deployer](https://docs.optimism.io/chain-operators/tools/op-deployer/installation.md): Learn how to install op-deployer from pre-built binaries or from source.\n- [Bootstrap Commands](https://docs.optimism.io/chain-operators/tools/op-deployer/usage/bootstrap.md): Learn how to deploy global singletons and implementation contracts for new OP Stack deployments.\n- [Init Command](https://docs.optimism.io/chain-operators/tools/op-deployer/usage/init.md): Learn how to initialize intent and state files for your OP Stack deployment.\n- [Apply Command](https://docs.optimism.io/chain-operators/tools/op-deployer/usage/apply.md): Learn how to deploy your OP Chain based on the intent file.\n- [Verify Command](https://docs.optimism.io/chain-operators/tools/op-deployer/usage/verify.md): Learn how to verify deployed contract source code on block explorers.\n- [Custom Deployments](https://docs.optimism.io/chain-operators/tools/op-deployer/usage/custom-deployments.md): Learn how to manage custom deployments with OP Deployer.\n- [Release Workflows](https://docs.optimism.io/chain-operators/tools/op-deployer/usage/release-workflows.md): Learn how to backport fixes onto earlier OP Deployer versions and add support for new contract versions.\n- [Known Limitations](https://docs.optimism.io/chain-operators/tools/op-deployer/known-limitations.md): Known limitations and workarounds for OP Deployer.\n- [Architecture](https://docs.optimism.io/chain-operators/tools/op-deployer/reference/architecture/overview.md): Understand OP Deployer's architecture and internals.\n- [Deployment Pipeline](https://docs.optimism.io/chain-operators/tools/op-deployer/reference/architecture/pipeline.md): Understand how OP Deployer's pipeline is architected: the intent and state files it consumes and produces, and what each deployment stage is responsible for.\n- [Scripting Engine](https://docs.optimism.io/chain-operators/tools/op-deployer/reference/architecture/engine.md): Understand OP Deployer's in-memory EVM scripting engine: what it enables, why on-chain interactions run through Solidity scripts, and how Go code communicates with scripts inside the simulated EVM.\n- [Artifacts Locators](https://docs.optimism.io/chain-operators/tools/op-deployer/reference/artifacts-locators.md): Learn how OP Deployer uses artifacts locators to point to contract artifacts.\n- [op-deployer versioning and releases](https://docs.optimism.io/chain-operators/tools/op-deployer/reference/releases.md): Reference for where to find OP Deployer releases and how each OP Deployer version maps to a supported contract release.\n- [OP Interop Filter](https://docs.optimism.io/chain-operators/tools/op-interop-filter.md): Learn how op-interop-filter validates interop executing messages so the execution layer can reject invalid cross-chain transactions before they reach the sequencer.\n- [OP Txproxy](https://docs.optimism.io/chain-operators/tools/op-txproxy.md): A passthrough proxy service that can apply additional constraints on transactions prior to reaching the sequencer.\n- [Run proxyd](https://docs.optimism.io/chain-operators/tools/proxyd.md): Learn how to build, configure, and run proxyd, the OP Stack RPC request router and proxy.\n- [Batcher configuration reference](https://docs.optimism.io/chain-operators/reference/batcher-configuration.md): Reference for all op-batcher configuration options, covering CLI flags, environment variables, and default values.\n- [Challenger configuration reference](https://docs.optimism.io/chain-operators/reference/challenger-configuration.md): Reference for all op-challenger configuration options, covering CLI flags, environment variables, and default values.\n- [OP Contracts Manager](https://docs.optimism.io/chain-operators/reference/opcm.md): Understand what OP Contracts Manager is, why it exists, and how it deploys and upgrades the L1 contracts for OP Stack chains in a single transaction.\n- [Rollup deployment configuration](https://docs.optimism.io/chain-operators/reference/rollup-deployment-configuration.md): Reference for the OP Stack rollup deployment configuration values.\n- [Fee parameters](https://docs.optimism.io/chain-operators/reference/fee-parameters.md): Reference for the fee-related SystemConfig parameters on an OP Stack chain — what each parameter controls, its setter and getter, and the OP Mainnet values.\n- [How the DA footprint block limit works](https://docs.optimism.io/chain-operators/reference/da-footprint.md): Understand the Data Availability (DA) footprint block limit introduced in the Jovian hardfork, how the DA footprint is calculated, and why the default gas scalar is 400.\n- [Generating an op-program absolute prestate (archived)](https://docs.optimism.io/chain-operators/tutorials/archive/op-program-prestate.md): Archived: legacy op-program prestate generation flow for chains resolving in-flight CANNON game type 1 disputes.\n- [Node Operator Overview](https://docs.optimism.io/node-operators/overview.md): Learn about running nodes on OP Stack networks.\n- [Consensus client configuration](https://docs.optimism.io/node-operators/guides/configuration/consensus-clients.md): Learn how to configure consensus clients (op-node, kona-node) for your OP Stack node.\n- [Execution client configuration](https://docs.optimism.io/node-operators/guides/configuration/execution-clients.md): Configure op-reth as your OP Stack execution client and migrate off end-of-support op-geth.\n- [Supernode setup](https://docs.optimism.io/node-operators/guides/configuration/supernode-setup.md): Stand up op-supernode end to end - build the binary, wire each chain's engine API, start the process, and verify every chain is syncing.\n- [Supernode configuration](https://docs.optimism.io/node-operators/guides/configuration/supernode.md): Learn how to configure op-supernode to run every chain in an interop dependency set in one process.\n- [Running an archive node](https://docs.optimism.io/node-operators/guides/management/archive-node.md): Learn how to configure and run an archive node.\n- [Fetch blob data for your node](https://docs.optimism.io/node-operators/guides/management/blobs.md): Configure op-node to fetch L1 batcher blob data, including blobs older than the beacon retention window.\n- [Restore a Node From a Snapshot](https://docs.optimism.io/node-operators/guides/management/restore-from-snapshot.md): Download, verify, and extract a snapshot into your node's data directory to skip the initial sync.\n- [Node Metrics and Monitoring](https://docs.optimism.io/node-operators/guides/monitoring/metrics.md): Learn about the different metrics you can use to monitor the health of your node.\n- [Node Troubleshooting](https://docs.optimism.io/node-operators/guides/troubleshooting.md): Learn solutions to common problems to troubleshoot your node.\n- [Running a Node With Docker](https://docs.optimism.io/node-operators/tutorials/node-from-docker.md): Run an OP Stack node (op-reth + op-node) using the official Docker images and docker-compose.\n- [Building and running an OP Stack node from source](https://docs.optimism.io/node-operators/tutorials/run-node-from-source.md): Build and run an OP Stack node (op-reth + op-node) from source code for full nodes and archive nodes.\n- [Running op-reth with Historical Proofs](https://docs.optimism.io/node-operators/tutorials/reth-historical-proofs.md): Configure op-reth's proofs-history (v2) store to serve efficient historical eth_getProof responses for permissionless withdrawal proving.\n- [System Requirements](https://docs.optimism.io/node-operators/kona-node/requirements.md)\n- [Install kona-node](https://docs.optimism.io/node-operators/kona-node/install/overview.md): Prerequisites and the three ways to obtain kona-node: Docker images, pre-built binaries, or building from source.\n- [Building from Source](https://docs.optimism.io/node-operators/kona-node/install/source.md)\n- [Run a Node](https://docs.optimism.io/node-operators/kona-node/run/overview.md)\n- [Run Kona Node as a Binary](https://docs.optimism.io/node-operators/kona-node/run/binary.md): Run the kona-node binary against an op-reth execution client, from starting both clients to watching the node sync.\n- [Docker Guide](https://docs.optimism.io/node-operators/kona-node/run/docker.md): Run kona-node with op-reth using Kona's pre-packaged docker-compose setup, including Grafana dashboards and Prometheus.\n- [How it Works](https://docs.optimism.io/node-operators/kona-node/run/mechanics.md)\n- [Configure RPC Trust](https://docs.optimism.io/node-operators/kona-node/run/rpc-trust.md): Decide when to enable RPC response verification on kona-node and configure the --l1-trust-rpc and --l2-trust-rpc flags for trusted and untrusted providers.\n- [Run a Sequencer Node](https://docs.optimism.io/node-operators/kona-node/run/sequencer.md): Run kona-node in sequencer mode from the command line, including required arguments, sequencer-specific flags, and example configurations.\n- [JSON-RPC](https://docs.optimism.io/node-operators/kona-node/rpc/overview.md)\n- [P2P RPC Methods](https://docs.optimism.io/node-operators/kona-node/rpc/p2p.md)\n- [Rollup RPC Methods](https://docs.optimism.io/node-operators/kona-node/rpc/rollup.md)\n- [Admin RPC Methods](https://docs.optimism.io/node-operators/kona-node/rpc/admin.md)\n- [Kona Node CLI Reference](https://docs.optimism.io/node-operators/kona-node/configuration.md): Reference for all kona-node CLI flags and environment variables, grouped by category, plus default ports and default runtime behavior.\n- [Monitoring](https://docs.optimism.io/node-operators/kona-node/monitoring.md): Set up logging, Prometheus metrics, and Grafana dashboards for kona-node.\n- [`kona-node` Subcommands](https://docs.optimism.io/node-operators/kona-node/subcommands.md)\n- [FAQ](https://docs.optimism.io/node-operators/kona-node/faq/overview.md)\n- [Node Ports](https://docs.optimism.io/node-operators/kona-node/faq/ports.md)\n- [Node Design Overview](https://docs.optimism.io/node-operators/kona-node/design/intro.md)\n- [Derivation in Kona Node](https://docs.optimism.io/node-operators/kona-node/design/derivation.md)\n- [Execution Engine](https://docs.optimism.io/node-operators/kona-node/design/engine.md)\n- [P2P Networking](https://docs.optimism.io/node-operators/kona-node/design/p2p.md)\n- [Sequencer Mode](https://docs.optimism.io/node-operators/kona-node/design/sequencer.md): Understand how the kona-node sequencer actor builds L2 blocks, and the trait abstractions and programmatic configuration behind sequencer mode.\n- [op-reth for node operators](https://docs.optimism.io/node-operators/op-reth/index.md): op-reth is the OP Stack execution client built on reth. Start here to run it alongside a rollup node and to find its CLI reference.\n- [Sync OP Mainnet](https://docs.optimism.io/node-operators/op-reth/run/faq/sync-op-mainnet.md): Syncing op-reth with OP Mainnet and Bedrock state.\n- [Node architecture](https://docs.optimism.io/node-operators/reference/architecture/index.md): Understand how the components of an OP Stack node fit together.\n- [op-node configuration options](https://docs.optimism.io/node-operators/reference/op-node-config.md): Complete reference for all op-node command-line flags and environment variables.\n- [op-node JSON-RPC API](https://docs.optimism.io/node-operators/reference/op-node-json-rpc.md): Complete reference for op-node RPC methods including rollup-specific functionality.\n- [op-supernode configuration options](https://docs.optimism.io/node-operators/reference/op-supernode-config.md): Complete reference for all op-supernode command-line flags and environment variables.\n- [op-reth configuration options](https://docs.optimism.io/node-operators/reference/op-reth-config.md): Where to find the op-reth CLI reference, and how op-reth pairs with op-node.\n- [op-reth JSON-RPC API](https://docs.optimism.io/node-operators/reference/op-reth-json-rpc.md): Complete reference for op-reth execution client RPC methods with OP Stack enhancements.\n- [op-reth historical proof configuration](https://docs.optimism.io/node-operators/reference/op-reth-historical-proof-config.md): Configuration options for the op-reth historical proof store (v2).\n- [Consensus-layer sync](https://docs.optimism.io/node-operators/reference/consensus-layer-sync.md): Learn about the consensus-layer sync mode.\n- [Understanding the op-reth CLI](https://docs.optimism.io/node-operators/op-reth/cli/overview.md): Understand how the op-reth command-line interface is organized, how chain selection works through the Superchain Registry, and where configuration values come from.\n- [op-reth](https://docs.optimism.io/node-operators/op-reth/cli/op-reth.md)\n- [op-reth node](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/node.md)\n- [op-reth init](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/init.md)\n- [op-reth init-state](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/init-state.md)\n- [op-reth import-op](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/import-op.md)\n- [op-reth import-receipts-op](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/import-receipts-op.md)\n- [op-reth dump-genesis](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/dump-genesis.md)\n- [op-reth db](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db.md)\n- [op-reth db stats](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/stats.md)\n- [op-reth db list](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/list.md)\n- [op-reth db checksum](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/checksum.md)\n- [op-reth db checksum mdbx](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/checksum/mdbx.md)\n- [op-reth db checksum static-file](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/checksum/static-file.md)\n- [op-reth db checksum rocksdb](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/checksum/rocksdb.md)\n- [op-reth db copy](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/copy.md)\n- [op-reth db diff](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/diff.md)\n- [op-reth db get](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/get.md)\n- [op-reth db get mdbx](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/get/mdbx.md)\n- [op-reth db get static-file](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/get/static-file.md)\n- [op-reth db get rocksdb](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/get/rocksdb.md)\n- [op-reth db drop](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/drop.md)\n- [op-reth db clear](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/clear.md)\n- [op-reth db clear mdbx](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/clear/mdbx.md)\n- [op-reth db clear static-file](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/clear/static-file.md)\n- [op-reth db repair-trie](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/repair-trie.md)\n- [op-reth db static-file-header](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/static-file-header.md)\n- [op-reth db static-file-header block](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/static-file-header/block.md)\n- [op-reth db static-file-header path](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/static-file-header/path.md)\n- [op-reth db version](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/version.md)\n- [op-reth db path](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/path.md)\n- [op-reth db settings](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/settings.md)\n- [op-reth db settings get](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/settings/get.md)\n- [op-reth db settings set](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/settings/set.md)\n- [op-reth db settings set v2](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/settings/set/v2.md)\n- [op-reth db prune-checkpoints](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/prune-checkpoints.md)\n- [op-reth db prune-checkpoints get](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/prune-checkpoints/get.md)\n- [op-reth db prune-checkpoints set](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/prune-checkpoints/set.md)\n- [op-reth db stage-checkpoints](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/stage-checkpoints.md)\n- [op-reth db stage-checkpoints get](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/stage-checkpoints/get.md)\n- [op-reth db stage-checkpoints set](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/stage-checkpoints/set.md)\n- [op-reth db account-storage](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/account-storage.md)\n- [op-reth db state](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/state.md)\n- [op-reth db migrate-v2](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/db/migrate-v2.md)\n- [op-reth stage](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage.md)\n- [op-reth stage run](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/run.md)\n- [op-reth stage drop](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/drop.md)\n- [op-reth stage dump](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/dump.md)\n- [op-reth stage dump execution](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/dump/execution.md)\n- [op-reth stage dump storage-hashing](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/dump/storage-hashing.md)\n- [op-reth stage dump account-hashing](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/dump/account-hashing.md)\n- [op-reth stage dump merkle](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/dump/merkle.md)\n- [op-reth stage unwind](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/unwind.md)\n- [op-reth stage unwind to-block](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/unwind/to-block.md)\n- [op-reth stage unwind num-blocks](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/stage/unwind/num-blocks.md)\n- [op-reth p2p](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/p2p.md)\n- [op-reth p2p header](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/p2p/header.md)\n- [op-reth p2p body](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/p2p/body.md)\n- [op-reth p2p rlpx](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/p2p/rlpx.md)\n- [op-reth p2p rlpx ping](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/p2p/rlpx/ping.md)\n- [op-reth p2p bootnode](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/p2p/bootnode.md)\n- [op-reth p2p enode](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/p2p/enode.md)\n- [op-reth config](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/config.md)\n- [op-reth prune](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/prune.md)\n- [op-reth re-execute](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/re-execute.md)\n- [op-reth proofs](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs.md)\n- [op-reth proofs init](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs/init.md)\n- [op-reth proofs backfill](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs/backfill.md)\n- [op-reth proofs prune](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs/prune.md)\n- [op-reth proofs snapshot](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs/snapshot.md)\n- [op-reth proofs snapshot init](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs/snapshot/init.md)\n- [op-reth proofs snapshot drop](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs/snapshot/drop.md)\n- [op-reth proofs unwind](https://docs.optimism.io/node-operators/op-reth/cli/op-reth/proofs/unwind.md)\n- [App developers](https://docs.optimism.io/app-developers/index.md): Routes app developers to the quickstarts, guides, tutorials, tools, and reference for building on OP Mainnet and other OP Stack chains.\n- [App developer quickstart](https://docs.optimism.io/app-developers/quickstarts/get-started.md): Get testnet ETH, deploy your first contract to OP Sepolia, and bridge assets - your first steps on the Superchain.\n- [Integrating DeFi with Actions SDK](https://docs.optimism.io/app-developers/quickstarts/actions.md): Perform DeFi actions with lightweight, composable, and type-safe modules.\n- [Building apps on OP Stack chains](https://docs.optimism.io/app-developers/guides/building-apps.md): Learn the basics of building apps on OP Stack chains.\n- [Testing apps for OP Stack chains](https://docs.optimism.io/app-developers/guides/testing-apps.md): Learn best practices for testing apps on OP Stack chains.\n- [Configuring Actions SDK](https://docs.optimism.io/app-developers/guides/configuring-actions.md): Learn how to configure Actions SDK for your application.\n- [Connecting a wallet to Actions SDK](https://docs.optimism.io/app-developers/guides/connect-wallet-to-actions.md): Connect an embedded provider wallet to Actions SDK so it can perform DeFi actions like Lend, Borrow, Swap, and Pay.\n- [Bridging basics](https://docs.optimism.io/app-developers/guides/bridging/basics.md): Learn about the fundamentals of sending data and tokens between Ethereum and OP Mainnet.\n- [Custom bridges](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge.md): Important considerations when building custom bridges for OP Mainnet.\n- [Sending data between L1 and L2](https://docs.optimism.io/app-developers/guides/bridging/messaging.md): Understand how bridging between L1 and L2 works, the messenger contracts that carry messages, what messages cost, and why the challenge period exists.\n- [Using the Standard Bridge](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge.md): Learn how the Standard Bridge moves ETH and ERC-20 tokens between Layer 1 and Layer 2.\n- [Verifying bridged token addresses](https://docs.optimism.io/app-developers/guides/bridging/verify-bridged-tokens.md): Use the Superchain Token List to find and verify the correct bridged representation of a token before using the Standard Bridge.\n- [Build interoperable apps on OP Stack devnet](https://docs.optimism.io/app-developers/guides/interoperability/get-started.md): Learn about deploying contracts, cross-chain messaging, and tutorials to help you build applications on OP Stack chains.\n- [Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing.md): Understand how interop message passing works, from the initiating message on the source chain to the executing message on the destination chain.\n- [Reading Logs with OP Stack Interop](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs.md): Understand how contracts use CrossL2Inbox to validate logs from other interop chains, and how this pull model differs from sending messages.\n- [Message expiration](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration.md): What message expiration is, why it exists, and how to reemit a previously sent message if it has expired and was never relayed.\n- [Estimating transaction fees on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/estimates.md): Learn how to properly estimate the total cost of a transaction on OP Mainnet."}
{"url":"https://docs.monad.xyz/guides/build-with-nfts","domain":"docs.monad.xyz","title":"Build with NFTs - Monad Documentation","hash":"9ef6b6a43c6ba51bc45feeb0074c836e1078b2f02c27dd5427846966f7257794","tokens":1598,"chars":6389,"crawler":"crawler-f6nn","verified":"exact","ts":1791172221297,"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\nBuild with NFTs\nHow to build an NFT project on Monad: standards, a deploy quickstart, and the tooling for minting, marketplaces, indexing, wallets, and more.\nMonad is fully EVM-compatible, so the NFT stack you already know works unchanged. Its high throughput and low fees also make mint-heavy and fully onchain NFTs practical.\nWhat you can build\nAnything you can build on an EVM chain, plus a few things that are only comfortable when blockspace is cheap and fast:\n- Collections and PFPs : standard ERC-721/1155 drops, allowlists, and reveals.\n- Fully onchain and dynamic NFTs : store art or state onchain and mutate metadata on interaction.\n- High-frequency mints : large collections and open editions that would be prohibitively expensive elsewhere.\n- Game and app assets : items, passes, and rewards that live onchain.\n- Token-bound accounts : give each NFT its own wallet with ERC-6551 .\nNFT standards\nMonad executes standard EVM bytecode, so the usual standards and libraries work with no changes:\n- ERC-721 : the base non-fungible token standard.\n- ERC-1155 : multi-token standard for editions and semi-fungible items.\n- ERC-721A : gas-optimized ERC-721 for cheap batch mints.\n- EIP-2981 : onchain royalty signaling. As on every chain, royalties are read by marketplaces, and enforcement is marketplace-dependent.\n- ERC-6551 : token-bound accounts that let each NFT own assets, interact with contracts, and maintain its own onchain identity.\nSome popular implementations: OpenZeppelin , thirdweb , solady , or ERC721A .\nExperimental primitives include ERC-404 (an unofficial mixed token hybrid) and DN-404 (a linked ERC-20/721 pair). Deployable, Monad-configured examples of both are in monad-developers/erc404-dn404-monad .\nQuickstart: deploy a collection\nDeploy a minimal ERC-721 to Monad Testnet with Foundry .\nPrerequisites: Foundry installed, and a funded testnet account. Monad Testnet is chain ID 10143 and mainnet is 143 . Get testnet funds and RPC endpoints from the Testnet page.\nSet up the project and add OpenZeppelin:\nforge init my-collection && cd my-collection\nforge install OpenZeppelin/openzeppelin-contracts\nWrite the contract:\nsrc/MyCollection.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24 ;\nimport { ERC721 } from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\" ;\nimport { Ownable } from \"@openzeppelin/contracts/access/Ownable.sol\" ;\ncontract MyCollection is ERC721 , Ownable {\nuint256 public nextId;\nconstructor () ERC721 (\"My Collection\", \"MYC\") Ownable (msg.sender) {}\nfunction mint ( address to ) external onlyOwner {\n_safeMint (to, nextId ++ );\n}\nfunction _baseURI () internal pure override returns ( string memory ) {\nreturn \"ipfs://YOUR_CID/\" ;\n}\nDeploy it:\nforge create src/MyCollection.sol:MyCollection \\\n--rpc-url https://testnet-rpc.monad.xyz \\\n--private-key $PRIVATE_KEY \\\n--broadcast\nFund the deploying account before you deploy. Get testnet MON from the faucet linked on the Testnet page.\nThen mint the first token:\ncast send < COLLECTION_ADDRES S > \"mint(address)\" < YOUR_ADDRES S > \\\n--rpc-url https://testnet-rpc.monad.xyz \\\n--private-key $PRIVATE_KEY\nThat is a working collection. From here you can swap in an allowlist, a public mint price, or a batch-mint standard like ERC-721A, and wire in the tooling below.\nChoose your tooling\nEverything an NFT project needs is live on Monad. Pick per layer.\nMinting and launchpads\nNo-code tools to create, deploy, and manage a collection:\n- Scatter : artist-first launchpad that deploys fully-owned ERC-721A/1155 collections through low-fee contract factories.\n- thirdweb : prebuilt Drop contracts and a claim UI.\nMarketplaces\nList and trade on marketplaces live on Monad:\n- OpenSea : including SeaDrop for primary mints.\n- Scatter : buy and sell collections, compatible with other NFT marketplaces.\nIndexing and NFT APIs\nRead balances, ownership, metadata, and transfer history without running your own indexer, with providers like Rarible and thirdweb Insight. See Indexers for the full list and for building custom transfer indexes.\nWallets and onboarding\nEmbedded wallets and account abstraction let users mint with an email or social login. With smart accounts and a paymaster you can sponsor gasless mints . See Wallet infrastructure .\nRandomness (fair mints and reveals)\nFor provably fair mint order and trait reveals, use a verifiable random function (VRF). See Oracles .\nToken-bound accounts (ERC-6551)\nThe canonical Tokenbound stack (registry, account proxy, and implementation) is deployed on Monad at the same addresses as every other EVM chain, so the SDK’s default flow works out of the box. See Get started with ERC-6551 .\nMetadata and storage\nMetadata works the same as anywhere on EVM: point tokenURI at a stable location. For decentralized permanence, pin your files and JSON to IPFS or Arweave (for example Pinata, thirdweb Storage, or Irys) and reference them with ipfs:// URIs. Freeze metadata once revealed so collectors can trust it will not change.\nWhat minting costs\nMinting on Monad is efficient. A mint costs its gas usage times the network base fee (typically about 100 gwei), paid in MON:\ntotal cost (MON) = number of NFTs x gas per mint x base fee\nTypical gas per mint:\n- Gas-optimized batch mint (ERC-721A): about 40,000 gas\n- Standard ERC-721 mint: about 85,000 gas\nUse the estimator to size a specific drop. It computes cost in MON from the gas and base fee, which is always accurate, and can pull the live MON price for an optional USD figure.\nAt a base fee of 100 gwei, minting out a full 10,000-item collection uses on the order of 40 to 85 MON in total gas, and deploying the contract is a one-time cost of roughly 0.25 MON. Each individual mint costs a negligible amount, which is what makes large drops, open editions, and fully onchain art practical on Monad. If you sponsor gas with a paymaster, the team covers this small amount instead of the minter.\nResources\n- Get started with ERC-6551 (Token-Bound Accounts)\n- Indexers\n- Wallet infrastructure\n- Oracles\n- OpenZeppelin Contracts\n- ERC-721A\nNeed help?\nJoin the Monad Developer Discord .\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://vitalik.eth.limo/general/2026/06/29/obfuscation1.html","domain":"vitalik.eth.limo","title":"Obfuscation: building the final boss of cryptography (Part I)","hash":"b9abf5ef21d2c961bbf340746499dc51962f83224613b798ad06d9ca9bbd2676","tokens":9995,"chars":39980,"crawler":"crawler-f6nn","verified":"exact","ts":1791172225491,"text":"Dark Mode Toggle\nObfuscation: building the final boss of cryptography (Part I)\n2026 Jun 29\nSee all posts\nObfuscation: building the final boss of cryptography (Part I)\nSpecial thanks to Sora Suegami, Janmajaya Mall, Aayush\nJain and Fun Killer for feedback and review.\nThe most powerful primitive that has been conceived in cryptography\nis obfuscation . Obfuscation lets you convert a program\n\\(P\\) into an\n\"encrypted program\" \\(Obf(P)\\) such that you can run \\(Obf(P)\\)\non cleartext inputs and get the same cleartext outputs that \\(P\\) gives\nyou, but the internal workings of \\(P\\) are hidden. The precise\nformalism typically used, indistinguishability\nobfuscation (iO), says that if you are given obfuscations\nof two different programs that have the same functionality, you can't\ntell which is which. Effectively, it's hiding the code, not the\ndata.\nObfuscation is powerful because it comes very close to the\ntheoretical ideal of a universal \"trustless trusted third party\":\nSource: The\nGod Protocols (Nick Szabo), 1997\nCryptography protocols are often described by first imagining a\nprotocol that relies on a trusted third party who sees everyone's\nmessages and responds honestly, and then figuring out some way to do the\nsame thing without the trust.\n- Encryption is simple: the \"trusted third party\" is effectively a\npostage system that accepts instructions saying \"I want [recipient] to\nsee [message]\" and passes along the message to the recipient.\n- Zero knowledge proofs replace a trusted third party who receives\nyour data, checks it, and then confirms to anyone who asks that the data\nis in some sense correct\nObfuscation (technically, obfuscation plus hashes) lets you make a\nsimulated trusted third party for basically any protocol , so it\ncan replace both of the above and much much more. There is only one\nmajor exception: an obfuscated program can't prevent itself from being\ncopied, so it can't do \"stateful\" things like money - and that's exactly\nthe gap that blockchains are well-placed to fill.\nAnd so if you have obfuscation and a blockchain, you can do\nsome pretty magical things. Like, say, a secure, private and\ncollusion-resistant voting\nsystem that has almost no trust assumption at all - no\nM-of-N threshold committee required. Or basically anything from this\nlist from 2014 , without any M-of-N trust assumption.\nA fairly general-purpose way to combine obfuscation and\nblockchains to make something very close to a \"trustless trusted third\nparty\"\nSo what's the catch? Well, it turns out that making a\nsecure form of obfuscation is really really hard .\nThere has been a decades-long tradition of insecure\nobfuscation: people shuffling around the logic in compiled programs to\nmake it harder to\nsee what's going on - admittedly, often to prevent users from\nmodifying proprietary programs like games. This is the equivalent of\nthings like the Caesar cipher for\nencryption - and, like Caesar-style ciphers, it regularly gets\nbroken.\nAs a result, there has also been a decades-long tradition of trying\nto create an obfuscation protocol that we can mathematically prove is\nsecure. But almost from the beginning, this ran into a problem. In 2001,\nwe got a\nfamous result that creating an ideal form of obfuscation - obfuscate\n\\(P\\) in such\na way that running \\(Obf(P)\\) reveals nothing beyond what\nyou can learn by querying an API that gives \\(P(x)\\) for any user-supplied \\(x\\) - is\nimpossible. The core idea is that a code instantiation of \\(P\\) always\nreveals at least something beyond its outputs to user-supplied inputs:\nat the very least, you can learn things by applying \\(P\\) to\nits own code .\nFrom that point, researchers shifted to trying to prove the\nsecond-best target: indistinguishability\nobfuscation (iO). This has been a twenty-year project, with many\nfailed attempts, many constructions of protocols that build on top of an\ningredient that does not yet exist , many people trying to build\nthat ingredient, failed attempts of that , and so on.\nBut in the last few years, we finally have some good news: we know how\nto achieve iO under reasonable security assumptions.\nBut within the good news, there is bad news: the run time is\nliterally galactic . It's technically polynomial, but\nit involves stacking many layers of \"take one thing that's vaguely like\nfully homomorphic encryption, now put the circuit for evaluating that\ninto another thing that's vaguely like fully homomorphic\nencryption, run that in plain old regular fully homomorphic encryption\nonce for each bit generating an intermediate multi-megabyte\nvalue, and oh yeah, did I mention that you have to put that whole thing\ninto another thing that's vaguely like fully homomorphic\nencryption, and then run all that once for each bit in the\ninput?\" As a result, runtimes for these \"sort of provably-secure iO\nschemes\" are somewhere over λ 10 (where λ is the \"security\nparameter\", ie. the logarithm of how long it takes to break the scheme;\nit's standard to say λ = 100 or 120)\nThere are two hopeful stories that you can tell here. One is that\nthis is similar to where SNARKs\nwere in 2010, and now that we know it's possible, smart people (and\nbots) will start coming up with clever workarounds to each bottleneck,\nand chopping off orders of magnitude from the runtime one after the\nother, and eventually we'll get to something that \"only\" takes a day on\na heavy GPU to run (that may still sound prohibitive, but it's actually\nenough for many interesting applications). Another is that we will see\nmore work on a different strategy toward the same goal: getting much\nbetter at developing new cryptographic assumptions , and getting\nbetter at telling which new assumptions are likely to be actually\nsafe.\nIf you add in the more heuristic approaches, there are roughly three\n(not-yet-dead) families of obfuscation protocols so far, and you can\nplace them on a \"tradeoff frontier\" of efficiency vs bravery on security\nassumptions:\nThis post will describe in detail the most galactic, but also the\nmost rigorous, family so far: the one that's in blue in the diagram\nabove.\nJust a warning: there will be a lot of math .\nObfuscation is hard because it basically requires stacking almost every\nprimitive that cryptographers have invented in the past twenty years,\nexcept for the primitives that you already know about if you're\na blockchain developer, such as SNARKs\nand STARKs .\nThe underlying math will also be different: whereas SNARKs and STARKs\ntend to have a lot of polynomials, hashes and elliptic curves,\nobfuscation will have a lot of lattices, vectors and\nmatrices.\nNotation notes\n- The descriptions in this post are based on a combination of\napproaches from different papers, they do not completely follow any\nsingle one of them.\n- In some cases choice of notation and vocabulary will differ from any\nindividual underlying post\n- Vectors are lowercase, matrices are uppercase\n- In the diagrams, the greyed text and dotted lines informally mean \"X\ndepends on Y, but you don't have to actually pass Y into X, so the (size\n/ runtime) of X may be much smaller than the (size / runtime) of Y\"\n- \"iO\" = \"indistinguishability obfuscation\", as opposed to \"IO\" =\n\"input/output\", and both as opposed to the British Indian Ocean\nTerritory, which is what the .io TLD is named after\nThe standard pipeline\nThe \"reasonably provably secure\" obfuscation protocols that are built\ntoday are built on top of a decade-old tower of constructions: the AJ15 / BV15 / LPST15 / LPST16 lineage.\nAJ15 and BV15 are two roughly simultaneous papers that both\ndiscovered roughly the same way to build obfuscation on top of a\nprimitive called functional encryption : an\n\"authority\" publishes keys tied to a function \\(F\\) , and\nonce those keys exist, anyone with the encryption key can encrypt \\(x%\\) in\nsuch a way that anyone with the decryption key can recover \\(F(x)\\) .\nLPST15 came up with something similar. But the functional encryption\nrequired needed to have very strong properties which were not yet\navailable. Fortunately, a year later, LPST16 discovered a way to build\nobfuscation on top of something similar, sublinear compact\nrandomized encoding , and then built it on top of an already-known\n\"succinct-but-not-compact\" functional encryption scheme plus a new\nprimitive called XiO - obfuscation that is only slightly\nsmaller in size than publishing a table of the outputs of the function\non all possible inputs. The bulk of the work since then has been\nfiguring out ways to actually implement XiO (though some protocols take\nother routes, eg. JLS20 ).\nWe will split this description in three parts:\n- Assuming you have a succinct FE scheme and an XiO scheme, how do you\nbuild an obfuscation protocol?\n- How do you build a succinct FE scheme?\n- How do you build an XiO scheme?\nAssuming\nyou have a succinct FE scheme and an XiO scheme, how do you build an\nobfuscation protocol?\nThere are several ways to build an obfuscation protocol on top of\nsuccinct FE and XiO, and they are all roughly equal in their high-level\nprinciples and their properties. So I will stick to a simplified version\nof the LPST15 design.\nNote that in this post, we will often use \"function\" and \"circuit\"\ninterchangeably. A circuit is a set of AND, OR, NOT, etc gates with\nwires linking them that can be used to evaluate a function. To get a\nbetter intuition of circuits, I recommend this\npost explaining garbled circuits (a primitive that we will need\nlater anyway).\nFirst, let us define succinct FE and XiO, so we understand the\nproperties of these gadgets.\nHere is succinct FE:\nAuthority generates circuit-independent public\nparameters, and circuit-specific decryption keys for a publicly-known\nfunction with a single-bit output with circuit \\(C\\) .\nEncryptor can use the encryption keys to encrypt\n\\(x\\) . The\nruntime of this step does not increase (or increases only slightly) with\nthe circuit size of \\(C\\) , though it does scale linearly\nwith input length.\nDecryptor can use the decryption keys to learn \\(C(x)\\) and\nnothing else about \\(x\\) . The runtime of this step\ndoes scale with the circuit size of \\(C\\) .\nIn other words: someone does a trusted\nsetup , I encrypt \\(x\\) , you can decrypt \\(C(x)\\)\n(different from fully homomorphic encryption: in FHE, anyone who can\ndecrypt \\(C(x)\\) can\nalso decrypt \\(x\\) or any other function of \\(x\\) )\nFunctional encryption is not on its own sufficient for obfuscation,\nbecause (i) it doesn't hide the function, and (ii) each published\nencryption is bound to one input and can only decrypt the function\nevaluated on that one input. But it gets you a lot of the way there.\nNote that the more common definition of succinct FE requires the FE\nto tolerate high circuit size , not high circuit depth .\nIn our usage, however, we do need to tolerate high depth.\nFortunately, depth-independent succinct FE is a fairly simple wrapper on\ntop of depth-bounded succinct FE (we will get into this later), so in\nthis post we will just assume that the succinct FE that we use is also\ndepth-independent.\nNow, here is XiO:\nGenerator chooses parameters for a hidden function\nwith circuit \\(C\\) that has a single-bit output.\nThey generate an encoding of that function. This step is allowed to take\nas long as evaluating \\(C\\) on all possible inputs or even\nlonger, but the output must be smaller than the truth table (the set of\noutputs for all possible inputs)\nEvaluator evaluates the encoding to learn \\(C(x)\\) for\nany input \\(x\\) .\nThe class of functions that XiO is designed for is functions that are\nreally best understood as zero-input functions (aka\n\" thunks \")\nthat produce a large but manageably-sized output. Given a thunk \\(() \\rightarrow\nX\\) , we can think of it as being a function \\(i \\rightarrow\nX[i]\\) , ie. the function which takes as input an index\n\\(i\\) as\ninput, and returns the i'th output of the thunk. These are two different\nviews of the same object; in this post we will regularly bounce back and\nforth between these views.\nFor example, you could imagine taking a function that generates a STARK\n(a roughly 128-512 kB sized cryptographic proof) and turning it into a\nfunction that takes as input an index \\(0 \\le i \\lt\n2^{22}\\) , generates the STARK internally, and then outputs\nthe i'th bit of the STARK. The goal of the XiO is that it's a gadget\nsmaller than the STARK (though note: even a STARK may be too small to\nactually allow known XiO protocols to shrink it) that lets you\ngenerate that STARK, without being able to learn anything else about the\nunderlying process that's generating it.\nNow, we combine succinct FE and XiO into a primitive called a\nsublinear compact randomized encoding :\nLet's walk through this carefully. The goal here is to create a\n\"randomized encoding\" of \\(P()\\) - that is, a gadget that\nenables executing \\(P()\\) - which is asymptotically\nsmaller than the runtime of \\(P\\) and asymptotically smaller than\nits output, and which hides \\(P\\) .\nThis is slightly different than the usual presentation of\nrandomized encodings , which operate over \\(P(x)\\) and\nhide \\(x\\) but not\n\\(P\\) (eg.\ngarbled circuits work this way), but this is what we need for our use\ncase - obfuscation is all about hiding the function.\nThe primitives that we will be working with do not hide the function.\nTo do this, we make the \"outer\" function that these primitives are\noperating over just be a virtual machine (or \"Turing machine\") -\nbasically, a function \\(VM\\) which takes circuits as input,\nso \\(VM(P,\nX) = P(x)\\) . The circuit evaluating \\(VM\\) is\noften called a universal circuit . This way, \\(P\\) becomes\njust another input, which can be made private.\nOne nuance in terms of asymptotic complexity: \\(VM\\) needs\nto be instantiated as a circuit , and the size of a circuit must\nbe proportional to its runtime (because circuits do not allow looping).\nHence, the size of the \\(VM\\) circuit must be proportional to\nthe runtime of \\(P\\) . Fortunately, succinct FE allows\ngeneration to be fast even if the circuit is large and deep. However,\nthe output may have size and encryption cost that scales with\nthe size of \\(P\\) . This is the reason why \\(P\\) must be\nexpressed in a language other than circuits (such as a Turing machine ):\nits size must be fixed even if the computations get large.\nWe do a trusted\nsetup of succinct functional encryption, where the creator publishes\npublic params and decryption keys for \\(VM\\) . This allows anyone to encrypt\n\\((P, x)\\) in\nsuch a way that anyone else can decrypt \\(VM(P, x) = P(x)\\) , but without\nlearning \\(P\\) or\n\\(x\\) .\nTo generate this randomized encoding, the creator wraps the two\nprimitives I mentioned above inside each other: they do an XiO of a\nsuccinct FE encryption of \\(VM(P, x)\\) . The succinct FE\nencryption hides \\((P,\nx)\\) , and it's fast to generate even if \\(P\\) takes a\nlong time to run. But succinct FE is not output-compressing: if the\noutput is big, the succinct FE encryption is even bigger (and this is an unavoidable\nlimitation of that type of construction). The XiO cuts the size back\ndown. The creator makes a circuit \\(C_{sfe}(i)\\) that outputs the i'th\nbit of the succinct FE encryption, and does XiO over that. Its size is\nnow asymptotically smaller, and it's asymptotically faster to generate,\nthan the program \\(P\\) itself (note \"asymptotically\":\nat small sizes, the overhead of the scheme dominates, the key property\nwe want is that for sufficiently large circuits, \\(xIO(sFE(VM(P, x))))\\) becomes\nsmaller than \\((P,\nx)\\) itself, both in byte size and in generation time.\nNotice that here we already have our first glimpse of obfuscation:\nthe creator themselves can both do the trusted setup and publish the\nxIO, and others can execute it without being able to learn the program\nbeing run. But we have a big problem: this only works for one\npre-configured input.\nNow, we get to the next part: the final obfuscation construction.\nEssentially, we take the sublinear compact RE primitive, and we apply\nit recursively, recursing on the number of bits of input going into the\nfunction you are trying to obfuscate. At the base case (zero inputs), we\njust use the sublinear compact RE as above. To add one bit, we make a\nsublinear compact RE of the process of generating two obfuscations one\nlevel lower: obfuscate the function \\(P_0(x)\\) which executes \\(P\\) but\nwith the first input bit fixed to \\(0\\) , and \\(P_1(x)\\)\nwhich executes \\(P\\) but with the first input bit\nfixed to \\(1\\) .\nRemember the key properties of the two building blocks of sublinear\ncompact RE:\n- XiO ensures that this obfuscation can be smaller than the\ntwo sub-obfuscations it is generating\n- Succinct FE ensures that it can be faster to generate than\nthe two sub-obfuscations it is generating.\nBoth properties are needed to ensure the recursion avoids blowup.\nTo evaluate an obfuscated program, you evaluate the top-level RE to\nget your two new obfuscations (both with one fewer input bit required),\nthen choose either left or right based on the first input bit, then keep\nrecursing further down, until you bottom out with a thunk that generates\n\\(P(x)\\) for\nthe \\(x\\) that is\nthe full path you walked down.\nHere's another equivalent way to look at what's going on:\nFor programs with an n-bit input, there is a depth-n, size \\(2^n\\) tree\nof all possible evaluations. However, most of this tree is never\nevaluated. The whole thing is a tree of \"thunks\", and so the exponential\ncost of creating the tree is never paid because all the thunks that are\nnot on the path to the specific input you care about never actually get\ninstantiated. The only thing that does get instantiated is the\nobfuscation at each step along with path going from the root to the\ninput. And at a very high level, that's it, that's the core design.\nNote that the original LPST15 and LPST16 papers describe what\nis going on slightly differently (but equivalently): they do not recurse\non obfuscation directly, rather they recurse on a \"node\nprogram\" . One nice property of that approach is that the node\nprogram captures the \"bits of the input so far\", so you don't have to\nmanipulate or wrap \\(P\\) itself; \\(P\\) stays\nunchanged throughout the whole process in their version.\nAnother thing that the above description elided is that for\nobfuscation to be secure, it needs to be randomized. So actually, it's\nnot \\(iO(P)\\) ,\nit's \\(iO(P,\nseed)\\) , where the \\(seed\\) is a value that is hashed to\ngenerate (pseudo-)randomness needed by primitives like garbled circuits.\nRandomized encoding, XiO and succinct functional encryption also all\ntake a \\(seed\\) as\nan argument. When one of these functions calls any other as a\nsubroutine, it should generate the seed for the subroutine via a hash\nfrom its own seed, and take care to provide a unique different seed for\neach one. To make the security proofs clean, the hash must technically\nbe a puncturable\nPRF , though with the interesting property that the punctured version\nof the hash needs to be possible to construct but never actually gets\nrun.\nHow do you build a\nsuccinct FE scheme?\nThe bad news: the succinct FE scheme is a complicated tower of\nconstructions, one stacked on top of the other.\nThe good news: these constructions are relatively well-understood,\nuse very standard cryptographic assumptions (\"just\" lattices ),\nand the pipeline to build succinct FE has been understood since roughly\n2014.\nHere's the diagram first:\nLet's go through these one by one. The two most fundamental building\nblocks are garbled circuits and fully homomorphic encryption.\nGarbled circuits\nHere\nis a post where I explain garbled circuits in more detail. The basic\nsummary is:\n- For each wire in a circuit you generate two labels, one representing\n0 and one representing 1.\n- For each gate, you publish a table of which pair of input labels\ncorresponds to which output label, stored sorted by label so it's not\nclear which input label corresponds to zero and which corresponds to\none.\n- The output labels are not given \"in the clear\"; instead, they are\ntypically XOR'd with the hash of the two inputs. This makes them\ncalculable when needed, but prevents you from learning anything about\nthe \"branch\" other than the one that you have both input labels\nfor.\n- To execute, you need to obtain the labels corresponding to your\ninput, and then you \"walk down the circuit\" to eventually determine the\nvalues of the wires at the end (which are actually values, and not just\nlabels)\nGarbled circuits can only safely be executed once. If you give\nsomeone the labels for two inputs, they are able to compute much more\nthan two outputs. Garbled circuits were originally developed as a 2-of-2\nmulti-party-computation primitive: I have a circuit \\(C\\) , you\nknow \\(x\\) , I send\nyou a garbling of \\(C\\) , for each input wire I help you\nlearn one of the two input wires without learning which one using a\ntechnique called oblivious\ntransfer , and then you walk the circuit to compute the output\n\\(C(x)\\) .\nA basic rough description of how oblivious transfer works: you send\nme two public keys \\(A\\) and \\(B\\) that have to add up to some\nrandom hash so only one of them can have a valid private key but I don't\nknow which one, I encrypt one label with \\(A\\) and one with \\(B\\) , you\ndecrypt the label that you have a private key for, but I can't tell\nwhich one that is.\nHere, however, we are not doing 2-of-2 computation. Rather, we are\nusing garbled circuits as an ingredient to get the properties\nthat we need for succinct FE. Garbled circuits have many valuable\nproperties. Notably:\n- You can give someone labels for an input without revealing the\ninput.\n- Because the per-gate work is parallel, generating a garbled circuit\nfor \\(C\\) is\nlow-depth, even if \\(C\\) itself is very high depth.\nBoth of these properties will be important.\nGarbling hides some information about the circuit, but not\nenough to be meaningfully useful for anything where you want\nfunction-hiding. When function-hiding is required (eg. the 2-of-2 MPC\nuse case), a typical solution is to garble a universal circuit (aka\nvirtual machine) and have the circuit provider also provide the actual\ncircuit \\(C\\) they\nwant to run as labels that become part of the input. For our\nuse case, we don't care about garbling leaking details of the function,\nin fact precisely because we are employing this \"wrap it in a VM\"\ntrick.\nFully homomorphic encryption\n(FHE)\nHere\nis a post where I talk about FHE in more detail. Because the details\nmatter for the other constructions later in this post, I will provide a\nbasic summary.\nFHE is based on a cryptographic assumption called learning with\nerrors (LWE). Basically, if you have an approximate\nsolution to a system of linear equations modulo some number (ie. a\nmatrix \\(A\\) ,\nvectors \\(s\\) and\n\\(b\\) ,\nmodulus \\(q\\) such\nthat \\(b =\n(A*s + e) % q\\) modulo \\(q\\) , where \\(e\\) is a\n\"small\" (aka \"low-norm\") error vector, so each value in \\(e\\) is much\nsmaller than \\(q\\) ), then given \\(b\\) and\n\\(A\\) you\ncan't extract \\(s\\) . If you have an exact\nequation \\(s * A =\nb\\) , then that's a system of linear equations ( modulo q ),\nwhich can be done reasonably cheaply with Gaussian\nelimination . But with errors added, doing this inversion is\ncomputationally infeasible.\nThere are many FHE algorithms built on top of this assumption that\nhave different properties. The simplest idea involves randomly choosing\na private key \\(s\\) , generating a random matrix\n\\(A\\) , and\ncomputing \\(b = A * s + e + m *\n\\frac{q}{2}\\) modulo \\(q\\) as the encryption of a single\nbit \\(m\\) (here,\nadding a bit to a vector adds that value to every element of the\nvector).\nThe creator can then publish encryptions of \\(0\\) and\n\\(1\\)\ncomputed this way. To decrypt, you can compute \\(b - A * s\\)\nwhich equals \\(e + m *\n\\frac{q}{2}\\) ; the higher-order bit encodes the message\nand the lower-order bits encode the error which can be thrown away. If\nyou have two ciphertexts \\(b_1\\) and \\(b_2\\) that\nare valid encryptions of \\(x_1\\) and \\(x_2\\) , then\n\\(b_1 + b_2\\)\n(again, all modulo \\(q\\) ) is a valid encryption of \\(x_1 +\nx_2\\) .\nNotice also that the above design as written can support encrypting\nvectors of bits in the message slot, and not just single bits.\nBut there's one critical thing that the above design does not actually\nsupport: multiplication.\nMultiplication is trickier than addition, for a few reasons. First,\nyou can't multiply two vectors by each other and get a vector; you can\nonly do that to other structures like matrices or polynomials. Second,\nwhereas adding two three-term values \\(A * s + e + m *\n\\frac{q}{2}\\) gives you another three-term value,\nmultiplying two three-term values gives you a nine-term value, so you're\nstill getting something of a different \"shape\". Third, you end up\nmultiplying the \"small\" error by \"large\" other things, which makes the\nerror blow up after only one round of multiplication.\nThere is no one easy solution to this. There are several families of\nsolutions, that all have different drawbacks. The ones that use\npolynomials are based off of a stronger assumption called Ring\nLWE ; a commonly-used scheme is BFV .\nThe scheme that is most convenient to FHE usage is based on matrices,\nand is called GSW . To\nshow how it works, I will first show a simplified version that makes the\nbasic arithmetic work, but does not deal with the error issue, so it\nbreaks if you have nonzero error.\nFirst, generate a secret \\(s\\) . To encrypt a value \\(m\\) , first\ngenerate an otherwise-random matrix \\(A\\) where \\(s * A\\)\nequals some \"small\" or \"low-norm\" error \\(e\\) . One way to do this is to\ngenerate both in two parts:\n- Generate a random \\(s_{prefix}\\) , and then set \\(s =\n(-s_{prefix}\\ |\\ 1)\\) ( \\(|\\) is concatenation)\n- Generate a random \\(A_{prefix}\\) , and a random low-norm\nerror \\(e\\) , and\nthen set \\(A =\n({{A_{prefix}} \\atop {s_{prefix} * A_{prefix} + e}})\\)\n(that's vertical concatenation)\nThen, compute \\(c = A +\nm * I\\) (where \\(I\\) is the identity matrix). And to\ndecrypt the ciphertext, read off \\((s * C)[-1]\\) (ie. the last value of\n\\(s *\nC\\) ).\nIf you are a mathematician, you might notice that we are \"hiding\"\n\\(m\\) in an\nigon\nvalue eigenvalue of C: \\(s\\) is the eigenvector, so it\nsatisfies \\(s * C\n\\approx s * m\\) . They are not quite an exact\neigenvector and eigenvalue; they're eigenvectors and eigenvalues with\nerrors. But first, we can set aside the errors, and note some properties\nthat make eigenvalues special.\nAdding ciphertexts is again trivial: if\n\\(C_1\\)\nsatisfies \\((s * C_1)[-1] \\approx\nm_1\\)\n\\(C_2\\)\nsatisfies \\((s * C_2)[-1] \\approx\nm_2\\)\nthen\n\\(C_1 + C_2\\)\nsatisfies \\((s * (C_1 + C_2))[-1]\n\\approx (m_1 + m_2)\\)\nBut unlike before, we can multiply ciphertexts too: if\n\\(s * C_1\n\\approx s * m_1\\)\n\\(s * C_2\n\\approx s * m_2\\)\nthen\n\\(s *\n(C_1 * C_2)\\)\n\\(= (s *\nC_1) * C_2\\)\n\\(\\approx\nm_1 * s * C_2\\)\n\\(\\approx\nm_1 * m_2 * s\\)\nEigenvalues are basically the only attribute of a matrix that has\nboth an additive and a multiplicative property like this, and even there\nwe are restricting to matrices that have the same eigenvector.\nNow, let's bring back error tolerance . The mechanism\nabove, as written, has a fatal flaw: if you write out the full equations\nwith error, you end up multiplying error by elements of \\(C\\) and\n\\(s\\) , which\ncan be anywhere in the full range \\([0, q-1]\\) . Hence, this immediately\nblows up error to the maximum. Additionally, even decryption cannot\ntolerate error.\nTo plug the first hole (we'll get back to the second at the end),\nactual GSW relies on a gadget matrix mechanism.\nHere is what a gadget matrix looks like:\nOn its own this looks nice but it does not make much sense. However,\nit is intended to be paired with an operation (not a matrix) that it\ncancels out: the matrix bit decomposition operation:\nEvery adjacent four values in the output of this operation (which we\ncall \" \\(G^{-1}\\) \")\nis the (least-significant-bit first) binary encoding (aka. bit\ndecomposition) of the correspondingly-placed value in the input.\nThe most important facts about \\(G\\) and \\(G^{-1}\\) are:\n- The output of \\(G^{-1}\\) is\n\" low-norm \" (all small values)\n- \\(G *\nG^{-1}(x) = x\\) , for any \\(x\\)\nYou can see the latter intuitively. If you trace the highlighted\nbit-decomposition of 2 ( 0 1 0 0 ) in the above example\nthrough the computation, then it gets multiplied by 1 2 4 8\nfrom the gadget, and the result is \\((0 * 1) + (1 * 2) + (0 *\n4) + (0 * 8) = 2\\) . That is, if you apply the gadget\nmatrix to a bit decomposition, it \"evaluates\" the bit decomposition to\nget back the original value.\nIn those places where we used the identity matrix ( \\(I\\) ) in the\nsimplified description above, in the actual protocol we use\n\\(G\\) . That\nis, ciphertexts are of the form \\(A + m * G\\) . We multiply two\nciphertexts by computing \\(C_1 *\nG^{-1}(C_2)\\) . The message is being hidden in something\nthat's no longer quite an eigenvalue-with-errors, but we still\npreserve the needed properties. The math ends up working the same way,\nbut because the error never gets multiplied by large numbers,\nmultiplication actually works. Specifically:\n- Encryption: \\(C = A +\nm * G\\)\n- Decryption: \\(\\frac{(s * C)[-1]}{q /\n2}\\)\n- Adding: \\(C_1 +\nC_2\\) (duh)\n- Multiplying: \\(C_1 *\nG^{-1}(C_2)\\)\nNote one subtlety in the decryption. The last column of \\(G\\)\ncontains \\(\\frac{q}{2}\\) as its only nonzero\nentry, and so multiplying by \\(G\\) actually gives us an object\ncontaining \\(m *\n\\frac{q}{2} + e\\) (and not \\(m + e\\) ). This is what gives us\nerror tolerance in decryption. This is also why we are now dividing by\n\\(\\frac{q}{2}\\) when we encrypt. Note\nthat this method as written requires \\(q\\) to be a power of two. If you\nwant, you can make \\(q\\) be something else, but this\nrequires tweaking the decryption procedure slightly.\nWe can check the correctness of multiplication. Let's start with just\nthe algebra. First for addition:\n\\(C_1 =\nA_1 + m_1 * G\\)\n\\(C_2 =\nA_2 + m_2 * G\\)\nAnd then for multiplication:\n\\(C_1 *\nG^{-1}(C_2)\\)\n\\(= (A_1 + m_1 * G) *\nG^{-1}(C_2)\\)\n\\(= A_1 *\nG^{-1}(C_2) + m_1 * G * G^{-1}(C_2)\\)\n\\(= A_1 * G^{-1}(C_2) + m_1\n* C_2\\)\n\\(= A_1 *\nG^{-1}(C_2) + m_1 * A_2 + m_1 * m_2 * G\\)\nNow, we have to show that the first two terms are both valid \"pads\",\nin the same way that the original \\(A_1\\) and \\(A_2\\) were\nvalid pads. The core property we need is that multiplying \\(s * A\\)\nleaves only a small low-norm error.\nThe second term is easy: \\(A_2\\) is a valid pad ( \\(s * A_2\\)\nis low-norm), and we multiply it by \\(m_1\\) , which is small, so \\(m_1 * A_2\\)\nis also low norm and hence a valid pad.\nFor the first term, let us unpack \\(s * A_1 *\nG^{-1}(C_2)\\) . \\(s * A_1\\) returns a \"small\" error.\n\\(G^{-1}(C_2)\\) returns a matrix of\nones and zeroes. Hence, \\(s * A_1 *\nG^{-1}(C_2)\\) is a small error multiplied by a matrix of\nones and zeroes, which is still a small error.\nThe error in the second pad blows up by roughly the size of the\nmessage space (so, 0 or 1). The error in the first pad blows up by\nroughly the size of the matrix. Hence, each multiplication blows up the\nerror by a constant factor, and so we can predict how many\nmultiplications the FHE can survive before the error gets too high. At\nthat point, you would need to reset the error by bootstrapping: evaluate\nthe FHE decryption circuit inside FHE.\nFinally, one more nuance: to keep the error blowup bounded, we need\nto require messages to stay small; specifically, they must be 0 or 1 (we\ncan also accept eg. -1 or 2). Addition and multiplication do\nnot respect size limitations, and unlike BGV, here we do not have native\n\"wraparound\" modulo 2. So to make the above algorithm safe, you would\nneed to use circuits with \"logic gates\" implemented like this:\n- \\(AND(a,\nb) = ab\\)\n- \\(OR(a,\nb) = a + b - ab\\)\n- \\(XOR(a,\nb) = a + b - 2ab\\)\n- \\(NOT(a)\n= E_1 - a\\) where \\(E_1\\) is an encryption of 1.\nThis is only one way to do it; it's not optimal; there are ways to do\nit more efficiently, and that is part of the art of FHE\noptimization.\nHere is some python code that follows along this style of GSW, though\nnote that it uses a slightly different technique where \\(A * R\\) is\nthe \"pad\" instead of \\(A\\) (this has all of the properties\nabove, plus an extra property that we will need later). https://gist.github.com/vbuterin/f0f8a9eb09633226ada20c21a98d537e\nIt's worth playing around with this kind of FHE, because it helps\nbuild intuitions for some of the other primitives that we are going to\nuse below.\nNow, let's get to the next one:\nAttribute-based encryption\n(ABE)\nNot this Abe.\nAnd not this Abe.\nAnd also not this Abe.\nHere is the definition of attribute-based encryption:\nAuthority generates keys for a function with circuit\n\\(C\\) , they\ngenerate a \"master public key\" \\(mpk\\) (public), and a secret key\n\\(sk_C\\)\n(given to decryptor) that depends on \\(C\\)\nEncryptor knows \\(m\\) (a message to encrypt), they\nknow a \\(tag\\) for\nthat message, they do not necessarily know \\(C\\) but they do know \\(mpk\\) . They\nproduce a ciphertext \\(T\\)\nA decryptor given such a \\(T\\) and\n\\(sk_C\\) can\ndecrypt to recover \\(m\\) if \\(C(tag) = 0\\) , otherwise they\ncannot.\nUsually, attribute-based encryption is justified by examples like:\n\\(m\\) might\nbe medical records at some hospital \\(H\\) , \\(tag\\) might be an object that\nrepresents \"you work at \\(H\\) AND you have a medical degree\",\nso it becomes easy to encrypt the medical records in such a way that\nonly the intended doctors can see them. As far as I can tell, however,\nthe number of use cases that map well to this paradigm and can't easily\nbe solved with much simpler public key encryption is very small. And so\nABE has not been used much in practice.\n. But here, we have very good news: ABE has some valuable\nproperties that make it very useful in building functional encryption!\n(And hence, obfuscation) In particular, even for circuits that\nare large, encryption is cheap . This is the ultimate seed of\nthe asymmetry that allows the \"thunks\" in the obfuscation to be faster\nto create than they are to execute, and hence makes the\nexponentially-sized tree possible at all.\nHere is how ABE works. Here we will follow the BGG+14 construction ,\nwhose properties are ideal for the succinct FE and obfuscation use\ncase.\nWe work over a circuit. To have an example in your head, take the\ncircuit that we used in the garbled circuits example (it's a two-bit\nadder), but remove the \"two labels per wire\" piece:\nInstead, we will have only one matrix \\(B_w\\) per wire, plus two\nrandomly-generated global public matrices \\(A\\) and \\(D\\) .\nThe initial \\(B_i\\) are generated randomly. To\ngenerate the \\(B\\) matrices for the wires further\ndown, we walk down the circuit going through each gate:\n- If it is ADD, then compute \\(B_{out} = B_{L} +\nB_{R}\\)\n- If it is MUL, then compute \\(B_{out} = B_R *\nG^{-1}(-B_L)\\)\nAs in FHE, we need to build OR, XOR and AND from ADD and MUL in ways\nthat preserve the wire values staying in \\(\\{0, 1\\}\\) .\nThe authority publishes circuit-independent \\(A\\) and\n\\(D\\) , and\nthe \\(B_i\\) for\nthe input wires for the circuit. They also provide the\ndecryptor with a decryption key, a low-norm matrix \\(R_f\\) that\nsatisfies \\((A |\nB_f) * R_f = D\\) , where \\(B_f\\) is the \\(B\\) matrix\nfor the wire that encodes the output (ie. \\(C(tag)\\) ). Notice that the\nconstruction of \\(B\\) matrices is not dependent on the\ninput to the circuit, which is why the authority is able to\nconstruct \\(B_f\\) in a way that is then valid\nfor all inputs. To make the equation between \\((A |\nB_f) * R_f = D\\) correct, \\(A\\) needs to be constructed in a\nspecial way that gives it a \"trapdoor\"; we will return to this\nlater.\nFirst, let's go through the encryptor and decryptor's logic.\nTo encrypt, the encryptor chooses a random vector \\(s\\) , and\ncomputes \\(c_{out}\n= s * D + e_{out} + \\frac{q}{2} * m\\) . They also provide\nthe input encodings, \\(c_i = s * (B_i + G *\ntag[i]) + e_i\\) , and \\(c_A = s * A +\ne_A\\) . Notice how encrypting does not depend on the\ncircuit itself; it only requires knowing and doing a few multiplications\ninvolving the input \\(B_i\\) and \\(D\\) .\nThe decryptor's job will be to start with these \\(c_i\\)\nvalues, and walk down the circuit, doing a homomorphic-encryption-like\noperation at each gate to convert the \\(c_L\\) for the left input wire and\n\\(c_R\\) for\nthe right input wire into \\(c_{out}\\) for the output wire.\nHere, the ADD case is again trivial: \\(c_{out} = c_L +\nc_R\\) . The MUL case is the harder one.\nThe formula is: \\(c_{out} = x_R * c_L + c_R\n* G^{-1}(-B_L)\\)\n\\(x_R\\) here\nis the actual value on that wire in the computation. To see why this\nworks, let's look at each component in turn. For ease of exposition,\nI'll write \\(G^{-1}(-B_L)\\) as \\(R_{-L}\\) ;\njust remember that because \\(G\\) and \\(G^{-1}\\) cancel out, \\(G * R_{-L} =\n-B_L\\) :\n\\(x_R *\nc_L\\)\n\\(= x_R * (s * (x_L * G +\nB_L) + e_L)\\)\n\\(= x_R * s * (x_L * G +\nB_L) + x_R * e_L\\)\n\\(= s *\n(x_L * x_R * G + x_R * B_L) + x_R * e_L\\)\n\\(c_R *\nR_{-L}\\)\n\\(= (s * (x_R * G + B_R) +\ne_R) * R_{-L}\\)\n\\(= s *\n(x_R * G * R_{-L} + B_R * R_{-L}) + e_R * R_{-L}\\)\n\\(= s *\n(-x_R * B_L + B_R * R_{-L}) + e_R * R_{-L}\\)\nIf we add the two together, the \\(x_R * B_L\\) cancel out, and we\nget:\n\\(s *\n(x_L * x_R * G + B_R * R_{-L}) + x_R * e_L + e_R *\nR_{-L}\\)\nThe \\(B_R *\nR_{-L}\\) on the left side is just \\(B_R *\nG^{-1}(-B_L)\\) , which is the definition of \\(B_{out}\\)\nfor multiplication that we gave above. And the right side is error\nmultiplied by low-norm values, so it stays as low-norm error.\nAnd so the decryptor has everything they need to walk their way to\n\\(c_f\\) .\nIf \\(C(tag)\n= 0\\) , then the \\(s * x_f * G\\) term drops off from\nthe definition of \\(c_f\\) , and we just have: \\(c_f = s\n* B_f + e_f\\)\nOnce they get to \\(c_f\\) , they prepend \\(c_A\\) to\nget \\(c'_f =\n(c_A\\ |\\ c_f)\\) , which satisfies \\(c'_f =\ns * (A\\ |\\ B_f) + e'_f\\) . They then compute:\n\\(c_{out}\n- c'_f * R_f\\)\n\\(= s * D\n+ e_{out} + \\frac{q}{2} * m - s * (A\\ |\\ B_f) * R_f - e'_f *\nR_f\\)\n\\(= s * D\n+ e_{out} + \\frac{q}{2} * m - s * D - e'_f * R_f\\)\n\\(= e_{out} + \\frac{q}{2} *\nm - e'_f * R_f\\)\nIf the error did not blow up too much (remember, \\(R_f\\) is\nalso low-norm), the decryptor can now freely recover \\(m\\) .\nNow, let's get back to the trapdoor mechanism.\nWe do not construct \\(A\\) randomly. Instead, we construct\nit as \\(A = (A_{prefix}\\ |\\ G -\nA_{prefix} * R)\\) , where \\(R\\) is a low-norm \"trapdoor\", and\n\\(G\\) is the\ngadget matrix from before. Similarly to the FHE ciphertexts we saw,\nunder the LWE assumption this kind of construction is computationally\ninfeasible to distinguish from random if you do not have the trapdoor\nyourself.\nThe goal is to satisfy a neat mathematical property:\n\\(A * {R\n\\atop I}\\)\n\\(=\n(A_{prefix}\\ |\\ G - A_{prefix} * R) * {R \\atop I}\\)\n\\(=\nA_{prefix} * R + (G - A_{prefix} * R) * I\\)\n\\(= A_{prefix} * R + G -\nA_{prefix} * R\\)\n\\(= G\\)\nOr graphically:\nWe've constructed a matrix \\(A\\) , where in some sense \\(R \\atop I\\)\nis a sort of \"inverse\" of A (remember: \\(G\\) often plays the role of\n\"pretending\" to be the identity matrix in these types of LWE\nconstructions).\nThe goal here is that we want to create matrices for which, for any\nknown vector \\(u\\) , only the creator can find a\nlow-norm vector \\(r\\) where \\(A*r = u\\) .\nThat is, the trapdoor lets us \"solve\" the short\ninteger solution (SIS) problem , which is closely related to LWE and\nis the basis for this type of cryptography working.\nHere is the algorithm:\n- Binary-decompose \\(u\\) (ie. apply good old \\(G^{-1}\\) to\nit), let the output be \\(z\\)\n- Output \\(r = {R\n\\atop I} * z\\)\n\\(R\\) , \\(I\\) and\n\\(z\\) are all\nlow-norm, so this is also low-norm. To see algebraically why this solves\nthe equation, compute:\n\\(A * r\n\\\\ = A * {R \\atop I} * z \\\\ = G * z \\\\ = u\\)\nTo guarantee that this is safe (in the sense of not leaking \\(R\\) ),\nreal-world implementations add additional error at this step; see MP12\nfor more details on maximally efficient ways to do this.\nNow, let's go back to the still-unsolved puzzle from above: computing\n\\(R_f\\) .\nThe equation we are solving for is:\n\\((A\\ |\\\nB_f) * R_f = D\\)\nWe will interpret \\(R_f\\) as \\(R_{top}\n\\atop R_{bottom}\\) , so we get:\n\\(A * R_{top} + B_f *\nR_{bottom} = D\\)"}
{"url":"https://docs.velocity.exchange/protocol/how-it-works/where-the-money-sits","domain":"docs.velocity.exchange","title":"Where the money sits | Velocity Protocol","hash":"7ffd893de82af65991ecf147651f69e50f50cef44b4504962b1af92241639394","tokens":1168,"chars":4672,"crawler":"crawler-f6nn","verified":"exact","ts":1791172228130,"text":"Velocity Protocol Developers\nMechanics\nView as Markdown\nWhere the money sits\nOne balance per user fails on the first winning trade. The vaults that hold real tokens, the pools that are only accounting balances, and how value moves between them.\nVelocity holds user funds in vaults and moves value between several internal pools. The pools are referenced across the fee, P&L, liquidation and bankruptcy pages. This is the map.\nWhy there are pools at all\nOne balance per user fails on the first winning trade. A perpetual is a two-sided contract: one account's gain is another's loss. Crediting a gain the instant the position closed would pay the winner before the protocol had collected from the other side, and a run of unmatched winners would drain the vault holding everyone else's deposits.\nSo gains and losses are not moved directly between users. They pass through pools, and a claim is only paid out of value that has actually been collected. The pools are the accounting layer that makes \"the account won\" and \"the account has been paid\" two separate events.\nThe vaults, which hold real tokens\nSpot market vault. One per spot market. Every deposit lives here, and it is the only place user tokens actually sit. Collateral for perpetual positions, balances being lent out, and balances being borrowed are all the same tokens in this vault, tracked by balance rather than segregated.\nInsurance fund vault. Held separately from the collateral vault. It is the backstop that absorbs bad debt before it is socialized across other users, so it is not drawable by ordinary account activity. See Insurance Fund .\nThe pools, which are accounting balances\nThese do not hold separate tokens. They are claims against the vaults above, tracked per market.\nPool Lives on Holds\nP&L pool Each perp market The market's realized P&L, waiting to be settled to users\nAMM fee pool Each perp market's AMM The AMM's share of trading fees, its own working capital\nProtocol fee pool Each perp and spot market The protocol's share of fees\nRevenue pool Each spot market The insurance fund's share of lending interest\nHow value moves\nA trade fee is split at the moment of the fill. The taker pays, a maker rebate is carved out first if one applies, and the remainder is divided between the AMM's fee pool, the insurance fund, and the protocol's fee pool. The AMM and insurance shares are admin-set per market, and the protocol receives whatever they leave. See Fee mechanics .\nLending interest is carved on accrual. Borrowers pay interest, lenders receive most of it, and a configured fraction is carved off into the spot market's revenue pool and toward the insurance fund. See Borrow and lend APY .\nRealized P&L passes through the perp market's P&L pool. A closing trade writes a realized gain or loss into that pool, and settlement then moves a user's share out of it and into their balance. A gain can only be settled against value the pool has actually collected, which is why settlement is a separate step from closing.\nThe AMM's fee pool retains a buffer. The sweep that moves accrued fees out leaves a target amount behind, so the AMM keeps working capital rather than being drained to zero after every sweep.\nBad debt draws in a fixed order. When a position is bankrupt, a defined sequence of sources absorbs the loss, and only what none of them can cover is socialized across remaining holders. See Bankruptcy resolution for the order, which differs between perp and spot.\nWhat this means in practice\nAs a trader. Realized profit sits in the market's P&L pool until it is settled. That is why a closed, profitable position does not immediately increase a withdrawable balance.\nAs a lender. A deposit sits in the spot market vault and is being borrowed against. That is where the yield comes from, and it is also why a market throttles withdrawals in a rolling window: the tokens are out on loan. See Withdrawal limits .\nAs someone assessing risk. The insurance fund vault is the only pool held apart from user collateral, and it stands between a bad debt and everyone else's balance. Its size and its per-tier caps are the numbers that matter. See Insurance Fund .\nEdit on GitHub\nOracles\nWhy a perpetual exchange has to import a price it does not set, the grades the protocol assigns to an incoming price, and what a trader sees while a feed is degraded.\nRevenue pool\nThe staging balance that holds the insurance fund's cut of protocol income until it settles, what flows into it, and the two things that can draw it down.\nOn this page\nWhy there are pools at all\nThe vaults, which hold real tokens\nThe pools, which are accounting balances\nHow value moves\nWhat this means in practice"}
{"url":"https://docs.lido.fi/ipfs/about","domain":"docs.lido.fi","title":"About IPFS | Lido Docs","hash":"5a59cc8dcc2a7aa76b8f3b052ffbff207921c0e7da76a0f4d91fb8239d47c04c","tokens":965,"chars":3859,"crawler":"crawler-f6nn","verified":"exact","ts":1791172230161,"text":"Skip to main content\nAbout IPFS\nIPFS (InterPlanetary File System) is a suite of protocols for publishing data (files, directories, websites, etc.) in a decentralized fashion.\nFor more info, see What is IPFS .\nThere is an option to use some Lido interfaces via IPFS, for example Lido Ethereum Staking Widget .\nIPFS is used for Lido apps because:\n- IPFS has no single point of failure. The failure of a single or even multiple nodes in the network does not affect the functioning of the entire network.\n- IPFS is decentralized, which makes IPFS more resilient than traditional systems.\n- IPFS uses cryptographic hashes to verify the authenticity and integrity of files, making it difficult for malicious actors to affect files.\nAddress\nWhat is a CID\nA content identifier, or CID, is a label used to point to material in IPFS. CIDs are based on the content’s cryptographic hash.\nAny difference in the content will produce a different CID.\nNote that CIDs won't match file hashes (checksums), because CID contains additional information that the hash does not (i.e., the codec of the data).\nIPFS HTTP Gateways\nAn IPFS gateway is a web-based service that gets content from an IPFS network, and makes it available via HTTP protocol\nthat all web browsers understand. A gateway address can look like this: https://{CID}.ipfs.cf-ipfs.com .\nYou can use available gateway of your choice . Check gateway availability here\nWhere to get CID and gateway address\ninfo\nEach new set of changes to a Lido app will produce a new CID, therefore each release will be available at its specific address.\nThis means that for a Lido app, there won't be a gateway address that always points to the most recent release .\nThe gateway you are currently using may point to the most updated version, but it will remain so until a new release to IPFS occurs.\nAfter opening a Lido app, it will automatically check if the app's version is the latest one. If not, the user will be notified and asked to use the latest version.\nReleases page on GitHub\nThe latest release information is available on GitHub under the Releases page of the app repository.\nFor Ethereum Staking Widget it is here .\nUsing the page, one can find the information about the latest release, including the IPFS pinning artifacts.\ninfo\nNote, that not every release is pinned to IPFS, see Release frequency\nAction page on GitHub\nYou can take this information from the latest GitHub action in which IPFS pinning happened:\n- Open the app's repo, follow the \"Actions\" tab.\n- On the left side, in the navigation bar, find the workflow for IPFS releases; for the Ethereum Staking Widget it is called \" IPFS Release \".\n- Open the latest successful workflow and look for the \"ipfs-pinning\" title. There you will find a root CID and a link to an IPFS HTTP gateway.\nIPFS.json\nThere is a convention to store the latest CID for an app in the IPFS.json file in the project's root.\ninfo\nThis solution might be not the final one, serves for development purposes, and is a subject to change in the future.\nThe future plans are to replace the latest CID registry with the one living on-chain and be updated via the Lido DAO governance.\nRelease frequency\nNot every new release of Lido applications will be deployed to IPFS; only major releases or critical fixes will be deployed.\nSo the deployment cadence shouldn't be too frequent.\nThis approach is preferred due to the numerous actions required to make an IPFS release,\nand also the fact that each new release of a Lido app will produce a new CID and will be available at the new address,\nwhich is inconvenient for users willing to always use the latest version of an application.\nFurther reading\n- Release Flow\n- Security\n- Hash Verification\n- IPFS applications list\n- Address\n- What is a CID\n- IPFS HTTP Gateways\n- Where to get CID and gateway address\n- Release frequency\n- Further reading"}
{"url":"https://bitcoin.org/fa/bitcoin-for-businesses","domain":"bitcoin.org","title":"بیت کوین در خدمت کسب و کارها - بیت کوین","hash":"018ef8e9bf5ee3fba60ed5409f17ee1148c0fee9aac279d7338fd9f3c863fcbc","tokens":1187,"chars":4748,"crawler":"crawler-f6nn","verified":"exact","ts":1791172232257,"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- مقدمه\n- افراد\n- کسب و کارها\n- توسعه دهندگان\n- آغاز به کار\n- چگونه کار می کند\n- لازم است بدانید\n- منابع\n- Exchanges\n- جامعه\n- BIPs list\n- دایره واژگان\n- Bitcoin Core\n- نو آوری\n- مشارکت\n- حمایت از بیت کوین\n- Buy Bitcoin\n- Sell Bitcoin\n- توسعه\n- پرسشهای رایج\n- فارسی\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: fa\nبیت کوین برای کسب و کارها\nبیت کوین راهی بسیار ایمن و ارزان برای مدیریت پرداخت هاست.\nدریافت کمترین کارمزدها\nامنیت زیاد رمزنگاری بیت کوین باعث شده تا تراکنش ها، با کارایی بسیار ولی ارزان پردازش شوند. می توانید با استفاده از شبکه بیت کوین و تقریباً بدون پرداخت هیچگونه کارمزدی، عملیات دریافت و یا پرداخت وجه را انجام دهید. در بیشتر موارد، پرداخت کارمزد خیلی الزامی نیست ولی توصیه می شود برای تایید سریعتر تراکنشهای خود، کارمزد پرداخت کنید.\nحفاظت در برابر کلاهبرداری\nهر کسب و کاری که کارتهای اعتباری یا پی پال را قبول می کند، مشکل ناشی از پرداختهایی که بعدها برگشت میخورند را میدانند. کلاهبرداری در پرداختهای برگشتی به بازار محدود و افزایش قیمتها می انجامد که به نوبه خود مشتریان را جریمه می کند. پرداختهای بیت کوین برگشت ناپذیر و ایمن هستند؛ یعنی اینکه هزینه کلاهبرداری، دیگر بر معامله گران تحمیل نمی شود\nپرداخت های سریع بین المللی\nبیت کوینها می توانند درعرض 10 دقیقه از آفریقا به کانادا منتقل شوند. در حقیقت، بیت کوینها هرگز مکان فیزیکی واقعی ندارند، بنابراین می توان هر مقدار بیت کوین را بدون هیچ محدودیت، تاخیر و یا کارمزد اضافی به هر جایی منتقل کرد. هیچ بانک واسطی هم وجود ندارد که مجبورتان کند سه روز کاری صبر کنید.\nتوافق با PCI الزامی نیست\nپذیرش آنلاین کارتهای اعتباری معمولاً به کنترلهای امنیتی زیادی نیاز دارد تا از مطابقت آنها با استاندارد PCI اطمینان حاصل شود. بیت کوین همچنان شما را ملزم می دارد که\nکیف پول و پرداختهای خود را ایمن نمایید . اما هزینه ها و مسئولیتهای ناشی از اطلاعات حساس در حال پردازش مشتریانتان، مانند شماره کارت های اعتباری آنان، بر عهده شما نیست.\nبطور رایگان خود را بیشتر در معرض دیده شدن قرار دهید\nبیت کوین بازار نوپدیدی از مشتریان جدیدی است که به دنبال راه هایی برای خرج کردن بیت کوین هایشان می گردند. پذیرش آنها راه خوبی برای جذب مشتریان جدید است و به کسب و کار شما فرصتی تازه برای دیده شدن می دهد. پذیرش یک روش پرداخت جدید، اغلب اقدامی هوشمندانه برای کسب و کار های آنلاین بشمار می رود.\nچند امضایی بودن\nبیت کوین یک ویژگی دیگر به نام چند امضایی بودن نیز دارد که تنها زمانی به بیت کوینها اجازه خرج شدن را می دهد که گروهی از افراد، آن تراکنش را تصدیق کرده باشند. نمونه کاربرد این ویژگی یک هیات مدیره است که با استفاده از این ویژگی، از هزینه کردن یکی از اعضا بدون جلب رضایت کافی از اعضای دیگر، جلوگیری می کند و نیز برای ردیابی اینکه کدامیک از اعضا اجازه ی چه پرداخت وجهی را دارند.\nشفافیت در حسابداری\nاز بسیاری از سازمانها درخواست می شود که برای فعالیتهای خود، مستندات حسابداری فراهم کنند. استفاده از بیت کوین به شما اجازه میدهد میزان شفافیت را به بالاترین میزان برسانید؛ چون شما می توانید اطلاعاتی برای اعضای خود فراهم کنید که بتوانند به کمک آنها ترازها و تراکنشهای شما را درستی آزمایی کنند. سازمانهای غیرانتفاعی نیز می توانند به عموم مردم اجازه دهند تا مقدار کمکهای اهدایی دریافت شده توسط سازمان را ببینند.\nAccept fast payments with Lightning\nThe Lightning Network lets your business accept bitcoin payments that settle near-instantly with minimal fees, even for small amounts. Point-of-sale systems and open-source payment tools support Lightning at checkout. See Lightning resources for more.\nآغاز به کار با بیتکوین\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nمقدمه:\n-\nافراد\n-\nکسب و کارها\n-\nتوسعه دهندگان\n-\nآغاز به کار\n-\nچگونه کار می کند\n-\nلازم است بدانید\nمنابع:\n-\nمنابع\n-\nExchanges\n-\nجامعه\n-\nBIPs list\n-\nدایره واژگان\n-\nBitcoin Core\nمشارکت:\n-\nحمایت از بیت کوین\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nتوسعه\nOther:\nحقوقی\nPrivacy Policy\nمطبوعات\nدرباره bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 منتشر شده تحت MIT license\nNetwork Status\n- فارسی\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- 繁體中文\nfa"}
{"url":"https://gov.uniswap.org/c/temperature-check/9","domain":"gov.uniswap.org","title":"Temperature Check - Uniswap Governance","hash":"cae29a9199d3d0010512d10a4d6817170be42d8606bb32c8cb90afda7b3c394e","tokens":641,"chars":2561,"crawler":"crawler-f6nn","verified":"exact","ts":1791172234708,"text":"Uniswap Governance\nTemperature Check\nTopic\nReplies\nViews\nActivity\nREAD ME: How to Create a Temperature Check\n3\n3300\nDecember 24, 2020\n[Temp Check] Protocol Fee Expansion: Arc\n5\n461\nOctober 1, 2026\n[Temp Check] Rotate Sentinel Addresses on the DUNI-Owned Uniswap Earn Vaults\n6\n248\nOctober 1, 2026\n[Temp Check] Activate v4 Protocol Fees\n24\n2782\nAugust 18, 2026\n[Temp Check] Protocol Fee Expansion: Robinhood Chain\n3\n984\nJuly 22, 2026\n[Temp Check] Protocol Fee Expansion: Three More Chains\n3\n667\nMay 20, 2026\n[Temp Check] Protocol Fee Expansion: Eight More Chains and Remaining Mainnet v3 Pools\n7\n1243\nMarch 3, 2026\nTrial run a Technical Advisory Board (TAB)\n16\n793\nJune 17, 2025\n[Re-Temperature Check] - Activate Uniswap Protocol Governance\n5\n763\nMay 31, 2025\n[Temp Check] Forse Analytics for Uniswap Revitalization and Growth Program\n47\n2186\nMarch 27, 2025\nGovernance Proposal - Scale Uniswap Liquidity on Celo\n15\n945\nJanuary 10, 2025\n[Temp Check] - Adopt The SEAL Safe Harbor Agreement\n1\n239\nDecember 17, 2024\nRFC - Uniswap V3 Deployment to Fantom\n7\n6993\nDecember 13, 2024\nTipping Protocol for Increased Community Engagement\n1\n135\nNovember 28, 2024\nArbitrum LTIPP Incentive Matching\n25\n2483\nSeptember 26, 2024\n[Temp Check] Raise the onchain proposal quorum threshold from 40M\n4\n339\nOctober 8, 2024\n[Temperature Check]: Delegation of UNI to Active but Underrepresented Delegates\n42\n7594\nDecember 4, 2023\nTemperature Check - [Merge the Uniswap Grant Program into Uniswap DAO Governance]\n8\n6966\nJune 2, 2024\n[Temperature Check]: Invest in Ekubo Protocol\n8\n7691\nOctober 29, 2023\nTemperature Check - [Issue a Visa Card with Uniswap Logo ]\n18\n2956\nOctober 27, 2023\nTemperature Check- Deploy Uniswap V3 on Gnosis Chain\n8\n4863\nOctober 3, 2023\n[Temperature Check] Post-BSL Cross-chain Deployment Process & Creation of new Uniswap.eth Subdomain\n3\n3494\nSeptember 18, 2023\nFee switch date approaching, time to act\n102\n14057\nJune 2, 2023\nTemperature Check - Should Uniswap v3 be deployed to Gnosis Chain?\n10\n7270\nFebruary 9, 2023\nTemperature Check - How to 10x LP earnings & TVL. A proposal for Uniswap v4\n3\n4441\nApril 3, 2023\n[Temperature Check] Accountability Committee Proposal\n5\n5889\nMarch 9, 2023\nUniswap DAO can help 80K UNI to Turkey to relief after the big earthquake disaster\n0\n3856\nFebruary 14, 2023\n[Temperature Check] Should Uniswap v3 be deployed to BNB Chain? 🦄\n7\n9428\nJanuary 22, 2023\nTemperature Check - Add limit order to the UI\n2\n4036\nJanuary 9, 2023\n[Temperature Check] Fix the Cross Chain Messaging Bridge on Arbitrum\n8\n5318\nDecember 9, 2022\nnext page →"}
{"url":"https://ethereum.org/","domain":"ethereum.org","title":"Ethereum - The complete guide from ethereum.org","hash":"3f69459038c56b2c881cd1e62e24024ae91cf85a14adf6a3a4bab5b9f9b548d4","tokens":768,"chars":3072,"crawler":"crawler-f6nn","verified":"exact","ts":1791172237640,"text":"Skip to main content\nThe internet that belongs to you\nEthereum is the global network where you control your assets, your data, and your identity.\nNever offline\n100% uptime\n10 years\nSince 2015\nProven track record\nBuilt to last\nEthereum has run continuously since 2015 without a single second of downtime.\nThe code is open for anyone to verify. No company runs it, no one can shut it down, and thousands of independent operators keep it going worldwide.\nGet ETH\nWhat makes Ethereum different\nPrinciples that set Ethereum apart from traditional systems\nDirect ownership\nYour bank balance is a custody promise . Your Ethereum balance is true ownership.\n$4.6B+\nDaily trading volume (USD)\nPublic rules\nThe code is public, agreements execute exactly as written. Think vending machine versus hoping the cashier gives correct change.\nGlobal\nAnyone, anywhere can use Ethereum. No permission needed.\nFree access\nNo credit check, no minimum balance, no account approval. If you have internet, you're in.\nNobody owns Ethereum\nChanges happen through open proposals that anyone can participate in. Think community garden versus corporate farm.\nWhat is Ethereum?\nNov 3 – 6 , 2026 November 3 – 6 , 2026\nMumbai, India\nGather with the curious at Devcon 8\nUse ETHORG10 to claim your exclusive 10% General Admission discount\nGet tickets\nlink-external-assistive-text\nLatest Ethereum updates\nBlast Shuts Down Its L2\nETH Daily\nBlast is winding down its Ethereum Layer 2 due to unsustainable operating costs, urging users to withdraw before October 26 as the exit delay drops to 24 hours.\nNewsletters\nOct 2, 2026\nlink-external-assistive-text\nEthereal news weekly #41\nEthereal\nGlamsterdam upgrade on Sepolia testnet October 6, Vitalik: the cryptographic world computer, Hegotá upgrade focil-devnet-0 live\nNewsletters\nOct 2, 2026\nlink-external-assistive-text\nRemix Release v2.6.4\nEthereum Remix\nRemixAI now selects audit checklist. Deploy & Run with a UI improvement. New RemixAI for low cost LLMs.\nDev tooling\nOct 1, 2026\nlink-external-assistive-text\nView more\nGet started on Ethereum\nTakes 2 minutes to get started. No credit check, no paperwork, no minimum balance.\nUnderstand Ethereum\nStart here. Learn what it is, why it matters, and how it works in plain language.\n- What is Ethereum?\n- How do wallets work?\n- DeFi, stablecoins, and NFTs explained\nStart learning\nStart building\nFor developers. Access documentation, tools, and tutorials to build on Ethereum.\n- Developer documentation\n- Smart contract tutorials\n- Development tools & frameworks\nView materials\nFor enterprise\nBusiness use cases, institutional resources, and how Ethereum can serve your organization.\n- Enterprise use cases\n- Private & permissioned networks\n- Institutional resources\nExplore enterprise\nlink-external-assistive-text\nThe user-owned internet\nEthereum gives back control of your assets\nYour bank account is an entry in someone else's database. Your application is a file in someone else's server. Ethereum is an alternative network where you hold your assets directly.\n322M\nETH holders\n13 333 514\nTransactions today"}
{"url":"https://docs.cosmos.network/llms.txt","domain":"docs.cosmos.network","title":"Cosmos Docs","hash":"0393234d3696466f690fcdf386122791740b6d32415f48443836f1ce96bf31e3","tokens":9258,"chars":37032,"crawler":"crawler-f6nn","verified":"exact","ts":1791172240145,"text":"# Cosmos Docs\n> Developer documentation for the Cosmos stack. Build secure, reliable, and high-performance blockchains.\n## Home\n- [Cosmos Developer Documentation](https://docs.cosmos.network/index.md)\n- [Cosmos SDK (442 pages)](https://docs.cosmos.network/_llms/cosmos-sdk.md): Documentation for Cosmos SDK.\n## Cosmos EVM\n### v0.7.0\n#### Documentation\n##### About\n- [Overview](https://docs.cosmos.network/evm/latest/documentation/overview.md)\n- [EVM Compatibility](https://docs.cosmos.network/evm/latest/documentation/evm-compatibility.md)\n- [Frequently Asked Questions](https://docs.cosmos.network/evm/latest/documentation/getting-started/faq.md)\n##### Build\n- [Run an EVM Chain](https://docs.cosmos.network/evm/latest/documentation/getting-started/build-a-chain/quick-start.md): Create your own blockchain by forking and customizing the Cosmos EVM reference chain (evmd). This guide covers the example chain configuration, running the chain locally, and understanding the foundation for building your custom network.\n- [Tooling & Resources](https://docs.cosmos.network/evm/latest/documentation/getting-started/tooling-and-resources.md): Tools, libraries, wallets, and explorers for building on Cosmos EVM.\n###### Additional Configuration\n- [Mempool Configuration](https://docs.cosmos.network/evm/latest/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.md): Customize the EVM mempool behavior on your Cosmos EVM chain.\n- [Predeployed Contracts](https://docs.cosmos.network/evm/latest/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.md): Deploy standard EVM contracts at fixed addresses on your Cosmos EVM chain.\n- [Precompile Configuration](https://docs.cosmos.network/evm/latest/documentation/getting-started/build-a-chain/additional-configuration/precompiles.md): Choose which precompiles are active on your chain and add custom ones.\n- [Node Configuration](https://docs.cosmos.network/evm/latest/documentation/getting-started/network-operators/node-configuration.md): Complete reference for configuring Cosmos EVM nodes, JSON-RPC settings, and command-line options\n##### Learn\n###### Concepts\n- [Overview](https://docs.cosmos.network/evm/latest/documentation/concepts/overview.md): Understanding how the EVM module provides Ethereum compatibility within the Cosmos SDK platform\n- [Accounts](https://docs.cosmos.network/evm/latest/documentation/concepts/accounts.md): Cosmos EVM accounts are implemented to be compatible with Ethereum type addresses\n- [Chain ID](https://docs.cosmos.network/evm/latest/documentation/concepts/chain-id.md): Chain IDs are unique identifiers that distinguish blockchain networks from each other. Cosmos EVM uses a dual Chain ID system to maintain compatibility with both Cosmos SDK and Ethereum ecosystems.\n- [Encoding](https://docs.cosmos.network/evm/latest/documentation/concepts/encoding.md): Encoding refers to the process of converting data from one format to another to make it more secure and efficient. In the context of blockchain, encoding is used to ensure that data is stored and transmitted in a way that is secure and easily accessible.\n- [Gas and Fees](https://docs.cosmos.network/evm/latest/documentation/concepts/gas-and-fees.md): Fee calculation and gas metering in Cosmos EVM\n- [IBC](https://docs.cosmos.network/evm/latest/documentation/concepts/ibc.md): An Overview of the Inter-Blockchain Communication Protocol\n- [Mempool](https://docs.cosmos.network/evm/latest/documentation/concepts/mempool.md): Design and Rationale\n- [State Export/Import](https://docs.cosmos.network/evm/latest/documentation/concepts/migrations.md): Cosmos EVM can dump the entire application state to a JSON file. This, besides upgrades, can be useful for manual analysis of the state at a given height.\n- [Pending State](https://docs.cosmos.network/evm/latest/documentation/concepts/pending-state.md): When a transaction is submitted to the Ethereum network, it first goes into the pending status, waiting to be executed by the nodes. A transaction can be in the pending state for a longer duration if the gas price is set very low in the transaction and the nodes are busy processing other higher gas…\n- [EIP-155: Replay Protection](https://docs.cosmos.network/evm/latest/documentation/concepts/replay-protection.md): EIP-155 is an Ethereum Improvement Proposal that introduced replay protection by including chain ID information in signed transaction data. This prevents a signed transaction from being valid on multiple networks, protecting users from replay attacks.\n- [Signing](https://docs.cosmos.network/evm/latest/documentation/concepts/signing.md): Signing is the process of creating a digital signature using a private key to verify a transaction on a blockchain. The signature is created using a specific cryptographic algorithm that ensures the authenticity and integrity of the transaction using methods like wallets and the CLI.\n- [Single Token Representation](https://docs.cosmos.network/evm/latest/documentation/concepts/single-token-representation.md): Unified token model across Cosmos and EVM ecosystems\n- [Tokens](https://docs.cosmos.network/evm/latest/documentation/concepts/tokens.md): It is recommend to uses for your base denomination to maintain parity with Ethereum. There are two types of assets to consider on a Cosmos EVM-based chain:\n- [Transactions](https://docs.cosmos.network/evm/latest/documentation/concepts/transactions.md): Transaction types and lifecycle in Cosmos EVM\n- [EIP-1559 Fee Market](https://docs.cosmos.network/evm/latest/documentation/concepts/eip-1559-feemarket.md): Understanding dynamic fee pricing and the EIP-1559 mechanism in Cosmos EVM chains\n###### Precompiles\n- [Overview](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/overview.md): Precompiles are predefined functions that are integrated at the protocol level but exposed as EVM smart contract interfaces. Many precompiles provide access to Cosmos SDK module functionality for EVM applications and clients to easily leverage.\n- [Bank](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/bank.md): An ERC20 interface to native Cosmos SDK tokens for balance queries and supply information\n- [Bech32](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/bech32.md): Address format conversion between Ethereum hex addresses and Cosmos bech32 addresses\n- [Callbacks](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/callbacks.md): Interface for IBC packet lifecycle callbacks in smart contracts\n- [Distribution](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/distribution.md): Withdraw staking rewards and interact with the community pool\n- [ERC20](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/erc20.md): Standard ERC20 token functionality for native Cosmos tokens\n- [Governance](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/governance.md): On-chain governance participation through proposal submission, voting, and governance query operations\n- [ICS20](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/ics20.md): Cross-chain token transfers via IBC (Inter-Blockchain Communication) protocol\n- [P256](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/p256.md): secp256r1 (P-256) signature verification precompile for WebAuthn and secure hardware\n- [Slashing](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/slashing.md): Validator slashing and jail management for network security\n- [Staking](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/staking.md): Validator operations, delegation management, and staking functionality\n- [WERC20](https://docs.cosmos.network/evm/latest/documentation/smart-contracts/precompiles/werc20.md): Single token representation: An ERC20 interface for any token\n###### Cosmos SDK\n- [Overview](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/overview.md): Build application-specific blockchains with the modular Cosmos SDK framework.\n- [Command Line Interface (CLI)](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/cli.md): The CLI tool ('evmd') provides a full-feature interface for interacting with the blockchain. This includes commands for node operations, key management, querying blockchain state, submitting transactions, and more.\n- [Technical Architecture](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/protocol.md): Cosmos EVM is a framework that allows you to add Ethereum Virtual Machine (EVM) compatibility to any Cosmos SDK-based chain. Built on the CometBFT consensus engine, it provides fast finality, high transaction throughput, and short block times (~2 seconds).\n###### Modules\n- [ERC20](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/modules/erc20.md): ERC-20 token representation and conversion for native Cosmos tokens\n- [Fee Market](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/modules/feemarket.md): EIP-1559 dynamic fee pricing for EVM transactions\n- [IBC](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/modules/ibc.md): Inter-Blockchain Communication protocol implementation with EVM callbacks\n- [PreciseBank](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/modules/precisebank.md): High-precision bank module for 18-decimal EVM token accounting\n- [VM](https://docs.cosmos.network/evm/latest/documentation/cosmos-sdk/modules/vm.md): Core EVM implementation for Ethereum compatibility on Cosmos chains\n##### Migrations\n- [Migration: v0.6.0 to v0.7.0](https://docs.cosmos.network/evm/latest/documentation/migrations/migration-v0.6-to-v0.7.md)\n- [Migrating off x/precisebank: Gas Converter Precompile](https://docs.cosmos.network/evm/latest/documentation/migrations/gas-converter-migration.md): Run an 18-decimal gas token alongside a 6-decimal staking denom using a converter precompile, replacing the deprecated x/precisebank module.\n###### Previous Versions\n- [Migration: v0.4.x to v0.5.0](https://docs.cosmos.network/evm/latest/documentation/migrations/migration-v0.4-to-v0.5.md)\n- [Migration: v0.3.0 to v0.4.0](https://docs.cosmos.network/evm/latest/documentation/migrations/migration-v0.3-to-v0.4.md)\n- [Migration: v0.5.0 to v0.6.0](https://docs.cosmos.network/evm/latest/documentation/migrations/migration-v0.5-to-v0.6.md)\n- [ERC20 Precompiles Migration](https://docs.cosmos.network/evm/latest/documentation/migrations/erc20-precompiles-migration.md): Migration for ERC20 precompiles when upgrading to v0.4.0\n###### Advanced\n- [Upgrade Handlers](https://docs.cosmos.network/evm/latest/documentation/migrations/upgrade-handlers.md): Understanding and performing coordinated chain upgrades\n- [Custom Improvement Proposals](https://docs.cosmos.network/evm/latest/documentation/custom-improvement-proposals.md): Cosmos EVM allows protocol developers to register custom EIP activators that modify EVM behavior. This advanced feature enables chains to enable additional Ethereum Improvement Proposals or create chain-specific EVM modifications when needed.\n- [Adding EVM to an Existing Chain](https://docs.cosmos.network/evm/latest/documentation/migrations/add-evm-to-existing-chain.md): Guide for integrating the EVM module into a running Cosmos chain post-genesis\n#### API Reference\n- [Ethereum JSON-RPC](https://docs.cosmos.network/evm/latest/api-reference/ethereum-json-rpc/index.md): The JSON-RPC server provides an API that allows you to connect to a Cosmos EVM-enabled blockchain and interact with the EVM. This gives you direct access to reading Ethereum-formatted transactions or sending them to the network.\n- [Methods](https://docs.cosmos.network/evm/latest/api-reference/ethereum-json-rpc/methods.md): Find below a list of JSON-RPC methods supported on Cosmos EVM, sorted by namespaces.\n- [JSON-RPC Explorer](https://docs.cosmos.network/evm/latest/api-reference/ethereum-json-rpc/rpc-explorer.md): Complete reference for Ethereum JSON-RPC methods supported on Cosmos EVM\n#### Changelog\n- [Changelog](https://docs.cosmos.network/evm/latest/changelog/release-notes.md): Release history and changelog for Cosmos EVM\n- [IBC Protocol (192 pages)](https://docs.cosmos.network/_llms/ibc-protocol.md): Documentation for IBC Protocol.\n- [CometBFT (202 pages)](https://docs.cosmos.network/_llms/comet-bft.md): Documentation for CometBFT.\n## Skip Go\n### Documentation\n#### General API Docs\n- [Introduction](https://docs.cosmos.network/skip-go/general/getting-started.md): This pages explains what the Skip Go API is, gives examples of applications built with it, and provides guidance on standard ways to use it.\n- [Quickstart Guide](https://docs.cosmos.network/skip-go/general/quickstart-guide.md): This guide walks you through the process of setting up and using the Skip Go Client to perform a cross-chain from USDC on Noble to TIA on Celestia.\n- [Overview & Common Usage Patterns](https://docs.cosmos.network/skip-go/general/overview-and-typical-usage.md)\n- [Supported Ecosystems](https://docs.cosmos.network/skip-go/general/supported-ecosystems-and-bridges.md)\n- [Transaction Tracking](https://docs.cosmos.network/skip-go/general/multi-chain-realtime-transaction-and-packet-tracking.md): This document covers the tooling provided in Skip Go for tracking transaction status across multiple chains and bridge hops.\n- [Skip Explorer Integration](https://docs.cosmos.network/skip-go/general/explorer-integration.md): Guide to integrating Skip Explorer v2 for transaction visualization and tracking in your applications.\n- [Requesting & Using API Keys](https://docs.cosmos.network/skip-go/general/api-keys.md)\n- [Smart Relay](https://docs.cosmos.network/skip-go/general/smart-relay.md): This page covers Smart Relay -- Skip Go API's universal cross-chain data & token delivery service\n- [Post-Route Actions](https://docs.cosmos.network/skip-go/general/post-route-actions.md): How to specify actions to perform after a route of transfers/swaps is completed\n- [Setting Affiliate Fees](https://docs.cosmos.network/skip-go/general/affiliate-fees.md): This page covers how integrators can earn affiliate fees on swaps.\n- [Getting Fee Info](https://docs.cosmos.network/skip-go/general/fee-info.md): Understand how Skip Go handles user-facing fees\n- [Transaction Support](https://docs.cosmos.network/skip-go/general/transaction-support.md)\n- [FAQ](https://docs.cosmos.network/skip-go/general/faq.md)\n#### Skip Go Widget\n- [Getting Started](https://docs.cosmos.network/skip-go/widget/getting-started.md)\n- [Configuration](https://docs.cosmos.network/skip-go/widget/configuration.md): This page details your widget configuration options. Tweak it to fit your exact user experience needs!\n- [Gas on Receive](https://docs.cosmos.network/skip-go/widget/gas-on-receive.md): Automatically provide users with gas tokens on destination chains during cross-chain swaps\n- [Web Component](https://docs.cosmos.network/skip-go/widget/web-component.md)\n- [Migration Guide](https://docs.cosmos.network/skip-go/widget/migration-guide.md)\n- [FAQ](https://docs.cosmos.network/skip-go/widget/faq.md)\n#### Skip Go Client\n- [Getting Started](https://docs.cosmos.network/skip-go/client/getting-started.md): @skip-go/client is a TypeScript library that streamlines interaction with the Skip Go API, enabling cross-chain swaps and transfers across multiple ecosystems.\n- [Balances, Gas and Transaction Fee Utilities](https://docs.cosmos.network/skip-go/client/balance-gas-and-fee-tooling.md): This page details the utility functions for token balances, gas calculations, and transaction fees in Skip Go.\n- [Executing a route](https://docs.cosmos.network/skip-go/client/executing-a-route.md): This page documents the executeRoute function, used to execute a token transfer/swap using a route from /v2/fungible/route API\n- [Gas on Receive with Custom Frontends](https://docs.cosmos.network/skip-go/client/gas-on-receive.md): Implement Gas on Receive functionality in your custom frontend using the Skip Go Client Library\n- [Advanced Features](https://docs.cosmos.network/skip-go/client/advanced-features.md): This page details advanced features and utilities in the Skip Go client library.\n- [Migration Guide](https://docs.cosmos.network/skip-go/client/migration-guide.md)\n#### Advanced Transfer\n- [Cross-chain Failure Cases](https://docs.cosmos.network/skip-go/advanced-transfer/handling-cross-chain-failure-cases.md): This page covers the different ways our cross-chain swaps + transfers might fail to help identify failures and manage user expectations\n- [Interpreting Transaction & Transfer Status](https://docs.cosmos.network/skip-go/advanced-transfer/interpreting-transaction-status.md): Learn how to interpret the status of transactions and individual transfer steps from the Skip Go API's /v2/tx/status endpoint to provide accurate feedback to users.\n- [IBC Token Routing: Problem + Skip Go API Routing Algorithm](https://docs.cosmos.network/skip-go/advanced-transfer/ibc-routing-algorithm.md): This page describes the IBC token routing problem and the algorithm Skip Go API uses to select / recommend token denoms and IBC paths\n- [EVM Transactions](https://docs.cosmos.network/skip-go/advanced-transfer/evm-transactions.md): This doc covers how to interact with the EvmTx type returned by the Skip Go API\n- [SVM Transactions](https://docs.cosmos.network/skip-go/advanced-transfer/svm-transaction-details.md): This document explains how to use Skip Go API and Client TypeScript Package to construct SVM transactions.\n- [CW20 Tokens & Their Limitations](https://docs.cosmos.network/skip-go/advanced-transfer/cw20-swaps.md): Information about performing CW20 swaps\n- [Experimental Features](https://docs.cosmos.network/skip-go/advanced-transfer/experimental-features.md): This page provides a living record of the features that can be turned on with the experimental_features flag\n- [Go Fast](https://docs.cosmos.network/skip-go/advanced-transfer/go-fast.md): A brief overview of the Go Fast Transfer system\n#### Advanced Swapping\n- [Understanding Quote Quality Metrics](https://docs.cosmos.network/skip-go/advanced-swapping/understanding-quote-quality-metrics.md): This doc covers the various ways route quote quality is measured -- slippage, USD estimates of the amount in and out, and price impact\n- [`allow_unsafe`: Preventing & Handling Bad Execution](https://docs.cosmos.network/skip-go/advanced-swapping/allow_unsafe-preventing-handling-bad-execution.md)\n- [SAFE Swapping: How to Protect Users from Bad Trades](https://docs.cosmos.network/skip-go/advanced-swapping/safe-swapping-how-to-protect-users-from-harming-themselves.md)\n- [Smart Swap](https://docs.cosmos.network/skip-go/advanced-swapping/smart-swap-options.md): This page introduces the Smart Swap functionality provided by the Skip Go API to improve swap speed, price, and customization.\n#### Support Requirements\n- [Chain Support Requirements](https://docs.cosmos.network/skip-go/support-requirements/chain-support-requirements.md): This document describes what new chains need to do the support Skip Go API\n- [Token & Route Support Requirements](https://docs.cosmos.network/skip-go/support-requirements/token-support-requirements.md): This document describes the steps you must complete for the Skip Go API to begin providing new routes for users to transfer a token over to various remote chains using IBC.\n- [Skip Go Asset Registry & Overrides](https://docs.cosmos.network/skip-go/support-requirements/asset-registry-overrides.md)\n- [Swap Venue Requirements](https://docs.cosmos.network/skip-go/support-requirements/swap-venue-requirements.md): This document covers what Skip Go API requires of DEXes to support them as potential swapping venues within the API's cross-chain DEX aggregation functionality. At the end, the document provides instructions for helping the Skip team add your DEX to the API as a swapping venue\n- [Chain Integration Request](https://docs.cosmos.network/skip-go/support-requirements/chain-integration-request.md)\n#### Eureka\n- [Overview](https://docs.cosmos.network/skip-go/eureka/eureka-overview.md): An overview of IBC Eureka for developers\n- [Technical Overview](https://docs.cosmos.network/skip-go/eureka/eureka-tech-overview.md): Technical details of how IBC Eureka works\n- [Integration Guide](https://docs.cosmos.network/skip-go/eureka/integration-guide.md): A guide on how to integrate IBC Eureka for chain developers, asset issuers, and application developers\n- [Custom ERC20 Integration](https://docs.cosmos.network/skip-go/eureka/custom-erc20-integration.md): A guide for asset issuers to deploy and register custom ERC20 contracts for their tokens on Ethereum\n- [Security Properties](https://docs.cosmos.network/skip-go/eureka/security-properties.md)\n- [Contract Addresses](https://docs.cosmos.network/skip-go/eureka/contract-addresses.md): Key contract addresses for the IBC Eureka deployment.\n### API Reference\n#### Prod Endpoints\n##### Info\n- [Get /v2/info/chains](https://docs.cosmos.network/skip-go/api-reference/prod/info/get-v2infochains.md): Get all supported chains along with additional data useful for building applications + frontends that interface with them (e.g. logo URI, IBC capabilities, fee assets, bech32 prefix, etc...)\n- [Get /v2/info/bridges](https://docs.cosmos.network/skip-go/api-reference/prod/info/get-v2infobridges.md): Get all supported bridges\n- [Post /v2/info/balances](https://docs.cosmos.network/skip-go/api-reference/prod/info/post-v2infobalances.md): Get the balances of a given set of assets on a given chain and wallet address. Compatible with all Skip Go-supported assets, excluding CW20 assets, across SVM, EVM, and Cosmos chains.\n##### Fungible\n- [Get /v2/fungible/venues](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/get-v2fungiblevenues.md): Get supported swap venues.\n- [Get /v2/fungible/assets](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/get-v2fungibleassets.md): Get supported assets. Optionally limit to assets on a given chain and/or native assets.\n- [Post /v2/fungible/assets_from_source](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/post-v2fungibleassets_from_source.md): Get assets that can be reached from a source via transfers under different conditions (e.g. single vs multiple txs)\n- [Post /v2/fungible/route](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/post-v2fungibleroute.md): This supports cross-chain actions among EVM chains, Cosmos chains, and between them. Returns the sequence of transfers and/or swaps to reach the given destination asset from the given source asset, along with estimated amount out. Commonly called before /msgs to generate route info and quote.\n- [Post /v2/fungible/msgs](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/post-v2fungiblemsgs.md): This supports cross-chain actions among EVM chains, Cosmos chains, and between them. Returns minimal number of messages required to execute a multi-chain swap or transfer. Input consists of the output of route with additional information required for message construction (e.g. destination addresses…\n- [Post /v2/fungible/msgs_direct](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/post-v2fungiblemsgs_direct.md): This supports cross-chain actions among EVM chains, Cosmos chains, and between them. Returns minimal number of messages required to execute a multi-chain swap or transfer. This is a convenience endpoint that combines /route and /msgs into a single call.\n- [Post /v2/fungible/ibc_origin_assets](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/post-v2fungibleibc_origin_assets.md): Get origin assets from a given list of denoms and chain IDs.\n- [Post /v2/fungible/assets_between_chains](https://docs.cosmos.network/skip-go/api-reference/prod/fungible/post-v2fungibleassets_between_chains.md): Given 2 chain IDs, returns a list of equivalent assets that can be transferred\n##### Transaction\n- [Post /v2/tx/submit](https://docs.cosmos.network/skip-go/api-reference/prod/transaction/post-v2txsubmit.md): Submit a signed base64 encoded transaction to be broadcast to the specified network. On successful submission, the status of the transaction and any subsequent IBC or Axelar transfers can be queried through the /status endpoint.\n- [Post /v2/tx/track](https://docs.cosmos.network/skip-go/api-reference/prod/transaction/post-v2txtrack.md): Requests tracking of a transaction that has already landed on-chain but was not broadcast through the Skip Go API. The status of a tracked transaction and subsequent IBC or Axelar transfers if routing assets cross chain can be queried through the /status endpoint.\n- [Get /v2/tx/status](https://docs.cosmos.network/skip-go/api-reference/prod/transaction/get-v2txstatus.md): Get the status of the specified transaction and any subsequent IBC or Axelar transfers if routing assets cross chain. The transaction must have previously been submitted to either the /submit or /track endpoints.\n#### Reference Guides\n- [API Error Codes & Status Messages](https://docs.cosmos.network/skip-go/api-reference/error-codes.md): Reference for error codes and status messages returned by the Skip Go API, including transaction, bridge, and packet-specific statuses.\n## Cosmos Hub\n### Latest\n#### Documentation\n##### Cosmos Hub\n- [Introduction](https://docs.cosmos.network/hub/latest/index.md): Welcome to the Cosmos Hub\n###### Getting Started\n- [Getting Started](https://docs.cosmos.network/hub/latest/getting-started/README.md): This folder contains tutorials related to the gaia application.\n- [What is Gaia?](https://docs.cosmos.network/hub/latest/getting-started/what-is-gaia.md): The Cosmos Hub is a public Proof-of-Stake chain that uses ATOM as its native staking token. It is the first blockchain launched in the Cosmos Network and developed using the cosmos-sdk development framework and ibc-go.\n- [Installing Gaia](https://docs.cosmos.network/hub/latest/getting-started/installation.md): This guide will explain how to install the gaiad binary and run the cli. With this binary installed on a server, you can participate on the mainnet as either a Full Node or a Validator.\n- [Quick Start - Join Mainnet](https://docs.cosmos.network/hub/latest/getting-started/quickstart.md): Bootstrap a cosmoshub-4 mainnet node\n- [System requirements](https://docs.cosmos.network/hub/latest/getting-started/system-requirements.md)\n###### Hub Tutorials\n- [Interacting with Gaiad (CLI)](https://docs.cosmos.network/hub/latest/hub-tutorials/gaiad.md)\n- [Joining Mainnet](https://docs.cosmos.network/hub/latest/hub-tutorials/join-mainnet.md)\n- [Joining Testnet](https://docs.cosmos.network/hub/latest/hub-tutorials/join-testnet.md): Visit the testnets repo for the most up-to-date information on the currently available public testnets:\n- [Upgrading the Chain](https://docs.cosmos.network/hub/latest/hub-tutorials/live-upgrade-tutorial.md): This document demonstrates how a live upgrade can be performed on-chain through a governance process.\n- [Gaia Tutorials](https://docs.cosmos.network/hub/latest/hub-tutorials/README.md): This folder contains tutorials related to the gaiad application.\n- [Upgrading Your Node](https://docs.cosmos.network/hub/latest/hub-tutorials/upgrade-node.md): This document describes the upgrade procedure of a gaiad full-node to a new version.\n###### Validators\n- [Validator Overview](https://docs.cosmos.network/hub/latest/validators/overview.md)\n- [Validators](https://docs.cosmos.network/hub/latest/validators/README.md): This folder contains documentation relevant to validators of the Cosmos Hub and other gaia blockchains.\n- [Validator Security](https://docs.cosmos.network/hub/latest/validators/security.md): Each validator candidate is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validator candidates should commence their setup phase now in order to be on time for launch.\n- [Validator FAQ](https://docs.cosmos.network/hub/latest/validators/validator-faq.md)\n- [Running a Validator](https://docs.cosmos.network/hub/latest/validators/validator-setup.md)\n- [Setting up Tendermint KMS + Ledger](https://docs.cosmos.network/hub/latest/validators/kms/kms_ledger.md)\n- [KMS - Key Management System](https://docs.cosmos.network/hub/latest/validators/kms/kms.md): Tendermint KMS is a key management service that allows separating key management from Tendermint nodes. In addition it provides other advantages such as:\n###### Delegators\n- [Delegator FAQ](https://docs.cosmos.network/hub/latest/delegators/delegator-faq.md)\n- [Delegator Guide (CLI)](https://docs.cosmos.network/hub/latest/delegators/delegator-guide-cli.md): This document contains all the necessary information for delegators to interact with the Cosmos Hub through the Command-Line Interface (CLI).\n- [Delegator Security](https://docs.cosmos.network/hub/latest/delegators/delegator-security.md)\n- [Delegators](https://docs.cosmos.network/hub/latest/delegators/README.md): This folder contains documentation relevant to delegators of the Cosmos Hub and other gaia blockchains.\n###### Governance\n- [Off-Chain Proposal Process](https://docs.cosmos.network/hub/latest/governance/best-practices.md): Once a proposal is on-chain, it cannot be changed to reflect feedback or new information. It's very important to give a proposal time off-chain to receive feedback, input, and edits before going on-chain and asking for votes.\n- [Formatting a Proposal](https://docs.cosmos.network/hub/latest/governance/formatting.md)\n- [On-Chain Proposal Process](https://docs.cosmos.network/hub/latest/governance/process.md)\n- [Governance Overview](https://docs.cosmos.network/hub/latest/governance/README.md): The Cosmos Hub (\"Gaia\") has an on-chain governance mechanism for signaling, changing consensus parameters, and spending funds from the community pool.\n- [Submitting a Proposal](https://docs.cosmos.network/hub/latest/governance/submitting.md): If you have a final draft of your proposal ready to submit, you may want to push your proposal live on the testnet first. These are the three primary steps to getting your proposal live on-chain.\n- [Community Pool Spend](https://docs.cosmos.network/hub/latest/governance/proposal-types/community-pool-spend.md): Cosmos Hub launched with community-spend capabilities on December 11, 2019, effectively unlocking the potential for token-holders to vote to approve spending from the Community Pool.\n- [Parameter Changes](https://docs.cosmos.network/hub/latest/governance/proposal-types/param-change.md): This documentation aims to provide guidelines for creating and assessing parameter-change proposals.\n- [Proposal Types](https://docs.cosmos.network/hub/latest/governance/proposal-types/README.md): - Text - Community Pool Spend - Parameter Change - Software Upgrade - IBC Client Update\n- [Software Upgrade](https://docs.cosmos.network/hub/latest/governance/proposal-types/software-upgrade.md): Software upgrade proposals are submitted to signal that a Cosmos Hub release with new features, bugfixes and various other improvements is available and ready for production deployment.\n- [Text (Signaling)](https://docs.cosmos.network/hub/latest/governance/proposal-types/text-prop.md): Signaling proposals are used to make an on-chain record of support or agreement on a certain topic or ideas. Text proposals do not contain any code. That is, they do not directly cause any changes to the Hub once passed.\n###### Interchain Security\n- [Interchain Security](https://docs.cosmos.network/hub/latest/interchain-security/README.md)\n###### Modules\n- [x/liquid](https://docs.cosmos.network/hub/latest/modules/liquid.md): The x/liquid module used by the Hub includes types and APIs that enable liquid staking. You can read more about it in our module documentation.\n- [Cosmos SDK LSM](https://docs.cosmos.network/hub/latest/modules/lsm-migration.md): As of the v24.x release of Gaia, the Cosmos SDK based Liquid Staking Module is deprecated. The v24 release line will still have all the types from the forked SDK version, but all the API endpoints will be disabled.\n- [Metaprotocol](https://docs.cosmos.network/hub/latest/modules/metaprotocols.md): The x/metaprotocol module adds support for encoding and decoding additional fields attached to transactions.\n- [Gaia Modules](https://docs.cosmos.network/hub/latest/modules/README.md): Here you can find an overview of the modules included on the Cosmos Hub (Gaia) blockchain with relevant info and links for each one.\n###### Architecture\n- [ADR Creation Process](https://docs.cosmos.network/hub/latest/architecture/PROCESS.md)\n- [Architecture Decision Records (ADR)](https://docs.cosmos.network/hub/latest/architecture/README.md): This is a location to record all high-level architecture decisions for new feature and module proposals in the Cosmos Hub.\n- [ADR 001: Interchain Accounts](https://docs.cosmos.network/hub/latest/architecture/adr/adr-001-interchain-accounts.md)\n- [Adr template](https://docs.cosmos.network/hub/latest/architecture/templates/adr-template.md)\n- [ADR 002: Globalfee Module [DEPRECATED]](https://docs.cosmos.network/hub/latest/architecture/adr/adr-002-globalfee.md): - 2023-06-12: Initial Draft - 2024-06-06: Change status to deprecated\n- [ADR 003: Interchain Accounts Controller Module](https://docs.cosmos.network/hub/latest/architecture/adr/adr-003-ica-controller.md)\n- [ADR Creation Process](https://docs.cosmos.network/hub/latest/architecture/adr/PROCESS.md)\n- [Architecture Decision Records (ADR)](https://docs.cosmos.network/hub/latest/architecture/adr/README.md)\n###### Resources\n- [Cosmos Hub Archives](https://docs.cosmos.network/hub/latest/resources/archives.md): With each breaking upgrade of the Cosmos Hub, the network is restarted at height 0. During this process, an export of the last state of the previous network is made to produce the genesis state of the new one.\n- [The Genesis File](https://docs.cosmos.network/hub/latest/resources/genesis.md): This document explains how the genesis file of the Cosmos Hub mainnet is structured. It also explains how you can build a genesis file for your own gaia testnet.\n- [HD Wallets](https://docs.cosmos.network/hub/latest/resources/hd-wallets.md)\n- [Ledger Nano Support](https://docs.cosmos.network/hub/latest/resources/ledger.md)\n- [Resources](https://docs.cosmos.network/hub/latest/resources/README.md): This folder contains resources on the gaia software.\n- [Building Gaia Deterministically](https://docs.cosmos.network/hub/latest/resources/reproducible-builds.md)\n- [Service Providers](https://docs.cosmos.network/hub/latest/resources/service-providers.md): 'Service Providers' are defined as entities that provide services for end-users that involve some form of interaction with the Cosmos Hub. More specifically, this document is focused on interactions with tokens.\n###### Telemetry\n- [Gaia Telemetry](https://docs.cosmos.network/hub/latest/telemetry/telemetry.md)\n## OpenAPI Specs\n- [openapi](/sdk/latest/api-reference/rest/openapi.yaml)\n- [openapi](/sdk/next/api-reference/rest/openapi.yaml)\n- [openapi](/cometbft/latest/api-reference/rpc/openapi.yaml)\n- [openapi](/cometbft/next/api-reference/rpc/openapi.yaml)\n- [openapi](/cometbft/v0.39/api-reference/rpc/openapi.yaml)\n- [openapi](/cometbft/v0.38/api-reference/rpc/openapi.yaml)\n- [swagger](/swagger.yml)\n- [openapi](/evm/v0.4.x/api-reference/ethereum-json-rpc/openapi.yaml)\n> The links below point to documentation indexes. Follow each `/_llms/` index recursively until you reach documentation pages.\n## Indexes\n- [Cosmos SDK (442 pages)](https://docs.cosmos.network/_llms/cosmos-sdk.md): Documentation for Cosmos SDK.\n- [Cosmos SDK / v0.55 (311 pages)](https://docs.cosmos.network/_llms/cosmos-sdk/v0-55.md): Documentation for Cosmos SDK / v0.55.\n- [Cosmos SDK / v0.55 / Cosmos SDK (180 pages)](https://docs.cosmos.network/_llms/cosmos-sdk/v0-55/cosmos-sdk.md): Documentation for Cosmos SDK / v0.55 / Cosmos SDK.\n- [Cosmos SDK / v0.55 / API Reference (131 pages)](https://docs.cosmos.network/_llms/cosmos-sdk/v0-55/api-reference.md): Documentation for Cosmos SDK / v0.55 / API Reference.\n- [Cosmos SDK / next (131 pages)](https://docs.cosmos.network/_llms/cosmos-sdk/next.md): Documentation for Cosmos SDK / next.\n- [Cosmos SDK / next / API Reference (131 pages)](https://docs.cosmos.network/_llms/cosmos-sdk/next/api-reference.md): Documentation for Cosmos SDK / next / API Reference.\n- [IBC Protocol (192 pages)](https://docs.cosmos.network/_llms/ibc-protocol.md): Documentation for IBC Protocol.\n- [IBC Protocol / v11.x.x (163 pages)](https://docs.cosmos.network/_llms/ibc-protocol/v11-x-x.md): Documentation for IBC Protocol / v11.x.x.\n- [CometBFT (202 pages)](https://docs.cosmos.network/_llms/comet-bft.md): Documentation for CometBFT."}
{"url":"https://www.metaplex.com/docs/smart-contracts/mpl-hybrid/guides","domain":"www.metaplex.com","title":"Guides | Hybrid","hash":"09f258626753ceea95b8a73d4c0afadc7db4b2162413ca9d48d1b8addd52080e","tokens":87,"chars":346,"crawler":"crawler-f6nn","verified":"exact","ts":1791172244296,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nGeneral\nGuides\nThe following Guides for Mpl Hybrid are currently available:\nCreate your first Hybrid Collection\nLearn how to create a hybrid collection, fully end-to-end!\nMPL-404 Hybrid UI Template\nLearn how to use the swap UI template\nNext\nCreate your first Hybrid Collection →"}
{"url":"https://docs.ethena.fi/backing-assets/protocol-revenue","domain":"docs.ethena.fi","title":"Protocol Revenue | Ethena","hash":"99811d3b4bc19150bdd40dd2f228feaf80e22e1dea320455b017f0fffddf7171","tokens":475,"chars":1897,"crawler":"crawler-f6nn","verified":"exact","ts":1791172246879,"text":"⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nProtocol Revenue\nEthena generates revenue from its backing assets. As the backing portfolio has diversified, so have the sources of that revenue, which now span several distinct and largely uncorrelated streams.\nProtocol revenue is generated from:\n-\nFunding and basis spread. The funding and basis earned on delta-neutral basis trades, in crypto markets and, increasingly, in non-crypto markets such as tokenised commodities. Historically, the mismatch between demand and supply for leveraged exposure has resulted in a positive funding and basis return over time.\n-\nLending revenue. The return earned on investments in overcollateralised loans of stable assets, supplied both into on-chain DeFi lending markets and to institutional counterparties.\n-\nReal-world asset yield. The yield earned on tokenised real-world assets held as backing, including short-duration government debt and high-liquidity credit.\n-\nLiquid stablecoin rewards . Rewards earned on liquid stablecoin holdings, depending on the asset and where it is held.\nThe central purpose of diversifying the backing portfolio is to diversify protocol revenue and risk. A model concentrated in a single strategy ties overall risk to a single set of market dynamics; spreading exposure across funding, lending, real-world assets, and stablecoin rewards reduces the likelihood of stress to the Ethena system resulting from revenue compression across all sources at the same time.\nEach stream responds to different drivers, so weakness in one can be offset by strength in others, producing a revenue base and risk profile designed to be more resilient across market cycles.\nPeriods of negative protocol revenue are designed to be borne by the Reserve Fund. See the Reserve Fund section below.\nLast updated 2 months ago\nWas this helpful?"}
{"url":"https://forum.arbitrum.foundation/c/security-council/52","domain":"forum.arbitrum.foundation","title":"Latest Security Council topics - Arbitrum","hash":"9f5046d3065332c35625f3722b39aeca3ca467b644df50fb4ed7c7fbd1d739a9","tokens":923,"chars":3691,"crawler":"crawler-f6nn","verified":"exact","ts":1791172249139,"text":"Arbitrum\nSecurity Council\nSecurity Council Elections\nAll information related to electing new Security Council members every six months.\nTopic\nReplies\nViews\nActivity\nAbout the Security Council category\nSecurity Council\n0\n79\nAugust 29, 2024\nSecurity Council Emergency Action – 2/10/2026\nSecurity Council\n0\n199\nOctober 2, 2026\nNon-Emergency Security Action to Correct Total DVP\nSecurity Council\ncouncil-actions\n0\n96\nJuly 24, 2026\nNon-emergency action to facilitate key rotation of Security Council - July 2026\nSecurity Council\ncouncil-actions\n1\n112\nJuly 17, 2026\nSecurity Council Emergency Action – 24/05/2026\nSecurity Council\ncouncil-actions\n0\n246\nMay 24, 2026\nMarch 2026 Security Council Elections - Complete\nSecurity Council Elections\nmar-2026-elections\n0\n84\nMay 22, 2026\nMarch 2026 Security Council Election: Member Election\nSecurity Council Elections\nmar-2026-elections\n4\n302\nMay 5, 2026\nSecurity Council Emergency Action – 21/04/2026\nSecurity Council\ncouncil-actions\n6\n1584\nApril 24, 2026\nSecurity Council Elections - L2BEAT voting rationale thread\nSecurity Council Elections\n9\n1497\nApril 21, 2026\nMarch 2026 Security Council Election: Nominee Selection\nSecurity Council Elections\nmar-2026-elections\n7\n248\nApril 14, 2026\nAragon - March 2026 Security Council\nSecurity Council Elections\nmar-2026-elections\n4\n127\nApril 13, 2026\nMarch 2026 Security Council Election: Compliance Check\nSecurity Council Elections\nmar-2026-elections\n1\n107\nApril 11, 2026\nDaniel Goldman - March 2026 Security Council\nSecurity Council Elections\nmar-2026-elections\n3\n113\nApril 10, 2026\nDaniel Goldman - Candidate for Security Council, September 2025\nSecurity Council Elections\nsep-2025-elections\n4\n152\nApril 9, 2026\nMateusz Jędrzejewski (Nethermind) - Candidate for Arbitrum Security Council (March 2026)\nSecurity Council Elections\nmar-2026-elections\n2\n98\nApril 4, 2026\nCertora (Elad Erdheim) - March 2026 Security Counsil\nSecurity Council Elections\nmar-2026-elections\n4\n129\nMarch 28, 2026\nSEEDGov (Martin Azpiroz) - March 2026 Security Council\nSecurity Council Elections\nmar-2026-elections\n4\n100\nMarch 25, 2026\nJosef Gattermayer - Security Council candidate Mar 2026\nSecurity Council Elections\nmar-2026-elections\n7\n224\nMarch 23, 2026\nMarch 2026 Security Council — Questions I couldn't find answers to\nSecurity Council Elections\n3\n99\nMarch 22, 2026\nWilliam Bowling - March 2026 Security Council\nSecurity Council Elections\nmar-2026-elections\n2\n105\nMarch 22, 2026\nGustavo Grieco - March 2026 Security Council\nSecurity Council Elections\nmar-2026-elections\n1\n116\nMarch 17, 2026\nHudson Jameson - Security Council Election Mar 2026\nSecurity Council Elections\nmar-2026-elections\n0\n62\nMarch 16, 2026\nMichael Lewellen - Security Council Reelection Mar 2026\nSecurity Council Elections\nmar-2026-elections\n7\n154\nMarch 16, 2026\nPablo Sabbatella (pablito.eth) @ Opsek - Security Council candidate Mar 2026\nSecurity Council Elections\nmar-2026-elections\n5\n173\nMarch 15, 2026\nMarch 2026 Security Council Election: Contender Submission\nSecurity Council Elections\nmar-2026-elections\n0\n139\nMarch 15, 2026\nBlockful (Alex Netto) - Security Council Candidate Mar 2026\nSecurity Council Elections\nmar-2026-elections\n0\n58\nMarch 13, 2026\nL2BEAT (Bartek Kiepuszewski) - Security Council Reelection Mar 2026\nSecurity Council Elections\nmar-2026-elections\n0\n60\nMarch 13, 2026\nVahe Karapetyan (kemmio) - Security Council March 2026\nSecurity Council Elections\nmar-2026-elections\n0\n87\nMarch 10, 2026\nGustavo Grieco - Candidate for Security Council\nSecurity Council Elections\nsep-2025-elections\n7\n195\nMarch 9, 2026\nMarch 2026 Security Council Election: Call for Candidates\nSecurity Council Elections\nmar-2026-elections\n0\n231\nMarch 3, 2026\nnext page →"}
{"url":"https://docs.ens.domains/wrapper/usecases","domain":"docs.ens.domains","title":"Name Wrapper Use-Cases | ENS Docs","hash":"679ab8ba48ab6c1d6a141b47729107e527c658d2e59473d39da6c1be6f27bd3e","tokens":2698,"chars":10791,"crawler":"crawler-f6nn","verified":"exact","ts":1791172251811,"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\nName Wrapper Use-Cases\nLock the resolved records for a name\nBy default, newly registered names will use the Public Resolver, which just allows the current manager/controller of the name to update any records.\nHowever, in some cases perhaps you want to make sure that a name resolves to specific records and never changes. You can accomplish this with the CANNOT_SET_RESOLVER fuse.\nSay you own mycoolcontract.eth representing a smart contract. You can use ENS subnames to refer to specific versions of that contract, like 1.mycoolcontract.eth . And perhaps you want those versioned subnames to always point to:\n- The ETH address of that immutable contract\n- The ABI for that contract\n- The contenthash for some versioned documentation page\n- etc.\nOne way to do this is just to make sure the name is Locked , all the records are set correctly, and then transfer the owner to some burn address so it can never be updated again.\nBut of course this isn't ideal, because maybe there are some records that you do want to update in the future. Or maybe you still want to keep ownership of that subname for other reasons.\nInstead of essentially burning the name, you could create a custom resolver that locks in certain records forever. Then:\n- Set the resolver of that name to your custom contract\n- Set the records however you want and lock them into the resolver\n- Burn these fuses on the name:\n- PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_SET_RESOLVER\nNow you can still keep ownership and even some limited management power over the name, while still guaranteeing that the ETH address, ABI, and whatever other records are completely immutable, as long as the expiry is set appropriately.\nIssue subdomains as tickets to an event\nMaybe you have mycoolevent.eth and you want to issue tickets like 1.ticket.2023.mycoolevent.eth .\nIf you want, you can choose to not Emancipate those subnames, but still burn some custom parent-controlled fuses. Those fuses might:\n- Indicate what \"tier\" their event ticket is\n- Maybe they can upgrade their ticket to a higher tier, which would burn some additional fuses\n- Allow them access to the express line or some VIP room\n- Maybe even automatically via some smart door\nWhen you burn those fuses, perhaps you also set the expiry to the day after the event ends.\nOr, maybe you want your attendees to be able to keep their subnames as a souvenir or proof-of-attendance!\nIf so, then instead of letting the names expire at the end of the event, you could extend the expiry and burn some additional fuses to allow the attendees to keep them forever! In that case you might want to burn these fuses:\n- CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL\nIf you want those tickets to be non-transferrable (soulbound to the address that attended), then burn these fuses:\n- CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_TRANSFER\nSell or rent subnames\nI want to sell / rent out subnames!\nSay you own the wrapped name verypopularname.eth . Obviously you can just manually create wrapped subnames like my.verypopularname.eth and then sell them on an NFT marketplace. But that sure doesn't scale well.\nTo accomplish this, you will want to create a subname registrar . This is a contract that will handle all the registration / renewal for you, and then users will be able to interact with that contract in order to register their own subnames.\nIn fact, this is exactly how .eth 2LDs are registered. The owner of the eth TLD (the NFT contract) delegates registration / renewal to the ETHRegistrarController contract. It is acting as a subname registrar for the name eth .\nYour contract would expose a register method that anyone can call. Under the hood it will use the setSubnodeOwner or setSubnodeRecord methods to create subnames, passing in the fuses and expiry you want to set.\nWhat fuses should I burn???\nFirst, note that if you want to burn any fuses on subnames, then your name must be Locked (meaning CANNOT_UNWRAP is burned).\nAssuming that you want your subnames to be \"unruggable\", such that you cannot replace / revoke them, then you will want to burn PARENT_CANNOT_CONTROL on the subnames. This will place them in the Emancipated state upon registration.\nIf you want to sell \"forever\" subnames, where users register once and can then keep them for as long as they wish, then you can consider burning the CAN_EXTEND_EXPIRY fuse.\nThis will allow the subname owner to extend their own expiry whenever they want. The max expiry is the expiry of the parent name, but the .eth Registrar allows anyone to renew/extend a .eth 2LD as well.\nIf you just want to rent subnames, then do not burn CAN_EXTEND_EXPIRY . Instead, you could include a renew method on your contract that users can call for another fee.\nIf you want to enable \"unruggable renewals\" for your registrar, to guarantee that users will always be able to renew, then you can call approve on the Name Wrapper and approve your registrar contract as the \"subname renewal manager\" for your name.\nThen, burn the CANNOT_APPROVE fuse on your name, to guarantee that you can never revoke that contract for subname renewals. See Approved Operators for more info.\nIf you want to impose other restrictions on your registered subnames, then you can burn the CANNOT_UNWRAP fuse to Lock the subname, and also burn whatever other fuses you want.\nFor example, if you want to prevent owners of your subnames (like my.verypopularname.eth from creating their own subnames (like buy.my.verypopularname.eth ), then you would burn CANNOT_UNWRAP and CANNOT_CREATE_SUBDOMAIN .\nTo recap on fuses...\n- Sell permanent names:\n- CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL\n- Sell permanent names, but prevent them from creating their own subnames:\n- CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_CREATE_SUBDOMAIN\n- Rent out names:\n- PARENT_CANNOT_CONTROL\n- Rent out names, but prevent them from transferring or reselling them:\n- PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_TRANSFER\nAnd so on, it's up to you. You can also burn whatever custom parent-controlled or owner-controlled fuses you want to.\nCan I customize my own rules and fees?\nYes! It's your registrar contract, so you can impose whatever rules and fees you want.\nFor example, the .eth Registrar imposes a 3-character minimum on all names, as well as a custom fee structure and a temporary premium auction upon expiration.\nBy default there is no character limit on subnames, but your contract could have its own rules and fee structure or whatever you want. For example, you can:\n- Allow or disallow specific addresses from registering / renewing\n- Only allow registration based on some custom criteria like holding a specific NFT\n- Custom length restrictions like only 3+ characters or < 100 characters\n- Only allow names with characters [a-z0-9] and nothing else\n- Use a custom fee structure based on:\n- The length of the name\n- The specific characters that are in the name, like emojis\n- A pre-curated list of \"good\" names like people's first names\n- And whatever other rules you want.\nMore information\nSee this page for a step-by-step guide on creating and setting up your own subname registrar: Creating a Subname Registrar\nThere is even a set of reference implementation contracts you can use as a starting base!\nGive subnames out to NFT holders\nI want to give subnames out to all of my DAO members / NFT holders!\nSay you own the wrapped name mycoolnft.eth , representing a popular NFT project you created. You want to distribute subnames like 6529.mycoolnft.eth to all holders.\nOne option is to just bulk create the subnames and drop the wrapped NFTs into their wallets. This might be good at least as an initial drop, because then the holders don't need to interact with any contract or spend any gas, you're doing that for them!\nTo create the subnames, you'd use the setSubnodeOwner or setSubnodeRecord methods.\nYou must also decide:\nHow much control over the subnames do you want to relinquish?\nDo you want to be able to revoke subnames? Or do you want them to be completely outside your control?\nOne thing to consider is whether you want the current holder of your NFT to always be able to claim/reclaim the corresponding ENS subname. If so, then you will not want to Emancipate those subnames (in other words, do not burn PARENT_CANNOT_CONTROL ).\nIf the subname is Emancipated, then the NFT holder could sell/transfer the NFT but keep the subname (up until the expiry).\nTo make it easy for anyone to claim/reclaim a subname after your initial drop, you can set up a contract for this.\nSetting up a subname claim contract\nThe claim method of your contract could:\n- Call ownerOf or balanceOf on your NFT contract to get or verify the current owner of the NFT\n- Call ownerOf or balanceOf on the ENS Name Wrapper contract to get or verify the current owner of the wrapped subname\n- If both owner addresses are the same, just return, nothing to do\n- Call setSubnodeOwner or setSubnodeRecord on the ENS Name Wrapper:\n- owner: The current owner of the NFT\n- fuses: What fuses you want to burn (if any) on that subname. If you burn any fuses, you must also set an expiry.\n- expiry: When the subname will expire.\nThen, to give that contract access to create subnames on your behalf, you would call setApprovalForAll on the Name Wrapper to approve your contract as an operator.\nNow, even if the NFT gets sold / transferred, the new owner will be able to claim their mycoolnft.eth subname at any time.\nIn addition, if you expand your NFT collection in the future and there are new owners, then those new owners would be able to claim their subnames as well.\nIf you are creating a new NFT contract, you could even bake this functionality directly into the NFT contract too, instead of needing a separate contract! By doing this, you wouldn't need a separate claim method either, your NFT contract would just automatically transfer the wrapped ENS subname whenever the NFT itself gets transferred!\nGiving your subname owners perks\nIf you decide to not Emancipate the subnames that you issue, you will still be able to burn any Parent-Controlled Fuses. There are 13 unreserved parent-controlled fuses that you can use however you wish!\nFor example, perhaps you want to grant onchain \"perks\" or \"roles\" to certain holders. You would call setChildFuses on the Name Wrapper and pass in the fuses you want to burn, and the expiry.\nThis means that those \"perks\" or \"roles\" can also be time-boxed if you want. Maybe a perk expires in 1 week or something, up to you.\nThere is also the reserved CAN_EXTEND_EXPIRY parent-controlled fuse. If you burn this, then the subname owner will be able to extend their own expiry whenever they want."}
{"url":"https://docs.monad.xyz/tooling-and-infra/cross-chain","domain":"docs.monad.xyz","title":"Cross-Chain - Monad Documentation","hash":"7effbe7255978e2c5bdded5bffde8f6583abbf1b770167cb8d327d6b259a652e","tokens":4312,"chars":17247,"crawler":"crawler-f6nn","verified":"exact","ts":1791172254300,"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\nCross-Chain\nDefinitions\nAt a high level, bridges offer the following features:\nFeature Description\nArbitrary Messaging Bridge (AMB) Allows arbitrary messages to be securely relayed from a smart contract on chain 1 to a smart contract on chain 2.\nAMB provides guarantees that messages delivered to chain 2 represent events finalized on chain 1.\nToken Bridge Allows user to lock native tokens or ERC20 tokens on chain 1 and mint claim tokens on chain 2.\nBridge maintains the invariant that, for each token minted on chain 2, there exists a corresponding token locked on chain 1.\nIntents Bridge / Liquidity Layer Allows user to turn in tokens on one chain and quickly redeem tokens on another chain,\ntypically relying on drawing on a pool of assets maintained on each side. Provides\ngreater immediacy relative to waiting for full finality of an AMB.\nBridge Aggregator Aggregates multiple liquidity layers or token bridges, potentially integrating\nswapping as well so that users may receive a different token than the one they input.\nChain Abstraction Enables a user experience exempt from the manual processes required to interact with multiple chains.\nProvider Summary\n-\nMainnet\n-\nTestnet\nProvider Docs Bridge Type Contract Addresses Explorer\nAcross Docs Intents Bridge See contract addresses\nAxelar Docs AMB; Token Bridge See contract addresses Axelarscan\nBungee Docs Bridge Aggregator See contract addresses\nChangeHero Docs Bridge Aggregator\nChainlink CCIP Docs AMB; Token Bridge See contract addresses CCIP Explorer\nCircle CCTP Docs Token Bridge See contract addresses\ndeBridge Docs AMB; Token Bridge See contract addresses deExplorer\nDZap Docs Bridge Aggregator\nExolix Docs Bridge Aggregator\nFlashnet Docs Liquidity Layer\nGarden Docs Token Bridge for BTC See contract addresses\nGas.zip Docs Token Bridge See contract addresses Explorer\nHoudini Docs Bridge Aggregator\nHyperlane Docs AMB; Token Bridge See contract addresses Hyperlane Explorer\nJumper Bridge aggregator\nLayerZero Docs AMB; Token Bridge See contract addresses LayerZeroScan\nLetsExchange Docs Bridge Aggregator\nLi.fi Docs Bridge aggregator SDK See contract addresses Li.Fi Scan\nMayan Docs Bridge Aggregator Mayan Explorer\nNEAR Intents Docs Intents Bridge\nParticle Network Docs Chain Abstraction Explorer: https://universalx.app/activity/details?id=${transactionId}\n(Replace transactionId )\nPolymer Docs AMB PolyScan\nRelay Docs Liquidity Layer Transactions\nSimpleSwap Docs Bridge Aggregator\nSocket Docs AMB Socketscan\nSquid Docs Liquidity Layer Explorer (Axelarscan)\nStargate Docs Liquidity Layer\nTrails Docs Intents Bridge / Liquidity Layer\nTrustware Docs Chain Abstraction\nWormhole / Portal Docs AMB; Token Bridge See contract addresses WormholeScan\nProvider Docs Bridge Type Contract Addresses Explorer\nGarden Docs Token Bridge See contract addresses\nLayerZero Docs AMB; Token Bridge See contract addresses LayerZeroScan\nProvider Details\nAxelar\nAxelar is an interchain platform that connects blockchains to enable universal web3 transactions. By integrating with Axelar, applications built on Monad can now easily send messages and assets between the 49+ blockchains connected via Axelar.\nTo learn more about Axelar visit our docs and GitHub .\nTo view current transactions and live stats about the Axelar network, please visit the Axelarscan block explorer .\nBungee Exchange\nBungee provides seamless swaps between any blockchain. With over\n$24B in volume and trusted by major wallets and dApps, Bungee makes moving assets between networks\nefficient, secure, and accessible to everyone, powered by the SOCKET.\nTo learn more, check out the docs .\nChangeHero\nChangeHero is a cross-chain swap platform enabling frictionless asset exchanges across a wide range of networks. Leveraging aggregated liquidity and optimized routing logic, it delivers fast settlement and consistent pricing for any supported pair. Its clean integration pathways and dependable execution make ChangeHero a straightforward tool for powering multi-chain swaps within decentralized applications.\nTo learn more, check out the docs .\nChainlink CCIP\nChainlink Cross-Chain Interoperability Protocol (CCIP) is the standard for cross-chain interoperability. CCIP enables developers to build secure cross-chain apps that can transfer tokens, send messages, and initiate actions across blockchains.\nThrough the Cross-Chain Token (CCT) standard, CCIP enables token developers to integrate new and existing tokens with CCIP in a self-serve manner in minutes, without requiring vendor lock-in, hard-coded functions, or external dependencies that may limit future optionality. CCTs support self-serve deployments, full control and ownership for developers, zero-slippage transfers, and enhanced programmability via configurable rate limits and reliability features such as Smart Execution. CCIP is powered by Chainlink decentralized oracle networks (DONs)—a proven standard with a track record of securing tens of billions of dollars and enabling over $19 trillion in onchain transaction value.\nKey CCIP developer tools:\n- CCIP official documentation : start integrating CCIP into your cross-chain application.\n- CCIP Token Manager : an intuitive front-end web interface for the deployment of new and management of existing CCTs by their developers, including no-code guided deployments and configuration tools.\n- CCIP SDK : a software development kit that streamlines the process of integrating CCIP, allowing developers to use JavaScript to create a token transfer frontend dApp.\nContract Addresses:\n- Router (mainnet): 0x33566fE5976AAa420F3d5C64996641Fc3858CaDB\nCircle CCTP\nCross-Chain Transfer Protocol (CCTP) by Circle is a permissionless onchain utility that facilitates USDC transfers securely between supported blockchains via native burning and minting.\nCircle created CCTP to improve capital efficiency and minimize trust assumptions when using USDC across blockchains.\nCCTP enables developers to build multichain applications that allow users to perform 1:1 transfers of USDC securely across blockchains.\nTo get started, visit the Circle CCTP documentation\ndeBridge\nBuild once, interoperate everywhere. deBridge enables secure, fast, and capital-efficient\nconnectivity across 20+ chains, so you can swap and transfer assets natively, trigger Cross-Chain\nlogic in seconds, all with chain abstraction and one unified protocol.\nTo get started, visit the deBridge documentation or check out the\napp .\nDZap\nDZap is a DeFi aggregation and composability layer that lets wallets, apps, and protocols access any liquidity and automate multi-step DeFi actions—swaps, bridges, lending, staking, and LP positions—across 200+ protocols and 70+ chains, including Monad. Its swap-and-bridge aggregator finds the best route across DEXs and bridges, and supports single-signature intent execution where a solver settles the outcome, with gasless and cross-chain flows exposed through a REST API and SDK.\nTo get started, visit the DZap documentation .\nExolix\nExolix is a non-custodial cross-chain exchange aggregator that sources liquidity from both centralized and decentralized exchanges to deliver instant swaps across 200+ blockchains, including Monad. It supports fixed and floating rates, requires no account signup, and never custodies user funds or private keys.\nDevelopers can integrate Exolix’s instant-exchange API to embed cross-chain swaps directly into wallets, dApps, and DeFi products, with a revenue-share model for partners.\nTo get started, visit the Exolix developer documentation .\nFlashnet\nFlashnet builds Bitcoin exchange infrastructure. Its Orchestra API enables cross-chain swaps between stablecoins and native BTC with sub-10 second settlement and ultra-low-fees. Orchestra handles all routing, execution, and settlement, allowing applications on Monad to offer the best native Bitcoin swaps through a single integration.\nTo get started, visit the documentation .\nGarden\nGarden is transforming Bitcoin interoperability with its next-gen bridge. It is built by the renBTC team using an intents based architecture with trustless settlement, enabling cross-chain Bitcoin swaps in as little as 30 seconds with zero custody risk.\nIn its first year, Garden processed over $1 billion in volume—proving the market’s demand for seamless, cost-effective Bitcoin bridging solutions.\nNow, Garden is unlocking a new era of interoperability—supporting non-likewise assets, external liquidity, and a wallet-friendly API—to onboard the next wave of partners and users.\nTo get started, visit the documentation .\nGas.zip\nGas.zip is a token bridge that enables seamless cross-chain asset transfers.\nContract Address:\n- Deployment: 0x9E22ebeC84c7e4C4bD6D4aE7FF6f4D436D6D8390\nHoudini\nHoudini is a non-custodial, privacy-focused cross-chain swap aggregator that routes transactions through a combination of decentralized exchanges, centralized exchange liquidity, and cross-chain solvers. It supports swaps across 100+ chains, including Monad, without requiring users to bridge manually, connect a wallet, or complete KYC.\nHoudini offers three swap modes: Private Swap (breaks the on-chain link between sender and receiver via compliant privacy routing), No Wallet Connect Swap (execute a swap with only a receiving address), and Onchain DEX Swap (cross-chain swaps via leading DEXs). It includes MEV protection, slippage control, gasless options, and AML/OFAC screening.\nTo get started, visit the Houdini documentation or explore the developer hub for API integration.\nHyperlane\nHyperlane is a permissionless interoperability protocol for cross-chain communication. It enables message passing and asset transfers across different chains without relying on centralized intermediaries or requiring any permissions.\nTo get started, visit the Hyperlane documentation .\nHyperlane Explorer\nTo view status of your cross chain transactions, please visit the Hyperlane Explorer .\nLayerZero\nLayerZero is an omnichain interoperability protocol that enables cross-chain messaging. Applications built on Monad can use the LayerZero protocol to connect to 35+ supported blockchains seamlessly.\nTo get started with integrating LayerZero, visit the LayerZero documentation and provided examples on GitHub .\nLetsExchange\nLetsExchange is a non-custodial instant exchange and cross-chain swap aggregator that sources liquidity from 20+ centralized and decentralized providers to deliver swaps across 6,000+ cryptocurrencies, including Monad. It supports both fixed and floating rates and lets users swap cross-chain without exposing their private keys or personal data.\nDevelopers can integrate the LetsExchange API to embed instant swaps into wallets, aggregators, and payment products, with a revenue-share affiliate model for partners.\nTo get started, visit the LetsExchange API documentation .\nLi.fi\nLI.FI delivers a seamless solution for multi-chain payments and swaps through a single unified API and SDK. By combining access to all liquidity sources—including DEX aggregators, bridges, and solvers—it ensures comprehensive coverage across ecosystems. Its smart routing technology identifies the cheapest and fastest path for any payment or trade, optimizing efficiency and cost.\nAdditionally, LI.FI offers a plug-and-play widget that enables instant, user-friendly payment flows, making integration simple for developers and intuitive for end users.\nTo get started, visit Li.fi documentation\nParticle Network\nParticle Network enables chain abstraction through its Universal Accounts (UA) infrastructure. A UA provides each user with a single account and a combined balance across multiple chains (EVM and non-EVM).\nThis allows users to interact with a dApp on Monad even if their assets are held on another network—without manual bridging or chain-switching.\nUniversal Accounts support:\n- Cross-chain deposits and swaps without manual bridging\n- Unified balance aggregation across chains\n- Gas abstraction, allowing transaction fees to be paid in any supported token\nMayan\nMayan is a cross-chain swap protocol that enables fast and efficient token transfers across multiple blockchains.\nMayan provides seamless token bridging with optimized routing to ensure the best execution for cross-chain transfers.\nTo get started, visit the Mayan documentation or explore transactions on the Mayan Explorer .\nNEAR Intents\nNEAR Intents is a chain-abstraction protocol that lets users swap and transfer any asset across chains—and even off-chain—through a competitive network of solvers that settle requests as intents. Users express the outcome they want, and solvers compete to fill it at the best price, delivering fast cross-chain execution without manual bridging. Monad is among the supported chains .\nTo get started, visit the NEAR Intents documentation .\nPolymer\nPolymer is an interoperability protocol tailor made for multi-rollup applications. It places control in the hands of the builder, by combining cross-chain merkle proofs and a simple API to allow application builders to flexibly adopt Polymer’s infrastructure for their own needs. Prove any action. Cross-chain.\nTo get started visit the Polymer documentation .\nRelay\nRelay is the fastest and cheapest way to bridge and transact across chains, offering a multichain payments network that makes swapping and transacting across hundreds of blockchains delightfully simple. Since its launch in 2024, Relay has served over 5 million users, processed 50 million transactions, and facilitated more than $5 billion in volume across 85+ networks.\nAt its core, Relay combines two powerful components: instant, low-cost cross-chain intents powered by the Relay Protocol, and comprehensive DEX meta-aggregation spanning 85 chains (including Monad), ensuring users always get the best execution.\nTo get started, visit the Relay documentation\nSimpleSwap\nSimpleSwap is a privacy-focused, self-custody crypto exchange aggregator with 3000+ currencies and cross-chain support across 130+ blockchains. It offers competitive rates and timing, significantly simplifying buying and exchanging crypto with sign-up-free solutions.\nTo learn more, check out the docs .\nSocket\nSOCKET Protocol is the first chain-abstraction protocol, empowering\ndevelopers to build applications that seamlessly leverage multiple blockchains. It enables the\ncreation of chain-abstracted apps that interact across chains as if operating on a single one.\nTo get started, visit the SOCKET documentation .\nSquid\nSquid creates unlimited access for anything in crypto. Squid can be used to seamlessly swap tokens from 100+ chains across including Monad.\nSquid’s API, SDK, and Widgets offer ease of integration for projects building on any chain to enable cross-chain functionality in just 1 click.\nStargate\nStargate Finance is a cross-chain bridge protocol that enables users\nto transfer native assets between different blockchains with instant guaranteed finality using\nunified liquidity pools.\nTo get started, visit the Stargate documentation .\nTrails\nTrails is the universal intents SDK for 1-click crypto transactions. Trails lets users transact with any wallet, any token, across any chain by orchestrating swaps, bridges, and payments behind the scenes. Developers can integrate pay, swap, fund, and checkout flows through a single SDK with cross-chain execution, gasless transactions, and the ability to pay gas with any token including USDC.\nTo get started, visit the documentation .\nTrustware\nTrustware is a chain abstraction platform that acts as a Universal Deposit Layer, letting apps accept any asset on any chain and settle to any destination. It handles routing, swaps, and settlement under the hood, so users on Monad can deposit from another chain or token without manual bridging or chain-switching. Trustware can be integrated via a drop-in React widget, a hosted wallet bridge, or a headless REST API for backend control.\nTo get started, visit the documentation .\nWormhole\nWormhole is a cross-chain interoperability protocol that provides secure communication between blockchains. Monad uses two Wormhole products: Messaging and NTT (Native Token Transfers) .\nBy integrating Wormhole, a Monad application can access users and liquidity on > 30 chains and > 7 different platforms.\nWormhole Messaging\nWormhole Messaging is a generic messaging protocol that enables secure cross-chain communication and arbitrary data transfer between blockchains.\nTo get started with Wormhole Messaging:\n- Quickstart Guide\n- GitHub Examples\nWormhole NTT (Native Token Transfers)\nWormhole NTT (Native Token Transfer) framework enables seamless cross-chain token movement without wrapping or liquidity pools, allowing projects to maintain token ownership and customize their cross-chain token deployment.\nTo get started with Wormhole NTT:\n- Quickstart Guide\n- GitHub Examples\nFor end-users looking to bridge assets, you can use Wormhole Portal Bridge .\nFor more information on integrating Wormhole, visit their documentation .\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.optimism.io/op-mainnet/network-information/connecting-to-op","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"8a70773da1fbbcf93508fc5635df6e14581642598f01960f0de4b805114b7c46","tokens":575,"chars":2299,"crawler":"crawler-f6nn","verified":"exact","ts":1791172256384,"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\nReference\nConnecting to OP Mainnet\nDocumentation for OP Mainnet and OP Sepolia. This page covers network information including network names, chain IDs, RPC endpoints, currency symbols, block explorers, and contract addresses.\nThis page provides network information for OP Mainnet and OP Sepolia, including RPC endpoints, chain IDs, and block explorers.\nThe public RPC URLs provided below are rate limited and do not support websocket connections.\nIf you are experiencing rate limiting issues or need websocket functionality, consider running your own node or signing up for a third-party RPC provider .\nOP Mainnet\nParameter Value\nNetwork Name OP Mainnet\nChain ID 10\nCurrency Symbol 1 ETH\nExplorer https://explorer.optimism.io\nPublic RPC URL https://mainnet.optimism.io\nSequencer URL 2 https://mainnet-sequencer.optimism.io\nSubblocks websocket URL 3 wss://op-mainnet-fb-ws-pub.optimism.io/ws\nContract Addresses Refer to the Contract Addresses page\nConnect Wallet Click here to connect your wallet to OP Mainnet\n- The “currency symbol” is required by some wallets like MetaMask.\n- The sequencer URL is write only.\n- Strictly rate-limited public URL. Please rely on Ethereum JSON RPC or reach out to the Optimism team for a more relaxed private endpoint.\nOP Sepolia\nParameter Value\nNetwork Name OP Sepolia\nChain ID 11155420\nCurrency Symbol 1 ETH\nExplorer https://testnet-explorer.optimism.io\nPublic RPC URL https://sepolia.optimism.io\nSubblocks websocket URL 3 wss://op-sepolia-fb-ws.optimism.io/ws\nSequencer URL 2 https://sepolia-sequencer.optimism.io\nContract Addresses Refer to the Contract Addresses page\nConnect Wallet Click here to connect your wallet to OP Sepolia\n- The “currency symbol” is required by some wallets like MetaMask.\n- The sequencer URL is write only.\n- Strictly rate-limited public URL. Please rely on Ethereum JSON RPC or reach out to the Optimism team for a more relaxed private endpoint.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.marginfi.com/protocol-overview/architecture","domain":"docs.marginfi.com","title":"Architecture","hash":"935291e4e7f8ac3da25b683b8784366cea6e7b212067206fab85c369d73630ef","tokens":1009,"chars":4036,"crawler":"crawler-f6nn","verified":"exact","ts":1791172261412,"text":"Protocol Overview\nArchitecture\nCore data model of Project 0, including Groups, Banks, Accounts, Balances, and Oracles.\nProject 0 is built on the mrgnLendv2 program, a Solana smart contract that manages all lending, borrowing, and risk operations on-chain. The protocol's data model consists of five core entities.\nArchitecture at a Glance\n┌────────────┐ ┌───────────┐ ┌──────────┐\n│ │ │ │ │ │\n│ Group │1─────n│ Bank │1─────n│ Oracle │\n│ │ │ │ │ │\n└────────────┘ └───────────┘ └──────────┘\n1 1\n│ │\nn 1\n┌───────────┐ ┌────────────┐\n│ Margin │ │ │\n│ Account │1───≤16│ Balance │\n│ │ │ │\n└───────────┘ └────────────┘\nGroup\nA collection of Banks. Each Group has a single administrator (typically a secure governance multisig) who has broad authority over it, and several delegate admins (limit, emode, etc.) who can perform lower-risk modifications. All the assets you see on app.0.xyz belong to a single Group overseen by the foundation.\nBank\nEach asset available to borrow and lend on P0 has a Bank. This account controls all the settings for a particular asset: interest rate curves, risk parameters (asset weights, liability weights), deposit and borrow caps, oracle configuration, and fee structure. Many Banks might exist for the same underlying token. Every asset listed on app.0.xyz is a Bank.\nAccount\nUsers can create as many Accounts as they want. Accounts are per-Group, and each Account can have up to 16 positions across any Banks in that Group. The Account contains various user-specific settings and cached values, along with a LendingAccount where Balances are stored.\nBalance\nA Balance is an asset or liability position in a single Bank. Users cannot have both an asset and a liability in the same Bank, and can have at most one Balance per Bank. Each Account's LendingAccount holds a collection of up to 16 Balances. Balances can be blank/unused, and are always sorted in byte order by the corresponding Bank's public key.\nAsset Weight\nEach asset available to lend has two asset weight rates: Initial and Maintenance. The Maintenance rate is always higher. When executing a borrow, collateral is valued at price * initial weight . When a liquidator attempts a liquidation, collateral is valued at price * maintenance weight . The range between these is sometimes called the \"health buffer.\"\nFor example, if a user has collateral worth $10 and init/maint rates are 50% and 60% respectively, the user can borrow $10 * 0.5 = $5. For liquidation purposes, their collateral is worth $10 * 0.6 = $6.\nThe LTV displayed on app.0.xyz is the Initial weight. The health shown on the portfolio page uses the Maintenance weight.\nLiability Weight\nEach borrowable asset also has a liability weight, split into Initial and Maintenance. The Maintenance rate is always lower. When executing a borrow, liabilities are valued at price * initial weight . When a liquidator attempts a liquidation, liabilities are valued at price * maintenance weight .\nOn the borrowing page, the displayed \"LTV\" is 1 / Initial Liability Weight , i.e. the LTV you would get if lending an asset with an Asset Weight of 1.\nOracle\nEach Bank has an oracle used to determine the price of the asset it transacts in. The Group admin is responsible for picking and maintaining the Oracle. Typically, Switchboard is the oracle provider, but Pyth is also supported, and some Banks have a fixed price. An Oracle may use multiple accounts. For example, a Kamino Bank uses a price source and the Kamino reserve.\nFor details on confidence intervals, EMA vs spot pricing, and staleness rules, see Oracles .\nFor detailed developer and integrator documentation (instruction construction, account packing, Kamino integration internals), see the guides on GitHub .\nWhat is Project 0\nAn on-chain prime broker that unifies collateral, risk, and margin across Solana DeFi.\nLending & Borrowing\nHow deposits, borrows, interest accumulation, LTV, and the share system work on Project 0.\nOn this page\nArchitecture at a Glance Group Bank Account Balance Asset Weight Liability Weight Oracle"}
{"url":"https://docs.lido.fi/ipfs/hash-verification","domain":"docs.lido.fi","title":"Hash verification | Lido Docs","hash":"b23e5c2e2cf942bde6ae6084585d410c87fea9fa976bdab63cf51bb2b7d97bdf","tokens":1301,"chars":5202,"crawler":"crawler-f6nn","verified":"exact","ts":1791172263490,"text":"Skip to main content\nHash verification\nYou may want to verify the authenticity and integrity of the application, deployed on IPFS.\nIt can be done by CID (hash) verifying. In order to do so, you will need to download the source code of the application and build it locally.\nSee the detailed instructions below.\nSteps\ninfo\nLido Ethereum Staking Widget is taken as example here.\nPrerequisites\nYou will need these tools installed in your system:\n- Node.js 20+\n- Yarn package manager v1 (classic)\nAlternatively, you can use Docker to set up a building environment; read the sections below for the instructions.\n1. Clone the repository\nThe repo for Ethereum Staking Widget is here: https://github.com/lidofinance/ethereum-staking-widget\n2. Git checkout a commit, matching the IPFS version\nYou need to git checkout the specific commit, matching the release of an app you want to verify.\nThis way, you can be sure that the app will not include any other changes, which affect the CID.\nThere are several ways to do it.\nMethod 1 – using git tags\nEach released version has its own git tag, one can use it for git checkout.\n- Open the app in your browser and check the right side of its footer.\nThere will be a version number, which is actually a link to a Releases page on GitHub.\n- Run git fetch --all --tags --prune to fetch all tags.\n- Run git checkout tags/ , where is the version from step 1.\nMethod 2 – searching on the GitHub Release page\n- Open the Releases page of the project's repository on GitHub. For Ethereum Staking Widget it is here .\n- Search manually for the latest release, where IPFS pinning happened.\n- Look for the commit hash near the release information.\n- Run git checkout , where is the commit hash from the previous step.\n3. Set up the project\nWithout Docker\n- Add ENV variables as instructed in README.\n- Remove node_modules directory if the project was set up earlier.\n- Install node modules using yarn install --frozen-lockfile .\n- Follow other instructions described in the project's README.\nUsing Docker\nIf you have problems with setting up the environment or if it is your preference,\nyou can use Docker to set up and build the project.\nSteps for Docker\n- Configure build-info.json as instructed in this step .\n- Create verification.Dockerfile file in the project's root with this content:\n# build env\nFROM node:20-alpine as build\nWORKDIR /app\nRUN apk add --no-cache git=~2\nCOPY package.json yarn.lock ./\nRUN yarn install --frozen-lockfile --non-interactive --ignore-scripts && yarn cache clean\nCOPY . .\nRUN NODE_NO_BUILD_DYNAMICS=true yarn typechain && yarn build-ipfs\n# public/runtime is used to inject runtime vars; it should exist and user node should have write access there for it\nRUN rm -rf /app/public/runtime && mkdir /app/public/runtime && chown node /app/public/runtime\n# final image\nFROM node:20-alpine as base\nWORKDIR /app\nRUN apk add --no-cache curl=~8\nCOPY --from=build /app /app\n- Add ENV variables as instructed in the project's README.\n- Run these commands:\ndocker build --no-cache -t verification:0 -f verification.Dockerfile .\ndocker create --name verification-container verification:0\ndocker cp verification-container:/app/out /Users/${Name}/${Path-to-project}/dockerbuild-verification\ndocker rm verification-container\n- Run further steps from step 6 of this instruction.\n4. Configure build-info.json\nThe build-info.json file is located in the project's root, here is the link .\nIt must contain information about the version of the application, which is currently deployed to IPFS.\nYou can take this information from the latest GitHub action in which IPFS pinning happened:\n- Open the app's repo, follow the \"Actions\" tab.\n- On the left, in the navigation, find the workflow for IPFS releasing, for the Ethereum Staking Widget it is called \" IPFS Release \".\n- Open the latest successful workflow and look for the \"prepare-for-ipfs summary\" title or the JSON data which looks like this:\n{ \"branch\" : \"main\" , \"commit\" : \"56ab68d\" , \"version\" : \"0.0.1\" }\n- Copy the data to your local build-info.json\n5. Build the IPFS version\nRun a suitable npm script to build the IPFS version.\nIn case of Ethereum Staking Widget, it is yarn build-ipfs .\n6. Create a CAR file and get its CID (hash)\nFor Next.js applications the build files will be in the out directory.\nThe following command generates a CAR file from the out directory with build files, and it will display the IPFS hash in the console:\nnpx ipfs-car pack ./out --output ./out.car\n7. Get CID (hash) of the application deployed to IPFS\nYou will need to get the hash of the latest released CAR file.\nIt can be found on the Releases page of the repository under the \"Assets\" collapsible block.\nDownload the CAR file and run the following command:\nnpx ipfs-car roots ipfs_source_code.car\nIt will show CID roots found in the CAR header. The CID (hash) must be the same as in the previous step.\n- Steps\n- Prerequisites\n- 1. Clone the repository\n- 2. Git checkout a commit, matching the IPFS version\n- 3. Set up the project\n- 4. Configure build-info.json\n- 5. Build the IPFS version\n- 6. Create a CAR file and get its CID (hash)\n- 7. Get CID (hash) of the application deployed to IPFS"}
{"url":"https://docs.filecoin.io/build-on-filecoin/developing-contracts","domain":"docs.filecoin.io","title":"Developing contracts | Filecoin Docs","hash":"e392bdae4c3aa977c3bac63a0ae9c2905ef4c88a28a88dc6bde2bf8cacf53401","tokens":242,"chars":965,"crawler":"crawler-f6nn","verified":"exact","ts":1791172266281,"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 .\nDeveloping contracts\nWrite, deploy, and test smart contracts on the Filecoin Virtual Machine.\nThis section covers how to build dApps by writing smart contracts on the Filecoin Virtual Machine.\nTable of contents\n-\nGet test tokens — obtain tFIL from a faucet for testing on Calibration\n-\nERC-20 quickstart — deploy your first ERC-20 token on Filecoin\n-\nCall built-in actors — interact with Filecoin system actors from your contracts\n-\nFilecoin.sol — Solidity libraries for accessing Filecoin storage primitives\n-\nSolidity libraries — third-party contract templates and libraries\n-\nBest practices — guidelines for building reliable FVM dApps\n-\nSupport — where to get help with contract development\nWas this page helpful?\nPrevious Foundry\nNext Get test tokens\nLast updated 3 months ago"}
{"url":"https://docs.orca.so/liquidity/advanced/strategies","domain":"docs.orca.so","title":"Advanced Liquidity Position Concepts - Orca Documentation","hash":"4b35532df30a95a72b69a1a88d7519e8d88db4a70f908f7150700c905773d1dd","tokens":2680,"chars":10718,"crawler":"crawler-f6nn","verified":"exact","ts":1791172269104,"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\nAdvanced\nAdvanced Liquidity Position Concepts\nReview advanced concepts for experienced liquidity providers.\nThis guide covers advanced concepts for experienced liquidity providers who understand the basics of concentrated liquidity.\nConcentrated liquidity positions involve risk. Position outcomes depend on price movement, liquidity range, trading activity, fees, rewards, market conditions, and how actively positions are managed. This guide is informational only and does not provide financial advice or guarantee results.\nIf you’re new to providing liquidity, start with the Beginner Guide .\nUnderstanding position objectives\nBefore creating or managing a position, it can help to understand what you are trying to model or monitor.\nObjective Position focus Considerations\nFee exposure Narrower ranges around active prices May require more monitoring and rebalancing\nLower management frequency Wider ranges Liquidity is spread across a broader range\nToken accumulation Asymmetric ranges or range-order-style positions Creates directional token exposure\nPosition hedging Range placement based on existing exposure Outcomes vary based on market conditions\nRange concepts\nNarrow ranges\nNarrow ranges concentrate liquidity closer to a selected price range.\nThey may be used when a liquidity provider wants more concentrated exposure around active prices.\nArea Consideration\nRange width Smaller percentage range around the current price\nPotential benefit More concentrated liquidity if price remains in range\nPotential drawback Price may move out of range more quickly\nManagement May require more frequent monitoring\nNarrow ranges may be more relevant for pairs with lower relative price movement or for users who plan to monitor positions frequently.\nWide ranges\nWide ranges spread liquidity across a broader price range.\nThey may be used when a liquidity provider wants less frequent range management.\nArea Consideration\nRange width Broader percentage range around the current price\nPotential benefit Position may remain in range across more price movement\nPotential drawback Liquidity is less concentrated\nManagement May require less frequent range adjustment\nWide ranges may be more relevant for volatile pairs or for users who do not plan to monitor positions frequently.\nLaddered ranges\nLaddered ranges use multiple positions across different price ranges.\nExample:\nPosition 1: $90 - $100 (below current price)\nPosition 2: $100 - $110 (around current price)\nPosition 3: $110 - $120 (above current price)\nPossible considerations:\n- Liquidity can be distributed across multiple price areas.\n- Some positions may be in range while others are out of range.\n- Multiple positions can increase transaction costs and management complexity.\n- Capital is split across ranges.\nAsymmetric ranges\nAsymmetric ranges place liquidity mostly above or below the current price.\nThey may be used to model directional token exposure or range-order-style behavior.\nRange mostly above current price\n- As price rises through the range, the position may convert from one token to the other.\n- This creates directional exposure based on the selected range.\nRange mostly below current price\n- As price falls through the range, the position may convert from one token to the other.\n- This creates directional exposure based on the selected range.\nLearn more: Range Orders\nRebalancing concepts\nWhen users may review a position\nLiquidity providers may review a position when:\n- Price exits the selected range — The position stops earning swap fees while out of range.\n- Position composition changes — The position may become heavily weighted toward one token.\n- Market conditions change — Volatility, volume, and liquidity conditions may change over time.\n- Fee or reward conditions change — Displayed APR, reward availability, and trading activity may vary.\nManual rebalancing\nManual rebalancing usually involves:\n- Withdrawing liquidity — Remove liquidity from the current position and harvest any accrued fees.\n- Reviewing current conditions — Review current price, price range, volatility, and liquidity conditions.\n- Selecting a new range — Choose a new range based on the position setup you want to create.\n- Opening a new position — Deposit liquidity into the new range.\nRebalancing can involve transaction costs, price movement, slippage, and changes in token composition. Review transaction details before confirming.\nExample review triggers\nSome liquidity providers use review triggers to decide when to check positions.\nTrigger Possible review action\nPrice approaches range edge Review whether the range still matches your intended setup\nPrice exits range Review whether to leave, withdraw, or create a new position\nPosition remains out of range Review token composition and fee accrual status\nFee or reward metrics change Review whether the displayed metrics still match expectations\nCost considerations\nEach rebalance can involve costs or trade-offs:\n- Transaction fees — Solana network fees and any required account costs\n- Slippage or execution differences — Final received amounts may differ from quoted amounts\n- Time out of range — A position may not earn swap fees while out of range\n- Token composition changes — Rebalancing can change exposure to each token\nRisk considerations\nImpermanent loss\nImpermanent loss is the difference between holding tokens and providing them as liquidity at a given price.\nFactors that may affect impermanent loss include:\n- Relative token price movement — Larger price changes can increase impermanent loss.\n- Range width — Concentrated ranges can create stronger exposure to price movement.\n- Time in range — Fees can only accrue while liquidity is in range.\n- Token correlation — Tokens that move differently can create larger changes in position value.\nLearn more: Understanding Impermanent Loss\nPosition sizing\nLiquidity providers may choose to distribute liquidity across different pools, ranges, or assets.\nConsiderations include:\n- Exposure to each token\n- Pool liquidity and volume\n- Range width\n- Time required to monitor positions\n- Transaction costs\n- Slippage and withdrawal outcomes\nAlerts and review points\nOrca alerts can help users monitor when a position may need review.\nExamples of alert conditions include:\n- Price approaching a range boundary\n- Price moving out of range\n- Fee accumulation reaching a selected level\n- Significant changes in pool activity\nLearn more: Creating Alerts\nAdvanced concepts\nJust-in-time liquidity\nJust-in-time, or JIT, liquidity involves adding liquidity around specific trading activity and removing it afterward.\nConsiderations include:\n- Requires advanced tooling and technical knowledge\n- May involve MEV-related risks and execution complexity\n- May not be suitable for most users\n- Outcomes depend on transaction ordering, market activity, and execution conditions\nThis concept is generally relevant to sophisticated users with custom infrastructure.\nArbitrage activity\nArbitrage activity can occur when pool prices differ from prices elsewhere.\nLiquidity providers should understand that:\n- Arbitrage can move pool prices toward other market prices.\n- LP positions may be traded against during arbitrage.\n- Fees may accrue from swaps that use the position’s liquidity.\n- Fee accrual may or may not offset changes in position value.\nYield and reward metrics\nDisplayed yield or APR metrics are estimates based on current or historical information. These metrics can change as pool conditions change.\nWhen reviewing yield or rewards, consider:\n- Pool volume — Future volume may differ from historical volume.\n- Reward availability — Rewards may change, end, or be unavailable.\n- Liquidity changes — More or less liquidity can affect displayed metrics.\n- Token price movement — Price changes can affect position value and token composition.\nTools and resources\nPosition review\n- Orca Portfolio — Track your positions and accrued fees\n- Price charts — Review price movement relative to your selected range\n- Position Simulator — Model estimated outcomes based on selected assumptions\nAlerts and monitoring\nSet up alerts for:\n- Price approaching range boundaries\n- Price moving out of range\n- Fee accumulation milestones\n- Changes you want to review manually\nLearn how: Creating Alerts\nThird-party tools\nThe Solana ecosystem includes third-party tools for portfolio tracking, analytics, and liquidity management.\nAlways review third-party tools carefully before connecting your wallet or signing transactions. Orca does not control third-party tools or their security practices.\nPosition review framework\nYou can use the following questions to review a position setup.\nHow often can you review the position?\n├── Frequently → Narrower or actively managed ranges may require more attention\n├── Occasionally → Medium or wider ranges may require less frequent adjustment\n└── Rarely → Full-range or wider-range positions may require less active review\nHow much price movement do you want to model?\n├── Lower movement → Narrower ranges may concentrate liquidity\n├── Moderate movement → Medium ranges may balance concentration and coverage\n└── Higher movement → Wider ranges may cover more price movement\nWhat token exposure are you comfortable holding?\n├── More token A exposure → Review ranges that may increase token A concentration\n├── More token B exposure → Review ranges that may increase token B concentration\n└── Balanced exposure → Review symmetric ranges around the selected price\nThis framework is informational only. It does not recommend a specific range, token pair, or liquidity position.\nCommon issues to watch for\n- Frequent rebalancing costs — Rebalancing too often can increase transaction costs and execution risk.\n- Ignoring impermanent loss — Position value may differ from simply holding the deposited tokens.\n- Relying only on displayed APR — High displayed APR can change and may reflect temporary pool or reward conditions.\n- Overlooking network and account costs — Onchain transactions may require network fees and account costs.\n- Leaving narrow ranges unattended — Narrow ranges can move out of range quickly during price movement.\nNext Steps\n- Understanding Impermanent Loss - Learn how impermanent loss works\n- Ticks and Fee Tiers - Technical mechanics\n- Creating Alerts - Monitor your positions\n- Range Orders - Learn about range-order-style positions\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.marinade.finance/llms.txt","domain":"docs.marinade.finance","title":"Marinade Documentation","hash":"e6199167fbd148eb37090f80df6e402e38463fcbf5f164efd7b1735722d7ba33","tokens":3093,"chars":12372,"crawler":"crawler-f6nn","verified":"exact","ts":1791172271139,"text":"# Marinade Documentation\n## English\n- [Welcome to Marinade](https://docs.marinade.finance/readme.md): The best place to stake your SOL.\n- [Marinade DAO](https://docs.marinade.finance/marinade-dao.md): Marinade.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.\n- [Contributors](https://docs.marinade.finance/marinade-dao/contributors.md): You will find here the internal structure of the mDAO and its team members.\n- [The MNDE token](https://docs.marinade.finance/the-mnde-token.md): Marinade’s MNDE token lets holders participate in the protocol's governance. This includes control of the DAO’s fees and treasury.\n- [MNDE Governance](https://docs.marinade.finance/governance.md): Marinade is governed by people that lock MNDE and obtain veMNDE.\n- [Official Links](https://docs.marinade.finance/official-links.md): If you want to join us, here is where you can find us!\n- [Protocol Overview](https://docs.marinade.finance/marinade-protocol/protocol-overview.md): Marinade Finance was built to bring to life a vision. A non-custodial liquid staking solution on Solana, decentralizing the network.\n- [Marinade Native](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-native.md): Marinade native is a tool to have your staked SOL managed and optimized automatically by Marinade's delegation strategy.\n- [Marinade Native: API & SDK](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-native/marinade-native-api-and-sdk.md)\n- [Marinade Select](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-select.md): Marinade Select is a curated set of trusted Solana validators offering secure, decentralized, and capital-efficient staking.\n- [Marinade Recipes](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-recipes.md): Stake SOL and receive your rewards in a token of your choice instead of more SOL. Principal stays in SOL. Also called Customized Rewards.\n- [Marinade Liquid](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-liquid.md)\n- [What is mSOL?](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-liquid/what-is-msol.md): mSOL represents your staked SOL in the Marinade stake pool. Here's what that means and how it unlocks your liquidity.\n- [mSOL Token](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-liquid/msol-token.md)\n- [Bot operations](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-liquid/bot-operations.md)\n- [Marinade Borrow](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-borrow.md): Borrow against mSOL collateral that keeps earning staking rewards while your loan is open.\n- [Marinade Instant Unstake](https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-instant-unstake.md): Learn how Instant Unstake works, when to use it, and how it differs from delayed unstaking.\n- [USDC Earn Vault](https://docs.marinade.finance/marinade-protocol/protocol-overview/usdc-earn-vault.md): Learn how to deposit USDC, earn yield automatically, and withdraw anytime with no lockup. This guide covers how the USDC Vault works, fees, and risks\n- [mTransactions](https://docs.marinade.finance/marinade-protocol/protocol-overview/mtransactions.md): mTransactions is an exploration of a bandwidth marketplace for transactions on the Solana blockchain\n- [Protected Staking Rewards](https://docs.marinade.finance/marinade-protocol/protocol-overview/protected-staking-rewards.md): Protected Staking Rewards (PSR) can compensate Marinade stakers for rewards lost to prolonged validator downtime and unexpected commission increases, using a bond the validator posts.\n- [Stake Auction Market (SAM)](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market.md): Marinade Native and Marinade Liquid delegate through the Stake Auction Marketplace, where validators compete by bidding to offer the highest yield to stakers.\n- [SAM Onboarding Guide](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/sam-onboarding-guide.md): Step-by-step onboarding for validators joining the Marinade Stake Auction Marketplace.\n- [Eligibility Criteria](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/eligibility-criteria.md): Requirements a validator must meet to receive stake from SAM, and how to exit cleanly.\n- [Stake Distribution and Decentralization](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/stake-distribution-and-decentralization.md): How Marinade allocates stake each epoch, how it reduces stake when needed, and the constraints that protect network decentralization.\n- [Blacklist Policy](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/blacklist-policy.md): Grounds for blacklisting a validator from the Marinade Stake Auction Marketplace, and the process for removal from the blacklist.\n- [Dynamic Bids](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/dynamic-bids.md): How dynamic commission bids work and how to configure them in the validator bonds CLI.\n- [maxStakeWanted Parameter](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/maxstakewanted-parameter.md): Cap the maximum amount of Marinade stake a validator wants to receive through SAM.\n- [Stake Matching](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/stake-matching.md): Marinade matches a portion of a validator's external stake with additional delegation, with no Protected Staking Rewards (PSR) slashable bond required on the matched portion.\n- [Bonds Settlements](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/bonds-settlements.md): How Marinade settles validator bids each epoch, with formula, worked example, and where to view settlements.\n- [Bid Reduction Penalty](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/bid-reduction-penalty.md): Penalty mechanics for validators who reduce their bid after receiving stake.\n- [Activating Stake Fee](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/activating-stake-fee.md): One-time fee charged when new stake activates, scaled by how far the validator bid above the auction clearing rate.\n- [Bond Risk Reduction Mechanism](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/bond-risk-reduction-mechanism.md): Covers the Bond Risk Reduction Mechanism: what triggers it, how the fee is calculated, and what validators need to do to avoid it.\n- [Bond Notifications](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/bond-notifications.md): How validators are notified of bond-related events including underfunding, auction status changes, and announcements.\n- [SAM Resources](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/sam-resources.md): Dashboards, repositories, APIs, and technical reference for SAM participants.\n- [Staking Rewards Report](https://docs.marinade.finance/marinade-protocol/protocol-overview/staking-rewards-report.md): Learn how to use the Staking Rewards Report to view and export your Marinade native staking rewards by epoch, and understand what the data represents.\n- [Fees and Pricing](https://docs.marinade.finance/marinade-protocol/protocol-overview/fees-and-pricing.md): A single reference for every fee across Marinade products: what each fee is, how it is calculated, whether it is fixed or variable, and which costs come from third parties rather than from Marinade.\n- [FAQ](https://docs.marinade.finance/marinade-protocol/faq.md): You'll find the answers to most of your questions here! If something is not yet answered, reach out to us on our Discord.\n- [Glossary](https://docs.marinade.finance/marinade-protocol/glossary.md)\n- [Security](https://docs.marinade.finance/marinade-protocol/security.md): Security has always been a primary concern for Marinade. We are doing everything we can to set a high standard for security in our protocol and in the Solana ecosystem.\n- [Audits](https://docs.marinade.finance/marinade-protocol/security/audits.md): You'll find here the list of our audits and code review reports.\n- [Principal Service Commitments and System Requirements](https://docs.marinade.finance/marinade-protocol/security/principal-service-commitments-and-system-requirements.md): An overview of Marinade Finance’s key commitments and technical controls to ensure security, availability, and compliance with SOC 2 standards.\n- [Multisig governance](https://docs.marinade.finance/marinade-protocol/security/multisig-governance.md): Marinade's on-chain authority is not a single multisig. It is split across four layers, and each layer authorizes different actions on different programs. Knowing which layer controls what is the poin\n- [Legal](https://docs.marinade.finance/marinade-protocol/legal.md)\n- [Terms of Use and Privacy Policy](https://docs.marinade.finance/marinade-protocol/legal/terms-of-use-and-privacy-policy.md): Terms of Use, Privacy Policy, and the legal terms governing use of the Marinade website and Services.\n- [Risks](https://docs.marinade.finance/marinade-protocol/legal/risks.md): Key risks associated with using the Marinade website and Services, including smart contract, validator, market, and third-party protocol risk.\n- [Disclaimer](https://docs.marinade.finance/marinade-protocol/legal/disclaimer.md): Disclaimers governing the use of the Marinade website and Services, provided on an as-is basis without warranties.\n- [Marinade Ts/Js SDK](https://docs.marinade.finance/developers/marinade-ts-js-sdk.md): This is a marinade typescript and anchor based SDK to interact with Marinade from any Front-End App\n- [Marinade Rust SDK](https://docs.marinade.finance/developers/marinade-rust-sdk.md): There is no supported standalone Rust SDK. If you are building in Rust, use one of the two routes below.\n- [Anchor IDL](https://docs.marinade.finance/developers/anchor-idl.md)\n- [Bug Bounty](https://docs.marinade.finance/developers/bug-bounty.md): Marinade is dedicated to improve the security of its users. For this reason, we are holding a bug bounty program to help strengthen our protocol even more.\n- [Contracts & Tokens Addresses](https://docs.marinade.finance/developers/contract-addresses.md): Here is a list of the smart contracts and tokens created by Marinade as well as details on their authorities\n- [Stake to Marinade via Fireblocks](https://docs.marinade.finance/developers/stake-to-marinade-via-fireblocks.md)\n- [Become our Partner](https://docs.marinade.finance/partnerships/become-our-partner.md)\n- [Marinade Press Kit](https://docs.marinade.finance/partnerships/marinade-press-kit.md): Please find official Marinade imagery below for your use. For additional info or media inquiries, contact press@marinade.finance\n- [Marinade Referral Program](https://docs.marinade.finance/partnerships/marinade-referral-program.md): Earn rewards by supporting Marinade’s mission to decentralize Solana. Marinade shares fees with both the referring partner and the staker, creating a win-win incentive.\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, you can query the documentation dynamically by asking a question.\nPerform an HTTP GET request on a page URL with the `ask` query parameter:\n```\nGET https://docs.marinade.finance/readme.md?ask=\n```\nThe question should be specific, self-contained, and written in natural language.\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://bitcoin.org/fr/acheter","domain":"bitcoin.org","title":"Buy Bitcoin","hash":"2a6782c14894794f8fe0ae1ee5a978af6dcaed9582031ee2f806f0f8f7390dd1","tokens":499,"chars":1994,"crawler":"crawler-f6nn","verified":"exact","ts":1791172273019,"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- Particuliers\n- Entreprises\n- Développeurs\n- Débuter\n- Comment ça marche\n- Vous devez savoir\n- Ressources\n- Exchanges\n- Communauté\n- BIPs list\n- Vocabulaire\n- Bitcoin Core\n- Innovation\n- Participer\n- Soutenir Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Développement\n- FAQ\n- Français\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: fr\nBuy Bitcoin\nThe above widget is provided by a third party provider ( MoonPay ) and is not associated with bitcoin.org.\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroduction:\n-\nParticuliers\n-\nEntreprises\n-\nDéveloppeurs\n-\nDébuter\n-\nComment ça marche\n-\nVous devez savoir\nRessources:\n-\nRessources\n-\nExchanges\n-\nCommunauté\n-\nBIPs list\n-\nVocabulaire\n-\nBitcoin Core\nParticiper:\n-\nSoutenir Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nDéveloppement\nOther:\nLégal\nPrivacy Policy\nPresse\nÀ propos de bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Publié sous la licence MIT\nNetwork Status\n- Français\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- 繁體中文\nfr"}
{"url":"https://bitcoin.org/ar/","domain":"bitcoin.org","title":"البت كوين - عملة ند-للند \"P2P\" مفتوحة المصدر","hash":"254cdee15852451dfb0cdf87ff14d05b2940e55c2aae38cfd5940fb0d90c6286","tokens":613,"chars":2450,"crawler":"crawler-f6nn","verified":"exact","ts":1791172274943,"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- المقدمة\n- الأفراد\n- الأعمال\n- المطورين\n- البداية\n- كيف يعمل\n- يجب عليك معرفة\n- المصادر\n- Exchanges\n- المجتمع\n- BIPs list\n- المفردات\n- Bitcoin Core\n- الإبتكار\n- المشاركة\n- دعم البت كوين\n- Buy Bitcoin\n- Sell Bitcoin\n- التطوير\n- الأسئلة الشائعة\n- العربية\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: ar\nالبت كوين هي شبكة دفع مبتكرة وشكل جديد للأموال\nإبدأ الآن مع البت كوين\nقم بإختيار محفظتك\nBuy Bitcoin\nأو قم بإلقاء نظرة عامة على\nالأفراد\nLearn more\nالأعمال\nLearn more\nالمطورين\nLearn more\nإبدأ الآن مع البت كوين\nتستخدم البت كوين تكنولوجيا الند-للند لكي تعمل بدون سلطات مركزية أو بنوك؛ إدارة المعاملات وإصدار عملات البت كوين تتم إجمالاً بواسطة الشبكة. البت كوين مفتوحة المصدر؛ تصميمها مفتوح للعامة، لا أحد يملك أو يدير شبكة البت كوين و يمكن لأي أحد المشاركة . من خلال العديد من خصائصها الفريدة، تسمح البت كوين بإستخدامات مثيرة لم يكن من الممكن تغطيتها من قبل أي نظام دفع سابق.\n-\nمعاملات\nند-للند فورية\n-\nمدفوعات\nعالمية\n-\nرسوم معالجة\nقليلة أو غير موجودة\nإبدأ الآن مع البت كوين\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nالمقدمة:\n-\nالأفراد\n-\nالأعمال\n-\nالمطورين\n-\nالبداية\n-\nكيف يعمل\n-\nيجب عليك معرفة\nالمصادر:\n-\nالمصادر\n-\nExchanges\n-\nالمجتمع\n-\nBIPs list\n-\nالمفردات\n-\nBitcoin Core\nالمشاركة:\n-\nدعم البت كوين\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nالتطوير\nOther:\nالمسائل القانونية\nPrivacy Policy\nصحافة\nحول موقع bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 مصدر تحت MIT ترخيص\nNetwork Status\n- العربية\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- 繁體中文\nar"}
{"url":"https://eips.ethereum.org/core","domain":"eips.ethereum.org","title":"Core | Ethereum Improvement Proposals","hash":"f22ea3c39d236964a28eefe411a52fd4a2a2ffe13f1bb216c58409daabe18d93","tokens":9977,"chars":39908,"crawler":"crawler-f6nn","verified":"exact","ts":1791172277387,"text":"Ethereum Improvement Proposals\nCore\nFinal\nNumber Title Author\n2\nHomestead Hard-fork Changes\nVitalik Buterin ( @vbuterin )\n5\nGas Usage for `RETURN` and `CALL*`\nChristian Reitwiessner < c@ethdev.com >\n7\nDELEGATECALL\nVitalik Buterin ( @vbuterin )\n100\nChange difficulty adjustment to target mean block time including uncles\nVitalik Buterin ( @vbuterin )\n140\nREVERT instruction\nAlex Beregszaszi ( @axic ), Nikolai Mushegian < nikolai@nexusdev.us >\n141\nDesignated invalid EVM instruction\nAlex Beregszaszi ( @axic )\n145\nBitwise shifting instructions in EVM\nAlex Beregszaszi ( @axic ), Paweł Bylica ( @chfast )\n150\nGas cost changes for IO-heavy operations\nVitalik Buterin ( @vbuterin )\n152\nAdd BLAKE2 compression function `F` precompile\nTjaden Hess < tah83@cornell.edu >, Matt Luongo ( @mhluongo ), Piotr Dyraga ( @pdyraga ), James Hancock ( @MadeOfTin )\n155\nSimple replay attack protection\nVitalik Buterin ( @vbuterin )\n158\nState clearing\nVitalik Buterin ( @vbuterin )\n160\nEXP cost increase\nVitalik Buterin ( @vbuterin )\n161\nState trie clearing (invariant-preserving alternative)\nGavin Wood ( @gavofyork )\n170\nContract code size limit\nVitalik Buterin ( @vbuterin )\n196\nPrecompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128\nChristian Reitwiessner < chris@ethereum.org >\n197\nPrecompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128\nVitalik Buterin < vitalik@ethereum.org >, Christian Reitwiessner < chris@ethereum.org >\n198\nBig integer modular exponentiation\nVitalik Buterin ( @vbuterin )\n211\nNew opcodes: RETURNDATASIZE and RETURNDATACOPY\nChristian Reitwiessner < chris@ethereum.org >\n214\nNew opcode STATICCALL\nVitalik Buterin < vitalik@ethereum.org >, Christian Reitwiessner < chris@ethereum.org >\n225\nClique proof-of-authority consensus protocol\nPéter Szilágyi < peterke@gmail.com >\n649\nMetropolis Difficulty Bomb Delay and Block Reward Reduction\nAfri Schoedon ( @5chdn ), Vitalik Buterin ( @vbuterin )\n658\nEmbedding transaction status code in receipts\nNick Johnson < nick@ethereum.org >\n684\nRevert creation in case of collision\nVitalik Buterin ( @vbuterin ), Renan Rodrigues de Souza ( @RenanSouza2 )\n1014\nSkinny CREATE2\nVitalik Buterin ( @vbuterin )\n1052\nEXTCODEHASH opcode\nNick Johnson < arachnid@notdot.net >, Paweł Bylica < pawel@ethereum.org >\n1108\nReduce alt_bn128 precompile gas costs\nAntonio Salazar Cardozo ( @shadowfiend ), Zachary Williamson ( @zac-williamson )\n1153\nTransient storage opcodes\nAlexey Akhunov ( @AlexeyAkhunov ), Moody Salem ( @moodysalem )\n1234\nConstantinople Difficulty Bomb Delay and Block Reward Adjustment\nAfri Schoedon ( @5chdn )\n1283\nNet gas metering for SSTORE without dirty maps\nWei Tang ( @sorpaas )\n1344\nChainID opcode\nRichard Meissner ( @rmeissner ), Bryant Eisenbach ( @fubuloubu )\n1559\nFee market change for ETH 1.0 chain\nVitalik Buterin ( @vbuterin ), Eric Conner ( @econoar ), Rick Dudley ( @AFDudley ), Matthew Slipper ( @mslipper ), Ian Norden ( @i-norden ), Abdelhamid Bakhta ( @abdelhamidbakhta )\n1884\nRepricing for trie-size-dependent opcodes\nMartin Holst Swende ( @holiman )\n2028\nTransaction data gas cost reduction\nAlexey Akhunov ( @AlexeyAkhunov ), Eli Ben Sasson < eli@starkware.co >, Tom Brand < tom@starkware.co >, Louis Guthmann < louis@starkware.co >, Avihu Levy < avihu@starkware.co >\n2200\nStructured Definitions for Net Gas Metering\nWei Tang ( @sorpaas )\n2384\nMuir Glacier Difficulty Bomb Delay\nEric Conner ( @econoar )\n2537\nPrecompile for BLS12-381 curve operations\nAlex Vlasov ( @shamatar ), Kelly Olson ( @ineffectualproperty ), Alex Stokes ( @ralexstokes ), Antonio Sanso ( @asanso )\n2565\nModExp Gas Cost\nKelly Olson ( @ineffectualproperty ), Sean Gulley ( @sean-sn ), Simon Peffers ( @simonatsn ), Justin Drake ( @justindrake ), Dankrad Feist ( @dankrad )\n2681\nLimit account nonce to 2^64-1\nAlex Beregszaszi ( @axic )\n2718\nTyped Transaction Envelope\nMicah Zoltu ( @MicahZoltu )\n2929\nGas cost increases for state access opcodes\nVitalik Buterin ( @vbuterin ), Martin Swende ( @holiman )\n2930\nOptional access lists\nVitalik Buterin ( @vbuterin ), Martin Swende ( @holiman )\n2935\nServe historical block hashes from state\nVitalik Buterin ( @vbuterin ), Tomasz Stanczak ( @tkstanczak ), Guillaume Ballet ( @gballet ), Gajinder Singh ( @g11tech ), Tanishq Jasoria ( @tanishqjasoria ), Ignacio Hagopian ( @jsign ), Jochem Brouwer ( @jochem-brouwer ), Sina Mahmoodi ( @s1na )\n3198\nBASEFEE opcode\nAbdelhamid Bakhta ( @abdelhamidbakhta ), Vitalik Buterin ( @vbuterin )\n3529\nReduction in refunds\nVitalik Buterin ( @vbuterin ), Martin Swende ( @holiman )\n3541\nReject new contract code starting with the 0xEF byte\nAlex Beregszaszi ( @axic ), Paweł Bylica ( @chfast ), Andrei Maiboroda ( @gumb0 ), Alexey Akhunov ( @AlexeyAkhunov ), Christian Reitwiessner ( @chriseth ), Martin Swende ( @holiman )\n3554\nDifficulty Bomb Delay to December 2021\nJames Hancock ( @madeoftin )\n3607\nReject transactions from senders with deployed code\nDankrad Feist ( @dankrad ), Dmitry Khovratovich ( @khovratovich ), Marius van der Wijden ( @MariusVanDerWijden )\n3651\nWarm COINBASE\nWilliam Morriss ( @wjmelements )\n3675\nUpgrade consensus to Proof-of-Stake\nMikhail Kalinin ( @mkalinin ), Danny Ryan ( @djrtwo ), Vitalik Buterin ( @vbuterin )\n3855\nPUSH0 instruction\nAlex Beregszaszi ( @axic ), Hugo De la cruz ( @hugo-dc ), Paweł Bylica ( @chfast )\n3860\nLimit and meter initcode\nMartin Holst Swende ( @holiman ), Paweł Bylica ( @chfast ), Alex Beregszaszi ( @axic ), Andrei Maiboroda ( @gumb0 )\n4345\nDifficulty Bomb Delay to June 2022\nTim Beiko ( @timbeiko ), James Hancock ( @MadeOfTin ), Thomas Jay Rush ( @tjayrush )\n4399\nSupplant DIFFICULTY opcode with PREVRANDAO\nMikhail Kalinin ( @mkalinin ), Danny Ryan ( @djrtwo )\n4788\nBeacon block root in the EVM\nAlex Stokes ( @ralexstokes ), Ansgar Dietrichs ( @adietrichs ), Danny Ryan ( @djrtwo ), Martin Holst Swende ( @holiman ), lightclient ( @lightclient )\n4844\nShard Blob Transactions\nVitalik Buterin ( @vbuterin ), Dankrad Feist ( @dankrad ), Diederik Loerakker ( @protolambda ), George Kadianakis ( @asn-d6 ), Matt Garnett ( @lightclient ), Mofi Taiwo ( @Inphi ), Ansgar Dietrichs ( @adietrichs )\n4895\nBeacon chain push withdrawals as operations\nAlex Stokes ( @ralexstokes ), Danny Ryan ( @djrtwo )\n5133\nDelaying Difficulty Bomb to mid-September 2022\nTomasz Kajetan Stanczak ( @tkstanczak ), Eric Marti Haynes ( @ericmartihaynes ), Josh Klopfenstein ( @joshklop ), Abhimanyu Nag ( @AbhiMan1601 )\n5656\nMCOPY - Memory copying instruction\nAlex Beregszaszi ( @axic ), Paul Dworzanski ( @poemm ), Jared Wasinger ( @jwasinger ), Casey Detrio ( @cdetrio ), Pawel Bylica ( @chfast ), Charles Cooper ( @charles-cooper )\n6110\nSupply validator deposits on chain\nMikhail Kalinin ( @mkalinin ), Danny Ryan ( @djrtwo ), Peter Davies ( @petertdavies )\n6780\nSELFDESTRUCT only in same transaction\nGuillaume Ballet ( @gballet ), Vitalik Buterin ( @vbuterin ), Dankrad Feist ( @dankrad )\n6916\nAutomatically Reset Testnet\nMário Havel ( @taxmeifyoucan ), pk910 ( @pk910 ), Rémy Roy ( @remyroy ), Holly Atkinson ( @atkinsonholly ), Tereza Burianova ( @T-ess )\n7002\nExecution layer triggerable withdrawals\nDanny Ryan ( @djrtwo ), Mikhail Kalinin ( @mkalinin ), Ansgar Dietrichs ( @adietrichs ), Hsiao-Wei Wang ( @hwwhww ), lightclient ( @lightclient ), Felix Lange ( @fjl )\n7044\nPerpetually Valid Signed Voluntary Exits\nLion ( @dapplion )\n7045\nIncrease max attestation inclusion slot\nDanny Ryan ( @djrtwo )\n7251\nIncrease the MAX_EFFECTIVE_BALANCE\nmike ( @michaelneuder ), Francesco ( @fradamt ), dapplion ( @dapplion ), Mikhail ( @mkalinin ), Aditya ( @adiasg ), Justin ( @justindrake ), lightclient ( @lightclient ), Felix Lange ( @fjl )\n7514\nAdd Max Epoch Churn Limit\ndapplion ( @dapplion ), Tim Beiko ( @timbeiko )\n7516\nBLOBBASEFEE instruction\nCarl Beekhuizen ( @carlbeek )\n7549\nMove committee index outside Attestation\ndapplion ( @dapplion ), Mikhail Kalinin ( @mkalinin )\n7594\nPeerDAS - Peer Data Availability Sampling\nDanny Ryan ( @djrtwo ), Dankrad Feist ( @dankrad ), Francesco D'Amato ( @fradamt ), Hsiao-Wei Wang ( @hwwhww ), Alex Stokes ( @ralexstokes )\n7623\nIncrease calldata cost\nToni Wahrstätter ( @nerolation ), Vitalik Buterin ( @vbuterin )\n7685\nGeneral purpose execution layer requests\nlightclient ( @lightclient ), Felix Lange ( @fjl )\n7691\nBlob throughput increase\nParithosh Jayanthi ( @parithosh ), Toni Wahrstätter ( @nerolation ), Sam Calder-Mason ( @samcm ), Andrew Davis ( @savid ), Ansgar Dietrichs ( @adietrichs )\n7702\nSet Code for EOAs\nVitalik Buterin ( @vbuterin ), Sam Wilson ( @SamWilsn ), Ansgar Dietrichs ( @adietrichs ), lightclient ( @lightclient )\n7823\nSet upper bounds for MODEXP\nAlex Beregszaszi ( @axic ), Radoslaw Zagorowicz ( @rodiazet )\n7825\nTransaction Gas Limit Cap\nGiulio Rebuffo ( @Giulio2002 ), Toni Wahrstätter ( @nerolation )\n7883\nModExp Gas Cost Increase\nMarcin Sobczak ( @marcindsobczak ), Marek Moraczyński ( @MarekM25 ), Marcos Maceo ( @stdevMac )\n7917\nDeterministic proposer lookahead\nLin Oshitani (@linoscope) < lin@nethermind.io >, Justin Drake (@JustinDrake) < justin@ethereum.org >\n7918\nBlob base fee bounded by execution cost\nAnders Elowsson ( @anderselowsson ), Ben Adams ( @benaadams ), Francesco D'Amato ( @fradamt )\n7934\nRLP Execution Block Size Limit\nGiulio Rebuffo ( @Giulio2002 ), Ben Adams ( @benaadams ), Storm Slivkoff ( @sslivkoff )\n7939\nCount leading zeros (CLZ) opcode\nVectorized ( @Vectorized ), Georgios Konstantopoulos ( @gakonst ), Jochem Brouwer ( @jochem-brouwer ), Ben Adams ( @benaadams ), Giulio Rebuffo ( @Giulio2002 )\n7951\nPrecompile for secp256r1 Curve Support\nCarl Beekhuizen ( @carlbeek ), Ulaş Erdoğan ( @ulerdogan ), Doğan Alpaslan ( @doganalpaslan )\nLast Call\nNumber Review ends Title Author\n7523\n2024-03-26\nEmpty accounts deprecation\nPeter Davies ( @petertdavies )\n7610\n2024-11-20\nRevert creation in case of non-empty storage\nGary Rong ( @rjl493456442 ), Martin Holst Swende ( @holiman )\n8246\n2026-11-04\nRemove SELFDESTRUCT Burn\nPaweł Bylica ( @chfast )\nReview\nNumber Title Author\n2780\nResource-based intrinsic transaction gas\nMatt Garnett ( @lightclient ), Uri Klarman ( @uriklarman ), Ben Adams ( @benaadams ), Maria Inês Silva ( @misilva73 ), Anders Elowsson ( @anderselowsson ), Anthony Sassano ( @sassal ), Dragan Rakita ( @rakita )\n7495\nSSZ ProgressiveContainer\nEtan Kissling ( @etan-status ), Cayman ( @wemeetagain )\n7688\nForward compatible consensus data structures\nEtan Kissling ( @etan-status ), Cayman ( @wemeetagain )\n7708\nETH transfers emit a log\nVitalik Buterin ( @vbuterin ), Peter Davies ( @petertdavies ), Etan Kissling ( @etan-status ), Gajinder Singh ( @g11tech ), Carson ( @carsons-eels ), Jared Wasinger ( @jwasinger )\n7732\nEnshrined Proposer-Builder Separation\nFrancesco D'Amato < francesco.damato@ethereum.org >, Nico Flaig < nflaig@protonmail.com >, Barnabé Monnot < barnabe.monnot@ethereum.org >, Michael Neuder < michael.neuder@ethereum.org >, Potuz ( @potuz ), Justin Traglia < jtraglia@ethereum.org >, Terence Tsao < ttsao@offchainlabs.com >\n7778\nBlock Gas Accounting without Refunds\nBen Adams ( @benaadams ), Toni Wahrstätter ( @nerolation )\n7784\nGETCONTRACT opcode\nTim Pechersky ( @peersky )\n7834\nSeparate Metadata Section for EOF\nKaan Uzdogan ( @kuzdogan ), Marco Castignoli ( @marcocastignoli ), Manuel Wedler ( @manuelwedler )\n7843\nSLOTNUM opcode\nMarc Harvey-Hill ( @Marchhill )\n7880\nEOF - EXTCODEADDRESS instruction\nDanno Ferrin ( @shemnon )\n7916\nSSZ ProgressiveList\nZsolt Felföldi ( @zsfelfoldi ), Cayman ( @wemeetagain ), Etan Kissling ( @etan-status )\n7928\nBlock-Level Access Lists\nToni Wahrstätter ( @nerolation ), Dankrad Feist ( @dankrad ), Francesco D`Amato ( @fradamt ), Jochem Brouwer ( @jochem-brouwer ), Ignacio Hagopian ( @jsign ), Felipe Selmo ( @fselmo ), Rahul ( @raxhvl ), Stefan ( @qu0b )\n7954\nIncrease Maximum Contract Size\nGiulio Rebuffo ( @Giulio2002 ), Ben Adams ( @benaadams )\n7976\nIncrease Calldata Floor Cost\nToni Wahrstätter ( @nerolation )\n7981\nIncrease Access List Cost\nToni Wahrstätter ( @nerolation )\n7997\nDeterministic Factory Contract\nFrancisco Giordano ( @frangio ), Toni Wahrstätter ( @nerolation ), Nick Johnson ( @Arachnid ), Jochem Brouwer ( @jochem-brouwer )\n8024\nBackward compatible SWAPN, DUPN, EXCHANGE\nFrancisco Giordano ( @frangio ), Charles Cooper ( @charles-cooper ), Alex Beregszaszi ( @axic ), Paweł Bylica ( @chfast )\n8037\nState Creation Gas Cost Increase\nMaria Silva ( @misilva73 ), Carlos Perez ( @CPerezz ), Jochem Brouwer ( @jochem-brouwer ), Ansgar Dietrichs ( @adietrichs ), Łukasz Rozmej ( @LukaszRozmej ), Anders Elowsson ( @anderselowsson ), Francesco D'Amato ( @fradamt ), Dragan Rakita ( @rakita ), Paweł Bylica ( @chfast ), Spencer Taylor-Brown ( @spencer-tb ), Gary Rong ( @rjl493456442 )\n8038\nState-access gas cost update\nMaria Silva ( @misilva73 ), Wei Han Ng ( @weiihann ), Ansgar Dietrichs ( @adietrichs )\n8045\nExclude slashed validators from proposing\nFrancesco D'Amato ( @fradamt ), Barnabas Busa ( @barnabasbusa )\n8061\nIncrease exit and consolidation churn\nFrancesco D'Amato ( @fradamt ), Anders Elowsson ( @anderselowsson )\n8163\nReserve `EXTENSION (0xae)` opcode\nBruce Collie ( @Baltoli ), Piotr Dobaczewski ( @pdobacz )\n8182\nPrivate ETH and ERC-20 Transfers\nTom Lehman ( @RogerPodacter )\n8282\nBuilder Execution Requests\nCayman ( @wemeetagain ), Nico Flaig < nflaig@protonmail.com >, Felix Lange < fjl@ethereum.org >, Justin Traglia < jtraglia@ethereum.org >\nDraft\nNumber Title Author\n2926\nChunk-Based Code Merkleization\nSina Mahmoodi ( @s1na ), Alex Beregszaszi ( @axic ), Guillaume Ballet ( @gballet ), Jochem Brouwer ( @jochem-brouwer ), Ignacio Hagopian ( @jsign )\n3298\nRemove storage-clear refund and refund cap\nVitalik Buterin ( @vbuterin ), Martin Swende ( @holiman ), Jochem Brouwer ( @jochem-brouwer )\n4762\nStatelessness gas cost changes\nGuillaume Ballet ( @gballet ), Vitalik Buterin ( @vbuterin ), Dankrad Feist ( @dankrad ), Ignacio Hagopian ( @jsign ), Tanishq Jasoria ( @tanishqjasoria ), Gajinder Singh ( @g11tech )\n5920\nPAY opcode\nGavin John ( @Pandapip1 ), Zainan Victor Zhou ( @xinbenlv ), Sam Wilson ( @SamWilsn ), Jochem Brouwer ( @jochem-brouwer ), Charles Cooper ( @charles-cooper )\n6404\nSSZ transactions\nEtan Kissling ( @etan-status ), Gajinder Singh ( @g11tech ), Vitalik Buterin ( @vbuterin )\n6465\nSSZ withdrawals root\nEtan Kissling ( @etan-status ), Mikhail Kalinin ( @mkalinin )\n6466\nSSZ receipts\nEtan Kissling ( @etan-status ), Gajinder Singh ( @g11tech ), Vitalik Buterin ( @vbuterin )\n6493\nSSZ transaction signature scheme\nEtan Kissling ( @etan-status ), Gajinder Singh ( @g11tech ), Matt Garnett ( @lightclient ), Vitalik Buterin ( @vbuterin )\n7619\nPrecompile Falcon512 generic verifier\nErick Pacheco Pedraza ( @eum602 ), Marcos Allende < mallende@lacnet.com >, Diego Lopez León < dieguitoll@gmail.com >\n7666\nEVM-ify the identity precompile\nVitalik Buterin ( @vbuterin ), Kevaundray Wedderburn ( @kevaundray )\n7709\nRead BLOCKHASH from Storage and Update Cost\nVitalik Buterin ( @vbuterin ), Tomasz Stanczak ( @tkstanczak ), Guillaume Ballet ( @gballet ), Gajinder Singh ( @g11tech ), Tanishq Jasoria ( @tanishqjasoria ), Ignacio Hagopian ( @jsign ), Jochem Brouwer ( @jochem-brouwer ), Gabriel Rocheleau ( @gabrocheleau )\n7716\nAnti-Correlation Attestation Penalties\ndapplion ( @dapplion ), Toni Wahrstätter ( @nerolation ), Vitalik Buterin ( @vbuterin ), Oisín Kyne ( @OisinKyne )\n7745\nTrustless log and transaction index\nZsolt Felföldi ( @zsfelfoldi )\n7748\nState conversion to Verkle Tree\nGuillaume Ballet ( @gballet ), Ignacio Hagopian ( @jsign ), Gajinder Singh ( @g11tech ), Ansgar Dietrichs ( @adietrichs ), Gottfried Herold ( @GottfriedHerold ), Jamie Lokier ( @jlokier ), Tanishq Jasoria ( @tanishqjasoria ), Parithosh Jayanthi ( @parithosh ), Gabriel Rocheleau ( @gabrocheleau ), Karim Taam ( @matkt )\n7782\nReduce Block Latency\nBen Adams ( @benaadams ), Dankrad Feist ( @dankrad ), Maria Inês Silva ( @misilva73 ), Paul Harris ( @rolfyone )\n7791\nGAS2ETH opcode\nCharles Cooper ( @charles-cooper ), pcaversaccio ( @pcaversaccio )\n7799\nSystem logs\nEtan Kissling ( @etan-status ), Gajinder Singh ( @g11tech )\n7804\nWithdrawal Credential Update Request\nLucas Saldanha ( @lucassaldanha ), Mikhail Kalinin ( @mkalinin )\n7805\nFork-choice enforced Inclusion Lists (FOCIL)\nThomas Thiery (@soispoke) < thomas.thiery@ethereum.org >, Francesco D'Amato < francesco.damato@ethereum.org >, Julian Ma < julian.ma@ethereum.org >, Barnabé Monnot < barnabe.monnot@ethereum.org >, Terence Tsao < ttsao@offchainlabs.com >, Jacob Kaufmann < jacob.kaufmann@ethereum.org >, Jihoon Song < jihoon.song@ethereum.org >\n7807\nSSZ execution blocks\nEtan Kissling ( @etan-status ), Gajinder Singh ( @g11tech )\n7819\nSETDELEGATE instruction\nHadrien Croubois ( @amxx )\n7848\nOn-chain upgrade signaling\nWilliam Entriken ( @fulldecent )\n7851\nCode-Controlled EOA Delegation\nLiyi Guo ( @colinlyguo ), Nicolas Consigny ( @nconsigny )\n7862\nDelayed State Root\nCharlie Noyes < charlie@paradigm.xyz >, Dan Robinson < dan@paradigm.xyz >, Justin Drake < justin@ethereum.org >, Toni Wahrstätter ( @nerolation )\n7863\nBlock-level Warming\nToni Wahrstätter ( @nerolation ), Jochem Brouwer ( @jochem-brouwer ), Alex Stokes ( @ralexstokes ), Ansgar Dietrichs ( @adietrichs ), Yoav Weiss ( @yoavw ), Alex Forshtat ( @forshtat )\n7864\nEthereum state using a unified binary tree\nVitalik Buterin ( @vbuterin ), Guillaume Ballet ( @gballet ), Dankrad Feist ( @dankrad ), Ignacio Hagopian ( @jsign ), Kevaundray Wedderburn ( @kevaundray ), Tanishq Jasoria ( @tanishqjasoria ), Gajinder Singh ( @g11tech ), Danno Ferrin ( @shemnon ), Piper Merriam ( @pipermerriam ), Gottfried Herold ( @GottfriedHerold )\n7885\nPrecompile for NTT operations\nRenaud Dubois ( @rdubois-crypto ), Simon Masson ( @simonmasson ), Yoon Hyoung Lee ( @yhl125 )\n7906\nTransaction Assertions via State Diff Opcode\nAlex Forshtat ( @forshtat ), Shahaf Nacson ( @shahafn ), Dror Tirosh ( @drortirosh ), Yoav Weiss ( @yoavw ), Fredrik Svantes ( @0xfredrik ), Daniil Ankushin ( @AnkushinDaniil )\n7907\nMeter Contract Code Size\nCharles Cooper ( @charles-cooper ), Qi Zhou ( @qizhou ), Matt ( @lightclient ), Dragan Rakita ( @rakita ), Ben Adams ( @benaadams )\n7911\nScaling Ethereum with a Perceptron Tree ZKP\nRyo Ha (@sopia19910) < sopia19910@gmail.com >, Khajiev Nizomjon (@khajievN) < nizom7812@gmail.com >\n7923\nLinear, Page-Based Memory Costing\nCharles Cooper ( @charles-cooper ), Qi Zhou ( @qizhou )\n7932\nSecondary Signature Algorithms\nJames Kempton ( @SirSpudlington )\n7937\nEVM64 - 64-bit mode EVM opcodes\nWei Tang ( @sorpaas )\n7942\nAvailable Attestation\nMingfei Zhang (@Mart1i1n) < mingfei.zh@outlook.com >, Rujia Li < rujia@tsinghua.edu.cn >, Xueqian Lu < xueqian.lu@bitheart.org >, Sisi Duan < duansisi@tsinghua.edu.cn >\n7960\nEOF - Extended types section\nWei Tang ( @sorpaas )\n7961\nEVM64 - EOF code section\nWei Tang ( @sorpaas )\n7971\nHard Limits for Transient Storage\nCharles Cooper ( @charles-cooper ), Ben Adams ( @benaadams ), Maria Silva ( @misilva73 ), Jochem Brouwer ( @jochem-brouwer )\n7973\nWarm Account Write Metering\nCharles Cooper ( @charles-cooper ), Maria Silva ( @misilva73 ), Ben Adams ( @benaadams )\n7979\nCall and Return Opcodes for the EVM\nGreg Colvin (@gcolvin) < greg@colvin.org >, Martin Holst Swende ( @holiman ), Brooklyn Zelenka ( @expede ), John Max Skaller\n7998\nTurn `randao_reveal` into a VRF\nAlberto La Rocca ( @71104 ), Aryaethn ( @aryaethn )\n7999\nUnified multidimensional fee market\nAnders Elowsson ( @anderselowsson ), Vitalik Buterin ( @vbuterin ), Maria Silva ( @misilva73 )\n8011\nMultidimensional Gas Metering\nMaria Silva ( @misilva73 ), Davide Crapis ( @dcrapis ), Anders Elowsson ( @anderselowsson ), Toni Wahrstätter ( @nerolation )\n8013\nStatic relative jumps and calls for the EVM\nGreg Colvin ( @gcolvin ), Alex Beregszaszi ( @axic ), Andrei Maiboroda ( @gumb0 ), Paweł Bylica ( @chfast )\n8015\nRemove `deposit` and `eth1data` fields\nTerence ( @terencechain ), Etan Kissling ( @etan-status )\n8016\nSSZ CompatibleUnion\nEtan Kissling ( @etan-status ), Cayman ( @wemeetagain )\n8025\nOptional Execution Proofs\nKevaundray Wedderburn ( @kevaundray ), Justin Drake (@JustinDrake) < justin@ethereum.org >, Ignacio Hagopian ( @jsign ), Han ( @han0110 ), Francesco Risitano ( @frisitano ), Cody Gunton ( @codygunton )\n8030\nP256 algorithm support\nJames Kempton ( @SirSpudlington )\n8032\nSize-Based Storage Gas Pricing\nGuillaume Ballet ( @gballet ), Carlos Perez ( @CPerezz ), Matan Prasma ( @KanExtension ), Wei Han Ng ( @weiihann )\n8046\nUniform price auction over inclusion lists\nAnders Elowsson ( @anderselowsson )\n8051\nPrecompile for ML-DSA signature verification\nRenaud Dubois ( @rdubois-crypto ), Simon Masson ( @simonmasson )\n8052\nPrecompile for Falcon support\nRenaud Dubois ( @rdubois-crypto ), Simon Masson ( @simonmasson ), Antonio Sanso ( @asanso ), Marius van der Wijden ( @mariusvanderwijden ), Kevaundray Wedderburn ( @kevaundray ), Zhenfei Zhang ( @zhenfeizhang ), Nicolas Consigny ( @nconsigny )\n8053\nMilli-gas for High-precision Gas Metering\nMaria Silva ( @misilva73 )\n8057\nInter-Block Temporal Locality Gas Discounts\nBen Adams ( @benaadams ), Toni Wahrstätter ( @nerolation ), Maria Inês Silva ( @misilva73 ), Amirul Ashraf ( @asdacap )\n8058\nContract Bytecode Deduplication Discount\nCarlos Perez ( @CPerezz ), Wei Han Ng ( @weiihann ), Guillaume Ballet ( @gballet )\n8059\nGas Units Rebase for High-precision Metering\nMaria Silva ( @misilva73 )\n8062\nAdd sweep withdrawal fee for 0x01 validators\nAnders Elowsson ( @anderselowsson ), Toni Wahrstätter ( @nerolation ), Francesco D'Amato ( @fradamt ), Ben Adams ( @benaadams ), Maria Inês Silva ( @misilva73 )\n8068\nNeutral effective balance design\nAnders Elowsson ( @anderselowsson )\n8071\nPrevent using consolidations as withdrawals\nMikhail Kalinin ( @mkalinin ), Francesco D'Amato ( @fradamt )\n8075\nAdaptive state cost to cap growth & scale L1\nAnders Elowsson ( @anderselowsson ), Francesco D'Amato ( @fradamt ), Maria Silva ( @misilva73 )\n8079\nNative rollups\nLuca Donno (@lucadonnoh) < donnoh@l2beat.com >, Justin Drake (@JustinDrake) < justin@ethereum.org >\n8080\nLet exits use the consolidation queue\nFrancesco D'Amato ( @fradamt )\n8096\nIncrease Gas Cost of Point Evaluation\nMarcin Sobczak ( @marcindsobczak ), Kamil Chodoła ( @kamilchodola ), Marek Moraczyński ( @MarekM25 )\n8099\nMEVless Protocol\nLawliet Chan ( @lawliet-chan )\n8101\nPayload Chunking with Chunk Access Lists\nToni Wahrstätter ( @nerolation ), Milos Stankovic ( @morph-dev ), Jihoon Song ( @jihoonsong ), Bharath Vedartham ( @bharath-123 ), Raúl Kripalani ( @raulk )\n8105\nUniversal Enshrined Encrypted Mempool\nJannik Luhn ( @jannikluhn )\n8115\nBatch priority fees at end of block\nEtan Kissling ( @etan-status ), Gajinder Singh ( @g11tech )\n8116\nReplace cumulative receipt fields\nEtan Kissling ( @etan-status ), Gajinder Singh ( @g11tech )\n8120\nMLOAD8 and CALLDATALOAD8 Opcodes\nHelkomine ( @Helkomine )\n8125\nTemporary Contract Storage\nWei Han Ng ( @weiihann )\n8130\nKeystore Accounts\nChris Hunter (@chunter-cb) < chris.hunter@coinbase.com >\n8131\nUnified Transaction Content Floor\nToni Wahrstätter ( @nerolation )\n8141\nFrame Transaction\nVitalik Buterin ( @vbuterin ), lightclient ( @lightclient ), Felix Lange ( @fjl ), Yoav Weiss ( @yoavw ), Alex Forshtat ( @forshtat ), Dror Tirosh ( @drortirosh ), Shahaf Nacson ( @shahafn ), Derek Chiang ( @derekchiang ), Toni Wahrstätter ( @nerolation ), Stavros Vlachakis ( @svlachakis )\n8142\nBlock-in-Blobs (BiB)\nKevaundray Wedderburn ( @kevaundray ), Ignacio Hagopian ( @jsign ), Jihoon Song < jihoon.song@ethereum.org >, Francesco Risitano ( @frisitano ), Thomas Thiery (@soispoke) < thomas.thiery@ethereum.org >, Toni Wahrstätter ( @nerolation ), Péter Garamvölgyi ( @thegaram )\n8146\nBlock Access List Sidecars\nToni Wahrstätter ( @nerolation ), Raúl Kripalani ( @raulk )\n8148\nCustom sweep threshold for validators\nDmitry Gusakov ( @dgusakov ), Dmitry Chernukhin ( @madlabman ), Greg Koumoutsos ( @gkoumout ), Manu ( @nalepae )\n8149\nMulti KZG Point Evaluation Precompile\nChris Mata ( @protocolwhisper )\n8151\nAccount Code Restricted ecRecover\nLiyi Guo ( @colinlyguo ), Nicolas Consigny ( @nconsigny )\n8164\nNative Key Delegation for EOAs\nGregory Markou (@GregTheGreek) < gregorymarkou@gmail.com >, James Prestwich (@prestwich) < james@prestwi.ch >\n8175\nComposable Transaction\nDragan Rakita ( @rakita )\n8178\nBinary SSZ Transport for the Engine API\nGiulio Rebuffo ( @Giulio2002 )\n8184\nLUCID encrypted mempool\nAnders Elowsson ( @anderselowsson ), Justin Florentine ( @jflo ), Julian Ma ( @ma-julian )\n8188\nLast-Written Block for Accounts and Slots\nWei Han Ng ( @weiihann ), Amirul Ashraf ( @asdacap ), Guillaume Ballet ( @gballet ), Maria Silva ( @misilva73 ), Gary Rong ( @rjl493456442 ), Carlos Perez ( @CPerezz ), Jochem Brouwer ( @jochem-brouwer )\n8197\nCryptographically Agile Transactions\nDanno Ferrin (@shemnon) < danno@tectonic.xyz >, Ron Kahat < ron@tectonic.xyz >\n8198\nQuick Slots\nCarl Beekhuizen ( @carlbeek )\n8200\nEVMification\nKevaundray Wedderburn ( @kevaundray )\n8202\nScheme-Agile Transactions\nGiulio Rebuffo ( @Giulio2002 ), Ben Adams ( @benaadams )\n8205\nWithdrawal credentials preregistration\nGeorge Avsetsin ( @avsetsin ), Dmitry Gusakov ( @dgusakov ), Greg Koumoutsos ( @gkoumout ), Eugene Mamin ( @TheDZhon )\n8209\nCommit-Reveal Transaction Frames\nAlex Forshtat ( @forshtat ), Shahaf Nacson ( @shahafn )\n8219\nChecked Arithmetic Opcodes\nHubert Ritzdorf ( @ritzdorf )\n8222\nLean Staking\nMohammad Jahanara ( @mmjahanara ), Pierre Daix-Moreux ( @dmpierre )\n8237\nIndependent CL/EL Sync\nM. Kalinin < noblesse.knight@gmail.com >, Potuz ( @potuz ), Toni Wahrstätter ( @nerolation )\n8243\nBatching Attestations at Source\nRaúl Kripalani ( @raulk ), Toni Wahrstätter ( @nerolation ), Mikhail Kalinin ( @mkalinin )\n8250\nKeyed Nonces for Frame Transactions\nThomas Thiery ( @soispoke ), Toni Wahrstätter ( @nerolation ), lightclient ( @lightclient ), Vitalik Buterin ( @vbuterin )\n8253\nBump nonce of zero-nonce storage accounts\nJochem Brouwer ( @jochem-brouwer )\n8254\nCap Deposit Requests Per Block\npk910 ( @pk910 ), Barnabas Busa ( @barnabasbusa )\n8256\nBlob Streaming\nMarios ( @mariosioannou-create ), Bharath ( @bharath-123 ), Francesco D'Amato ( @fradamt ), Julian Ma ( @ma-julian ), Raúl Kripalani ( @raulk ), Bosul Mun ( @healthykim ), Csaba Kiraly ( @cskiraly ), Anders Elowsson ( @anderselowsson )\n8266\nExpiring Nonces for Frame Transactions\nToni Wahrstätter ( @nerolation ), lightclient ( @lightclient )\n8268\nStorage Roots in Block Access Lists\nToni Wahrstätter ( @nerolation ), Carlos Perez ( @CPerezz )\n8272\nRecent Roots for Frame Transactions\nThomas Thiery ( @soispoke ), Vitalik Buterin ( @vbuterin ), Toni Wahrstätter ( @nerolation ), lightclient ( @lightclient )\n8279\nBlock Access List Byte Floor\nToni Wahrstätter ( @nerolation )\n8288\nIn-mempool signature and proof aggregation\nVitalik Buterin ( @vbuterin ), Thomas Coratger ( @tcoratger )\n8289\nMulti-block Access List Warming\nToni Wahrstätter ( @nerolation )\n8292\nPost-Quantum Attestation Aggregators\nAnshal Shukla ( @anshalshukla ), Gajinder Singh ( @g11tech ), Parthasarathy Ramanujam ( @ch4r10t33r ), Guillaume Ballet ( @gballet ), Shariq Naiyer ( @shariqnaiyer ), Kolby Moroz Liebl ( @KolbyML ), Unnawut Leepaisalsuwanna ( @unnawut ), Tom Wambsgans ( @tomWambsgans ), Thomas Coratger ( @tcoratger ), Justin Drake ( @JustinDrake )\n8295\nState Tiering by Periods\nWei Han Ng ( @weiihann ), Amirul Ashraf ( @asdacap ), Guillaume Ballet ( @gballet ), Maria Silva ( @misilva73 ), Gary Rong ( @rjl493456442 ), Carlos Perez ( @CPerezz ), Jochem Brouwer ( @jochem-brouwer )\n8296\nFixed-Cutoff State Tiering\nWei Han Ng ( @weiihann )\n8297\nPartitioned Binary Tree\nVitalik Buterin ( @vbuterin ), Guillaume Ballet ( @gballet ), Dankrad Feist ( @dankrad ), Ignacio Hagopian ( @jsign ), Kevaundray Wedderburn ( @kevaundray ), Tanishq Jasoria ( @tanishqjasoria ), Gajinder Singh ( @g11tech ), Danno Ferrin ( @shemnon ), Piper Merriam ( @pipermerriam ), Gottfried Herold ( @GottfriedHerold ), Wei Han Ng ( @weiihann ), Carlos Perez ( @CPerezz )\n8298\nSETCODEFROM Code Reuse Instruction\nLiyi Guo ( @colinlyguo ), Ben Adams ( @benaadams ), Carlos Perez ( @CPerezz ), Nicolas Consigny ( @nconsigny )\n8304\nTrustless log and transaction index\nZsolt Felföldi ( @zsfelfoldi )\n8311\nIncrease Calldata Floor Cost to 96\nMaria Silva ( @misilva73 ), Toni Wahrstätter ( @nerolation )\n8321\nHash-Chain RANDAO\nKevaundray Wedderburn ( @kevaundray ), Benedikt Wagner ( @benedikt-wagner ), Tom Wambsgans ( @TomWambsgans ), Justin Drake ( @JustinDrake ), Thomas Coratger ( @tcoratger )\n8337\nValidated EVM Code\nGreg Colvin (@gcolvin) < greg@colvin.org >, Martin Holst Swende ( @holiman ), Brooklyn Zelenka ( @expede ), John Max Skaller\n8347\nOffline State Migration to the PBT\nCarlos Perez ( @CPerezz ), Maria Silva ( @misilva73 ), Kevaundray Wedderburn ( @kevaundray )\n8355\nPrecompiles for ML-DSA Verification\nDanno Ferrin ( @shemnon )\n8360\nTCREATE Opcode\nHelkomine ( @Helkomine ), abc-123-c ( @abc-123-c ), Milos ( @milonite ), Peter Phillips ( @PeterMPhillips )\n8363\nTapered Issuance Burn\npintail ( @pintail-xyz ), Jérôme de Tychey ( @jdetychey ), dapplion ( @dapplion ), pa7x1 ( @pa7x1 ), Ladislaus von Daniels ( @ladidan ), Justin Drake ( @justindrake )\n8365\nDisallow new 0x00 validators\nNC ( @ensi321 ), Kevaundray Wedderburn ( @kevaundray )\n8368\nCPSB Recalibration for New Gas Limit\nMaria Silva ( @misilva73 ), Toni Wahrstätter ( @nerolation )\n8372\nNormalized state gas limit\nAnders Elowsson ( @anderselowsson )\n8379\nTop-up Sync\nJacek Sieka ( @arnetheduck ), Dustin ( @tersec ), Tamaghna Choudhuri ( @RazorClient )\n8390\nRemove the Sync Committee\nLion ( @dapplion )\nStagnant\nNumber Title Author\n86\nAbstraction of transaction origin and signature\nVitalik Buterin ( @vbuterin )\n101\nSerenity Currency and Crypto Abstraction\nVitalik Buterin ( @vbuterin )\n210\nBlockhash refactoring\nVitalik Buterin ( @vbuterin )\n615\nSubroutines and Static Jumps for the EVM\nGreg Colvin < greg@colvin.org >, Brooklyn Zelenka ( @expede ), Paweł Bylica ( @chfast ), Christian Reitwiessner ( @chriseth )\n616\nSIMD Operations for the EVM\nGreg Colvin < greg@colvin.org >\n663\nSWAPN, DUPN and EXCHANGE instructions\nAlex Beregszaszi ( @axic ), Charles Cooper ( @charles-cooper ), Danno Ferrin ( @shemnon )\n665\nAdd precompiled contract for Ed25519 signature verification\nTobias Oberstein < tobias.oberstein@crossbario.com >\n689\nAddress Collision of Contract Address Causes Exceptional Halt\nYoichi Hirai < i@yoichihirai.com >\n698\nOPCODE 0x46 BLOCKREWARD\nCody Burns < dontPanic@codywburns.com >\n858\nReduce block reward and delay difficulty bomb\nCarl Larson < cslarson@gmail.com >\n969\nModifications to ethash to invalidate existing dedicated hardware implementations\nDavid Stanfill < david@airsquirrels.com >\n1010\nUniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c\nAnderson Wesley ( @andywesley )\n1011\nHybrid Casper FFG\nDanny Ryan ( @djrtwo ), Chih-Cheng Liang ( @ChihChengLiang )\n1015\nConfigurable On Chain Issuance\nAlex Van de Sande < avsa@ethereum.org >\n1051\nOverflow checking for the EVM\nNick Johnson < arachnid@notdot.net >\n1057\nProgPoW, a Programmatic Proof-of-Work\nGreg Colvin < greg@colvin.org >, Andrea Lanfranchi ( @AndreaLanfranchi ), Michael Carter ( @bitsbetrippin ), IfDefElse < ifdefelse@protonmail.com >\n1087\nNet gas metering for SSTORE operations\nNick Johnson ( @arachnid )\n1109\nPRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts)\nJordi Baylina ( @jbaylina )\n1227\nDefuse Difficulty Bomb and Reset Block Reward\nSmeargleUsedFly ( @SmeargleUsedFly )\n1276\nEliminate Difficulty Bomb and Adjust Block Reward on Constantinople Shift\nEOS Classic ( @eosclassicteam )\n1285\nIncrease Gcallstipend gas in the CALL opcode\nBen Kaufman < ben@daostack.io >, Adam Levi < adam@daostack.io >\n1295\nModify Ethereum PoW Incentive Structure and Delay Difficulty Bomb\nBrian Venturo ( @atlanticcrypto )\n1352\nSpecify restricted address range for precompiles/system contracts\nAlex Beregszaszi ( @axic )\n1380\nReduced gas cost for call to self\nAlex Beregszaszi ( @axic ), Jacques Wagener ( @jacqueswww )\n1418\nBlockchain Storage Rent Payment\nWilliam Entriken ( @fulldecent )\n1482\nDefine a maximum block timestamp drift\nMaurelian ( @Maurelian )\n1485\nTEthashV1\ntrustfarm < trustfarm.info@gmail.com >, trustfarm < cpplover@trustfarm.net >\n1681\nTemporal Replay Protection\nMartin Holst Swende ( @holiman )\n1702\nGeneralized Account Versioning Scheme\nWei Tang ( @sorpaas )\n1829\nPrecompile for Elliptic Curve Linear Combinations\nRemco Bloemen < Recmo@0x.org >\n1895\nSupport for an Elliptic Curve Cycle\nAlexandre Belling < alexandrebelling8@gmail.com >\n1930\nCALLs with strict gas semantic. Revert if not enough gas available.\nRonan Sandford ( @wighawag )\n1959\nNew Opcode to check if a chainID is part of the history of chainIDs\nRonan Sandford ( @wighawag )\n1962\nEC arithmetic and pairings with runtime definitions\nAlex Vlasov ( @shamatar )\n1965\nMethod to check if a chainID is valid at a specific block Number\nRonan Sandford ( @wighawag )\n1985\nSane limits for certain EVM parameters\nAlex Beregszaszi ( @axic ), Paweł Bylica ( @chfast )\n2014\nExtended State Oracle\nAlex Beregszaszi ( @axic )\n2026\nState Rent H - Fixed Prepayment for accounts\nAlexey Akhunov ( @AlexeyAkhunov )\n2027\nState Rent C - Net contract size accounting\nAlexey Akhunov ( @AlexeyAkhunov )\n2029\nState Rent A - State counters contract\nAlexey Akhunov ( @AlexeyAkhunov )\n2031\nState Rent B - Net transaction counter\nAlexey Akhunov ( @AlexeyAkhunov )\n2035\nStateless Clients - Repricing SLOAD and SSTORE to pay for block proofs\nAlexey Akhunov ( @AlexeyAkhunov )\n2045\nParticle gas costs for EVM opcodes\nCasey Detrio ( @cdetrio ), Alex Beregszaszi ( @axic )\n2046\nReduced gas cost for static calls made to precompiles\nAlex Beregszaszi ( @axic )\n2242\nTransaction Postdata\nJohn Adler ( @adlerjohn )\n2327\nBEGINDATA opcode\nMartin Lundfall ( @MrChico )\n2330\nEXTSLOAD opcode\nDominic Letz ( @dominicletz ), Santiago Palladino ( @spalladino )\n2474\nCoinbase calls\nRicardo Guilherme Schmidt ( @3esmit )\n2488\nDeprecate the CALLCODE opcode\nAlex Beregszaszi ( @axic )\n2515\nImplement Difficulty Freeze\nJames Hancock ( @madeoftin )\n2539\nBLS12-377 curve operations\nAlex Vlasov ( @shamatar ), hujw77 ( @hujw77 )\n2583\nPenalty for account trie misses\nMartin Holst Swende ( @holiman )\n2584\nTrie format transition with overlay trees\nGuillaume Ballet ( @gballet )\n2593\nEscalator fee market change for ETH 1.0 chain\nDan Finlay < dan@danfinlay.com >\n2666\nRepricing of precompiles and Keccak256 function\nAlex Vlasov ( @shamatar )\n2803\nRich Transactions\nMicah Zoltu ( @MicahZoltu )\n2936\nEXTCLEAR Opcode For SELFDESTRUCTed contracts\nWilliam Morriss ( @wjmelements )\n2937\nSET_INDESTRUCTIBLE opcode\nVitalik Buterin ( @vbuterin )\n2970\nIS_STATIC opcode\nVitalik Buterin ( @vbuterin )\n2997\nIMPERSONATECALL Opcode\nSergio Demian Lerner ( @SergioDemianLerner )\n3026\nBW6-761 curve operations\nYoussef El Housni ( @yelhousni ), Michael Connor ( @iAmMichaelConnor ), Aurore Guillevic < aurore.guillevic@inria.fr >, hujw77 ( @hujw77 )\n3068\nPrecompile for BN256 HashToCurve Algorithms\nDr. Christopher Gorman ( @chgormanMH )\n3102\nBinary trie structure\nGuillaume Ballet ( @gballet ), Vitalik Buterin ( @vbuterin )\n3143\nIncrease block rewards to 5 ETH\nBen Tinner ( @Terra854 )\n3220\nCrosschain Identifier Specification\nWeijia Zhang ( @weijia31415 ), Peter Robinson ( @drinkcoffee )\n3238\nDifficulty Bomb Delay to Q2/2022\nAfri Schoedon ( @q9f )\n3267\nGiving Ethereum fees to Future Salaries\nVictor Porton ( @vporton ), Victor Porton < porton@narod.ru >\n3300\nPhase out refunds\nWilliam Morriss ( @wjmelements )\n3322\nAccount gas storage opcodes\nWilliam Morriss ( @wjmelements )\n3336\nPaged memory allocation for the EVM\nNick Johnson ( @arachnid )\n3337\nFrame pointer support for memory load and store operations\nNick Johnson ( @arachnid )\n3368\nIncrease block rewards to 3 ETH, with 2 Year Decay to 1 ETH Scheduled\nMichael D. Carter ( @BitsBeTrippin )\n3372\n5 FNV primes for ethash\nmineruniter969 ( @mineruniter969 ), mineruniter969 < mineruniter969@tutanota.com >\n3403\nPartial removal of refunds\nVitalik Buterin ( @vbuterin ), Martin Swende ( @holiman )\n3416\nMedian Gas Premium\nHexZorro ( @hexzorro ), Mojtaba Tefagh ( @mtefagh )\n3436\nExpanded Clique Block Choice Rule\nDanno Ferrin ( @shemnon )\n3455\nSUDO Opcode\nWilliam Morriss ( @wjmelements ), Baptiste Vauthey ( @thabaptiser )\n3508\nTransaction Data Opcodes\nAlex Papageorgiou ( @alex-ppg )\n3520\nTransaction Destination Opcode\nAlex Papageorgiou ( @alex-ppg )\n3521\nReduce access list cost\nMatt Garnett ( @lightclient )\n3534\nRestricted Chain Context Type Transactions\nIsaac Ardis ( @whilei )\n3540\nEOF - EVM Object Format v1\nAlex Beregszaszi ( @axic ), Paweł Bylica ( @chfast ), Andrei Maiboroda ( @gumb0 ), Matt Garnett ( @lightclient ), Piotr Dobaczewski ( @pdobacz )\n3584\nBlock Access List\nGajinder Singh ( @g11in ), Piper Merriam ( @pipermerriam )\n3670\nEOF - Code Validation\nAlex Beregszaszi ( @axic ), Andrei Maiboroda ( @gumb0 ), Paweł Bylica ( @chfast )\n3690\nEOF - JUMPDEST Table\nAlex Beregszaszi ( @axic ), Paweł Bylica ( @chfast ), Andrei Maiboroda ( @gumb0 )\n3756\nGas Limit Cap\nlightclient ( @lightclient )\n3788\nStrict enforcement of chainId\nGregory Markou ( @GregTheGreek )\n3978\nGas refunds on reverts\nAnton Bukov ( @k06a ), Mikhail Melnik ( @ZumZoom )\n4200\nEOF - Static relative jumps\nAlex Beregszaszi ( @axic ), Andrei Maiboroda ( @gumb0 ), Paweł Bylica ( @chfast )\n4396\nTime-Aware Base Fee Calculation\nAnsgar Dietrichs ( @adietrichs )\n4488\nTransaction calldata gas cost reduction with total calldata limit\nVitalik Buterin ( @vbuterin ), Ansgar Dietrichs ( @adietrichs )\n4520\nMulti-byte opcodes prefixed by EB and EC.\nBrayton Goodall ( @Spore-Druid-Bray ), Mihir Faujdar ( @uink45 )\n4573\nProcedures for the EVM\nGreg Colvin ( @gcolvin ), Greg Colvin < greg@colvin.org >\n4747\nSimplify EIP-161\nPeter Davies ( @petertdavies )\n4750\nEOF - Functions\nAndrei Maiboroda ( @gumb0 ), Alex Beregszaszi ( @axic ), Paweł Bylica ( @chfast )\n4758\nDeactivate SELFDESTRUCT\nGuillaume Ballet ( @gballet ), Vitalik Buterin ( @vbuterin ), Dankrad Feist ( @dankrad )\n4760\nSELFDESTRUCT bomb\nGuillaume Ballet ( @gballet ), Vitalik Buterin ( @vbuterin ), Dankrad Feist ( @dankrad )\n4803\nLimit transaction gas to a maximum of 2^63-1\nAlex Beregszaszi ( @axic )\n4863\nBeacon chain push withdrawals\nAlex Stokes ( @ralexstokes ), Danny Ryan ( @djrtwo )\n5000\nMULDIV instruction\nHarikrishnan Mulackal ( @hrkrshnn ), Alex Beregszaszi ( @axic ), Paweł Bylica ( @chfast )\n5022\nIncrease price of SSTORE from zero to non-zero to 40k gas\nGreen ( @greenlucid )\n5027\nRemove the limit on contract code size\nQi Zhou ( @qizhou )\n5065\nInstruction for transferring ether\nMudit Gupta ( @maxsam4 )\n5081\nExpirable Transaction\nZainan Victor Zhou ( @xinbenlv ), Nick Johnson ( @Arachnid ), Konrad Feldmeier < konrad@brainbot.com >\n5283\nSemaphore for Reentrancy Protection\nSergio D. Lerner ( @SergioDemianLerner )\n5450\nEOF - Stack Validation\nAndrei Maiboroda ( @gumb0 ), Paweł Bylica ( @chfast ), Alex Beregszaszi ( @axic ), Danno Ferrin ( @shemnon )\n5478\nCREATE2COPY Opcode\nQi Zhou ( @qizhou )\n5806\nDelegate transaction\nHadrien Croubois ( @Amxx )\n5988\nAdd Poseidon hash function precompile\nAbdelhamid Bakhta ( @abdelhamidbakhta ), Eli Ben Sasson ( @Elistark ), Avihu Levy ( @avihu28 ), David Levit Gurevich ( @DavidLevitGurevich )\n6046\nReplace SELFDESTRUCT with DEACTIVATE\nAlex Beregszaszi ( @axic )\n6188\nNonce Cap\nGavin John ( @Pandapip1 )\n6189\nAlias Contracts\nGavin John ( @Pandapip1 )\n6190\nVerkle-compatible SELFDESTRUCT\nGavin John ( @Pandapip1 )\n6206\nEOF - JUMPF and non-returning functions\nAndrei Maiboroda ( @gumb0 ), Alex Beregszaszi ( @axic ), Paweł Bylica ( @chfast ), Matt Garnett ( @lightclient )\n6475\nSSZ Optional\nEtan Kissling ( @etan-status ), Zahary Karadjov ( @zah )\n6690\nEVM Modular Arithmetic Extensions\nJared Wasinger ( @jwasinger ), Alex Beregszaszi ( @axic ), Vitalik Buterin ( @vbuterin ), Radosław Zagórowicz ( @rodiazet ), Paweł Bylica ( @chfast )\n6800\nEthereum state using a unified verkle tree"}
{"url":"https://docs.filecoin.io/build-on-filecoin/developing-contracts/call-built-in-actors","domain":"docs.filecoin.io","title":"Call built-in actors | Filecoin Docs","hash":"de9e6ff56a68cb2179d2cb2f0d3f29da7d1f276ba7315888a4ea2f687f2fe247","tokens":1749,"chars":6995,"crawler":"crawler-f6nn","verified":"exact","ts":1791172280752,"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 .\nCall built-in actors\nFilecoin built-in actors can be invoked in a smart contract using either the Protocol API or the Filecoin.sol library. This page provides instructions on how to use each method.\nFor conceptual information on built-in actors, including their purposes, how they work and available types, see the conceptual guide\nBuilt-in actors can be invoked using the Protocol JSON-RPC API or the Filecoin.sol API.\nAPIs compared\nThe Protocol JSON-RPC API:\n-\nIs maintained by Protocol Labs (PL).\n-\nUses JSON-RPC, a standardized way to encode remote procedure calls in JSON that can be transported using HTTP or WebSockets.\n-\nProvides a language agnostic interface for Filecoin functionality.\n-\nAllows applications to access Filecoin functionality using HTTP or WebSockets calls to a Filecoin node, like the Lotus daemon.\n-\nRequires authentication for some API calls.\n-\nServes as the foundation for language-specific libraries (some of which are maintained by organizations other than PL) such as filecoin.js .\nThe Filecoin.sol API:\n-\nSupports some but not all of the built-in actors and their methods .\nProtocol API\nApplications and off-chain services can access built-in actors and methods using the Filecoin JSON-RPC API exposed by nodes such as Lotus. Smart contracts should use Filecoin.sol or the actor precompiles instead. Links to the reference guides for each of the available actor methods are listed below:\n-\nAccount actor\n-\nDatacap\n-\nMiner\n-\nMultisig\n-\nStorage market actor\n-\nStorage power actor\n-\nVerified registry actor\nFilecoin.sol\nSmart contracts can access built-in actor methods with the filecoin.sol library, a set of Solidity libraries that allow Solidity smart contracts to call methods of Filecoin built-in actors. The maintained npm package is filecoin-solidity-api , and its current import paths use contracts/v0.8 . This section contains information on the actors and methods available from filecoin.sol , along with installation instructions and references for examples of smart contracts that call built-in actor methods.\nTo invoke built-in actor methods using filecoin.sol , follow these steps:\n-\nReview the available actors and methods .\n-\nImport filecoin.sol .\n-\nCall a built-in actor .\nAvailable actors and methods\nThe majority of the Account, DataCap, Storage Market, Miner, Storage Owner and Verified Registry actor methods are supported and are listed below. Cron, Payment Channel, Reward and System actor methods are currently not supported.\nAccount\nMethod\nSupported?\nAuthenticateMessage\n✔️\nConstructor\n✖️\nPubkeyAddress\n✖️\nUniversalReceiverHook\n✔️\nDataCap\nMethod\nSupported?\nAllowance\n✔️\nBalanceOf\n✔️\nBurn\n✔️\nBurnFrom\n✔️\nConstructor\n✖️\nDecreaseAllowance\n✔️\nDestroy\n✖️\nIncreaseAllowance\n✔️\nMint\n✖️\nName\n✔️\nRevokeAllowance\n✔️\nSymbol\n✔️\nTotalSupply\n✔️\nTransfer\n✔️\nTransferFrom\n✔️\nMiner\nMethod\nSupported?\nApplyRewards\n✖️\nChangeBeneficiary\n✔️\nChangeMultiaddrs\n✔️\nChangeOwnerAddress\n✔️\nChangePeerID\n✔️\nChangeWorkerAddress\n✔️\nCheckSectorProven\n✖️\nCompactPartitions\n✖️\nCompactSectorNumbers\n✖️\nConfirmSectorProofsValid\n✖️\nConfirmUpdateWorkerKey\n✖️\nConstructor\n✖️\nControlAddresses\n✖️\nDeclareFaults\n✖️\nDeclareFaultsRecovered\n✖️\nDisputeWindowedPoSt\n✖️\nExtendSectorExpiration\n✖️\nExtendSectorExpiration2\n✖️\nGetAvailableBalance\n✔️\nGetBeneficiary\n✔️\nGetOwner\n✔️\nGetSectorSize\n✔️\nGetVestingFunds\n✔️\nIsControllingAddress\n✔️\nOnDeferredCronEvent\n✖️\nPreCommitSector\n✖️\nPreCommitSectorBatch\n✖️\nPreCommitSectorBatch2\n✖️\nProveCommitAggregate\n✖️\nProveCommitSector\n✖️\nProveReplicaUpdates\n✖️\nProveReplicaUpdates2\n✖️\nRead fee debt\n✖️\nRead initial pledge total\n✖️\nRead peer ID, multiaddr\n✔️\nRead pre-commit deposit\n✖️\nRepayDebt\n✔️\nReportConsensusFault\n✖️\nSubmitWindowedPoSt\n✖️\nTerminateSectors\n✖️\nWithdrawBalance\n✔️\nMultisig\nMethod\nSupported?\nAddSigner\n✔️\nApprove\n✔️\nCancel\n✔️\nChangeNumApprovalsThreshold\n✖️\nConstructor\n✖️\nList signers and threshold\n✖️\nLockBalance\n✔️\nPropose\n✔️\nRemoveSigner\n✔️\nSwapSigner\n✔️\nUniversalReceiverHook\n✔️\nStorage market\nMethod\nSupported?\nActivateDeals\n✖️\nAddBalance\n✔️\nComputeDataCommitment\n✖️\nConstructor\n✖️\nCronTick\n✖️\nGetBalance\n✔️\nGetDealActivation\n✔️\nGetDealClient\n✔️\nGetDealClientCollateral\n✔️\nGetDealDataCommitment\n✔️\nGetDealEpochPrice\n✔️\nGetDealLabel\n✔️\nGetDealProvider\n✔️\nGetDealProviderCollateral\n✔️\nGetDealTerm\n✔️\nGetDealVerified\n✔️\nOnMinerSectorsTerminate\n✖️\nPublishStorageDeals\n✔️\nVerifyDealsForActivation\n✖️\nWithdrawBalance\n✔️\nStorage power\nMethod\nSupported?\nCompute pledge collateral for new sector\n✖️\nConstructor\n✖️\nCreateMiner\n✔️\nCurrentTotalPower\n✖️\nEnrollCronEvent\n✖️\nGet miner count, consensus count\n✔️\nGet miner’s QA power\n✖️\nGet network bytes committed?\n✖️\nGet network epoch pledge collateral\n✖️\nGet network epoch QA power\n✖️\nGet network total pledge collateral?\n✖️\nMinerRawPower\n✔️\nNetworkRawPower\n✔️\nOnEpochTickEnd\n✖️\nSubmitPoRepForBulkVerify\n✖️\nUpdateClaimedPower\n✖️\nUpdatePledgeTotal\n✖️\nVerified registry\nMethod\nSupported?\nAddVerifiedClient\n✔️\nAddVerifier\n✖️\nClaimAllocations\n✖️\nConstructor\n✖️\nExtendClaimTerms\n✔️\nGetClaims\n✔️\nList claims\n✖️\nList/check verifiers\n✖️\nList/get allocations\n✖️\nRemoveExpiredAllocations\n✔️\nRemoveExpiredClaims\n✔️\nRemoveVerifiedClientDataCap\n✖️\nRemoveVerifier\n✖️\nUniversalReceiverHook\n✔️\nImport filecoin.sol\nThe filecoin.sol library is embeddable into your smart contract, which means it does not need be present on chain first. Instead, you can just import the library and call the available methods. The filecoin.sol library can be added via npm or manually imported into your contract. The npm -based import is simpler, and is recommended.\nImport filecoin.sol with npm\n-\nInstall the Filecoin Solidity API package:\nUse the maintained filecoin-solidity-api package and import paths. Older examples may use legacy Zondax package names or repository paths; do not copy those into new projects.\nImport filecoin.sol manually\n-\nNavigate to your smart contract project folder :\n-\nCreate a folder named libs :\n-\nMove into the libs directory:\n-\nCopy the Filecoin Solidity API contracts with the methods you wish to call from the contracts folder into libs . Preserve the subdirectories such as types , utils , and cbor , because the actor API files import those dependencies.\nCall a built-in actor\nOnce you’ve either imported particular contracts manually or installed filecoin-solidity-api using npm, create a callable method to access the built-in actor methods the way you normally would in a Solidity smart contract. See the Filecoin.sol guide for npm import examples and the reference guide for actor-specific method examples.\nWas this page helpful?\nPrevious ERC-20 quickstart\nNext Filecoin.sol\nLast updated 3 months ago\n- APIs compared\n- Protocol API\n- Filecoin.sol\n- Available actors and methods\n- Import filecoin.sol\n- Call a built-in actor\nnpm install filecoin-solidity-api\ncd my-project\nmkdir libs\ncd libs"}
{"url":"https://www.helius.dev/use-case/wallets","domain":"www.helius.dev","title":"Solana Infrastructure and APIs for Wallets","hash":"a6d15cd66738f0811750224b75b75d87be555995ee1777fb8a10ab90243b22dc","tokens":1533,"chars":6129,"crawler":"crawler-f6nn","verified":"exact","ts":1791172282983,"text":"---\ntitle: \"Solana Infrastructure and APIs for Wallets\"\ndescription: \"Build the most performant Solana wallet with flexible token and NFT APIs, archival data, real-time data streams, and transaction landing services.\"\ncanonical: \"https://www.helius.dev/use-case/wallets\"\nlast-updated: \"2025-10-02T13:52:00.704Z\"\n---\n# Solana Infrastructure and APIs for Wallets\n> Build the most performant Solana wallet with flexible token and NFT APIs, archival data, real-time data streams, and transaction landing services.\n**Use Cases**\n## Integrate and scale your Solana wallet\nGive Solana users a wallet experience that they love and trust by building with a stack purpose-built to deliver unmatched reliability, scale, and speed.\n[Get started](https://dashboard.helius.dev/signup)\n## Ensure your wallet stays up during Solana's largest onchain events\n## How DFlow Uses LaserStream to Quote Solana's Best Prices\nSee how DFlow, a leading DEX Aggregator on Solana eliminated engineering overhead, achieved 100% uptime, and recorded the single best month of swap volume in protocol history.\n[Read now](https://www.helius.dev/blog/dflow)\n## Powering leading wallets\nBackpack, Phantom, Solflare, Squads, Ledger, MetaMask, Exodus, Trust\n## Your complete Solana wallet development stack\nEverything you need to build world-class hardware wallets, embedded wallets, or wallets for browsers and mobile experiences.\n- **Regions covered**: 7\n- **SOL staked**: 15M+\n- **Uptime**: 99.99%\n- **Support**: 24/7\n## Trusted by Solana's best wallets\n## Update your wallet data in real-time\nPower your wallet with ultra low latency streams of Solana blocks, accounts, and transactions so users always see the freshest Solana state.\n- Powered by ultra low latency shreds\n- Maximally redundant with automatic failover\n- 48-hour historical replay and auto reconnects\n> \"LaserStream was a seamless drop-in replacement for Geyser. It integrated perfectly with Jupiter infra and performed impressively fast.\"\n> — Aryan, Co-founder at SendAI\n[Learn more](https://www.helius.dev/laserstream)\n## Reliably land in-wallet swaps and sends at scale\nNo matter how busy Solana gets, predictably land your user's deposits, swaps, and transfers by submitting transactions to our top-staked validator.\n- Bypass public queues for reliable delivery\n- Reduce failed transactions for improved UX\n- Earn [SOL rebates](https://www.helius.dev/docs/sending-transactions/backrun-rebates) from trades that create arbitrages\n> \"Thanks to [Helius's] support, we handled extreme congestion and enabled our users to complete more than 10 million transactions in just one day.\"\n> — Jorge Valdeiglesias, Staff Software Engineer at Phantom\n[Learn more](https://www.helius.dev/staked-connections)\n## Power your wallets with industry-leading RPCs\nGet token accounts, token balances, and [historical data](https://www.helius.dev/historical-data) for all of your users, and reliably simulate, send, and monitor the status of transactions sent via RPC.\n- Battle-tested to handle wallet-level scale\n- Highly redundant and SOC II Type 2 certified\n- Helius exclusive methods with cursor-based pagination\n> \"RPC side, Helius has been incredibly responsive. Working with bleeding edge tech like NFT compression, this has been invaluable.\"\n> — Noah Prince, Head of Protocol Engineering at Helium\n[Learn more](https://www.helius.dev/solana-rpc-nodes)\n**See also:**\n- [Solana RPC Benchmarks](https://www.helius.dev/benchmarks): Compare RPC latency and reliability across providers\n## Every token. Every NFT. Every transaction.\nBuild a feature-rich Solana wallet users truly love with powerful APIs to manage tokens, transaction histories, and estimating priority fees.\n- [NFT APIs](https://www.helius.dev/docs/das-api) for fast, reliable, and accurate querying\n- [Token APIs](https://www.helius.dev/solana-token-apis) for displaying balances and metadata\n- [Parsed Events API](https://www.helius.dev/parsed-data) for decoding wallet activity into readable instructions, transfers, and summaries\n> \"Helius is super fast, reliable, and I'd recommend them to anyone looking for the best developer experience on Solana.\"\n> — Armani Ferrante, Co-founder and CEO, Backpack\n[Learn more](https://www.helius.dev/docs/das-api)\n## Trusted by Solana's best wallets\n> \"The Helius team's deep technical expertise in Solana and node management was absolutely critical during one of our most challenging and busiest days. Thanks to their support, we handled extreme congestion and enabled our users to complete more than 10 million transactions in just one day.\"\n— **Jorge Valdeiglesias**, STAFF SOFTWARE ENGINEER, PHANTOM\n> \"Helius is super fast, reliable, and I'd recommend them to anyone looking for the best developer experience on Solana. They power a great portion of our infrastructure at Backpack.\"\n— **Armani Ferrante**, CEO AND CO-FOUNDER, BACKPACK\n> \"The Helius team is the GOAT. They ship fast, intake product feedback overnight, and power a great deal of Crossmint infrastructure. A big percentage of Crossmint products couldn't exist without Helius.\"\n— **Alfonso Gomez Manas**, CO-FOUNDER, CROSSMINT\n> \"Helius is an absolutely essential piece of infrastructure, their service is robust and reliable, the team is responsive and brilliant, their attitude and dedication shows how much they care. They are passionately aligned with the success of their customers.\"\n— **Stepan Simkin**, CEO & CO-FOUNDER, SQUADS\n> \"Helius runs a dedicated gRPC plugin that we use for large, real-time data consumption. The performance and support has been better than anything we've seen in the industry.\"\n— **Tanner Philp**, COO, FLIPCASH\n> \"Helius's RPC service delivers same-slot latency with ready-to-use frontend links that integrate seamlessly into our app—complete with smart rate limiting to avoid any overages, saving us countless dev hours, and protecting against unexpected expenses.\"\n— **Bill Papas**, FOUNDER, UNRUGGABLE\n## Build a world-class Solana wallet\nGet started in less than 10 seconds, or contact our sales team.\n[Get started](https://dashboard.helius.dev/signup)\n| [Contact us](https://www.helius.dev/contact)"}
{"url":"https://docs.ipfs.tech/how-to/websites-on-ipfs/dnslink-gateway/","domain":"docs.ipfs.tech","title":"Setup a DNSLink Gateway to serve static sites with Kubo | IPFS Docs","hash":"d5b306a8de38853787ffcea12478dcc37c0c4647b3f45137c7331a6a2783256d","tokens":2332,"chars":9326,"crawler":"crawler-f6nn","verified":"exact","ts":1791172285133,"text":"IPFS Docs\n# Setup a DNSLink Gateway to serve static sites with Kubo and Caddy\nThis guide explains how to serve a static site or app on IPFS using a DNSLink Gateway.\nFor this, you will use a dedicated DNSLink IPFS gateway using Kubo and Caddy (opens new window) to serve content over HTTPS via a custom domain name.\nThis allows users to access IPFS content through a known domain name without needing special browser extensions or users needing to know the specific Content Identifier (CID). The gateway automatically resolves the DNSLink TXT record associated with the domain to CID, and fetches and serves the content of the CID.\nThis guide assumes the CID of the site or app is already pinned to IPFS. If not, check out the Deploy Static Apps to IPFS with GitHub Actions guide.\n# Goal\nBy the end of this guide, you will have:\n- Your domain, e.g. https://yourdomain.com , serving the site or app specified in its DNSLink TXT record.\n- A running Kubo IPFS node configured as a DNSLink gateway for yourdomain.com .\n- A Caddy web server acting as a reverse proxy, handling TLS termination so that the site is served over HTTPS.\n# Note about verification\nNote that the DNSLink gateway you will configure will function as a trusted gateway , in the sense that the readers trust the server your domain points to serve the correct content, without verifying the content. As such, it assumes the same security assumptions and risks of the web (opens new window) .\nThis may be fine for your use-case. However, if the site or app you are deploying requires more security and less trust, we recommend your users to use a verifying IPFS client by viewing your site using a local IPFS Node like Kubo or using the Service Worker Gateway (opens new window) to load the site while also verifying the content matches the CID in the DNSLink TXT record.\n# Prerequisites\nBefore you start, ensure you have the following:\n- A server with a static public IP address (e.g., YOUR_SERVER_IP ).\n- Port 443 open on your server's firewall to allow HTTPS traffic.\n- A domain name (e.g., yourdomain.com ).\n- DNS configured for your domain:\n- An A record pointing yourdomain.com to your server's public IP address ( YOUR_SERVER_IP ).\n- (We will configure the required DNSLink TXT record later in the guide).\n- Kubo installed and initialized on your server.\n- Caddy installed on your server.\n# Step 1: Configure Kubo\n# Adjust Kubo Gateway Configuration\nFirst, you need to adjust the Kubo gateway configuration. These settings tell Kubo to act as a specific gateway for your domain and disable certain default behaviors, like fetching arbitrary CIDs.\nWith this configuration, Kubo will match the domain in the host header (opens new window) of requests that are proxied from Caddy, and if it matches the domain configured in this step, it will resolve the DNSLink TXT record and serve the content of the CID.\n# Commands to Run\n-\nDisable fetching content for arbitrary CIDs :\nThis prevents your gateway from being used as a general-purpose public gateway. Config docs (opens new window)\nipfs config --json Gateway.NoFetch true\n-\nDisable DNSLink resolution globally (default) :\nYou'll enable it only for your specific domain in the next step. Config docs (opens new window)\nipfs config --json Gateway.NoDNSLink true\n-\nEnable DNSLink for yourdomain.com :\nThis explicitly allows DNSLink resolution only for requests hitting this hostname. Config docs (opens new window)\nipfs config --json Gateway.PublicGateways '{\n\"yourdomain.com\": {\n\"NoDNSLink\": false,\n\"Paths\": []\n}\n}'\n-\nRestart the Kubo daemon for the changes to take effect. Stop and re-run ipfs daemon , or, if you run Kubo as a systemd service:\nsudo systemctl restart ipfs\nThese commands modify the config file in your IPFS repository (usually ~/.ipfs/config ). The Gateway.PublicGateways setting defines specific configurations for different hostnames. Here, you override the global NoDNSLink setting specifically for yourdomain.com .\n# Step 2: Configure Caddy\n# Set Up Caddy as a Reverse Proxy\nNext, configure Caddy to handle incoming HTTPS requests for yourdomain.com and proxy them to the Kubo gateway, which is listening by default on 127.0.0.1:8080 .\nTo verify that the gateway exposed by Kubo is listening, you can run the following command:\nipfs config Addresses.Gateway\nYou should see something like this:\n/ip4/127.0.0.1/tcp/8080\nThis confirms that the gateway exposed by Kubo is listening on 127.0.0.1:8080 .\n# Caddyfile Configuration\nCreate or edit your Caddyfile (usually located at /etc/caddy/Caddyfile or in your current directory if running Caddy manually) with the following content:\nyourdomain.com {\n# Caddy automatically handles HTTPS provisioning for your domain\n# Proxy all requests to the local Kubo gateway\nreverse_proxy localhost:8080\n# Optional: Configure logging\nlog {\noutput stdout\nformat json\nlevel INFO\n}\nExplanation:\n- yourdomain.com { ... } : Defines a site block for your domain. Caddy will automatically obtain and renew a TLS certificate for it, provided the A record DNS is set correctly.\n- reverse_proxy localhost:8080 : Forwards all incoming requests for yourdomain.com to the Kubo daemon listening on port 8080.\n- log { ... } : Configures access logging (optional but recommended).\nStart or reload Caddy for the configuration to apply:\n# If using systemd:\nsudo systemctl reload caddy\n# Or, if running Caddy manually in the directory with the Caddyfile:\ncaddy run\n# Step 3: Set up DNSLink TXT Record\n# Configure DNSLink DNS Record\nNow, you will create the DNSLink TXT record for your domain to point to CID of the site or app you want to serve, which is necessary in addition to the A record pointing to your server's IP address.\nWhen requests are made to yourdomain.com , the DNSLink gateway will automatically resolve the DNSLink TXT record and serve the content of the CID. Because Gateway.NoFetch is set to true , the gateway will not retrieve data from other providers: the content must already be present on your Kubo node.\n# Steps to Create a TXT Record\n-\nGet the CID of the content you want to serve.\n-\nPin the CID on your server's Kubo node , so the gateway can serve it despite Gateway.NoFetch being true :\nipfs pin add YOUR_CID\n-\nGo to your DNS provider's dashboard for yourdomain.com .\n-\nCreate a TXT record :\n- Name/Host : _dnslink (or the full name _dnslink.yourdomain.com , depending on your provider's interface)\n- Type : TXT\n- Value/Content : dnslink=/ipfs/bafybeiay2koog2jnndn5gr2raytxh7evobry5lo2w4s7nhugc7xipy6aze (Replace the example CID with your actual CID)\nNote: The record name must start with _dnslink. . DNS propagation might take some time. You can check if it has propagated using tools like dig or nslookup :\ndig +short TXT _dnslink.yourdomain.com\n# Expected Output: \"dnslink=/ipfs/bafybeiay2koog2jnndn5gr2raytxh7evobry5lo2w4s7nhugc7xipy6aze\"\n# Also verify your A record:\ndig +short A yourdomain.com\n# Expected Output: YOUR_SERVER_IP\nNote: The DNSLink record will need to be updated every time you update the site or app, leading to a new CID for the build. In order to automate this, you can use the DNSLink GitHub Action (opens new window) , as part of your CI/CD pipeline.\n# Step 4: Verify\n# Ensure Everything is Working\nOnce both DNS records ( A and TXT ) have propagated and both Kubo and Caddy are running with the correct configurations:\n- Open your web browser and navigate to that domain, e.g. https://yourdomain.com .\n- You should see the content associated with your CID served securely over HTTPS via your Caddy server, which fetched it from your Kubo node using the DNSLink record.\nYour gateway will now automatically serve the content specified in the _dnslink.yourdomain.com TXT record. To update the site, pin the new version to your Kubo node, get the new CID, and update the TXT record's value with the new CID path ( dnslink=/ipfs/NEW_CID_HERE ).\n# Automate DNSLink Updates\nDepending on how you deploy your site, you can automate DNSLink updates using the DNSLink Action as part of your CI/CD pipeline. For a step-by-step guide, see Automate DNSLink updates with GitHub Actions .\nSecurity Best Practice\nFor production deployments, consider using a sandboxed DNS zone to limit what your CI API token can modify. This way, if credentials are compromised, attackers can only modify the DNSLink TXT record, not other DNS records like A, MX, or NS.\nYou can also use other DNS management tools like dnscontrol (opens new window) or octodns (opens new window) .\n# Troubleshooting\n# Common Issues and Solutions\n-\nDNS Propagation Delays : If your domain isn't resolving, check the DNS settings and ensure the DNSLink record has propagated. You can use dig to verify:\ndig +short TXT _dnslink.yourdomain.com\n# Expected Output: \"dnslink=/ipfs/bafy...\"\n-\nCaddy Configuration Errors : Ensure your Caddyfile syntax is correct. Check Caddy logs for any errors.\n-\nIPFS Node Issues : Make sure your IPFS node is running and accessible. Restart the daemon if necessary.\n# Summary\nYou've successfully set up a DNSLink Gateway using Kubo and Caddy to serve IPFS content via your domain. Keep your software updated and monitor your server for any issues. For further customization, refer to the Kubo config documentation (opens new window) and Caddy documentation (opens new window) .\nHelp us improve this site!\nEdit this page\nor\nopen an issue"}
{"url":"https://docs.layerzero.network/v2/concepts/protocol/message-properties","domain":"docs.layerzero.network","title":"Message Properties - LayerZero","hash":"20fbcd528b7d4be66777f9a25d77e8350b7259ecc51aae9a5544e75988ba832d","tokens":1267,"chars":5066,"crawler":"crawler-f6nn","verified":"exact","ts":1791172287704,"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\nProtocol\nMessage Properties\nLayerZero is purpose built for lightweight message passing across multiple blockchains. To accomplish this, the protocol provides authentic and guaranteed…\nLayerZero is purpose built for lightweight message passing across multiple blockchains. To accomplish this, the protocol provides authentic and guaranteed message delivery with a configurable level of trustlessness.\nMessage State\nMessages are sent from the User Application (UA) at source srcUA to the UA at the destination dstUA . Once the message is received by the dstUA , the message is considered delivered (transitioning from INFLIGHT to either SUCCESS or STORED )\nMessage State Cases\nINFLIGHT After a message is sent\nSUCCESS A1: dstUA success OK()\nA2: dstUA fails with uncaught exception\nSTORED B1: dstUA fails with uncaught error / exception\n// message handling at destination chain\ntry ILayerZeroReceiver (_dstAddress).lzReceive{gas : _gasLimit}(_srcChainId, _srcAddress, _nonce, _payload) {\n// message state becomes SUCCESS\n} catch {\n// message state becomes STORED\nemit PayloadStored (_srcChainId, _srcAddress, _dstAddress, _payload);\n}\nCase A2: dstUA is expected to store the message in their contract to be retried (LayerZero will not store any successfully delivered messages). dstUA is expected to monitor and retry STORED messages on behalf of its users.\nCase B1: dstUA is expected to gracefully handle all errors/exceptions when receiving a message, and any uncaught errors/exceptions (including out-of-gas) will cause the message to transition into STORED. A STORED message will block the delivery of any future message from srcUA to all dstUA on the same destination chain and can be retried until the message becomes SUCCESS. dstUA should implement a handler to transition the stored message from STORED to SUCCESS. If a bug in dstUA contract results in an unrecoverable error/exception, LayerZero provides a last-resort interface to force resume message delivery, only by the dstUA contract.\nMessage Ordering\nLayerZero provides ordered delivery of messages from a given sender to a destination chain, i.e. srcUA -> dstChain . In other words, the message order nonce is shared by all dstUA on the same dstChain . That’s why a STORED message blocks the message pathway from srcUA to all dstUA on the same destination chain. If it isn’t necessary to preserve the sequential nonce property for a particular dstUA the sender must add the nonce into the payload and handle it end-to-end within the UA. UAs can implement a non-blocking pattern in their contract code.\nExtensibility\nMessage Adapter Parameters\nLayerZero allows UAs to add arbitrary transaction params in the send() function, providing a high level of flexibility and opening up opportunities for a diverse set of 3rd party plugins This is implemented as an unreserved byte array parameter to the send() function, with UAs allowed to write any additional data necessary into that parameter. We recommend that UAs leave some degree of configurability for the extra parameters to allow for feature extensions.\nOne great feature of _adapterParams is performing an Airdrop.\nPatterns\nNon-Reentrancy\nLayerZero Endpoint has a non-reentrancy guard for both the send() and receive() , respectively. In other words, both send() and receive() can not call themselves on the same chain. UAs should not rely on LayerZero to perform the non-reentrancy check. However, UAs can query the endpoint to see if the endpoint isSendingPayload() or isReceivingPayload() for finer-grained reentrancy control.\nMessage Chaining\nUAs can call send() in the receive() calls on the same chain. Example applications for calling send() in the receive() include (e.g. Ping Pong):\n- the UA at the source chain wants a message receipt (Chain A -> Chain B -> Chain A)\n- the UA at the destination reroutes the message (Chain A -> Chain B -> Chain C)\nfunction lzReceive ( uint16 _srcChainId , bytes memory _fromAddress , uint64 , /*_nonce*/ bytes memory _payload ) external override {\n...\n// message chaining\nendpoint.send{value : messageFee}(\n...\n);\n}\nHowever, the fee for sending messages on another chain is not observable onchain. UAs would need to create some fee estimate heuristics. Optionally, user apps can store the chained message and then resend them with another transaction.\nMulti-Send\nUAs can send multiple messages in one transaction at the source chain. The endpoint non-reentrancy will not block this pattern.\nfunction sendFirstMessage (\nuint gasAmountForDst , uint16 [] calldata chainIds , bytes [] calldata dstAddresses ) external payable {\n...\nfor ( uint i = 0 ; i < chainIds.length; i ++ ){\nendpoint.send{value : fee}(chainIds[i], dstAddresses[i], messageString, msg.sender , address ( 0x0 ), _relayerParams);\n}\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://www.metaplex.com/docs/tokens/transfer-a-token","domain":"www.metaplex.com","title":"How to Transfer Fungible Tokens on Solana | Tokens","hash":"887b9a00a0a1955f321f20a6e53c8e389fb6c0ca2c806bbb2c731259eb99f01d","tokens":1052,"chars":4208,"crawler":"crawler-f6nn","verified":"exact","ts":1791172290208,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nGetting Started\nTransfer Fungible Tokens\nLast updated November 25, 2025\nTransfer fungible tokens (SPL tokens) between wallets on the Solana blockchain.\nTransfer Tokens\nIn the following section you can find a full code example and the Parameters that you might have to change. You can learn more about token transfer details in the Token Metadata program pages.\n1 // To install all the required packages use the following command\n2 // npm install @metaplex-foundation/mpl-toolbox @metaplex-foundation/umi @metaplex-foundation/umi-bundle-defaults\n3 import {\n4 createTokenIfMissing ,\n5 findAssociatedTokenPda ,\n6 transferTokens ,\n7 } from '@metaplex-foundation/mpl-toolbox' ;\n8 import {\n9 keypairIdentity ,\n10 publicKey ,\n11 transactionBuilder ,\n12 } from '@metaplex-foundation/umi' ;\n13 import { createUmi } from '@metaplex-foundation/umi-bundle-defaults' ;\n14 import { readFileSync } from 'fs' ;\n15\n16 // Initialize Umi with Devnet endpoint\n17 const umi = createUmi ( 'https://api.devnet.solana.com' )\n18\n19 // Load your wallet/keypair\n20 const wallet = ''\n21 const secretKey = JSON . parse ( readFileSync ( wallet , 'utf-8' ) )\n22 const keypair = umi . eddsa . createKeypairFromSecretKey ( new Uint8Array ( secretKey ) )\n23 umi . use ( keypairIdentity ( keypair ) )\n24\n25 // Your token mint address and destination wallet\n26 const mintAddress = publicKey ( '' )\n27 const destinationAddress = publicKey ( '' )\n28\n29 // Find the source token account (your account)\n30 const sourceTokenAccount = findAssociatedTokenPda ( umi , {\n31 mint : mintAddress ,\n32 owner : umi . identity . publicKey ,\n33 } )\n34\n35 // Find the destination token account\n36 const destinationTokenAccount = findAssociatedTokenPda ( umi , {\n37 mint : mintAddress ,\n38 owner : destinationAddress ,\n39 } )\n40\n41 // Create the destination token account if it doesn't exist\n42 transactionBuilder ( )\n43 . add ( createTokenIfMissing ( umi , {\n44 mint : mintAddress ,\n45 owner : destinationAddress ,\n46 } ) )\n47 // Transfer 100 tokens\n48 . add (\n49 transferTokens ( umi , {\n50 source : sourceTokenAccount ,\n51 destination : destinationTokenAccount ,\n52 amount : 100 ,\n53 } ) )\n54 . sendAndConfirm ( umi )\n55\n56 console . log ( 'Transferred 100 tokens' )\n57 console . log ( 'From:' , sourceTokenAccount )\n58 console . log ( 'To:' , destinationTokenAccount )\n1 # Transfer Tokens using the Metaplex CLI\n2\n3 # Usage: mplx toolbox token transfer \n4 mplx toolbox token transfer < MINT_ADDRESS > < AMOUNT > < DESTINATION_ADDRESS >\n5\n6 # Example: Transfer 100 tokens (0 decimals)\n7 mplx toolbox token transfer 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 100 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\n8\n9 # Example: Transfer 100 tokens (9 decimals)\n10 # Amount is in smallest units: 100 * 10^9 = 100000000000\n11 mplx toolbox token transfer 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 100000000000 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM\n12\n13 # Note: If the destination doesn't have a token account, it will be created automatically\nParameters\nCustomize these parameters for your transfer:\nParameter Description\nmintAddress The token mint address\ndestinationAddress Recipient wallet address\namount Number of tokens to transfer\nHow It Works\nThe transfer process involves four steps:\n- Find source token account - Locate your token account using findAssociatedTokenPda\n- Find destination token account - Locate the recipient's token account\n- Create destination token account if needed - Use createTokenIfMissing to ensure the recipient has a token account\n- Transfer tokens - Execute the transfer with transferTokens\nToken Accounts\nEach wallet has an Associated Token Account (ATA) for each type of token they hold. The findAssociatedTokenPda function derives the address of these accounts based on the wallet address and token mint.\nThe createTokenIfMissing function automatically creates the token account if it doesn't exist yet, or does nothing if it already exists. This ensures the transfer will always succeed.\nPrevious\n← Mint Tokens\nNext\nDistribute Tokens →"}
{"url":"https://docs.ton.org/contracts/overview","domain":"docs.ton.org","title":"Smart contracts","hash":"e6afb902b934580ee71727024b463a443c64955de0ef32d580a1f5bfb48d2f2a","tokens":497,"chars":1987,"crawler":"crawler-f6nn","verified":"exact","ts":1791172296166,"text":"Onboarding Nodes Applications APIs Contracts Smart contracts Tolk Tolk language TVM TON Virtual Machine Foundations Blockchain foundations\nSmart contracts\nHow to build, test, deploy, debug, and otherwise interact with TON smart contracts\nThis section covers the recommended toolchain, editor support, standard contracts, reusable techniques, and the legacy TypeScript environment.\nThe Web IDE is retired\nThe Web IDE at ide.ton.org has been retired and is no longer available. Develop locally with the Acton toolchain and one of the editor plugins below.\nToolchain\nTolk is the recommended language for TON smart contracts. Acton ↗️ is the recommended all-in-one toolchain for the entire contract development lifecycle, including building, testing, and deploying Tolk contracts.\nExternal documentation\nActon ↗️ documentation is hosted and updated externally.\nIDEs and editor plugins\nAdd support for the Acton toolchain, Tolk language, and intermediate TON languages to a local editor:\n- VS Code and forks — extension for VS Code, VSCodium, Cursor, Windsurf, and other VS Code-based editors\n- JetBrains IDEs — plugin for IntelliJ IDEA, WebStorm, CLion, PyCharm, and other JetBrains IDEs\nQuick start\nFollow the quickstart page in the Acton documentation .\nStandard contracts\nDescriptions of the most popular standardized contracts and how to work with them: Standard contracts .\nTechniques\nFocused how-to guides for advanced smart contract tasks:\n- Signing and signature verification\n- Contract sharding\n- Security best practices\n- Gas optimization\n- On-chain jetton processing\n- Using on-chain libraries\n- Random number generation\n- Contract upgrades\n- Vanity addresses\n- Zero-knowledge proofs\n- Groth16 examples\nBlueprint (legacy)\nBlueprint is a legacy TypeScript environment that is still supported for older projects.\nNotification reference\nPrevious Page\nJetBrains IDEs\nNext Page\nOn this page\nToolchain IDEs and editor plugins Quick start Standard contracts Techniques Blueprint (legacy)"}
{"url":"https://docs.optimism.io/app-developers/guides/testing-apps","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"5f22def151bdd8e853f1e0b1f7a2ff264f30ac58e362625b77c28d31c6fa619a","tokens":974,"chars":3894,"crawler":"crawler-f6nn","verified":"exact","ts":1791172298624,"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\nGuides\nTesting apps for OP Stack chains\nLearn best practices for testing apps on OP Stack chains.\nFor the most part, running applications on OP Stack chains is identical to running them on Ethereum, so the testing is identical too.\nIn this guide, you learn the best practices for OP Stack testing where there are differences.\nUnit tests and single layer integration tests\nThe vast majority of tests do not involve any OP Stack-specific features.\nIn those cases, while you could test everything on an OP Stack chain or a test network, that would normally be inefficient.\nMost Ethereum development stacks include features that make testing easier, which normal Ethereum clients, such as geth (and our modified version, op-geth ) don’t support.\nTherefore, it is a good idea to run the majority of tests, which do not rely on OP Stack-specific features, in the development stack.\nIt is a lot faster.\nIt is a best practice to design and run thorough tests across an OP test network, either in your local multichain development environment , our devnets , or on the test network , depending on your use case. Alternatively, with Tenderly Virtual TestNets you can run tests with complete integration with existing protocols, access to unlimited faucets, continuous state sync, and access to development tools such as Debugger and Simulator UI.\nRunning proper testing is key to identifying fringe cases where the equivalence between OP Stack chains and Ethereum breaks down (or where Ethereum mainnet itself and the development stack may be non-equivalent in a production environment).\nMultilayer integration tests\nSome apps need OP Stack-specific features that aren’t available as part of the development stack.\nFor example, if your decentralized application relies on inter-domain communication , the effort of developing a stub to let you debug it in a development stack is probably greater than the hassle of having the automated test go to a local multichain development environment each time.\nTesting and Staging with Tenderly\nTenderly Virtual TestNets provide a powerful environment for testing OP Stack applications with mainnet-like conditions. They offer several advantages for testing OP Stack applications:\n- Mainnet State Replication : Virtual TestNets can sync with the latest OP Stack mainnet state, allowing you to test against real network conditions and interact with up-to-date protocols without spending real assets.\n- Unlimited Faucet : Access unlimited test tokens for both native currency and ERC-20 tokens, enabling comprehensive testing of complex DeFi interactions.\n- Collaborative Testing : Your entire team can access the same testing environment, making it easier to debug issues and validate fixes.\n- CI/CD Integration : Incorporate automated testing in your deployment pipeline using Virtual TestNets’ API and GitHub Actions integration .\n- Development tools : Rely on the built-in developer explorer and debugging tools to analyze test transactions and contract interactions.\nIntegration with other products\nIn many cases a decentralized application requires the services of other contracts.\nFor example, Perpetual v. 2 cannot function without Uniswap v. 3 .\n- If that is the case, you can use mainnet forking . It works with OP Stack chains.\n- Create a Virtual TestNet to get access to third party contracts (e.g. Uniswap) and it’s latest or historical state.\n- Alternatively, you can connect to our test network if those contracts are also deployed there (in many cases they are).\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://gov.optimism.io/c/general/1","domain":"gov.optimism.io","title":"✨ General - Optimism Collective","hash":"1864a5e6bf519f96a6fcde35499b12a2953a5a1de1e16abbfe22b03fd4b9e728","tokens":671,"chars":2684,"crawler":"crawler-f6nn","verified":"exact","ts":1791172301445,"text":"Optimism Collective\n✨ General\nTopic\nReplies\nViews\nActivity\nExploring execution-time authorization for Superchain applications\n4\n64\nSeptember 24, 2026\nSeason 8 Growth Grants - TVL Impact Review\nseason-8\n2\n162\nSeptember 23, 2026\nOP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n3\n104\nSeptember 4, 2026\nAccelerated Decentralization Proposal For Optimism\n36\n3597\nAugust 26, 2026\nSandcastles and Social Mercenaries: Why EVM DAOs Are Being Looted\n2\n88\nAugust 7, 2026\nBreaking the Capitalist Supremacy: How Grant Bottlenecks Drive the Sea Shell Economy\n1\n81\nJuly 21, 2026\nThe Capitalist Supremacy Trap: Why Our DAO Governance is a Digitized Feudal State\n7\n131\nJuly 21, 2026\nThe Legalist Trap: Why Smart-Contract Absolutism is Killing Our DAO\n1\n94\nJuly 7, 2026\nThe VC-Driven Oligarchy: Why Token-Weighted Voting is Killing Our DAO\n4\n142\nJuly 7, 2026\nSchool project research\n4\n101\nJune 26, 2026\nIntroduction about myself\n8\n167\nJune 25, 2026\nHelp: Dashboard not loading wallet\n1\n111\nJune 25, 2026\nOptimism OP and liquidity Alliance Erisprotocol Strategy\n3\n143\nJune 17, 2026\nRFC: Six-Month Superchain Education Campaign with Underground Crypto\n2\n89\nJune 16, 2026\nExpand Superchain Passport to Include All OP Superchain Apps\n0\n83\nJune 1, 2026\nThe Northern Trade Link – Enhancing Logistics as a Public Good in Somaliland\n5\n134\nMay 19, 2026\nShould the Optimism Security Council Include a Non-Technical Member Role?\nseason-9\n0\n72\nMay 12, 2026\nRFP Hub: grants and funding opportunities across web3\n5\n133\nMay 2, 2026\nURTAN: Can DeFi Build a Universal Panic Button ? Lessons from Kelp Hack\n0\n49\nApril 26, 2026\nStatus of the Bedrock Constitution — Working Constitution expires April 2026\n2\n94\nApril 23, 2026\nTally Is Shutting Down — Option to Maintain the Existing Interface (No Contract Changes)\n0\n36\nApril 13, 2026\nMistakenly sent USDT to the USDT contract address, instead of the receiving exchange address\n4\n115\nMarch 19, 2026\nBase, the Superchain, and Governance: Questions That Merit Answers\n5\n1071\nMarch 3, 2026\nSeeking Feedback: A New Tool to Prevent Crypto Transfer Mistakes\n0\n42\nFebruary 13, 2026\nDecentralised sequencer\n1\n75\nFebruary 12, 2026\nIntroducing a Deterministic, Audit-Ready Treasury Reporting MVP for Optimism DAOs\n0\n50\nJanuary 26, 2026\nUsers who sold the initial OP airdrop should become ineligible for all future airdrops\n599\n43708\nJanuary 20, 2026\nThe Quantum-Mirrored Internet: Securing All of Web3 on Optimism 🌈\n2\n68\nJanuary 13, 2026\nVenture studio for Optimism projects, offered by Pollen Labs - General communication thread\nseason-6\n6\n329\nJanuary 10, 2026\nS8 to S9 Council Budget Reprice Request\nseason-9\n0\n134\nJanuary 8, 2026\nnext page →"}
{"url":"https://docs.phantom.com/sdks/react-sdk/index","domain":"docs.phantom.com","title":"Phantom React SDK - Phantom developer documentation","hash":"9201bf3f4d5c4af7bdcb961d548e9eac1d117c00083504c07db68e4f0d6b7b59","tokens":4626,"chars":18504,"crawler":"crawler-f6nn","verified":"exact","ts":1791172304344,"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\nReact SDK\nPhantom React SDK\nIntegrate Phantom wallets into React web apps with hooks for multi-chain transaction support.\nThe Phantom Connect React SDK provides React hooks for connecting to existing Phantom user wallets in your React apps with native transaction support across multiple blockchains.\nQuick start\nGenerate a new Solana project using the Phantom Embedded React Starter template.\n-\nnpm\n-\npnpm\n-\nyarn\n-\nbun\nnpx -y create-solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react\npnpm create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react\nyarn create solana-dapp -t solana-foundation/templates/community/phantom-embedded-react\nbun create solana-dapp@latest -t solana-foundation/templates/community/phantom-embedded-react\nRun the command above in your terminal to get started.\nView template on Solana Templates →\nFeatures\n- Built for React: Provides React hooks ( usePhantom , useModal ) and a provider component for app-level configuration.\n- Multi-chain support: Solana and Ethereum with dedicated hooks.\n- Connection modal: Built-in, customizable modal for connecting users to Phantom.\n- Flexible authentication providers: OAuth (Google, Apple) and the Phantom browser extension.\n- User wallet integration: Connects to existing Phantom user wallets using Phantom Connect.\n- TypeScript support: Fully typed API surface.\nSecurity\nThe Phantom Connect React SDK connects to existing Phantom user wallets, ensuring:\n- Users control their own wallets and private keys.\n- Integration with Phantom’s secure wallet infrastructure.\n- No private key handling in your application.\n- User maintains full control of their assets.\nPrerequisites\nPhantom Portal is not accepting new applications at this time. New sign-ups for Phantom Connect SDK access and new app submissions to the Phantom app directory are paused. Existing Portal apps and App IDs are not affected.\n- Use an existing app: Sign in to the Phantom Portal and select your app.\n- Obtain your App ID:\n- In Phantom Portal, expand your app in the left navigation, then select Set Up .\n- Your App ID appears at the top of the page.\n- Allowlist your domains and redirect URLs: Add your app’s domains and redirect URLs in the Phantom Portal to enable wallet connections.\nAuthentication configuration\nWhen using OAuth providers (google, apple), you’ll need to configure authentication options:\nauthOptions : {\nredirectUrl : \"https://yourapp.com/auth/callback\" , // Your callback page\n}\nImportant notes about redirectUrl :\n- Must be an existing page/route in your application\n- Must be whitelisted in your Phantom Portal app configuration\n- This is where users will be redirected after completing OAuth authentication\n- Required for google and apple providers\n- Not required for injected provider\nInstallation\nnpm install @phantom/react-sdk\nDependencies\nInstall additional dependencies based on the networks you want to support:\nNetwork support Required dependencies\nSolana @solana/web3.js OR @solana/kit\nEthereum/EVM viem\nExample for Solana and Ethereum support:\nnpm install @phantom/react-sdk @solana/web3.js viem\nQuick start\nimport { PhantomProvider , useModal , darkTheme , usePhantom } from \"@phantom/react-sdk\" ;\nimport { AddressType } from \"@phantom/browser-sdk\" ;\nfunction App () {\nreturn (\n< PhantomProvider\nconfig = { {\nproviders: [ \"google\" , \"apple\" , \"injected\" ], // Enabled auth methods\nappId: \"your-app-id\" , // Get your app ID from phantom.com/portal\naddressTypes: [ AddressType . solana , AddressType . ethereum ],\nauthOptions: {\nredirectUrl: \"https://yourapp.com/auth/callback\" , // Must be whitelisted in Phantom Portal\n},\n} }\ntheme = { darkTheme }\nappIcon = \"https://your-app.com/icon.png\"\nappName = \"Your App Name\"\n>\n< WalletComponent />\n\n);\n}\nfunction WalletComponent () {\nconst { open , close , isOpened } = useModal ();\nconst { isConnected , user } = usePhantom ();\nif ( isConnected ) {\nreturn (\n< div >\n< p > Connected \n\n);\n}\nreturn < button onClick = { open } > Connect Wallet ;\n}\nConnection Modal\nThe SDK includes a built-in connection modal UI that provides a user-friendly interface for connecting to Phantom. The modal supports multiple connection methods (Google, Apple, browser extension) and handles all connection logic automatically.\nUsing the Modal with useModal Hook\nTo use the modal, pass a theme prop to PhantomProvider and use the useModal() hook to control visibility:\nimport { PhantomProvider , useModal , darkTheme , usePhantom } from \"@phantom/react-sdk\" ;\nimport { AddressType } from \"@phantom/browser-sdk\" ;\nfunction App () {\nreturn (\n< PhantomProvider\nconfig = { {\nproviders: [ \"google\" , \"apple\" , \"injected\" ],\nappId: \"your-app-id\" ,\naddressTypes: [ AddressType . solana , AddressType . ethereum ],\n} }\ntheme = { darkTheme } // or lightTheme, or custom theme object\nappIcon = \"https://your-app.com/icon.png\"\nappName = \"Your App Name\"\n>\n< WalletComponent />\n\n);\n}\nfunction WalletComponent () {\nconst { open , close , isOpened } = useModal ();\nconst { isConnected } = usePhantom ();\nif ( isConnected ) {\nreturn (\n< div >\n< p > Connected \n\n);\n}\nreturn < button onClick = { open } > Connect Wallet ;\n}\nModal features:\n- Multiple auth providers : Google, Apple, browser extension\n- Automatic provider detection : Shows browser extension option when Phantom is installed\n- Error handling : Clear error messages displayed in the modal\n- Loading states : Visual feedback during connection attempts\n- Responsive design : Optimized for both mobile and desktop\nConnectButton Component\nA ready-to-use button component that handles the complete connection flow:\nimport { ConnectButton , AddressType } from \"@phantom/react-sdk\" ;\nfunction Header () {\nreturn (\n< div >\n{ /* Default: Shows first available address */ }\n< ConnectButton />\n{ /* Show specific address type */ }\n< ConnectButton addressType = { AddressType . solana } />\n< ConnectButton addressType = { AddressType . ethereum } />\n{ /* Full width button */ }\n< ConnectButton fullWidth />\n\n);\n}\nConnectButton features:\n- When disconnected: Opens connection modal with auth provider options\n- When connected: Displays truncated address and opens wallet management modal\n- Uses theme styling for consistent appearance\nConnectBox component\nAn inline embedded component that displays the connection UI directly in your page layout (without a modal backdrop). Perfect for auth callback pages or when you want a more integrated connection experience. The component automatically handles all connection states including loading, error, and success during the auth callback flow.\nimport { ConnectBox } from \"@phantom/react-sdk\" ;\nfunction AuthCallbackPage () {\nreturn (\n< div >\n< h1 > Connecting to Phantom... \n< ConnectBox />\n\n);\n}\nProps:\nProperty Type Default Description\nmaxWidth string | number \"350px\" Maximum width of the box\ntransparent boolean false Removes background, border, and shadow for a transparent appearance\nappIcon string — URL to your app icon (optional, can also be set via PhantomProvider )\nappName string — Your app name (optional, can also be set via PhantomProvider )\nUsage Examples:\nimport { ConnectBox } from \"@phantom/react-sdk\" ;\n// Default usage\n< ConnectBox />\n// Custom width\n< ConnectBox maxWidth = \"500px\" />\n// Transparent (no background/border)\n< ConnectBox transparent />\n// Custom width with transparent\n< ConnectBox maxWidth = { 600 } transparent />\nConnectBox Features:\n- Inline embedded : Renders directly in page flow (not as a floating modal)\n- Auto state management : Automatically shows connection/login UI when disconnected, wallet info when connected\n- Auth callback support : Handles loading and error states during OAuth callback flows\n- No close button : Designed for embedded use cases where users shouldn’t dismiss the UI\n- Theme-aware : Uses your configured theme for consistent styling\nUse ConnectBox for auth callback pages : When using OAuth providers (Google, Apple), users are redirected to your callback URL after authentication. Place ConnectBox on this page to automatically handle the auth flow completion with proper loading and error states.\nTheming\nThe SDK includes pre-built themes and supports full customization to match your app’s design.\nPre-built themes\nUse the included darkTheme or lightTheme :\nimport { PhantomProvider , darkTheme , lightTheme } from \"@phantom/react-sdk\" ;\n// Dark theme\n< PhantomProvider config = { config } theme = { darkTheme } appIcon = \"...\" appName = \"...\" >\n< App />\n\n// Light theme\n< PhantomProvider config = { config } theme = { lightTheme } appIcon = \"...\" appName = \"...\" >\n< App />\n\nCustom themes\nCreate a custom theme object to fully control the modal’s appearance:\nconst customTheme = {\nbackground: \"#1a1a1a\" , // Background color for modal\ntext: \"#ffffff\" , // Primary text color\nsecondary: \"#98979C\" , // Secondary color for text, borders, dividers\nbrand: \"#ab9ff2\" , // Brand/primary action color\nerror: \"#ff4444\" , // Error state color\nsuccess: \"#00ff00\" , // Success state color\nborderRadius: \"16px\" , // Border radius for buttons and modal\noverlay: \"rgba(0, 0, 0, 0.8)\" , // Overlay background color (with opacity)\n};\n< PhantomProvider config = { config } theme = { customTheme } appIcon = \"...\" appName = \"...\" >\n< App />\n\nProperty Description Example\nbackground Modal background color \"#1a1a1a\"\ntext Primary text color \"#ffffff\"\nsecondary Secondary text, borders, and dividers \"#98979C\"\nbrand Brand/primary action color \"#ab9ff2\"\nerror Error state color \"#ff4444\"\nsuccess Success state color \"#00ff00\"\nborderRadius Border radius for buttons and modal \"16px\"\noverlay Modal overlay background (supports opacity) \"rgba(0, 0, 0, 0.8)\"\nThe secondary color must be a hex color value (for example, #98979C ) as it’s used to derive auxiliary colors with opacity.\nChain-Specific Hooks\nThe React SDK provides dedicated hooks for each blockchain:\nuseSolana hook\nimport { useSolana } from \"@phantom/react-sdk\" ;\nfunction SolanaOperations () {\nconst { solana , isAvailable } = useSolana ();\n// Check if Solana is available before using it\nif ( ! isAvailable ) {\nreturn < div > Solana is not available for the current wallet ;\n}\nconst signMessage = async () => {\nconst signature = await solana . signMessage ( \"Hello Solana!\" );\nconsole . log ( \"Signature:\" , signature );\n};\nconst signAndSendTransaction = async () => {\nconst result = await solana . signAndSendTransaction ( transaction );\nconsole . log ( \"Transaction sent:\" , result . hash );\n};\nconst switchNetwork = async () => {\nawait solana . switchNetwork ( 'devnet' );\n};\nreturn (\n< div >\n< button onClick = { signMessage } > Sign Message \n< button onClick = { signAndSendTransaction } > Send Transaction \n< button onClick = { switchNetwork } > Switch to Devnet \n< p > Connected: { solana . isConnected ? 'Yes' : 'No' } \n\n);\n}\nuseEthereum hook\nEVM support for Phantom Connect embedded wallets will go live later in 2026.\nimport { useEthereum } from \"@phantom/react-sdk\" ;\nfunction EthereumOperations () {\nconst { ethereum , isAvailable } = useEthereum ();\n// Check if Ethereum is available before using it\nif ( ! isAvailable ) {\nreturn < div > Ethereum is not available for the current wallet ;\n}\nconst signPersonalMessage = async () => {\nconst accounts = await ethereum . getAccounts ();\nconst signature = await ethereum . signPersonalMessage ( \"Hello Ethereum!\" , accounts [ 0 ]);\nconsole . log ( \"Signature:\" , signature );\n};\nconst sendTransaction = async () => {\nconst result = await ethereum . sendTransaction ({\nto: \"0x742d35Cc6634C0532925a3b8D4C8db86fB5C4A7E\" ,\nvalue: \"1000000000000000000\" , // 1 ETH in wei\ngas: \"21000\" ,\n});\nconsole . log ( \"Transaction sent:\" , result . hash );\n};\nconst switchChain = async () => {\nawait ethereum . switchChain ( 137 ); // Switch to Polygon\n};\nreturn (\n< div >\n< button onClick = { signPersonalMessage } > Sign Personal Message \n< button onClick = { sendTransaction } > Send Transaction \n< button onClick = { switchChain } > Switch to Polygon \n< p > Connected: { ethereum . isConnected ? 'Yes' : 'No' } \n\n);\n}\nMonad support has been deprecated.\nSupported EVM Networks:\nNetwork Chain ID Usage\nEthereum Mainnet 1 ethereum.switchChain(1)\nEthereum Sepolia 11155111 ethereum.switchChain(11155111)\nPolygon Mainnet 137 ethereum.switchChain(137)\nPolygon Amoy 80002 ethereum.switchChain(80002)\nBase Mainnet 8453 ethereum.switchChain(8453)\nBase Sepolia 84532 ethereum.switchChain(84532)\nArbitrum One 42161 ethereum.switchChain(42161)\nArbitrum Sepolia 421614 ethereum.switchChain(421614)\nMonad Mainnet (Deprecated) 143 ethereum.switchChain(143)\nMonad Testnet (Deprecated) 10143 ethereum.switchChain(10143)\nAuto-Confirm Hook (Injected Provider Only)\nThe SDK provides auto-confirm functionality that allows automatic transaction confirmation for specified chains.\nuseAutoConfirm hook\nimport { useAutoConfirm , NetworkId } from \"@phantom/react-sdk\" ;\nfunction AutoConfirmControls () {\nconst {\nenable ,\ndisable ,\nstatus ,\nsupportedChains ,\nisLoading ,\nerror ,\n} = useAutoConfirm ();\nconst handleEnable = async () => {\n// Enable auto-confirm for specific chains\nconst result = await enable ({\nchains: [ NetworkId . SOLANA_DEVNET , NetworkId . ETHEREUM_MAINNET ]\n});\nconsole . log ( \"Auto-confirm enabled:\" , result );\n};\nconst handleDisable = async () => {\nawait disable ();\nconsole . log ( \"Auto-confirm disabled\" );\n};\nreturn (\n< div >\n< p > Status: { status ?. enabled ? \"Enabled\" : \"Disabled\" } \n< button onClick = { handleEnable } disabled = { isLoading } >\nEnable Auto-Confirm\n\n< button onClick = { handleDisable } disabled = { isLoading } >\nDisable Auto-Confirm\n\n\n);\n}\nWallet Discovery Hook\nuseDiscoveredWallets\nGet discovered injected wallets with automatic loading and error states. Discovers wallets using Wallet Standard (Solana) and EIP-6963 (Ethereum) standards.\nimport { useDiscoveredWallets } from \"@phantom/react-sdk\" ;\nfunction WalletSelector () {\nconst { wallets , isLoading , error , refetch } = useDiscoveredWallets ();\nif ( isLoading ) {\nreturn < div > Discovering wallets... ;\n}\nif ( error ) {\nreturn < div > Error discovering wallets: { error . message } ;\n}\nreturn (\n< div >\n< h3 > Available Wallets \n{ wallets . map (( wallet ) => (\n< div key = { wallet . id } >\n< img src = { wallet . icon } alt = { wallet . name } width = { 24 } />\n< span > { wallet . name } \n\n)) }\n< button onClick = { refetch } > Refresh \n\n);\n}\nReturns:\nProperty Type Description\nwallets InjectedWalletInfo[] Array of discovered wallet information\nisLoading boolean true while discovery is in progress\nerror Error | null Error object if discovery fails\nrefetch () => Promise Function to manually refresh the wallet list\nSDK Initialization\nThe SDK provides an isLoading state to track when initialization and autoconnect are in progress:\nimport { useConnect , usePhantom } from \"@phantom/react-sdk\" ;\nfunction App () {\nconst { isLoading } = usePhantom ();\nconst { connect } = useConnect ();\n// Show loading state while SDK initializes\nif ( isLoading ) {\nreturn (\n< div >\n< h1 > Initializing Phantom SDK... \n< p > Please wait... \n\n);\n}\n// SDK is ready\nreturn (\n< div >\n< h1 > Welcome! \n< button onClick = { () => connect ({ provider: \"injected\" }) } >\nConnect Wallet\n\n\n);\n}\nDebug Configuration\nConfigure debug logging by passing a debugConfig prop to PhantomProvider :\nimport { PhantomProvider , DebugLevel } from \"@phantom/react-sdk\" ;\nfunction App () {\nconst [ debugMessages , setDebugMessages ] = useState ([]);\nconst debugConfig = {\nenabled: true ,\nlevel: DebugLevel . INFO ,\ncallback : ( message ) => {\nsetDebugMessages (( prev ) => [ ... prev , message ]);\n},\n};\nreturn (\n< PhantomProvider config = { config } debugConfig = { debugConfig } >\n< YourApp />\n\n);\n}\nDebug configuration properties:\nProperty Type Description\nenabled boolean Enable debug logging\nlevel DebugLevel Debug level (ERROR, WARN, INFO, DEBUG)\ncallback (message: DebugMessage) => void Custom debug message handler\nAvailable hooks\nHook Purpose Returns\nuseModal Control the connection modal { open, close, isOpened }\nusePhantom Access wallet/user state { isConnected, isLoading, user, wallet }\nuseConnect Connect to wallet { connect, isConnecting, isLoading, error }\nuseAccounts Get wallet addresses WalletAddress[] or null\nuseIsExtensionInstalled Check extension status { isLoading, isInstalled }\nuseDisconnect Disconnect from wallet { disconnect, isDisconnecting }\nuseAutoConfirm Auto-confirm management (injected only) { enable, disable, status, supportedChains, ... }\nuseDiscoveredWallets Get discovered injected wallets { wallets, isLoading, error, refetch }\nuseSolana Solana chain operations { solana, isAvailable }\nuseEthereum Ethereum chain operations { ethereum, isAvailable }\nuseTheme Access current theme PhantomTheme\nWhat you can do\nConnect to wallets\nLearn how to connect to Phantom user wallets with React hooks\nSign messages\nImplement message signing for authentication and verification\nSign and send transactions\nHandle transaction signing and broadcasting across blockchains\nStarter kits and examples\nGet started quickly with production-ready React templates:\nReact SDK demo app\nFull-featured React example with wallet connection, signing, and transactions\nNext.js example\nComplete Next.js integration with Phantom React SDK\nWagmi Integration\nUse Phantom SDK alongside Wagmi for enhanced Ethereum support\nConnect modal example\nDrop-in connect modal example showing the full sign-in flow\nAll examples\nBrowse all example applications on GitHub\nAdditional resources\nSDK overview\nCompare all Phantom SDKs and choose the right one\nPhantom Connect\nLearn about authentication flows and user experience\nJWT authentication\nImplement custom JWT-based authentication\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.anza.xyz/cli/wallets/paper","domain":"docs.anza.xyz","title":"Paper Wallets using the Solana CLI | Agave","hash":"a93d7e0a02a1f97c9958c4489bd7d3275f70175c12651eb8a80211c79b078179","tokens":1672,"chars":6685,"crawler":"crawler-f6nn","verified":"exact","ts":1791172306373,"text":"Skip to main content\nPaper Wallets using the Solana CLI\nThis document describes how to create and use a paper wallet with the Solana CLI\ntools.\nWe do not intend to advise on how to securely create or manage paper\nwallets. Please research the security concerns carefully.\nOverview\nSolana provides a key generation tool to derive keys from\nBIP39 -compliant\nseed phrases. Solana CLI commands for running a validator and staking tokens all\nsupport keypair input via seed phrases.\nPaper Wallet Usage\nSolana commands can be run without ever saving a keypair to disk on a machine.\nIf avoiding writing a private key to disk is a security concern of yours, you've\ncome to the right place.\nEven using this secure input method, it's still possible that a private key\ngets written to disk by unencrypted memory swaps. It is the user's\nresponsibility to protect against this scenario.\nBefore You Begin\n- Install the Solana command-line tools\nCheck your installation\nCheck that solana-keygen is installed correctly by running:\nsolana-keygen --version\nCreating a Paper Wallet\nUsing the solana-keygen tool, it is possible to generate new seed phrases as\nwell as derive a keypair from an existing seed phrase and (optional) passphrase.\nThe seed phrase and passphrase can be used together as a paper wallet. As long\nas you keep your seed phrase and passphrase stored safely, you can use them to\naccess your account.\nFor more information about how seed phrases work, review this\nBitcoin Wiki page .\nSeed Phrase Generation\nGenerating a new keypair can be done using the solana-keygen new command. The\ncommand will generate a random seed phrase, ask you to enter an optional\npassphrase, and then will display the derived public key and the generated seed\nphrase for your paper wallet.\nAfter copying down your seed phrase, you can use the\npublic key derivation instructions to verify that you\nhave not made any errors.\nsolana-keygen new --no-outfile\nIf the --no-outfile flag is omitted , the default behavior is to write\nthe keypair to ~/.config/solana/id.json , resulting in a\nfile system wallet .\nThe output of this command will display a line like this:\npubkey: 9ZNTfG4NyQgxy2SWjSiQoUyBPEvXT2xo7fKc5hPYYJ7b\nThe value shown after pubkey: is your wallet address .\nNote: In working with paper wallets and file system wallets, the terms\n\"pubkey\" and \"wallet address\" are sometimes used interchangeably.\nFor added security, increase the seed phrase word count using the\n--word-count argument\nFor full usage details, run:\nsolana-keygen new --help\nPublic Key Derivation\nPublic keys can be derived from a seed phrase and a passphrase if you choose to\nuse one. This is useful for using an offline-generated seed phrase to derive a\nvalid public key. The solana-keygen pubkey command will walk you through how\nto use your seed phrase (and a passphrase if you chose to use one) as a signer\nwith the solana command-line tools using the prompt URI scheme.\nsolana-keygen pubkey prompt://\nNote that you could potentially use different passphrases for the same seed\nphrase. Each unique passphrase will yield a different keypair.\nThe solana-keygen tool uses the same BIP39 standard English word list as it\ndoes to generate seed phrases. If your seed phrase was generated with another\ntool that uses a different word list, you can still use solana-keygen , but\nwill need to pass the --skip-seed-phrase-validation argument and forego this\nvalidation.\nsolana-keygen pubkey prompt:// --skip-seed-phrase-validation\nAfter entering your seed phrase with solana-keygen pubkey prompt:// the\nconsole will display a string of base-58 characters. This is the\nderived solana BIP44 wallet address associated\nwith your seed phrase.\nCopy the derived address to a USB stick for easy usage on networked computers\nIf needed, you can access the legacy, raw keypair's pubkey by instead passing\nthe ASK keyword:\nsolana-keygen pubkey ASK\nA common next step is to check the balance of the\naccount associated with a public key\nFor full usage details, run:\nsolana-keygen pubkey --help\nHierarchical Derivation\nThe solana-cli supports\nBIP32 and\nBIP44\nhierarchical derivation of private keys from your seed phrase and passphrase by\nadding either the ?key= query string or the ?full-path= query string.\nBy default, prompt: will derive solana's base derivation path m/44'/501' . To\nderive a child key, supply the ?key=/ query string.\nsolana-keygen pubkey 'prompt://?key=0/1'\nTo use a derivation path other than solana's standard BIP44, you can supply\n?full-path=m//// .\nsolana-keygen pubkey 'prompt://?full-path=m/44/2017/0/1'\nBecause Solana uses Ed25519 keypairs, as per\nSLIP-0010 all\nderivation-path indexes will be promoted to hardened indexes -- eg.\n?key=0'/0' , ?full-path=m/44'/2017'/0'/1' -- regardless of whether ticks are\nincluded in the query-string input.\nVerifying the Keypair\nTo verify you control the private key of a paper wallet address, use\nsolana-keygen verify :\nsolana-keygen verify prompt://\nwhere is replaced with the wallet address and the keyword prompt://\ntells the command to prompt you for the keypair's seed phrase; key and\nfull-path query-strings accepted. Note that for security reasons, your seed\nphrase will not be displayed as you type. After entering your seed phrase, the\ncommand will output \"Success\" if the given public key matches the keypair\ngenerated from your seed phrase, and \"Failed\" otherwise.\nChecking Account Balance\nAll that is needed to check an account balance is the public key of an account.\nTo retrieve public keys securely from a paper wallet, follow the\nPublic Key Derivation instructions on an\nair gapped computer .\nPublic keys can then be typed manually or transferred via a USB stick to a\nnetworked machine.\nNext, configure the solana CLI tool to\nconnect to a particular cluster :\nsolana config set --url # (i.e. https://api.mainnet-beta.solana.com)\nFinally, to check the balance, run the following command:\nsolana balance \nCreating Multiple Paper Wallet Addresses\nYou can create as many wallet addresses as you like. Simply re-run the steps in\nSeed Phrase Generation or\nPublic Key Derivation to create a new address.\nMultiple wallet addresses can be useful if you want to transfer tokens between\nyour own accounts for different purposes.\nSupport\nYou can find additional support and get help on the\nSolana StackExchange .\n- Overview\n- Paper Wallet Usage\n- Before You Begin\n- Check your installation\n- Creating a Paper Wallet\n- Seed Phrase Generation\n- Public Key Derivation\n- Hierarchical Derivation\n- Verifying the Keypair\n- Checking Account Balance\n- Creating Multiple Paper Wallet Addresses\n- Support"}
{"url":"https://docs.near.org/chain-abstraction/omnibridge/how-it-works","domain":"docs.near.org","title":"How Omni Bridge Works - NEAR Docs","hash":"2beca3eeb3cb2e0066c723254439f55ea0b7e37f4063ad1798ef3f6b298f3e77","tokens":1545,"chars":6180,"crawler":"crawler-f6nn","verified":"exact","ts":1791172309095,"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\nHow Omni Bridge Works\nLearn how Omni Bridge uses Chain Signatures to enable cross-chain transfers.\nThe journey toward truly trustless cross-chain communication took a significant leap forward when the NEAR team created the first trustless bridge with Ethereum (Rainbow Bridge). This pioneering achievement demonstrated that completely trustless cross-chain communication was possible, marking a crucial step toward the vision of chain abstraction. However, this approach relied on implementing a NEAR light client directly on Ethereum - essentially requiring Ethereum to understand and verify NEAR’s complex blockchain rules.\nOmni Bridge introduces a more elegant solution using Chain Signatures. Instead of running light clients on each destination chain, it leverages Chain Signature’s MPC Service to enable secure cross-chain message verification without the overhead of light client verification. This new approach reduces verification times from hours to minutes while significantly reducing gas costs across all supported chains.\nIssues with Light Clients\nA light client is a smart contract that lets one blockchain verify events happening on another blockchain. In Rainbow Bridge’s case, the Ethereum light client needs to track NEAR’s blocks, verify its validators’ signatures, and confirm transactions. This comes with major technical challenges: it requires storing two weeks of Ethereum block data, maintaining an updated list of NEAR validators and their stakes, and most crucially, verifying NEAR’s ED25519 signatures - a process Ethereum wasn’t built for. This verification is computationally expensive, making the whole process slow, costly, and ultimately a major bottleneck.\nFor example, with Rainbow Bridge, transactions from NEAR to Ethereum take between 4 and 8 hours due to the 4-hour challenge period and block submission intervals driven by Ethereum’s high gas costs. More importantly, this approach becomes increasingly impractical when connecting to multiple chains, as each chain would require its own light client implementation. Some chains, such as Bitcoin, don’t even support smart contracts, making it technically impossible to implement a NEAR light client.\nWhile we still need to support light clients of different networks on NEAR (which is significantly easier to implement), a different approach is needed for verifying NEAR state on foreign chains.\nToken Standards and Cross-Chain Communication\nBefore exploring how Chain Signatures solves these issues, it’s important to understand how tokens work on NEAR. NEP-141 , NEAR’s fungible token standard, has a key feature that sets it apart from Ethereum’s ERC-20: built-in composability through transfer-and-call functionality.\nWhen a token transfer happens on NEAR using ft_transfer_call , the token contract first transfers the tokens and then automatically calls the specified ft_on_transfer method on the receiver contract. While these operations happen in sequence within the same transaction, the receiver contract has the ability to reject the transfer, causing the tokens to be refunded. This atomic behavior ensures the integrity and safety of bridge operations by preventing partial execution states.\nFor more information see Fungible Tokens .\nEnter Chain Signatures\nInstead of maintaining complex light clients on destination chains, Chain Signatures introduces a fundamentally different approach based on three core components:\n-\nDeterministic Address Derivation - Every NEAR account can mathematically derive addresses on other chains through derivation paths. This isn’t just a mapping - it’s a cryptographic derivation that ensures the same NEAR account always controls the same set of addresses across all supported chains.\n-\nBridge Smart Contract - A central contract on NEAR coordinates with the MPC network to generate secure signatures for cross-chain transactions. This contract handles the token locking and requesting of signatures for outbound transfers\n-\nMPC Service - A decentralized network of nodes that jointly sign transactions without ever reconstructing a full private key. The security comes from threshold cryptography - no single node or small group of nodes can create valid signatures alone.\nPutting It All Together\nAs we’ve learned, Chain Signatures fundamentally changes the verification mechanism for cross-chain messages. Here’s what this means in practice:\nThe light client approach requires destination chains to verify ED25519 signatures from NEAR validators. Chain Signatures replaces this with a single MPC signature verification. Destination chains only need to verify one signature using their native signature verification schemes - typically ECDSA for EVM chains.\nNEP-141’s transaction guarantees handle the security of token locking. A transfer creates two operations within a single transaction :\n- Lock tokens and record the transfer state\n- Request MPC signature for the destination chain\nThe Locker contract requests signatures from the MPC network, which then generates signatures for valid transfer requests. This replaces the need for challenge periods - the security derives from the MPC threshold guarantees rather than optimistic assumptions.\nAdding new chains becomes a matter of implementing three standard components:\n- Chain-specific address derivation\n- MPC signature verification (or transaction signing for chains like Bitcoin)\n- Bridge contract deployment\n- Communication path for transfers back to NEAR (currently using Wormhole for newer chains)\nWhile we still need light clients on NEAR for receiving transfers from other chains, this approach makes it feasible to support a wider range of chains without implementing complex verification logic on each destination chain.\nTo get started building with Omni Bridge, see:\n- Bridge SDK JS Omni Bridge implementation in JavaScript\n- Bridge SDK Rust Omni Bridge implementation in Rust\nWas this page helpful?"}
{"url":"https://gov.optimism.io/t/expand-superchain-passport-to-include-all-op-superchain-apps/10689","domain":"gov.optimism.io","title":"Expand Superchain Passport to Include All OP Superchain Apps - ✨ General - Optimism Collective","hash":"6edfb0ed59a676ef43683643f5a31323c4e0e524aef564c00828d76e0535b5a0","tokens":705,"chars":2820,"crawler":"crawler-f6nn","verified":"exact","ts":1791172311544,"text":"Optimism Collective\nExpand Superchain Passport to Include All OP Superchain Apps\n✨ General\nop001\nJune 1, 2026, 10:28am\n1\nExpand Superchain Passport to Include All OP Superchain Apps\nSummary\nI would like to propose expanding Superchain Passport to include all applications and products that support the OP Superchain ecosystem.\nMotivation\nThe OP Superchain ecosystem continues to grow rapidly, with new applications, infrastructure providers, DeFi protocols, consumer apps, and developer tools launching across Superchain networks. However, discovering these products can still be difficult for users, especially newcomers.\nSuperchain Passport is already a valuable entry point for users. By expanding it to showcase all eligible Superchain-supported products, Passport could become the primary hub for ecosystem discovery.\nProposal\nAdd a dedicated ecosystem directory within Superchain Passport that includes applications and products operating on Superchain networks.\nPossible features:\n-\nFilter by chain (OP Mainnet, Base, Unichain, Ink, Soneium, and other Superchain networks).\n-\nFilter by category (DeFi, Gaming, NFTs, Infrastructure, Social, AI, Developer Tools, etc.).\n-\nAllow projects to submit their applications for inclusion.\n-\nHighlight products that are actively deployed on Superchain chains.\n-\nEnable users to easily discover and explore applications across the ecosystem.\nBenefits\nBetter User Discovery\nUsers can find relevant applications in one place instead of searching across multiple websites and ecosystem pages.\nStronger Ecosystem Growth\nProjects gain additional visibility, helping attract more users and activity across the OP Superchain.\nImproved Onboarding\nNew users can quickly understand what they can do within the Superchain ecosystem and begin using applications immediately.\nIncreased Network Usage\nMaking ecosystem discovery easier can drive more activity across OP Mainnet and other Superchain networks.\nConclusion\nThe OP Superchain is becoming one of the largest blockchain ecosystems. Expanding Superchain Passport to include all Superchain-supported applications would make Passport a central discovery hub, improve onboarding, and help users engage more deeply with the ecosystem.\n2 Likes\nRelated topics\nTopic\nReplies\nViews\nActivity\nIntroducing the new: Superchain.Eco\nUpdates and Announcements 📢\n1\n185\nMarch 14, 2025\n[Looking for sponsor] Intent 3 Open Finance\nGovernance Fund Missions\ncycle-27\n7\n462\nSeptember 10, 2024\n[Mission Request]: Intent #3B: Support the Superchain\nGovernance Fund Missions\nseason-6\n6\n2130\nAugust 16, 2024\n[Mission Request] Decentralized Solvers and Aggregators on OP Mainnet / Superchain\nGovernance Fund Missions\ncycle-27\n10\n556\nOctober 8, 2024\n[Mission Request] Superchain Borrow/Lend Aggregator\nGovernance Fund Missions\ncycle-27\n9\n590\nOctober 31, 2024"}
{"url":"https://docs.anza.xyz/consensus/stake-delegation-and-rewards","domain":"docs.anza.xyz","title":"Stake Delegation and Rewards | Agave","hash":"10c0066ae1fac951ca4d14b4368b7c82fe848107bf21337054df7e570944e721","tokens":3667,"chars":14667,"crawler":"crawler-f6nn","verified":"exact","ts":1791172314044,"text":"Skip to main content\nStake Delegation and Rewards\nStakers are rewarded for helping to validate the ledger. They do this by\ndelegating their stake to validator nodes. Those validators do the legwork of\nreplaying the ledger and sending votes to a per-node vote account to which\nstakers can delegate their stakes. The rest of the cluster uses those\nstake-weighted votes to select a block when forks arise. Both the validator and\nstaker need some economic incentive to play their part. The validator needs to\nbe compensated for its hardware and the staker needs to be compensated for the\nrisk of getting its stake slashed. The economics are covered in\nstaking rewards . This section, on\nthe other hand, describes the underlying mechanics of its implementation.\nBasic Design\nThe general idea is that the validator owns a Vote account. The Vote account\ntracks validator votes, counts validator generated credits, and provides any\nadditional validator specific state. The Vote account is not aware of any stakes\ndelegated to it and has no staking weight.\nA separate Stake account (created by a staker) names a Vote account to which\nthe stake is delegated. Rewards generated are proportional to the amount of\nlamports staked. The Stake account is owned by the staker only. Some portion of\nthe lamports stored in this account are the stake.\nPassive Delegation\nAny number of Stake accounts can delegate to a single Vote account without an\ninteractive action from the identity controlling the Vote account or submitting\nvotes to the account.\nThe total stake allocated to a Vote account can be calculated by the sum of all\nthe Stake accounts that have the Vote account pubkey as the\nStakeStateV2::Stake::voter_pubkey .\nVote and Stake accounts\nThe rewards process is split into two on-chain programs. The Vote program solves\nthe problem of making stakes slashable. The Stake program acts as custodian of\nthe rewards pool and provides for passive delegation. The Stake program is\nresponsible for paying rewards to staker and voter when shown that a staker's\ndelegate has participated in validating the ledger.\nVoteState\nVoteState is the current state of all the votes the validator has submitted to\nthe network. VoteState contains the following state information:\n- votes - The submitted votes data structure.\n- credits - The total number of rewards this Vote program has generated over\nits lifetime.\n- root_slot - The last slot to reach the full lockout commitment necessary for\nrewards.\n- commission - The commission taken by this VoteState for any rewards claimed\nby staker's Stake accounts. This is the percentage ceiling of the reward.\n- Account::lamports - The accumulated lamports from the commission. These do not\ncount as stakes.\n- authorized_voter - Only this identity is authorized to submit votes. This\nfield can only modified by this identity.\n- node_pubkey - The Solana node that votes in this account.\n- authorized_withdrawer - the identity of the entity in charge of the lamports\nof this account, separate from the account's address and the authorized vote\nsigner.\nVoteInstruction::Initialize(VoteInit)\n-\naccount[0] - RW - The VoteState.\nVoteInit carries the new vote account's node_pubkey , authorized_voter ,\nauthorized_withdrawer , and commission .\nother VoteState members defaulted.\nVoteInstruction::Authorize(Pubkey, VoteAuthorize)\nUpdates the account with a new authorized voter or withdrawer, according to the\nVoteAuthorize parameter ( Voter or Withdrawer ). The transaction must be\nsigned by the Vote account's current authorized_voter or\nauthorized_withdrawer .\n- account[0] - RW - The VoteState. VoteState::authorized_voter or\nauthorized_withdrawer is set to Pubkey .\nVoteInstruction::AuthorizeWithSeed(VoteAuthorizeWithSeedArgs)\nUpdates the account with a new authorized voter or withdrawer, according to the\nVoteAuthorize parameter ( Voter or Withdrawer ). Unlike\nVoteInstruction::Authorize this instruction is for use when the Vote account's\ncurrent authorized_voter or authorized_withdrawer is a derived key. The\ntransaction must be signed by someone who can sign for the base key of that\nderived key.\n- account[0] - RW - The VoteState. VoteState::authorized_voter or\nauthorized_withdrawer is set to Pubkey .\nVoteInstruction::Vote(Vote)\n- account[0] - RW - The VoteState. VoteState::lockouts and\nVoteState::credits are updated according to voting lockout rules see\nTower BFT .\n- account[1] - RO - sysvar::slot_hashes A list of some N most recent slots\nand their hashes for the vote to be verified against.\n- account[2] - RO - sysvar::clock The current network time, expressed in\nslots, epochs.\nStakeStateV2\nA StakeStateV2 takes one of four forms, StakeStateV2::Uninitialized,\nStakeStateV2::Initialized, StakeStateV2::Stake, and StakeStateV2::RewardsPool.\nOnly the first three forms are used in staking, but only StakeStateV2::Stake is\ninteresting. All RewardsPools are created at genesis.\nStakeStateV2::Stake\nStakeStateV2::Stake is the current delegation preference of the staker and\ncontains the following state information:\n- Account::lamports - The lamports available for staking.\n- stake - the staked amount (subject to warmup and cooldown) for generating\nrewards, always less than or equal to Account::lamports.\n- voter_pubkey - The pubkey of the VoteState instance the lamports are\ndelegated to.\n- credits_observed - The total credits claimed over the lifetime of the\nprogram.\n- activated - the epoch at which this stake was activated/delegated. The full\nstake will be counted after warmup.\n- deactivated - the epoch at which this stake was de-activated, some cooldown\nepochs are required before the account is fully deactivated, and the stake\navailable for withdrawal.\n- authorized_staker - the pubkey of the entity that must sign delegation,\nactivation, and deactivation transactions.\n- authorized_withdrawer - the identity of the entity in charge of the lamports\nof this account, separate from the account's address, and the authorized\nstaker.\nStakeStateV2::RewardsPool\nTo avoid a single network-wide lock or contention in redemption, 256\nRewardsPools are part of genesis under pre-determined keys, each with\nstd::u64::MAX credits to be able to satisfy redemptions according to point\nvalue.\nThe Stakes and the RewardsPool are accounts that are owned by the same Stake\nprogram.\nStakeInstruction::DelegateStake\nThe Stake account is moved from Initialized to StakeStateV2::Stake form, or from\na deactivated (i.e. fully cooled-down) StakeStateV2::Stake to activated\nStakeStateV2::Stake. This is how stakers choose the vote account and validator\nnode to which their stake account lamports are delegated. The transaction must\nbe signed by the stake's authorized_staker .\n- account[0] - RW - The StakeStateV2::Stake instance.\nStakeStateV2::Stake::credits_observed is initialized to\nVoteState::credits , StakeStateV2::Stake::voter_pubkey is initialized to\naccount[1] . If this is the initial delegation of stake,\nStakeStateV2::Stake::stake is initialized to the account's balance in\nlamports, StakeStateV2::Stake::activated is initialized to the current Bank\nepoch, and StakeStateV2::Stake::deactivated is initialized to std::u64::MAX\n- account[1] - R - The VoteState instance.\n- account[2] - R - sysvar::clock account, carries information about current\nBank epoch.\n- account[3] - R - sysvar::stakehistory account, carries information about\nstake history.\n- account[4] - R - stake::Config account, carries warmup, cooldown, and\nslashing configuration.\nStakeInstruction::Authorize(Pubkey, StakeAuthorize)\nUpdates the account with a new authorized staker or withdrawer, according to the\nStakeAuthorize parameter ( Staker or Withdrawer ). The transaction must be\nby signed by the Stakee account's current authorized_staker or\nauthorized_withdrawer . Any stake lock-up must have expired, or the lock-up\ncustodian must also sign the transaction.\n-\naccount[0] - RW - The StakeStateV2.\nStakeStateV2::authorized_staker or authorized_withdrawer is set to\nPubkey .\nStakeInstruction::Deactivate\nA staker may wish to withdraw from the network. To do so he must first\ndeactivate his stake, and wait for cooldown. The transaction must be signed by\nthe stake's authorized_staker .\n- account[0] - RW - The StakeStateV2::Stake instance that is deactivating.\n- account[1] - R - sysvar::clock account from the Bank that carries current\nepoch.\nStakeStateV2::Stake::deactivated is set to the current epoch + cooldown. The\naccount's stake will ramp down to zero by that epoch, and Account::lamports will\nbe available for withdrawal.\nStakeInstruction::Withdraw(u64)\nLamports build up over time in a Stake account and any excess over activated\nstake can be withdrawn. The transaction must be signed by the stake's\nauthorized_withdrawer .\n- account[0] - RW - The StakeStateV2::Stake from which to withdraw.\n- account[1] - RW - Account that should be credited with the withdrawn\nlamports.\n- account[2] - R - sysvar::clock account from the Bank that carries current\nepoch, to calculate stake.\n- account[3] - R - sysvar::stake_history account from the Bank that carries\nstake warmup/cooldown history.\nBenefits of the design\n- Single vote for all the stakers.\n- Clearing of the credit variable is not necessary for claiming rewards.\n- Each delegated stake can claim its rewards independently.\n- Commission for the work is deposited when a reward is claimed by the delegated\nstake.\nExample Callflow\nStaking Rewards\nThe specific mechanics and rules of the validator rewards regime is outlined\nhere. Rewards are earned by delegating stake to a validator that is voting\ncorrectly. Voting incorrectly exposes that validator's stakes to\nslashing .\nBasics\nThe network pays rewards from a portion of network\ninflation . The number of\nlamports available to pay rewards for an epoch is fixed and must be evenly\ndivided among all staked nodes according to their relative stake weight and\nparticipation. The weighting unit is called a\npoint .\nRewards for an epoch are not available until the end of that epoch.\nAt the end of each epoch, the total number of points earned during the epoch is\nsummed and used to divide the rewards portion of epoch inflation to arrive at a\npoint value. This value is recorded in the bank in a\nsysvar that maps epochs to point\nvalues.\nDuring redemption, the stake program counts the points earned by the stake for\neach epoch, multiplies that by the epoch's point value, and transfers lamports\nin that amount from a rewards account into the stake and vote accounts according\nto the vote account's commission setting.\nEconomics\nPoint value for an epoch depends on aggregate network participation. If\nparticipation in an epoch drops off, point values are higher for those that do\nparticipate.\nEarning credits\nValidators earn one vote credit for every correct vote that exceeds maximum\nlockout, i.e. every time the validator's vote account retires a slot from its\nlockout list, making that vote a root for the node.\nStakers who have delegated to that validator earn points in proportion to their\nstake. Points earned is the product of vote credits and stake.\nStake warmup, cooldown, withdrawal\nStakes, once delegated, do not become effective immediately. They must first\npass through a warmup period. During this period some portion of the stake is\nconsidered \"effective\", the rest is considered \"activating\". Changes occur on\nepoch boundaries.\nThe stake program limits the rate of change to total network stake, reflected in\nthe stake program's config::warmup_rate (set to 25% per epoch in the current\nimplementation).\nThe amount of stake that can be warmed up each epoch is a function of the\nprevious epoch's total effective stake, total activating stake, and the stake\nprogram's configured warmup rate.\nCooldown works the same way. Once a stake is deactivated, some part of it is\nconsidered \"effective\", and also \"deactivating\". As the stake cools down, it\ncontinues to earn rewards and be exposed to slashing, but it also becomes\navailable for withdrawal.\nBootstrap stakes are not subject to warmup.\nRewards are paid against the \"effective\" portion of the stake for that epoch.\nWarmup example\nConsider the situation of a single stake of 1,000 activated at epoch N, with\nnetwork warmup rate of 20%, and a quiescent total network stake at epoch N of\n2,000.\nAt epoch N+1, the amount available to be activated for the network is 400 (20%\nof 2000), and at epoch N, this example stake is the only stake activating, and\nso is entitled to all of the warmup room available.\nepoch effective activating total effective total activating\nN-1 2,000 0\nN 0 1,000 2,000 1,000\nN+1 400 600 2,400 600\nN+2 880 120 2,880 120\nN+3 1000 0 3,000 0\nWere 2 stakes (X and Y) to activate at epoch N, they would be awarded a\nportion of the 20% in proportion to their stakes. At each epoch effective and\nactivating for each stake is a function of the previous epoch's state.\nepoch X eff X act Y eff Y act total effective total activating\nN-1 2,000 0\nN 0 1,000 0 200 2,000 1,200\nN+1 333 667 67 133 2,400 800\nN+2 733 267 146 54 2,880 321\nN+3 1000 0 200 0 3,200 0\nWithdrawal\nOnly lamports in excess of effective+activating stake may be withdrawn at any\ntime. This means that during warmup, effectively no stake can be withdrawn.\nDuring cooldown, any tokens in excess of effective stake may be withdrawn\n(activating == 0). Because earned rewards are automatically added to stake,\nwithdrawal is generally only possible after deactivation.\nLock-up\nStake accounts support the notion of lock-up, wherein the stake account balance\nis unavailable for withdrawal until a specified time. Lock-up is specified as an\nepoch height, i.e. the minimum epoch height that must be reached by the network\nbefore the stake account balance is available for withdrawal, unless the\ntransaction is also signed by a specified custodian. This information is\ngathered when the stake account is created, and stored in the Lockup field of\nthe stake account's state. Changing the authorized staker or withdrawer is also\nsubject to lock-up, as such an operation is effectively a transfer.\n- Basic Design\n- Passive Delegation\n- Vote and Stake accounts\n- VoteState\n- VoteInstruction::Initialize(VoteInit)\n- VoteInstruction::Authorize(Pubkey, VoteAuthorize)\n- VoteInstruction::AuthorizeWithSeed(VoteAuthorizeWithSeedArgs)\n- VoteInstruction::Vote(Vote)\n- StakeStateV2\n- StakeStateV2::Stake\n- StakeStateV2::RewardsPool\n- StakeInstruction::DelegateStake\n- StakeInstruction::Authorize(Pubkey, StakeAuthorize)\n- StakeInstruction::Deactivate\n- StakeInstruction::Withdraw(u64)\n- Benefits of the design\n- Example Callflow\n- Staking Rewards\n- Basics\n- Economics\n- Earning credits\n- Stake warmup, cooldown, withdrawal\n- Withdrawal\n- Lock-up"}
{"url":"https://docs.meteora.ag/get-started/pushing-the-boundaries-of-defi","domain":"docs.meteora.ag","title":"Pushing the Boundaries of DeFi - Meteora Documentation","hash":"0e5ff7b3df7e5eb5135a0f3bb799e0831387e12305c59cb8c1e8229c6046c7c7","tokens":429,"chars":1713,"crawler":"crawler-f6nn","verified":"exact","ts":1791172316359,"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\nPushing the Boundaries of DeFi\nExplore the innovative DeFi programs Meteora is building on Solana, including DLMM, DAMM, DBC, and more.\nWe write innovative programs that push the boundaries of DeFi on Solana.\nConcentrated Market Making, Dynamic AMMs, Launch Curves, Vault Yield, Fee Sharing, and many more - each product solves a specific market-design problem so builders , protocols , liquidity providers , and traders can go live onchain with the best capital efficiency.\nActive Programs\nActive\n= will have new developments and still actively maintained\nProgram Program ID Open Source\nDLMM LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo ❌\nDAMM v2 cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG ✅\nDBC dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN ✅\nPresale Vault presSVxnf9UU8jMxhgSMqaRwNiT36qeBdNeTRKjTdbj ✅\nAlpha Vault vaU6kP7iNEGkbmPkLmZfGwiGxd4Mob24QQCie5R9kd2 ❌\nDynamic Fee Sharing dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh ✅\nZap zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz ✅\nLegacy Programs\nLegacy\n= will not have new developments but still maintained\nProgram Program ID Open Source\nDAMM v1 Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB ❌\nDynamic Vault 24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi ❌\nStake2Earn FEESngU3neckdwib9X3KWqdL7Mjmqk9XNp3uh5JbP4KP ❌\nFarm FarmuwXPWXvefWUeqFAa5w6rifLkq5X6E8bimYvrhCB1 ❌\nMercurial Stable Swap MERLuDFBMmsHnsBPZw2sDQZHvXFMwp8EdjudcU2HKky ❌\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.getmonero.org/infrastructure/monero-pulse/","domain":"docs.getmonero.org","title":"MoneroPulse - Monero Docs","hash":"eb9c939d43e271401f749315e965aaa1cb064c6bd8f287afe8cd85872d5c0204","tokens":1602,"chars":6405,"crawler":"crawler-f6nn","verified":"exact","ts":1791172319178,"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- Fixing \"WARNING: no two valid MoneroPulse DNS checkpoint records were received\"\n- Reference\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- Fixing \"WARNING: no two valid MoneroPulse DNS checkpoint records were received\"\n- Reference\nMoneroPulse ¶\nWhat is MoneroPulse? ¶\nMoneroPulse is infrastructure for emergency checkpointing the blockchain.\nIt aims to mitigate chain-splits resulting from consensus bugs (like this one from 2014 ).\nEffectively, MoneroPulse operators can publish which fork they consider the valid one. Technically, the \"checkpoint\" they publish is a block hash and the block height.\nBy default, Monero full node will simply warn users when MoneroPulse checkpoint does not match the fork it is on. The error will be present in the log and on the console in red. Users are free to discard it. Ideally though, users should consult community on what is going on, and make educated decision on whether to follow the checkpoint-compatible fork or the default fork.\nUsers can also set auto-enforcing the checkpoints via --enforce-dns-checkpointing option to monerod . In case of mismatch, monerod will rollback the local blockchain by a few blocks. Eventually, the alternative (\"fixed\") fork will get heavier and the node will follow it, leaving the \"invalid\" fork behind. This option is recommended for unattended full nodes.\nSumming up, MoneroPulse is emergency checkpointing mechanism. It is opt-in for the users.\nMoneroPulse is DNS based ¶\nThe checkpoints are stored as DNS TXT records for domains owned by MoneroPulse operators.\nTo get the idea you can access the checkpoints manually with any DNS client:\nTry:\ndig -t txt checkpoints.moneropulse.net +dnssec\nResult:\n(cut)\n;; ANSWER SECTION:\ncheckpoints.moneropulse.net. 299 IN TXT \"1288616:875ac1bc7aa6c5eedc5410abb9c694034f9e7f79dce4c60698baf37009cb6365\"\ncheckpoints.moneropulse.net. 299 IN TXT \"375000:c80c23e387585e12ffb6649d678e9ba328181797b9583a6d8911b77e25375737\"\ncheckpoints.moneropulse.net. 299 IN TXT \"325000:4260d56368267bc2a70dd58d73c5ecf23b4e4d96e63c29a868e4a679b0741c7f\"\ncheckpoints.moneropulse.net. 299 IN TXT \"233000:4f69bec2af6c0852412bdd10c19e6af10c8d738fe2618b5511a98efd03ab477e\"\ncheckpoints.moneropulse.net. 299 IN TXT \"450000:4d098b511ca97723e81737c448343cfd4e6dadb3d8a0e757c6e4d595e6e48357\"\ncheckpoints.moneropulse.net. 299 IN TXT \"250000:f59d31839bd909ec8830b4f7f66ff213f0bd006334c8523daee452725e5c7a79\"\ncheckpoints.moneropulse.net. 299 IN TXT \"550000:c2e80a636438bd9f7a7ab432a6ad297e35540d80ff5b868bca098124cad2ff8c\"\ncheckpoints.moneropulse.net. 299 IN TXT \"650000:1d567f2b491324375a825895c5e7b52857b38e4fed0e42c40909c2d52240b4e0\"\ncheckpoints.moneropulse.net. 299 IN TXT \"800000:2ced10aa85357ab6c14bb12b6b56d1dde28940820dda30911b73a5cc9a301760\"\ncheckpoints.moneropulse.net. 299 IN TXT \"850000:00e2b557dde9fd4a9e2e3dd7ddac962f5ca475eb1095bc50aa757fd1218ab0a5\"\ncheckpoints.moneropulse.net. 299 IN TXT \"900000:d9958d0e7dcf91a5a7b11de225927bf7efc6eb26240315ce12372be902cc1337\"\ncheckpoints.moneropulse.net. 299 IN TXT \"913193:5292d5d56f6ba4de33a58d9a34d263e2cb3c6fee0aed2286fd4ac7f36d53c85f\"\ncheckpoints.moneropulse.net. 299 IN TXT \"913269:f8302e6b8ba1c49aad9a854b8d6c79d8272c6239dcbba5a75ed0784c1d4f56a1\"\ncheckpoints.moneropulse.net. 299 IN TXT \"350000:74da79f6a136969abd6364bd3d37af273c408d6471e8ab598e80569b42415f86\"\ncheckpoints.moneropulse.net. 299 IN TXT \"400000:1b2b0e7a30e59691491529a3d506d1ba3d6052d0f6b52198b7330b28a6f1b6ac\"\ncheckpoints.moneropulse.net. 299 IN TXT \"500000:2428f0dbe49796be05ed81b347f53e1f7f44aed0abf641446ec2b94cae066b02\"\ncheckpoints.moneropulse.net. 299 IN TXT \"600000:f5828ebf7d7d1cb61762c4dfe3ccf4ecab2e1aad23e8113668d981713b7a54c5\"\ncheckpoints.moneropulse.net. 299 IN TXT \"700000:12be9b3d210b93f574d2526abb9c1ab2a881b479131fd0d4f7dac93875f503cd\"\ncheckpoints.moneropulse.net. 299 IN TXT \"300000:0c1cd46df6ccff90ec4ab493281f2583c344cd62216c427628990fe9db1bb8b6\"\ncheckpoints.moneropulse.net. 299 IN RRSIG TXT 13 3 300 20180922151845 20180920131845 35273 moneropulse.net. 8CyqtsM2f9o6OHZYqtGPVf+8gcFM+eUyoMi29LlkcLtK1AXbZlKqCcdN NvdvB+4OzepmpTanSc+TbLWbz/sIzA==\nPlease note the DNSSEC signature entry at the end.\nThe checkpoints are mirrored on several DNS servers:\nMainnet:\ncheckpoints.moneropulse.se\ncheckpoints.moneropulse.org\ncheckpoints.moneropulse.net\ncheckpoints.moneropulse.co\nStagenet:\nstagenetpoints.moneropulse.se\nstagenetpoints.moneropulse.org\nstagenetpoints.moneropulse.net\nstagenetpoints.moneropulse.co\nTestnet:\ntestpoints.moneropulse.se\ntestpoints.moneropulse.org\ntestpoints.moneropulse.net\ntestpoints.moneropulse.co\nMoneroPulse as attack vector ¶\nIt is worth noting that MoneroPulse does not produce blocks and cannot split the chain on its own. It only suggests the valid fork.\nShould MoneroPulse got entirely compromised, attacker could stop all auto-enforcing nodes from advancing, by feeding them with the fake checkpoint. This is partially mitigated by DNSSEC and by operating multiple domains. Monero expects checkpoints are consistent across domains. Thus, compromising a single domain or registrar should not lead to any disruption.\nMoneroPulse also increases the say of its operators in case of possible contentious hard forks. While well intended, this effectively centralizes more power in hands of core developers, or whomever is at the time running MoneroPulse infrastructure.\nWho are MoneroPulse operators? ¶\nMoneroPulse is operated by selected core developers.\nFixing \"WARNING: no two valid MoneroPulse DNS checkpoint records were received\" ¶\nThis means that the DNS server you're using doesn't acknowledge the +dnssec flag which is necessary to securely query for checkpoints.\nBy default, your operating system will use DNS server provided by your Internet Service Provider.\nTo fix this warning, change your DNS server to one that supports DNSSEC.\nChanges can be made either system-wide in your network configuration, or specifically for your monerod instance.\nExample Using Google DNS for monerod:\nDNS_PUBLIC=tcp://8.8.8.8 ./monerod\nExample Using Cloudflare DNS for monerod:\nDNS_PUBLIC=tcp://1.1.1.1 ./monerod\nReference ¶\n- StackExchange answer\n- Reddit answer\n- Monero source code"}
{"url":"https://docs.ens.domains/web/siwe","domain":"docs.ens.domains","title":"Sign In With Ethereum (SIWE) | ENS Docs","hash":"e293720b19bc5b74ffea73f5113f76211d2700efd47dd25af7dcc68e20ab852b","tokens":190,"chars":757,"crawler":"crawler-f6nn","verified":"exact","ts":1791172321366,"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\nSign In With Ethereum (SIWE)\nA specification that leverages Ethereum signatures to perform authentication\nERC-4361 defines a message format that a user signs using their keys to authenticate.\nAn example payload looks like the following:\nlocalhost wants you to sign in with your Ethereum account:\n0x225f137127d9067788314bc7fcc1f36746a3c3B5\nThis is a test statement.\nURI: https://localhost/login\nVersion: 1\nChain ID: 1\nNonce: abcdef1234567890\nIssued At: 2023-01-30T00:00:00.000Z\nAfter authentication, an app may resolve the user's ENS name and profile, as well as other onchain resources .\nResources\n- ERC-4361\n- Project website\n- Docs\n- Libraries"}
{"url":"https://gov.uniswap.org/guidelines","domain":"gov.uniswap.org","title":"Guidelines - Uniswap Governance","hash":"81d9c485184c4b47f98e633509d10b480b71972e43c1cd31487185c20aeb1c90","tokens":1275,"chars":5099,"crawler":"crawler-f6nn","verified":"exact","ts":1791172323490,"text":"Uniswap Governance\n- About\n- Guidelines\n- Terms of Service\n- Privacy\nThis is a Civilized Place for Public Discussion\nPlease treat this discussion forum with the same respect you would a public park. We, too, are a shared community resource — a place to share skills, knowledge and interests through ongoing conversation.\nThese are not hard and fast rules, merely guidelines to aid the human judgment of our community and keep this a clean and well-lighted place for civilized public discourse.\nImprove the Discussion\nHelp us make this a great place for discussion by always working to improve the discussion in some way, however small. If you are not sure your post adds to the conversation, think over what you want to say and try again later.\nThe topics discussed here matter to us, and we want you to act as if they matter to you, too. Be respectful of the topics and the people discussing them, even if you disagree with some of what is being said.\nOne way to improve the discussion is by discovering ones that are already happening. Spend time browsing the topics here before replying or starting your own, and you’ll have a better chance of meeting others who share your interests.\nBe Agreeable, Even When You Disagree\nYou may wish to respond to something by disagreeing with it. That’s fine. But remember to criticize ideas, not people . Please avoid:\n- Name-calling\n- Ad hominem attacks\n- Responding to a post’s tone instead of its actual content\n- Knee-jerk contradiction\nInstead, provide reasoned counter-arguments that improve the conversation.\nYour Participation Counts\nThe conversations we have here set the tone for every new arrival. Help us influence the future of this community by choosing to engage in discussions that make this forum an interesting place to be — and avoiding those that do not.\nDiscourse provides tools that enable the community to collectively identify the best (and worst) contributions: bookmarks, likes, flags, replies, edits, and so forth. Use these tools to improve your own experience, and everyone else’s, too.\nLet’s leave our community better than we found it.\nIf You See a Problem, Flag It\nModerators have special authority; they are responsible for this forum. But so are you. With your help, moderators can be community facilitators, not just janitors or police.\nWhen you see bad behavior, don’t reply. It encourages the bad behavior by acknowledging it, consumes your energy, and wastes everyone’s time. Just flag it . If enough flags accrue, action will be taken, either automatically or by moderator intervention.\nIn order to maintain our community, moderators reserve the right to remove any content and any user account for any reason at any time. Moderators do not preview new posts; the moderators and site operators take no responsibility for any content posted by the community.\nAlways Be Civil\nNothing sabotages a healthy conversation like rudeness:\n- Be civil. Don’t post anything that a reasonable person would consider offensive, abusive, or hate speech.\n- Keep it clean. Don’t post anything obscene or sexually explicit.\n- Respect each other. Don’t harass or grief anyone, impersonate people, or expose their private information.\n- Respect our forum. Don’t post spam or otherwise vandalize the forum.\nThese are not concrete terms with precise definitions — avoid even the appearance of any of these things. If you’re unsure, ask yourself how you would feel if your post was featured on the front page of the New York Times.\nThis is a public forum, and search engines index these discussions. Keep the language, links, and images safe for family and friends.\nKeep It Tidy\nMake the effort to put things in the right place, so that we can spend more time discussing and less cleaning up. So:\n- Don’t start a topic in the wrong category.\n- Don’t cross-post the same thing in multiple topics.\n- Don’t post no-content replies.\n- Don’t divert a topic by changing it midstream.\n- Don’t sign your posts — every post has your profile information attached to it.\nRather than posting “+1” or “Agreed”, use the Like button. Rather than taking an existing topic in a radically different direction, use Reply as a Linked Topic.\nPost Only Your Own Stuff\nYou may not post anything digital that belongs to someone else without permission. You may not post descriptions of, links to, or methods for stealing someone’s intellectual property (software, video, audio, images), or for breaking any other law.\nPowered by You\nThis site is operated by your friendly local staff and you , the community. If you have any further questions about how things should work here, open a new topic in the site feedback category and let’s discuss! If there’s a critical or urgent issue that can’t be handled by a meta topic or flag, contact us via the staff page .\nTerms of Service\nYes, legalese is boring, but we must protect ourselves – and by extension, you and your data – against unfriendly folks. We have a Terms of Service describing your (and our) behavior and rights related to content, privacy, and laws. To use this service, you must agree to abide by our TOS ."}
{"url":"https://docs.jup.ag/user-docs/launch/lock","domain":"docs.jup.ag","title":"Jupiter Lock Overview - Jupiter Documentation","hash":"a9c1ba30cc8309beb0c1a1ad8fdc01308a52a3dee95d01c7451230362014c665","tokens":555,"chars":2219,"crawler":"crawler-f6nn","verified":"exact","ts":1791172326116,"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\nJupiter Lock\nJupiter Lock Overview\nA free token locking and vesting tool on Solana.\nJupiter Lock is a token locking tool on Solana that allows anyone to create onchain escrows with vesting schedules. It is designed for token creators, project teams, and DAOs that need to lock tokens with transparent, verifiable unlock conditions.\nLocked tokens are held in an onchain escrow account. They cannot be moved or accessed until the conditions defined at creation are met.\nNo Fees\nJupiter Lock has no protocol fees. Only standard Solana network fees apply.\nFlexible Vesting\nCliff + linear vesting schedules, with configurable cancel and recipient-change permissions.\nAudited\nAudited by OtterSec and Sec3. Read the OtterSec and Sec3 reports.\nMultisig Support\nLock creation is compatible with multisig wallets.\nWhat You Can Do with Jupiter Lock\n- Lock tokens until a specific date. Tokens remain in escrow and are released based on the vesting schedule defined at creation.\n- Define vesting schedules. Each lock supports a cliff + linear vesting model: an initial amount unlocks at the cliff date, and the remainder vests gradually over time.\n- Control permissions. At creation, the lock creator decides who can cancel the lock and who can change the recipient (creator, recipient, both, or none).\nWho Uses Jupiter Lock\n- Project teams locking team allocations, ecosystem reserves, or investor tokens.\n- DAOs enforcing onchain vesting for contributors or treasury management.\n- Any wallet holder who wants to lock tokens with a verifiable schedule.\nJupiter Lock is a standalone tool with no dependency on other Jupiter products. It is also used by Jupiter DTF to lock non-sale token allocations during token launches.\nJupiter Lock is a public good maintained by the Jupiter team.\nNext Steps\nHow It Works\nFull breakdown of vesting mechanics, lock parameters, permissions, and onchain behavior.\nFAQ\nQuick answers to the most common questions about Jupiter Lock.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://discuss.ens.domains/c/ens-ecosystem/community/73","domain":"discuss.ens.domains","title":"Latest Community topics - ENS DAO Governance Forum","hash":"5f433480670fe90b5495697cb73455b3ea030cd5c0c49601ea551f8673ca4305","tokens":614,"chars":2455,"crawler":"crawler-f6nn","verified":"exact","ts":1791172328137,"text":"ENS DAO Governance Forum\n🌱 ENS Ecosystem\nCommunity\nTopic\nReplies\nViews\nActivity\nAbout the Community category\n0\n220\nJanuary 4, 2023\nProposal & Core Contribution] Resolving 2300 Gas Reverts for Smart Contract Wallets (ERC-4337 & Safe) in ENS Controller — PR #577\n1\n32\nOctober 4, 2026\nENS Advisor: buy an expiring .eth name at your budget without handing anyone your ETH, plus a weekly .eth sales report\n0\n32\nOctober 1, 2026\nETH, Ethiopia, Ethereum: Liminal Namespaces & .eth Legitimacy\n0\n86\nJuly 1, 2026\nContributor Report: estmcmxci.eth\n2\n188\nMay 7, 2026\nENS Research: Namechain, ENSIP-19 & Multichain Interop\nresearch\n10\n574\nDecember 4, 2025\nENSIP-X: Metadata Standards and Contract Naming Convention\n2\n124\nOctober 16, 2025\nENS @ Real World Ethereum Hackathon – ETH Latam 2025 São Paulo\ngrants\n6\n229\nOctober 9, 2025\nNamechain L2 and ENS burning / re-claiming burn address owned names\n12\n408\nSeptember 4, 2025\nIntroducing the ENS MCP Server: Bringing ENS to Claude and other AI Assistants\n0\n237\nMarch 11, 2025\n[Feedback Request] x23.ai - applying LLMs to web3 data\n10\n1050\nFebruary 12, 2025\n[Feedback Request] JustaName Intros\n2\n228\nJanuary 19, 2025\nJustaName XMTP AI Agent and Launchpad Announcement\n0\n105\nJanuary 16, 2025\nENS DAO revenue, profit, treasury, etc\n2\n174\nSeptember 14, 2024\nSuggestion: Submit .ens TLD application to ICANN\n3\n1475\nAugust 12, 2024\nCollabTech Hackathon Sponsorship Proposal\nhackathons\n0\n358\nJuly 17, 2024\nProposal to Move ENS from Discord to Console\n1\n482\nJuly 4, 2024\nResults of Latina Blockchain Hackathon by Womenbiz\npublic-goods\n1\n693\nMay 28, 2024\n[RFP] ENS \"School Nights\"\n1\n1519\nMarch 15, 2024\nVisualizing the Manifold Finance Discussion\n0\n828\nMarch 2, 2024\nRequest for feedback: Grants Pathfinder, a guide to web3 grants\n0\n935\nFebruary 15, 2024\nThe State of ENS Governance\n4\n1401\nJanuary 9, 2024\nEthereum Name Advertising Network (ENAN)\n2\n1124\nJanuary 9, 2024\nProposal: Renewal module for ENS\n13\n1666\nDecember 28, 2023\nIs there a primary ENS name of a contract can be displayed on etherscan?\n9\n2406\nNovember 26, 2023\nENS on Swarm decentralized storage\nsubdomains\n11\n4326\nNovember 16, 2023\nENS Marketing Research Pilot Episode: ENS Econometrics\n22\n3169\nOctober 24, 2023\nProposal - What option will bots prefer? - need help\n16\n1814\nOctober 17, 2023\n1W3 ENS Buildathon Competition: Build, Win, and Transform the Decentralized Web!\n3\n1513\nOctober 11, 2023\nIncrease Use Case For ENS Domains\n6\n1336\nOctober 3, 2023\nnext page →"}
{"url":"https://docs.filecoin.io/build-on-filecoin/developing-contracts/get-test-tokens","domain":"docs.filecoin.io","title":"Get test tokens | Filecoin Docs","hash":"3d6b7679e0d1169031f4c5951cbcbb188fc2b11e60a0016a7f6f16c2e1e9b7fc","tokens":647,"chars":2585,"crawler":"crawler-f6nn","verified":"exact","ts":1791172331095,"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 .\nGet test tokens\nTest funds are available to developers so that they can test their smart contracts and applications within the confines of a test network. This page covers how to get test funds.\nCalibration testnet\nMetaMask is one of the easier ways to manage addresses on the Calibration testnet. MetaMask displays Filecoin EVM accounts in Ethereum 0x format; on Filecoin testnets those accounts map to delegated t4 addresses . Follow the MetaMask setup guide if you haven’t set up an address in your MetaMask wallet yet.\n-\nIn your browser, open MetaMask and copy your address to your clipboard.\n-\nGo to faucet.calibnet.chainsafe-fil.io and click Send Funds .\n-\nPaste your address into the address field and click Send funds :\nThe Calibration faucet website.\n-\nThe webpage will give you a transaction ID:\nA transaction ID returned by the Calibration faucet.\n-\nYou can copy this ID into a block explorer to track the progress of your transaction:\nA block explorer showing a pending transaction on the Calibration testnet.\nThat’s all there is to it! Getting tFIL is easy!\nLocal testnet\nBefore we begin, you must have a local testnet running. Follow the Run a local network guide if you haven’t got a local testnet set up yet. Run the commands below from the directory that contains your local lotus binary, and replace the placeholder addresses with addresses from your local node.\n-\nChange directory to where you created the lotus and lotus-miner binaries. If you followed the Run a local network guide these binaries will be in ~/lotus-devnet :\n-\nView the wallets available on this node with lotus wallet list :\n-\nCreate the send request with lotus send , supplying a funded local wallet as the --from address, the receiving address, and the amount of FIL you want to send:\nTo create a delegated address for local Filecoin EVM testing, run:\n-\nCheck the balance of your receiving address with lotus wallet balance :\nIf you want to manage your local testnet tokens in MetaMask, use a delegated address and connect MetaMask to your local testnet to see the new balance within the MetaMask extension.\nWas this page helpful?\nPrevious Developing contracts\nNext ERC-20 quickstart\nLast updated 3 months ago\n- Calibration testnet\n- Local testnet\ncd ~/lotus-devnet\n./lotus wallet list\n./lotus send --from \n./lotus wallet new delegated\n./lotus wallet balance "}
{"url":"https://wormhole.com/docs/products/token-transfers/wrapped-token-transfers/faqs/","domain":"wormhole.com","title":"Wrapped Token Transfers (WTT) FAQs | Wormhole Docs","hash":"8dcbb013318e871301b0b38a258d4251d7818e97a42d237281cf04930ecab5fe","tokens":647,"chars":2586,"crawler":"crawler-f6nn","verified":"exact","ts":1791172333383,"text":"Skip to content\nInitializing search\n- Configuration\n- Concepts\n- FAQs\n- Reference\n- Transceivers\n- Wrapped Token Transfers\n- Tutorials\n- Concepts\n- FAQs 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\nWrapped Token Transfers (WTT) FAQs ＃\nView page in Markdown Download page in Markdown Open in ChatGPT Open in Claude\nCan ownership of wrapped tokens be transferred from the WTT? ＃\nNo. Ownership of wrapped token contracts cannot be transferred, because WTT deploys and retains control of these contracts and tokens.\n- On EVM chains : When you attest a token, WTT deploys a new ERC-20 contract as a beacon proxy. The upgrade authority for these contracts is the WTT contract itself.\n- On Solana : The WTT deploys a new SPL token, where the upgrade authority is a Program Derived Address (PDA) controlled by the WTT contract.\nThe logic behind deploying these token contracts involves submitting an attestation VAA, which allows WTT to verify and deploy the wrapped token contract on the destination chain.\nRelevant contracts:\n- Ethereum ERC-20\n- Solana SPL\n- Attestation VAA and Token Contract Deployment Logic\nHow do I update the metadata of a wrapped token? ＃\nWrapped tokens are deployed and controlled by the WTT program under Guardian authority. You cannot update their metadata directly. Instead, you must coordinate with the respective block explorer teams to request and apply metadata changes.\nHow do I calculate the current gas costs for Ethereum Mainnet VAA verification? ＃\nYou can refer to the core-bridge repository for guidance on how to calculate the current gas costs associated with verifying VAAs on Ethereum Mainnet. This repository provides up-to-date references and examples to help you gauge costs accurately.\nHow can I update my wrapped token image on Solscan? ＃\nUpdating the metadata (such as the token image, name, or symbol) of a wrapped token on Solscan requires contacting the Solscan team directly. Wormhole cannot make these updates for you because the wrapped token contracts are owned and controlled by the WTT program, not individual developers or projects.\nTo request an update, contact Solscan via support@solscan.io or their contact form .\nLast update: September 28, 2026\n| Created: September 28, 2026"}
{"url":"https://www.metaplex.com/docs/dev-tools","domain":"www.metaplex.com","title":"Solana Dev Tools | CLI, SDKs & APIs for NFTs & Tokens | Metaplex","hash":"610d02b7ad3036685d0824fe4873f51f737cd37f91f15871597d41013dbfa2ef","tokens":139,"chars":553,"crawler":"crawler-f6nn","verified":"exact","ts":1791172335567,"text":"API\nTokens\nAgents\nNFTs\nSmart Contracts\nDev Tools\nSolana\nDev Support\nSolana Developer Tools\nDeveloper tools for building on Solana. CLI tools, TypeScript SDKs, APIs, and utilities for NFTs, tokens, and digital assets.\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"}
{"url":"https://www.helius.dev/docs/data-streaming","domain":"www.helius.dev","title":"Solana Data Streaming - Helius Docs","hash":"bec9e985e93f3afa6e624e577a56944078cbeed0e564852c19f042781291b926","tokens":2396,"chars":9584,"crawler":"crawler-f6nn","verified":"exact","ts":1791172338531,"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 Streaming & Event Listening\nSolana Data Streaming\nStream real-time Solana blocks, account updates, transaction data, and blockchain events. LaserStream gRPC, LaserStream WebSocket, Webhooks, and Shred Delivery solutions.\nWhat is data streaming on Solana?\nData streaming allows applications to receive real-time updates from the Solana blockchain as events occur on-chain. Instead of repeatedly polling for updates, streaming establishes persistent connections that push data to your application instantly when transactions are processed, accounts change, or blocks are produced.\nThis is essential for applications that require up-to-the-second data such as:\n- Trading applications monitoring price changes and liquidations\n- DeFi protocols tracking user interactions and state changes\n- NFT marketplaces detecting sales, listings, and transfers\n- Analytics platforms collecting comprehensive blockchain metrics\n- Wallets showing real-time balance and transaction updates\nBuilding a trading strategy? The Trading section brings\ntogether the latency-sensitive products — Preconfirmations , Shred\nDelivery , and Helius\nSender — in one place.\nWhy choose Helius for data streaming?\nUltra-Low Latency\nDirect connections to Solana leaders ensure sub-second data delivery\nEnterprise Reliability\nMulti-node redundancy and automatic failover for 99.9% uptime\n24-Hour Historical Replay\nNever miss data with automatic backfill capabilities\nGlobal Infrastructure\nEndpoints in multiple regions for optimal performance worldwide\nWhich streaming solution should I use?\nPick the product that matches what stage of the data you need and how your app wants to consume it . The table below maps each option to its delivery shape and the type of workloads it’s best suited to.\nSolution Best for Protocol Plan Replay\nPreconfirmations propAMMs, snipers, copy traders, liquidation bots — earliest transaction signal WebSocket Professional ❌\nShred Delivery (raw shreds) propAMMs, snipers, copy traders, liquidation bots, arbitrage — pre-execution data UDP All plans ( paid add-on ) ❌\nPreprocessed Transactions Decoded pre-execution transactions without running deshredding WebSocket All paid plans ❌\nLaserStream gRPC Mission-critical backends, indexers, multi-region failover gRPC Business+ (Mainnet), All plans (Devnet) ✅ 24h\nLaserStream WebSocket Web apps, real-time UIs, broad client compatibility WebSocket Free+ ❌\nWebhooks Server-to-server event notifications, low-volume integrations HTTP POST Free+ ❌\nNot sure which to pick? Most production apps start with LaserStream gRPC\nfor backends and LaserStream WebSocket for browser/UI clients.\nWebhooks are great when you don’t want to maintain a persistent\nconnection. Shred Delivery is purpose-built for sub-millisecond trading\nstrategies, and Preprocessed Transactions delivers the decoded\npre-execution transactions without deshredding. For the earliest transaction signal of all, Preconfirmations streams transactions before they’re shredded.\nPick by what you’re optimizing for\nThe shred-based products and LaserStream’s commitment levels sit at different points in the transaction lifecycle. What you’re trying to receive matters as much as the protocol:\nGoal Fastest path\nEarliest transaction signal Preconfirmations (before shreds) → Raw shreds (UDP) → Preprocessed transactions ( preprocessedSubscribe WebSocket ) (~8 ms ahead of processed ) → LaserStream gRPC at processed\nEarliest account / program updates LaserStream gRPC at processed — shreds and preprocessed transactions only carry transaction data, not account state. Account updates are produced by the runtime during execution, so they aren’t available until processing completes.\nEarliest confirmed transactions or accounts LaserStream gRPC at confirmed — fastest commitment level that won’t roll back\nCommon gotcha: if you need real-time account or program state changes (for\nexample, monitoring an AMM’s bonding-curve account or a user’s token balance),\nShred Delivery does not help — those updates simply don’t exist at the\nshred stage. Use LaserStream gRPC at processed instead.\nHelius Streaming Solutions\nPreconfirmations\nPreconfirmations stream transactions at the earliest point they can be observed — before they are collected into entries and shredded. Helius preconfirmations are emitted the instant the leader executes a transaction, together with its execution status; BAM preconfirmations are emitted when the validator commits to executing it. It is the lowest-latency transaction signal Helius offers, delivered over a preconfSubscribe WebSocket subscription. Available to any Professional plan or higher subscriber at 10 credits per message .\nBest For\nThe earliest possible reaction to onchain activity:\n- propAMMs\n- Snipers\n- Copy traders\n- Liquidation bots\nA preconfirmation is an early signal, not a guarantee — the transaction has\nnot yet landed and could still fail or be dropped.\nShred Delivery\nShred Delivery is Helius’s pre-execution data product: raw shreds (UDP) . Helius is a top validator by stake, so we receive shreds before lower-stake validators and non-staked RPC nodes. You implement the deshredding yourself. Available on all plans; each seat is $1,000/month per IP ($800/month per IP on Pro plans). Subscribe in your Helius Dashboard - no manual provisioning required.\nBest For\n- propAMMs\n- Snipers\n- Copy traders\n- Liquidation bots\n- Arbitrage\n- RPC node operators who want to remove network sync latency\nReady to receive raw shreds? Subscribe in your Helius\nDashboard . See pricing for details.\nPreprocessed Transactions\nPreprocessed transactions are pre-execution transactions, aggregated primarily from decoded shreds with the deshredding handled by Helius. Delivered over the preprocessedSubscribe WebSocket (Public Beta, all paid plans, 0.1 credits per message ).\nBest For\nLatency-sensitive trading applications that want decoded, pre-execution transactions without operating a shred decoder.\nLaserStream gRPC (All plans Devnet, Business+ Mainnet)\nLaserStream gRPC provides ultra low-latency data streaming via gRPC, with advanced features such as historical replay, automatic reconnects, and multi-node reliability. LaserStream is wire-compatible with the open Yellowstone gRPC protocol, so any Yellowstone client works.\nKey Features\n- Turnkey: Get faster gRPC streams without the headaches of managing hardware or upgrades\n- 48-Hour Historical Replay: Automatically backfill up to 48 hours of missed data\n- Auto-Reconnection: Built-in connection management with intelligent retry logic\n- Global Endpoints: Available in 9 regions worldwide for optimal latency\n- Yellowstone-Compatible: Drop-in replacement for existing @triton-one/yellowstone-grpc setups\nBest For\n- Backend services\n- High-throughput applications\n- Mission-critical systems requiring guaranteed data delivery\nGet started with LaserStream from your Helius Dashboard . Mainnet requires a Business plan or higher; Devnet is available on all paid plans. See our plans for details.\nLaserStream WebSocket\nLaserStream WebSocket is the WebSocket-protocol variant of LaserStream. It serves the standard Solana JSON-RPC subscription methods ( accountSubscribe , programSubscribe , logsSubscribe , …) alongside Helius-specific extensions like transactionSubscribe for advanced filtering, all on the same unified endpoint and powered by the same LaserStream backend as the gRPC product.\nKey Features\n- Full Solana compatibility: works with any Solana WebSocket client library\n- Helius extensions: transactionSubscribe and an enhanced accountSubscribe for richer filtering\n- Up to 200 ms faster than standard Agave RPC-based WebSockets\n- Unified endpoint: wss://mainnet.helius-rpc.com and wss://devnet.helius-rpc.com for both standard and Helius-extended methods\nBest For\nReal-time frontend apps, moderate-volume backends, broad ecosystem compatibility\nWebhooks\nEvent-driven, server-to-server webhook notifications for on-chain activities delivered to your endpoints.\nKey Features\n- Parsed Event Data: Human-readable transaction data for sales, swaps, and more\n- Multiple Types: Enhanced, raw, and Discord webhook options\n- Transaction Filtering: Subscribe to specific event types and addresses\n- Reliable Delivery: Automatic retries and delivery confirmations\nBest For\nEvent-driven architectures, notifications, integrations with external services\nGetting Started\n1\nChoose Your Solution\nSelect the streaming method that best fits your app requirements and infra.\n2\nGet Your API Key\nSign up at dashboard.helius.dev and obtain\nyour API key.\n3\nFollow the Quickstart\nEach solution has dedicated quickstart guides and code examples.\n4\nMonitor & Scale\nUse the Helius dashboard to monitor usage and scale your plan as needed.\nData Streaming Quickstart\nGet up and running with your first streaming connection in minutes\nSupport & Community\nDocumentation\nComprehensive API references and guides for all streaming methods\nDiscord Community\nJoin thousands of developers building on Solana with Helius\nEnterprise Support\nPriority support channels for business and professional customers\nReady to start streaming Solana data?\nChoose your preferred method above and dive into the documentation!\nWas this page helpful?\n⌘ I\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.cosmos.network/evm/latest/documentation/getting-started/network-operators/node-configuration","domain":"docs.cosmos.network","title":"Node Configuration - Cosmos Docs","hash":"7ca517eb42d6a4ea224f191ecceeec74d1763d681b30694ad39062ddb46f859e","tokens":7163,"chars":28650,"crawler":"crawler-f6nn","verified":"exact","ts":1791172341921,"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\nDocumentation\nAPI Reference\nChangelog\nAdditional Configuration\nNode Configuration\nComplete reference for configuring Cosmos EVM nodes, JSON-RPC settings, and command-line options\nConfigure EVM-specific settings in ~/.evmd/config/app.toml . This guide covers parameters unique to the EVM implementation.\n-\nEVM\n-\nMempool\n-\nJSON-RPC\n-\nRuntime Flags\n-\nApplication Config\n-\nGenesis Config\n-\nValidator Nodes\nEVM execution environment configuration.\nstring\ndefault: \"\"\nControls VM execution tracing for debugging. Valid Options:\n- \"\" - Disabled (default)\n- \"json\" - Full execution trace in JSON format, used by debug_traceTransaction RPC\n- \"struct\" - Go struct format for programmatic processing\n- \"access_list\" - Generates EIP-2930 access lists for gas optimization\n- \"markdown\" - Human-readable format for manual analysis\nSource: server/config/config.go:139\nImplementation: x/vm/keeper/state_transition.go:150-157\nnumber\ndefault: \"0\"\nLimits gas for transactions in CheckTx mode to prevent DoS attacks. When set to 0, any gas amount is accepted which can lead to mempool spam. Source: server/config/config.go:141\nTestnet Default: Set by evmd/cmd/evmd/cmd/testnet.go:303\nboolean\ndefault: \"false\"\nEnables SHA3 preimage recording in the VM for debugging tools to reverse hash lookups. Increases memory usage when enabled. Source: server/config/config.go:143\nnumber\ndefault: \"262144\"\nEIP-155 replay protection chain ID. Must match the expected network chain ID. Used for transaction signing validation. Source: server/config/config.go:145\nUsed in: x/vm/genesis.go:22\nnumber\ndefault: \"0\"\nMinimum priority fee (tip) required for transaction inclusion in mempool. Transactions with tips below this value may be rejected. Set to 0 to disable filtering. Flag: EVMMinTip\nSource: server/config/config.go:150\nType: Converted to uint256.Int internally\nstring\ndefault: \"127.0.0.1:8100\"\nAddress for go-ethereum metrics server. Emits EVM-specific metrics in Prometheus format on a separate server from Cosmos SDK metrics. Source: server/config/config.go:152\nNew in: v0.5.0\nEVM mempool configuration for transaction pool management.\nNew in v0.5.0 : Mempool configuration is now fully exposed in app.toml and can be adjusted without code changes. Previously, these settings were hardcoded.\nnumber\ndefault: \"1\"\nMinimum gas price to enforce for acceptance into the pool (in wei). Transactions with gas prices below this value are rejected from the mempool. Source: server/config/config.go:160\nValidation: Must be at least 1\nnumber\ndefault: \"10\"\nMinimum price bump percentage to replace an already existing transaction (nonce). When replacing a transaction with the same nonce, the new transaction must have a gas price at least this percentage higher. Source: server/config/config.go:162\nExample: 10 = require 10% higher gas price\nValidation: Must be at least 1\nnumber\ndefault: \"16\"\nNumber of executable transaction slots guaranteed per account. Each account is guaranteed to have this many pending transactions in the executable queue. Source: server/config/config.go:164\nValidation: Must be at least 1\nnumber\ndefault: \"5120\"\nMaximum number of executable transaction slots for all accounts. Total capacity for all pending executable transactions across all accounts (4096 + 1024 = 5120). Source: server/config/config.go:166\nValidation: Must be at least 1\nnumber\ndefault: \"64\"\nMaximum number of non-executable transaction slots permitted per account. For transactions with gaps in nonce sequence (future transactions). Source: server/config/config.go:168\nValidation: Must be at least 1\nnumber\ndefault: \"1024\"\nMaximum number of non-executable transaction slots for all accounts. Total capacity for queued (non-executable) transactions across all accounts. Source: server/config/config.go:170\nValidation: Must be at least 1\nstring\ndefault: \"3h0m0s\"\nMaximum amount of time non-executable transactions are queued. Transactions that remain non-executable longer than this duration are removed from the mempool. Source: server/config/config.go:172\nFormat: Go duration string (e.g., \"1h30m\" , \"30m0s\" , \"24h0m0s\" )\nValidation: Must be at least 1ns\nConfiguration Examples\nHigh-Throughput Chain:\n[ evm . mempool ]\nglobal-slots = 10240\nglobal-queue = 2048\nprice-limit = 100000000 # 0.1 gwei minimum\nlifetime = \"6h0m0s\"\nLow-Resource Node:\n[ evm . mempool ]\nglobal-slots = 2048\nglobal-queue = 512\nlifetime = \"1h0m0s\"\naccount-slots = 8\nStrict Spam Protection:\n[ evm . mempool ]\nprice-limit = 1000000000 # 1 gwei minimum\nprice-bump = 25 # 25% replacement cost\nlifetime = \"30m0s\"\naccount-slots = 4\nEthereum JSON-RPC server configuration.\nCore Settings\nboolean\ndefault: \"false\"\nEnable the JSON-RPC server. Must be true for Ethereum compatibility. Source: server/config/config.go:169\nTestnet configuration: evmd/cmd/evmd/cmd/testnet.go:303\nstring\ndefault: \"127.0.0.1:8545\"\nHTTP server bind address using standard Ethereum RPC port. Source: server/config/config.go:153\nstring\ndefault: \"127.0.0.1:8546\"\nWebSocket server address for eth_subscribe methods. Source: server/config/config.go:155\nImplementation: rpc/stream/rpc.go\nstring\ndefault: \"eth,net,web3\"\nJSON-RPC namespaces to enable. Available namespaces: web3 , eth , personal , net , txpool , debug , miner Source: server/config/config.go:151\nNamespace implementations: rpc/namespaces/\nstring[]\ndefault: \"['127.0.0.1', 'localhost']\"\nAllowed CORS origins for WebSocket connections. Source: server/config/config.go:195\nResource Limits\nnumber\ndefault: \"25000000\"\nGas limit for eth_call/estimateGas operations (25M gas). Set to 0 for unlimited. Source: server/config/config.go:157\nEnforced: rpc/namespaces/ethereum/eth/api.go:1039\nnumber\ndefault: \"1\"\nMaximum transaction fee cap in ether for eth_sendTransaction. Source: server/config/config.go:163\nEnforced: rpc/namespaces/ethereum/eth/api.go:1586\nnumber\ndefault: \"200\"\nMaximum concurrent filters per connection. Source: server/config/config.go:165\nImplementation: rpc/namespaces/ethereum/eth/filters/\nnumber\ndefault: \"100\"\nMaximum blocks that can be fetched for eth_feeHistory. Source: server/config/config.go:167\nnumber\ndefault: \"10000\"\nMaximum logs returned from a single eth_getLogs query. Source: server/config/config.go:171\nEnforced: rpc/namespaces/ethereum/eth/filters/api.go:442\nnumber\ndefault: \"10000\"\nMaximum block range allowed for eth_getLogs queries. Source: server/config/config.go:173\nEnforced: rpc/namespaces/ethereum/eth/filters/filter.go:268\nConnection Settings\nnumber\ndefault: \"1000\"\nMaximum number of requests in a batch (go-ethereum standard). Source: server/config/config.go:182\nnumber\ndefault: \"25000000\"\nMaximum bytes returned from a batched call (25MB). Source: server/config/config.go:184\nstring\ndefault: \"30s\"\nRead/write timeout for HTTP JSON-RPC server. Source: server/config/config.go:175\nstring\ndefault: \"120s\"\nIdle timeout for HTTP connections. Source: server/config/config.go:177\nnumber\ndefault: \"0\"\nMaximum simultaneous connections for the server listener. Set to 0 for unlimited. Source: server/config/config.go:187\nstring\ndefault: \"5s\"\nGlobal timeout for eth_call operations. Source: server/config/config.go:161\nFeatures\nboolean\ndefault: \"false\"\nEnable custom transaction indexer for EVM transactions. Required for: eth_getLogs , eth_getTransactionReceipt Source: server/config/config.go:189\nTestnet default: evmd/cmd/evmd/cmd/testnet.go:303\nboolean\ndefault: \"false\"\nEnable pprof endpoints in debug namespace. Source: server/config/config.go:197\nstring\ndefault: \"127.0.0.1:6065\"\nPrometheus metrics server address. Metrics path: /debug/metrics/prometheus Source: server/config/config.go:191\nSecurity\nboolean\ndefault: \"false\"\nAllow non-EIP155 signed transactions to be submitted. Source: server/config/config.go:180\nboolean\ndefault: \"true\"\nAllow insecure account unlocking when personal namespace is enabled. Source: server/config/config.go:159\nCLI flags and environment variables for runtime configuration. These parameters can be set via command line or environment variables to override configuration file settings.\nContext : These are EVM-specific runtime parameters that complement the standard Cosmos SDK flags. They control chain initialization and runtime behavior specific to EVM functionality.\nstring\ndefault: \"local-1\"\nCosmos SDK chain identifier for transaction signing and network identification. CLI Flag: --chain-id\nEnvironment: EVMD_CHAIN_ID\nUsage: evmd start --chain-id mychain-1\nnumber\ndefault: \"262144\"\nEIP-155 replay protection chain ID for Ethereum compatibility. Must be unique across all EVM networks. CLI Flag: --evm.evm-chain-id\nEnvironment: EVMD_EVM_CHAIN_ID\nUsage: evmd start --evm.evm-chain-id 9000\nConfig Alternative: Set in app.toml under [evm] evm-chain-id\nstring\ndefault: \"atest\"\nBase denomination for native token transactions and staking. CLI Flag: --denom\nEnvironment: EVMD_DENOM\nUsage: evmd init mynode --denom mytoken\nnumber\ndefault: \"0\"\nMinimum priority fee (in wei) required for mempool inclusion. CLI Flag: --evm.min-tip\nEnvironment: EVMD_EVM_MIN_TIP\nUsage: evmd start --evm.min-tip 1000000000\nConfig Alternative: Set in app.toml under [evm] min-tip\nnumber\ndefault: \"0\"\nMaximum gas limit for transactions in CheckTx validation mode. CLI Flag: --evm.max-tx-gas-wanted\nEnvironment: EVMD_MAX_TX_GAS_WANTED\nUsage: evmd start --evm.max-tx-gas-wanted 50000000\nConfig Alternative: Set in app.toml under [evm] max-tx-gas-wanted\nComplete app.toml with EVM-specific sections highlighted.\nComplete Application Configuration\n# This is a TOML config file.\n# For more information, see https://github.com/toml-lang/toml\n###############################################################################\n### Base Configuration ###\n###############################################################################\n# The minimum gas prices a validator is willing to accept for processing a\n# transaction. A transaction's fees must meet the minimum of any denomination\n# specified in this config (e.g. 0.25token1,0.0001token2).\nminimum-gas-prices = \"0atest\"\n# The maximum gas a query coming over rest/grpc may consume.\n# If this is set to zero, the query can consume an unbounded amount of gas.\nquery-gas-limit = \"0\"\n# default: the last 362880 states are kept, pruning at 10 block intervals\n# nothing: all historic states will be saved, nothing will be deleted (i.e. archiving node)\n# everything: 2 latest states will be kept; pruning at 10 block intervals.\n# custom: allow pruning options to be manually specified through 'pruning-keep-recent', and 'pruning-interval'\npruning = \"default\"\n# These are applied if and only if the pruning strategy is custom.\npruning-keep-recent = \"0\"\npruning-interval = \"0\"\n# HaltHeight contains a non-zero block height at which a node will gracefully\n# halt and shutdown that can be used to assist upgrades and testing.\n#\n# Note: Commitment of state will be attempted on the corresponding block.\nhalt-height = 0\n# HaltTime contains a non-zero minimum block time (in Unix seconds) at which\n# a node will gracefully halt and shutdown that can be used to assist upgrades\n# and testing.\n#\n# Note: Commitment of state will be attempted on the corresponding block.\nhalt-time = 0\n# MinRetainBlocks defines the minimum block height offset from the current\n# block being committed, such that all blocks past this offset are pruned\n# from CometBFT. It is used as part of the process of determining the\n# ResponseCommit.RetainHeight value during ABCI Commit. A value of 0 indicates\n# that no blocks should be pruned.\n#\n# This configuration value is only responsible for pruning CometBFT blocks.\n# It has no bearing on application state pruning which is determined by the\n# \"pruning-*\" configurations.\n#\n# Note: CometBFT block pruning is dependant on this parameter in conjunction\n# with the unbonding (safety threshold) period, state pruning and state sync\n# snapshot parameters to determine the correct minimum value of\n# ResponseCommit.RetainHeight.\nmin-retain-blocks = 0\n# InterBlockCache enables inter-block caching.\ninter-block-cache = true\n# IndexEvents defines the set of events in the form {eventType}.{attributeKey},\n# which informs CometBFT what to index. If empty, all events will be indexed.\n#\n# Example:\n# [\"message.sender\", \"message.recipient\"]\nindex-events = []\n# IavlCacheSize set the size of the iavl tree cache (in number of nodes).\niavl-cache-size = 781250\n# IAVLDisableFastNode enables or disables the fast node feature of IAVL.\n# Default is false.\niavl-disable-fastnode = false\n# AppDBBackend defines the database backend type to use for the application and snapshots DBs.\n# An empty string indicates that a fallback will be used.\n# The fallback is the db_backend value set in CometBFT's config.toml.\napp-db-backend = \"\"\n###############################################################################\n### Telemetry Configuration ###\n###############################################################################\n[ telemetry ]\n# Prefixed with keys to separate services.\nservice-name = \"\"\n# Enabled enables the application telemetry functionality. When enabled,\n# an in-memory sink is also enabled by default. Operators may also enabled\n# other sinks such as Prometheus.\nenabled = true\n# Enable prefixing gauge values with hostname.\nenable-hostname = false\n# Enable adding hostname to labels.\nenable-hostname-label = false\n# Enable adding service to labels.\nenable-service-label = false\n# PrometheusRetentionTime, when positive, enables a Prometheus metrics sink.\nprometheus-retention-time = 1000000000000\n# GlobalLabels defines a global set of name/value label tuples applied to all\n# metrics emitted using the wrapper functions defined in telemetry package.\n#\n# Example:\n# [[\"chain_id\", \"cosmoshub-1\"]]\nglobal-labels = [\n]\n# MetricsSink defines the type of metrics sink to use.\nmetrics-sink = \"\"\n# StatsdAddr defines the address of a statsd server to send metrics to.\n# Only utilized if MetricsSink is set to \"statsd\" or \"dogstatsd\".\nstatsd-addr = \"\"\n# DatadogHostname defines the hostname to use when emitting metrics to\n# Datadog. Only utilized if MetricsSink is set to \"dogstatsd\".\ndatadog-hostname = \"\"\n###############################################################################\n### API Configuration ###\n###############################################################################\n[ api ]\n# Enable defines if the API server should be enabled.\nenable = true\n# Swagger defines if swagger documentation should automatically be registered.\nswagger = false\n# Address defines the API server to listen on.\naddress = \"tcp://localhost:1317\"\n# MaxOpenConnections defines the number of maximum open connections.\nmax-open-connections = 1000\n# RPCReadTimeout defines the CometBFT RPC read timeout (in seconds).\nrpc-read-timeout = 10\n# RPCWriteTimeout defines the CometBFT RPC write timeout (in seconds).\nrpc-write-timeout = 0\n# RPCMaxBodyBytes defines the CometBFT maximum request body (in bytes).\nrpc-max-body-bytes = 1000000\n# EnableUnsafeCORS defines if CORS should be enabled (unsafe - use it at your own risk).\nenabled-unsafe-cors = false\n###############################################################################\n### gRPC Configuration ###\n###############################################################################\n[ grpc ]\n# Enable defines if the gRPC server should be enabled.\nenable = true\n# Address defines the gRPC server address to bind to.\naddress = \"localhost:9090\"\n# MaxRecvMsgSize defines the max message size in bytes the server can receive.\n# The default value is 10MB.\nmax-recv-msg-size = \"10485760\"\n# MaxSendMsgSize defines the max message size in bytes the server can send.\n# The default value is math.MaxInt32.\nmax-send-msg-size = \"2147483647\"\n###############################################################################\n### gRPC Web Configuration ###\n###############################################################################\n[ grpc-web ]\n# GRPCWebEnable defines if the gRPC-web should be enabled.\n# NOTE: gRPC must also be enabled, otherwise, this configuration is a no-op.\n# NOTE: gRPC-Web uses the same address as the API server.\nenable = true\n###############################################################################\n### State Sync Configuration ###\n###############################################################################\n# State sync snapshots allow other nodes to rapidly join the network without replaying historical\n# blocks, instead downloading and applying a snapshot of the application state at a given height.\n[ state-sync ]\n# snapshot-interval specifies the block interval at which local state sync snapshots are\n# taken (0 to disable).\nsnapshot-interval = 0\n# snapshot-keep-recent specifies the number of recent snapshots to keep and serve (0 to keep all).\nsnapshot-keep-recent = 2\n###############################################################################\n### State Streaming ###\n###############################################################################\n# Streaming allows nodes to stream state to external systems.\n[ streaming ]\n# streaming.abci specifies the configuration for the ABCI Listener streaming service.\n[ streaming . abci ]\n# List of kv store keys to stream out via gRPC.\n# The store key names MUST match the module's StoreKey name.\n#\n# Example:\n# [\"acc\", \"bank\", \"gov\", \"staking\", \"mint\"[,...]]\n# [\"*\"] to expose all keys.\nkeys = []\n# The plugin name used for streaming via gRPC.\n# Streaming is only enabled if this is set.\n# Supported plugins: abci\nplugin = \"\"\n# stop-node-on-err specifies whether to stop the node on message delivery error.\nstop-node-on-err = true\n###############################################################################\n### Mempool ###\n###############################################################################\n[ mempool ]\n# Setting max-txs to 0 will allow for a unbounded amount of transactions in the mempool.\n# Setting max_txs to negative 1 (-1) will disable transactions from being inserted into the mempool (no-op mempool).\n# Setting max_txs to a positive number (> 0) will limit the number of transactions in the mempool, by the specified amount.\n#\n# Note, this configuration only applies to SDK built-in app-side mempool\n# implementations.\nmax-txs = -1\n###############################################################################\n### EVM Configuration ###\n###############################################################################\n[ evm ]\n# Tracer defines the 'vm.Tracer' type that the EVM will use when the node is run in\n# debug mode. To enable tracing use the '--evm.tracer' flag when starting your node.\n# Valid types are: json|struct|access_list|markdown\ntracer = \"\"\n# MaxTxGasWanted defines the gas wanted for each eth tx returned in ante handler in check tx mode.\nmax-tx-gas-wanted = 0\n# EnablePreimageRecording enables tracking of SHA3 preimages in the VM\ncache-preimage = false\n# EVMChainID is the EIP-155 compatible replay protection chain ID. This is separate from the Cosmos chain ID.\nevm-chain-id = 262144\n# MinTip defines the minimum priority fee for the mempool.\nmin-tip = 0\n# Geth metrics server address\ngeth-metrics-address = \"127.0.0.1:8100\"\n# Mempool configuration for EVM transactions\n[ evm . mempool ]\n# PriceLimit is the minimum gas price to enforce for acceptance into the pool (in wei)\nprice-limit = 1\n# PriceBump is the minimum price bump percentage to replace an already existing transaction (nonce)\nprice-bump = 10\n# AccountSlots is the number of executable transaction slots guaranteed per account\naccount-slots = 16\n# GlobalSlots is the maximum number of executable transaction slots for all accounts\nglobal-slots = 5120\n# AccountQueue is the maximum number of non-executable transaction slots permitted per account\naccount-queue = 64\n# GlobalQueue is the maximum number of non-executable transaction slots for all accounts\nglobal-queue = 1024\n# Lifetime is the maximum amount of time non-executable transaction are queued\nlifetime = \"3h0m0s\"\n###############################################################################\n### JSON RPC Configuration ###\n###############################################################################\n[ json-rpc ]\n# Enable defines if the JSONRPC server should be enabled.\nenable = true\n# Address defines the EVM RPC HTTP server address to bind to.\naddress = \"127.0.0.1:8545\"\n# Address defines the EVM WebSocket server address to bind to.\nws-address = \"127.0.0.1:8546\"\n# WSOrigins defines the allowed origins for WebSocket connections.\n# Example: [\"localhost\", \"127.0.0.1\", \"myapp.example.com\"]\nws-origins = [ \"127.0.0.1\" , \"localhost\" ]\n# API defines a list of JSON-RPC namespaces that should be enabled\n# Example: \"eth,txpool,personal,net,debug,web3\"\napi = \"eth,net,web3\"\n# GasCap sets a cap on gas that can be used in eth_call/estimateGas (0=infinite). Default: 25,000,000.\ngas-cap = 25000000\n# Allow insecure account unlocking when account-related RPCs are exposed by http\nallow-insecure-unlock = true\n# EVMTimeout is the global timeout for eth_call. Default: 5s.\nevm-timeout = \"5s\"\n# TxFeeCap is the global tx-fee cap for send transaction. Default: 1eth.\ntxfee-cap = 1\n# FilterCap sets the global cap for total number of filters that can be created\nfilter-cap = 200\n# FeeHistoryCap sets the global cap for total number of blocks that can be fetched\nfeehistory-cap = 100\n# LogsCap defines the max number of results can be returned from single 'eth_getLogs' query.\nlogs-cap = 10000\n# BlockRangeCap defines the max block range allowed for 'eth_getLogs' query.\nblock-range-cap = 10000\n# HTTPTimeout is the read/write timeout of http json-rpc server.\nhttp-timeout = \"30s\"\n# HTTPIdleTimeout is the idle timeout of http json-rpc server.\nhttp-idle-timeout = \"2m0s\"\n# AllowUnprotectedTxs restricts unprotected (non EIP155 signed) transactions to be submitted via\n# the node's RPC when the global parameter is disabled.\nallow-unprotected-txs = false\n# MaxOpenConnections sets the maximum number of simultaneous connections\n# for the server listener.\nmax-open-connections = 0\n# EnableIndexer enables the custom transaction indexer for the EVM (ethereum transactions).\nenable-indexer = false\n# MetricsAddress defines the EVM Metrics server address to bind to. Pass --metrics in CLI to enable\n# Prometheus metrics path: /debug/metrics/prometheus\nmetrics-address = \"127.0.0.1:6065\"\n# Maximum number of requests in a batch.\nbatch-request-limit = 1000\n# Maximum number of bytes returned from a batched call.\nbatch-response-max-size = 25000000\n# Enabled profiling in the debug namespace\nenable-profiling = false\n###############################################################################\n### TLS Configuration ###\n###############################################################################\n[ tls ]\n# Certificate path defines the cert.pem file path for the TLS configuration.\ncertificate-path = \"\"\n# Key path defines the key.pem file path for the TLS configuration.\nkey-path = \"\"\nLines (130-260): are EVM-specific configuration sections added by Cosmos EVM Lines (1-129): are Base Cosmos SDK parameters Key EVM sections:\n- [evm] : EVM runtime settings (lines 645-670)\n- [evm.mempool] : Mempool configuration (lines 672-694, new in v0.5.0 )\n- [json-rpc] : Ethereum JSON-RPC server (lines 700-747)\n- [tls] : TLS configuration (lines 753-760)\nTemplate sources:\n- SDK config: cosmos-sdk/server/config/toml.go\n- EVM config: evm/server/config/toml.go\nBlockchain initialization parameters set during chain genesis. These EVM-specific parameters configure the initial state and behavior of the EVM module.\nContext : These parameters are set once during chain initialization and typically cannot be changed without governance proposals or network upgrades. They control fundamental EVM behavior and compatibility.\nGenesis Configuration Example\n{\n\"chain_id\" : \"mychain-1\" ,\n\"app_state\" : {\n\"evm\" : {\n\"params\" : {\n\"evm_denom\" : \"atest\" ,\n\"history_serve_window\" : 8192 ,\n\"active_static_precompiles\" : [\n\"0x0000000000000000000000000000000000000100\" ,\n\"0x0000000000000000000000000000000000000400\" ,\n\"0x0000000000000000000000000000000000000800\" ,\n\"0x0000000000000000000000000000000000000801\" ,\n\"0x0000000000000000000000000000000000000802\" ,\n\"0x0000000000000000000000000000000000000804\" ,\n\"0x0000000000000000000000000000000000000805\"\n],\n\"access_control\" : {\n\"create\" : { \"access_type\" : \"ACCESS_TYPE_PERMISSIONLESS\" },\n\"call\" : { \"access_type\" : \"ACCESS_TYPE_PERMISSIONLESS\" }\n}\n},\n\"feemarket\" : {\n\"params\" : {\n\"no_base_fee\" : false ,\n\"base_fee_change_denominator\" : 8 ,\n\"elasticity_multiplier\" : 2 ,\n\"base_fee\" : \"1000000000\" ,\n\"min_gas_price\" : \"0\" ,\n\"min_gas_multiplier\" : \"0.5\"\n}\n},\n\"consensus\" : {\n\"params\" : {\n\"block\" : {\n\"max_bytes\" : \"22020096\" ,\n\"max_gas\" : \"100000000\"\n}\nEVM-Specific Parameters:\n- evm_denom : Base denomination for EVM operations and gas payments\n- history_serve_window : Number of historical block hashes to store (EIP-2935)\n- active_static_precompiles : Enabled precompile contract addresses\n- access_control : Permissions for contract creation and execution\nFee Market Parameters:\n- base_fee : Initial EIP-1559 base fee value\n- base_fee_change_denominator : Rate of base fee adjustment\n- elasticity_multiplier : Block utilization threshold for fee changes\nConsensus Parameters:\n- max_gas : Maximum gas per block (critical for mempool configuration)\nProduction validator node configuration and security considerations.\nCritical Security Notice: Validator nodes should NEVER expose RPC/API ports publicly. Only dedicated RPC nodes (non-validators) should serve public traffic.\nValidator vs RPC Node Architecture\nProduction networks should use a two-tier architecture:\nValidator Nodes (Private)\nPurpose: Block production and consensus participation only Configuration Requirements:\n- Disable all public-facing services\n- Restrict network access to other validators via persistent peers\n- Do NOT enable JSON-RPC server\n- Do NOT expose API/gRPC ports publicly\n- Use firewall rules to block external access\nRecommended app.toml settings:\n[ api ]\nenable = false # Disable REST API\n[ grpc ]\nenable = false # Disable gRPC or bind to localhost only\naddress = \"localhost:9090\"\n[ json-rpc ]\nenable = false # CRITICAL: Keep JSON-RPC disabled on validators\n[ evm ]\nmax-tx-gas-wanted = 50000000 # Set reasonable gas limits\nWhy this matters:\n- DDoS Protection: Public RPC access can overwhelm validator resources\n- Resource Exhaustion: Heavy query load impacts block production\n- Uptime: Validators must prioritize consensus participation over serving requests\n- Security: Reduced attack surface for exploits\n- Slashing Risk: Downtime from overload can lead to slashing penalties\nRPC Nodes (Public)\nPurpose: Serve public API/RPC requests without participating in consensus Configuration Requirements:\n- Enable JSON-RPC, API, and WebSocket endpoints\n- Use load balancers for distribution\n- Set appropriate rate limits and caps\n- Can run multiple RPC nodes for redundancy\n- No validator keys stored\nRecommended app.toml settings:\n[ api ]\nenable = true\naddress = \"tcp://0.0.0.0:1317\" # Bind to all interfaces\nmax-open-connections = 1000\n[ grpc ]\nenable = true\naddress = \"0.0.0.0:9090\"\n[ json-rpc ]\nenable = true\naddress = \"0.0.0.0:8545\"\nws-address = \"0.0.0.0:8546\"\napi = \"eth,net,web3,txpool\"\n# Set resource limits\ngas-cap = 50000000\nfilter-cap = 200\nlogs-cap = 10000\nblock-range-cap = 10000\nmax-open-connections = 500\nbatch-request-limit = 100\nValidator Security Checklist\n- JSON-RPC is disabled on validator nodes\n- API/gRPC endpoints not exposed publicly on validators\n- Firewall rules restrict validator access to known peers only\n- Separate RPC nodes deployed for public access\n- Load balancers configured for RPC node redundancy\n- Monitoring alerts for validator downtime\n- Regular security audits of network architecture\n- Validator keys stored securely (preferably HSM)\n- SSH access restricted and key-based only\nNetwork Topology Example\nPublic Internet\n│\n├─── Load Balancer\n│ │\n│ ┌────┴────┬────────┐\n│ │ │ │\n│ RPC Node RPC Node RPC Node\n│ │ │ │\n└────┴─────────┴────────┘\n│\n═══════════════════════════\nPrivate Validator Network\n═══════════════════════════\n│\n┌──────────┼──────────┐\n│ │ │\nValidator 1 Validator 2 Validator 3\n(RPC disabled) (RPC disabled) (RPC disabled)\nState Sync Consideration: If validators need to quickly sync using state sync, they may temporarily enable RPC on a private network segment to serve snapshots to each other. This should be done on a separate internal interface, never exposed publicly.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.solana.com/t/a-practical-overview-of-scheduler-implementations-in-solana-validators/4803","domain":"forum.solana.com","title":"A Practical Overview of Scheduler Implementations in Solana Validators - Research - Solana Developer Forums","hash":"9d916f4f09ce3576a8427072cbc28d55acbf72d9710b76a9b23f44c26b3d2616","tokens":4665,"chars":18657,"crawler":"crawler-f6nn","verified":"exact","ts":1791172344412,"text":"Solana Developer Forums\nA Practical Overview of Scheduler Implementations in Solana Validators\nResearch\ncore\nrezabfil\nMay 18, 2026, 9:26pm\n1\nA Practical Overview of Scheduler Implementations in Solana Validators\nContributors: Veronika Bauer, Filip Rezabek, Prof. Georg Carle\nIn blockchains like Solana, the leader node is responsible for creating blocks. Each block consists of transactions that must be executed by the network. Since high-throughput blockchains often receive more transactions than can be included immediately, the leader needs a policy for deciding which transactions to process next.\nOn Solana, this responsibility sits with the scheduler . The scheduler determines the order in which incoming transactions are assigned for execution. This affects both user experience and validator economics: users can submit priority transactions [7] by paying an additional fee, and validators can earn more when high-value transactions are selected efficiently. Solana charges a base fee for every submitted transaction, while users may optionally add a priority fee [8] to improve confirmation speed. The size of that priority fee depends on network demand and can vary substantially during periods of congestion, such as NFT mints, liquidations, or arbitrage opportunities.\nThis creates a scheduling trade-off. A validator may prefer high-priority transactions because they pay more, but transactions that consume fewer compute units can be cheaper and easier to execute. As a result, scheduling is not just a performance problem; it is also a validator revenue and resource allocation problem. This post provides an overview of different scheduler implementations in Solana validators, focusing on Agave and Firedancer / Frankendancer .\nWhat is a scheduler?\nA scheduler is part of Solana’s Transaction Processing Unit , or TPU. The TPU receives transactions, verifies them, forwards them when appropriate, and eventually executes them during the banking stage. A useful overview of the TPU is available in the Anza validator documentation [1], and Andrew Fitzgerald has a detailed explanation of the Solana banking stage and scheduler [2].\nAt a high level, transaction processing works as follows:\n- A transaction is sent to a validator.\n- The transaction is received by the QUIC streamer.\n- During the SigVerify stage, transactions are deduplicated and signatures are verified.\n- Invalid transactions are dropped.\n- If the node is not the current leader, the forwarding stage forwards the transaction to the leader.\n- If the node is the current leader, the transaction enters the banking stage.\n- The banking stage schedules and executes transactions while Proof of History is produced.\n- Once a batch has been built, it is broadcast through Turbine so downstream validators can receive and vote on the block.\nThe faster a transaction is scheduled and processed by the banking stage, the sooner it can be propagated and finalized. Therefore, the scheduler plays a central role in both transaction latency and block construction quality.\nSolana transaction processing unit, showing packet ingress, signature verification, forwarding, banking, scheduling, workers, Proof of History, broadcast, Turbine, and validators.690x253 3260×1198 230 KB\nFigure 1: Solana transaction processing unit (TPU). Adapted from the Anza TPU documentation [1] and Andrew Fitzgerald’s banking stage and scheduler overview [2].\nScheduler implementations in Agave\nAgave has gone through several scheduler designs. Before Agave v1.18, it used a thread-local multi-iterator rather than a centralized scheduler. Worker threads pulled transactions directly from a shared channel. Each thread maintained its own transaction queue, sorted transactions by priority, selected a transaction, and attempted to acquire the required locks.\nThis design could create severe delays under high load. During periods such as NFT mints, many high-priority transactions may conflict on the same accounts. In that case, worker threads repeatedly fail to acquire locks, and different threads may compete for the same locked accounts. To address this, Agave introduced a central scheduler in v1.18, described in Anza’s post on the central scheduler in Agave v1.18 [3] and summarized in Helius’s Solana v1.18 update [4].\nAgave currently provides two scheduler implementations:\n- The central scheduler , which has been the standard scheduler since Agave v2.0, according to the Helius Agave v2.0 update [5].\n- The greedy scheduler , introduced in Agave v2.1 but opt-in rather than enabled by default, as described in the Helius Agave v2.1 update [6].\nAgave central scheduler\nThe central scheduler was introduced to prioritize high-value transactions while reducing account lock conflicts. Its goal is to schedule high-priority transactions that do not conflict with each other, then send them to worker threads for execution.\nIncoming transactions are inserted into a priority queue. Agave’s priority calculation is based on fees and requested compute units:\nPriority = ((priority fee × requested compute units) + base fee) / (1 + requested compute units)\nThis formula means that transactions with higher priority fees can receive higher priority, but the requested compute units also matter. A transaction that requests fewer compute units can be comparatively more attractive, all else equal.\nThe central scheduler then pops high-priority transactions from the queue and uses them to build a **priority graph**. This graph models dependencies between transactions. Transactions that conflict with each other are connected by edges, while non-conflicting transactions can be scheduled in parallel. The graph is a directed acyclic graph used to decide which transactions can be safely assigned to worker threads.\nThe central scheduler works roughly as follows:\n- Determine how many compute units can still be assigned to each worker thread.\n- Select threads whose assigned compute units are below the configured limit.\n- Pick the next transaction from the priority graph.\n- Acquire the required locks.\n- Assign the transaction to a worker thread.\n- Update the worker’s compute unit count.\n- Remove the scheduled transaction from the graph.\n- Insert another transaction from the priority queue.\n- Repeat while worker threads still have available compute capacity.\nA key benefit of the central scheduler is its centralized view of account locks. If a selected transaction requires locks already held by a specific thread, the scheduler attempts to place it on that thread. If no thread currently holds the required locks, the transaction may be scheduled to any available thread.\nThe scheduler is also conservative around conflicts. If a high-priority transaction cannot be scheduled immediately because of conflicts, it remains in the priority graph. The scheduler avoids scheduling lower-priority transactions that would conflict with the held-back transaction.\nThe trade-off is overhead. Constructing and maintaining the priority graph can become expensive under high load. As noted in discussions of the central scheduler [3], the graph improves lock-aware scheduling, but it also introduces work that can slow down scheduling when transaction volume is high.\nAgave greedy scheduler\nThe greedy scheduler was introduced to reduce scheduling overhead and improve throughput potential. Unlike the central scheduler, it does not build a dependency graph first. Instead, it tries to schedule transactions immediately in priority order.\nThe greedy scheduler begins by sanitizing incoming transactions and calculating their priorities. Transactions are inserted into a priority queue ordered by priority. Worker threads are assigned compute-unit budgets, representing how much additional work each thread can accept before reaching its compute limit.\nThe scheduler then proceeds greedily:\n- Add all worker threads with the remaining compute-unit budget to the list of schedulable threads.\n- Select the highest-priority transaction from the priority queue.\n- Check which locks the transaction requires.\n- Determine whether the transaction can be assigned to an available thread.\n- If the transaction conflicts with any transaction in the current batch, complete and send the current batch.\n- If the transaction still cannot be scheduled, place it in an unscheduled list.\n- Otherwise, acquire the required locks, assign the transaction to a thread, and update that thread’s budget.\n- Repeat until no available thread has remaining budget.\n- Return unscheduled transactions to the priority queue.\nThe greedy scheduler’s main goal is to schedule the highest-priority transaction as soon as possible. This can reduce latency for high-priority transactions. However, it can also lead to smaller batches.\nFor example, suppose transactions A, E, and I all have high priority but conflict with each other. The central scheduler may fill a batch with non-conflicting transactions such as A, B, C, and D. The greedy scheduler may instead immediately send a batch containing only A if the next high-priority transaction conflicts with the current batch. This allows the next high-priority transaction to be considered sooner, but at the cost of smaller batch sizes and potentially lower batching efficiency.\nThe trade-off is therefore clear: the greedy scheduler can improve responsiveness for high-priority transactions, but it may reduce batch size and overall efficiency in some workloads. Helius’s Agave v2.1 update [6] gives a useful overview of why this design was introduced and why it is not enabled by default.\nFiredancer / Frankendancer scheduler\nFiredancer is a Solana validator implementation developed by Jump Crypto. Frankendancer refers to the transitional architecture that combines Firedancer components with parts of Agave while the Firedancer team works toward removing Agave code. The scheduler behavior in Firedancer can be configured using different modes in the Firedancer codebase [12].\nFiredancer supports two main scheduling modes:\nMode\nGoal\nBehavior\nBalanced\nOptimize for revenue while keeping block production practical\nEnabled by default. Votes are always scheduled. Bundles are restricted to one bank tile, while other transactions are paced.\nPerf\nFill blocks as quickly as possible\nVotes, transactions, and bundles can be scheduled as needed. The emphasis is on full blocks and throughput.\nOlder versions also included a bundle mode. This mode enabled the revenue scheduler, which could increase revenue but often resulted in blocks that were not fully occupied. In this mode, votes and bundles were allowed on every tile, while single transactions were scheduled only during the final 50 ms of the slot. This mode has since been deprecated.\nFiredancer distinguishes between two important transaction groupings:\n- Microblocks , which contain multiple transactions that can be executed in arbitrary order.\n- Bundles , which contain multiple atomic transactions that must be executed in order.\nBundles are often treated as especially lucrative, so they are prioritized. However, they also carry an important risk: if one transaction in a bundle expires, the entire bundle becomes invalid. Harsh Patel’s article on Firedancer’s transaction scheduler [10] provides a detailed overview of this design.\nFiredancer priority queues and treaps\nAfter a transaction is received by Firedancer, it passes a series of checks, including deduplication and blacklist checks. If it passes, its priority is calculated, and it is assigned to a priority queue.\nFiredancer uses a treap , which is a balanced binary search tree, for priority ordering. It maintains several treap types:\n- Pending treap\n- Pending votes treap\n- Penalty treap\n- Pending bundles treap\nA transaction’s priority is based on its reward relative to compute resources:\npriority = reward / compute resources\nThis means that Firedancer favors transactions that provide a higher reward per unit of compute. However, this is not the whole story. Transactions that allocate large amounts of data are penalized by reducing their reward:\ndivisor = (allocated data × maximum allowed costs per block) /\n(estimated costs × maximum allowed allocated data per block)\nnew reward = reward / divisor\nAs a result, transactions with significant data allocation receive lower priority.\nA similar penalty applies to transactions that write to hot accounts. Hot accounts are accounts that have been touched by many transactions, which means other transactions may need to wait before they can access them. These transactions are placed into the penalty treap.\nWhen a transaction can be executed, Firedancer selects the highest-priority transaction from the relevant treap.\nFiredancer dropping behavior\nIf a treap is full, Firedancer may delete transactions. The transaction selected for deletion depends on both its reward-cost ratio and a scale factor.\nThe scale factor differs by treap:\nTreap\nScale factor behavior\nPending\nUsually 1.0. Can become 0.0 depending on vote composition.\nPending votes\nUsually 1.0, unless the treap is more than 75% full, in which case it can become 0.0.\nPenalty\n1.0 while the treap has 100 or fewer transactions. Above that, it decreases according to the number of transactions.\nPending bundles\nVery large, because bundles are assumed to be high-reward.\nFor the penalty treap, the scale factor is:\nscale factor = sqrt(100 / number of transactions in treap)\nThe scheduler multiplies the scale factor by the reward-to-cost ratio of sampled transactions, then deletes the transaction with the smallest result. A larger scale factor makes a transaction less likely to be deleted.\nTransactions can also be dropped for other reasons. If the heap of the relevant Firedancer module is full, a new transaction is dropped if its priority is lower than the lowest-priority transaction already in the heap. Transactions can also be dropped if they require too many compute units or if their costs cannot be estimated.\nBundles are a special case. They can occupy only up to half the maximum pack depth. Once that threshold is reached, new bundles are dropped. Within the bundle treap, bundles are generally ordered first-in, first-out. Bundles also cannot be mixed with voting transactions, so they are scheduled only when no vote is scheduled.\nThere is one exception: initializer bundles. These are placed at the top of the list and executed next. They are used when state initialization is required at the beginning of a slot, and the relevant state may change between transactions.\nComparison of Solana scheduler implementations\nFeature\nAgave central scheduler\nAgave greedy scheduler\nFiredancer / Frankendancer scheduler\nValidator\nAgave\nFiredancer / Frankendancer\nIntroduced in\nAgave v1.18\nAgave v2.1\nN/A; developed by Jump Crypto\nDefault?\nYes, since Agave v2.0\nNo, opt-in\nYes, balanced mode\nPriority structure\nPriority queue → dependency graph\nPriority queue\nTreap / balanced binary search tree\nConflict handling\nHolds back conflicting transactions in the graph; schedules on the same thread when possible\nCompletes and sends the current batch when a conflict is detected\nUses penalty treap for hot accounts; bundles are generally FIFO\nBatch strategy\nTries to fill batches with non-conflicting high-priority transactions\nMay release smaller batches to prioritize high-priority transactions sooner\nConfigurable through balanced and perf modes\nTransaction types\nStandard transactions\nMicroblocks and bundles\nKey trade-off\nBetter batch construction, but graph construction is expensive under high load\nFaster handling of high-priority transactions, but smaller batches\nRevenue versus block fullness depends on configuration\nMain weakness\nDependency graph can be costly under load\nSmaller batches may reduce throughput\nBundle expiry can invalidate the entire bundle\nSummary\nSolana scheduler design is still evolving. Agave moved from a thread-local multi-iterator model to a central scheduler, and later introduced the opt-in greedy scheduler. These changes show that scheduling is a hard problem: the scheduler must balance transaction priority, compute-unit usage, lock conflicts, batch size, validator revenue, and block fullness.\nFiredancer takes a different approach, using treaps and configurable scheduling modes to balance performance and revenue. It also treats bundles as first-class scheduling objects, which introduces additional complexity around ordering, expiry, and block construction.\nThe main takeaway is that Solana scheduling is not a solved problem. It is an active design space where small policy differences can affect latency, throughput, validator economics, and user experience. With future protocol changes, such as Alpenglow, on the horizon, the Solana scheduler design will likely continue to evolve.\nAcknowledgements\nWe are grateful for the support provided by the Staking Facilities team. We especially thank Matthias Schmitz for his valuable feedback on the report.\nReferences\n[1] Anza. Transaction Processing Unit in a Solana Validator .\n[2] Andrew Fitzgerald. Solana Banking Stage and Scheduler .\n[3] Anza. Introducing the Central Scheduler: An Optional Feature of Agave v1.18 .\n[4] Helius. All You Need to Know About Solana’s v1.18 Update .\n[5] Helius. Agave v2.0 Update: All You Need to Know .\n[6] Helius. Agave v2.1 Update: All You Need to Know .\n[7] Harsh Patel. What’s new with Solana’s transaction scheduler? .\n[8] Solana. Fee Structure .\n[9] GETBLOCK. How To Optimize Solana Transactions with Priority Fees .\n[10] Harsh Patel. What’s unique about Firedancer’s transaction scheduler? .\n[11] Anza. agave ., GitHub\n[12] Firedancer-io. firedancer . GitHub\n1 Like\nginugokz\nMay 22, 2026, 8:41am\n2\nHonestly, I think Agave is overcomplicating things. The central scheduler looks good on paper, but in practice we’re adding overhead for marginal gains. The greedy scheduler is more honest about what the network actually looks like under load. My concern is that we’re optimizing for congestion scenarios that rarely play out the way the models assume.\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\n12929\nDecember 25, 2024\nSIMD-0326: Proposal for the New Alpenglow Consensus Protocol\nGovernance\ncore\n117\n11685\nJune 13, 2026\nProposal For Introducing a Programmatic, Market-Based Emission Mechanism Based on Staking Participation Rate\nGovernance\nsimd\n63\n7453\nMarch 14, 2025\nProposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet\nGovernance\nfeature\n,\ncore\n25\n5616\nOctober 4, 2025\nSteak Proposal - A Solana Proposal For Memecoins\nResearch\n0\n388\nJuly 2, 2026\nDiscourse Footer"}
{"url":"https://discuss.ens.domains/t/fluidkey-spp3-quarterly-reports/22362","domain":"discuss.ens.domains","title":"Fluidkey: SPP3 Quarterly Reports - Reports - ENS DAO Governance Forum","hash":"d2ea96bf97e556238cf01e4585cdac808b8dd42d1df87c5f359c69cf6f52fc10","tokens":178,"chars":712,"crawler":"crawler-f6nn","verified":"exact","ts":1791172346622,"text":"ENS DAO Governance Forum\nFluidkey: SPP3 Quarterly Reports\nService Provider Program\nReports\nservice-providers\nmoritz\nAugust 19, 2026, 1:56pm\n1\nFluidkey: SPP3 Quarterly Reports\nAbout\nThis post contains our reporting requirement for the ENS Service Provider Program Season 3.\nEach quarterly report is contained in this forum thread and will cover:\n- the current progress against the deliverables in our SPP3 application;\n- what’s planned for the next quarter, and;\n- any scope changes or challenges (if applicable).\nReports\n- Q3 2026 — Pending\n- Q4 2026 — Pending\n- Q1 2027 — Pending\n- Q2 2027 — Pending\nFor any questions, please contact us via email at hey@fluidkey.com\n2 Likes\nENS DAO Newsletter #119 — 09/01/2026"}
{"url":"https://aave.com/docs/aave-v4/positions","domain":"aave.com","title":"Aave v4 User Positions | Aave Protocol Documentation","hash":"fb1726176f00f97a8f0eb66553fdf380efe874cb2571694897867cc52990e92d","tokens":1093,"chars":4370,"crawler":"crawler-f6nn","verified":"exact","ts":1791172348944,"text":"Docs\nUser Positions # Copy\nLearn how to manage user positions on Aave v4.\nA User Position represents the complete financial state of a user within a specific Spoke, tracking User Supplies and User Borrows alongside key risk metrics such as Health Factor and Risk Premium .\nUnlike v3, where user positions were per-market, v4 positions are per-Spoke, allowing users to manage different strategies and risk profiles independently.\nIn the Aave Protocol, a User Account —often referred to simply as a User —is\na single Ethereum address that has interacted with the protocol, either as an\nExternally Owned Account (EOA) or a smart contract.\nUser Supplies # Copy\nUser Supplies represent assets that a user has deposited into a spoke's Reserve. Each supply position:\n-\nAccrues yield automatically through share-based accounting that appreciates over time\n-\nMay be enabled as collateral (if the reserve supports it) to provide borrowing power based on the asset's Loan-to-Value (LTV) ratio\n-\nAffects the Risk Premium when enabled as collateral — riskier collateral assets increase the overall risk profile of the position\n-\nCan be withdrawn at any time, provided the position's Health Factor remains above 1.0\nThe above applies to standard Hub and Spoke behavior. Tailored implementations\nmay vary.\nUser Borrows # Copy\nUser Borrows represent assets that a user has borrowed from a spoke's Reserve. Each borrow position:\n-\nAccumulates interest based on the asset's borrow rate, increasing debt over time\n-\nRequires collateral backing according to liquidation thresholds specific to each borrowed asset\n-\nImpacts the Health Factor as part of the total debt value\n-\nCan be repaid partially or fully at any time to reduce debt and free up collateral\nThe above applies to standard Hub and Spoke behavior. Tailored implementations\nmay vary.\nHealth Factor # Copy\nThe Health Factor is the core safety metric that determines a user position's liquidation risk. It measures the stability of a user position:\nHealth Factor = Total Borrow Value Total Collateral Value × Weighted Average Collateral Factor\nThe health factor value determines the position's safety status:\n-\nAbove 1.0 : The position is safe from liquidation\n-\nBelow 1.0 : The position becomes eligible for liquidation — liquidators repay only enough debt to restore the position to a healthy state\n-\nChanges dynamically as asset prices fluctuate and interest accrues on both supplies and borrows\n-\nCan be improved by supplying more collateral or repaying part of the borrowed amount\n-\nDetermines available actions — new borrows or collateral withdrawals are blocked if they would reduce the Health Factor below 1.0\nExample:\nIf a user supplies $10,000 in ETH as collateral with an 80% Collateral Factor and borrows $6,000 in GHO, the health factor would be 1.333.\nUser Risk Premium # Copy\nUser Risk Premium represents the additional interest charge applied to borrowing based on the quality of a user’s collateral. It determines how much extra a user pays on top of the base borrow rate for any borrowed asset within a Spoke.\n-\nBased on Collateral Risk — a percentage value from 0% (highest quality) to 1000% (maximum risk) that reflects how risky an asset is when used as collateral\n-\nWeighted by collateral amounts — calculated using only the collateral needed to cover total debt, starting with the safest assets\n-\nUpdated dynamically — recalculated when users withdraw, borrow, or through ad-hoc refresh.\n-\nLower is better — users with safer collateral pay lower interest rates\nFor example, a 0% User Risk Premium means paying only the base rate, while 50% means paying 50% more (7.5% total if base rate is 5%).\nCross-Spoke Strategies # Copy\nv4’s modular design enables sophisticated position management across multiple Spokes.\nSpoke Isolation # Copy\nEach Spoke maintains independent risk parameters and liquidation logic. This means:\n-\nPositions in different Spokes do not affect each other’s Health Factors\n-\nA user can hold conservative positions in one Spoke and aggressive positions in another\nMulti-Hub Access # Copy\nAdvanced Spokes can access multiple Hubs , enabling strategies such as:\n-\nCollateralizing assets from one Hub to borrow from another\n-\nAccessing different yield opportunities across Hub configurations\n-\nOptimizing liquidity and rates across the entire protocol\nPrevious\nIncentives\nNext\nOpen Positions"}
{"url":"https://docs.squads.so/main/getting-started/create-a-squad","domain":"docs.squads.so","title":"Create a Squad | Squads Docs","hash":"2a2538eb631f9688f1c4e999ab73b779668b671def93210987907f7ec77f0b92","tokens":615,"chars":2458,"crawler":"crawler-f6nn","verified":"exact","ts":1791172351819,"text":"Squads Docs\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nCreate a Squad\nEverything you need to know about creating your first Squad.\nCreating a Squad\n-\nHead over to app.squads.so and connect your Solana wallet by clicking the \"Connect Wallet\" button.\nThe app will automatically detect the compatible Solana wallets you have installed and show them in the \"Connect your wallet\" pop-up. If you do not have a wallet, you can also create and use a Squads account with your email via TipLink .\nLedger Connect is not supported. If you're using a Ledger, connect through Phantom or Solflare wallets instead. Enable Blind Signing on your Ledger device to ensure successful transaction signing.\nSelect wallet pop-up\n-\nAfter connecting your wallet, click on the \"Create a Squad\" button.\n-\nEnter your Squad's details (can be modified later):\n-\nSquad name\n-\nProfile picture (JPEG, PNG, or GIF formats, under 3MB)\n-\nDescription (optional, limited to 64 characters)\nSquad details\n-\nAdd members to your Squad with their public keys and set a confirmation threshold.\nSquad members and confirmation threshold setup\nThe confirmation threshold determines the number of approvals required from Squad members for transaction execution. For example, a 2/3 threshold means two out of three wallets must approve a transaction for it to be executed.\nAvoid setting the threshold at 1/1 signatures as it creates a single point of failure. Similarly, setting the threshold at maximum capacity may lead to access issues if control over one wallet is lost.\nYou can add up to 10 initial members. Additional members can be added after the Squad is created, subject to multisig approval based on the set confirmation threshold. Review the information once all members are added and click \"Next\".\nSummary of your Squad's details\n-\nOn the final review screen, click \"Confirm\" to create your Squad. Once created, you can use the \"Share\" button in the pop-up to share the Squad URL with your team members.\nDeploying a Squads multisig requires a small amount of SOL to cover a one-time 0.1 SOL deployment fee, 0.001 SOL to fund your Squads account, and ~0.0018 SOL in network rent for account deployment.\n-\nUpon creation, you'll be directed to the \"Treasury\" tab. For guidance on navigating your Squads dashboard, please refer to the Dashboard section .\nTreasury tab\nPrevious Quickstart Guide\nNext On and Off-Ramp\nLast updated 1 year ago"}
{"url":"https://docs.orca.so/create/listings/token-list","domain":"docs.orca.so","title":"Orca Token List - Orca Documentation","hash":"35b413f46c63aa138bcd1318fdc460c3d1963efb5f81a389498ca145163a47bb","tokens":1727,"chars":6905,"crawler":"crawler-f6nn","verified":"exact","ts":1791172354632,"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\nListings\nOrca Token List\nLearn how token display information may be reviewed for the Orca interface.\nThe Orca Token List helps Orca display token information in the interface, such as token names, symbols, and logos.\nToken list inclusion is reviewed by Orca. Listing is not an endorsement of a token, project, team, or community, and does not guarantee trading activity, liquidity, route availability, or how a token appears on third-party platforms.\nTokens that are not included on the Orca Token List may display with a warning triangle in the Orca interface to alert users that the token is not listed.\nWhy submit token information?\nArea What listing may affect\nToken display The token may display with its name, symbol, and logo instead of only its mint address\nSearch display Users may be able to search for the token by name or symbol in Orca\nInterface clarity Consistent metadata can make it easier for users to identify the token they intend to interact with\nWarning display Listed tokens may no longer display the warning triangle associated with non-included tokens\nReview requirements\nBefore submitting token information for review, prepare the following:\nToken and pool information\n- Active Orca pool — The token should have an existing pool on Orca\n- Available liquidity — The pool should have liquidity available for trading\n- Valid token metadata — Name, symbol, decimals, and logo should be configured correctly\n- Working logo URL — The logo should be accessible over HTTPS\nToken metadata standards\nField Requirements\nName Clear, non-misleading token name\nSymbol Clear, non-misleading ticker symbol\nLogo Square image, preferably PNG or SVG\nDecimals Correctly configured token decimals\nTokens may be declined\nOrca may decline or remove token list entries for reasons including, but not limited to:\n- Impersonating another project, token, or brand\n- Misleading names, symbols, or logos\n- Broken, inaccessible, or inappropriate logo links\n- Association with scams, rug pulls, or malicious activity\n- Intellectual property concerns\n- Incomplete, inaccurate, or unverifiable submission information\nHow to submit\nOption 1: During pool creation\nWhen creating a new pool through Orca:\n- Complete the pool creation process.\n- If prompted, submit token metadata.\n- Fill in the requested information.\n- Submit the information for review.\nOption 2: For existing pools\nIf your token already has a pool but does not display with full token information in Orca:\nStep 1: Prepare your information\nGather the following:\n- Token mint address\n- Token name and symbol\n- Logo URL\n- Pool address on Orca\n- Project website, if available\n- Social links, if available\n- Brief project description\nStep 2: Submit a request\nSubmit your request through one of these channels:\n- Support Ticket — Use the Support function in the Orca app wallet menu\n- Community — Reach out on Discord or Telegram\n- Direct Contact — If you already have an existing communication channel with the Orca team\nStep 3: Include required details\nToken Name: [Your Token Name]\nToken Symbol: [SYMBOL]\nMint Address: [Solana address]\nPool Address: [Orca pool address]\nLogo URL: [https://...]\nWebsite: [https://...]\nTwitter/X: [@handle]\nDiscord: [invite link]\nBrief Description: [1-2 sentences about your project]\nStep 4: Wait for review\nThe Orca team will review your submission. Review timing may vary based on submission completeness, review queue, and any follow-up information required.\nYou may be contacted for additional information. You will be notified of the review outcome when review is complete.\nAfter review\nIf your token is listed\nIf your token is added to the Orca Token List:\n- Go to orca.so .\n- Search for your token by name, symbol, or mint address.\n- Check that the token name, symbol, and logo display as expected.\n- Check whether the warning triangle is no longer shown for the token.\nUpdating token information\nIf token information needs to be updated after listing:\n- Submit a new request through the same channels.\n- Specify what needs to be updated.\n- Provide the updated information, such as a new logo URL or corrected metadata.\nExternal platforms\nToken list inclusion on Orca does not determine whether a token is listed, verified, or displayed on external platforms. Each third-party platform manages its own review process and criteria.\nCoinGecko\nCoinGecko manages its own asset listing process and criteria.\nSee How to list a new asset with CoinGecko .\nJupiter\nJupiter manages its own token verification and display process.\nSee How to verify your token on Jupiter .\nFrequently Asked Questions\nHow long does listing take?\nReview timing may vary based on submission completeness, review queue, and whether additional information is required.\nIs there a fee for listing?\nThere is no fee for standard Orca Token List review submissions.\nMy token was declined. What can I do?\nReview the reason provided, address any issues, and submit a new request if appropriate.\nCommon issues may include:\n- Missing or broken logo URL\n- Incomplete token or pool information\n- Misleading token name, symbol, or logo\n- Unverifiable project information\n- Policy or safety concerns\nCan I submit multiple tokens?\nYes. Submit a separate request for each token.\nDo I need to be listed to create a pool?\nNo. Token list inclusion is not required to create a pool. Anyone can create a pool for a valid SPL token.\nWhy does my token show a warning triangle in Orca?\nTokens that are not included on the Orca Token List may display with a warning triangle in the Orca interface.\nThe warning triangle alerts users that the token is not included on the Orca Token List. It does not necessarily mean the token is malicious, but users should review token details carefully before interacting with it.\nMy logo is not showing correctly. What should I do?\nCheck that:\n- The logo URL is accessible over HTTPS\n- The image is square\n- The file format is supported\n- The image is high enough resolution to display clearly\nBefore submitting\nBefore submitting token information for review:\n- Check that your Orca pool exists.\n- Verify the token mint address.\n- Confirm that token name, symbol, and decimals are correct.\n- Test that the logo URL loads correctly.\n- Make sure the submitted information is accurate and up to date.\nRelated Resources\n- Creating a Splash Pool - Launch pools for new tokens\n- Creating a CLMM Pool - Advanced pool creation\n- Adding Rewards - Incentivize liquidity providers\n- CoinGecko Listing - External listing guide\n- Jupiter Verification - External verification guide\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.polkadot.com/apps/concepts/","domain":"docs.polkadot.com","title":"Concepts | Polkadot Developer Docs","hash":"75ff0f3a87f5407123ba58e95f4f88535eb7f3ff200faebae05eb73338bfc115","tokens":555,"chars":2218,"crawler":"crawler-f6nn","verified":"exact","ts":1791172357004,"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\nConcepts ¶\nView page in Markdown\nDownload page in Markdown\nOpen in ChatGPT\nOpen in Claude\nThe Build guides and Deploy Your App walk you through tasks. This section explains the ideas underneath them.\n-\nLearn Identity\nThe per-app account and Proof of Personhood as a user's two identities, and why your Product's own .dot address is not one of them.\nIdentity\n-\nLearn Accounts and Signing\nWhich component holds which account — phone, Host, and CLI — and why an allowance can land on the wrong one.\nAccounts and Signing\n-\nLearn Allowances and Permissions\nWhat the grants your Product requests authorize, their scope and lifetime, and how re-approval works.\nAllowances and Permissions\n-\nLearn Where to Store Data\nA decision guide across contract storage, cloud storage, the statement store, and local storage.\nWhere to Store Data\n-\nLearn Networks\nPaseo Next v2 and the devnet: how they relate and the differences that affect your app.\nNetworks\nLast update: September 18, 2026\n| Created: September 2, 2026"}
{"url":"https://bitcoinops.org/cs/newsletters/2026/02/13/","domain":"bitcoinops.org","title":"Zpravodaj „Bitcoin Optech” č. 392 | Bitcoin Optech","hash":"bc3d5a3f10f05d83454ce71878e3eb4cbfb37999e660e6d4bf3f976f229c1c2d","tokens":2438,"chars":9750,"crawler":"crawler-f6nn","verified":"exact","ts":1791172359360,"text":"en\n| ja\n| es\n| cs\n| hi\n| zh\n| de\n| fr\n| pt\n/ home / newsletters /\nZpravodaj „Bitcoin Optech” č. 392\nFeb 13, 2026\nZpravodaj tento týden shrnuje diskuzi o zlepšení situace s nejhorší možnou\nefektivitou skenování tichých plateb a popisuje myšlenku na možnost stanovit\nmnoho podmínek utrácení v jediném klíči. Též nechybí naše pravidelné rubriky\ns oznámeními nových vydání a popisem významných změn v populárním\nbitcoinovém páteřním software.\nNovinky\n-\n● Návrh na omezení počtu příjemců tichých plateb ve skupině : Sebastian\nFalbesoner zaslal do emailové skupiny Bitcoin-Dev příspěvek\no objevení a opatření před teoretickým útokem na příjemce tichých plateb . Útok nastává, když protivník zkonstruuje transakci s velkým\npočtem taprootových výstupů (dle aktuálních pravidel konsenzu je maximální\npočet výstupů v bloku 23 255), které všechny cílí na stejnou entitu.\nKdyby neexistovalo žádné omezení na velikost skupiny, trvalo by ji zpracovat\nněkolik minut namísto desítek sekund.\nTo vedlo k přidání nového parametru K_max , který omezuje počet příjemců\nna skupinu v rámci jediné transakce. Teoreticky by tato změna nebyla\nzpětně kompatibilní, ale v praxi by žádná peněženka podporující tiché platby\nneměla být ovlivněna pro dostatečně vysoký K_max . Falbesoner navrhuje K_max=1000 .\nFalbesoner žádá o zpětnou vazbu k navrženému omezení. Dále poznamenává,\nže kontaktoval vývojáře většiny peněženek a jsou tedy s problémem seznámeni.\n-\n● BLISK, logika booleovských obvodů integrovaná do jediného klíče : Oleksandr\nKurbatov zaslal do fóra Delving Bitcoin příspěvek o BLISKu,\nprotokolu navrženém na vyjádření komplexních autorizačních pravidel pomocí\nbooleovské logiky. BLISK (Boolean circuit Logic Integrated into the Single Key)\nmá za cíl vyřešit omezení existujících pravidel utrácení. Na příklad protokoly\njako MuSig2 , ač efektivní a zachovávající soukromí, jsou schopné\nvyjádřit kardinalitu ( k z n ), avšak neumí určit, „kdo” může utrácet.\nBLISK vytváří jednoduché AND/OR booleovské obvody a mapuje logická hradla na\nznámé kryptografické techniky. Konkrétně: AND hradla vznikají aplikací\nn z n vícenásobného podpisu, kde každý účastník musí přispět validním\npodpisem. Na druhou stranu, OR hradla vznikají použitím protokolu výměny\nklíčů, jako je ECDH , kde kterýkoliv účastník může odvodit\nsdílený tajný kód použitím svého soukromého klíče a veřejného klíče kteréhokoliv\nz ostatních účastníků. Dále také využívá neinteraktivního dokladu s nulovou\nznalostí , aby umožnil ověřit výsledek obvodu a tím zabránil podvodům.\nVýsledkem řešení obvodu BLISKu je jediný klíč pro ověřování podpisu. Díky tomu\nje potřeba ověřit jen jeden Schnorrův podpis oproti\njednomu veřejnému klíči.\nDalší výhodou BLISKu oproti jiným přístupům je odstranění nutnosti generovat\nčerstvý klíč, jelikož umožňuje připojit existující klíč ke konkrétní instanci\npodpisu.\nKurbatov poskytl pro tento protokol ověřovací implementaci , i když\nuvedl, že zatím nedosáhla produkční kvality.\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● Bitcoin Core 29.3 je údržbovým vydáním předchozí hlavní verze, které\npřináší opravu několika chyb v migrování peněženek (viz zpravodaj\nč. 387 ), přidává vyrovnávací paměť mezistavu sighashe vstupů\n(snižuje dopady kvadratického algoritmu v zastaralých skriptech, viz\nzpravodaj č. 367 , angl. ) a odstraňuje systém hodnocení\nšpatného chování peer spojení za nevalidní transakce (viz zpravodaj\nč. 367 , angl. ). Poznámky k vydání\nobsahují další podrobnosti.\n-\n● LDK 0.2.2 je údržbovým vydáním této knihovny pro budování aplikací\ns podporou LN. Mění příznak podpory splicingu na produkční\nfeature bit (63), opravuje chybu, která mohla po restartování způsobit\nzamrznutí databázových asynchronních operací ChannelMonitorUpdate ,\ncož vedlo k vynucenému zavření kanálu, a opravuje chybu debug assertu,\nkterá se objevila po přijetí nevalidní splicingové zprávy.\n-\n● HWI 3.2.0 je vydáním tohoto balíčku poskytujícího jednotné rozhraní\nk několika hardwarovým podpisovým zařízením. Nové vydání přidává podporu\npro zařízení Jade Plus a BitBox02 Nova a podporu pro MuSig2 PSBT pole dle specifikace v BIP373 .\n-\n● Bitcoin Inquisition 29.2 je vydáním tohoto signetového\nplného uzlu určeného pro experimentování s návrhy soft forků a jinými\nvýznamnými změnami protokolu. Je založeno na Bitcoin Core 29.3r2, implementuje\nnávrh BIP54 ( pročištění konsenzu ) a deaktivuje\ntestnet4 .\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 ,\nLightning BLIPs , Bitcoin Inquisition a repozitáři BINANA .\n-\n● Bitcoin Core #32420 přestává v Mining IPC rozhraní (viz\nzpravodaj č. 310 ) přidávat do scriptSig mincetvorné\ntransakce falešný extraNonce . Do CreateNewBlock() přidává novou volbu\ninclude_dummy_extranonce a IPC ji nastavuje na false . Klienty\nStratum v2 obdrží v scriptSig pouze výšku,\njak konsenzus dle BIP34 požaduje, a nemusí tato extra data odstraňovat\nnebo ignorovat.\n-\n● Core Lightning #8772 odstraňuje podporu zastaralého formátu onion\nplateb. I když CLN přestal staré onion používat v roce 2022 (viz\nzpravodaj č. 193 , angl. ), přidal ve verzi 24.05\npřekladovou vrstvu, která se starala o několik zbývajících zastaralých\nonion zpráv produkovaných staršími LND. Ty nejsou od LND verze\n0.18.3 vytvářeny, podpora již proto není potřebná. Tento zastaralý\nformát byl z BOLT specifikace odstraněn v roce 2022 (viz zpravodaj\nč. 220 , angl. ).\n-\n● LND #10507 přidává do odpovědi na RPC volání GetInfo příznak wallet_synced ,\nkterý určuje, zda peněženka dokončila synchronizaci s aktuálním vrcholem\nřetězce. Na rozdíl od stávajícího příznaku synced_to_chain toto nové pole\nnevyžaduje, aby router grafu kanálů (který validuje oznámení kanálů ), ani blockbeat dispatcher (podsystém, který koordinuje\nudálosti bloků) synchronizaci již dokončily.\n-\n● LDK #4387 mění příznak podpory splicingu z provizorního\nfeature bitu 155 na produkční bit 63. LDK verze 0.2 používala bit 155,\nkterý používá též Eclair pro vlastní implementaci splicingu ve Phoenixu,\nkterá předchází současný návrh specifikace a není s ní v souladu.\nKvůli tomu se Eclair uzly snažily provádět splicing pomocí vlastního\nprotokolu, což vedlo s LDK uzly k chybám deserializace a odpojování.\n-\n● LDK #4355 přidává asynchronní podepisování commitmentů u interaktivně\notevíraných transakcí. Děje se tak během splicingu i\noboustranně financovaných kanálů. Po obdržení\nEcdsaChannelSigner::sign_counterparty_commitment asynchronní podepisující\nobjekt okamžitě vrátí a ozve se přes callback ChannelManager::signer_unblocked ,\nkdyž je podpis hotov. Oboustranně financované kanály vyžadují pro plnou\npodporu asynchronního podepisování další práci.\n-\n● LDK #4354 mění výchozí hodnotu volby negotiate_anchors_zero_fee_htlc_tx\nna true , čímž budou standardně vytvářeny kanály s anchor výstupy . Automatické přijímání kanálů bylo odstraněno,\nvšechny příchozí žádosti o kanál tak musí být schválené manuálně.\nTo zajistí, že peněženka má v případě vynuceného zavření kanálu dostatek\nonchain prostředků na pokrytí poplatků.\n-\n● LDK #4303 opravuje dvě chyby, které mohly způsobit dvojité přeposlání\nHTLC po restartu ChannelManager : poprvé, když bylo odchozí\nHTLC stále v interní frontě, ale nedošlo na něj, a podruhé, když bylo již\npřeposláno, urovnáno a odstraněno z odchozí fronty, ale příchozí\ninterní fronta pro něj stále měla urovnání. PR dále odstraní příchozí\nHTLC onion zprávy poté, co jsou definitivně přeposlané.\n-\n● HWI #784 přidává do PSBT podporu pro serializaci a\ndeserializaci MuSig2 polí včetně veřejných klíčů\núčastníků, veřejných noncí a částečných podpisů dle specifikace\nv BIP327 .\n-\n● BIPs #2092 přiřazuje zprávě\nfeature jednobajtové ID pro použití s v2 P2P transport protokolem a BIP434 . Do BIP324 přidává nový\nsoubor zaznamenávající přiřazená ID napříč BIPy, který by měl\nvývojářům pomoci vyvarovat se konfliktů. Soubor též zaznamenává\nnavrhovaná přiřazení pro Utreexo .\n-\n● BIPs #2004 přidává BIP89 pro Chain Code Delegation (viz\nzpravodaj č. 364 , angl. ), mechanismus pro společnou\nsprávu prostředků (collaborative custody), kde delegující nesdělí\ndelegovanému BIP32 chain code, avšak sdílí s ním pouze informace\nnutné pro podepsání; tyto informace nejsou dostatečné pro sledování\nostatních adres.\n-\n● BIPs #2017 přidává BIP110 , který specifikuje dočasný soft fork\npro redukci dat (Reduced Data Temporary Softfork, RDTS). Tento návrh\nmá za cíl dočasně, na zhruba jeden rok, konsenzem omezit části\ntransakcí sloužících pro přenos libovolných dat. Pravidla by\nzneplatnila scriptPubKey překračující 34 bajtů (kromě OP_RETURN\ns maximálně 83 bajty), pushdata a položky v zásobníku witnessů\npřekračující 256 bajtů, utrácení nedefinovaných witness verzí,\npřílohy taprootu , kontrolní bloky překračující\n257 bajtů, opkódy OP_SUCCESS a OP_IF / OP_NOTIF\nv tapscriptech . Vstupy utrácející UTXO\nvytvořená před aktivací mají výjimku. Aktivace používá modifikovaný\nBIP9 se sníženým 55% prahem signalizace těžařů a povinnou\nfixací zhruba před zářím 2026. Viz též zpravodaj č. 379\n( angl. ), který tento návrh již dříve popisoval.\n-\n● Bitcoin Inquisition #99 přidává na signet\nimplementaci BIP54 , soft forku pročištění konsenzu .\nImplementuje čtyři opatření: omezuje počet potenciálně spuštěných\nzastaralých operací nad podpisy (sigops) za každou transakci,\nzabraňuje útokům ohýbáním času (timewarp attacks) pomocí dvouhodinového\npřechodného období (společně s nemožností negativních intervalů\núpravy složitosti), vyžaduje nastavení časového zámku mincetvorné\ntransakce na výšku bloku a zneplatňuje 64bajtové transakce."}
{"url":"https://docs.pyth.network/entropy/protocol-design","domain":"docs.pyth.network","title":"Protocol Design | Pyth Developer Hub","hash":"92a38283efe1c7c956e2681868830ecf62a75ab19d662231608b4d56ffcb4c84","tokens":1016,"chars":4061,"crawler":"crawler-f6nn","verified":"exact","ts":1791172361665,"text":"Try the Entropy Explorer to track and debug callback issues. | Learn what's new in Entropy v2.\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\nProtocol Design\nUnderstanding how Pyth Entropy generates secure random numbers\nThe Entropy protocol implements a secure 2-party random number generation procedure. The protocol\nis an extension of a simple commit/reveal protocol. The original version has the following steps:\n- Two parties A and B each randomly sample secret contributions to the random number, ( x A ) and ( x B ) .\n- A commits to their number by sharing ( h A ) = ha s h ( x A ) .\n- B reveals x B\n- A reveals x A\n- B verifies that ha s h ( x A ) == h A\n- The random number r = ha s h ( x A , x B )\nThis protocol has the property that the result is random as long as either A or B are honest.\nHonesty means that (1) they draw their value at random, and (2) for A, they keep ( x A ) a secret until\nstep 4. Thus, neither party needs to trust the other -- as long as they are themselves honest, they can\nensure that the result ( r ) is random.\nEntropy implements a version of this protocol that is optimized for on-chain usage. The\nkey difference is that one of the participants (the provider) commits to a sequence of random numbers\nup-front using a hash chain. Users of the protocol then simply grab the next random number in the sequence.\nSetup : The provider P computes a sequence of N random numbers, x i for 0 ≤ i ≤ N − 1 :\n- x N − 1 = r an d o m ( )\n- x i = ha s h ( x i + 1 )\nThe provider commits to x 0 by posting it to the Entropy contract.\nEach random number in the sequence can then be verified against the previous one in the sequence by hashing it, i.e., ha s h ( x i ) = x i − 1\nRequest : To produce a random number, the following steps occur.\n- The user randomly samples their contribution ( x U ) and submits it to the contract.\n(Users may also run this step using an on-chain PRNG if they trust the validator to not collude with the provider.)\n- The contract remembers ( x U ) and assigns it an incrementing sequence number ( i ) , representing which\nof the provider's random numbers the user will receive.\n- After sufficient block confirmations, the provider submits a transaction to the contract revealing their contribution ( x i ) to the contract.\n- The contract verifies ha s h ( x i ) == x i − 1 to prove that ( x i ) is the ( i ) 'th random number.\nThe contract stores ( x i ) as the ( i ) 'th random number to reuse for future verifications.\n- If the condition above is satisfied, the random number ( r ) = ha s h ( x i , x U ) .\n- The contract submits a callback to the calling contract with the random number ( r ) .\nThis flow is secure as long as several trust assumptions hold:\n- Providers are trusted to reveal their random number ( x i ) regardless of what the final result ( r ) is. Providers can compute ( r ) off-chain before they reveal ( x i ) , which permits a censorship attack.\n- Providers are trusted not to front-run user transactions (via the mempool or colluding with the validator). Providers who observe user transactions can manipulate the result by inserting additional reuests or rotating their commitment.\n- Providers are trusted not to keep their hash chain a secret. Anyone with the hash chain can predict the result of a randomness request before it is requested,\nand therefore manipulate the result. This applies both to users of the protocol as well as blockchain validators who can use this information to manipulate the on-chain PRNG or reorder user transactions.\nThe code of default deployed provider can be found here .\nError Codes\nOn chain error codes from the Pyth Entropy EVM contracts\nFees\nUnderstanding Pyth Entropy fee structure"}
{"url":"https://bitcoin.org/en/spend-bitcoin","domain":"bitcoin.org","title":"Spending Bitcoin - Bitcoin","hash":"22cd4d82f2bf7760a85e005c32d131d8787cb66308a78bc4fe8ffc761f1f81e8","tokens":1009,"chars":4035,"crawler":"crawler-f6nn","verified":"exact","ts":1791172363880,"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\nSpending Bitcoin\nFind local businesses\nMany local businesses, like cafes, restaurants, and shops, accept Bitcoin. You can use btcmap.org , an open-source map built on open data, to browse thousands of them across the globe. Many in-person payments are made over the Lightning Network, a payment layer built on top of Bitcoin that makes payments instant and keeps fees low. Acceptance now reaches national chains: Steak 'n Shake , for example, takes Lightning payments at its restaurants across the United States.\nShop online\nA growing number of online stores accept Bitcoin at checkout, often through a payment processor. Look for a Bitcoin or Lightning payment option when paying: you scan a QR code or open a payment link with your wallet, and the store gets paid. For independent stores that accept Bitcoin directly, Galaxy Mind maintains a directory of manually verified stores and shows when each listing was last confirmed.\nBuy gift cards\nWhere direct payment isn't available, gift cards can bridge the gap. Several services sell gift cards for major retailers, restaurants, and travel in exchange for bitcoin. One example is Bitrefill , a Bitcoin-native service selling gift cards, mobile top-ups, and other prepaid products. Availability varies by region.\nSupport a cause\nMany nonprofits, charities, and open-source projects around the world accept bitcoin donations, which work across borders without intermediaries. Examples include the Hal Finney ALS/MND Research Fund , created in memory of the recipient of the first bitcoin transaction, and OpenSats and the Human Rights Foundation , both funding open-source Bitcoin development.\nAccept Bitcoin at your business\nIf you run a business, accepting Bitcoin lets you reach customers who are looking for places to spend it. Square , a mainstream point-of-sale provider, lets sellers in the United States accept Bitcoin payments over the Lightning Network. Learn how on the Bitcoin for Businesses page. Once you accept it, you can add your business to the map.\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/chain-operators/launch-paths","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"87d64539a195737150d9c03c3de2da3f074c7d067a735c566d56f918b7c4a4db","tokens":2322,"chars":9285,"crawler":"crawler-f6nn","verified":"exact","ts":1791172366034,"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\nChoose how to run your chain\nThe spectrum between running an OP Stack chain yourself and having it operated for you, and what your team owns at each point on it.\nEvery team launching an OP Stack chain lands somewhere on the same spectrum. At\none end, your team runs every service and holds every key. At the other end,\nsomeone runs them for you. The choice is not about capability: it is about which\nparts of a standing operation your team wants to own.\nThis page describes the spectrum and what falls to your team at each point on\nit. It does not pick a point for you. The pages linked below document the whole\nsystem regardless of who operates it.\nThe spectrum\nRun it yourself Run it with engineering support Have it operated for you\nSequencer cluster Your team Your team, with OP Labs engineering behind it OP Enterprise\nFault-proof defense Your team Your team, with OP Labs engineering behind it OP Enterprise\nUpgrade execution Your team Your team, with OP Labs engineering behind it OP Enterprise\nIncident response Your team Your team, with OP Labs engineering behind it OP Enterprise\nThese docs The reference for what you run The reference for what you run The reference for what runs on your behalf\nRun it yourself\nYour team runs every service, holds every key, and owns every incident. These\ndocs cover all of it, and every destination below is one click away.\nWhat that ownership includes, stated the way the docs themselves state it:\nThe services you run\n- The sequencer. A single sequencer is a single point of failure for the\nwhole chain: when it stops, no new unsafe blocks exist for anyone. The\nhigh-availability answer is a sequencer cluster managed by\nop-conductor , with its nodes in\nseparate failure domains. The design is not Byzantine fault tolerant: it\nassumes every node in the cluster is honest and operated by you, so it\nprotects against crashes and partitions, not against a malicious cluster\nmember. See\nthe launch guide’s sequencer topology step .\n- The defense. The defense is a service you run and a set of decisions\nyour team staffs. The\nop-challenger is a service that\nmonitors every game, defends valid proposals, challenges invalid ones,\nresolves games, and claims bonds. Starting it is not the whole job. Every\nclaim it posts carries a bond sent as transaction value; correct claims are\nrefunded, incorrect ones pay the counter-claimer, and bonds from won games\npay out only after a delay, so capital stays locked while games resolve.\nHow much the challenger’s account holds, how quickly you can top it up\nduring an active dispute, and which absolute prestate it plays with are\noperational answers your team owns; the challenger refuses to interact with\ngames whose prestate it does not have. See\nRun a fault-proof challenger .\n- The monitoring. Watching the chain is a separate set of services from\nrunning it. op-dispute-mon tracks the status of every dispute game and is\nhow you learn that your challenger is acting; monitorism carries the\nonchain security monitors, whose security-integrity group exists to check\nthat the bridges between L2 and L1 behave as expected, including the\nfaultproof withdrawal monitor that watches ProvenWithdrawals events on\nthe OptimismPortal and flags invariant violations. Your own components\nneed their metrics endpoints scraped alongside that: op-node ,\nop-batcher , op-proposer , and op-challenger each expose one. Peer\ncount belongs on that list too, because an op-node without peers cannot\nsync unsafe blocks and falls behind the sequencer. See\nChain monitoring options and\nthe important node metrics .\n- The RPC endpoints. Every service in the stack depends on RPC, and not\nonly on L1. Each sequencer’s op-node derives the chain from an L1 RPC and\nan L1 beacon endpoint, and the batcher, proposer, and challenger read and\ntransact against L1; op-challenger additionally needs an L2 archive node\n( --l2-eth-rpc ) and a rollup node with SafeDB ( --rollup-rpc ), and\nop-dispute-mon takes a rollup RPC of its own. Redundant nodes behind a\ngeneric load balancer are the wrong shape for any of them. Two nodes can be\nat the same head, but nothing holds them there, and a service whose\nconsecutive requests round-robin between them reads that divergence as\nblocks appearing and disappearing: reorgs that never happened. The\nchallenger is the least tolerant consumer and needs one trusted endpoint\nthat fails over deliberately rather than per request. See\nthe launch guide’s section on a consistent view .\nThe keys and the decisions\n- The keys. The batcher and proposer addresses need their private keys\nonline somewhere for the system to work, and if those addresses are\ncompromised, the system can be exploited. They are not the only privileged\naddresses your chain has. The Proxy Admins can upgrade most of the system\ncontracts on L1 and L2, the System Config Owner can change the values in\nthe SystemConfig contract, the Guardian can pause withdrawal logic and\ndisable dispute game types from executing withdrawals, and the permissioned\nChallenger role is a distinct address from the op-challenger service.\nWhich addresses hold which role, and how each key is held, whether through\nan HSM or a cloud key management system, are decisions the chain operator\nmakes. See\nKey management and\nPrivileged roles in OP Stack chains\nfor what every role can do and what a compromise of it means.\n- The path to permissionless proofs. Chains deployed with op-deployer\nstart with the permissioned dispute game, in which the proposer and\nchallenger are specific addresses holding privileged roles. Moving to\npermissionless fault proofs is a switch your team schedules after launch.\nSee\nthe launch guide’s permissionless-proofs step .\nThe work that recurs\n- The protocol upgrade cadence. The OP Stack is being continuously\nimproved and it’s your responsibility to keep it up to date. Network\nupgrades, deprecations, security patches, and operational changes arrive as\ntime-bound action items in Network Notices , with the permanent\nrecord of each hardfork in the\nhardfork registry , which records\nactivation times, the governing spec, and minimum component versions.\nTracking each notice, moving your components to the versions it names, and\nexecuting the change on your chain recurs for as long as the chain runs.\n- The standing work. Running current production releases, keeping the\ndeployment artifacts, staggering upgrade rollouts across your\ninfrastructure, isolating the sequencer, and writing your own runbooks are\ncontinuous tasks rather than launch-day ones. Monitoring only helps if\nsomeone is on the other end of it. Metrics endpoints on your key\ncomponents, and runbooks to execute when something is not behaving as\nexpected, are the documented practice; the alerting path, the people\nreachable through it, and the incident response itself are yours to build\nand staff. See\nChain operator best practices .\nDeploy a chain, component by component\nThe full deployment tutorial: contracts, genesis, sequencer, batcher,\nproposer, and challenger on a testnet.\nTake a chain to production\nThe launch guide: fault proofs from day one and a sequencer topology with no\nsingle point of failure, through failover drills.\nStaff the defense\nBond budgeting, prestate selection, the infrastructure the challenger\ndepends on, and how to confirm it is defending your chain.\nRun it day to day\nRelease selection, deployment artifacts, staggered rollouts, sequencer\nisolation, and runbooks.\nRun it with engineering support\nYour team still runs the chain. The difference is who sits behind the decisions\nabove and behind the incidents when they happen: OP Labs engineering does,\nalongside your operators. Everything linked in the previous section stays the\nreference for what your team is running, because it is the same system.\nOne capability on this path is not something your team has to stand up itself:\nOP Labs can optionally run a backup sequencer for your chain, alongside the\nsequencer cluster your team operates. It is opt-in rather than part of the path\nby default, and whether to take it is your team’s decision.\nHave it operated for you\nOP Enterprise runs the chain and your team consumes it. The pages above still\ndescribe what is running on your behalf, which is why they are worth reading on\nthis path too: the properties you are buying are the ones those pages document.\nWhat OP Enterprise is\nOP Enterprise is Optimism’s managed offering. It covers fully managed and\nsupported self-managed options, backed by an uptime SLA, priority incident\nresponse, direct engineering support, and managed public RPC.\nThe\nOP Enterprise\npage states what each option includes and is the source of truth for its terms.\nThis page does not restate them.\nWhere to go from here\nWhichever point on the spectrum you choose, the\nchain operator quickstart and the pages it leads\nto describe the same chain. Start there if you have not deployed one yet.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.squads.so/main/additional-resources/advanced-security-best-practices","domain":"docs.squads.so","title":"Advanced Security Best Practices | Squads Docs","hash":"5d4231b2a67f0a9b3cf3f813a257ae450ddd7111f0912a514f4f1c1ee513501d","tokens":3384,"chars":13536,"crawler":"crawler-f6nn","verified":"exact","ts":1791172369229,"text":"Squads Docs\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\nAdvanced Security Best Practices\nAdvanced best practices to safeguard your assets.\nThis guide provides comprehensive security recommendations for organizations using Squads to manage digital assets. Following these best practices will help protect your treasury and program upgrades from both external and internal threats.\nTable of Contents\n-\nGeneral Overview\n-\nCore Security Practices\n-\nTreasury Segmentation\n-\nProgram Upgrades\n-\nSquads Frontend Verification\n-\nMitigating Signer Attacks\nGeneral Overview\nAn important element of Squads' security is its transparent, sequential transaction process. This sequential structure comes from Squads Protocol's architecture, where each transaction follows a verifiable, onchain lifecycle:\n-\nInitiate: A transaction is proposed and recorded onchain. This creates both a transaction account (containing the actual transaction data to be executed) and a proposal account (for tracking approvals). Transaction details include a unique transaction ID that all members can cross-reference to ensure they're approving the same transaction.\n-\nApprove: Signers review and provide onchain signatures to approve the transaction. Each signature modifies the proposal account's state rather than changing the transaction account. This approach preserves the original transaction while tracking approval progress.\n-\nExecute: Once the multisig threshold is met (minimum required approvals), the transaction is executed onchain. The system verifies the proposal account's status before processing the unchanged transaction account.\nThis sequential, fully onchain approach creates an immutable audit trail that enables users to self-verify transactions and eliminates opportunities for manipulation between approval and execution stages. Squads never sends the same transaction to multiple signers - it only updates the proposal state with each approval.\nCore Security Practices\nSquads Multisig Configuration\n-\nHigher approval threshold: Implement a threshold of 4/6 or higher to ensure multiple signers are required for transaction approval, adding layers of security against individual compromises.\n-\nTime Locks: Enable time locks to defer execution of approved transactions for a set period. This creates a safety window to respond to potentially unauthorized transactions even after approval. Choose appropriate durations—shorter intervals (e.g. 10-15 minutes) for program upgrades that may require quick responses, longer intervals for treasury transfers where additional review time enhances security.\n-\nKey Rotation: Rotate keys that have been potentially exposed to unauthorized parties or not properly isolated from external systems.\n-\nSeparate Approval and Execution: Always approve and execute transactions in separate steps. Avoid using the \"Approve + Execute\" feature for maximum security.\n-\nDiversify signing interfaces and devices: Employ signers using both mobile and desktop with hardware wallets to enhance security through diversity.\nTransaction Verification\n-\nLive communication: Maintain live communication with other signers during transaction approval, ensuring each signer's approval has been properly registered before proceeding.\n-\nTransaction simulation and inspection: Simulate transactions and check the results using Solana Explorer Inspector to ensure expected behavior before execution.\nGuidelines on Simulating Transactions:\nWhen reviewing a simulated transaction, check the simulation details in the Explorer Inspector. This step ensures that the transaction will perform as intended before executing it. Ideally also ensure the programs your transaction is calling are known to you, as malicious programs have the ability to change execution behavior between when you simulate and when you execute.\nHere are specific elements to watch out for and how to handle them:\n-\nBPFLoaderUpgradeab1e11111111111111111111111:\n-\n\"New authority Some(XXX)\": When you see this message, it means you are changing the buffer/program authority to a different wallet. Confirm that changing the authority is your intended action, and verify that the new wallet address (XXX) is correct.\n-\n\"Upgraded program XXX\": This message indicates that program XXX is being upgraded. Review the transaction details to ensure that this upgrade is expected and intended as part of the transaction.\n-\nToken Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA):\n-\n\"Instruction: Approve\": This means that you are delegating funds to another wallet. Confirm that this delegation is intended, as any misconfiguration can lead to a loss of funds. If delegation is not intended, take immediate action to correct it.\nIn addition, double-check the tokens and amounts that will be moved by any transaction. In cases where swaps are involved, be aware that other tokens may be moved as part of the swap, but the total USD value should still align with what you intended.\nTreasury Segmentation\nWhile transaction controls like time locks protect individual transactions, treasury segmentation provides an additional layer of security at the organizational level. This strategy involves creating a \"cold\", advanced security Reserve Treasury account where your business secures the majority of your assets and one or more operations accounts for everyday use that require a lower level of security.\nReserve Treasury\n-\nContains 85-95% of your total assets\n-\nEmploys stringent security: higher thresholds, extended time locks\n-\nReserved for infrequent transactions and long-term asset storage\n-\nAdvanced key management practices (e.g. only use dedicated devices/hardware wallets) for maximum protection\nOperations Account\n-\nHolds 5-15% of funds for routine transactions\n-\nUses more accessible security: lower thresholds, accessible key management\n-\nHandles payroll, vendor payments, and daily operations\n-\nReceives periodic replenishment from the Reserve Treasury\nProgram Upgrade Account\n-\nDedicated account with specialized security for program upgrades\n-\nSeparate from both reserve and operations to isolate upgrade permissions\n-\nEmploys stringent security: higher thresholds, time locks\n-\nAdvanced key management practices (e.g. only use dedicated devices/hardware wallets) for maximum protection\nThis structure compartmentalizes risk—if your operations account is compromised, most assets remain protected in your more secure reserve treasury. Meanwhile, your team maintains the operational flexibility needed for day-to-day activities without navigating excessive security hurdles for routine transactions.\nProgram Upgrades: Double Verification and Verifiable Builds\nUnderstanding Buffer Accounts\nA buffer account is a temporary onchain storage location that holds program code before it's deployed to its final program address. This intermediary step allows for verification before execution of the upgrade.\nKey Functions:\n-\nStores the compiled program binary data onchain\n-\nEnables verification before the actual upgrade occurs\n-\nProvides a checkpoint for security review\nVerifiable Builds\nVerifiable builds ensure the integrity of program code throughout the upgrade process by generating a cryptographic hash that can be independently verified by all team members.\nImplementation Process:\n-\nBuild your program locally, generating a unique cryptographic hash\n-\nDeploy the program to a buffer account\n-\nShare the expected hash with all team members\n-\nTeam members independently verify the buffer content matches this hash\n-\nExecute the upgrade from buffer to program account\n-\nPost-upgrade, verify the deployed program hash matches the verified buffer\nThis process confirms deployed code matches the audited version, prevents unauthorized modifications, creates an audit trail through git commit references, and enables external verification of deployed programs against audit reports.\nSquads Frontend Verification\nAccounts with high-value operations - such as Reserve Treasury and Program Upgrade accounts - should ensure transaction integration and the validity of the Squads frontend using multiple interfaces.\nExplorers\nExplorers provide basic transaction verification but have limitations:\nCurrent Capabilities:\n-\nView transaction metadata, status, IDs, and associated accounts\n-\nConfirm transaction creation time\nLimitations:\n-\nLimited parsing of complex transactions and inner instructions\nWe are currently working with Solana Foundation on parsing Squads transactions in the Solana Explorer and implementing Squads transaction parsing in the Range interface.\nCLI Tools\nDirect Interaction:\n-\nUsers can interact directly with the Squads CLI for core transaction operations. The CLI enables programmatic control of Squads multisig accounts without relying on web interfaces\n-\nLinks to our CLI tools: Squads v3 CLI and Squads v4 CLI\nTransaction Verification (coming soon):\n-\nNo dedicated verification tool exists yet for Squads transactions\n-\nA comprehensive CLI tool is under development to automate transaction parsing and verification\nRun UI Locally\nThere are two lightweight backup front-ends designed for easy verification, decentralization, and security. These clients are just five files each, making them simple to hash against a commit, deploy to IPFS, or self-host—ensuring complete transparency:\n-\nDownload and run the Squads lightweight front-ends from GitHub:\n-\nv4: https://github.com/Squads-Protocol/public-v4-client\n-\nv3: https://github.com/Squads-Protocol/public-v3-client\nRange Integration (coming soon)\nRange will provide enhanced verification through automated notifications, human-readable transaction parsing, risk assessment, and detailed verification interfaces.\nCold IPFS Frontend & Onchain Verification (coming soon)\nSquads will deploy a minimalist “cold” frontend on IPFS that operates completely independent of Squads’ infrastructure, reducing dependency on Squads’ servers and web interface. This approach enhances security by removing exposure to potential Squads infrastructure compromises and dependencies on local environment security. This “cold” frontend is ideal for large-value accounts (e.g., Reserve Treasury and Program Upgrades). Additionally, builds will be hashed accordingly by release and have the hash published on Solana, IPFS, and other relevant channels. Users can then verify the authenticity of the client themselves, regardless of origin (IPFS, self-hosting, etc).\nMitigating Signer Attacks\nProtecting individual signers is fundamental to maintaining the integrity of your multisig operations. By implementing these security measures, your team can significantly strengthen your overall security:\nDedicated Hardware Security\nDedicated Devices\n-\nUse dedicated hardware wallets exclusively for Squads transactions\n-\nNever use these devices for other applications, especially for keys with initiate permissions\nDiversify Hardware Vendors\n-\nUse hardware wallets from different manufacturers (Ledger, Trezor, Keystone)\n-\nHardware diversification prevents single-vendor vulnerabilities\nInitiator Security\nTransaction initiators pose the highest security risk since they define what gets recorded onchain:\n-\nTransaction content becomes immutable once initiated\n-\nApply strictest security measures to devices used for initiation\n-\nRestrict initiation rights using Squads Permissions\nRole-Based Permissions Squads Permissions offers three distinct roles:\n-\nProposer - Can only create transactions\n-\nVoter - Can only vote on proposed transactions\n-\nExecutor - Can only execute approved transactions\nLimiting who can initiate transactions creates a critical security barrier at the most vulnerable point in the workflow.\nThe Two-Minute Rule\nThe sequential nature of Squads transactions, combined with Solana's blockhash expiration, creates a powerful security mechanism:\nWhen multiple signers need to approve a transaction:\n-\nAfter initiation, each signer should wait 2 minutes before the next person proceeds\n-\nThis waiting period allows the blockhash to expire\n-\nIf no suspicious transactions appears during this 2-minute window, the next signer can safely proceed\nWhy This Works:\n-\nSolana signatures are linked to specific blockhashes\n-\nThese blockhashes automatically expire after 2 minutes\n-\nIf your device is compromised and someone captures your signature, they only have a 2-minute window to misuse it\n-\nAfter 2 minutes, the captured signature becomes useless for malicious transactions\n-\nBecause the transaction content is fixed onchain at initiation, signers can verify they're approving the intended transaction through multiple independent sources\nDurable Nonce Exception\nThe two-minute rule depends on blockhash expiration, but durable nonces bypass this protection:\n-\nDurable nonces allow transactions to remain valid indefinitely\n-\nIf the initiator has a durable nonce account, the two-minute rule is ineffective\nTo ensure a durable nonce transaction is not involved:\n-\nVerify the initiator has no durable nonce accounts using getProgramAccounts calls\n-\nEnsure the displayed fee-payer for transactions matches the initiators public key (if your Squads Fee Relayer is turned on, then the fee-payer should be the Fee Relayer key address of which you can find in Settings)\nPrevious FAQs\nNext Costs of using Squads\nLast updated 1 year ago\n- Table of Contents\n- General Overview\n- Core Security Practices\n- Treasury Segmentation\n- Program Upgrades: Double Verification and Verifiable Builds\n- Squads Frontend Verification\n- Mitigating Signer Attacks"}
{"url":"https://governance.aave.com/t/tokenlogic-delegate-platform/12516","domain":"governance.aave.com","title":"TokenLogic Delegate Platform - Delegate Platforms - Aave","hash":"5fa2333ce76db7deeaa6e61f4be912c641d3089eb54bf2895db2e655c8acf1aa","tokens":9967,"chars":39865,"crawler":"crawler-f6nn","verified":"exact","ts":1791172375082,"text":"Aave\nTokenLogic Delegate Platform\nDelegate Platforms\nTokenLogic\nMarch 29, 2023, 1:42pm\n1\nScreenshot 2024-05-19 at 15.00.13 1777×893 124 KB\nHi Aave Community\nWe are excited to announce that TokenLogic is creating a delegate platform to compliment our ongoing contributions to Aave. Members of our team have been contributing to Aave since 2021 and the “TokenLogic Delegate Platform” represents our active contributions to Aave’s governance\nTokenLogic is a newly formed independent voting delegate focused on supporting the growth and adoption of decentralisation communities through governance participation.\nKey Details\nDelegate Address: 0x2cc1ADE245020FC5AAE66Ad443e1F66e01c54Df1\nTelegram: @Matthew_Graham\nDiscord: Matthew_Graham#9177\nTwitter: Token_Logic\nTwitter: Matthew\nExternal Website: www.tokenlogic.xyz\nDedicated Email: aave@tokenlogic.com.au\nLegacy Voting Record: Boardroom\nNew Delegation Boardroom\nIntroduction\nScreenshot 2024-04-08 at 19.38.21 1561×580 109 KB\nI am thrilled to announce that Aave is to become the primary delegation platform for TokenLogic. As the founder, @MatthewGraham , I have been actively contributing to Aave since May 2021 . I led the Aave team at Llama from receipt of the first grant in mid-2021 and by late 2022, Llama transitioned into a service provider where I am currently managing the Llama <> Aave program.\nTokenLogic will act purely independent and will cast all votes with Aave’s best interest front of mind and without outside influence. As a delegate, TokenLogic commits to dedicating time and resources to supporting Aave’s development and growth whilst maintaining complete independence from Llama’s voting process. We are actively scoping out our front end where we intend to provide details about TokenLogic and our voting history within the Aave ecosystem.\nWhy TokenLogic\nAt TokenLogic we believe in helping communities grow and develop progressive governance ecosystems. Our delegate platform is intended to serve as an independent voting voice within the thriving Aave ecosystem.\nAs the Aave ecosystem grows and matures, the protocol benefits from delegation diversity with independent visions and value propositions.\nMembers of TokenLogic are deeply integrated into the Aave ecosystem. The below highlights some of their ongoing contributions to the Aave ecosystem:\n- Aave Guardian\n- Finance Service Provider\n- Analytics Platform\n- GHO’s Growth\nValues\nAt TokenLogic we believe in being open, building trust through collaboration and realising possibilities together as a team.\nOur values are at the centre of everything we do. They shape how we act with each other, our partners and help us to achieve our vision of helping communities realise their full potential.\nOur foundational beliefs, reflect our values:\n- Transparency/Openness. We believe in open lines of communication and transparency. We share our knowledge and embrace diversity of thought.\n- Trust. We partner constructively and develop close working relationships. We actively listen to the community’s feedback and support compromise to foster solutions in effort to help the community realise its fullest potential.\n- Integrity. We act honestly and ethically in all dealings. We reinforce a culture of doing what is right.\n- Collaboration. We believe in achieving together and building trust as we strive to deliver the best in all that we do.\n- Entrepreneurial Spirit. We adopt an ‘owner mindset’. We identify opportunities and we take the initiative to pursue new and innovative ways of delivering value.\nFocus Areas\nThe following are areas of interest where TokenLogic seeks to focus its efforts:\n- GHO Adoption. Accelerating the transition from a safe/guarded launch to achieving escape velocity via the widespread adoption of GHO across DeFi.\n- Revenue Growth. Growth avenues expected to attract new users, protocol revenue and tailoring of risk parameters supportive of those building on top of Aave Protocol.\n- Live Financial Reporting. Expansion of financial data across Aave, such as live financial statements, bad debt dashboards, service provider funding contracts v Aave budgets and asset holding performance over time\n- Aave v3 Features. Initiatives that introduce and extend the v3 design features of Aave Protocol, such as portals, facilitator roles and meta-governance.\nThe Team\nThe TokenLogic team, led by Matthew, consists of the following contributors.\n-\nMatthew ( @MatthewGraham on the forum, Matthew_Graham_ on Twitter). Mechanical Engineer with 12+ years of industry experience, bachelor degrees in Mechanical Engineering, Investment Finance and Corporate Finance. Published numerous ARCs with a good understanding of DeFi legos, risks, governance, value flow (tokenomics) and fund management.\n-\nFermin ( @efecarranza on the forum, efecarranza on Twitter). A Software Engineer with 8+ years of experience, working extensively with smart contracts. First at ConsenSys where he developed the underlying contracts for the Infura NFT SDK. Later as a Lead Solidity Developer at Llama supporting Aave DAO. Fermin developed the Aave Swap and Strategic Asset Manager contract, both are used frequently.\n-\nJoaquin ( @JoFa on the forum, Jo__Fa on Twitter). Full-stack Software Engineer with 5+ years of experience, previously leading development teams on TradFi and AI-driven real-estate projects. Now a Solidity developer working with smart contracts and leading TokenLogic’s automation initiatives. Joaquin has proven adaptability, attention to detail, and drive—delivering consistent, high-quality execution.\n-\nSerena ( @notnotsez on the forum, notnotsezpoo on Twitter). Data Scientist with a Bachelor’s degree in Data Science and Decisions (UNSW), certified AWS Solutions Architect and Google Cloud Professional Data Engineer. She has experience across the asset management industry and tech consulting, with strong expertise in modern data platforms including AWS, GCP, Snowflake, dbt, SQLMesh and Dagster, specialising in SQL, Python and JavaScript/TypeScript. Serena focuses on building scalable infrastructure and analytics pipelines to enhance Aave’s financial reporting, risk monitoring and governance transparency.\n-\nScott ( @scottincrypto on the forum, scottincrypto on Twitter). Data Scientist with Bachelor degrees in Mathematics & Electrical Engineering. Scott loves digging into the intricacies and subtleties of novel dApps and innovative protocols and building detailed analytic dashboards showcasing how the protocol/product is performing. Scott led the development of Llama’s backend data analytics platform and built v1 and v2 of Aave DAO financial reporting, treasury, Safety Module and preliminary risk analysis dashboards.\n-\nMak ( @agentMAK on the forum, agentMAK_ on Twitter). A Full-Stack developer with a Computer Science degree and extensive experience in TradFi payment systems. At Index Coop, MAK built dashboards and tools to monitor the protocol’s performance and product liquidity. Previously Mak has contributed to CitaDAO’s RAW on-chain application where he enhanced the UI/UX. With a deep understanding of Web3 and keen eye for detail, Mak has proven instrumental in creating and upgrading protocols.\nThe team is continually growing and we are always on the look out for DeFi Strategists and skilled Developers.\nIf you are interested in joining the team, check out our Careers Page .\nConflicts of Interest\nIf any potential conflicts of interest are to arise, these will be disclosed among various stakeholders within the Aave ecosystem and when it is appropriate, our team members will either abstain or at the very least openly communicate the potential for a conflict of interest to arise.\nDelegation\nIf anyone would like to delegate to TokenLogic, please use the following address:\n0x2cc1ADE245020FC5AAE66Ad443e1F66e01c54Df1\nDelegate Platform: https://delegate.tokenlogic.xyz\nCopyright\nCopyright and related rights waived via CC0 .\n19 Likes\n[TEMP CHECK] - Incentivized Delegate Campaign (3-month)\n[TEMP CHECK] GHO Liquidity Pools\n[ARFC] Reserve Factor Updates - Polygon Aave v2\n[ARFC] Safety Module - Reduce Emissions\n[TEMP CHECK] TokenLogic Proposal\n[GHO Stewards] October 2026 - GHO Borrow Rate Update\n[Risk Stewards] August 2026 - WETH Interest Rate Adjustment\n[GHO Stewards] August 2026 - GHO Borrow Rate and Aave Savings Rate Update\n[ARFC] Launch remoteGSM on Arbitrum\n[Direct-to-AIP] March 2026 - Funding Update\n[Direct-to-AIP] Onboard PT-USDG-25FEB2027 on X Layer\n[ARFC] SVR Expansion: Next Phase of Multi-Network Expansion\n[ARFC] Buyback Program - Budget Adjustment\n[ARFC] rsETH Incident Funding Update\n[ARFC] Update Signers and SAFE Configuration March 2026\n[Direct-to-AIP] Increase GHO GSM Capacity on Plasma\n[ARFC] sGHO Launch Configuration\n[ARFC] Governance Framework v2\n[ARFC] Deploy Aave Protocol v3.7 on Monad\n[Direct To AIP] wstETH CAPO Oracle Incident User Reimbursement\n[Direct-to-AIP] May/June 2026 - Funding Update\n[Direct-to-AIP] April 2026 - Funding Update\nRemoteGSM Upgrade: Enabling L2 GSMs for GHO\n[ARFC] Launch sGHO Cross-Chain\n[ARFC] stkAAVE Emissions Update\n[TEMP CHECK] Deploy Aave Protocol on Monad\nAave DAO Funding Insights\n[ARFC] Umbrella Parameter Update: Target Liquidity and Emission Optimization\n[ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance\n[ARFC] GHO Stewards Signer Update\n[ARFC] June - Update Signers and SAFE Configuration\n[ARFC] Deploy Aave V4 on the Monad Network\n[Direct-to-AIP] Asset Listing - USDe X Layer\n[Risk Stewards] Reduce wETH Slope1\n[ARFC] Pause AAVE Buybacks\n[Direct-to-AIP] Asset Listing - USDC X Layer\n[Direct-to-AIP] Safety Module August 2026 - Allowance Update\n[Risk Stewards] September 2026 - WETH Interest Rate Adjustment on Base\n[Gho Stewards] September 2026 - GHO Parameter Update\n[ARFC] Umbrella on Aave v4: Coverage Framework and Initial Market Parametrization\n[Risk Stewards] Monad Stablecoin IRM Adjustments: Slope1 to 5.00%\n[Direct-to-AIP] Add X Layer Loop Tool & Margin Trading to FlashBorrowers\n[Direct-to-AIP] August/September 2026 - Funding Update\n[Direct-to-AIP] PT-USDG X Layer\n[Direct to AIP] Onboard PT-USDe-22OCT2026 to Aave V3 Monad\n[Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\nAave Labs Contributions Report\n[Direct-To-AIP] Umbrella - Renew Allowances\n[ARFC] TokenLogic Phase II - Extension\nTokenLogic\nApril 23, 2023, 4:09pm\n4\nHi Everyone\nIt was an honour to participate and finish on top of the Butter Delegation Competition . We look forward to actively contributing to the Aave ecosystem.\nTo date we have published a TEMP CHECK and ARFC proposal for the community to discuss.\n- [TEMP CHECK] Polygon v2 to v3 Liquidity Migration\n- [ARFC] Polygon v2 - Parameter Update\n- [ARFC] wMATIC Risk Parameter Update Polygon v3\n@ChaosLabs will be progressing the wMATIC proposal forward along with other risk parameter amendments on the Polygon v3 deployment. We intend to progress the Polygon v2 Parameter Update in the coming weeks. This will likely be our first AIP proposal submission for on-chain voting.\n@EzR3aL we hope over time our continued participation in Aave’s governance will demonstrate a strong track record of adding value and advancing the protocol. Please do note, TokenLogic is only a delegate, not a Service Provider, and governance publications are to be implemented with collaboration from service providers. A distinguishing feature between TokenLogic and some other delegates, TokenLogic contributors have a strong track record of contributing to Aave dating back to mid 2021.\nAs a delegate we welcome any support from the broader community and are committed to voting independently in the best interest of Aave Protocol.\nVoting History to Date\n[TEMP CHECK] - GHO Facilitator Onboarding Process and Application\nVote Cast: YAE\nHaving reviewed this proposal prior to it publication we are glad to support this much needed onboarding process definition proposal. Great work by the @oneski22 and @khan . We look forward to seeing the ARFC emerge in time.\n[ARFC] Align AAVE Risk Parameters on Aave V3 Ethereum Market with Aave V2\nVote Cast: YAE\nA solid proposal by @MarcZeller and we directly support the alignment of risk parameters such that v3 is positioned to offer the same or better user experience relative v2 deployments on the same network.\n[TEMP CHECK] Aave V3 Deployment on zkSync Era Mainnet\nVote Cast: YAE\nGreat to see @fig and the Flipside Crypto team getting more active in the Aave ecosystem. We firm support the expansion of Aave v3 deployments on emerging networks which we expect to generate material adoptions and revenue potential to the Aave DAO.\nACI Service Provider Proposal\nVote Cast: YAE\nWe are in full support of the one man band, @MarcZeller , growing a team and enhancing ACI’s contribution to the Aave ecosystem.\n[Temp Check] - Community Preference for Supply Cap Limits for LSTs\nVote Cast: YAE\nWe are comfortable with increasing Aave’s risk exposure to LST and believe the rewards for doing so outweigh the risks. The ability to redeeming, or swapping, the LST for the native network token is unique to LST.\nAave v2/v3 Collectors unification\nVote Cast: YAE\nThis AIP is a key enabler for other service providers to begin managing the Treasury on respective networks. @llama implemented a simpler change enabling v1 aTokens to be received by the v2 Collector Contract and this @bgdlabs proposals achieves the same objective in a more governance efficient, holistic and streamlined approach. This is a great proposal from the @bgdlabs team.\nUpdate AAVE V3 ETH Risk Parameters\nVote Cast: YAE\nWe are in full support of increasing the LTV of AAVE on Ethereum v3 to match the Ethereum v2 deployment.\nSupply/Borrow Cap Updates V3 Arbitrum\nVote Cast: YAE\nWe are supporting of increasing the Supply and Borrow Caps for wETH and wBTC on Arbitrum. This enables the Aave v3 deployment to continue growing without deposit cap limitations. Enabling sufficient deposit capacity is critical to encouraging builder to create structured products on Aave Protocol.\nRisk Parameter Updates Aave V3 Optimism\nVote Cast: YAE\nWe are direction aligned with this proposal and our only caution was DAI with an LT of 83% as this is starting to get high. This aside, we fully support the proposal from @ChaosLabs .\n[ARFC] Add MAI to Arbitrum Aave V3 pool\nVote Cast: YAE\nWe firmly support the inclusion of additional LST and Stable coins across all Aave Protocol deployments.\n[ARFC] Add MAI to Optimism Aave V3 pool\nVote Cast: YAE\nWe firmly support the inclusion of additional LST and Stable coins across all Aave Protocol deployments.\n4 Likes\n[TEMP CHECK] - Incentivized Delegate Campaign (3-month)\nTokenLogic\nMay 20, 2023, 4:10pm\n5\n[TEMP CHECK] Gas Fee Rebate for On-Chain Votes\nVote Cast: YAE\nWe support the reimbursement of gas costs incurred by delegates who have a material representation within Aave’s governance.\nRisk Parameter Updates for Aave V3 Polygon (2023-04-21)\nVote Cast: YAE\nWe are supportive on Gauntlet’s increase the EURS Borrow Cap on Polygon.\nUpgrade Aave V3 pools to Aave V3.0.2\nVote Cast: YAE\nGreat proposal by @bgdlabs . Also noting two mentioned audits. We are strongly in favour of this upgrade.\nIncrease SupplyCap stMATIC Polygon & wETH Arbitrum\nVote Cast: YAE\nGiven approval from risk providers was attained and our preference to grow LST exposure on Aave, we are strongly in favour of this proposal.\nAdd wstETH to Polygon Aave v3\nVote Cast: YAE\nWe are strong advocates for welcoming the growth of LSTs on Aave Protocol.\nBAL Interest Rate Upgrade\nVote Cast: YAE\nSupporting of staged increases in the BAL interest rate that gradually align the Uoptimal value with market rates whilst monitoring the markets response over time.\n[ARFC] MaticX Supply Cap Increase Polygon v3\nVote Cast: YAE\nSimilar to the above, we are supportive of LST growth on Aave Protocol provided it is conducted in a safe and controlled manner.\n[ARFC] Deprecate Aave V2 AMM Market\nVote Cast: YAE\nThis Aave deployment failed to gain meaningful traction in the market. Full support to deprecate the v2 AMM, especially given the v3 version will be coming to market post GHO launch.\n[ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Polygon - 2023.04.23\nVote Cast: YAE\nThis proposal leans into supporting further migration from v2 to v3 which is something TokenLogic is a keen supporter of.\nWAVAX Borrow Cap Update - V3 Avalanche - 04.21.2023\nVote Cast: YAE\nIncreasing the wAVAX Borrow Cap enables the yield maximising strategy to grow Aave’s TVL and wAVAX revenue.\n[ARFC] Aave V2 Interest Rate Curve Changes (2023-04-21)\nVote Cast: NAE\nWe are directionally aligned with this proposal. However, we think the wMATIC parameters are not ideal and should be reworked. We voted NAE to signal an intent to rework the proposal in line with feedback provided on the forum. However, if the community supports the lower wMATIC rates, we will vote YAE at the AIP vote and then monitor how the market responds. If the market dynamics are adversely affected, we will prepare a proposal to revert the wMATIC interest rate parameters.\n[ARFC] Polygon v2 - Parameter Update\nVote Cast: Option 2\nThis is our own proposal. We are supportive of a conservative initial implementation with the option to prepare a follow up proposal after reviewing how the market responds to the first implementation.\n[TEMP CHECK] Aave V3 GHO Genesis Parameters\nVote Cast: YAE\nWe want to see GHO come to market asap. We are supportive of this proposal and acknowledge the ability to amend parameters post launch.\nAave Metis V3\nVote Cast: YAE\nWe view this as an experiment and hope to see strong adoption without consuming many resources to maintain the deployment.\nUpgrade Aave V3 pools to Aave V3.0.2\nVote Cast: YAE\nGreat proposal by @bgdlabs . Looking forward to seeing this in production.\n[TEMP CHECK] Allocation of 300k OP Received by Aave Grants DAO\nVote Cast: YAE\nWe are looking to see AGD use these OP rewards to encourage builders on Aave Optimism v3. Using OP represents a solid alternative to AAVE tokens.\n[ARFC] Aave V3 Interest Rate Curve Changes (2023-04-27)\nVote Cast: YAE\nSolid interest rate improvements and RF adjustments.\n[ARFC] - GHO Facilitator Onboarding Process and Application\nVote Cast: YAE\nHaving review this proposal and provided feedback pre-forum. We are in support of creating a GHO Facilitator onboarding process. We seek to help communities submit applications to become a facilitator in time.\nGauntlet Recommendations for Polygon V3 and Arbitrum V3\nVote Cast: YAE\nWe would have liked to see the BAL Supply Cap increased. However, we are also supportive of increasing the EURS Supply Cap and thus voted YAE on this proposal.\n[ARFC] E-Mode Specific Supply and Borrow Caps\nVote Cast: NAE\nWe voted for no change. If we did not vote this way, our next preference was Option 2.\n[TEMP CHECK] Defining the Service Provider & Delegation Platform Relationship\nVote Cast: Option 2\nWe think Service Providers should already have the context to make informed votes and they should be active in governance. As a result, we believe Service Providers should be excluded from receiving reward for providing voting delegation platform service to the DAO. It is reasonable to expect these costs are somewhat already baked into the Service Provider agreement pricing.\n[TEMP CHECK] Safety Module Update Part I - Migrate AAVE/wETH\nVote Cast: 80/20 AAVE/wstETH\nWe are fans of capital efficiency and believe wstETH to be a low risk asset suitable for inclusion in Aave’s Safety Module. We also noted the comments from Solarcurve in the comments on this post and the overall direction of Balancer to focus on LST paired liquidity.\nMaticX Supply Cap Increase Polygon v3 and AGD Approval\nVote Cast: YAE\nWe are strongly in support of facilitating the safe growth of LST collateral and yield maximising strategies being built on Aave Polygon v3. We also support the corrective USDT payment to AGD. It is not ideal that these proposals are bundled and this should be avoided. We supported this proposal and hoped the feedback from the community would be incorporated for future proposals without creating the need to submit two votes.\nAdd MAI to Aave Optimism V3 pool\nVote Cast: YAE\nStable coin diversity is good for Aave and we are supportive of MAI’s expansion across several networks.\nUpgrade the safety module to v1.5 PART 1\nVote Cast: YAE\nGreat to see this upgrade coming to AIP with two audits from a very strong developer team. Strongly in favour of this proposal.\nAdd MAI to Aave Arbitrum V3 pool\nVote Cast: YAE\nStable coin diversity is good for Aave and we are supportive of MAI’s expansion across several networks.\nSupply and Borrow Cap Updates Aave V3\nVote Cast: YAE\nGlad to support this proposal to support the further safe growth of Aave.\nRisk Parameter Updates Aave V3 Polygon\nVote Cast: YAE\nWe support the continual refinement of risk parameters in line with market conditions.\nUpgrade the safety module to v1.5 PART 2\nVote Cast: YAE\nGreat to see this upgrade coming to AIP with two audits from a very strong developer team. Strongly in favour of this proposal.\nAave V2 Interest Rate Curve Changes (4/21)\nVote Cast: YAE\nIn line with prior comment relating to the Snapshot vote. Although we believe the wMATIC parameters are sub-optimal, we support the overall proposal and reserve the ability to amend the wMATIC interest rate at a later date, pending how the market responds.\nLST Supply Cap Increase Polygon & Arbitrum\nVote Cast: YAE\nWe support the continued safe growth of LSTs on Aave deployments and acknowledge support from the risk providers for all proposed parameter changes.\n[ARFC] Add LUSD Arbitrum v3\nVote Cast: YAE\nWe support the diversification of Aave’s stable coin offering.\n[TEMP CHECK] - Add support for fUSDC on Ethereum v3 Pool\nVote Cast: YAE\nThis represents an exciting growth opportunity for Aave and we welcome further exploration of adding fUSDC as collateral on Aave v3 with conservative risk parameters upon being added.\n[ARFC] Add 1INCH to Aave V3 Ethereum\nVote Cast: YAE\nWe are in support of migrating 1inch from v2 to v3. Adding 1inch to the v3 market is the first step in this journey.\n[ARFC] Add ENS to Aave V3 Ethereum\nVote Cast: YAE\nSimilar reasoning to 1inch above.\n[ARFC] BUSD Offboarding Plan Part II\nVote Cast: YAE\nBUSD is not a good fit for Aave and we support the off boarding effort.\n[ARFC] Activate emode for rETH Aave Ethereum V3 Pool\nVote Cast: YAE\nAdding rETH to the ETH mode will enable more structured products to be built on Aave v3, promote diversify and will lead to great wETH being borrowed with generates revenue for Aave. We believe this to be low risk and are looking for @bgdlabs to review the oracle used within E-Mode before supporting this proposal at AIP stage of the governance process.\n[TEMP CHECK] - Add support for RPL on Ethereum v3\nVote Cast: YAE\nWe support adding RPL, as we did LDO, and we would like to highlight the extra utility that RPL offers relative to LDO. Hopefully there is strong RPL borrowing demand.\n[ARFC] Acquire BB-A-USD and deposit 50% into both Balancer and Aura Finance\nVote Cast: YAE\nWe are supportive of Aave DAO deploying the treasury to earn. Especially where it is perceived to be low risk and in line with other initiatives within the DAO.\n[ARFC] Migrate Holdings from v2 to v3 and acquire wstETH and rETH\nVote Cast: YAE\nWe are supportive of Aave DAO holding funds in the safer of the two deployments. We also support Aave DAO holding the most battle test LST and holding these assets outside of the liquidity pools. We would advocate to explore how a portion of these assets could be used in the future to earn additional yield.\n[ARFC] Consolidate Collector Contract & Secure Service Provider Runway\nVote Cast: YAE\nThe USDC runway on Aave v2 requires replenishing and the logic presented of swapping small holdings of high volatility assets to aUSDC makes a lot of practical sense for Aave DAO.\nRisk Parameter Updates for Ethereum v3 (05/09/2023)\nVote Cast: YAE\nWe support the controlled increase of the LUSD supply cap.\nAave V3 Interest Rate Curve Changes (4/27)\nVote Cast: YAE\nWe support the revised interest rate parameters.\nAGD Approval\nVote Cast: YAE\nWe are supportive of this corrective USDT payment for AGD.\nMaticX Supply Cap Increase Polygon v3\nVote Cast: YAE\nWe support the continued safe growth to LSTs across Aave v3 deployments.\n[ARFC] Add rETH to Aave V3 Arbitrum Liquidity Pool\nVote Cast: YAE\nWith rETH liquidity on Arbitrum growing, we are supportive of adding rETH to Aave v3 with conservative risk parameters.\n2 Likes\nTokenLogic\nJune 1, 2023, 5:43pm\n6\nHi everyone,\nFollowing the snapshot vote for the Delegate Code of Conduct.\nBy this post, the @TokenLogic is officially stating its intent to follow this code and is proud to participate in this initiative.\n2 Likes\nTokenLogic\nJanuary 7, 2024, 10:07pm\n7\nHi All,\nPlease below our Snapshot voting history continuing on from the most recent vote mentioned above. A separate comment to follow will show our AIP voting history.\n[ARFC] Consolidate Collector Contract & Secure Service Provider Runway\nVote Cast: YAE\n12 months runway should be held in each of the required reserves. This proposal moves towards this direction.\n[ARFC] Migrate Holdings from v2 to v3 and acquire wstETH and rETH\nVote Cast: YAE\nWe are supportive of migrating funds from legacy v2 deployments to v3 and acquiring LSTs within the Treasury.\n[ARFC] Acquire BB-A-USD and deposit 50% into both Balancer and Aura Finance\nVote Cast: YAE\nWe created this proposal and are supportive of improving the efficiency of the DAOs assets whilst accumulating governance influence via token rewards in doing so.\n[TEMP CHECK] - Add support for RPL on Ethereum v3\nVote Cast: YAE\nWe expect to see borrowing demand from RPL’s utility and support the isolation mode risk parameter configuration.\nTEMP CHECK - Add support for fUSDC on Ethereum v3 Pool\nVote Cast: YAE\nWe are supportive of adding productive assets as collateral.\n[ARFC] Activate emode for rETH Aave Ethereum V3 Pool\nVote Cast: YAE\nWe support adding rETH to Category 1 (E-Mode) and enabling users to enter the yield maximising strategy that loops rETH and ETH to generate yield.\n[ARFC] BUSD Offboarding Plan Part II\nVote Cast: YAE\nWe support the continued efforts to offboard BUSD.\n[ARFC] Add ENS to Aave V3 Ethereum\nVote Cast: YAE\nWe support migrating assets from v2 to v3 and adding ENS to v3 with proper risk restrictions enables this to happen.\n[ARFC] Add 1INCH to Aave V3 Ethereum\nVote Cast: YAE\nWe support migrating assets from v2 to v3 and adding 1INCH to v3 with proper risk restrictions enables this to happen.\n[TEMP CHECK] Add ARB to Arbitrum Aave v3\nVote Cast: YAE\nWe support adding the native token to each respective Aave deployment.\n[TEMP CHECK] FlashMinter Facilitator Approval\nVote Cast: YAE\nWe support this development update provide by Aave Companies.\n[ARC] Framework For Recognized Delegates]( Snapshot )\nVote Cast: YAE\nWe support recognising the effort of delegates in a more formal capacity.\n[ARC] Delegate Code Of Conduct\nVote Cast: YAE\nThis is a nice improvement and are supporting of introducing a base line of expectations within the DAO.\n[ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Ethereum - 2023.05.18\nVote Cast: YAE\nWe support the analysis and efforts to fine tune the risk parameters presented within this proposal.\n[ARFC] Polygon Supply Cap Update 23.05.2023\nVote Cast: YAE\nWe prepared this proposal and are in support of increasing the supply cap for MaticX on Polygon v3.\n[ARFC] Optimism v3 Supply Cap Update\nVote Cast: YAE\nWe voted in favour of Chaos Lab’s methodology yielding a 21,000 unit wstETH cap.\n[ARFC] Optimism Create ETH E-Mode\nVote Cast: YAE\nWe created this proposal and are in favour of enhancing the LST/ETH yield looping strategies by creation of Category 1 ETH E-mode.\n[TEMP CHECK] Safety Module Upgrade Part II - Asset Diversity, SM Categories & Slashing Updates\nVote Cast: YAE\nWe are in favour of diversifying the assets held in the Aave SM to reduce the dependency on AAVE.\n[TEMP CHECK] Safety Module Upgrade Part III - Enable gauges on BPT in Safety Module (smBPT\nVote Cast: YAE\nCreation of smBPT gauges that replace the standard BPT gauges enhances the efficiency of the overall strategy by removing one of two competing options for where users can deposit the BPT.\n[ARFC] Add fUSDC to Ethereum v3\nVote Cast: YAE\nWe are in favour of adding yield generating assets as collateral.\n[ARFC] Add RPL to Ethereum v3\nVote Cast: YAE\nWe expect to see borrowing demand from RPL’s utility and support the isolation mode risk parameter configuration.\n[ARFC] Polygon v3 Supply Cap Update 2023.05.21\nVote Cast: YAE\nWe support increasing the stMATIC supply cap enabling the stMATIC/wMATIC yield maximising strategy to grow.\n[TEMP CHECK] Aave V3 Deployment on Base\nVote Cast: YAE\nWe are supporting of deploying Aave v3 across various networks with real adoption/usage potential.\n[TEMP CHECK] Pyth to Support AAVE on Optimism as a Secondary Oracle\nVote Cast: AGAINST\nWe do not support the integration of a back up oracle within the Aave Protocol. There is no technical upside of doing so and the feature is not used within the Aave Protocol as it is redundant.\n[TEMP CHECK] Aave v3 MVP deployment on Scroll mainnet\nVote Cast: YAE\nWe are supportive of deploying Aave v3 across various networks to further support Aave’s growth.\n[ARFC] Add FRAX to Ethereum Aave v3\nVote Cast: YAE\nWe co-authored this proposal and are supportive of Aave offer a diverse range of stable coins.\n[TEMP CHECK] Add GMX to Arbitrum v3\nVote Cast: YAE\nWe are supportive of adding GMX to Aave v3 Arbitrum. GMX has experience significant growth during the bear market and is a prominent app within Arbitrum ecosystem.\n[ARFC] Add FRAX Arbitrum Aave v3\nVote Cast: YAE\nWe co-authored this proposal and are supportive of Aave offer a diverse range of stable coins.\n[ARFC] Add native USDC to the Arbitrum V3 pool\nVote Cast: YAE\nWe support introducing native USDC to all Aave v3 deployments.\n[ARFC] - Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum - 2023.06.15\nVote Cast: YAE\nWe support Chaos Labs proposed CRV changes on Aave v2 Ethereum.\n[ARFC] Gauntlet Recommendation on TUSD for Aave v2 Ethereum\nVote Cast: YAE\nWe support the lower LT TUSD option which is the more aggressive of the two options.\n[ARFC] Chaos Labs - Incremental Reserve Factor Updates - Aave V2 Ethereum\nVote Cast: YAE\nWe are supportive of increasing the RF across Ethereum v2. We expect this to help encourage users to migrate to v3.\n[ARFC] Chaos Labs Risk Parameter Update - CRV Aave V3 Polygon - 2023.06.20\nVote Cast: YAE\nWe support reducing the LT and LTV parameters for CRV on Polygon due to declining liquidity conditions.\n[TEMP CHECK] Integrating MakerDAO’s DSR into Aave V3 Ethereum Pool\nVote Cast: YAE\nWe expect this to be a significant source of growth for aave and expect it to lead to higher borrowing rates of stables coins as users loop sDAI and stable coin debt to generate yield.\n[TEMP CHECK] GHO Stewards: Agile Parameter Changes\nVote Cast: YAE\nGiven the success of the Risk Stewards, we are supportive of the introduction of the GHO Steward role to provide the needed flexibility to manage GHO efficiently.\n[TEMP CHECK] Allocating part of GHO Revenue to Safety Incentives\nVote Cast: YAE\nWe are supportive of distributing GHO to SM depositors to further promote the adoption and velocity of the stable coin.\n[ARFC] Chaos Labs Risk Parameter Updates - FEI on Aave V2 Ethereum - 2023.6.22\nVote Cast: YAE\nWe are supportive of the continued deprecation of the FEI stable coin given how FEI Protocol / Tribe DAO is being sunset.\n[ARFC] Chaos Labs Risk Parameter Updates - Aave V2 Ethereum - 2023.6.23\nVote Cast: YAE\nGiven prevailing market conditions, we are supportive of aggressively reducing Aave’s risk exposure.\n[ARFC] Gas Rebate for Recognized Delegates\nVote Cast: YAE\nWe are supportive of reimbursing gas costs to recognised delegates and deployment costs of service providers.\n[ARFC] Aave Robot v1 activation\nVote Cast: YAE\nWe support the introduction of the Aave Robot v1.\n[ARFC] Framework for ARFC and TEMP CHECK Proposals\nVote Cast: YAE\nWe are supportive of the continued iterative effort of ACI to improve Aave’s governance processes.\n[ARFC] Gauntlet Risk Parameter Updates for Ethereum v3, Arbitrum v3, Ethereum v2\nVote Cast: YAE\nWe broadly support the proposed LTV changes that Gauntlet has proposed.\n[ARFC] Add rETH Aave v3 Optimism\nVote Cast: YAE\nWe are the author of this proposal and are supportive of onboarding additional LSTs to support continued demand for native network tokens, like ETH in this instance.\n[ARFC] Add GMX to Arbitrum v3\nVote Cast: YAE\nWe are supportive of adding GMX to Arbitum.\n[TEMP CHECK] Aave V3 Deployment on Linea Testnet\nVote Cast: YAE\nWe are supportive of deploying Aave v3 on various networks to promote the further adoption of the protocol.\n[TEMP CHECK] Safety Module Upgrade Part IV - Incentives Management Upgrade\nVote Cast: YAE\nWe are supportive of creating an incentive committee to support the maintenance of bribe campaign to maintain the yield across SM deposits.\n[TEMP CHECK] Safety Module Upgrade Part V - veToken Holding\nVote Cast: YAE\nSimilar to the previous ARFC, we are a co-author of this proposal and support the management of ve Assets in the DAOs best interest.\n[ARFC] - Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum - 2023.07.10\nVote Cast: YAE\nWe favour of Chaos Labs aggressive reduction of CRV’s LT and LTV on Ethereum v2.\n[ARFC] TUSD Offboarding Plan\nVote Cast: YAE\nWe support the DAO’s continued efforts to offboard TUSD.\n[TEMP CHECK] Introducing “Curator” by Llama\nVote Cast: YAE\nWe support the creation of a contract, “Curator” that enables the DAO to swap assets via the short executor with MEV protection on Cowswap. Do note, TokenLogic lead the design/specification of the “Curator” for Llama.\n[ARFC] Reserve Factor Updates - Polygon Aave v2\nVote Cast: YAE\nWe published this proposal and are supportive of continually increasing the RF parameters on Polygon v2 to further encourage users to migrate from v2 to v3.\n[ARFC] Gauntlet - Synchronicity Price Adapter “Killswitch” Functionality for LST Emode\nVote Cast: OPTION 3\nWe favoured Option 3 relative to the other options based upon the discussion presented on the forum.\n[ARFC] Chaos Labs Risk Parameter Updates - MAI on Aave V3 - 2023.7.23\nVote Cast: YAE\n[ARFC] GHO Liquidity Pools: Primary Pools Initial Strategy\nVote Cast: YAE\nWe are the author of this proposal. This proposal is a continual of an earlier TEMP CHECK proposal.\n[ARFC] Aave V3 Deployment on Base\nVote Cast: YAE\nWe support deploying Aave v3 across various networks to support the further adoption and usage of the protocol.\n[ARFC] Cancel Llama Service Provider Stream\nVote Cast: ABSTAIN\nAs we receive payment from Llama we have abstained from participating in this vote.\n[ARFC] BUSD Offboarding Plan Part III\nVote Cast: YAE\nWe support the continued effort to offboard BUSD and expect this proposal to become a good revenue source for Aave DAO throughout the deprecation process.\n[ARFC] Aave | Flipside Crypto Facilitator [v2]\nVote Cast: NAY\nWe do not support the current iteration of Flipside’s proposal as it overlaps with other service provider efforts whilst also introducing unneeded bureaucracy within the DAO.\n[ ARFC] Activate LUSD as Collateral on Aave V3 ETH Pool]( Snapshot )\nVote Cast: YAE\nWe support enabling LUSD as collateral on Aave v3. LUSD’s stability pool provides a borrowers an opportunity to earn yield with LUSD. We expect this utility to provide a level of borrowing demand support.\n[TEMP CHECK] Treasury Management - Avalanche v2 to v3 Migration\nVote Cast: YAE\nAs the author of this proposal, we favour the migration of the DAO’s funds from Aave v2 Avalanche to v3.\n[ARFC] sDAI Aave V3 Onboarding\nVote Cast: YAE\nWe are supportive of adding yield generating assets as collateral which are expected to stimulate borrowing demand.\n[ARFC] wGHO Aave V3 Onboarding\nVote Cast: YAE\nIt my be to early in GHO’s life for it to be added to Aave v3. With conservative, appropriate, risk parameter we support adding GHO. We would like liquidity conditions to improve and for this to be reflected in further increases to the supply cap.\n[ARFC] Treasury Management - Avalanche v2 to v3 Migration\nVote Cast: YAE\nWe authored this proposal and support the migration of the DAO’s funds from Aave v2 to v3.\n[ARFC] Return OP to Aave Grants DAO Safe\nVote Cast: YAE\nWe support correcting a past mistake that lead to the OP airdrop being directed to the Guardian address and not AGD address on the Optimism Network.\n[ARFC] Increase GHO Borrow Rate\nVote Cast: YAE\nThis proposal begins to reduce the gap between GHO and other stable coin funding rates. We do not expect increasing the interest rate to fix the peg, but potentially reduce the rate at whihc GHO is being borrowed at.\n[ARFC] Enabling USDT as collateral on Aave v3 AVAX Market\nVote Cast: YAE\nWe support amending USDT on Avalanche to enable it being used as collateral.\n[ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Ethereum - 2023.08.25\nVote Cast: YAE\nWe support Chaos Labs suggested amendments to the Ethereum v3 risk parameters.\n[ARFC] Treasury Management - Acquire AURA\nVote Cast: YAE\nTokenLogic brokered the deal with Olympus DAO and is supportive of Aave accumulative AURA with the intention of bootstrapping GHO liquidity.\n[ARFC] Treasury Management - Replace AGD’s DAI Allowance with GHO Allowance\nVote Cast: YAE\nWe are supportive of increasing the adoption and velocity of GHO. With AGD using GHO, it sends a positive signal to the market that the DAO will use its own stable coin for payments.\n[ARFC] Quarterly Gas Rebate Distribution - August 2023\nVote Cast: YAE\nTokenLogic is a beneficiary of this proposal and supports the gas costs of recognised delegates being reimbursed.\n[TEMP CHECK] Update Balancer Ecosystem Holdings\nVote Cast: YAE\n[ARFC] Gauntlet Interest Rate Recommendation for WETH\nVote Cast: YAE\nGiven how the yield from ETH LSTs has faded over time, we are supportive of reducing the Slop1 parameter to be inline / narrowly below the leading LST yield. Upon implementation, this should lead to additional LST/ETH looping and greater ETH revenue as the volume of debt offsets the reduced revenue per unit of ETH debt.\n[ARFC] Gauntlet recommendation for WETH Uopt on Ethereum v3\nVote Cast: OPTION 3\nWe favour the No Change option which is to leave the Uoptimal parameter as is. Generally, the higher the Uoptimal value the more capital efficient the reserve.\n[ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Avalanche - 2023.09.06\nVote Cast: YAE\nWe support the risk parameter amendments as present by Chaos Labs for the Avalanche v3 deployment.\n[ARFC] wGHO Aave V3 Onboarding\nVote Cast: YAE\nWe are supportive of adding wGHO to the Ethereum v3 deployment, even more so when liquidity conditions improve.\n[ARFC] OP Risk Parameters Update for Aave V3 Optimism Pool\nVote Cast: YAE\nWe support enabling borrowing of OP on the Optimism Aave v3 deployment. We expect this to generate revenue, but are unsure as to if this will become a meaningful revenue driver.\n[ARFC] Safety Module - Polygon & Avalanche Coverage Update\nVote Cast: YAE\nTo further support the migration of users from v2 to v3, we proposed removing the SM’s coverage from v2 deployments on Polygon and Avalanche.\n[ARFC] Expansion of “Orbit” - A DAO Funded Delegate Platform Initiative\nVote Cast: YAE\nWe support the migration of Orbits funding from the ACI to the Aave DAO.\n[TEMP CHECK] Treasury Management - Swap B-80BAL-20wETH to GHO\nVote Cast: YAE\nWith Balancer’s support we propose swapping a portion of the Aave DAOs B-80BAL-20WETH to GHO to fund the AURA OTC swap with Olympus DAO. This is part of a broader strategy to improve the overall efficiency of the DAO’s strategic assets.\n[TEMP CHECK] Treasury Management - Create and Fund GHO Liquidity\nVote Cast: YAE"}
{"url":"https://docs.marinade.finance/official-links","domain":"docs.marinade.finance","title":"Official Links | Marinade Documentation","hash":"f7522952d35d3eaaa7503fd42f3c6c1ac051745d35c5020f65e9fe07d07d35d5","tokens":456,"chars":1824,"crawler":"crawler-f6nn","verified":"exact","ts":1791172378348,"text":"Marinade Documentation\n⌘ Ctrl k\nFor the complete documentation index, see llms.txt . This page is also available as Markdown .\n🔗 Official Links\nIf you want to join us, here is where you can find us!\nThese are the only official Marinade channels. If a link, wallet prompt or support request reaches you from anywhere else, it is not from Marinade.\nMarinade will never DM you first, never ask for your seed phrase or private key, and never ask you to \"validate\", \"sync\" or \"migrate\" your wallet. Support does not happen in direct messages. Always reach the app through app.marinade.finance and check the domain before connecting a wallet. Anyone who contacts you claiming to be Marinade support is a scammer.\nUse Marinade\nStaking app: https://app.marinade.finance/\nMain website: https://marinade.finance/\nInteract With Us\nDiscord: https://discord.gg/yTdH8YkYKg\nX: https://x.com/MarinadeFinance\nYouTube: https://www.youtube.com/@marinadefinance\nForum: https://forum.marinade.finance/\nFollow Our Work\nBlog: https://marinade.finance/blog/\nDocumentation: https://docs.marinade.finance/\nHelp center: https://help.marinade.finance/\nGitHub organisation: https://github.com/marinade-finance\nAudits: https://docs.marinade.finance/marinade-protocol/security/audits\nPress kit: https://docs.marinade.finance/partnerships/marinade-press-kit\nData And Dashboards\nMarinade Stats: https://stats.marinade.finance/\nValidator explorer: https://app.marinade.finance/explore/\nProtected Staking Rewards validator dashboard: https://psr.marinade.finance/\nGovernance and DAO treasury on Realms: https://v2.realms.today/dao/899YG3yk4F66ZgbNWLHriZHTXSKk9e1kvsKEquW7L6Mo\nPrevious MNDE Governance\nNext Protocol Overview\nLast updated 10 days ago\nWas this helpful?\n- Use Marinade\n- Interact With Us\n- Follow Our Work\n- Data And Dashboards\nWas this helpful?"}
{"url":"https://gov.optimism.io/t/help-dashboard-not-loading-wallet/10726","domain":"gov.optimism.io","title":"Help: Dashboard not loading wallet - ✨ General - Optimism Collective","hash":"9a568c66ec2fbbe4226ee55f45532572ece26e0f39f36b3b431c485f10c77763","tokens":275,"chars":1100,"crawler":"crawler-f6nn","verified":"exact","ts":1791172380926,"text":"Optimism Collective\nHelp: Dashboard not loading wallet\n✨ General\nRyan_Optimism_Dev\nJune 25, 2026, 12:05am\n1\nStaking dashboard not loading my wallet balances\n1 Like\nMconnectDAO\nJune 25, 2026, 3:08am\n2\nYou might try a few quick checks:\nConfirm you are connected to the correct network (Optimism Mainnet) in your wallet.\nHard refresh the page and clear cache, or try a different browser/incognito window.\nMake sure your wallet is actually connected to the dashboard and that you have no pending wallet pop‑up.\nIf the issue persists, sharing your browser, wallet, and a screenshot of the console (F12 → Console) could help the team debug it. @Ryan_Optimism_Dev\nRelated topics\nTopic\nReplies\nViews\nActivity\nKarma - link forum username to wallet\n✨ General\n51\n3986\nMarch 1, 2025\nKarma - Grantee accountability+feedback thread\nAccountability 🗂️\ngrant-update\n40\n4338\nOctober 3, 2023\n[FINAL] OP Governance Analytics Dashboard\nARCHIVED & OLD Missions\nseason-4\n42\n5492\nJune 4, 2024\nPlease help me out\n✨ General\n1\n753\nJuly 14, 2023\n[FINAL] OPdelegate.com\nARCHIVED & OLD Missions\nseason-4\n23\n3799\nDecember 15, 2023"}
{"url":"https://docs.jup.ag/user-docs/trade/spot/faq","domain":"docs.jup.ag","title":"Jupiter Spot FAQ - Jupiter Documentation","hash":"74be876cba52345ee8e7b65e60a41d5c332bbf16f975ee54c79a8bd246ee4256","tokens":6789,"chars":27156,"crawler":"crawler-f6nn","verified":"exact","ts":1791172384118,"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 FAQ\nFrequently asked questions about Jupiter Spot: trading and execution, token safety, charts, features and tools, and limitations.\nGeneral\nHow do I access Jupiter Spot on mobile?\nJupiter Spot is available on the Jupiter Mobile app:\n- Android : Google Play Store\n- iOS : Apple App Store\njup.ag won't load in my wallet's mobile browser (e.g. Backpack). What should I do?\nThis is usually caused by stale site data in the browser. Work through these steps in order:\n1\nClose all jup.ag tabs\nIn the wallet’s in-app browser, close every jup.ag tab, then fully close the wallet app.\n2\nReopen from a fresh tab\nOpen the app again and load jup.ag in a brand-new tab. Do not use the Reload button on an existing tab. If the in-app browser keeps failing, open jup.ag in your device’s browser (Safari or Chrome) instead.\n3\nClear the site data for jup.ag\nIf it still fails, clear the browser’s stored data for jup.ag:\n- iOS (Safari): Settings → Apps → Safari → Advanced → Website Data, search for “jup.ag”, then swipe left to delete it.\n- Android (Chrome): tap the three-dot menu → Settings → Site settings → All sites, search for “jup.ag”, then tap Clear & reset.\n- In-app wallet browsers: most do not offer per-site clearing. Look for a “clear browser data” or “clear cache” option in the wallet’s own settings.\nNever clear a wallet app’s storage or app data from your phone’s system settings unless your recovery phrase is safely backed up. Clearing app data can remove wallets stored on the device.\nAs a reliable alternative on mobile, use the Jupiter Mobile app directly.\nWhat is the difference between Classic and Trench mode?\nClassic mode (for all traders) is the classic Jupiter UX with a simple swap widget, using Ultra only. Trench mode (one-click trading) is a compact, information-dense pro layout with manual presets, designed for active trading on volatile tokens. Both modes execute swaps identically — the difference is purely visual. You can switch between them in Settings → Spot → Trading Mode (gear icon in the top navigation bar). See What is Jupiter Spot? for more details.\nHow do I hide the news icons on the chart?\nOpen Display Options in the chart toolbar and uncheck News under Markers. The same dropdown hides your own trades, dev trades, followed-wallet trades, and migration markers. The News button above the chart and the news drawer keep working. See Charts .\nHow do I hide or move the chat bubble that covers part of the trade page?\nThe round button in the bottom-right corner is the support bubble: it opens the help and feedback chat. It cannot be dragged elsewhere, but you can hide it. Open Settings (gear icon in the top bar), stay on the General tab, and turn off Show support bubble . The chat remains available from Get Help at the bottom of the left sidebar. The setting is saved in your browser. See Settings .\nWhat is the difference between Quick Buy and Quick Swap?\n- Quick Buy lets you purchase a token directly from a discovery tab or AlphaScan without opening the token page. Set an amount in SOL or USDC, then click the ⚡ icon next to any token.\n- Quick Swap is available on the right side of a token page. It lets you buy or sell that specific token without leaving the page.\nBoth use your current execution settings (Ultra mode by default, or your manual Trade Presets).\nTrading & Execution\nWhat is the vault access signature on Limit and DCA orders, and how do I revoke it?\nLimit V2 and DCA V2 ask you to sign a message (or a transaction, for wallets that cannot sign messages, such as a Ledger connected directly to jup.ag) before showing or placing orders. It is a sign-in that proves you own the address; it cannot move funds. Placing an order or withdrawing from the vault still needs its own transaction signature; cancelling an order is the one action the sign-in covers by itself, and even then the tokens only leave the vault once you sign the withdrawal. The credential is stored in your browser for that address, is renewed while you use the site, and lapses after 30 days without a visit (90 days at most). To revoke it, disconnect the wallet from jup.ag, which also ends the session on Jupiter’s side; your orders and vault funds are unaffected, and you will be asked to sign again next time. See Vault access .\nWhat fees apply on Jupiter Spot?\nSpot uses Jupiter Ultra by default, which charges 0% to 0.5% depending on the volatility of the token pair. More stable pairs tend toward the lower end, and more volatile pairs (e.g. newly launched tokens) tend toward the higher end. If your wallet doesn’t have enough SOL for gas, gasless trading activates automatically. A relayer covers the SOL cost on your behalf and the swap fee is increased by the equivalent value; there is no extra fee for gasless itself. The gas cost is fixed (not proportional to trade size), so larger trades have a smaller percentage impact. Gasless is only available when this amount stays within 10% of the trade, hence a minimum trade size. Both fees are included in the quote shown before you confirm. See Fees for full details.\nWhy is my Ultra slippage at X% (e.g. 0.73%)?\nIn Ultra Mode, slippage is calculated automatically by RTSE (Real-Time Slippage Estimator) based on:\n- The token category (stable, major, volatile, new listing)\n- Recent price volatility on that token\n- Liquidity depth in the pools your trade routes through\n- Current network conditions on Solana\nValues like 0.73%, 1.2%, or higher are normal for non-stable pairs and reflect current market conditions. RTSE sets the lowest slippage that still allows your trade to land successfully. If the slippage seems too high for your liking, you can switch to Manual Mode and set a fixed slippage yourself. Note that lowering slippage too much may cause your trade to fail. See How RTSE Works for details.\nWhy does the chart jump or jitter on 1-second or 15-second candles?\nAt those intervals each candle is built live from a handful of trades, so one large trade or a swap through a thin pool prints as a spike or a step. Longer intervals absorb the same trades into a single candle. Charts quoted against a pair or another token refresh about every 60 seconds and reload if their history has a gap. Switch to a 1-minute or longer interval to read the trend. See Charts .\nWhy is my transaction taking longer than expected?\nSeveral factors can delay execution:\n- Network congestion — Solana may be experiencing high activity.\n- Low liquidity — If your trade needs to route through multiple pools, it may take longer.\n- Slippage settings too low — If price movement exceeds your slippage tolerance, the trade may get stuck or revert.\nIf your transaction hasn’t been processed in a long time, please reach out to the team at support.jup.ag .\nMy swaps keep failing — what should I do?\nIf you are trying to buy a new token with high volatility, it may be difficult to land your trades. This is due to the price moving between the time you submit the swap and the time it executes. Jupiter’s built-in slippage protection prevents you from buying tokens at unexpectedly high prices. Usually, it should take no more than 3 tries to buy a volatile token. If you struggle for more than 3 times, please let the team know at support.jup.ag .\nYou will pay gas fees for failed trades. Jupiter may compensate users who lost gas on more than 3 consecutive failed attempts.\nMy swap isn't going through — \"No routes found\"\nWhen you see “No routes found,” it typically indicates one of these issues:\n- Insufficient liquidity for the token pair you’re trying to swap.\n- The trade size is too large relative to available liquidity, or too small for Jupiter to reliably execute.\n- The token may have trading restrictions that prevent routing.\nWhen liquidity is insufficient for your full trade amount, Jupiter may suggest a reduced amount with a “Try reducing to [amount]” message. This suggestion is a best-effort estimate based on available routes and is not a guaranteed maximum amount.\nI received fewer tokens than expected — what should I do?\nPossible reasons include:\n- Slippage — The token price moved before execution.\n- Routing optimization — The swap was split across multiple pools.\n- Liquidity depth — If a token has low liquidity, the trade impact can be significant.\nAlways check the preview screen before confirming a swap to see the estimated final amount.\nIf the difference is significant, please let the team know by submitting a ticket .\nI got rekt on an Ultra trade — what happened?\nIf you got rekt while using Ultra Mode, you may be eligible for compensation in the following cases:\n- A bad quote caused by bad routing, especially when a better route or market was available at the time of swap.\n- More than 3 consecutive trades that failed to execute, leading to a loss in gas.\n- Unreasonably high slippage (>20%) when unnecessary, leading to sandwich attacks.\nJupiter never compensates for potential PnL, and only compensates Ultra Mode users. Jupiter cannot guarantee zero MEV. Ultra Mode minimizes the risk of getting sandwiched but does not prevent it entirely.\nAllow up to 3 days for refund requests to be processed. Open a support ticket .\nWhy was my wallet flagged as high-risk?\nWallets are flagged if they’ve interacted with sanctioned exchanges or addresses linked to suspected criminal activity such as phishing or social engineering attacks. Please open a ticket on support.jup.ag so the team can look into your individual case.\nWhy am I paying more fees on Jupiter than expected?\nSome users have reported higher platform fees than expected. This is typically caused by browser extensions that modify quote responses or inject additional referral fees. Signs this may be happening:\n- Higher-than-expected fees on your Jupiter swaps.\n- Warnings in the app like: “Your platform fee is higher than expected due to an installed browser extension not affiliated with Jupiter.”\nKnown extensions observed to affect Jupiter swaps:\n- Kerberus — Injects a referral account and changes the platform fee to 0.95%.\n- Pocket Universe — Also injects referral fees in Jupiter swaps.\nThese extensions operate independently of Jupiter and are not developed or maintained by the Jupiter team.\nHow to fix:\n- Double-check fees before approving any transaction.\n- Disable or remove extensions that charge extra fees.\n- Restart your browser and open a fresh window.\n- Swap again on jup.ag — you should now see normal fees.\nJupiter Wallet includes Transaction Protection, which filters transfers to known malicious addresses injected by such extensions.\nCan I place Limit or Recurring orders on Token-2022 tokens?\nYes. Limit Order V2 and DCA V2 accept Token-2022 tokens, including those that charge a transfer fee. That fee is set by the token itself, not by Jupiter, and it applies each time the token moves: on the deposit, on the sell or each fill, on each buy, and when a cancellation returns your remaining tokens. The rate is shown in the review step before you confirm. A creator can change the rate afterwards, so an order can settle at a different rate than the one displayed. The one refusal is an OTOCO whose token to buy charges a transfer fee. The legacy V1 versions of both order types do not support these tokens. See Token-2022 and transfer fees .\nWhy was my Limit order not executed?\nLimit orders may fail to execute due to:\n- Extreme market volatility\n- Low token liquidity\n- Token creators removing all liquidity (rug pull)\n- Price movements too rapid for to process\n- The price moved before the order was settled\n- Slippage failures during settlement\nWhy did my DCA (Recurring) order fail to execute?\nDCA suborders may fail due to:\n- Insufficient liquidity\n- Price movements beyond acceptable slippage (slippage on DCA orders is managed automatically per execution; it is not a setting you configure)\n- Network congestion\n- Technical issues with the specific tokens\n- Price outside your set USD price range (V2 only — the suborder is marked as Out of Range and rescheduled to the next interval)\nFailed suborders automatically retry at the next scheduled interval.\nHow do I unwrap wSOL back into native SOL?\nOn jup.ag , whenever a wSOL balance is detected in your connected wallet, a line under the swap form reads “You have [amount] wrapped SOL that you can unwrap”. Click unwrap and approve the transaction: your entire wSOL balance becomes native SOL. It works from the swap form and from a token page’s trade panel, and it does not require the Use wSOL setting to be on. You do not need this after a normal swap, since swaps to SOL already deliver native SOL. It is for wSOL that reached your wallet another way, such as a withdrawal from an external protocol. See Wrapped SOL (wSOL) .\nHow do I get wrapped SOL (wSOL) in my wallet?\nMost users never need wSOL: Jupiter wraps and unwraps SOL automatically, and swaps to SOL deliver native SOL. If an external protocol requires wSOL, enable Use wSOL in the swap settings (gear icon → Manual → Routing ): swaps to SOL then deliver wSOL instead of native SOL. wSOL shows as SOL in the token selector (mint So11…1112 ). Any separate “Wrapped SOL” token in search results is unrelated and likely a scam. To go the other way, see the previous question. Full details on Wrapped SOL (wSOL) .\nTokens & Safety\nWhat are holder rewards, and why does this token charge a transfer fee?\nSome launchpads fund rewards for a token’s holders with a Token-2022 transfer fee: a percentage taken on every buy, sell and transfer, which the launchpad converts into the paired asset and distributes to eligible holders. These tokens show a Holder rewards icon next to the contract address and a JupShield warning with the rate. The fee applies to your own trades and transfers too, and the rewards are run by the launchpad, not by Jupiter, so they are not guaranteed. See Holder rewards .\nHow do I check if a token is safe to trade?\nSpot displays several safety indicators on each token page:\n- Mint Authority — can the developer create more tokens?\n- Freeze Authority — can the developer freeze token accounts?\n- Top 10 Holders % — how concentrated is the supply?\n- Dev Holding % — how much does the developer hold?\n- DB / DS markers — when did the developer buy or sell?\n- Snipers Holding % — how much is held by wallets that bought within the first three blocks after launch?\n- Insiders Holding % — how much is held by wallets that bought in the first block or received tokens from other insiders?\n- Pro Traders % — what percentage of supply is held by professional trading platform users?\n- Dex Paid — did the creator pay for a DEX listing?\n- Bonding Curve % — has the token migrated to a liquidity pool?\nThese indicators are informational tools, not guarantees of safety. Always do your own research. See Token Page and Risks and Limitations for more.\nI accidentally bought the wrong token — what can I do?\nTokens on Solana are permissionless, which means anyone can create a token. Always verify that you are buying the right token by checking the contract address. Jupiter reduces this risk by ranking tokens based on activity, using a verification system for community-verified tokens, and filtering out fake tokens when possible.\nJupiter is generally unable to support or compensate for buying the wrong tokens. This applies to all platforms: Jupiter Mobile, jup.ag, and others.\nWhat does the bonding curve percentage mean?\nSome tokens launch through a bonding curve mechanism. The percentage shown represents how much of the curve has been filled. Once it reaches 100%, the token typically migrates to a standard liquidity pool. Before migration, liquidity is limited and price impact per trade can be significantly higher. See Risks and Limitations for details.\nWhat are DB and DS markers on the chart?\nDB (Dev Bought) and DS (Dev Sold) are markers on the token chart showing when the developer wallet bought or sold the token. The developer wallet is identified as the wallet that deployed the token contract.\nWhat does the Organic Score mean?\nThe Organic Score estimates how much of a token’s activity (holders, volume, liquidity) comes from genuine users rather than bots or wash trading. A higher score indicates more organic activity. It is calculated by Jupiter and is independent of a token’s verification status. The Organic Score is a signal, not a guarantee — a high score does not mean a token is safe.\nHow is liquidity calculated on Spot?\nLiquidity is calculated by aggregating the quote side of trading pairs with a curated set of established bluechip tokens (e.g. SOL, JUP, JLP, jitoSOL, TRUMP, USDC, USDT). This list is maintained by Jupiter and may change over time. A token’s own liquidity is only included if Jupiter considers it an established asset — typically tokens with high market cap and deep liquidity. This number may differ from other sources, since Jupiter excludes certain pools that could artificially inflate liquidity figures.\nThe stats on my token page are not correct — how can I fix them?\nStats on Jupiter token pages may differ from other platforms since Jupiter uses its own set of heuristics and calculations to protect traders, and also refers to data from sources like CoinGecko and Birdeye. Currently, Jupiter does not support specialized features like aggregating liquidity across multiple chains or indexing token locks on other platforms, but the team is actively working on improving token pages. If you need assistance with your project’s token page, please open a ticket on support.jup.ag .\nCan I trade tokenized stocks 24/7?\nMost tokenized stocks are tradeable 24/7. Tokenized stocks issued by Ondo were the exception on a 24/5 schedule, but Ondo has enabled 24/7 trading on its most-traded tokens; the rest remain on 24/5 (generally Sunday 8pm ET until Friday 8pm ET) with any additional trading pauses displayed in the UI. Ondo Stocks are currently only tradeable against USDC. Ondo tokens use a mechanism, which means liquidity may be significantly lower outside of traditional U.S. market hours. See Tokenized Stocks for more.\nWhat is the difference between the Stocks and Tokenized stocks views?\nBoth live in the Stocks tab of Discover (also Stocks in the left navigation). The Stocks view lists one row per underlying listed stock, with the stock’s own price, market cap, and volume — tokenized versions from different issuers are grouped into that row, and clicking it opens the stock page where you pick an issuer. The Tokenized stocks view lists one row per token, with on-chain data (price on Solana, liquidity, holders). Switch between them with the chevron on the Stocks tab. See Stocks Screener .\nThe same stock is offered by several issuers — how do I choose?\nEach issuer mints its own token, so a stock like NVDA can exist as several tokens with different prices, liquidity, and terms. The Trade table on the stock page shows them side by side: the on-chain Price , and the Liquidity (or RFQ when it is quoted on demand). Beyond that, compare the issuers’ backing, redemption, trading hours, and eligibility rules — see Tokenized Stocks .\nFeatures & Tools\nWhy are some of my limit orders not shown on the chart?\nThe chart only draws open Limit V2 orders whose trigger asset is the token on the page, and only when the chart is quoted in USD, SOL, or market cap with the Trigger Buy / Trigger Sell lines enabled in Display Options . Orders still depositing or executing, V1 orders, orders that trigger on another token’s price, and orders beyond the 30 most recent are not drawn; they are all still listed in Open Orders . See Orders on the chart .\nWhere did the swap chart pair comparison go?\nChart pair comparison now lives on the token page: open the token’s chart and use the quote selector to chart the token against its market pair, USD, SOL, or another token of your choice. See Token Page .\nHow do I change the font size of the chart's price scale (including on a phone)?\nOpen the chart settings with the gear icon at the right of the chart toolbar, go to Canvas , and pick a size under Scales › Text . The change applies to the price and time scales, is saved in your browser, and survives a reload. In a mobile browser, scroll the chart toolbar to the right to reach the gear; the settings open as a list, so tap Canvas and scroll down to Scales › Text . See Charts .\nWhere are the drawing tools, such as trend lines, on the chart?\nIn a toolbar on the left edge of the chart, collapsed by default: click the small handle halfway down the left edge of the chart to open it. The second button from the top, Trend line tools, holds Trend Line, Ray, Horizontal Line, Vertical Line, Trend Angle and the channel tools; the other buttons cover Fibonacci tools, patterns, brushes, text, shapes and the measure tool. Pick a tool, then click on the chart to place its points. Drawings are saved in your browser for that base/quote pair. See Charts .\nHow do I reset the chart to its original view or settings?\nRight-click an empty area of the chart and choose Reset chart view (⌥R on Mac, Alt+R on Windows) to undo zooming and scrolling; the same menu has Remove indicators and Remove drawings . To restore the default colours, scales and other settings, open the chart settings with the gear icon and choose Apply defaults from the Template menu at the bottom left of the dialog ( ••• on a narrow window). See Charts .\nHow can I find my average entry and exit prices?\nYou can find your average entry and exit prices in two places:\n- On any token page, open the My Positions tab to see your Bought / Avg and Sold / Avg for that token.\n- Go to the Positions page to view all your positions across tokens with full PnL details.\nWhat is the PnL Calendar?\nThe PnL Calendar is a monthly calendar view of your daily trading performance, displaying up to 2 months. It is accessible from the Positions page and from the trader modal on any token page (click on a trader’s address in the tabs below the chart). It shows your daily and monthly PnL, your longest and current win streaks, and lets you export daily or monthly PnL cards as shareable images. See Positions for details.\nHow can I follow a wallet?\nOpen the SmartMoney tab and use the Wallet Tracker to enter a wallet address. You can also find wallets to track from any token page by clicking on a trader’s address in the Transactions table, or follow a trader directly from the SmartMoney leaderboards. Once tracked, the wallet’s trades appear in your live feed. You can configure sound alerts, chart markers, and feed visibility for each wallet. See SmartMoney for full details.\nWhere can I find the latest token launches on Solana?\nAlphaScan provides a real-time feed organized in three columns: New (just launched), Soon (approaching bonding curve completion), and Bonded (recently migrated to a liquidity pool). You can filter by keyword, launchpad, and various trading metrics. See AlphaScan for full details.\nHow do I show only tokens that bonded in the last few hours on AlphaScan?\nUse the column filters, not a timeframe: AlphaScan has no 5m / 1h / 6h / 24h selector (that is a Discover feature) and its metrics use a fixed 24-hour window. Click the filter button in the Bonded column header, open the Audit group, set a Bonded Age (mins) maximum (360 for six hours), then Save All . See Filtering a column .\nWhat are Launchpad Runners?\nRunners are tokens that meet all of the following criteria at the end of a 24-hour window from their launch:\n- Market Cap ≥ $1,000,000\n- Liquidity ≥ $100,000\n- Holders ≥ 1,000\n- Organic Score ≥ 75.0\nRunner status does not mean a token is safe or will maintain its performance. See Launchpad Screener & Runners for details.\nHow can I get my launchpad listed in the Launchpad Screener?\nJupiter currently supports launchpads built on Meteora DBC (Dynamic Bonding Curves) out of the box. If your launchpad uses Meteora DBC, you can get routing through Jupiter and 100+ partners via the API, real-time indexing with individual token pages, and AlphaScan support plus a dedicated screener page. To get listed, request it through the Meteora team, which coordinates DBC launchpad listings with Jupiter. Launchpads built on other technologies are evaluated case by case: contact the Jupiter team at support.jup.ag . See Launchpad Screener & Runners for details.\nWhy is my watchlist getting reset?\nYour Jupiter watchlist is stored in your browser’s cache. If the cache is cleared, your watchlist will reset. This can happen if:\n- You manually clear browser data.\n- Your device automatically clears cache.\n- A browser extension interferes with storage.\n- You use private/incognito mode.\n- You open Jupiter on a different device or browser.\nTo keep your watchlist intact, use the same browser regularly and avoid clearing cache.\nHow can I reclaim SOL locked in unused token accounts?\nWhen you trade tokens on Solana, your wallet pays a small SOL deposit (rent) to keep each token account open. If you no longer hold a token, the account is empty but the rent stays locked. Accounts you still use can also hold more rent than Solana now requires, and that excess can be reclaimed without closing them. Rent Reclaim is available at three places on jup.ag: the homepage (if you have 10 or more reclaimable accounts), the wallet side drawer, and the My Positions toolbar on token pages. Choose the accounts and tokens to include, then click Reclaim: empty accounts are closed and the excess rent of the others is returned. If you dismissed the homepage notification, use the wallet side drawer or the My Positions toolbar instead. Note that Rent Reclaim is currently not compatible with Trust Wallet’s in-app browser. See What is Jupiter Spot? for more details.\nLimitations\nCan I export my swap history?\nJupiter does not currently offer a native export feature for swap or order history. For swaps (Ultra and Manual Mode):\n- Your swap activity is visible in the Portfolio drawer under the Activity tab.\n- For a full transaction record, view your wallet on a block explorer like Solana Explorer or Solscan , where you can download transaction data.\nFor Limit Orders and DCA orders:\n- Order history is visible on the dedicated pages ( jup.ag/limit , jup.ag/recurring ) and in the Portfolio drawer.\nFor a broader view of activity across multiple Solana protocols, you can use Jupiter Portfolio .\nCan I check my swap volume?\nThere is no dedicated volume checker on Jupiter at this time. You can use the feature in Positions to review your trading activity.\nCan I buy an exact amount of a token?\nCurrently, you cannot set the exact amount of tokens you want to receive on Jupiter. The previous ExactOut option was removed because it often resulted in worse pricing compared to regular swaps.\nCan I pause my DCA order temporarily?\nNo, Jupiter does not currently support pausing and resuming DCA orders. If you need to stop, you must cancel the order and create a new one when ready to continue.\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.arbitrum.foundation/t/stableguard-by-fintechcheck-real-time-stablecoin-depeg-detection-for-treasury-defi-protection/31204","domain":"forum.arbitrum.foundation","title":"StableGuard by FintechCheck: Real-Time Stablecoin Depeg Detection for Treasury & DeFi Protection - General - Arbitrum","hash":"b239cad498732b1cadd49b73f9291680443ac7df8451df4d0809d4201636ebc7","tokens":9999,"chars":39993,"crawler":"crawler-f6nn","verified":"exact","ts":1791172386800,"text":"Arbitrum\nStableGuard by FintechCheck: Real-Time Stablecoin Depeg Detection for Treasury & DeFi Protection\nGeneral\nproposal ,\nproposal-discussions\nMatthew77\nAugust 13, 2026, 10:54am\n1\nHi all,\nI’m Matthew, founder of FintechCheck, building real-time DeFi risk monitoring infrastructure. I wanted to introduce StableGuard, our onchain depeg protection system, and explore whether it could be useful to ArbitrumDAO’s treasury operations or wider ecosystem.\nWhat StableGuard does:\n- Real-time monitoring across 19+ stablecoins with confidence-scored depeg detection (price feed + DEX divergence + market stress signals)\n- Backtested at 83.8% classification accuracy across 260,950+ data snapshots and 37 real historical depeg events\n- Live Chainlink integrations: Price Feeds, Automation, CCIP, with a CRE-based workflow currently in deployment for automated protective actions (e.g. vault-pausing on detected depeg risk)\n- Contracts live and tested on Sepolia; production deployment in progress\nWhy this could matter for Arbitrum:\nArbitrum’s treasury and DAO-affiliated protocols hold significant stablecoin reserves. An independent, real-time risk signal — not built by the stablecoin issuers themselves — offers a credibility advantage: early warning before a depeg event affects treasury value or dependent protocols. Given Arbitrum’s recent move to support agentic payment infrastructure (x402/MPP), this also aligns with the broader push toward automated, onchain financial tooling.\nWhat I’m looking for:\nFeedback from delegates and the Treasury Management Council on whether this is a gap worth addressing, and whether there’s an appropriate grant or procurement pathway (noting the DAO has previously run a data monitoring procurement process) to pilot this for Arbitrum-related treasuries or ecosystem protocols.\nHappy to answer technical questions or share a live demo.\nThanks for reading — open to any feedback.\nMatthew\nFintechCheck / StableGuard\n2 Likes\ncxclrfx\nAugust 13, 2026, 4:55pm\n2\nThe problem is real, but the current public evidence does not yet support an automated treasury-protection claim.\nI reviewed the published methodology and the current pegcheck / StableGuard implementation. The main issue is not the idea of depeg monitoring. It is that four different layers are currently being collapsed into one result:\nmarket observation → event classification → confidence state → admissible protective action\nThose layers need separate proof.\n1. The reported 83.8% is not classification accuracy\nThe repository defines 37 events by applying the system’s own HEDGE threshold and grouping threshold crossings separated by more than three hours.\nIt then calls 31 of those 37 events “confirmed” because the signal persisted for at least two consecutive hourly readings.\nTherefore:\n31 / 37 = 83.8%\nis a persistence or confirmation rate among system-generated threshold events .\nIt is not classification accuracy against an independent ground-truth event set.\nThe published material does not currently establish:\n- false negatives;\n- precision or recall;\n- specificity;\n- calibration of the confidence score;\n- out-of-sample performance;\n- detection lead time before a material depeg;\n- false protective-action rate;\n- cost-weighted consequences of pausing when the signal is wrong.\nThe 260,950 snapshots describe the observation corpus. They do not become labelled classification examples merely because a threshold was applied to them.\nThe claim should therefore be renamed and bounded exactly. A proper protection backtest requires a preregistered event definition, independent event labels, forward-time validation, per-asset results, lead-time distribution, and explicit false-action costs.\n2. The 19-asset monitor and the on-chain actuator are different systems\nThe off-chain monitor covers 19 stablecoins on an hourly schedule and aggregates multiple web/API sources.\nThe current on-chain StableGuard.sol path evaluates only USDC and DAI through Chainlink feeds, with one optional Uniswap V3 pool.\nThe off-chain confirmation rate cannot be used as validation of the on-chain action contract unless the exact same:\n- assets;\n- sources;\n- sampling frequency;\n- thresholds;\n- persistence rules;\n- freshness rules;\n- execution semantics\nare bound into one reproducible evaluation.\nAt present, the monitoring surface and the autonomous action surface have different evidence contracts.\n3. The protection threshold contradicts the confidence description\nIn StableGuard.sol , a Chainlink depeg alone produces score = 3 .\nThe source contract sends a CCIP alert at score >= 3 .\nThe destination StableGuardReceiver then calls vault.pause() at score >= 3 .\nThat means the automated pause path is activated by one Chainlink feed , not by a two-source high-confidence state.\nThe Uniswap confirmation raises the score to 5, but score 5 is not required for the destination action.\nThe code comments describe score 5 as the full-protection response, while the receiver performs the protection at score 3. The action boundary and the public confidence narrative therefore do not match.\nA defensible separation would be:\n- one fresh source: observation or warning;\n- two genuinely independent, asset-specific sources: confirmed depeg;\n- persistence and liquidity checks: protection admissible;\n- destination policy: exact action authorised.\n4. The DAI cross-check is not bound to DAI\nThe contract stores one uniswapPool , documented as a USDC/USDT pool.\nThat same pool is used to add the +2 DEX confirmation both when USDC is depegged and when DAI is depegged.\nA USDC/USDT divergence is not independent confirmation of a DAI/USD depeg.\nEven for USDC, a USDC/USDT pair divergence proves only that the pair moved. It does not identify which side caused the divergence without an external reference.\nFor DAI, the source is semantically unrelated.\nEvery confidence contribution must be bound to:\nasset → quote asset → venue → pool identity → liquidity → observation window → direction\nand a DEX confirmation should use an asset-relevant TWAP with a liquidity floor, not an instantaneous slot0 reading.\n5. “Real-time” freshness and cross-chain execution need a state machine\nThe current feed freshness boundary accepts Chainlink data up to 24 hours old.\nThat is incompatible with an autonomous real-time pause path. Freshness should be feed-specific and action-specific.\nThe source contract also permits a new broadcast every five minutes while the condition remains true. performUpkeep is publicly callable and recomputes the signal, so any caller can repeatedly advance the fee-spending CCIP path during a sustained depeg after each cooldown.\nThe destination side has no explicit:\n- transition identifier;\n- processed-message ledger;\n- evidence expiry;\n- alert supersession;\n- recovery state;\n- retry state;\n- all-destination reconciliation;\n- asset-to-vault exposure binding.\nThe receiver pauses any configured vault for any accepted symbol at score 3. It does not establish that the vault is exposed to the alerted asset.\nCCIP delivery failures are handled destination by destination. Some destinations can therefore receive and act while others fail, leaving the system in a partially protected cross-chain state without a reconciliation contract.\nThe correct object is not a repeated alert. It is an idempotent state transition:\nNORMAL → WATCH → CONFIRMED_DEPEG → PROTECTION_PENDING → PROTECTED → RECOVERY_PENDING → NORMAL\nEach transition should carry:\n- stable event ID;\n- asset and exposure scope;\n- source observations and timestamps;\n- evidence root;\n- confidence components;\n- threshold version;\n- source-chain block and finality state;\n- destination action policy;\n- expiry;\n- supersession/recovery rule;\n- per-destination completion state.\n6. What should be demonstrated before an Arbitrum treasury pilot\nA credible pilot should publish two separate records.\nDetection record\n- independent historical event baseline;\n- forward-time train/test separation;\n- per-stablecoin precision, recall and false-negative count;\n- false alarms per observation-day;\n- median and worst detection lead time;\n- score calibration;\n- source-ablation results;\n- results under stale, unavailable and conflicting sources;\n- DEX manipulation and low-liquidity tests.\nAction record\n- exact evidence state required for alert, hedge, pause and recovery;\n- asset-to-vault exposure binding;\n- idempotent cross-chain transition ID;\n- destination acknowledgement and retry ledger;\n- partial-delivery handling;\n- stale-message rejection;\n- maximum action latency;\n- human/governance override;\n- recovery and unpause policy;\n- invariant tests proving that one source, one pool, or one delayed message cannot silently cause an unintended treasury action.\nStableGuard is aimed at a real problem, and the public implementation is far enough along to make the missing boundary visible.\nBut the key requirement is this:\nA depeg signal is not yet a protection decision. The system must prove which evidence state authorises which action, for which asset exposure, for how long, and with what recovery path.\nOnce that boundary is explicit, the project can be evaluated as treasury protection infrastructure rather than as a monitoring dashboard connected to an actuator.\n1 Like\nMatthew77\nAugust 13, 2026, 6:21pm\n3\nHi,\nThanks for taking the time to write this up, genuinely useful and you’re right on the core point.\nThe current receiver pauses on accepted symbol at score 3, it doesn’t verify the vault actually holds the alerted asset. That’s a real gap, not a nuance, since a symbol match isn’t the same as a proven exposure. Same with CCIP: I’ve been treating delivery as effectively atomic across destinations, which it isn’t, and there’s no reconciliation contract handling partial delivery today.\nThe state machine you laid out (NORMAL through RECOVERY_PENDING with a stable event ID and per-destination completion state) is a clean way to make the implicit alert loop explicit and idempotent. I’m going to build that as the next milestone rather than iterating on the alert logic further.\nSame for the two-record structure. Right now I have a demo and a single fork test proving one path works, not a detection record (precision/recall, false-negative count, lead time, ablation results) or an action record (exposure binding, retry ledger, stale-message rejection, override/recovery policy). That’s the actual bar for treasury-protection infrastructure vs a monitoring dashboard connected to an actuator, and I don’t think StableGuard clears it yet.\nI’m going to work through this as a build list over the next couple of weeks; asset-to-vault exposure binding and the idempotent transition object first, since everything else depends on those. Happy to share progress as it lands, and if you’re willing, I’d value a second pass once the exposure binding and transition object are in place.\nThanks again, this was exactly the kind of feedback I needed.\nCheera\nMatthew\ncxclrfx\nAugust 13, 2026, 6:44pm\n4\nThat sequencing is correct.\nExposure binding and the idempotent transition object are the right first milestone. Before extending the alert logic further, I would lock three invariants into the implementation and tests:\n- An alert for an asset the vault does not actually hold must be incapable of changing vault state.\n- Duplicate, stale, replayed or out-of-order CCIP messages must never produce an illegal transition.\n- Partial delivery across destinations must always reconcile back to one canonical event state, with no ambiguity about which destinations are complete, pending, superseded or failed.\nKeep the detection record and the action record separate while doing this. A detection can be valid while the resulting treasury action is still inadmissible.\nOnce the exposure binding and transition object are in place, send the implementation or diff. I’ll review the transition semantics, replay/reconciliation boundaries and failure paths rather than just the happy-path flow.\n1 Like\nMatthew77\nAugust 13, 2026, 7:04pm\n5\nHi,\nAgreed on all three, and I’ll treat them as the acceptance criteria for this milestone rather than nice-to-haves:\n- Non-exposed asset cannot change vault state — enforced at the exposure binding layer, with the negative test (alert for asset A, vault holds only B, vault state must not change) as a required regression test, not just a manual check.\n- Duplicate/stale/replayed/out-of-order CCIP messages cannot produce an illegal transition — this pushes me toward making the event ID + sequencing part of the transition guard itself, not just a filter before it, so an out-of-order message is rejected by the state machine’s own transition rules rather than by something upstream that could be bypassed.\n- Partial delivery always reconciles to one canonical event state, with explicit per-destination status (complete/pending/superseded/failed) and no ambiguous in-between.\nAnd yes, keeping detection and action strictly separate. A valid depeg detection doesn’t imply an admissible action, that boundary is exactly what was missing before, so I’m not going to blur it back together for convenience.\nI’ll send the implementation/diff once exposure binding and the transition object are in, with the invariant tests included, not just the happy path. Given what you’re planning to review, I’ll make sure the replay/reconciliation and failure-path tests are easy to find and run in isolation.\nThanks, this is a genuinely useful bar to build against.\nCheers\nMatthew\nMconnectDAO\nAugust 14, 2026, 4:12am\n6\nStablecoin depeg monitoring is a relevant need for Arbitrum treasury and ecosystem protocols. However, monitoring signals should not directly become automated treasury actions without independent validation, asset specific evidence, strict freshness rules, human override, and a clear recovery process. A limited read only pilot with transparent performance reporting may be a safer first step than direct vault pause authority. @Matthew77\nMatthew77\nAugust 14, 2026, 8:06am\n7\nThanks, that’s a fair and honestly a safer path than what I originally proposed.\nI agree a read-only pilot is the right first step. Concretely, that would mean: StableGuard publishes depeg signals and its full evidence trail (source observations, confidence components, score) on-chain or via a public feed, but no vault ever receives pause authority during this phase. Treasury/protocol teams could consume the signal and decide manually whether to act, with StableGuard reporting precision, recall, false-alarm rate, and detection lead time openly the whole time.\nThat also lines up with feedback I’ve had elsewhere on this thread, separating detection from action, since a valid detection shouldn’t imply an admissible automated action. A read-only pilot forces that separation by construction rather than by policy, which is a stronger guarantee.\nIf/when there’s a case for moving beyond read-only, I think the bar should be: independent validation of the signal, asset-specific evidence (not just symbol matching), strict message freshness rules, human override on any action, and a defined recovery/unpause process, before any automated vault authority is even discussed.\nHappy to scope a read-only pilot proposal along those lines if that’s useful.\nMatthew77\nAugust 19, 2026, 4:16pm\n8\nUpdate since my last reply, in case useful — the pieces I said I’d build toward that read-only pilot are now actually built and public, not just planned:\nAsset-specific evidence — exposure binding verifies a vault actually holds the affected asset before any action is even considered; a depeg alert for an asset a vault doesn’t hold can’t trigger anything, and this is unit-tested.\nFreshness / replay safety — the transition state machine rejects stale or replayed messages once a destination has settled, preventing duplicate or out-of-order actions.\nDetection Record, published — 49 objectively-labeled historical depeg events (including UST/LUNA and the SVB/USDC event), scored against the actual detection logic: 100% recall, 0 false negatives, with precision explained honestly (early-warning signals are supposed to fire on ordinary noise, that’s not a flaw). Full methodology and labeling rules are documented, not just the headline numbers.\nAction Record, published — documents exactly what evidence is required before each action (alert/pause/recovery), citing the specific tests that prove it, and explicitly lists what’s not yet proven (still pending real cross-chain CCIP conditions) rather than glossing over gaps.\nRecovery process — this was the one open question even I flagged as unresolved. It’s now fully automatic: a vault only unpauses after sustained confirmation the price has genuinely stabilized (not a single data point), with no human step required, and no reliance on someone remembering to trigger recovery manually. Also closed a real edge case where a slow-recovering incident could otherwise leave a vault stuck paused indefinitely with nothing tracking it.\nAll of this is sitting in open PRs with an external reviewer right now (unrelated to Arbitrum — a security-minded community contact), so it’s genuinely being scrutinized, not just self-reported.\nGiven where things stand, I think the read-only pilot proposal I mentioned is worth actually writing up properly now, backed by this instead of intentions. Happy to put that together if there’s continued interest — would rather have something concrete to react to than keep describing plans.\n1 Like\nMatthew77\nAugust 27, 2026, 12:22am\n9\nThanks for laying out those three invariants clearly — all three are now built and tested, matching your framing:\n- Exposure binding: an alert for an asset the vault doesn’t hold can’t change vault state — unit tested.\n- Duplicate/stale/replayed/out-of-order messages can’t produce an illegal transition — the transition object rejects writes to any destination once it’s left PENDING.\n- Partial delivery reconciles to one canonical event state — lookup-before-create keeps one active event per coin, with explicit COMPLETE/PENDING/SUPERSEDED/FAILED states, no ambiguity.\nDetection record and action record are kept separate, as you suggested — published separately, with the action record explicitly noting which parts are still unproven pending real CCIP conditions.\nMy account isn’t letting me post a link here (getting a ‘can’t post a link to a host’ error) — the implementation is on GitHub, search for the user matsblocknode1957 hyphen oss, repo name depegguard hyphen skill, pull request number 1. Happy to send the actual link another way if that’s easier — just let me know.\nApologies if this should have come to you directly sooner — I think it went to a different contact by email rather than here. Happy to answer anything on the transition semantics, replay/reconciliation boundaries, or failure paths whenever you get a chance to look.\ncxclrfx\nAugust 27, 2026, 2:46am\n10\nDepegGuard / StableGuard — Second-Pass Technical Review\nMatthew, this will be a long description because the issue is not a single defect; it affects the structure of the code as a whole.\nAppreciate for the implementation update and for publishing the contracts, workflow, tests, and ACTION_RECORD.md openly. The first three invariants are no longer merely described; they are represented in code and tests:\n- an alert for an unregistered exposure cannot enter the pause path;\n- destination slots reject writes after they leave PENDING ;\n- lookup-before-create preserves one active event per coin and makes terminal closure explicit.\nThe separation between the detection record and the action record is also the correct direction, and the explicit list of conditions that remain unproven is materially better than presenting local tests as production evidence.\nThis second pass is therefore not a rejection of that work. It is the next layer exposed by the fact that the original layer was implemented successfully. The remaining problems now sit mainly between individually reasonable state machines :\nobservation state\n≠\nasset-incident state\n≠\nphysical vault state\n≠\ndelivery-attempt state\nThe current branch still collapses some of those identities into one another. That produces several reachable cases in which the event ledger and the physical system can disagree.\nReview target:\n- implementation branch: feat/automatic-recovery\n- implementation commit: 8ffd1dd7845bd8d2288e3fd1b5ffe2a3535737bf\n- documentation commit: 999baaa4bcc47f25c5df1475bf4c75228083d819\nThe reviewed implementation reports 85/85 tests passing. The analysis below is state-space and code-path review: it focuses on cross-object combinations that the current tests do not represent, so the existing pass count does not close these findings.\nExecutive conclusion\nI would not connect the current receiver to a real multi-asset vault or real asynchronous delivery path yet.\nFive items are production blockers:\n- independent asset incidents can independently unpause one shared vault;\n- resumeProtectionTracking() can manufacture an incident for the wrong asset from the single fact that the vault is paused;\n- report acceptance authenticates the Forwarder but not the intended workflow identity;\n- report replay and duplicate asset entries can satisfy stabilityWindow without new observations;\n- transferring the registry controller to the receiver makes several documented control and recovery operations unreachable.\nThe remaining findings concern attempt identity, partial-delivery truth, reconciliation, TTL determinism, evidence lineage, asset identity, and configuration hardening. They are all repairable without discarding the work already completed.\nI. Blocking invariants\nB-01 — Per-asset incidents control one global vault actuator\nSeverity: Blocker\nStatus: Confirmed from the current control flow\nStableGuardCREReceiver has one immutable vault , but it loops over an array of coins and advances a separate active event for each coin. When any one coin reaches RECOVERY_PENDING , the receiver calls vault.unpause() directly. There is no check for another active protected incident attached to the same vault.\nRelevant code:\n- StableGuardCREReceiver.sol , recovery branch\n- StableGuardCREReceiver.sol , one immutable vault\n- config.production.json , four configured assets\nReachable trace\nUSDC incident = PROTECTED\nUSDT incident = PROTECTED\nvault.paused() = true\nUSDC then produces stabilityWindow accepted stable calls\nUSDC incident -> RECOVERY_PENDING\nreceiver processes USDC\nreceiver calls vault.unpause()\nUSDC destination -> COMPLETE\nUSDC may eventually -> NORMAL\nUSDT incident is still PROTECTED\nbut vault.paused() = false\nThe USDC event has authority over a physical actuator that is also enforcing the USDT event. The logical scope is per asset; the actuator scope is per vault. Those scopes are not equivalent.\nThis is not solved by making pause() and unpause() idempotent. Idempotence prevents a revert; it does not preserve the conjunction of active protection requirements.\nRequired invariant\nFor every vault V :\nV may be unpaused\niff\nthere is no active protection hold requiring V to remain paused.\nFormally:\nunpauseAllowed(V) <=> activeHoldCount(V) == 0\nRecommended repair\nIntroduce a vault-level protection coordinator or equivalent hold ledger:\nstruct ProtectionHold {\nbytes32 holdId;\nbytes32 rootIncidentId;\nbytes32 assetId;\naddress vault;\nbool active;\n}\nmapping(address vault => uint256 count) public activeHoldCount;\nmapping(bytes32 holdId => ProtectionHold) public holds;\nProtection becomes:\nacquire hold for (vault, asset, rootIncident)\nif activeHoldCount changed 0 -> 1:\nphysically pause vault\nRecovery becomes:\nrelease only this incident's hold\nif activeHoldCount changed 1 -> 0:\nphysically unpause vault\nelse:\nkeep vault paused\nThe physical action must be derived from the aggregate hold set, not from the state of one coin event.\nMinimal alternative\nIf a vault is intentionally single-asset, make that restriction structural:\none receiver instance\n+ one vault\n+ one canonical assetId\n+ no multi-coin action loop\nThat is a valid smaller design. What is unsafe is advertising a multi-coin receiver while retaining a one-bit actuator with no aggregate authority model.\nMissing test\n1. Register USDC and USDT exposure for the same vault.\n2. Drive both incidents to PROTECTED.\n3. Feed stabilityWindow stable reports for USDC only.\n4. Continue feeding HEDGE for USDT.\n5. Assert USDC can close its own hold.\n6. Assert vault remains paused while the USDT hold remains active.\nB-02 — resumeProtectionTracking() reconstructs causality from the wrong fact\nSeverity: Blocker\nStatus: Confirmed; batch order changes the result\nThe continuation branch is evaluated when:\neventId == bytes32(0) && vault.paused()\nIt then creates a fresh PROTECTED event for the coin currently being processed. This happens before the exposure gate, and it does not require:\n- a prior event for that coin;\n- a prior event that expired;\n- a parent event ID;\n- an active hold belonging to that coin;\n- evidence that this coin caused the pause;\n- evidence that the existing pause belongs to DepegGuard at all.\nRelevant code:\n- StableGuardCREReceiver.sol , continuation branch before exposure check\n- DepegEventRegistry.sol , fresh PROTECTED event construction\nSingle-report reproduction\nTake one report with ordered arrays:\ncoins = [USDC, USDT]\nsignalLevels = [HEDGE, STABLE]\nAssume both coins have no active event and USDC is registered as an exposure.\nThe receiver loop executes sequentially:\nUSDC:\nprocessReport -> CONFIRMED_DEPEG\ninitiateProtection\nvault.pause()\nUSDC -> PROTECTED\nUSDT:\nprocessReport(STABLE) -> (0, NORMAL)\neventId == 0\nvault.paused() == true\nresumeProtectionTracking(USDT, ...)\nUSDT -> PROTECTED\nThe system has now created a protected USDT incident even though the same report said USDT was stable and no prior USDT incident existed.\nWorse, reversing the array order changes the result:\n[USDT STABLE, USDC HEDGE]\nUSDT is processed before the vault is paused, so no USDT event is created. The final state therefore depends on array order, not only on the observations.\nThat violates permutation invariance for a report whose coin observations are logically independent.\nConsequence\nThe fabricated USDT event can later accumulate stable calls, enter RECOVERY_PENDING , and invoke vault.unpause() while the real USDC depeg remains active. In combination with B-01, this creates a complete false-unpause path.\nRequired invariant\nA continuation event may exist only if it inherits a verified, still-active\nprotection hold for the same (vault, assetId, rootIncidentId).\nA global physical bit such as paused() can confirm physical state, but it cannot identify the cause of that state.\nRecommended repair\nDo not infer incident lineage from vault.paused() .\nEither remove resumeProtectionTracking() entirely by separating hold lifetime from event-epoch lifetime, or require explicit lineage:\nfunction resumeProtectionTracking(\nbytes32 parentEventId,\nbytes32 rootIncidentId,\nbytes32 holdId,\nbytes32 assetId,\nbytes32 observationId\n) external returns (bytes32 newEventId);\nThe registry must verify:\nparentEvent is terminal for an allowed continuation reason\nparentEvent.assetId == assetId\nhold[holdId].active == true\nhold[holdId].assetId == assetId\nhold[holdId].rootIncidentId == rootIncidentId\nhold[holdId].vault == destination vault\nA new event epoch may be created, but it must not create a new causal history.\nMissing tests\n- [A=HEDGE, B=STABLE] must not create a B incident.\n- Reversing the order to [B=STABLE, A=HEDGE] must produce the same logical state.\n- A vault paused for an unrelated reason must not permit any continuation event.\n- An expired A event must not authorize continuation for B.\n- A continuation must fail if the corresponding hold was already released.\nB-03 — The receiver authenticates a Forwarder, not the intended workflow\nSeverity: Blocker before state-changing production use\nStatus: Confirmed security-boundary gap\nThe receiver checks only:\nif (msg.sender != forwarder) revert UnauthorizedForwarder(msg.sender);\nThe metadata argument is explicitly ignored. Therefore, the consumer does not distinguish the intended DepegGuard workflow from another valid workflow delivered through the same Chainlink Forwarder.\nRelevant code:\n- StableGuardCREReceiver.sol , metadata intentionally unused\n- Chainlink ReceiverTemplate , workflow ID/owner/name validation\n- Chainlink consumer-contract guidance\nThe Forwarder check proves the delivery channel. It does not, by itself, prove the application-level author of the report.\nRequired invariant\nA state-changing report is accepted only when:\ncaller == configured Forwarder\nAND workflowId == expectedWorkflowId\nAND workflowOwner == expectedWorkflowOwner\nAND destination chain == configured chain\nAND receiver == address(this)\nWorkflow name may be checked as an additional label, but it should not be used without owner validation; the official template makes that distinction explicitly.\nRecommended repair\nInherit from or reproduce the relevant checks from ReceiverTemplate and configure at least:\nexpected Forwarder\nexpected workflow ID\nexpected workflow owner/author\nAlso ensure that chain selector and receiver identity are authenticated and bound before any state mutation, whether through authenticated CRE metadata, a signed report envelope, or an equivalent domain-separated mechanism, so a report cannot be validly reused in another domain.\nMissing tests\n- correct Forwarder + wrong workflow ID → revert;\n- correct Forwarder + wrong workflow owner → revert;\n- correct workflow + wrong receiver domain → revert;\n- correct workflow + wrong chain selector → revert;\n- correct metadata and report → accepted.\nB-04 — stabilityWindow counts calls, not fresh observations\nSeverity: Blocker\nStatus: Confirmed\nWhile an event is PROTECTED , each call to processReport() with a score below watchThreshold increments stableCount . The registry receives no observation sequence, source timestamp, report ID, or digest that must be unique. The receiver also does not reject the same coin appearing more than once in a report array.\nRelevant code:\n- DepegEventRegistry.sol , stableCount increments per call\n- StableGuardCREReceiver.sol , unbounded coin loop without uniqueness checks\n- Chainlink warning: signed reports can be replayed\nChainlink’s own documentation states that signed reports can be replayed on another chain or resubmitted on the same chain and that state-changing consumers must embed and verify protective metadata.\nTwo direct failure modes\nA. Report replay\nWith stabilityWindow = 3 :\none genuine stable observation\nsame signed report delivered three times\nstableCount: 0 -> 1 -> 2 -> recovery\nThe system interprets repeated delivery of one observation as three consecutive observations.\nB. Duplicate coin entries inside one accepted report\ncoins = [USDC, USDC, USDC]\nsignalLevels = [STABLE, STABLE, STABLE]\nThe receiver loops three times and calls processReport() three times in one transaction. The same payload can satisfy the entire stability window immediately.\nRequired invariant\nstableCount may advance at most once per asset per accepted observation sequence.\nA stronger definition is:\naccepted observation n+1 must have:\nsequence > lastAcceptedSequence\nsourceObservedAt > lastAcceptedSourceObservedAt\nsourceObservedAt within an allowed freshness window\nassetId unique within the report\nRecommended report envelope\nstruct ReportEnvelope {\nbytes32 workflowId;\nuint64 sourceChainSelector;\naddress receiver;\nuint64 sequence;\nuint64 sourceObservedAt;\nuint64 validUntil;\nbytes32 payloadDigest;\nCoinObservation[] observations;\n}\nstruct CoinObservation {\nbytes32 assetId;\nbytes32 feedId;\nint192 rawPrice;\nbytes32 evidenceDigest;\n}\nThe receiver should reject:\nsequence <= lastAcceptedSequence[workflowId]\nsourceObservedAt <= lastObservedAt[assetId]\nblock.timestamp > validUntil\nsourceObservedAt too far in the future\nsourceObservedAt older than maxReportAge\nrepeated assetId within one envelope\nwrong chain selector\nwrong receiver\nwrong workflow identity\nOnly after those checks should the registry receive an accepted observation ID and update stableCount .\nMissing tests\n- replay the exact same stable report stabilityWindow times; count must advance once;\n- submit the same sequence with modified payload; reject;\n- submit a lower sequence; reject;\n- submit a stale timestamp; reject;\n- include the same asset twice in one report; reject atomically;\n- submit two distinct fresh reports; count advances twice.\nB-05 — Controller transfer creates an authority dead-end\nSeverity: Blocker for documented operations\nStatus: Confirmed integration defect\nDepegEventRegistry has one controller . The documented deployment flow transfers that role to StableGuardCREReceiver . The integration test does exactly that.\nRelevant code:\n- DepegEventRegistry.sol , single controller and transfer\n- exposure-binding.test.js , controller transferred to receiver\nAfter transfer, only the receiver contract can call controller-gated methods. However, the receiver exposes no governance or forwarding entry point for:\n- retryFailedDestinations() ;\n- supersede() ;\n- manual initiateRecovery() ;\n- future transferController() ;\n- a customer-held early-unlock or override path described in ACTION_RECORD.md .\nAn EOA or multisig cannot call those registry functions because it is no longer controller. The receiver cannot spontaneously call them because no external function instructs it to do so.\nThis means several advertised recovery and governance paths become unreachable in the deployed composition even though they are callable in isolated registry tests.\nRecommended repair\nReplace the single controller with explicit capabilities:\nREPORTER_ROLE\naccepts authenticated observations and score transitions\nACTION_ROLE\nrecords destination callbacks and dispatch results\nRETRY_ROLE / KEEPER_ROLE\nretries or times out delivery attempts\nGOVERNANCE_ROLE\nchanges configuration, supersedes eligible incidents,\nauthorizes exceptional recovery, rotates roles\nPAUSE_COORDINATOR_ROLE\nacquires/releases physical vault holds\nA multisig or timelocked governance contract should retain governance and role-rotation authority. The CRE receiver should receive only the minimum roles required for automatic operation.\nIf the single-controller model is retained, the receiver needs explicit, access-controlled forwarding methods for every operation that must remain reachable. That is less clean but still better than an unreachable authority graph.\nMissing test\nDeploy exactly as intended, transfer control to the receiver, and prove that the designated governance identity can still:\n- retry a failed destination;\n- apply an allowed override;\n- rotate the receiver/controller;\n- supersede a pre-protection incident;\n- recover from a receiver upgrade or key compromise.\nII. Asynchronous delivery and reconciliation\nH-01 — A destination slot has no delivery-attempt identity\nSeverity: High before real CCIP/asynchronous integration\nStatus: Confirmed design gap\nA Destination contains only:\nchainSelector\nvault\nstate\nA callback contains only:\neventId\ndestIndex\nnewDestState\nA retry changes only:\nFAILED -> PENDING\nRelevant code:\n- Destination structure\n- destinationCallback()\n- retryFailedDestinations()\nDangerous ordering\nattempt 1 dispatched\nattempt 1 reports FAILED\nslot becomes FAILED\nattempt 2 is queued\nslot becomes PENDING\nlate callback from attempt 1 arrives before attempt 2 callback\nslot is currently PENDING\nold callback is accepted as the result of attempt 2\nThe sticky-slot rule correctly prevents a callback from overwriting COMPLETE . It does not distinguish two different attempts that occupy the same PENDING state at different times.\nThe existing stale-callback test covers:\nretry succeeds -> slot COMPLETE -> stale FAILED arrives\nThat case is rejected. The untested and dangerous interval is:\nretry requeued -> slot PENDING -> stale old callback arrives -> new callback has not arrived yet\nRequired identity\nDestination identity != Delivery-attempt identity\nRecommended attempt record:\nenum Phase { PROTECTION, RECOVERY }\nenum AttemptState { PENDING, COMPLETE, FAILED, TIMED_OUT, SUPERSEDED }\nstruct DeliveryAttempt {\nbytes32 eventId;\nPhase phase;\nbytes32 destinationKey;\nuint32 attemptNo;\nbytes32 messageId;\nuint64 startedAt;\nuint64 deadline;\nAttemptState state;\n}\nThe callback must bind at least:\neventId\nphase\ndestinationKey\nattemptNo\nmessageId\nresult\nA callback for attempt n must never be able to settle attempt n+1 .\nMissing test\n1. attempt 1 -> FAILED\n2. queue attempt 2 -> PENDING\n3. deliver late COMPLETE or FAILED from attempt 1\n4. assert rejection because messageId/attemptNo is stale\n5. deliver attempt 2 callback\n6. assert only attempt 2 changes current destination state\nH-02 — A retried destination can become permanently non-retryable\nSeverity: High\nStatus: Confirmed liveness gap\nretryFailedDestinations() is allowed only from PARTIALLY_PROTECTED or PARTIALLY_RECOVERED and changes a failed slot to PENDING . settlePending() is explicitly not available in the PARTIALLY_* states.\nIf the retried asynchronous message never returns:\nslot remains PENDING\nretry cannot be called again because slot is not FAILED\nsettlePending cannot be called because event is PARTIALLY_*\nThe only remaining bound is the outer event TTL. That can leave the system unable to retry for the full incident lifetime.\nRecommended repair\nGive each attempt its own deadline and a permissionless timeout transition:\nPENDING --after attemptDeadline--> TIMED_OUT\nTIMED_OUT -> eligible for next attempt\nThe event’s outer TTL should cap the incident; it should not substitute for per-attempt liveness.\nMissing test\nPARTIALLY_PROTECTED\nfailed destination retried\nnew attempt never callbacks\nattempt deadline passes\ntimeout marks attempt TIMED_OUT\nnext retry is permitted before outer eventTTL\nH-03 — pendingTTL collapses partial physical truth into global FAILED\nSeverity: High\nStatus: Confirmed\nConsider two destinations:\ndestination A = COMPLETE\ndestination B = PENDING\nBecause not all destinations are settled, the event remains PROTECTION_PENDING . After pendingTTL , either settlePending() or a subsequent callback terminates the entire event as FAILED .\nRelevant code:\n- destinationCallback() , timeout before recording the slot callback\n- settlePending() , whole-event termination\nThe ledger then says:\nEvent = FAILED\nwhile physical reality says:\nA is protected\nB timed out\nThis discards exactly the partial-delivery state that PARTIALLY_PROTECTED and PARTIALLY_RECOVERED were introduced to preserve.\nRecommended repair\nAt pending timeout:\n- mark only still- PENDING attempts as TIMED_OUT ;\n- preserve already COMPLETE destinations;\n- evaluate the aggregate state;\n- produce:\n- PROTECTED if all effective destinations completed;\n- PARTIALLY_PROTECTED if at least one completed and at least one failed/timed out;\n- FAILED only if none completed;\n- mirror the same logic for recovery.\nThe event state should summarize destination truth, not erase it.\nMissing tests\n- one complete + one pending at timeout → PARTIALLY_PROTECTED ;\n- one complete + one pending at recovery timeout → PARTIALLY_RECOVERED ;\n- all pending time out → FAILED ;\n- completed destination remains queryable and unchanged after timeout.\nH-04 — Physical action and ledger acknowledgement can diverge permanently\nSeverity: High\nStatus: Confirmed reconciliation gap\nThe receiver performs the physical action first and then reports the result to the registry.\nRecovery divergence\nvault.unpause() succeeds\nregistry.destinationCallback(...) reverts\nThe receiver emits RegistryCallbackFailed , but the physical vault is already unpaused. On the next report, the event may still be RECOVERY_PENDING ; however, because vault.paused() is now false, the receiver skips the callback block entirely and only attempts finalizeRecovery() . finalizeRecovery() cannot succeed while the destination remains PENDING .\nRelevant code:\n- StableGuardCREReceiver.sol , unpause then callback; callback skipped if already unpaused"}
{"url":"https://docs.ipfs.tech/concepts/comparisons/","domain":"docs.ipfs.tech","title":"IPFS comparisons | IPFS Docs","hash":"5270fd4ac9f741b2b6ab7f9ed35c11da3dd86922344959e7bd904848a53c0d87","tokens":1039,"chars":4155,"crawler":"crawler-f6nn","verified":"exact","ts":1791172389275,"text":"IPFS Docs\n# IPFS comparisons\nIPFS is a general-purpose file system that uses a distributed hash table (DHT) to route and transfer content-addressed data. This sets it apart from other solutions with a more specific focus or use of a specific data storage mechanism. For example:\n-\nBitTorrent (opens new window) is a peer-to-peer (P2P) file-sharing protocol that uses a centralized tracker to manage the distribution of files among peers. It focuses on file-sharing rather than file storage.\n-\nStorj (opens new window) and Sia (opens new window) are decentralized cloud storage platforms that use distributed networks of nodes for data storage. They focus on providing cloud storage services rather than a general-purpose distributed file system.\n-\nArweave (opens new window) is a decentralized, permanent storage platform that uses a novel data structure called a \"blockweave\" for data storage. It focuses on providing permanent storage rather than a file-sharing system.\n-\nFilecoin (opens new window) is a decentralized storage network that allows users to rent out disk space. It focuses on providing a decentralized storage marketplace. It uses a proof-of-replication consensus mechanism and supports payment in various cryptocurrencies.\nFilecoin is built on IPFS and uses the IPFS network for data storage and retrieval. Filecoin and IPFS are complementary technologies providing decentralized and efficient storage solutions.\n-\nHypercore (opens new window) is a decentralized data-sharing tool that uses a distributed hash table (DHT) for data storage. It focuses on enabling data sharing and collaboration.\n-\nHolo (opens new window) is a decentralized hosting platform that uses a unique data storage and sharing mechanism called Holochain. It allows users to host and run web-based applications on a peer-to-peer network.\n-\nSwarm (opens new window) is a decentralized storage and sharing platform built on the Ethereum blockchain. It uses smart contracts and cryptographic techniques to securely store and share data. It focuses on providing a decentralized, secure, and censorship-resistant storage solution.\n# Comparing the key features of other solutions to IPFS\nThe following tables outline key features of different mechanisms and how they compare to IPFS.\nAll of these solutions use content-based addressing.\n# General protocols\ntechnology storage mechanism data model networking stack identifier address composition links use cases similarity to IPFS hashing algorithm\nbittorrent (opens new window) P2P file-sharing merkle DAG TCP/IP torrent file filename + sha1 hash - file sharing low SHA-256\nhypercore (opens new window) decentralized data-sharing merkle DAG UDP dat key dat key dat://{key} decentralized data sharing medium SHA-256\ngit (opens new window) version control commit history TCP/IP commit hash commit hash - version control medium SHA-1, SHA-256\nSecure Scuttlebutt (SSB) (opens new window) decentralized social network append-only log Scuttlebutt Protocol feed id feed id ssb://{feed id} decentralized social networking high SHA-256\n# Crypto-economic networks\ntechnology storage mechanism data model consensus mechanism networking stack identifier address composition use cases similarity to IPFS\nfilecoin (opens new window) blockchain-based storage merkle DAG proof-of-replication libp2p cid cid decentralized data storage high\nstorj (opens new window) decentralized storage erasure coding proof-of-retrievability UDP farmer ID farmer ID + file metadata encrypted cloud storage medium\nHolo (opens new window) decentralized application distributed hash table distributed hash table actor model agent ID agent ID decentralized applications medium\nSwarm (opens new window) decentralized storage distributed hash table proof-of-custody libp2p chunk ID chunk ID decentralized data storage high\nsia (opens new window) decentralized storage erasure coding proof-of-work UDP sector ID sector ID + file metadata encrypted cloud storage medium\narweave (opens new window) blockchain-based storage blockweave proof-of-access TCP/IP block ID block ID permanent data archiving low\nHelp us improve this site!\nEdit this page\nor\nopen an issue"}
{"url":"https://bitcoinops.org/en/matrix/","domain":"bitcoinops.org","title":"Bitcoin Feature Matrix | Bitcoin Optech","hash":"0e6044145c0cf6bdf06a13e90d2b5ca2d4b26e9cf2535267085654692585af5d","tokens":2794,"chars":11175,"crawler":"crawler-f6nn","verified":"exact","ts":1791172391879,"text":"Bitcoin Feature Matrix\ntracking interoperability of ₿itcoin products & services 🤝\nSelect features to display:\nPlatform\nHardware Wallet Interface\nFee Bumping\nDescriptors\nMulti-Party (PSBT, MuSig2, Coinjoin, Payjoin)\nPayment Codes, Silent Payments\nLightning\nLegend:\n✅ - Full Support / Yes This response can represent \"Send & Receive Support\" (i.e. Bech32) or \"Yes\" (i.e. Native Segwit Change).\n💸 - Send Support This response represents \"Send Only Support\" (i.e. Bech32).\n❌ - No Support / No This response represents \"No Support\" or simply \"No\".\n🤷 - Unknown This response represents uncertain status.\n➖ - Not Applicable This response represents that a given feature is NOT applicable for a Product/Service category. For example, Lighting Features would be \"Not Applicable\" for a Signing Device.\n✔ - Alternate Implementation / ² - Multiple Implementations These responses represents cases where a feature is implemented via a solution other than the one be specifically tested for. For example, for Payjoin, BIP78 is solution being tested for, however other solutions will be recognised (i.e. BIP79).\nProduct\n/\nService\nCategory Category of the Product/Service being tested.\nKey\nFeatures /\nUse Cases\n(hover) Short description of Product/Service focus or differentiating features.\nPlatform\nHWI Is hardware signer support implemented via the HWI Python Library?\nDefault\nReceive\nAddress What is the default receive address for the product / service?\nNative Segwit P2WPKH, P2WSH, and P2TR all belong to the category of Native Segwit outputs.\nFee Bumping\nDescriptors Does the Product/Service support Descriptors?\nMulti-Party Transactions\nPayment\nCodes BIP47\nSilent\nPayments BIP352\nLightning Lightning only sending (Pay Invoice) and receiving (Create Invoice) capabilities are considered.\nDevice Devices on which the Product/Service is available.\nOS Operating Systems for which the Product/Service is available.\nWeb /\nBrowser Does the Product/Service have a web or browser interface for users?\nBech32\nP2WPKH\nP2WSH Does the Product/Service support Bech32 (BIP173)?\n- To qualify as having Bech32 sending support, a product should be able to send to BOTH P2WPKH and P2WSH.\n- To qualify as having Bech32 receiving support, it is sufficient to receive to EITHER P2WPKH or P2WSH.\nBech32m\nP2TR Does the Product/Service support Bech32m (BIP350)?\nNative\nSegwit\nChange Does the Product/Service provide Native Segwit Change (P2WPKH, P2WSH, or P2TR)?\nFull RBF\nBump\nFee Can the Product/Service increase the fee rate of a previously submitted transaction?\nFull RBF\nCancel\nTXN Does the Product/Service support changing the outcome of previously submitted transactions, e.g. to cancel a payment?\nFull RBF\nNotification Does the Product/Service:\n- track when incoming transactions get replaced\n- and notify the user\n?\nCPFP Can the Product/Service create Child-Pays-For-Parent transactions to bump an:\n- incoming transaction\n- outgoing transaction\n- any transaction that pays a wallet\n- at least one of the above\n?\nPSBT\nVersion Does the Product/Service support PSBT V0 / V2 (BIP174 & BIP370)?\nPSBT\nExport Can the Product/Service export PSBT (BIP174 & BIP370)?\nPSBT\nUpdate /\nFinalize Can the Product/Service update/finalize PSBT (BIP174 & BIP370)?\nMuSig2 Does the Product/Service support MuSig2 (BIP327)?\nCoinjoin Does the Product/Service support Coinjoin?\nPayjoin * Does the Product/Service support Payjoin?\nBIP78 and Alternate Implementations are considered\nSend /\nReceive Does the Product/Service support Reusable Payment Codes (BIP47)?\nSend /\nReceive Does the Product/Service support Silent Payments (BIP352)?\nSend / Receive\n+ DNS\nAddress Does the Product/Service support Silent Payments (BIP352) + DNS Human Readable Addresses?\nBOLT 11 Does the Product/Service support sending and receiving payments (BOLT11)?\nBOLT 12 Does the Product/Service support sending and receiving payments via Offers (BOLT12)?\nBOLT 12\n+ DNS\nAddresses Does the Product/Service support sending and receiving payments via Offers (BOLT12) + DNS Human Readable Addresses?\nLNURL Does the Product/Service support sending and receiving payments via LNURL?\nLNURL +\nLightning\nAddresses Does the Product/Service support sending and receiving payments via LNURL + Human Readable Lightning Addresses?\nBitGo\nSoftware Wallet (L1&L2)\n\" Web-Based, Self-Custodial 2-of-3 Multisig Wallet and Lightning for Enterprise Customers \"\n💡\n➖\nNot Applicable\n➖\nNot Applicable\n✅\nYes\n❌\nNo\nP2WSH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n❌\nNo\n✅\nYes\n✅\nFull Support (send & receive)\n❌\nNo\nV0\n✅\nYes\n✅\nYes\n✅\nFull Support (send & receive)\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - No Support -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n✅\nFull Support (send & receive)\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\nBitcoin Core Wallet\nSoftware Wallet (L1)\n\" Open source project which maintains and releases Bitcoin client software called Bitcoin Core. \"\n💡\n💻\nDesktop\nLinux, OS, Windows\n❌\nNo\n✅\nYes\nP2WPKH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n✅\nYes\n❌\nNo\n✅\nFull Support (send & receive)\n✅\nYes\nV2\n✅\nYes\n✅\nYes\n✅\nFull Support (send & receive)\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - No Support -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\nBitkit\nSoftware Wallet (L1&L2)\n\" Your ultimate Bitcoin toolkit. Self-custodial BTC and LN payments. Widgets, pay-to-contacts and more \"\n💡\n📱\nMobile\nAndroid, iOS\n❌\nNo\n❌\nNo\nP2WPKH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n❌\nNo\n❌\nNo\n✅\nFull Support (send & receive)\n❌\nNo\n❌\nNo Support\n❌\nNo\n❌\nNo\n❌\nNo Support\n❌\nNo Support\n➖\nBIP78 - Not Applicable\nAlternate - Not Applicable -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n✅\nFull Support (send & receive)\n❌\nNo Support\n❌\nNo Support\n✅\nFull Support (send & receive)\n💸\nSend Support\nCasa\nSoftware Wallet (L1)\n\" High security + UX via multi-vendor multisig \"\n💡\n📱\nMobile\nAndroid, iOS\n❌\nNo\n✅\nYes\nP2SH-P2WSH\n💸\nSend Support\n💸\nSend Support\n❌\nNo\n❌\nNo\n❌\nNo\n❌\nNo\n❌\nNo Support\n✅\nYes\nV2\n✅\nYes\n❌\nNo\n❌\nNo Support\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - No Support -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\nCoin Wallet\nSoftware Wallet (L1)\n\" Self-custodial wallet since 2015. Supports: web app, mobile, desktop, and TOR \"\n💡\n💻 📱\nDesktop, Mobile\nAndroid, Linux, iOS, Windows\n✅\nYes\n❌\nNo\nP2WPKH\n✅\nFull Support (send & receive)\n❌\nNo Support\n✅\nYes\n✅\nYes\n✅\nYes\n❌\nNo\n❌\nNo Support\n❌\nNo\n❌\nNo\n❌\nNo\n❌\nNo\n❌\nNo Support\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - No Support -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\nElectrum\nSoftware Wallet (L1&L2)\n\" Fast, self-custodial wallet for Bitcoin and the Lightning Network with Hardware Wallet support and reproducible build system \"\n💡\n💻 📱\nDesktop, Mobile\nLinux, Windows, OS, Android\n❌\nNo\n✅\nYes\nP2WPKH\n✅\nFull Support (send & receive)\n💸\nSend Support\n✅\nYes\n✅\nYes\n✅\nYes\n✅\nYes\n✅\nYes\n❌\nNo\nV0\n✅\nYes\n✅\nYes\n❌\nNo Support\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n✅\nFull Support (send & receive)\n❌\nNo Support\n❌\nNo Support\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\nEnvoy\nSoftware Wallet (L1)\n\" Envoy is a simple Bitcoin mobile wallet with powerful privacy features. \"\n💡\n📱\nMobile\nAndroid, iOS\n❌\nNo\n❌\nNo\nP2WPKH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n✅\nYes\n❌\nNo\n✅\nFull Support (send & receive)\n✅\nYes\nV0\n✅\nYes\n❌\nNo\n❌\nNo Support\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - No Support -\n💸\nSend Support\n❌\nNo Support\n❌\nNo Support\nLiana\nSoftware Wallet (L1)\n\" Liana is a simple self-custody wallet with recovery and inheritance features using Miniscript. \"\n💡\n💻\nDesktop\nLinux, OS, Windows\n❌\nNo\n❌\nNo\nP2WSH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n✅\nYes\n❌\nNo\n✅\nFull Support (send & receive)\n✅\nYes\nV0\n✅\nYes\n✅\nYes\n❌\nNo Support\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - No Support -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\nNunchuk\nSoftware Wallet (L1)\n\" Nunchuk is a Bitcoin wallet that specializes in multisig and collaborative multisig solutions. \"\n💡\n💻 📱\nDesktop, Mobile\nAndroid, Linux, iOS, OS, Windows\n❌\nNo\n✅\nYes\nP2WSH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n✅\nYes\n❌\nNo\n✅\nFull Support (send & receive)\n✅\nYes\nV0\n✅\nYes\n✅\nYes\n✅\nYes\n❌\nNo Support\n❌\nBIP78 - No Support\nAlternate - No Support -\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\nPassport\nSigning Device\n\" Open-source, intuitive, beautiful, and highly secure self-custody. \"\n💡\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\n❌\nNo\nP2WPKH/P2TR\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\nV0\n✅\nYes\n✅\nYes\n❌\nNo Support\n➖\nNot Applicable\n❌\nBIP78 -\nAlternate - -\n💸\nSend Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\nPhoenix\nSoftware Wallet (L2)\n\" Phoenix is an easy-to-use non-custodial lightning wallet \"\n💡\n📱\nMobile\nAndroid, iOS\n❌\nNo\n❌\nNo\nP2TR via swap-in-potentiam\n💸\nSend Support\n✅\nFull Support (send & receive)\n➖\nNot Applicable\n❌\nNo\n❌\nNo\n❌\nNo\n✅\nFull Support (send & receive)\n✅\nYes\n➖\nNot Applicable\n➖\nNot Applicable\n➖\nNot Applicable\n✅\nFull Support (send & receive)\n➖\nNot Applicable\n➖\nBIP78 - Not Applicable\nAlternate - Not Applicable -\n➖\nNot Applicable\n❌\nNo Support\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n💸\nSend Support\n💸\nSend Support\nSparrow Wallet\nSoftware Wallet (L1)\n\" Bitcoin desktop wallet with a focus on security, privacy and usability \"\n💡\n💻\nDesktop\nLinux, OS, Windows\n❌\nNo\n✅\nYes\nP2WPKH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n✅\nYes\n✅\nYes\n✅\nFull Support (send & receive)\n✅\nYes\nV0\n✅\nYes\n✅\nYes\n❌\nNo Support\n❌\nNo Support\n💸\nBIP78 - Send Support\nAlternate - -\n✅\nFull Support (send & receive)\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\nWasabi Wallet\nSoftware Wallet (L1)\n\" Privacy by default, with coinjoin, block filters, and Tor. \"\n💡\n💻\nDesktop\nLinux, OS, Windows\n❌\nNo\n✅\nYes\nP2WPKH\n✅\nFull Support (send & receive)\n✅\nFull Support (send & receive)\n✅\nYes\n✅\nYes\n✅\nYes\n✅\nYes\n✅\nFull Support (send & receive)\n✅\nYes\nV2\n✅\nYes\n✅\nYes\n❌\nNo Support\n✅\nFull Support (send & receive)\n💸\nBIP78 - Send Support\nAlternate - -\n❌\nNo Support\n💸\nSend Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\n❌\nNo Support\nNotes:\n🔸 Hover over a column header to see that column's details.\n🔸 Features with alternate implementations are denoted with * , hover for details.\nApproach:\n🔸 Bitcoinops has selected the initial features within the matrix, focusing on interoperability.\n🔸 The matrix will be split by category once enough results are collected.\n🔸 New feature as well as Product/Service requests are welcome! Open a PR in the Optech Github .\nContributions and corrections are welcome. Please see the contibuting\nguidelines\nfor details."}
{"url":"https://docs.optimism.io/chain-operators/tools/chain-monitoring","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"a7d40504d839602e33a0781474b5f5a59a44675d7c55c8cb6ea36212ab4592f4","tokens":2028,"chars":8110,"crawler":"crawler-f6nn","verified":"exact","ts":1791172394775,"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\nTools\nChain monitoring options\nLearn about onchain and offchain monitoring options for your OP Stack chain.\nThis explainer covers the basics of onchain and offchain monitoring options for your OP Stack chain. Onchain monitoring services allow chain operators to monitor the overall system and onchain events.\nOffchain monitoring lets chain operators to monitor the operation and behavior of nodes and other offchain components.\nOnchain monitoring services\nOnchain monitoring services provide insights into the overall system, helping chain operators track and monitor on-chain events. Some examples of onchain monitoring services include monitorism and dispute-mon .\nmonitorism\nMonitorism is a tooling suite that supports monitoring and active remediation actions for the OP Stack chain. Monitorism uses monitors as passive security providing automated monitoring for the OP Stack. They are used to monitor the OP stack and alert on specific events that could be a sign of a security incident.\nCurrently, the list of monitors includes:\nSecurity integrity monitors: These are monitors necessary for making sure Bridges between L2 and L1 are safe and work as expected. These monitors are divided in two subgroups:\n- Pre-Faultproof Chain Monitors:\n- Fault Monitor: checks for changes in output roots posted to the L2OutputOracle contract. When a change is detected, it reconstructs the output root from a trusted L2 source and looks for a match.\n- Withdrawals Monitor: checks for new withdrawals that have been proven to the OptimismPortal contract. Each withdrawal is checked against the L2ToL1MessagePasser contract.\n- Faultproof chain monitors:\n- Faultproof Withdrawal: The Faultproof Withdrawal component monitors ProvenWithdrawals events on the OptimismPortal contract and performs checks to detect any violations of invariant conditions on the chain. If a violation is detected, the issue is logged, and a Prometheus metric is set for the event. This component is designed to work exclusively with chains that are already utilizing the Fault Proofs system. This is a new version of the deprecated chain-mon , faultproof-wd-mon . For detailed information on how the component works and the algorithms used, please refer to the component README.\nSecurity monitors: Those tools monitor other aspects of several contracts used in optimism:\n- Global Events Monitor: made for taking YAML rules as configuration and monitoring the events that are emitted on the chain.\n- Liveness Expiration Monitor: monitors the liveness expiration on Safes.\n- Balances Monitor: emits a metric reporting the balances for the configured accounts.\n- Multisig Monitor: The multisig monitor reports the paused status of the OptimismPortal contract. If set, reports the latest nonce of the configured Safe address and the latest presigned nonce stored in One Password.. The latest presigned nonce is identified by looking for items in the configured vault that follow a ready-.json name. The highest nonce of this item name format is reported.\n- Drippie Monitor: tracks the execution and executability of drips within a Drippie contract.\n- Secrets Monitor: takes a Drippie contract as a parameter and monitors for any drips within that contract that use the CheckSecrets dripcheck contract. CheckSecrets is a dripcheck that allows a drip to begin once a specific secret has been revealed (after a delay period) and cancels the drip if a second secret is revealed. Monitoring these secrets is important, as their revelation may indicate that the secret storage platform has been compromised and someone is attempting to exfiltrate the ETH controlled by the drip.\nFor more information on these monitors and how to use them, check out the repo .\ndispute-mon\nChain operators should consider running op-dispute-mon . It’s an essential security monitoring service that tracks game statuses, providing visibility over the last 28 days.\ndispute-mon is set up and built the same way as op-challenger . This means that you can run it the same way (run make op-dispute-mon in the directory).\nA basic configuration option would look like this:\nOP_DISPUTE_MON_LOG_FORMAT=logfmt\nOP_DISPUTE_MON_METRICS_ENABLED=true\nOP_DISPUTE_MON_METRICS_ADDR=0.0.0.0\nOP_DISPUTE_MON_METRICS_PORT=7300\nOP_DISPUTE_MON_L1_ETH_RPC=..\nOP_DISPUTE_MON_ROLLUP_RPC=..\nOP_DISPUTE_MON_GAME_FACTORY_ADDRESS=..\nOP_DISPUTE_MON_HONEST_ACTORS=..\nOP_DISPUTE_MON_HONEST_ACTORS is a CSV (no spaces) list of addresses that are used for the honest op-challenger instances.\nAdditional flags:\n- OP_DISPUTE_MON_GAME_WINDOW : This is the window of time to report on games. It should leave a buffer beyond the max game duration for bond claiming. If Fault Proof game parameters are not changes (e.g. MAX_CLOCK_DURATION), it is recommended to leave this as the default.\n- OP_DISPUTE_MON_MONITOR_INTERVAL : The interval at which to check for new games. Defaults to 30 seconds currently.\n- OP_DISPUTE_MON_MAX_CONCURRENCY : The max thread count. Defaults to 5 currently.\nYou can find more info on op-dispute-mon on the repo .\nOffchain component monitoring\nOffchain monitoring allows chain operators to monitor the operation and behavior of nodes and other offchain components. Some of the more common components that you’ll likely want to monitor include op-node , op-geth , op-proposer , op-batcher , and op-challenger .\nThe general steps for enabling offchain monitoring are pretty consistent for all the OP components:\n- Expose the monitoring port by enabling the --metrics.enabled flag\n- Customize the metrics port and address via the --metrics.port and --metrics.addr flags, respectively\n- Use Prometheus to scrape data from the metrics port\n- Save the data in influxdb\n- Share the data with Grafana to build your custom dashboard\nop-node\nop-node metrics and monitoring is detailed in the Node Metrics and Monitoring guide. To enable metrics, pass the --metrics.enabled flag to op-node and follow the steps above for customization options.\nSee this curated list for important metrics to track specifically for op-node .\nop-geth\nTo enable metrics, pass the --metrics.enabled flag to the op-geth. You can customize the metrics port and address via the --metrics.port and --metrics.addr flags, respectively.\nop-proposer\nTo enable metrics, pass the --metrics.enabled flag to the op-proposer. You can customize the metrics port and address via the --metrics.port and --metrics.addr flags, respectively.\nYou can find more information about these flags in our Proposer configuration doc .\nop-batcher\nTo enable metrics, pass the --metrics.enabled flag to the op-batcher. You can customize the metrics port and address via the --metrics.port and --metrics.addr flags, respectively.\nYou can find more information about these flags in our Batcher configuration doc .\nop-challenger\nThe op-challenger operates as the honest actor in the fault dispute system and defends the chain by securing the OptimismPortal and ensuring the game always resolves to the correct state of the chain.\nFor verifying the legitimacy of claims, op-challenger relies on a synced, trusted rollup node as well as a trace provider (e.g., Cannon ). See the OP-Challenger Explainer for more information on this service.\nTo enable metrics, pass the --metrics.enabled flag to op-challenger and follow the steps above for customization options.\n--metrics.addr value (default: \"0.0.0.0\") ($OP_CHALLENGER_METRICS_ADDR)\nMetrics listening address\n--metrics.enabled (default: false) ($OP_CHALLENGER_METRICS_ENABLED)\nEnable the metrics server\n--metrics.port value (default: 7300) ($OP_CHALLENGER_METRICS_PORT)\nMetrics listening port\nNext steps\n- If you encounter difficulties at any stage of this process, please reach out to developer support .\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.optimism.io/app-developers/tutorials/bridging/replay-failed-deposit","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"28d72fdc60d7c44a40809a3d1853d3722b59bbd933e867a76bdd4a42d4a62412","tokens":1663,"chars":6650,"crawler":"crawler-f6nn","verified":"exact","ts":1791172397328,"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\nBridging\nReplaying a failed deposit\nLearn how deposit replays work by deliberately failing a deposit against a test contract on OP Sepolia and then replaying it with more gas, end to end.\nWhen a deposit transaction fails on L2 — usually because it ran out of gas or the L2 state didn’t allow it to succeed — the message isn’t lost. L2CrossDomainMessenger records it as a failed message, and you can replay it later, optionally with more gas.\nIn this tutorial, you’ll make a deposit fail on purpose against a test contract, then replay it successfully, so you can see the full failure-and-replay cycle end to end. For the concepts behind deposits and why replays are possible, see Deposit flow .\nBefore you begin\n- Foundry installed (this tutorial uses cast ).\n- A test account private key, funded with a small amount of test ETH on both Ethereum Sepolia (L1) and OP Sepolia (L2).\n- An L1 (Ethereum Sepolia) RPC URL — e.g. a free Infura key or another provider.\nL1 vs L2 network clarification This tutorial involves two different networks :\n- L1 : Ethereum Sepolia testnet ( https://sepolia.infura.io/v3/YOUR_KEY )\n- L2 : OP Sepolia testnet ( https://sepolia.optimism.io )\nYou’ll send transactions on L1 that trigger actions on L2. Make sure you’re using the correct RPC URLs for each step.\nTrigger and replay a failed deposit\nTo see how replays work, you can use this contract on OP Sepolia .\n-\nCall stopChanges , using this Foundry command:\nPRIV_KEY =< your private key her e >\nexport ETH_RPC_URL = https :// sepolia . optimism . io\nGREETER = 0xEF60cF6C6D0C1c755be104843bb72CDa3D778630\ncast send --private-key $PRIV_KEY $GREETER \"stopChanges()\"\n-\nVerify that getStatus() returns false, meaning changes are not allowed, and see the value of greet() using Foundry.\nNote that Foundry returns false as zero.\ncast call $GREETER \"greet()\" | cast --to-ascii ; cast call $GREETER \"getStatus()\"\n-\nGet the calldata.\nYou can use this Foundry command:\ncast calldata \"setGreeting(string)\" \"testing\"\nOr just use this value:\n0xa41368620000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000774657374696e6700000000000000000000000000000000000000000000000000\n-\nSend a greeting change as a deposit from L1 (Ethereum Sepolia) to L2 (OP Sepolia).\nUse these commands:\n# L1 = Ethereum Sepolia\n# Get a free Infura key at https://infura.io or use the public RPC below\nL1_RPC = https://sepolia.infura.io/v3/YOUR_INFURA_KEY\nL1XDM_ADDRESS = 0x5086d1eef304eb5284a0f6720f79403b4e9be294\nFUNC = \"sendMessage(address,bytes,uint32)\"\nCALLDATA = ` cast calldata \"setGreeting(string)\" \"testing\"`\ncast send --rpc-url $L1_RPC --private-key $PRIV_KEY $L1XDM_ADDRESS $FUNC $GREETER $CALLDATA 10000000\nThe transaction will be successful on L1 (Ethereum Sepolia) , but then emit a fail event on L2 (OP Sepolia) .\n-\nThe next step is to find the hash of the failed relay. There are several ways to do this:\nMethod A: Using Etherscan Internal Transactions\nLook in the internal transactions of the destination contract , and select the latest one that appears as a failure. It should be a call to L2CrossDomainMessenger at address 0x420...007 .\nMethod B: Using Contract Events (if internal transactions aren’t visible)\nIf you can’t see internal transactions on Etherscan, check the L2CrossDomainMessenger contract events and look for FailedRelayedMessage events with your contract address.\nMethod C: Using cast to query failed messages\n# First, you need the message hash. You can derive it from the L1 transaction, or check events\nL2XDM_ADDRESS = 0x4200000000000000000000000000000000000007\n# Replace MSG_HASH with the actual message hash from the FailedRelayedMessage event\ncast call $L2XDM_ADDRESS \"failedMessages(bytes32)\" $MSG_HASH\nIf the latest internal transaction is a success, it probably means your transaction hasn’t relayed yet. Wait until it is, that may take a few minutes.\n-\nGet the transaction information using Foundry.\nWait for the failed relay transaction Make sure you wait for the deposit to be processed on L2 and fail before proceeding. This can take 2-5 minutes. You should see a failed transaction in one of the methods from step 5.\nTX_HASH =< transaction hash from the failed relay on L 2>\nL2XDM_ADDRESS = 0x4200000000000000000000000000000000000007\nREPLAY_DATA = ` cast tx $TX_HASH input`\n-\nCall startChanges() to allow changes using this Foundry command:\ncast send --private-key $PRIV_KEY $GREETER \"startChanges()\"\nDon’t do this prematurely If you call startChanges() too early, it will happen when the message is relayed to L2, and then the initial deposit will be successful and there will be no need to replay it.\n-\nVerify that getStatus() returns true, meaning changes are not allowed, and see the value of greet() .\nFoundry returns true as one.\ncast call $GREETER \"greet()\" | cast --to-ascii ; cast call $GREETER \"getStatus()\"\n-\nNow send the replay transaction.\ncast send --private-key $PRIV_KEY --gas-limit 10000000 $L2XDM_ADDRESS $REPLAY_DATA\nWhy do we need to specify the gas limit? The gas estimation mechanism tries to find the minimum gas limit at which the transaction would be successful.\nHowever, L2CrossDomainMessenger does not revert when a replay fails due to low gas limit, it just emits a failure message.\nThe gas estimation mechanism considers that a success. To get a gas estimate, you can use this command:\ncast estimate --from 0x0000000000000000000000000000000000000001 $L2XDM_ADDRESS $REPLAY_DATA\nThat address is a special case in which the contract does revert.\n-\nVerify the greeting has changed:\ncast call $GREETER \"greet()\" | cast --to-ascii ; cast call $GREETER \"getStatus()\"\nDebugging\nTo debug deposit transactions, you can ask the L2 cross domain messenger for the state of the transaction.\n-\nLook on Etherscan to see the FailedRelayedMessage event. Set MSG_HASH to that value.\n-\nTo check if the message is listed as failed, run this:\ncast call $L2XDM_ADDRESS \"failedMessages(bytes32)\" $MSG_HASH\nTo check if it is listed as successful, run this:\ncast call $L2XDM_ADDRESS \"successfulMessages(bytes32)\" $MSG_HASH\nNext steps\n- Read Deposit flow to understand how deposits are processed across L1 and L2 under the hood.\n- Learn about sending data between L1 and L2 from your contracts.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://docs.ens.domains/wrapper/states","domain":"docs.ens.domains","title":"Wrapped States | ENS Docs","hash":"31145ae12e35dbf50673b11cb9285fb86657cbdae9995b24655df8dbed7cdeef","tokens":373,"chars":1491,"crawler":"crawler-f6nn","verified":"exact","ts":1791172399484,"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\nWrapped States\nTaking the Name Wrapper into account, an ENS name can be in one of these possible states:\nUnregistered\nThe name has not even been registered/created yet, or it has expired.\nUnwrapped\nThe name exists and has not expired (in the case of .eth second-level names). The Name Wrapper contract does not have ownership over the name. You own the name in the registry and/or .eth registrar.\nWrapped\nThe Name Wrapper contract has ownership of the name (in the registry/registrar). You are issued an ERC-1155 NFT in return, which proves that you are the actual owner.\nYou can unwrap the name at any time, which burns the ERC-1155 NFT, and returns ownership in the registry/registrar back to you.\nIf your name is a subname like sub.name.eth , then the owner of name.eth can technically replace the subname and transfer it to a different owner.\nIn addition, the parent owner can burn parent-controlled fuses on your name.\nEmancipated\nThe owner of the parent name is no longer able to replace this name, or burn any additional fuses on it. All .eth second-level names (like name.eth ) are automatically put into the Emancipated state when they are wrapped.\nThe name can still be unwrapped and rewrapped by the owner.\nLocked\nThe name can no longer be unwrapped. The owner can now burn owner-controlled fuses on the name. Fuses for subnames of this name can now be burned as well."}
{"url":"https://gov.optimism.io/tos","domain":"gov.optimism.io","title":"Terms of Service - Optimism Collective","hash":"112b925e3c555a4bf487e88ae1172531b07b3d3bd0bf57ceb70bee686a6c1989","tokens":3058,"chars":12232,"crawler":"crawler-f6nn","verified":"exact","ts":1791172401931,"text":"Optimism Collective\n- About\n- Guidelines\n- Terms of Service\n- Privacy\nThese terms govern use of the Internet forum at http://gov.optimism.io . To use the forum, you must agree to these terms with Optimism Collective, the company that runs the forum.\nThe company may offer other products and services, under different terms. These terms apply only to use of the forum.\nSkip to:\n- Important Terms\n- Your Permission to Use the Forum\n- Conditions for Use of the Forum\n- Acceptable Use\n- Content Standards\n- Enforcement\n- Your Account\n- Your Content\n- Your Responsibility\n- Disclaimers\n- Limits on Liability\n- Feedback\n- Termination\n- Disputes\n- General Terms\n- Contact\n- Changes\nImportant Terms\nThese terms include a number of important provisions that affect your rights and responsibilities, such as the disclaimers in Disclaimers , limits on the company’s liability to you in Limits on Liability , your agreement to cover the company for damages caused by your misuse of the forum in Responsibility for Your Use , and an agreement to arbitrate disputes in Disputes .\nYour Permission to Use the Forum\nSubject to these terms, the company gives you permission to use the forum. Everyone needs to agree to these terms to use the forum.\nConditions for Use of the Forum\nYour permission to use the forum is subject to the following conditions:\n-\nYou must be at least thirteen years old.\n-\nYou may no longer use the forum if the company contacts you directly to say that you may not.\n-\nYou must use the forum in accordance with Acceptable Use and Content Standards .\nAcceptable Use\n-\nYou may not break the law using the forum.\n-\nYou may not use or try to use another’s account on the forum without their specific permission.\n-\nYou may not buy, sell, or otherwise trade in user names or other unique identifiers on the forum.\n-\nYou may not send advertisements, chain letters, or other solicitations through the forum, or use the forum to gather addresses or other personal data for commercial mailing lists or databases.\n-\nYou may not automate access to the forum, or monitor the forum, such as with a web crawler, browser plug-in or add-on, or other computer program that is not a web browser. You may crawl the forum to index it for a publicly available search engine, if you run one.\n-\nYou may not use the forum to send e-mail to distribution lists, newsgroups, or group mail aliases.\n-\nYou may not falsely imply that you’re affiliated with or endorsed by the company.\n-\nYou may not hyperlink to images or other non-hypertext content on the forum on other webpages.\n-\nYou may not remove any marks showing proprietary ownership from materials you download from the forum.\n-\nYou may not show any part of the forum on other websites with
\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://bitcoin.org/en/alerts","domain":"bitcoin.org","title":"Network status and alerts - Bitcoin","hash":"268f8a38b32dcb440fda007fe2862ec718540c36396fbd7405609735706bea7c","tokens":817,"chars":3268,"crawler":"verify-mob","verified":"exact","ts":1791170032351,"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\nNetwork status and alerts\nStay aware of network alerts by\nsubscribing to the RSS feed\nThere is no ongoing event on the Bitcoin network.\n-\n2018-09-21 -\nNotice of Required Upgrade to 0.16.3\nRead more\n-\n2017-10-11 -\nBeware of Bitcoin's possible incompatibility with some major services\nRead more\n-\n2017-07-12 -\nPotential network disruption\nRead more\n-\n2016-11-01 -\nAlert System Retirement\nRead more\n-\n2016-08-17 -\n0.13.0 Binary Safety Warning\nRead more\n-\n2015-10-12 -\nVulnerability in UPnP library used by Bitcoin Core\nRead more\n-\n2015-07-04 -\nSome Miners Generating Invalid Blocks\nRead more\n-\n2014-04-11 -\nOpenSSL Heartbleed vulnerability\nRead more\n-\n2014-02-11 -\nTransaction malleability\nRead more\n-\n2013-08-11 -\nAndroid Security Vulnerability\nRead more\n-\n2013-03-15 -\n15 May 2013 Upgrade Deadline\nRead more\n-\n2013-03-11 -\n11/12 March 2013 Chain Fork Information\nRead more\n-\n2012-05-14 -\nCVE-2012-2459: Critical Vulnerability (denial-of-service)\nRead more\n-\n2012-03-16 -\nPotentially Critical Security Vulnerability\nRead more\n-\n2012-02-18 -\nFebruary 20, 2012 Protocol Changes\nRead more\nStatus and distribution of Bitcoin nodes\nPropagation time on the network\nComplete CVE list\nPlease refer to the\ndevelopment page if you want to report a vulnerability.\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.anza.xyz/validator/anatomy","domain":"docs.anza.xyz","title":"Anatomy of a Validator | Agave","hash":"b2c4c56bd245b651fb5c783df3d6c46825ec0a4157a9b1b16437cac4b12d101c","tokens":401,"chars":1602,"crawler":"verify-mob","verified":"exact","ts":1791170034116,"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://docs.orca.so/","domain":"docs.orca.so","title":"Orca Documentation - Orca Documentation","hash":"a8cf006c26bd090f5ae2344b08401fae18f5f373b8dd2063c72c58a2015817b9","tokens":563,"chars":2251,"crawler":"verify-mob","verified":"exact","ts":1791170036419,"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://bitcoin.org/fr/bitcoin-pour-entreprises","domain":"bitcoin.org","title":"Bitcoin pour les entreprises - Bitcoin","hash":"02eb1bbb64c577d51a8d09904ecad892647f53f4ea2e5425f8cc806322aefcc5","tokens":1277,"chars":5106,"crawler":"crawler-74kg","verified":"exact","ts":1791170333683,"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- Particuliers\n- Entreprises\n- Développeurs\n- Débuter\n- Comment ça marche\n- Vous devez savoir\n- Ressources\n- Exchanges\n- Communauté\n- BIPs list\n- Vocabulaire\n- Bitcoin Core\n- Innovation\n- Participer\n- Soutenir Bitcoin\n- Buy Bitcoin\n- Sell Bitcoin\n- Développement\n- FAQ\n- Français\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: fr\nBitcoin pour les entreprises\nBitcoin est un moyen très sécurisé et économique de traiter des paiements.\nLes frais les plus bas du marché\nLa haute sécurité cryptographique employée par Bitcoin lui permet de traiter des paiements de manière très efficace et économique. Vous pouvez émettre et recevoir des paiements avec le réseau Bitcoin presque sans aucun frais. Très souvent, les frais ne sont pas exigés mais ils sont recommandés pour une confirmation plus rapide de vos transactions.\nProtection contre la fraude\nToute entreprise qui accepte les cartes de crédit ou Paypal connaît le problème des paiements qui sont renversés plus tard après une vente. Les fraudes par rejet de débit occasionnent une pénétration de marché limitée et une augmentation des prix, ce qui à leur tour pénalise les consommateurs. Les paiements avec Bitcoin sont irréversibles et sécurisés, ce qui signifie que les coûts de la fraude ne sont plus à la charge des commerçants.\nTransferts internationaux sans délai\nLes bitcoins peuvent être transférés de l'Afrique vers le Canada en 10 minutes. En fait, les bitcoins n'ont aucun emplacement physique réel. Il est donc possible de transférer n'importe quelle somme n'importe où sans limite, sans délai et sans frais excessifs. Il n'y a pas de banque intermédiaire pour vous faire attendre pendant 3 jours ouvrables.\nAucune conformité PCI requise\nAccepter les cartes de crédit en ligne requiert des contrôles de sécurité approfondis pour se conformer à la norme PCI. Bitcoin nécessite de sécuriser votre portefeuille et vos demandes de paiement. Toutefois, vous ne portez pas les coûts et les responsabilités qu'impliquent le traitement d'informations sensibles tels que les numéros de cartes de crédit.\nGagnez en visibilité, gratuitement\nBitcoin est un marché émergeant de nouveaux consommateurs cherchant à dépenser leurs bitcoins. Les accepter est une bonne façon d'obtenir de nouveaux clients et de donner plus de visibilité à votre commerce. Accepter de nouvelles formes de paiements s'est souvent avéré bénéfique pour les commerces en ligne.\nMulti-signatures\nBitcoin inclut également une fonctionnalité multi-signature qui permet aux bitcoins d'être dépensés seulement si un sous-ensemble d'un groupe de personnes autorise la transaction. Ceci peut être utilisé par un conseil d'administration afin d'éviter que tout membre puisse effectuer des dépenses sans consentement suffisant des autres membres, ainsi que de suivre quels membres ont autorisé quels paiements.\nComptabilité transparente\nBeaucoup d'organisations doivent produire des documents comptables sur leur activité. Utiliser Bitcoin permet d'offrir le plus haut niveau de transparence puisque vous pouvez fournir des informations que vos membres peuvent utiliser afin de vérifier vos soldes et vos transactions. Les organisations sans but lucratif peuvent aussi permettre au public de visualiser combien elles reçoivent en dons.\nAccept fast payments with Lightning\nThe Lightning Network lets your business accept bitcoin payments that settle near-instantly with minimal fees, even for small amounts. Point-of-sale systems and open-source payment tools support Lightning at checkout. See Lightning resources for more.\nDébuter avec Bitcoin\nSupport Bitcoin.org:\nDonate\nbc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8\nIntroduction:\n-\nParticuliers\n-\nEntreprises\n-\nDéveloppeurs\n-\nDébuter\n-\nComment ça marche\n-\nVous devez savoir\nRessources:\n-\nRessources\n-\nExchanges\n-\nCommunauté\n-\nBIPs list\n-\nVocabulaire\n-\nBitcoin Core\nParticiper:\n-\nSoutenir Bitcoin\n-\nBuy Bitcoin\n-\nSell Bitcoin\n-\nDéveloppement\nOther:\nLégal\nPrivacy Policy\nPresse\nÀ propos de bitcoin.org\nBlog\n© Bitcoin Project 2009-2026 Publié sous la licence MIT\nNetwork Status\n- Français\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- 繁體中文\nfr"}
{"url":"https://docs.starknet.io/build/quickstart/environment-setup","domain":"docs.starknet.io","title":"Setting up your development environment - Starknet Documentation","hash":"29091c75390743c1fbe8c3dff36e14d813ee338664e8aa55110543f470feb275","tokens":1287,"chars":5147,"crawler":"crawler-74kg","verified":"exact","ts":1791170336117,"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\nStarknet Documentation home page\nWelcome\nBuild\nSecure\nLearn\nSetting up your development environment\nIf you encounter an issue while following this tutorial, see Troubleshooting .\nIntroduction\nWelcome to the first installment of the Deploy your first contract guide! 🥇\nAs a popular phrase (often attributed to Abraham Lincoln) says, “Give me six hours to chop down a tree, and I will spend the first four sharpening the axe”.\nThe first installment of the series will therefore guide you through setting up your development environment, which will include the three most recommended tools to begin developing on Starknet:\n-\nScarb , a build toolchain and package manager for Cairo and Starknet ecosystems\n-\nStarknet Foundry , the go-to framework for building and testing Starknet Smart Contracts\n-\nStarknet Devnet , a Rust implementation of a local Starknet node\nTo review all Starknet developer tools, see Developer tools .\nSetting up your environment on MacOS and Linux\nOn MacOS and Linux, Scarb, Starknet Foundry and Starknet Devnet can be easily installed using the Starkup installer by running:\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.starkup.sh | sh\nand following the onscreen instructions.\nIf you prefer to install the tools manually or encounter issues with Starkup, see Setting up your environment manually on MacOS and Linux .\nYou can verify that all three tools are installed correctly by running:\nscarb --version\nsnforge --version && sncast --version\nstarknet-devnet --version\nIf the installation was successful, the result should resemble the following:\nscarb 2.11.4 (c0ef5ec6a 2025-04-09)\ncairo: 2.11.4 (https://crates.io/crates/cairo-lang-compiler/2.11.4)\nsierra: 1.7.0\nsnforge 0.48.1\nsncast 0.48.1\nstarknet-devnet 0.4.3\nStarkup installs Scarb, Starknet Foundry, and Starknet Devnet on MacOS and Linux via the asdf version manager , which allows to easily switch between their different versions, both globally and per project (see full details in the asdf documentation or by running asdf --help ). Alongside Scarb and Starknet Foundry, Starkup uses asdf to install additional useful tools, including the Universal Sierra Compiler , Cairo Profiler , Cairo Coverage , and CairoLS . If you encounter any issues while using it or have any requests, please help by submitting an issue .\nSetting up your environment on Windows\nSetting up Scarb and Starknet Foundry on Windows requires configuring the Windows Subsystem for Linux (WSL) and installing the tools inside a Linux distribution such as Ubuntu.\nInstalling WSL and Ubuntu\n-\nOpen PowerShell as administrator and run:\nwsl --install\nThis command installs WSL along with the default Ubuntu distribution. If WSL or virtualization is not yet enabled, reboot and re-run the command as needed.\n-\nRestart your computer when prompted.\n-\nAfter reboot, launch Ubuntu from the Start menu. On the first launch, create a UNIX username and password when prompted.\nIf wsl --install does not work, enable WSL manually by running:\ndism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart\ndism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart\nand installing Ubuntu from the Microsoft Store .\nInstalling prerequisites in Ubuntu\n-\nOpen the Ubuntu terminal and run:\nsudo apt update\nsudo apt install -y curl git build-essential\nInstalling Homebrew\n-\nRun the Homebrew install script:\n/bin/bash -c \"$( curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\"\n-\nAdd Homebrew to your shell environment:\necho 'eval \"$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)\"' >> ~/.profile\nsource ~/.profile\n-\nVerify that Homebrew was installed correctly:\nbrew --version\nInstalling asdf\nUsing asdf allows you to easily switch between versions of Scarb, Starknet Foundry, and Starknet Devnet globally or per project.\n-\nInstall asdf using Homebrew:\nbrew install asdf\n-\nAdd asdf to your shell:\necho '. \"$(brew --prefix asdf)/libexec/asdf.sh\"' >> ~/.bashrc\nsource ~/.bashrc\n-\nVerify that asdf is installed correctly:\nasdf --version\nInstalling Scarb, Starknet Foundry, and Starknet Devnet\n-\nAdd the Scarb plugin and install the latest Scarb version:\nasdf plugin add scarb\nasdf install scarb latest\nasdf set -u scarb latest\n-\nAdd the Starknet Foundry plugin and install the latest Starknet Foundry version:\nasdf plugin add starknet-foundry\nasdf install starknet-foundry latest\nasdf set -u starknet-foundry latest\n-\nAdd the Starknet Devnet plugin and install the latest Starknet Devnet version:\nasdf plugin add starknet-devnet\nasdf install starknet-devnet latest\nasdf set -u starknet-devnet latest\n-\nRestart your terminal and verify that Scarb, Starknet Foundry, and Starknet Devnet were installed correctly:\nscarb --version\nsnforge --version && sncast --version\nstarknet-devnet --version\nIf scarb , snforge , or starknet-devnet are not recognized, try running source ~/.bashrc or restarting your terminal.\nWas this page helpful?\nSuggest edits Raise issue\n⌘ I"}
{"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-74kg","verified":"exact","ts":1791170339346,"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://raw.githubusercontent.com/bitcoin/bitcoin/master/README.md","domain":"raw.githubusercontent.com","title":"","hash":"22d3243eae5b744c74ae79f97f1af18d6c47c9885035d13aecb11987e337a35e","tokens":867,"chars":3465,"crawler":"crawler-74kg","verified":"exact","ts":1791170341307,"text":"Bitcoin Core integration/staging tree\n=====================================\nhttps://bitcoincore.org\nFor an immediately usable, binary version of the Bitcoin Core software, see\nhttps://bitcoincore.org/en/download/.\nWhat is Bitcoin Core?\n---------------------\nBitcoin Core connects to the Bitcoin peer-to-peer network to download and fully\nvalidate blocks and transactions. It also includes a wallet and graphical user\ninterface, which can be optionally built.\nFurther information about Bitcoin Core is available in the [doc folder](/doc).\nLicense\n-------\nBitcoin Core is released under the terms of the MIT license. See [COPYING](COPYING) for more\ninformation or see https://opensource.org/license/MIT.\nDevelopment Process\n-------------------\nThe `master` branch is regularly built (see `doc/build-*.md` for instructions) and tested, but it is not guaranteed to be\ncompletely stable. [Tags](https://github.com/bitcoin/bitcoin/tags) are created\nregularly from release branches to indicate new official, stable release versions of Bitcoin Core.\nThe https://github.com/bitcoin-core/gui repository is used exclusively for the\ndevelopment of the GUI. Its master branch is identical in all monotree\nrepositories. Release branches and tags do not exist, so please do not fork\nthat repository unless it is for development reasons.\nThe contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md)\nand useful hints for developers can be found in [doc/developer-notes.md](doc/developer-notes.md).\nTesting\n-------\nTesting and code review is the bottleneck for development; we get more pull\nrequests than we can review and test on short notice. Please be patient and help out by testing\nother people's pull requests, and remember this is a security-critical project where any mistake might cost people\nlots of money.\n### Automated Testing\nDevelopers are strongly encouraged to write [unit tests](src/test/README.md) for new code, and to\nsubmit new unit tests for old code. Unit tests can be compiled and run\n(assuming they weren't disabled during the generation of the build system) with: `ctest`. Further details on running\nand extending unit tests can be found in [/src/test/README.md](/src/test/README.md).\nThere are also [regression and integration tests](/test), written\nin Python.\nThese tests can be run (if the [test dependencies](/test) are installed) with: `build/test/functional/test_runner.py`\n(assuming `build` is your build directory).\nThe CI (Continuous Integration) systems make sure that every pull request is tested on Windows, Linux, and macOS.\nThe CI must pass on all commits before merge to avoid unrelated CI failures on new pull requests.\n### Manual Quality Assurance (QA) Testing\nChanges should be tested by somebody other than the developer who wrote the\ncode. This is especially important for large or high-risk changes. It is useful\nto add a test plan to the pull request description if testing the changes is\nnot straightforward.\nTranslations\n------------\nChanges to translations as well as new translations can be submitted to\n[Bitcoin Core's Transifex page](https://explore.transifex.com/bitcoin/bitcoin/).\nTranslations are periodically pulled from Transifex and merged into the git repository. See the\n[translation process](doc/translation_process.md) for details on how this works.\n**Important**: We do not accept translation changes as GitHub pull requests because the next\npull from Transifex would automatically overwrite them again."}
{"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-74kg","verified":"exact","ts":1791170343444,"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 \n
\n\n
\n\nConsole\n
\n\nAccess developer tools, deploy contracts, and manage your blockchain infrastructure.\n\n\n
\n\n","hash":"867cfe7ccf651cdedf7769c8adf7d0b35f117310f5a195f3a3489d4f15f63998","tokens":2159,"chars":8635,"crawler":"crawler-f6nn","verified":"exact","ts":1791171694319,"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://ethereum.org/developers/docs/evm/","domain":"ethereum.org","title":"Ethereum Virtual Machine (EVM) | ethereum.org","hash":"36e7ddc31c6beadd3be7898c9ba82259c5b1e33abdfd3bebe27bc076d4dd6d01","tokens":1523,"chars":6092,"crawler":"crawler-f6nn","verified":"exact","ts":1791171696808,"text":"Skip to main content\nChange page\nEthereum Virtual Machine (EVM)\nEdit page (opens in a new tab)\nThe Ethereum Virtual Machine (EVM) is a decentralized virtual environment that executes code consistently and securely across all Ethereum nodes. Nodes run the EVM to execute smart contracts, using \" gas \" to measure the computational effort required for operations , ensuring efficient resource allocation and network security.\nPrerequisites\nSome basic familiarity with common terminology in computer science such as bytes (opens in a new tab) , memory (opens in a new tab) , and a stack (opens in a new tab) are necessary to understand the EVM. It would also be helpful to be comfortable with cryptography/blockchain concepts like hash functions (opens in a new tab) and the Merkle tree (opens in a new tab) .\nFrom ledger to state machine\nThe analogy of a 'distributed ledger' is often used to describe blockchains like Bitcoin, which enable a decentralized currency using fundamental tools of cryptography. The ledger maintains a record of activity which must adhere to a set of rules that govern what someone can and cannot do to modify the ledger. For example, a Bitcoin address cannot spend more Bitcoin than it has previously received. These rules underpin all transactions on Bitcoin and many other blockchains.\nWhile Ethereum has its own native cryptocurrency (ether) that follows almost exactly the same intuitive rules, it also enables a much more powerful function: smart contracts . For this more complex feature, a more sophisticated analogy is required. Instead of a distributed ledger, Ethereum is a distributed state machine (opens in a new tab) . Ethereum's state is a large data structure which holds not only all accounts and balances, but a machine state , which can change from block to block according to a pre-defined set of rules, and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the EVM.\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nThe Ethereum state transition function\nThe EVM behaves as a mathematical function would: Given an input, it produces a deterministic output. It therefore is quite helpful to more formally describe Ethereum as having a state transition function :\nY(S, T)= S'\nGiven an old valid state (S) and a new set of valid transactions (T) , the Ethereum state transition function Y(S, T) produces a new valid output state S'\nState\nIn the context of Ethereum, the state is an enormous data structure called a modified Merkle Patricia Trie , which keeps all accounts linked by hashes and reducible to a single root hash stored on the blockchain.\nTransactions\nTransactions are cryptographically signed instructions from accounts. There are two types of transactions: those which result in message calls and those which result in contract creation.\nContract creation results in the creation of a new contract account containing compiled smart contract bytecode. Whenever another account makes a message call to that contract, it executes its bytecode.\nEVM instructions\nThe EVM executes as a stack machine (opens in a new tab) with a depth of 1024 items. Each item is a 256-bit word, which was chosen for the ease of use with 256-bit cryptography (such as Keccak-256 hashes or secp256k1 signatures).\nDuring execution, the EVM maintains a transient memory (as a word-addressed byte array), which does not persist between transactions.\nTransient storage\nTransient storage is a per-transaction key–value store accessed through the TSTORE and TLOAD opcodes. It persists across all internal calls during the same transaction but is cleared at the end of the transaction. Unlike memory, transient storage is modeled as part of the EVM state rather than the execution frame, yet it is not committed to the global state. Transient storage enables gas-efficient temporary state sharing across internal calls during a transaction.\nStorage\nContracts contain a Merkle Patricia storage trie (as a word-addressable word array), associated with the account in question and part of the global state. This persistent storage differs from transient storage, which is available only for the duration of a single transaction and does not form part of the account's persistent storage trie.\nOpcodes\nCompiled smart contract bytecode executes as a number of EVM opcodes , which perform standard stack operations like XOR , AND , ADD , SUB , etc. The EVM also implements a number of blockchain-specific stack operations, such as ADDRESS , BALANCE , BLOCKHASH , etc. The opcode set also includes TSTORE and TLOAD , which provide access to transient storage.\nDiagrams adapted from Ethereum EVM illustrated (opens in a new tab)\nEVM implementations\nAll implementations of the EVM must adhere to the specification described in the Ethereum Yellowpaper.\nOver Ethereum's ten year history, the EVM has undergone several revisions, and there are several implementations of the EVM in various programming languages.\nEthereum execution clients include an EVM implementation. Additionally, there are multiple standalone implementations, including:\n- Py-EVM (opens in a new tab) - Python\n- evmone (opens in a new tab) - C++\n- ethereumjs-vm (opens in a new tab) - JavaScript\n- revm (opens in a new tab) - Rust\nFurther Reading\n- Ethereum Yellowpaper (opens in a new tab)\n- Jellopaper aka KEVM: Semantics of EVM in K (opens in a new tab)\n- The Beigepaper (opens in a new tab)\n- Ethereum Virtual Machine Opcodes (opens in a new tab)\n- Ethereum Virtual Machine Opcodes Interactive Reference (opens in a new tab)\n- A short introduction in Solidity's documentation (opens in a new tab)\n- Mastering Ethereum - The Ethereum Virtual Machine (opens in a new tab)\nRelated Topics\n- Gas\nTutorials: Ethereum Virtual Machine (EVM) / Opcodes on Ethereum\n- Understanding the Yellow Paper's EVM Specifications – A guided walkthrough of the formal EVM spec from the Ethereum Yellow Paper.\n- Reverse Engineering a Contract – How to reverse-engineer a compiled smart contract using EVM opcodes.\nTest your Ethereum knowledge"}
{"url":"https://docs.optimism.io/use-cases/implement-a-custom-deposit-flow","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"7a5f0c92c2ea5727f95c2eeb14f64da1546a183b686e6376fd7e9a5dba390b74","tokens":2271,"chars":9083,"crawler":"crawler-f6nn","verified":"exact","ts":1791171699455,"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\nUse cases\nImplement a custom deposit flow\nBuild an L1 to L2 deposit path for your application, choosing the right contract entry point and handling gas, aliasing, and failed messages.\nThis guide takes an app developer whose contracts need to trigger effects on\nan OP Stack chain from Ethereum and walks the deposit path in one pass: how a\ndeposit travels from L1 to L2, which of the three contract entry points fits\nyour use case, and the safety details (gas limits, address aliasing, failed\nmessages) that custom integrations get wrong. It involves the StandardBridge ,\nthe CrossDomainMessenger pair, and the OptimismPortal contract.\nIs this guide for you?\nUse this guide if:\n- You are building contracts or backend infrastructure that initiate L2\nactions from L1: a custom token bridge, an L1-controlled L2 contract, or\na protocol that must be able to force transactions into the L2.\n- You need to choose which contract interface to build against, not just\nfollow one path.\nIf you only need to move ETH or a standard ERC-20 between layers, use the\nStandard Bridge as is. If\nyour goal is L2 to L1 (withdrawals), read the\nwithdrawal flow explanation instead; the\n7-day challenge period makes it a different problem. For messaging between two\nOP Stack chains rather than L1 and L2, see\ninterop explainer . This guide covers the L1 to\nL2 direction only.\nBefore you start\nYou should already have:\n- A Solidity development environment and a funded account on Sepolia and\nOP Sepolia (or another OP Stack testnet).\n- Basic familiarity with how contracts call each other on a single chain;\nthe bridging basics guide sets\nthe baseline vocabulary.\nStep 1: Map the deposit path\nEvery L1 to L2 write, whatever interface you use, ends as a call to the\nOptimismPortal contract’s depositTransaction function, which emits a\nTransactionDeposited event that the rollup node derives into an L2\ntransaction. Read the deposit flow explanation\nand take away:\n- The encapsulation chain: your contract calls a messenger, the messenger\ncalls the portal, the portal emits the event, and op-node turns the\nevent into an L2 transaction. Each layer you use adds convenience and\nsafety on top of the one below it.\n- That deposits are included by derivation, not by the sequencer’s grace:\nonce the L1 transaction is confirmed, the L2 transaction will happen.\nThen skim Sending data between L1 and L2\nand take away the sendMessage(target, message, minGasLimit) interface shape,\nthe 1 to 3 minute L1 to L2 delivery time, and how the portal charges for L2\nexecution by burning L1 gas.\nStep 2: Choose your entry layer\nThis is the decision that shapes everything downstream. Work down the table\nand stop at the first row that fits:\nIf … Choose … Because …\nYou are moving ETH or ERC-20 tokens and standard lock-and-mint accounting fits StandardBridge , extended if necessary It is the audited path, it is compatible with the Superchain Bridges UI and the token list, and building a custom bridged token covers most “the standard token doesn’t fit” cases without a new bridge.\nYou are calling an L2 contract and want delivery guarantees L1CrossDomainMessenger.sendMessage The messenger records messages that fail on L2 and lets anyone replay them with more gas, and the target can authenticate the L1 sender via xDomainMessageSender .\nYou need raw deposited transactions: forced inclusion when the sequencer censors you, or full control of the L2 call OptimismPortal.depositTransaction , called directly Nothing sits between you and derivation. But you give up the messenger’s replay safety net and sender authentication, and address aliasing applies to your contract (Step 3).\nFor the current contract interfaces, use the\ncontracts-bedrock reference\nor the source on develop :\nStandardBridge.sol ,\nCrossDomainMessenger.sol ,\nand OptimismPortal2.sol .\nDeployed addresses for OP Mainnet and OP Sepolia are on the\ncontract addresses page .\nIf you concluded you need a custom bridge, read the\ncustom bridges guide and take\naway the recommendation to extend StandardBridge rather than start from\nscratch, and the requirement to register bridged tokens in the Superchain\nToken List.\nStep 3: Get the safety details right\nThree properties of the deposit path surprise custom integrations. Check each\nagainst your design before writing code:\n- Address aliasing. When a contract (not an EOA) initiates a deposit,\nthe from address on L2 is the L1 contract’s address plus a constant\noffset. If your L2 contract checks msg.sender against an L1 contract\naddress, it must check the aliased form. Read\naddress aliasing in the deposits spec\nand take away the offset constant and the reason it exists. The messenger\nabstracts this away; portal-direct integrations must handle it themselves.\n- Gas limits are minimums with real floors. The minGasLimit you pass\nto sendMessage is a minimum for the L2 execution, and the portal\nenforces its own data-size-scaled minimum on every deposit (see\nminimumGasLimit in\nOptimismPortal2.sol )\nplus a hard cap on deposit calldata size. The L1 gas burned to pay for L2\ngas is dynamic, so follow the\nfee guidance in the messaging guide\nand take away the recommendation to buffer your gas limit by at least 20%.\n- Sender authentication. On the receiving side, msg.sender is the L2\nmessenger, not your L1 contract. Read\naccessing msg.sender\nand take away the xDomainMessageSender check pattern. Portal-direct\ndeposits do not get this: the L2 target sees only the (aliased) from .\nStep 4: Build against the pattern\nEach entry layer has a worked, runnable path. Follow the one matching your\nStep 2 decision; each is a tutorial, so it includes environment setup this\nguide skips:\n- Standard Bridge with a custom token : follow the custom-token path of\nCreate an L2 token for the Standard Bridge\nto deploy an OptimismMintableERC20 variant with custom logic.\n- Messenger-based contract calls : follow\nCommunicating between contracts on L1 and L2\nfor the full send, relay, and authenticate loop in Solidity.\n- Portal-direct deposits : there is no dedicated tutorial; work from the\ndepositTransaction interface in\nOptimismPortal2.sol\nand the\ndeposits spec ,\nand keep Step 3’s aliasing and gas rules in front of you.\nStep 5: Test the flow locally\nDeposits cross two chains, so test against a local multi-chain environment\nbefore testnet. Follow the\nsupersim deposit transactions tutorial\nand take away how supersim surfaces the OptimismPortal ,\nL1CrossDomainMessenger , and L1StandardBridge addresses for each local\nchain, and how to watch a deposit land on the L2 without running a full\nderivation pipeline.\nStep 6: Plan for failed deposits\nAn L2 execution can fail (usually out-of-gas), and your design must decide in\nadvance who notices and who pays for the retry:\nIf … Choose … Because …\nYou went through the messenger (or Standard Bridge) A monitoring-and-replay runbook Failed messages are recorded on L2 and anyone can replay them later with a higher gas limit.\nYou went portal-direct Conservative gas limits and idempotent L2 handlers There is no recorded-message safety net; a failed deposited transaction is final.\nFor the messenger path, follow the\nreplaying a failed deposit tutorial\nand take away how a failed message is detected and the replay call that\nretries it with more gas.\nStep 7: Verify the outcome\nRun your flow end to end on testnet and confirm each link of the chain:\n- The L1 side : your transaction emits a TransactionDeposited event\nfrom the OptimismPortal (directly or via the messenger). This event is\nthe canonical proof the deposit entered the system.\n- The L2 side : the corresponding L2 transaction appears within a few\nminutes, and the target contract observed the sender it expected\n( xDomainMessageSender for messenger flows, the aliased address for\nportal-direct flows).\n- The failure drill (messenger flows): force one deposit to fail with an\nundersized minGasLimit , confirm it is recorded as a failed message, and\nreplay it successfully per Step 6.\n- Token accounting (bridge flows): amounts locked on L1 match amounts\nminted on L2, and the round trip back burns and releases correctly.\nNext steps\n- Deposits in the protocol specs :\nthe normative definition of deposited transactions, the deposit contract,\nand address aliasing.\n- contracts-bedrock reference :\ngenerated interface documentation for the current contracts, for when you\nneed the exact function and event signatures.\n- OptimismPortal2.sol on develop :\nthe deposit entry point’s source, including minimumGasLimit and the\ncalldata cap. Tracks the develop branch, so read it alongside the\nrelease your chain actually runs.\n- Superchain Token List :\nwhere custom-bridged tokens must be registered before users can find\nthem.\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."}
{"url":"https://forum.solana.com/latest","domain":"forum.solana.com","title":"Latest topics - Solana Developer Forums","hash":"faeb56638b9c13f7c304b2d0605a2225af5861dc7409e54ae081515955f66551","tokens":733,"chars":2929,"crawler":"crawler-f6nn","verified":"exact","ts":1791171701742,"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\n128\nAugust 28, 2026\nSIMD-0550: Proposal to Double Disinflation\nGovernance\neconomics\n9\n1979\nAugust 18, 2026\nDecreasing number of validators, centralizing steak, and overall network health / resilience under extreme events\nGovernance\n0\n75\nAugust 12, 2026\nTest Validator Plugin Framework\nRFP\n15\n2172\nJuly 31, 2026\nVOTE! First Governance Advisory Vote by Validators\nGovernance\nvote\n6\n2811\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\n11685\nJune 13, 2026\nSIMD-0411: Proposal for Doubling the Disinflation Rate\nGovernance\neconomics\n1\n3387\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\n305\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\n5616\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\n1086\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://ethresear.ch/latest","domain":"ethresear.ch","title":"Ethereum Research","hash":"26684f41dd50feb0de528100b69aabcab9b86cac8f9918d57f947838b8a25fc7","tokens":831,"chars":3322,"crawler":"crawler-f6nn","verified":"exact","ts":1791171704541,"text":"Ethereum Research\nTopic\nReplies\nViews\nActivity\nRead this before posting\nAdministrivia\n13\n61457\nAugust 20, 2026\nProposal for a minimal compute-anchored purchasing power signal\nEconomics\n0\n47\nOctober 2, 2026\nSix defects in one signature verification tool, found from outside in six rounds\nSecurity\n0\n45\nOctober 2, 2026\nThe Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\nExecution Layer Research\nstateless\n10\n778\nOctober 2, 2026\nMempool Account Transaction Capacity from Historical Activity (MATCHA)\nExecution Layer Research\naccount-abstraction\n,\ntransaction-privacy\n9\n515\nOctober 2, 2026\nStaking rewards as venture capital, governed by futarchy\nEconomics\nfutarchy\n,\ndao\n2\n211\nOctober 1, 2026\nTrust minimized transaction simulation using state proofs\nSecurity\n7\n628\nOctober 1, 2026\nPQ anonymity for Stealth Address Protocol\nPrivacy\n4\n198\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\n147\nSeptember 30, 2026\nTowards Encrypted Mempools from Threshold IBE without Batching\nCryptography\n4\n231\nSeptember 29, 2026\nEthereum's TCB, Part 1: The client\nSecurity\nsecurity\n3\n337\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\n407\nSeptember 27, 2026\nFormal Verification of Execution and Consensus Clients\nSecurity\nsecurity\n12\n594\nSeptember 25, 2026\nSnappy with a memory: ~40% less gossip traffic\nNetworking\nsingle-slot-finality\n1\n149\nSeptember 25, 2026\nCapacity oracles\nEconomics\n4\n406\nSeptember 25, 2026\nDesigns for EVM gas accounting in EIP-7999\nExecution Layer Research\nfee-market\n6\n460\nSeptember 24, 2026\nProprietary AMMs and Ethereum\nExecution Layer Research\nmev\n13\n1315\nSeptember 24, 2026\nCHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\nExecution Layer Research\nnetworking\n,\np2p\n0\n104\nSeptember 24, 2026\nPost-Poseidon: Hash Function Variants for Ethereum\nCryptography\n0\n307\nSeptember 23, 2026\nEIP-8411 payload segmentation under the Shadow simulator\nNetworking\nscaling\n,\np2p\n0\n79\nSeptember 23, 2026\nPost-Quantum Lattice or Hash-Based: One Question, Two Right Answers\nCryptography\npost-quantum\n1\n179\nSeptember 22, 2026\nEtheorem update: the complete executable consensus specs written in Lean 4\nConsensus\n0\n190\nSeptember 21, 2026\nPost-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\nEconomics\n0\n144\nSeptember 21, 2026\nStrict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)\nPrivacy\n0\n53\nSeptember 19, 2026\nCryptographic canaries and backups\nCryptography\n8\n7556\nSeptember 18, 2026\nSame instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter\nExecution Layer Research\n1\n130\nSeptember 18, 2026\nBounding Collusion in Capital Allocation DAOs via Subjective Human Oracles\nEconomics\ncollusion\n,\ndao\n,\npublic-good\n4\n157\nSeptember 17, 2026\nHow Hegotá can influence the state roadmap\nExecution Layer Research\n1\n216\nSeptember 17, 2026\nWen fast payload broadcast? Segment, code, push, pull, and everything in between\nNetworking\np2p\n5\n243\nSeptember 17, 2026\nnext page →"}
{"url":"https://docs.ipfs.tech/","domain":"docs.ipfs.tech","title":"IPFS Documentation | IPFS Docs","hash":"cc70bfbc3d62ef76df2bd477f2010f8bc5f857345abf085fb00bb0c2f95a5de8","tokens":1041,"chars":4164,"crawler":"crawler-f6nn","verified":"exact","ts":1791171707467,"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://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-f6nn","verified":"exact","ts":1791171709912,"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://forum.arbitrum.foundation/t/constitutional-establish-an-l1-voting-recovery-system/31534","domain":"forum.arbitrum.foundation","title":"[CONSTITUTIONAL]: Establish an L1 Voting Recovery System - Proposals - Arbitrum","hash":"f8325b2f843a66a0143ad66b2e8439711214148919b93ab1615a8b304096cfb1","tokens":3416,"chars":13663,"crawler":"crawler-f6nn","verified":"exact","ts":1791171712206,"text":"Arbitrum\n[CONSTITUTIONAL]: Establish an L1 Voting Recovery System\nProposals\nproposal\noffchain\nOctober 2, 2026, 11:15pm\n1\n[Constitutional] AIP: Establish an L1 Voting Recovery System\nAbstract\nThis AIP proposes a L1 voting system that allows ArbitrumDAO proposals to be created, voted on, queued, and executed from Ethereum L1. Voting power is derived from ARB delegations proven against confirmed Arbitrum assertions. Approved actions would be routed through a new L1 timelock to the existing upgrade executors.\nThe system is intended as a last-resort recovery path if L2 governance is broken and the Security Council is unable to act. It does not replace normal L2 governance or modify the Security Council’s authority.\nMotivation\nA simultaneous failure of L2 governance and the Security Council could prevent the DAO from repairing its governance contracts. L2 governance could become unavailable because of a contract defect. Active delegates would still exist, but the DAO would have no independent path to authorize a repair.\nThe proposed system preserves a DAO-controlled recovery path by proving L2 voting state on L1 and allowing governance to proceed without relying on the L2 governor or Security Council.\nRationale\n- Maintain an always-available L1 governance path so that it remains accessible during an emergency.\n- Use extended delays to preserve delegate reaction time, effective voting time, and a weaker form of the right to withdraw.\nSpecifications\nFor supporting technical documentation, see l1-voting.md .\nAffected Governed Chains\nTo be confirmed before the temperature check. At that time this AIP will specify if it affects Arbitrum One and Arbitrum Nova.\nSystem Components\n- L1ArbitrumGovernor : A modified OpenZeppelin governor that creates proposals, checks proven voting power, records votes, and queues successful proposals.\n- L1ArbitrumTimelock : A new deployment of the same timelock contract that exists on L1.\n- DelegateMapping : A contract deployed on L1 and L2 that links an L1 voting address to an L2 delegate.\n- L2StateMirror : A contract that checkpoints confirmed assertions and stores L2 state values proven against them.\n- ProofHelper : A helper contract for handling L2 block headers and storage proofs.\n- VotingTokenMirror : The governor-facing contract that resolves L1 voters to L2 delegates and returns proven voting power and quorum inputs.\nDelegate Registration\n- Delegates using contract addresses: Must register an L1 voting address through DelegateMapping on Arbitrum One. Registration should preferably occur before an L1 proposal is created. Following proposal creation, delegates have 3 days to register so the updated mapping can be included in a confirmed assertion before voting begins.\n- Delegates using EOAs: May register an L1 voting address using an EIP-712 signature submitted through L2StateMirror.claimL1AddressBySig , without first registering the address on Arbitrum One. The signature is bound to the applicable assertion.\n- In both cases, the L1 voting address must claim the corresponding L2 delegate through the L1 DelegateMapping before proposing or voting.\nDeployment Parameters\nFor more detail on the “7 day censorship budget”, see the BoLD whitepaper .\n- Voting delay: 17 days, comprising 3 days for delegate reaction, including acquiring voting power or registering in the L2 DelegateMapping , plus up to 14 days for assertion confirmation.\n- Voting period: 21 days, comprising 14 days of effective voting time plus a 7-day censorship budget\n- Timelock delay: 25 days, comprising a 14-day worst-case assertion-confirmation period plus 11 additional days corresponding to the current 8-day L2 timelock and 3-day L1 timelock.\n- Proposal block lookback: Up to 300 L1 blocks, approximately one hour, for the proposal-threshold checkpoint. This gives proposers time to prove prerequisite information in the L2StateMirror\n- Quorum numerator: 5000 (50%), applied to the totalDelegated Votable Tokens at the locked snapshot block, consistent with the core governor on L2.\n- Late-quorum extension period: 2 days, consistent with the core governor on L2.\n- Minimum and maximum quorum: 150 million and 450 million ARB, respectively, consistent with the core governor on L2.\nGovernance and Execution\n- Deploy the L1 governance components behind transparent proxies owned by the existing proxy admin or admins, as applicable. See DeployL1Voting.s.sol for the deployment procedure.\n- Grant the new L1 timelock the EXECUTOR_ROLE on the L1 upgrade executor.\n- Grant the L2 alias of the new L1 timelock the EXECUTOR_ROLE on the L2 upgrade executor.\nProposed Changes to the ArbitrumDAO Constitution\nThis proposal would amend Section 2 of the ArbitrumDAO Constitution to recognize an additional L1 voting procedure.\nThe existing AIP process on Arbitrum One would remain unchanged. The L1 Voting Procedure would operate as an additional DAO-controlled governance path using ARB voting power proven from confirmed Arbitrum state.\nClarify the Scope of the Existing Process\nLocation: Section 2: DAO Proposals and Voting Procedures\nCurrent text:\nThe following process governs the rules and procedures by which the ArbitrumDAO may propose, vote on and implement Arbitrum Improvement Proposals (AIPs). No AIP may be in violation of applicable laws, in particular sanctions-related regulations.\nProposed new text:\nThe following process governs the rules and procedures by which the ArbitrumDAO may propose, vote on and implement Arbitrum Improvement Proposals (AIPs). For AIPs submitted through the L1 Voting Procedure described below, the rules and procedures in this Section apply except where expressly modified by the L1 Voting Procedure. No AIP may be in violation of applicable laws, in particular sanctions-related regulations.\nClarify the Existing Phase 2\nLocation: Section 2: DAO Proposals and Voting Procedures, Phase 2\nCurrent text:\nPhase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/ . The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens. After 3 days, a voter distribution snapshot will be taken and the voting period will begin; this gives interested parties time to discuss the AIP and gather votes before the voter distribution snapshot is taken.\nProposed new text:\nPhase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/ . The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens.\nAfter 3 days, a voter distribution snapshot will be taken and the voting period will begin;\nthis gives interested parties time to discuss the AIP and gather votes before the voter\ndistribution snapshot is taken.\nFor an AIP submitted through the L1 Voting Procedure, the requirements in the\npreceding two paragraphs concerning submission, the proposer threshold, the voter\ndistribution snapshot and the start of voting are replaced by the corresponding\nrequirements of the L1 Voting Procedure. The remaining provisions of this Phase 2,\nincluding those concerning labeling and classification of AIPs, specification of affected\nGoverned Chains, and the recommended AIP contents, apply to an AIP submitted\nthrough the L1 Voting Procedure.\nClarify the Existing Phase 3\nLocation: Section 2: DAO Proposals and Voting Procedures, Phase 3\nCurrent text:\nPhase 3: DAO votes on AIP, on Arbitrum One (14-16 days): During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP.\nProposed new text:\nPhase 3: DAO votes on AIP, on Arbitrum One (14-16 days): During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP, unless the AIP was submitted through the L1 Voting Procedure in which case voting takes place as provided in the L1 Voting Procedure. Threshold 1 and Threshold 2, as set out below, apply to every AIP, including an AIP submitted through the L1 Voting Procedure.\nAdd an L1 Voting Procedure\nLocation: Section 2: DAO Proposals and Voting Procedures\nCurrent text:\nNo corresponding provision currently exists.\nProposed new text:\nL1 Voting Procedure\nIn addition to the AIP process described above, the ArbitrumDAO may propose, vote on, approve, and implement AIPs through governance smart contracts deployed on Ethereum.\nVoting power under this procedure must be derived from Votable Tokens delegated on Arbitrum One and proven on Ethereum against a confirmed Arbitrum One assertion.\nThe AIP proposer is required to have an address on Arbitrum One that is delegated at least 1,000,000 Votable Tokens, or an Ethereum address registered as the L1 voting address for such an address, in each case as proven against a confirmed Arbitrum One assertion.\nFollowing submission of an AIP through the L1 Voting Procedure, voting will begin after 17 days . This comprises 3 days for delegates to gather voting power or register their L1 voting addresses, plus up to 14 days for assertion confirmation.\nAfter the voting delay, the ArbitrumDAO will be able to vote directly on-chain through the governance smart contracts deployed on Ethereum. Before the first vote is cast, the voter distribution snapshot must be fixed to a confirmed Arbitrum One block.\nThe voting period ends 21 days after the start of voting. However, if Threshold 2 was reached within the last 2 days of the 21-day voting period, the voting period will be extended to end 2 days after Threshold 2 was reached.\nAn AIP submitted through the L1 Voting Procedure passes if Threshold 1 and the Constitutional AIP requirements under Threshold 2 are satisfied. Voting power and Delegated Votable Tokens will be determined using Arbitrum One state proven on Ethereum against the confirmed assertion used for the voter distribution snapshot.\nIf the AIP passes, it will be queued in the L1VotingTimelock, a governance timelock smart contract deployed on Ethereum, for a minimum period of 25 days. Following that period, the AIP may be implemented through the relevant upgrade executor or executors.\nThe provisions of Phases 2 and 3 identified above as replaced, and phases 4 through 7 of the ordinary AIP process, do not apply to an AIP submitted through the L1 Voting Procedure. Instead the 17-day voting delay, 21-day voting period, applicable late-quorum extension, and 25-day L1 timelock govern its submission, voting, approval, and implementation.\nThe provisions of this Section concerning forum discussion, temperature checks, AIP labeling and classification, affected Governed Chains, recommended AIP contents voting options, Threshold 1, and Threshold 2 apply to AIPs submitted through the L1 Voting Procedure, except that threshold 2 applies as provided above.\nAn AIP may not be submitted through the L1 Voting Procedure while another AIP proposing the same or conflicting actions is pending under the ordinary AIP process, and an AIP may not be submitted under the ordinary AIP process while another AIP proposing the same or conflicting actions is pending under the L1 Voting Procedure. An AIP is pending from its submission until it fails to pass or is implemented. As a recommended guideline, DAO members should vote against any AIP submitted in violation of this paragraph.\nThe L1 Voting Procedure does not replace or modify the ordinary AIP process. It does not modify the Security Council’s powers under Section 3 of this Constitution.\nSteps to Implement\n- Publish this proposal on the ArbitrumDAO governance forum for community and delegate review.\n- Complete the forum discussion period.\n- Submit the proposal to Snapshot for a temperature check.\n- Incorporate applicable DAO feedback and finalize the contracts, deployment configuration, tests, and operating procedures.\n- Complete an independent security audit and publish the audit report and applicable remediations.\n- Test proposal creation, proof submission, voting, queuing, cross-chain execution, and recovery from stale checkpoints in a designated test environment.\n- Publish the final contract addresses, verified source code, deployment parameters, audit materials, constitutional amendments, and executable governance payload.\n- Submit the final Constitutional AIP through the standard ArbitrumDAO governance process.\n- If approved, deploy and initialize the system, grant the required executor roles, and begin checkpoint monitoring.\nTimeline\nThe implementation timeline will be finalized following technical review, audit scoping, and review by the Arbitrum Foundation and Legal.\n- Forum publication: This post\n- Temperature check: To be confirmed\n- Security audit and testing: Ongoing\n- Constitutional on-chain vote: Following successful technical review, audit, testing, and publication of the executable payload\n- Deployment: Subject to approval of the Constitutional AIP\nOverall costs\nAll engineering and research conducted for this proposal was done so by Offchain Labs at no explicit or additional costs to the ArbitrumDAO\n1 Like\nRelated topics\nTopic\nReplies\nViews\nActivity\nConstitutional - Extend Delay on L2Time Lock\nFinalized AIPs\n68\n1349\nNovember 1, 2024\nProposal: AIP-1.2 - Foundation and DAO Governance\nFinalized AIPs\npassed\n,\ntally\n65\n19046\nJune 21, 2023\n[Constitutional] AIP: DVP Quorum\nFinalized AIPs\n21\n897\nDecember 12, 2025\nExploring the Viability of Governance Attacks - Part 1: Arbitrum Governance and its Challenges\nARDC Research Member\n0\n361\nApril 9, 2025\nAreta Delegate Thread\nDelegate Statements\ndelegation\n,\ndelegate-statements\n27\n817\nAugust 12, 2026"}
{"url":"https://docs.celestia.org/","domain":"docs.celestia.org","title":"Celestia Documentation","hash":"546343424bf7aeafe6a2bf00e87acdf98ec60c7d07356e0b181f125b6fcef1a9","tokens":106,"chars":423,"crawler":"crawler-f6nn","verified":"exact","ts":1791171714526,"text":"Skip to Content\nCelestia docs\nCelestia is the modular blockchain powering unstoppable apps with full-stack\ncontrol.\n📚\nLearn\nUnderstand modular blockchains and Celestia’s architecture\n🛠️\nBuild\nStart building applications on Celestia’s data availability layer\n⚙️\nOperate\nRun and maintain Celestia nodes and infrastructure\n🔌\nAPI\nReference for Celestia’s node RPC methods and client libraries\nLast updated on October 1, 2026"}
{"url":"https://docs.anza.xyz/cli","domain":"docs.anza.xyz","title":"Solana CLI Tool Suite | Agave","hash":"a28d45f2fcdcfb3a758c35fc79dd5ba053c7d12d698f330774db63072fa356b9","tokens":205,"chars":820,"crawler":"crawler-f6nn","verified":"exact","ts":1791171716444,"text":"Skip to main content\nSolana CLI Tool Suite\nIn this section, we will describe how to use the Solana command-line tools to\ncreate a wallet , to send and receive SOL tokens, and to participate in the\ncluster by delegating stake.\nTo interact with a Solana cluster, we will use its command-line interface, also\nknown as the CLI. We use the command-line because it is the first place the\nAnza core team deploys new functionality. The command-line interface is not\nnecessarily the easiest to use, but it provides the most direct, flexible, and\nsecure access to your Solana accounts.\nGetting Started\nTo get started using the Solana Command Line (CLI) tools:\n- Install the Solana CLI Tool Suite\n- Introduction to our CLI conventions\n- Create a Wallet using the CLI\n- Choose a Cluster to connect to using the CLI\n- Getting Started"}
{"url":"https://solana.com/docs/core/transactions","domain":"solana.com","title":"","hash":"638e58ef5223351ab022ddbad9233d29eb14bf5c668f0a43ddc617ff7cceecf3","tokens":962,"chars":3846,"crawler":"crawler-f6nn","verified":"exact","ts":1791171718416,"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![](\"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://www.anchor-lang.com/docs","domain":"www.anchor-lang.com","title":"Introduction","hash":"d94f4b1ad24780aa70d91f351f31088e6440c19efb303267de80435024216953","tokens":199,"chars":794,"crawler":"crawler-f6nn","verified":"exact","ts":1791171820507,"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://docs.pyth.network/","domain":"docs.pyth.network","title":"Pyth Developer Hub","hash":"95ccd773aac6c27b7a91043b966570faf6b10f8c7b638561c2e23a465cd6ea08","tokens":364,"chars":1456,"crawler":"crawler-f6nn","verified":"exact","ts":1791171822526,"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.sui.io/getting-started/tooling","domain":"docs.sui.io","title":"Developer Tools","hash":"36f64a124964c5c98b5de2a22ce0cb16f846559fba63d9db45541357a27b218b","tokens":5671,"chars":22682,"crawler":"crawler-f6nn","verified":"exact","ts":1791171825042,"text":"# Developer Tools\n*[Documentation index](/llms.txt) · [Full index](/llms-full.txt)*\nBrowse the tools available for developing on Sui. Each tool includes a description, installation command, and link to its source.\n:::caution\nTools tagged as Community are maintained by third-party developers. Mysten Labs, Sui Foundation, and Walrus Foundation do not guarantee their functionality, security, or compatibility with the latest platform updates.\n:::\n## Fundamentals\n- [suiup](/getting-started/onboarding/sui-install): Installer and version manager for the Sui toolchain. Installs and manages sui, mvr, move-analyzer, walrus, and other Sui binaries.\n- [Sui CLI](/references/cli): The core Sui command-line interface. Includes sui move, sui client, sui replay, and other subcommands.\n- [Play Move](https://www.playmove.dev/): Move web IDE for quick experimentation without any downloads.\n- [Sui Devstack](https://ts-sdks-incubation.vercel.app/devstack): Boot a local Sui stack with Walrus, Seal, DeepBook, and faucets from a single TypeScript config. Publishes packages, funds accounts, and generates typed bindings.\n## Writing Move\nIDEs, editor extensions, and language tools for writing Move smart contracts.\n- [Move Analyzer](/references/ide/move): Move Language Server providing code completion, go-to-definition, hover information, and diagnostics.\n- [Prettier Move Plugin](https://marketplace.visualstudio.com/items?itemName=mysten.prettier-move): Official Move code formatter using a Prettier plugin backed by tree-sitter.\n- [Tree Sitter Move](https://github.com/MystenLabs/sui/tree/main/external-crates/move/tooling/tree-sitter): Tree-sitter grammar for the Move language, enabling syntax highlighting and code analysis in supported editors.\n- [Move Registry CLI (MVR)](https://docs.suins.io/move-registry): On-chain package manager for Sui with human-readable names, versioning, and dependency resolution.\n- [Move Registry](https://www.moveregistry.com/): Web portal for the Move Registry. Browse, search, and manage Move packages.\n- [IntelliJ Sui Move Language Plugin](https://plugins.jetbrains.com/plugin/23301-sui-move-language): IntelliJ-based plugin for Move on Sui development.\n- [Emacs move-mode](https://github.com/amnn/move-mode): Emacs major-mode for editing smart contracts written in the Move programming language.\n- [Move.vim](https://github.com/yanganto/move.vim): Vim syntax highlighting that supports the Move 2024 edition.\n- [Zed Move Extension](https://github.com/Tzal3x/move-zed-extension): Move language support for the Zed editor.\n- [BitsLab IDE](https://www.youtube.com/watch?v=-9-WkqQwtu8): Online Move code editor that requires no configuration. Supports Move syntax highlighting and interacting with Sui.\n- [ChainIDE](https://chainide.gitbook.io/chainide-english-1/ethereum-ide-1/9.-sui-ide): Cloud-powered Move development platform for Sui.\n- [Sui Extension (zktx.io)](https://docs.zktx.io/vsce/sui/): VS Code extension for compiling, deploying, and testing Sui smart contracts directly within the editor.\n- [Sui TUI](https://crates.io/crates/suitui): Terminal UI tool for Sui.\n## Building apps\nFrontend toolkits, wallet integration, authentication, and app scaffolding.\n- [@mysten/create-dapp](https://sdk.mystenlabs.com/dapp-kit): CLI tool for creating Sui apps.\n- [Sui dApp Kit](https://sdk.mystenlabs.com/dapp-kit): React components, hooks, and utilities for building apps on Sui.\n- [SuiLink](https://www.suilink.io/): Securely link wallet addresses from different blockchains to a Sui wallet address. Receive a soulbound NFT as proof of ownership.\n- [SAGAT](/sui-stack/sagat): Multisig wallet management platform for proposing, signing, and managing multi-party transactions.\n- [@mysten/signers](https://www.npmjs.com/package/@mysten/signers): The Sui KMS Signers package provides a set of tools for securely signing transactions using Key Management Services (KMS) like AWS KMS and GCP KMS.\n- [YubiSui](https://github.com/MystenLabs/yubigen): Create a Sui wallet inside a YubiKey and sign Sui transactions with it.\n- [Sui dApp Starter](https://sui-dapp-starter.dev/docs/): Full-stack boilerplate for scaffolding Sui projects with React.\n- [human.tech Wallet Protocol (WaaP) SDK](https://docs.waap.human.tech/for-apps): White label embedded wallets with social login, biometrics and gas sponsorship. One account works across apps, and also signs on Solana and EVM.\n- [Suiet Wallet Kit](https://kit.suiet.app/docs/QuickStart): React toolkit for apps to interact with all wallet types in Sui easily.\n- [@suiware/kit](https://github.com/suiware/kit/tree/main/packages/kit#readme): Opinionated React components and hooks for Sui apps.\n- [Sui Suitcase (Polymedia)](https://github.com/juzybits/polymedia-suitcase): Sui utilities for TypeScript, Node, and React.\n- [Sui dApp Scaffold (Bucket Protocol)](https://github.com/Bucket-Protocol/sui-dapp-scaffold-v1): Frontend scaffold for a decentralized app on Sui.\n- [Wormhole Kit (zktx.io)](https://github.com/zktx-io/wormhole-kit-monorepo): React library that enables instant integration of Wormhole into your app.\n- [create-dubhe (Dubhe Engine)](https://github.com/0xobelisk/dubhe/tree/main/packages/create-dubhe): Create a new Dubhe project on Sui.\n- [sui-dapp-kit-theme-creator](https://sui-dapp-kit-theme-creator.app/): Build custom Sui dApp Kit themes.\n- [PTB Studio](https://suicookbook.com/ptb-studio): Visual Programmable Transaction Block builder.\n### zkLogin\nTools and demos for integrating zkLogin authentication into your app.\n- [useSuiZkLogin](https://github.com/pixelbrawlgames/use-sui-zklogin): React hook and functions for seamless zkLogin integration on Sui.\n- [React ZK Login Kit](https://github.com/denyskozak/react-sui-zk-login-kit): Ready-to-use component with hook for sign-in and sign-transaction.\n- [zkLogin Demo (Polymedia)](https://github.com/juzybits/polymedia-zklogin-demo): Demo implementation of zkLogin.\n- [zkLogin Demo (jovicheng)](https://github.com/jovicheng/sui-zklogin-demo): Demo implementation of Sui zkLogin.\n- [zkWallet Demo (ronanyeah)](https://github.com/ronanyeah/sui-zk-wallet): Demo implementation of a Sui zk wallet.\n## Testing and debugging\nTools for unit testing, replaying transactions, and debugging Move execution locally.\n\n\n![\"Anza\"](\"https://i.postimg.cc/VkKTnMM9/agave-logo-talc-1.png\"){kind=logo}
\n\n
(Source Chain)\nparticipant CoreEth as Core Contract Ethereum
(Source Chain)\nparticipant Guardians\nparticipant WTTSol as WTT Solana
(Destination Chain)\nparticipant CoreSol as Core Contract Solana
(Destination Chain)\nAlice->>WTTEth: Initiate ETH transfer
(lock ETH)\nWTTEth->>CoreEth: Publish transfer message\nCoreEth-->>Guardians: Emit message event\nGuardians->>Guardians: Sign and publish VAA\nalt Automatic VAA submission\nGuardians->>WTTSol: Relayer submits VAA\nelse Manual VAA submission\nAlice->>Guardians: Retrieve VAA\nAlice->>WTTSol: Submit VAA\nend\nWTTSol->>CoreSol: Verify VAA\nCoreSol-->>WTTSol: VAA verified\nWTTSol-->>Alice: Mint wrapped ETH on Solana (complete transfer)\nMaybe Alice wants to transfer her wrapped ETH on Solana back to native ETH on Ethereum. The wrapped ETH is burned on Solana’s WTT, and the equivalent 5 ETH are released on Ethereum. The diagram below illustrates this transfer flow.\nsequenceDiagram\nparticipant User as Alice\nparticipant WTTSrc as WTT Solana
(Source Chain)\nparticipant CoreSrc as Core Contract Solana
(Source Chain)\nparticipant Guardians\nparticipant WTTDst as WTT Ethereum
(Destination Chain)\nparticipant CoreDst as Core Contract Ethereum
(Destination Chain)\nUser->>WTTSrc: Initiate transfer
(burn wrapped ETH)\nWTTSrc->>CoreSrc: Publish message\nCoreSrc-->>Guardians: Emit message event\nGuardians->>Guardians: Sign and publish VAA\nalt Automatic VAA submission\nGuardians->>WTTDst: Relayer submits VAA\nelse Manual VAA submission\nUser->>Guardians: Retrieve VAA\nUser->>WTTDst: User submits VAA directly\nend\nWTTDst->>CoreDst: Verify VAA\nCoreDst-->>WTTDst: VAA verified\nWTTDst-->>User: Release native ETH on Ethereum (Complete transfer)\nAutomatic vs. Manual Transfers ＃\nWTT supports two modes of transfer, depending on whether the VAA submission step is handled automatically or manually:\n- Automatic : A relayer service listens for new VAAs and automatically submits them to the destination chain.\n- Manual : The user (or dApp) must retrieve the VAA and manually submit it to the destination chain.\nHere's a quick breakdown of the key differences:\nFeature Automatic Transfer Manual Transfer\nWho submits the VAA? Relayer User or dApp\nUser Experience Seamless, one-step Requires manual intervention\nBest for End-users, simple UIs Custom dApps, advanced control\nDependency Requires relayer support None\nCompleting Manual Transfers ＃\nThe user who initiated the transfer must complete it within 24 hours for manual transfers. Guardian Sets are guaranteed to be valid for at least that long. If a user waits longer, the Guardian Set may have changed between initiation and redemption, causing the VAA to be rejected.\nIf this occurs, follow the Replace Outdated Signatures in VAAs tutorial to update the VAA with signatures from the current Guardian Set.\nWTT Relayer (TBR) ＃\nWhen completing an automatic transfer using WTT, either through Connect or programmatically via the Wormhole TypeScript SDK , the WTT Relayer (TBR) manages the interaction with the underlying WTT contracts on supported chains where the TBR is available .\nFlow of an Automatic Transfer via TBR ＃\nThe flow of an automatic transfer using the TBR looks like this:\n-\nInitiation on the Source Chain\nThe transfer begins when a user initiates a transfer on the source chain, which results in the TBR contract being called.\n-\nPrepare and Forward the Transfer\nThe TBR verifies the token, encodes transfer details (relayer fee, native gas request, recipient), and forwards the transfer to WTT.\n-\nCore Messaging Layer Processes the Transfer\nWTT emits a message to the Core Contract. Guardians observe the message and produce a signed VAA attesting to the transfer.\n-\nOff-Chain Relayer Observes the VAA\nAn off-chain relayer verifies the destination chain and token registration and then prepares to complete the transfer.\n-\nRelayer Computes Native Drop-Off and Submits the VAA\nThe relayer queries the destination TBR for the native gas amount, includes it in the transaction, and submits the signed VAA.\n-\nTBR Validates and Completes the Transfer\nThe destination TBR validates the VAA by invoking the WTT contract, confirms it's from a registered TBR, verifies the token and native gas request, and then takes custody of the tokens.\n-\nAsset Distribution on the Destination Chain\nThe TBR sends the remaining tokens and native gas to the user, pays the off-chain relayer fee, and refunds any excess native tokens.\nThe following diagram illustrates the key steps in the source chain during a transfer:\nsequenceDiagram\nparticipant User\nparticipant SourceTBR as Source Chain TBR\nparticipant SourceWTT as Source Chain WTT\nparticipant Messaging as Core Messaging Layer\nUser->>SourceTBR: Initiate transfer (token,
recipient, fees, native gas)\nSourceTBR->>SourceWTT: Forward transfer (burn or lock tokens)\nSourceWTT->>Messaging: Publish transfer message\nOnce the core messaging layer processes the transfer, the destination chain handles completion as shown below:\nsequenceDiagram\nparticipant Messaging as Core Messaging Layer\nparticipant Relayer as Off-chain Relayer\nparticipant DestTBR as Destination Chain TBR\nparticipant DestWTT as Destination Chain
WTT\nparticipant DestUser as User
(Destination Chain)\nMessaging->>Relayer: Emit signed VAA for transfer\nRelayer->>Relayer: Verifies destination chain and token registration\nRelayer->>DestTBR: Query native gas amount\nRelayer->>DestTBR: Submit signed VAA\nDestTBR->>DestWTT: Validate VAA\nDestTBR->>DestTBR: Take custody of tokens\nDestTBR->>DestUser: Send tokens (after fees & native gas)\nDestTBR->>Relayer: Pay relayer fee & refund excess\nNext Steps ＃\nNow that you’ve seen how a transfer works, try both types yourself to experience the full process.\n-\nGet Started with WTT\nPerform token transfers using WTT, including manual and automatic transfers.\nGet Started\nLast update: September 28, 2026\n| Created: September 28, 2026"} {"url":"https://docs.optimism.io/app-developers/quickstarts/get-started","domain":"docs.optimism.io","title":"Optimism Documentation","hash":"bf723b4a58f7ae8ae448c4e6d40ab2bd1c82685fca622415607ff6d997d2a531","tokens":857,"chars":3428,"crawler":"crawler-f6nn","verified":"exact","ts":1791172021364,"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\nBuild an app\nApp developer quickstart\nGet testnet ETH, deploy your first contract to OP Sepolia, and bridge assets - your first steps on the Superchain.\nOP Stack chains are EVM equivalent : everything you know from Ethereum works here, and everything you build here works across the OP Stack ecosystem.\nThis quickstart takes you from zero to a deployed contract on the OP Sepolia testnet, using only free testnet funds.\nNo real funds are needed at any point — everything below runs on testnets.\nBefore you start\nYou’ll need:\n- A wallet you control (any EVM wallet works; you’ll export or generate a private key for testnet use only).\n- A terminal with curl available.\nUse a fresh, testnet-only private key for tutorials. Never paste a key that holds real funds into a terminal.\n1\nGet testnet ETH\nGrab free OP Sepolia ETH from the Superchain Faucet .\nOther options are listed on the testnet faucets page .\n2\nConnect to OP Sepolia\nOP Sepolia’s public RPC endpoint is https://sepolia.optimism.io and its chain ID is 11155420 .\nVerify you can reach it:\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n--data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_chainId\",\"params\":[],\"id\":1}' \\\nhttps://sepolia.optimism.io\nExpected result: {\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0xaa37dc\"} ( 0xaa37dc = 11155420).\nFor other networks and production-grade endpoints, see network information and RPC providers .\n3\nDeploy your first contract\nFollow the Deploy a contract to OP Sepolia tutorial.\nIt walks you through installing Foundry, deploying a small Greeter contract, and reading and writing to it from the command line — the same workflow you’d use on Ethereum.\n4\nBridge ETH between L1 and L2 (optional)\nApps often need to move assets between Ethereum and an OP Stack chain.\nStart with Bridging basics to understand the model, then follow the Bridging ETH with Viem tutorial to do a Sepolia → OP Sepolia deposit programmatically.\nWhere to go next\nBuild apps on OP Stack chains\nDevelopment workflow, tooling, and what (little) is different from Ethereum.\nTest your apps\nTest against OP Stack chains locally and in CI.\nGo cross-chain with interop\nBuild apps that span multiple Superchain chains.\nIntegrate DeFi with the Actions SDK\nLend, borrow, and swap with lightweight, type-safe modules (early preview — not production-ready).\nRunning your app in production A production application depends on infrastructure your team does not run: RPC endpoints that hold up under real traffic (the public endpoints are rate-limited and not built for production), bridges your users rely on, and a chain whose operator keeps sequencing, upgrades, and incident response going around the clock. These docs cover building and testing. If your application is growing toward dedicated blockspace of its own, OP Enterprise offers managed and supported paths to running a chain. These docs stay the reference for what you build either way. OP Enterprise is Optimism’s managed offering.\nNeed help?\n- Ask a question or report documentation issues on the Optimism monorepo issue tracker .\nWas this page helpful?\nAssistant\nResponses are generated using AI and may contain mistakes."} {"url":"https://docs.anza.xyz/validator/blockstore","domain":"docs.anza.xyz","title":"Blockstore in a Solana Validator | Agave","hash":"5e552ebfff5dd7f90146ba8bb66a2068043e6299205ec42e2ed2ee95d72e407b","tokens":1608,"chars":6429,"crawler":"crawler-f6nn","verified":"exact","ts":1791172025435,"text":"Skip to main content\nBlockstore in a Solana Validator\nAfter a block reaches finality, all blocks from that one on down to the genesis block form a linear chain with the familiar name blockchain. Until that point, however, the validator must maintain all potentially valid chains, called forks . The process by which forks naturally form as a result of leader rotation is described in fork generation . The blockstore data structure described here is how a validator copes with those forks until blocks are finalized.\nThe blockstore allows a validator to record every shred it observes on the network, in any order, as long as the shred is signed by the expected leader for a given slot.\nShreds are moved to a fork-able key space the tuple of leader slot + shred index (within the slot). This permits the skip-list structure of the Solana protocol to be stored in its entirety, without a-priori choosing which fork to follow, which Entries to persist or when to persist them.\nRepair requests for recent shreds are served out of RAM or recent files and out of deeper storage for less recent shreds, as implemented by the store backing Blockstore.\nFunctionalities of Blockstore\n-\nPersistence: the Blockstore lives in the front of the nodes verification\npipeline, right behind network receive and signature verification. If the\nshred received is consistent with the leader schedule (i.e. was signed by the\nleader for the indicated slot), it is immediately stored.\n-\nRepair: repair is the same as window repair above, but able to serve any\nshred that's been received. Blockstore stores shreds with signatures,\npreserving the chain of origination.\n-\nForks: Blockstore supports random access of shreds, so can support a\nvalidator's need to rollback and replay from a Bank checkpoint.\n-\nRestart: with proper pruning/culling, the Blockstore can be replayed by\nordered enumeration of entries from slot 0. The logic of the replay stage\n(i.e. dealing with forks) will have to be used for the most recent entries in\nthe Blockstore.\nBlockstore Design\n-\nEntries in the Blockstore are stored as key-value pairs, where the key is the concatenated slot index and shred index for an entry, and the value is the entry data. Note shred indexes are zero-based for each slot (i.e. they're slot-relative).\n-\nThe Blockstore maintains metadata for each slot, in the SlotMeta struct containing:\n-\nslot_index - The index of this slot\n-\nnum_blocks - The number of blocks in the slot (used for chaining to a previous slot)\n-\nconsumed - The highest shred index n , such that for all m < n , there exists a shred in this slot with shred index equal to n (i.e. the highest consecutive shred index).\n-\nreceived - The highest received shred index for the slot\n-\nnext_slots - A list of future slots this slot could chain to. Used when rebuilding\nthe ledger to find possible fork points.\n-\nlast_index - The index of the shred that is flagged as the last shred for this slot. This flag on a shred will be set by the leader for a slot when they are transmitting the last shred for a slot.\n-\nis_connected - True iff every block from 0...slot forms a full sequence without any holes. We can derive is_connected for each slot with the following rules. Let slot(n) be the slot with index n , and slot(n).is_full() is true if the slot with index n has all the ticks expected for that slot. Let is_connected(n) be the statement that \"the slot(n).is_connected is true\". Then:\nis_connected(0) is_connected(n+1) iff (is_connected(n) and slot(n).is_full()\n-\nChaining - When a shred for a new slot x arrives, we check the number of blocks ( num_blocks ) for that new slot (this information is encoded in the shred). We then know that this new slot chains to slot x - num_blocks .\n-\nSubscriptions - The Blockstore records a set of slots that have been \"subscribed\" to. This means entries that chain to these slots will be sent on the Blockstore channel for consumption by the ReplayStage. See the Blockstore APIs for details.\n-\nUpdate notifications - The Blockstore notifies listeners when slot(n).is_connected is flipped from false to true for any n .\nBlockstore APIs\nThe Blockstore offers a subscription based API that ReplayStage uses to ask for entries it's interested in. These subscription API's are as follows:\n-\nfn get_slots_since(slots: &[u64]) -> Result