Skip to main content

The Arrow Constitution

The foundational document governing Arrow DAO — ratified June 2024.

Arrow's Constitution was ratified by a DAO-wide Snapshot vote on June 27, 2024. It is the foundational governance document for Arrow DAO — covering vision, organizational structure, decision-making, conflict resolution, and distributed authority.

note

Some sections reference "Pods," the pre-2025 organizational structure. The Projects Framework introduced in AIP-006 updated how Arrow organizes contributor work. Where there is a conflict between this Constitution and a subsequently passed AIP, the AIP takes precedence.

Article 1: Vision, Mission and Value of The DAO

1.1 Vision​

Arrow's vision is to create a world where human freedom and connectivity are greatly increased through easy and ubiquitous air travel. We imagine a future where air travel powered by electric vertical takeoff and landing aircraft (eVTOLs) is affordable and accessible to all. Arrow wants to break down the barriers of geography and enable people to move easily across the globe. We believe that this infrastructure is a critical public good for humanity and that it should be built and shared by the people who create it.

1.2 Mission​

Our mission is to build and scale an aerial manufacturing network that is accessible to as many people as possible. At Arrow, we believe that the best way to build massive infrastructure like this is to call upon the global community to come and build it together, keeping everything open-source to the public and shared using fair and decentralized governance.

1.3 On-chain and decentralized governance​

The DAO aims to establish on-chain governance for transparent and fair decision voting, and asset accumulation and distribution. Instead of having a third party to authenticate and authorize actions and proposals from members, the DAO aims to automate appropriate processes with web3 technologies, in order for all participants of the DAO to operate freely and in a decentralized and autonomous manner.

Votes and proposals are decided via Snapshot voting. See Article 4 for more details.

1.4 Community owned​

The roadmap of Arrow DAO will be paved by its community. The DAO will act as a central hub with a broad mission statement that gives a direction which gathers and attracts a global network of participants, resources, and ideas.

The DAO will be owned and governed by the people building and using it.

The DAO aims to encourage members to connect and collaborate on projects that fit into the general mission of the DAO, while providing its members with guidance, legal, financial and human resources, and all other necessary tools to actualize their visions.

In the long term, the DAO will function as a hub for enabling vertiport operators, aircraft operators, and eVTOL infrastructure partners to connect, build, and participate in governance on the Arrow network.

1.5 Roadmap​

This roadmap outlines the key steps that need to be taken to develop and deploy eVTOL technology, from tokenomics and education to building aircraft and launching commercial operations. It is important to note that this is a high-level roadmap and it can be adjusted and modified as necessary, based on the progress and feedback from the community.

  • Tokenomics — Develop and launch a token for the eVTOL DAO, used for governance, fundraising, and incentivizing community engagement.
  • Education — Develop educational resources and programs to inform the community about eVTOL technology and the benefits of decentralized autonomous organizations.
  • Building an ultralight — Develop and test a prototype of an ultralight eVTOL aircraft as a proof of concept.
  • Vertiports — Develop and deploy a network of vertiports to support the eVTOL aircraft, including infrastructure design, construction, and partnerships with existing operators.
  • Building a fleet — Develop and build a fleet of eVTOL aircraft for commercial use.
  • Certification and regulatory compliance — Obtain necessary certifications and approvals from relevant aviation authorities.
  • Launch commercial operations — Launch commercial operations of eVTOL aircraft for rideshare and cargo services.

1.6 Projects we want to support​

Arrow DAO will seek to collaborate, fund, advise, and support partners that will help extend the reach of the Arrow network, as well as contributing towards humanitarian needs in vulnerable regions. Such partners and projects include:

  • NGOs
  • Vertiport construction
  • Open-source designs
  • Supporting infrastructure (battery, solar, and charging technologies)
  • Community workshops
  • Air traffic control training for vertiports
  • Community-owned workshops for building and maintenance of aircraft

Article 2: Rules of Cooperation

The Rules of Cooperation covers two general areas:

  1. Transparency in measuring and reporting the progress of the DAO and its Pods.
  2. Creating relational agreements between members — agreements about how people will relate to each other while working together.

2.1 Transparency in measuring and reporting progress​

2.1.1 Arrow DAO roadmap​

The Growth/Ops Pod will maintain a roadmap of the DAO's current and upcoming projects, expected action items, and tentative completion dates. All members will have transparent access to this information.

2.1.2 Pod roadmaps​

Each Pod will keep a roadmap of the Pod's current and upcoming projects, expected action items, and tentative completion dates. All members will have transparent access to non-private information on Pod projects. Each Pod will be responsible for maintaining a budget to meet the goals and milestones of its roadmap.

2.1.3 Priorities​

Both Arrow DAO and each Pod will have an explanation of their overall priorities. Projects on the roadmap will be ranked by priority.

What is measured in updates — Information in updates may include: current and upcoming projects, expected action items, metrics, tentative completion dates, next actions, relative priorities, projections, efficiency, budget consumption, and engagement.

How often the roadmap is updated — Both the DAO roadmap and Pod roadmaps will be updated every two-month cycle.

2.1.4 Requests for clarification​

Any member may request clarification on a project using the Pods' public Discord channels.

  • Clarification on progress — Next steps on a current project, priority questions, accountability questions, or how a project impacts the DAO.
  • Clarification on other issues — A formal discussion with one Pod to address an issue specifically impacting that Pod.
  • Request for cooperation between Pods — A formal discussion between two or more Pods to determine whether projects are interoperating correctly.
  • Refusal to cooperate — A Pod may not ignore a properly submitted clarification request. The Growth/Ops Pod may request a meeting with the Pod in question.

2.2 Relational agreements​

2.2.1 Relational agreement​

A relational agreement is the expected behavior between two or more members and is the prerequisite to any collaborative work, whether in a Pod or between Pods. Its purpose is to establish effective relationships between all members of Arrow DAO.

  • Personal commitment — An important element of group work is knowing that other members of a project are committed. See the Arrow Compensation Framework for details on commitment levels.
  • Expectations of a project facilitator — Prior to any project, there will be a private meeting between the Pod and the project facilitator to discuss mutual expectations.
  • Expectations of project participants — Prior to any project, there will be a private meeting between the project facilitator and the participants to discuss mutual expectations.
  • Expectations meeting — At any time, a Pod member engaged in a project may request a facilitated discussion to address expectations or concerns.
  • Coordinape participation — All contributors are encouraged to reward contributors based on peer-reviewed performance.

Article 3: Organizational Structure

3.1 The composition of Arrow DAO​

Arrow DAO includes contributors who are actively working on projects within Arrow, as well as members not actively contributing.

  • Arrow members are those who possess Arrow governance tokens.
  • Pod members are contributors who join and participate in a Pod following the Arrow DAO onboarding process.

3.2 Stakeholders of Arrow DAO​

Anyone receiving and holding $ARROW tokens is a stakeholder of Arrow DAO.

3.3 Definition of Pods​

Pods are groups of members who work together on a specific mandate, based on the Pod Proposal when the Pod is established.

3.4 Pod creation​

Pods are created via an initial proposal and a subsequent vote (see Article 4). Once initiated, a Pod shall establish its own multisig, Discord category, and Google Drive folder, and outline basic onboarding procedures.

3.5 Joining a Pod​

To join a Pod, a member must complete the specific onboarding procedures for that Pod. See the Hiring Process Guidelines for full onboarding details.

3.6 Pod operations​

Pod operations include making proposals, carrying out approved tasks (see Article 4), and creating and completing bounties with respect to the Pod's objective.

Article 4: Governance

Introduction​

The overall purpose of a Governance Process is to ensure fairness and equitable treatment in matters relating to the governance of Arrow DAO, its members, Pods, and any related Sub-DAOs. All members in good standing should be fairly represented and allowed to make use of proposals, to vote, and to have recourse to conflict resolution.

While this document begins with certain concepts of governance, it is hoped that over time the Arrow DAO community can change the existing dynamics of power and experiment with forms of governance, including amendments to this Charter.

4.1 Decisions taken at the DAO level​

The Arrow DAO treasury is secured by a 3-of-5 multisig. Participation in the multisig is decided by a Snapshot vote. The multisig signers shall execute the actions required by DAO-level Snapshot votes, and shall not take actions without a prior Snapshot vote. Multisig membership is reviewed quarterly and ratified by Snapshot vote.

The DAO has the authority to:

  • Veto any decision made by any Pod.
  • Amend the Arrow DAO Constitution, Operating Agreement, Charter, or other DAO-level documents.
  • Make decisions involving forming, restructuring, or terminating a Pod.
  • Make decisions involving the multisig signers or treasuries/wallets.

All members have the right to vote at the DAO level.

4.2 Formation of Pods​

4.2.1 How to form a Pod​

To form a Pod, at least one member must create a Pod Proposal using the Pod Formation Template, with at least two initial members. The proposal must include: the need for the Pod, scope, mission and values, proposed Pod Facilitator, near-term roadmap, requested budget, multisig holders, and quorum for Pod voting. Pod roadmaps, budgets, and facilitators are voted on every two-month cycle via Snapshot.

Pod Facilitator — When a Pod is proposed, it must nominate initial Pod Facilitators, with a minimum of one.

Budget — The Pod proposal must reference a spreadsheet with line items and amounts. The budget is reviewed every two-month commitment cycle.

Quorum for Pod voting — Each Pod will set its own quorum (minimum of 3) in its proposal. This is the number of Pod members required for a Pod Improvement Proposal (PIP) to be valid.

Near-term roadmap — The Pod Proposal must contain key activities planned for the next 2 months, described in SMART terms.

DAO approval — Pod proposals shall be posted as AIPs and voted on by the DAO if a budget is requested.

Pod Improvement Proposals (PIPs) — Pod proposals are discussed internally and voted on by Pod members via Snapshot. Members outside the Pod may not vote on PIPs.

Vote of no confidence — Any Pod member may initiate a vote of no confidence in a Pod Facilitator by providing documented reasons of negligence or underperformance. This vote requires a supermajority of 75%. If passed, the Co-Facilitator will immediately take over as Interim Pod Facilitator.

Anonymity — A Pod member who wants to maintain anonymity when initiating a vote of no confidence may call on the Growth and Ops Pod to initiate it on their behalf.

4.2.2 Censure of a Pod​

If a Pod refuses to comply with the terms of this Constitution, it may be prevented from proposing any AIPs on the Arrow DAO forum or on Snapshot. If it chooses to comply, this sanction may be lifted.

4.2.3 How to terminate a Pod​

Any Pod member may initiate a vote to terminate their Pod by providing documented reasons. This termination vote must pass at both the Pod and DAO levels. If a Pod chooses to disband of its own volition, no DAO-level vote is required. Any funds in the Pod treasury will be returned to the main Arrow DAO treasury.

4.2.4 Protection of sensitive information​

If any sensitive or confidential information is held by a Pod that seeks to disband, provisions must be made for its protection.

4.2.5 Initial Pods​

Upon ratification of this Charter, the following Pods continue to operate:

  • Engineering Pod
  • Growth/Operations Pod

4.3 Arrow DAO Improvement Proposals (AIPs) and Pod Improvement Proposals (PIPs)​

4.3.1 Legitimate contractual obligations​

No AIP shall cause the DAO to be in breach of any legitimate contractual or regulatory obligation, including payment obligations such as taxes, utilities, or retainer of General Counsel.

4.3.2 Requests for disbursement of funds​

All AIPs and PIPs that ask for disbursement of funds must clearly state:

  • How the project is financially profitable for Arrow DAO, if at all
  • How the project has high utility (non-financial value) for Arrow DAO, if at all
  • How the project is ethical and fits into Arrow DAO's mission
  • A budget following the approved budget template

4.3.3 DAO-level vote​

All AIPs are voted on at the DAO level. Any member has the option to vote. Members are not required to participate.

4.3.4 Creation of AIPs​

AIPs may originate from any stakeholder with 15,000 $ARROW tokens.

Step 1 — Discord to Forum: Any individual with 15,000 $ARROW can post an AIP on the Forum. The commenting period lasts one week.

Step 2 — Forum to Snapshot: To move from the Forum to Snapshot, the AIP must receive the required number of likes within the specified timeframe.

Step 3 — Snapshot vote: The vote occurs on Snapshot and lasts one week. The vote is announced in the Discord Announcement Channel within 24 hours of going live.

Stamps of approval: Any Pod may provide a "Stamp of Approval" demonstrating support for an AIP, voted on and passed by the Pod.

Quorum: Quorum for AIPs is determined by the monetary threshold of the proposal:

  • Less than $10,000: 250 members
  • $10,000 to $20,000: 500 members

Who can vote: Anyone who holds a valid membership NFT may vote — one vote per membership NFT. The DAO reserves the right to restrict voting for specific memberships in cases of bad-faith participation.

Passing vote: Once quorum is met, a vote of 51% or greater in favor passes the AIP. A supermajority is defined as ⅔ (66%). If the AIP passes, it will be implemented by the DAO, subject to any objections.

Re-submission: If an AIP does not pass, there is a one-month cool-down period before a substantially similar AIP may be re-submitted.

4.4 The objection process for AIPs​

After an AIP passes, any member may object, regardless of whether they are in the proposing Pod.

  • Method — Objections are submitted as AIPs.
  • Objection quorum — A quorum of 20% of the Pod's membership is required to move an objection from the Pod to the DAO level.
  • Time limit — Members have 48 hours after an AIP passes to initiate an objection.
  • Pod actions — The Pod may not begin actions related to the AIP until after the objection time limit has passed. If an objection reaches quorum, the AIP is put on hold for an additional 48 hours (96 hours total).

4.5 Conflict resolution​

4.5.1 Conflict resolution​

This document does not prescribe specific methods of conflict resolution, but indicates who is responsible for facilitating resolution.

  • Conflicts between Pods — Facilitated by the Growth/Ops Pod, documented publicly in the Growth/Ops Pod public channel.
  • Conflicts within Pods — Facilitated by the Pod Facilitator. The Pod must maintain an ongoing log of internal conflicts, outcomes, and reasoning, publicly available to all members.
  • Conflicts between members of different Pods — Handled by the Pod Facilitators of both Pods. If unresolved, it can be brought to the Growth/Ops Pod.
  • Conflicts where neither member is in a Pod — Facilitated by the Community Pod.
  • Unresolved conflicts — If a conflict has not been resolved through the procedures above, the Growth/Ops Pod may help the individual find the next best course of action.

4.5.2 Grievances​

Where a member has a grievance that is not a conflict with a specific individual:

  • Grievance against the DAO — Facilitated by the Growth/Ops Pod.
  • Grievance against a Pod — Facilitated by the Pod Facilitator. If the grievance is against the Pod Facilitator, or their impartiality is in question, the Growth/Ops Pod facilitates.

4.6 Revocation authority​

The DAO may revoke the validity of a specific membership in extenuating circumstances, such as cases where a membership is stolen or used for bad-faith governance purposes.

4.7 Amendment of this Charter​

4.7.1 Initial modifications​

For the first 30 days following ratification of this Charter:

  • Non-material changes — A simple majority of the Growth/Ops Pod is sufficient.
  • Material changes affecting a specific Pod — A simple majority of both the Pod in question and the Growth and Ops Pod together.
  • Material changes affecting the underlying nature of this Charter — A DAO-wide AIP is required.

4.7.2 Further amendments​

After the initial 30-day period, any proposed amendments can be submitted as an AIP.

Article 5: Distributed Authority

Introduction​

All power is inherent in the members. Every person may speak, write, and publish sentiments on all subjects, but shall be responsible for the abuse of that right. This right is subject to applicable laws limiting freedom of expression and does not include the transmission of protected IP rights, secret, or inside information. Bigotry and hate speech will never be tolerated.

The powers of the DAO may be divided into Pods, SubDAOs, and Projects.

5.1 Pod organization, duties and responsibilities​

The purpose of each Pod shall be stated in its initial Pod proposal. In general, Pods should seek to contribute to Arrow DAO within their field of expertise.

Pods have the reasonable right and authority to inspect and investigate the books, records, papers, documents, data, operations, and physical plant of any operation of the DAO or SubDAO within their purview.

5.2 Pod Facilitators​

Each Pod shall have at least one facilitator and one co-facilitator. Pod facilitators have the authority to take any action or make any decision to enact their Pod's purpose, as long as they don't break a rule defined in this Charter.

Pod facilitators must honor the following constraint: they must act in good faith and may not violate any policies of the Pod, any SubDAO containing the Pod, or any applicable law.

5.3 Budget and appropriations​

No money shall be drawn from the treasury except in pursuance of an AIP passed pursuant to the rules in the Governance section. An AIP making appropriations for current expenses shall contain provisions on no other subject.

This section does not include bounties, which may be paid at the discretion of Pod facilitators and posted publicly for members to review.

5.3.1 General budgeting procedures​

The DAO operates on a two-month cycle. Each Pod is responsible for communicating a budget at the beginning of each cycle, following this timeline:

  • 15th — Projected expenses and accounting of actual expenses
  • 20th — Budget proposal submitted
  • 24th — Snapshot vote
  • 1st of following month — Adjustments to payment streams take effect

5.3.2 Financial statements​

No less than once every two-month commitment cycle, each Pod shall prepare a balance sheet showing its financial condition at the close of the period, and a profit and loss statement showing results of operations.

5.3.3 Spending authorization​

"Spending" is the disposal of any property of the DAO, or significantly limiting its use by others. It does not include de minimis expenses under $25 USD, non-reimbursable out-of-pocket expenses by a member, or acceptance of voluntary contributions for a specific purpose.

Neither a Pod nor an individual Pod member may spend any money or other assets without first getting authorization from the DAO. On a two-month basis, each Pod shall propose a budget. Upon majority consensus of Pod members, the proposed budget is added to a quarterly Appropriations AIP for DAO vote.

If a Pod wishes to deviate from its stated budget by $2,500 or more, the Pod must create an additional AIP and gain DAO approval before making such a transaction.

5.3.4 Wallets and transfers of funds​

Each Pod shall own and control its own multisig wallet and shall be solely responsible for the funds therein. When an AIP has been passed, the DAO treasury shall transfer the difference between the Pod's approved budget and the funds currently in the Pod's wallet within 72 hours.

At no time shall a Pod's wallet hold more than $25,000.

5.4 Smart contracts​

Any Pod, SubDAO, or Project shall have the authority to propose and/or create a smart contract on behalf of the DAO. Deployment shall be executed by the Developers Pod and subject to approval by the DAO via Snapshot vote.

The Developers Pod shall promulgate a set of minimum standards for smart contracts, including at minimum an audit by a reputable independent third party. No Arrow DAO smart contracts shall be deployed until such standards have been approved by the DAO via Snapshot vote.

5.5 Arrow DAO's treasury multisig​

Any transfer from Arrow DAO's main treasury shall be approved and signed by 3 out of 5 multisig holders. Multisig holders shall be compelled to approve transactions in a timely manner, and gas fees incurred by holders shall be reimbursed. The following multisig wallets are currently active:

  • Gnosis Safe (Main DAO)
  • Main DAO (OP)
  • Growth/Ops
  • Engineering
  • Services

Article 6: Guidelines for Coordination

The purpose of this section is to help Pods and groups coordinate and communicate in an effective and autonomous way. All communications should have a clearly defined goal.

Communication can be either synchronous or asynchronous. Members and contributors are welcome at all public meetings. Please be courteous and respectful of Pod meetings and keep distractions to a minimum.

6.1 Synchronous communications​

  • Weekly Community Calls — Open to all members.
  • Update meetings — Weekly Pod meetings for groups to update on progress and to-dos. Recommended to be held prior to the weekly Community Call.
  • Informational meetings — For individuals or groups to present ideas and projects to the DAO, Pods, or the public.
  • Working meetings — Semi-formal meetings to develop ideas and discuss specific topics.
  • Informal meetings — Brainstorming sessions for open-ended topics with a conclusive goal.
  • Free-flow meetings — Break-out style meetings for community discussion and bonding.

6.2 Asynchronous communications​

  • Discussions — Held asynchronously on Discord in related channels. Lengthy discussions should be presented as forum posts.
  • Project summaries — Updates on major projects summarized in a Pod Announcements channel in Discord.
  • Resource gathering — Each Pod should have a dedicated place (Notion, Discord Forums, Google Drive) for resource sharing, with all locations indexed centrally.
  • Task assignments and bounties — Pods are encouraged to use Dework/Notion for project management.

Arrow Constitution — Ratified June 25, 2024