​

Bylaws

​

1. Bylaws Adopted

These bylaws are adopted on the June 25, 2024 (the “Effective Date” pursuant to a directors’ resolution by the directors of the Blast Foundation (the “Foundation”) in accordance with the Foundation Articles. Capitalized terms used but not otherwise defined herein shall have the meanings ascribed to such terms in the Foundation Articles.

​

2. Governance Tools

Tokenholders have certain tools at their disposal to encourage the proposal, discussion, and participation in the Blast Network and Foundation governance. The following are the governance tools available to Tokenholders and other Blast Network participants at the time of the adoption of these Bylaws. Note that these governance tools may change over time as Blast Network and Foundation governance evolves, and any such updates will be communicated through the Foundation’s publicly available social media channels:

• Blast Foundation Discourse available at https://forum.blast.io/ (the “Foundation Discourse”) allows the Blast community to review and discuss governance proposals.

• Blast Foundation Proposal Template provides Tokenholders with a template to craft governance proposals in accordance with these Bylaws (the “BLIP Template”).

• Blast Foundation Snapshot available at https://snapshot.org/#/blastfoundation.eth (the “Foundation Snapshot”) allows Tokenholders to vote on governance proposals.

​

3. Definitions

1. “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.
2. “BLIP Process” means the rules and procedures of submitting and voting on BLIPs as described in Section 5 and Section 6, as applicable, herein.
3. “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.
4. “Bylaws” means these bylaws of the Foundation as may be amended from time to time in accordance with the Foundation Articles.
5. “Cayman Law” means the rules, regulations and laws of the Cayman Islands, including as they are modified, from time to time.
6. “Foundation Articles” means the Memorandum and Articles of Association of the Foundation (as may be amended from time to time).
7. “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.
8. “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.
9. “Moderator(s)” means an individual(s) engaged by the Foundation to, among other things, assist with the governance processes set forth herein.
10. “Quorum Requirements” means at least six billion (6,000,000,000) Tokens are cast in the applicable vote.
11. “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.
12. “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.

​

4. Tokenholder BLIP Categories

Pursuant to these Bylaws, Tokenholders may propose, and vote on BLIPs subject to, and in accordance with, the BLIP Process to:

• Make adjustments to the following parameters of the Blast Network:

  • General risk management frameworks.
  • USDB-backing composition.
  • ETH liquid staking providers.
  • Fees on ETH yield.
  • Fees on USDB yield.
  • Gas fee accrual.
  • Creation of a reserve fund.
  • Yield distribution allocation between ETH, USDB and the reserve fund.

• Appoint and remove members of the Progress Council.

• Increase the number of members of the Progress Council.

• Make changes to the inflation adjustment, provided however, that no such changes shall take effect on the date prior to the date that is four (4) years from the date of the public launch of the Token.

• Consent to any proposed changes to the Foundation’s Articles which only to the extent that such proposed changes adversely affect in a material way the rights or powers conferred on the Tokenholders under the Foundation’s Articles.

• Consent to any proposed changes to these Bylaws only to the extent that such proposed changes which adversely affect in a material way the rights or powers conferred on the Tokenholders under these Bylaws.

• Approve any other action in accordance with successful BLIPs.

The results of any Tokenholder votes and the approval of any BLIPs shall be taken under advisement by the Foundation so long as they fall within the Foundation’s power to effectuate the same, provided that the Foundation shall not be obligated to effectuate the results of the same. Tokenholders are encouraged to submit proposals, send and seek feedback, and fine-tune proposals prior to ultimate submission in accordance with the requirements and procedures described in Section 6 herein.

​

5. Tokenholder BLIPs

Any Tokenholder who wishes to submit a BLIP for Foundation consideration is required to comply with the following:

1. Phase One - Research and Community Feedback
1. Any Tokenholder who wishes to submit a BLIP (“Tokenholder BLIP”) to the Foundation shall first submit a draft of the proposed TBLIP to the Research and Discussion Forum in the Foundation Discourse 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.
2. Phase Two - Progress Council Review
1. After the expiration of the Community Feedback Period, the Tokenholder shall (1) update the draft TBLIP as necessary to incorporate community feedback and (2) submit the draft TBLIP for Progress Council review via the BLIP Submission Forum in the Foundation Discourse (the “Submitted TBLIP”). 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 and any such Submitted TBLIP will be removed from the Foundation Discourse by a Moderator.
2. 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 communicated in the Progress Council Forum on the Foundation Discourse.
3. 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.
3. Phase Three - Snapshot Voting
1. After review and approval of the Submitted TBLIP by the Progress Council, a Moderator will (1) move the Submitted TBLIP to the Voting Forum in the Foundation Discourse and (2) add the Submitted TBLIP to the Foundation Snapshot, at which point the Submitted TBLIP becomes a “Live BLIP.”
2. 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.
3. 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.”
4. 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”.
5. 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.
4. Phase Four - Implementation
1. 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.
2. 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:
1. Compromise the Foundation Director(s’) fiduciary duties as they are owed to the Foundation.
2. 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.
3. Cause the Foundation to be in breach of any contracts, agreements or any other arrangements.
4. Be against the best interests of the Foundation or the Blast Network.

Such Foundation Director(s) may direct the Progress Council to take such other steps as are required to amend, augment, reject or remediate the enactment of such BLIP.

​

6. Progress Council BLIPs

Any member of the Progress Council who wishes to submit a BLIP for Foundation consideration shall comply with the following:

1. Phase One - Progress Council Review and Vote
1. 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 the Progress Council Forum in the Foundation Discourse. The Progress Council BLIP shall be in the form of the BLIP Template.
2. Within seven (7) calendar days of the Progress Council BLIP being posted on the Foundation Discourse, 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”).
3. 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.
2. Phase Two - Tokenholder Veto
1. 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”).
3. Phase Three - Implementation
1. 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.
2. 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:
1. Compromise the Foundation Director(s’) fiduciary duties as they are owed to the Foundation.
2. 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.
3. Cause the Foundation to be in breach of any contracts, agreements or any other arrangements.
4. Be against the best interests of the Foundation or the Blast.

Such Foundation Director(s) may take such other steps as are required to amend, augment, reject or remediate the enactment of such BLIP.

​

7. Progress Council

1. 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.
2. 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”).
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

​

8. Safety Committee

1. 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”).
2. 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.
3. 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.
4. 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.

​

9. Governance Administration

1. 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:
1. Moderation of governance proposals to ensure they are validly submitted and voted upon.
2. Removal of proposals that reasonably appear to be fraudulent, spam-oriented, defamatory, hateful, or otherwise inappropriate or inconsistent with the values of the Foundation.
3. Monitoring of votes, voting power, and voting periods for purposes of determining whether quorums and approval thresholds are met or accurately reflected;
4. Management of mutually contradictory proposals that are submitted simultaneously or in close proximity to one another.
5. Administration of network maintenance, such as emergency bug fixes or release rollbacks (with or without a governance vote).
6. Such other things as the Foundation deems appropriate in connection with the above.
2. 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:
1. Ensure compliance with any applicable law or regulation of any jurisdiction.
2. Ensure that the Foundation acts in accordance with the Foundation Articles and these Bylaws.
3. To prevent any harm (including reputational harm) to the Foundation.

​

10. Blast Foundation & Contributors

1. 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.
2. 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.
3. The Tokenholders have the authority to propose certain decisions in relation to the Foundation as set forth in these Bylaws and the Foundation Articles.
4. 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.
5. 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.

​

11. Dispute Resolution

1. 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).
2. 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.

​

BLIP Template

​

Additional Guidelines

​

True and Complete

By submitting a BLIP, you represent and warrant to the Progress Council and the Blast Foundation that all the information it contains is true and complete to the best of your knowledge.

​

Prior Proposals

Sometimes, BLIPs aren’t passed on their initial submissions. If a BLIP is not passed, the proposer may resubmit the BLIP after sixty (60) days and should address the concerns of the community. The proposer should include the following additional sections in the resubmitted BLIP:

• A link to the previous BLIP - The link to the previous BLIP should be included in the resubmitted BLIP.
• Reasons why the BLIP was not passed - The reasons why the BLIP was not passed should be included in the resubmitted BLIP.
• Changes made to the BLIP - The changes made to the BLIP should be included to address the concerns raised during the previous BLIP submission.
• Additional information - More detailed intentions, specifics and implication details can help the community understand the revised BLIP, increasing the chances of it being passed.

​

Code Changes

Proposals that require code changes should include the code that will be executed when the proposal is passed. This code should handle the data structures, logic, executable data, and execution of the proposal. All code changes should include audit reports.