Blast yield comes from ETH staking and RWA protocols. The yield from these decentralized protocols is passed back to Blast users automatically. The default interest rate on other L2s is 0%. On Blast, it's 4% for ETH and 5% for stablecoins.
## Why a new L2
After the merge, Ethereum provides 4% yield on ETH. On-chain T-Bill protocols provide 5% yield on stablecoins. If users do not match or beat these rates, they are losing money to a form of inflation.
L2s today do not have this yield. Incorporating ETH and stablecoin yield natively requires a new L2 designed from the ground up. Blast is an EVM-compatible, optimistic rollup that raises the baseline yield for users and developers without changing the experience cryptonatives expect.
This yield makes it possible to create new business models for Dapps that aren’t possible on other L2s.
## How Blast works
### Auto Rebasing
ETH itself, not WETH, STETH, or any other ERC20, is natively rebasing on the L2. The ETH balance for EOAs is automatically rebasing. Smart contracts can opt-in to this rebasing, making it easy to existing Dapps to deploy on Blast without any changes.
USDB, Blast’s native stablecoin, is automatically rebasing as well. Like ETH on Blast, USDB is automatically rebasing for EOAs. USDB is also automatically rebasing for smart contracts. Smart contracts can opt-out from this rebasing.
### L1 Staking
Blast only became possible following Ethereum's Shanghai upgrade. ETH yield from L1 staking, initially Lido, is automatically transferred to users via rebasing ETH on the L2.
In the future, the Blast community will have the power to supplement, or even fully replace, Lido Blast-native solutions or other third party protocols.
### T-Bill Yield
Users who bridge stablecoins receive USDB, Blast's auto-rebasing stablecoin. The yield for USDB comes from MakerDAO's on-chain T-Bill protocol. USDB can be redeemed for DAI when bridging back to Ethereum.
In the future, the Blast community will have the power to supplement, or even fully replace, MakerDAO with Blast-native solutions or other third party protocols.
### Gas Revenue Sharing
Other L2s keep revenue from gas fees for themselves. Blast gives net gas revenue back to Dapps programmatically. Dapps developers can keep this revenue for themselves or use it to subsidize gas fees for users.
# Points API (Retired)
Source: https://metalayerlabs.mintlify.app/airdrop/mainnet-points-api/overview
Throughout Phase 1 and Phase 2 of the Blast Airdrop, the Points API allowed Blast dapps to redistribute Blast points and Gold to users.
With the launch of the Phase 2 Airdrop and 
The intended mainnet parameters look like this:
## Custom Gas Fee Claims
The following function is the lowest level claim helper. It allows you to specify exactly how much ETH you'd like to claim and how many ether-seconds you'd like to use to contribute to your claim rate.
```solidity
function claimGas(
address contractAddress,
address recipient,
uint256 etherToClaim,
uint256 etherSecondsToConsume
) external returns (uint256);
```
Claiming 1 ETH at the `ceilClaimRate` requires `ceilGasSeconds` ether-seconds. Providing fewer `ceilGasSeconds` than this would result in an effective claim rate less than the `ceilClaimRate`, based on the `zeroClaimRate` and `baseClaimRate` parameters.
# IBlast Interface
In the interface below, when you see a function like `configureX` with corresponding `configureXOnBehalf` version, the difference is that `configureX` configures the caller and `configureXOnBehalf` configures the contract corresponding to the `contractAddress` parameter.
```solidity
enum YieldMode {
AUTOMATIC,
VOID,
CLAIMABLE
}
enum GasMode {
VOID,
CLAIMABLE
}
interface IBlast {
// configure
function configureContract(address contractAddress, YieldMode _yield, GasMode gasMode, address governor) external;
function configure(YieldMode _yield, GasMode gasMode, address governor) external;
// base configuration options
function configureClaimableYield() external;
function configureClaimableYieldOnBehalf(address contractAddress) external;
function configureAutomaticYield() external;
function configureAutomaticYieldOnBehalf(address contractAddress) external;
function configureVoidYield() external;
function configureVoidYieldOnBehalf(address contractAddress) external;
function configureClaimableGas() external;
function configureClaimableGasOnBehalf(address contractAddress) external;
function configureVoidGas() external;
function configureVoidGasOnBehalf(address contractAddress) external;
function configureGovernor(address _governor) external;
function configureGovernorOnBehalf(address _newGovernor, address contractAddress) external;
// claim yield
function claimYield(address contractAddress, address recipientOfYield, uint256 amount) external returns (uint256);
function claimAllYield(address contractAddress, address recipientOfYield) external returns (uint256);
// claim gas
function claimAllGas(address contractAddress, address recipientOfGas) external returns (uint256);
function claimGasAtMinClaimRate(address contractAddress, address recipientOfGas, uint256 minClaimRateBips) external returns (uint256);
function claimMaxGas(address contractAddress, address recipientOfGas) external returns (uint256);
function claimGas(address contractAddress, address recipientOfGas, uint256 gasToClaim, uint256 gasSecondsToConsume) external returns (uint256);
// read functions
function readClaimableYield(address contractAddress) external view returns (uint256);
function readYieldConfiguration(address contractAddress) external view returns (uint8);
function readGasParams(address contractAddress) external view returns (uint256 etherSeconds, uint256 etherBalance, uint256 lastUpdated, GasMode);
}
```
# Indexing Account Balances
Source: https://metalayerlabs.mintlify.app/building/guides/indexing-balances
# Overview
If you're building a product that indexes ETH balances on Blast, it's important that you understand how Blast's account model differs from other EVM chains.
Instead of representing ETH balances as integer values, Blast represents them in terms of **shares**. Each account has some number of shares associated with it and that number is multiplied by a **global share price** to determine its ETH balance. In this way, Blast account balances are capable of automatically rebasing as new yield is reported and the global share price increases.
For the most accurate indexing of account balances, we recommend saving individual account shares along with the global share price instead of saving account balances directly. At read time an account's balance can then be derived by multiplying its shares with the global share price.
The rest of this document describes how to accurately index every account's ETH balance on Blast using this method.
* `"0x0"`: AUTOMATIC * `"0x1"`: VOID * `"0x2"`: CLAIMABLE
- **“BLIP”** means a Blast Improvement Proposal, which is a proposal put forth by a Tokenholder to a vote by all Tokenholders in accordance with the BLIP Process.
- **“BLIP Process”** means the rules and procedures of submitting and voting on BLIPs as described in Section 5 and Section 6, as applicable, herein.
- **“Blast Network”** or **“Blast”** means the series of smart contracts that create the layer-two blockchain scaling solution known as **“Blast”** (the **“Layer-Two Network”**) and permits users to transact on the Layer-Two Network, including, but not limited to, bridge to and from Ethereum mainnet to the Layer-Two Network.
- **"Bylaws"** means these bylaws of the Foundation as may be amended from time to time in accordance with the Foundation Articles.
- **"Cayman Law"** means the rules, regulations and laws of the Cayman Islands, including as they are modified, from time to time.
- **“Foundation Articles”** means the Memorandum and Articles of Association of the Foundation (as may be amended from time to time).
- **"Foundation Director(s)"** means the director(s) of the Foundation, which have certain powers and duties pursuant to Cayman Law and as further described in the Foundation Articles.
- **"Foundation Supervisor"** means the supervisor of the Foundation, which has certain powers and duties pursuant to Cayman Law and as further described in the Foundation Articles.
- **“Moderator(s)”** means an individual(s) engaged by the Foundation to, among other things, assist with the governance processes set forth herein.
- **“Quorum Requirements”** means at least six billion (6,000,000,000) Tokens are cast in the applicable vote.
- **“Token”** means the native token governing the Blast Network, known as \$BLAST and as identified by the following smart contract address on the Blast Network: [0xb1a5700fA2358173Fe465e6eA4Ff52E36e88E2ad](https://blastscan.io/token/0xb1a5700fA2358173Fe465e6eA4Ff52E36e88E2ad).
- **“Tokenholder(s)”** means the holder(s) of the Token from time to time, or individuals who have been delegated Tokens, as evidenced by the Blast Network.
- *Phase One - Research and Community Feedback*
- Any Tokenholder who wishes to submit a BLIP (“**Tokenholder BLIP**”) to the Foundation shall first post a draft of the proposed TBLIP on POW for review by the Blast community. The draft TBLIP should be reviewed and discussed by the Blast community for a period of no less than seven (7) calendar days (the “**Community Feedback Period**”). The TBLIP shall be in the form of the BLIP Template.
- *Phase Two - Progress Council Review*
- After the expiration of the Community Feedback Period, the Tokenholder shall (1) update the draft TBLIP as necessary to incorporate community feedback and (2) post the draft TBLIP for Progress Council review via POW. The Progress Council will review Submitted TBLIPs every other Friday. TBLIPs submitted by Tokenholders who are delegated less than 2,000,000 Tokens will not be considered by the Progress Council.
- In reviewing Submitted TBLIPs, the Progress Council may (1) allow the Submitted TBLIP to progress to Phase Three; (2) direct the Tokenholder(s) who submitted the TBLIP to provide additional information or update the Submitted TBLIP; or (3) reject the Submitted TBLIP in accordance with the following paragraph. These decisions will be communicated in discussions on POW.
- The Progress Council may choose to reject the Submitted TBLIP if, in consultation with legal counsel, it is determined that the Submitted TBLIP is not safe, not secure, or not consistent with the purposes of the Foundation or may not be capable of being implemented in a legally compliant manner. For the Progress Council to successfully veto a Submitted TBLIP, a majority of the members of the Progress Council must vote in favor of the veto.
- *Phase Three - Snapshot Voting*
- After review and approval of the Submitted TBLIP by the Progress Council, the Submitted TBLIP will be added to the Foundation Snapshot, at which point the Submitted TBLIP becomes a “**Live BLIP**.”
- Once live on Snapshot, the Live BLIP will be open to voting until the voting period closes, which is seven (7) calendar days later (the “**Voting Period**”). To confirm that each Tokenholder BLIP has gone through the appropriate approval processes set forth herein, Moderators are the only persons who can post Submitted TBLIPs to the Snapshot.
- One (1) Token is equal to one (1) vote on any Live BLIP. The voting options for any Live BLIP shall be “**In favor**,” “**Against**,” and “**Abstain**.”
- Live BLIPs that (1) satisfy the Quorum Requirements and (2) receive a majority of the votes cast in favor of it shall be considered to be “**Approved Tokenholder BLIPs**.” A Live BLIP that either (i) does not meet the Quorum Requirements or (ii) meets the Quorum Requirements but fails to receive a majority of votes cast in favor of it shall be considered a “**Failed Tokenholder BLIP**”.
- Approved Tokenholder BLIPs will move to Phase 4. Failed Tokenholder BLIPs may be resubmitted for Foundation consideration only after sixty (60) days have elapsed from the date the Tokenholder BLIP was considered to be a Failed Tokenholder BLIP.
- *Phase Four - Implementation*
- Subject to Section (ii) below, Approved Tokenholder BLIPs shall be taken under advisement by the Foundation and so long as they fall within the Foundation’s power to effectuate, shall be considered for implementation by the Foundation in a commercially reasonable time and manner.
- If, following the approval of a BLIP by the Tokenholders in accordance with the BLIP Process, a majority of the Foundation Director(s) acting in the best interests of the Foundation reasonably determine(s) that such BLIP, if implemented, would:
- Compromise the Foundation Director(s’) fiduciary duties as they are owed to the Foundation.
- Be in violation of any part of these Bylaws or the Foundation Articles, the BLIP Process, any statutory requirements of Cayman Law or the laws or regulations of any other applicable jurisdiction.
- Cause the Foundation to be in breach of any contracts, agreements or any other arrangements.
- Be against the best interests of the Foundation or the Blast Network.
- *Phase One - Progress Council Review and Vote*
- Any member of the Progress Council can submit a BLIP (a “**Progress Council BLIP**”) to the other members of the Progress Council by posting in POW. The Progress Council BLIP shall be in the form of the BLIP Template.
- Within seven (7) calendar days of the Progress Council BLIP being posted, the Progress Council shall review and vote on it. A majority of the members of the Progress Council are required to vote in favor of the Progress Council BLIP for it to be approved (an “**Approved Progress Council BLIP**”).
- In the event there are less than five (5) members on the Progress Council at any time, any Progress Council BLIP shall require at least a majority of the seats then filled to vote in favor to become an Approved Progress Council BLIP. In the event there is a tie, the Progress Council BLIP may be approved by the Foundation Director(s) in which case it shall move to Phase Two, immediately below.
- *Phase Two - Tokenholder Veto*
- Within three (3) calendar days of passing an Approved Progress Council BLIP, a Moderator shall post the Approved Progress Council BLIP on the Foundation Snapshot with the “**veto**” option. If (i) the Quorum Requirements on the applicable veto vote are satisfied and (ii) more than a majority of the votes cast are in favor of vetoing the Approved Progress Council BLIP, the proposal will not be enacted. The veto period shall be seven (7) calendar days from the posting of the Approved Progress Council BLIP (the “**Veto Period**”).
- *Phase Three - Implementation*
- Subject to Section (ii) below, Approved Progress Council BLIPs that have not otherwise been vetoed during the Veto Period will be implemented by the Foundation in a commercially reasonable time and manner.
- If, following the approval of a BLIP by the Progress Council in accordance with the BLIP Process, a majority of the Foundation Director(s) acting in the best interests of the Foundation reasonably determine(s) that such BLIP, if implemented, would:
- Compromise the Foundation Director(s’) fiduciary duties as they are owed to the Foundation.
- Be in violation of any part of the Governance Documentation, the BLIP Process, any statutory requirements of Cayman Law or the laws or regulations of any other applicable jurisdiction.
- Cause the Foundation to be in breach of any contracts, agreements or any other arrangements.
- Be against the best interests of the Foundation or the Blast.
- The Progress Council (the “**Progress Council**”) is tasked with serving as a steward for the Tokenholders and for providing oversight of the Foundation on behalf of the Tokenholders.
- Initially, the Progress Council shall be made-up of five (5) seats. Those seats will initially be filled by five (5) individuals appointed by the Foundation Director(s). At all times, one (1) seat shall be filled by an individual appointed by the Foundation Director(s) to serve as a representative of the Foundation (the “**Foundation Nominee**” and the other members, the “**Tokenholder Nominees**”).
- The Blast Foundation Progress Council members are each paid \$50,000, on an annual basis. The Blast Foundation feels that this amount represents a fair fee for the time and dedication that each member is providing to the Blast Foundation and the Blast ecosystem.
- Tokenholders may vote to remove a Tokenholder Nominee through, and subject to, the BLIP Process outlined in Section 5 herein. If, at any time, one or several Tokenholder Nominee members are removed in accordance with this Section 7(d), such that a vacancy exists on the Progress Council, the Foundation Director(s) shall, acting in the best interests of the Foundation, have the authority to nominate and appoint replacement members to the Progress Council who shall serve as Tokenholder Nominees until such time as they resign or are otherwise removed by Tokenholders subject to a BLIP.
- Members of the Progress Council may resign at any time by providing written notice to the Foundation Director(s). In such an event, the remaining members of the Progress Council shall identify an individual to fill the vacant seat and then shall put forth a Progress Council BLIP (in accordance with Section 6) nominating such individual.
- If no Tokenholder BLIP is made to nominate a new Progress Council member, or to remove an existing Progress Council member, then the existing Progress Council members shall continue their service until such time as they resign or are removed or voted out by the Tokenholders pursuant to the BLIP Process.
- All members of the Progress Council will be required to pass a screening process before being added to the Progress Council. This process may include KYC/AML obligations, sanctions screening or other obligations as may be required under Cayman Law from time to time, and a requirement that the member sign a standard contract, which will be implemented at the discretion of the Foundation.
- The Safety Committee is a committee of five (5) members who appointed by the Foundation Directors and who are signers of a multi-sig wallet, which has powers to perform certain Emergency Actions as set forth herein (the “**Safety Committee**”).
- The Safety Committee has the power to (i) execute any software upgrade or perform other required actions with no delay in order to respond to a security emergency, should one arise without specific governance approvals or (ii) veto any Approved Tokenholder BLIP or Approved Progress Council BLIP (such actions, "**Emergency Actions**"). Performing any Emergency Action requires a majority approval from the Safety Committee. The Safety Committee must not use its power to perform Emergency Actions except in a true security emergency, such as a critical vulnerability.
- After performing any Emergency Action, the Safety Committee shall in reasonable time and course, depending on the facts and circumstances of the Emergency Action, including the time that has elapsed, and in reasonable consultation with Foundation’s legal counsel, issue a transparency report to explain what actions were taken and why such Emergency Action was justified.
- The Foundation Director(s), in consultation with Foundation’s legal counsel, are able to curtail or eliminate the Safety Committee’s power to perform Emergency Actions.
- The Foundation will facilitate the administration of the governance procedures described in these Bylaws with the aim of ensuring that the Tokenholders may participate thoughtfully in governance. Such administrative services may include:
- Moderation of governance proposals to ensure they are validly submitted and voted upon.
- Removal of proposals that reasonably appear to be fraudulent, spam-oriented, defamatory, hateful, or otherwise inappropriate or inconsistent with the values of the Foundation.
- Monitoring of votes, voting power, and voting periods for purposes of determining whether quorums and approval thresholds are met or accurately reflected;
- Management of mutually contradictory proposals that are submitted simultaneously or in close proximity to one another.
- Administration of network maintenance, such as emergency bug fixes or release rollbacks (with or without a governance vote).
- Such other things as the Foundation deems appropriate in connection with the above.
- Subject to applicable law, the Foundation Articles and these Bylaws, the Foundation Director(s) will take any Approved Tokenholder BLIP or Approved Progress Council BLIP under advisement and, to the extent they desire to adopt such vote, are authorized to take any actions reasonably necessary on behalf of the Foundation to give effect to an Approved Tokenholder BLIP or Approved Progress Council BLIP including passing any director resolutions to memorialize such Approved Tokenholder BLIP or Approved Progress Council BLIP; provided that any Foundation Director may veto a proposal or place such limitations on its observation and implementation a Foundation Director in its discretion, deems necessary or appropriate to:
- Ensure compliance with any applicable law or regulation of any jurisdiction.
- Ensure that the Foundation acts in accordance with the Foundation Articles and these Bylaws.
- To prevent any harm (including reputational harm) to the Foundation.
- The Tokenholders are represented by the Foundation, which represent the Tokenholders' interests in connection with contractual and legal processes, including regulatory compliance and those other matters set forth in the Foundation Articles.
- The Blast Foundation has engaged with certain third parties to provide services as the Foundation Director(s), as required by Cayman Law. In accordance with the terms of the Foundation Articles and these Bylaws, and subject to Cayman Law, the Foundation Director(s) are required to take input for the Tokenholders in respect of certain matters.
- The Tokenholders have the authority to propose certain decisions in relation to the Foundation as set forth in these Bylaws and the Foundation Articles.
- The Foundation Director(s) are authorized to take any actions reasonably necessary on behalf of the Foundation to give effect to a vote of the Tokenholders including passing any director resolutions to memorialize such vote.
- To the extent there is ever a conflict between the provisions of the Bylaws and/or the Foundation Articles, the Foundation Articles will prevail in respect to the provisions of the Bylaws.
- Should a controversy, dispute or claim arise out of or in relation to these Bylaws ("**Dispute**"), the Foundation, the Foundation Director(s), the Progress Council and/or the Foundation Supervisor (as appropriate) must give thirty (30) days' notice of such Dispute to the relevant party/ies (the "**Notice of Dispute**"). Should the Dispute not be resolved at the expiration of thirty (30) days after service of the Notice of Dispute, the relevant party may commence arbitration proceedings in accordance with Section 2(b) of these Bylaws. In any dispute involving the actions of the Foundation Director(s), the Foundation Supervisor may commence arbitration proceedings against the Foundation Director(s) in accordance with this Section 2. For the avoidance of doubt, this Section 2 does not provide Tokenholders with a right of action against the Foundation or the Foundation Director(s).
- Should the Dispute remain at the expiration of thirty (30) days after service of the Notice of Dispute, the Dispute shall be settled by arbitration administered by the International Centre for Dispute Resolution in accordance with its International Arbitration Rules (the "Rules"). The arbitration shall be seated in George Town, Grand Cayman and governed by Cayman Law. The language of the arbitration shall be English. The arbitration shall be determined by a sole arbitrator to be appointed in accordance with the Rules. Any award or decision made by the arbitrator shall be in writing and shall be final and binding on the parties without any right of appeal, and judgment upon any award thus obtained may be entered in or enforced by any court having jurisdiction thereof. No action at law or in equity based upon any claim arising out of or related to these Bylaws shall be instituted in any court of any jurisdiction.
### Community - 50,000,000,000 (50%)
Blast's success is only due to the community of users and builders that contribute to the ecosystem. 50% of the total BLAST supply is reserved for the community and will be distributed through incentive campaigns. 100% of this allocation will go directly to the community. The community allocation unlocks linearly over 3 years from the date of the TGE and any distributions will be according to schedules determined by the Blast Foundation.
### Core Contributors - 25,480,226,842 (25.5%)
All tokens distributed to core contributors are subject to a 4 year lockup period, with 25% of the core contributor tokens unlocked 1 year after the date of the TGE, followed by a linear unlock each month over the following 3 years.
### Investors - 16,519,773,158 (16.5%)
All tokens distributed to investors are subject to a 4 year lockup period, with 25% of the investor tokens unlocked 1 year after the date of the TGE, followed by a linear unlock each month over the following 3 years.
### Blast Foundation - 8,000,000,000 (8%)
The Foundation allocation will be held in reserve to be used towards critical infrastructure and further growing the Blast ecosystem. The Foundation allocation is unlocked linearly over a 4 year period from the date of the TGE.
# Phase 1 Airdrop
### Blast Points - 7,000,000,000 (7%)
Users that bridged ETH or USDB to Blast bootstrapped the initial liquidity on
the Blast ecosystem and earned Blast Points throughout Phase 1. These
users will be rewarded with 7% of the total BLAST supply.
### Blast Gold - 7,000,000,000 (7%)
Users that contributed to the success of Dapps earned Blast Gold and will be
rewarded with 7% of the total BLAST supply.
### Vesting
The top 0.1% users (\~1000 wallets) will vest part of their airdrop linearly
over 6 months. Vesting is subject to reaching a monthly Points threshold
based on Phase 1 activity. Further details will be available on June 26.
### Blur Foundation - 3,000,000,000 (3%)
The Blur Foundation will receive 3% of the total BLAST supply to distribute to
the Blur community for both retroactive and future airdrops.
# Phase 2 Airdrop
Phase 2 was originally scheduled to end in June 2025, running for 12 months with an allocation of 10 billion BLAST. However, with the release of Blast Mobile, we are transitioning to new tokenomics that allow users and dApps to earn liquid BLAST rewards directly, rather than through points and Gold.
As part of this transition, Phase 2 will now conclude in January 2025 with a prorated allocation of 5 billion BLAST.
### Blast Points - 2,500,000,000 (2.5%)
Users that helped to maintain liquidity across the blast ecosystem by bridging and holding balances of ETH, USDB, and/or BLAST earned Blast Points throughout Phase 2. These
users will be rewarded with 2.5% of the total BLAST supply.
### Blast Gold - 2,500,000,000 (2.5%)
Users that contributed to the success of Dapps earned Blast Gold and will be
rewarded with 2.5% of the total BLAST supply.
# Analytics
Source: https://metalayerlabs.mintlify.app/tools/analytics
## Arkham
[Arkham](https://platform.arkhamintelligence.com/) is a public blockchain intelligence platform accessible via url that provides data on the entities and individuals behind crypto market activity by using AI to identify the owners of blockchain addresses. Features include a searchable database of onchain profiles, visualizer, tracer, alerts, custom dashboards, and an API.
**Supported Networks**
* Blast Mainnet
***
## Dune
[Dune](https://dune.com) is a blockchain analytics platform for querying, visualizing, and sharing on-chain data. It enables users to create custom dashboards and analyses using SQL-based queries.
**Supported Networks**
* Blast Mainnet
***
## Flipside Crypto
[Flipside Crypto](https://flipsidecrypto.xyz/) is an analytics provider that is similar to Dune, but typically faster for running complicated queries.
**Supported Networks**
* Blast Mainnet
# Block Explorers
Source: https://metalayerlabs.mintlify.app/tools/block-explorers
## Blastscan (Etherscan)
| Network | URL |
| ----------- | -------------------------------------------------------------- |
| **Mainnet** | [https://blastscan.io/](https://blastscan.io/) |
| **Testnet** | [https://sepolia.blastscan.io/](https://sepolia.blastscan.io/) |
## Blastexplorer (Routescan)
| Network | URL |
| ----------- | -------------------------------------------------------------------- |
| **Mainnet** | [https://blastexplorer.io](https://blastexplorer.io) |
| **Testnet** | [https://sepolia.blastexplorer.io](https://sepolia.blastexplorer.io) |
## Parsec
| Network | URL |
| ----------- | -------------------------------------------------------- |
| **Mainnet** | [https://voyager.parsec.fi/](https://voyager.parsec.fi/) |
## DexGuru
| Network | URL |
| ----------- | ------------------------------------------------------------ |
| **Mainnet** | [https://blast.dex.guru/](https://blast.dex.guru/) |
| **Testnet** | [https://blast-test.dex.guru/](https://blast-test.dex.guru/) |
## Blockscout
| Network | URL |
| ----------- | -------------------------------------------------------------- |
| **Mainnet** | [https://blast.blockscout.com/](https://blast.blockscout.com/) |
## Arkham
| Network | URL |
| ----------- | ------------------------------------------------------------------------------------ |
| **Mainnet** | [https://platform.arkhamintelligence.com/](https://platform.arkhamintelligence.com/) |
# Data Indexers
Source: https://metalayerlabs.mintlify.app/tools/data-indexers
## GhostGraph
[GhostGraph](https://GhostGraph.xyz/) makes it easy to build blazingly fast indexers (subgraphs) for smart contracts.
GhostGraph is the first indexing solution that lets you write your index transformations in **Solidity**. Blast dApps can query data with GraphQL using our hosted endpoints.
To get started, you can [sign up for an account](https://app.ghostlogs.xyz/ghostgraph/sign-up) and follow [this quickstart](https://docs.ghostlogs.xyz/category/-getting-started-1) guide on how to create, deploy, and query a GhostGraph.
**Supported Networks**
* Blast Mainnet
***
## Goldsky
Goldsky offers high-performance subgraphs and realtime data replication pipelines, making Blast data accessible to developers via hosted API endpoints, or directly within your own infrastructure.
Blast subgraphs deployed to Goldsky can also be replicated directly into [internal datastores](https://docs.goldsky.com/mirror/sinks/supported-sinks) via Goldsky Mirror, enabling alternative access patterns to the data, and for it to be joined seamlessly with other application/user data.
For instructions on deploying subgraphs to Goldsky, visit Goldsky's dedicated indexing [quickstart page](https://docs.goldsky.com/chains/blast) for Blast.
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
***
## The Graph
[The Graph](https://thegraph.com/) is an indexing protocol for organizing blockchain data and making it easily accessible with GraphQL.
Blast dapps can use GraphQL to query open APIs called subgraphs, to retrieve data that is indexed on the network.
Learn how to use The Graph via their [documentation](https://thegraph.com/docs/en/) or [this quickstart](https://thegraph.com/docs/en/cookbook/quick-start/).
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
***
## SQD
[SQD](https://www.sqd.dev/) is a decentralized hyper-scalable data platform optimized for providing efficient, permissionless access to large volumes of data. It currently serves historical on-chain data, including event logs, transaction receipts, traces, and per-transaction state diffs. SQD offers a powerful toolkit for creating custom data extraction and processing pipelines, achieving an indexing speed of up to 150k blocks per second.
Comment
Edit from here
To get started, visit their [documentation](https://docs.sqd.dev/) or see their [EVM examples](https://github.com/subsquid-labs/squid-evm-examples) of what you can build with SQD.
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
***
## SubQuery
SubQuery provides developers with fast, flexible, universal, open source and decentralised APIs for web3 projects. One of SubQuery's competitive advantages is the ability to aggregate data not only within a chain but across multiple blockchains all within a single project.
Learn how to use SubQuery via their [documentation](https://academy.subquery.network/) or this [quickstart guide](https://academy.subquery.network/indexer/quickstart/quickstart.html).
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
# null
Source: https://metalayerlabs.mintlify.app/tools/faucets
## Blast Sepolia Faucets
### Quicknode
[QuickNode Blast Faucet](https://faucet.quicknode.com/blast/sepolia) is an easy to use Multi-Chain Faucet that drips Blast Sepolia ETH.
### Blast API (No Affiliation to Blast L2)
[Blast API Blast Faucet](https://blastapi.io/faucets/blastl2-testnet) is an easy to use faucet with no registration required that you can use to claim Blast Sepolia ETH for free.
## Ethereum Sepolia Faucets
### Quicknode
[QuickNode Ethereum Faucet](https://faucet.quicknode.com/ethereum/sepolia) is an easy to use Multi-Chain Faucet that drips Ethereum Sepolia ETH.
### Blast API (No Affiliation to Blast L2)
[Blast API Ethereum Faucet](https://blastapi.io/faucets/ethereum-sepolia) is an easy to use faucet with no registration required that you can use to claim Sepolia ETH for free.
## Bridging Sepolia ETH to Blast Sepolia
Once you've acquired some Sepolia ETH, you can transfer it to use on Blast Sepolia by sending it to the Blast L1StandardBridge as demonstrated [here](https://sepolia.etherscan.io/tx/0x756d57214b500dedf5e5f9d5baaf9738f59f3492e242185bd51f31ae12b5573b).
# Governance
Source: https://metalayerlabs.mintlify.app/tools/governance
## Tally
[Tally](https://docs.tally.xyz/) is a DAO launch and operations platform. DAOs use Tally to share control over protocols, treasuries and public goods.
# Misc Tools
Source: https://metalayerlabs.mintlify.app/tools/misc
## Biconomy
[Biconomy](https://docs.biconomy.io/) is an Account Abstraction toolkit that enables Blast developers to provide the simplest UX for dapps or wallets. It offers modular smart accounts, as well as paymasters and bundlers as a service for sponsoring gas and executing transactions at scale.
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
***
## Gelato
Gelato provides Blast developers with native integrations with Gelato’s industry-leading Web3 middleware services including VRF, Account Abstraction, Web3 functions, and Relay to enable superior UX. Learn more [here](https://docs.gelato.network/).
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
***
## Tenderly
[Tenderly](https://tenderly.co/) is a full-stack Web3 development platform featuring RPC services, smart contract debugging, simulations, monitoring, alerting, and analytics.
**Supported Networks**
* Blast Mainnet
# Node Providers
Source: https://metalayerlabs.mintlify.app/tools/node-providers
## Quicknode
[Quicknode](https://quicknode.com) provides public and private rpc endpoints for Blast, along with websocket support.
**Supported Networks**
* Blast Mainnet - Public RPC: [https://rpc.blast.io](https://rpc.blast.io)
* Blast Sepolia - Public RPC: [https://sepolia.blast.io](https://sepolia.blast.io)
***
## Infura
[Infura](https://infura.io) provides public and private rpc endpoints for Blast.
**Supported Networks**
* Blast Mainnet - Public RPC: [https://blast.din.dev/rpc](https://blast.din.dev/rpc)
* Blast Sepolia - Public RPC: [https://testnet.blast.din.dev/rpc](https://testnet.blast.din.dev/rpc)
***
## Blast API (no affiliation to Blast L2)
[Blast API](https://blastapi.io) provides public and private rpc endpoints for Blast.
**Supported Networks**
* Blast Mainnet - Public RPC: [https://blastl2-mainnet.public.blastapi.io](https://blastl2-mainnet.public.blastapi.io)
* Blast Sepolia - Public RPC: [https://blastl2-sepolia.public.blastapi.io](https://blastl2-sepolia.public.blastapi.io)
***
## How to run your own nodes
If you want to self host Blast nodes, then you can follow the guide here which uses docker compose for a painless setup process: [https://github.com/blast-io/deployment](https://github.com/blast-io/deployment)
The above repo also links to more advanced documentation if you have custom deployment needs that require building the Blast software from source.
# null
Source: https://metalayerlabs.mintlify.app/tools/oracles
## API3
The [API3 Market](https://market.api3.org/blast) provides access to 200+ price feeds on [Blast Mainnet](https://market.api3.org/blast) and [Testnet](https://market.api3.org/blast-sepolia-testnet). The price feeds operate as a native push oracle and can be activated instantly via the Market UI.
The price feeds are delivered by an aggregate of [first-party oracles](https://docs.api3.org/explore/airnode/why-first-party-oracles.html) using signed data and support [OEV recapture](https://docs.api3.org/explore/introduction/oracle-extractable-value.html).
API3 also offers on-chain randomness on Blast via their [QRNG](https://docs.api3.org/guides/qrng/).
**Supported networks**
* Blast Mainnet
* Blast Sepolia
***
## Pyth
[Pyth Network](https://www.pyth.network/) offers price feeds and randomness on Blast.
Pyth provides real-time price data sourced directly from [first part data providers](https://www.pyth.network/publishers).
It introduces a [pull](https://docs.pyth.network/price-feeds/pull-updates) mechanism where any developer can permissionless consume prices ever 400 ms, making Pyth fast on-chain oracle.
A developer can consume consume [these prices](https://www.pyth.network/developers/price-feed-ids) on Blast network in just 3 lines of solidity code. Checkout our price feed guide [here](https://docs.pyth.network/price-feeds/use-real-time-data/evm).
Check our Entropy [guide](https://docs.pyth.network/entropy/generate-random-numbers/evm) here to get pure random numbers on Blast.
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
***
## Redstone
Redstone offers push-based price feeds for Blast.
Learn how to use Redstone feeds with [this guide](https://docs.redstone.finance/docs/introduction).
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
***
## Supra
Supra provides decentralized oracle price feeds for Blast. Learn how to use Supra price feeds [here](https://supra.com/docs/readme/).
Supra also offers on-chain randomness on Blast via their [distributed Verifiable Random Function (dVRF)](https://supra.com/docs/vrf) solution.
**Supported networks**
* Blast Mainnet
* Blast Sepolia
# Safes
Source: https://metalayerlabs.mintlify.app/tools/safes
## Protofire
Protofire has deployed and maintained Gnosis Safe infrastructure across numerous L2 networks, including zkSync, zkScroll, Mantle, Linea, and others.
You can create new safes on Blast or import existing Blast safes at [https://app.safe.protofire.io/](https://app.safe.protofire.io/). Be sure to check out the Blast Yield safe app for easy monitoring and management of Blast's native yield.
**Supported Networks**
* Blast Mainnet
* Blast Sepolia
# Using Blast
Source: https://metalayerlabs.mintlify.app/using-blast
## Mainnet
Blast Mainnet can be added as a custom network to any EVM-compatible wallet (i.e. [MetaMask](https://metamask.io)).
### Public RPC Endpoints
1. [https://rpc.blast.io](https://rpc.blast.io)
2. [https://blastl2-mainnet.public.blastapi.io](https://blastl2-mainnet.public.blastapi.io)
3. [https://blast.din.dev/rpc](https://blast.din.dev/rpc)
4. [https://blast.blockpi.network/v1/rpc/public](https://blastl2-mainnet.public.blastapi.io)
### MetaMask Quick Instructions
To add Blast Mainnet as a custom network to MetaMask:
1. Go to the Blast Explorer at [blastscan.io](https://blastscan.io).
2. Scroll to the bottom and click the **Add Blast Mainnet** button in the footer.
3. Approve adding the network in the MetaMask prompt that opens.
### MetaMask Manual Instructions
To add Blast Mainnet as a custom network to MetaMask:
1. Open the MetaMask browser extension.
2. Open the network selection dropdown menu by clicking the dropdown button at the top of the extension.
3. Click the **Add network** button.
4. Click **Add a network manually**.
5. In the **Add a network manually** dialog that appears, enter the following information for Blast Mainnet.
Network Name: **Blast**
RPC Endpoint: [https://rpc.blast.io](https://rpc.blast.io)
Chain ID: **81457**
Currency Symbol: **ETH**
Block Explorer: [https://blastscan.io](https://blastscan.io)
6. Tap the Save button to save Blast Mainnet as a network.
You should now be able to connect to the Blast Mainnet by selecting it from the network
## Testnet
Blast Sepolia can be added as a custom network to any EVM-compatible wallet (i.e. [MetaMask](https://metamask.io)).
### MetaMask Quick Instructions
To add Blast Sepolia as a custom network to MetaMask:
1. Go to the Blast Testnet Explorer at [sepolia.blastexplorer.io](https://sepolia.blastexplorer.io).
2. Scroll to the bottom and click the **Add Blast Testnet Sepolia Network** button in the footer.
3. Approve adding the network in the MetaMask prompt that opens.
### MetaMask Manual Instructions
To add Blast Sepolia as a custom network to MetaMask:
1. Open the MetaMask browser extension.
2. Open the network selection dropdown menu by clicking the dropdown button at the top of the extension.
3. Click the **Add network** button.
4. Click **Add a network manually**.
5. In the Add a network manually dialog that appears, enter the following information for the Blast Sepolia testnet.
Network Name: **Blast Sepolia**
RPC Endpoint: [https://sepolia.blast.io](https://sepolia.blast.io)
Chain ID: **168587773**
Currency Symbol: **ETH**
Block Explorer: [https://sepolia.blastexplorer.io](https://sepolia.blastexplorer.io)
6. Tap the Save button to save Blast Sepolia as a network.
You should now be able to connect to the Blast testnet by selecting it from the network selection dropdown menu.