gno.land Constitution
We need to write a constitution for Gno.land, specifically for GovDAO members.
We can draw a lot of inspiration from the extensive work done on AtomOne (https://github.com/atomone-hub/genesis), where we can likely recycle many valuable ideas.
Working to help drive an initial CONSTITUTION.md here. My goal is to start out simple with a basic scaffold we can work with, using the solid work from the ATOMONE. Below I'm outlining ideas and questions. I'd love feedback here.
- Let's move quickly and iterate
- Let's take the best, general ideas as a starting point
- Let's specialize as needed
- Let's delegate to domain experts and those who have strong opinions, as needed
- Let's take advantage of the simplicity of
PHILOSOPHY.mdand make something in alignment those values in this document.
Ideas:
- We currently have a really nice https://github.com/gnolang/gno/blob/master/PHILOSOPHY.md for
gnothat makes makes it very clear whatgnois all about. It would be nice to let this influence our constitution - Create a scaffold of the CONSTITUTION, based on the [ATOMONE constitution](https://github.com/atomone-hub/genesis/blob/main/CONSTITUTION.md)
- Proposed Initial Structure:
- Preamble
- Declaration of Intent
- Article 1: General Provisions
- Section 1: Fundamental Principles
- Section 2: Sovereignty of Gno.land
- Section 3: General Mission and Objectives
- Section 4: Rights, Liberties and Obligations
- NOTE: I’m advocating combining Section 4 and 5 into this single section
- Article 2: Governance
- Section 1: The gno.land Chain
- Section 2: Laws and Amendments
- Section 3: gno.land Governance
- Section 4: Common DAO Spec & Core DAOs with Special Powers
- Section 5: Airdrops and forks
- Section 6: Special Purpose DAOs
- NOTE: Now sure how we want to handle Section 4-6, worth discussing.
- Article 3: Economics
- Section 1: Economic Model
- Section 2: The GNOT Token
- Section 3-9:
- NOTE: Not sure how we want to structure this, these seem specific to ATOMONE, but it does touch on things like the Community Pool, Validators, Inflation, etc. This needs a gno.land specific structure.
- Article 4: Implementation
- Section 1: Updates to Gno.land
- Section 2: Protocols
- Section 3: Computer/Storage/Memory Limitations
- Defined Terms
- NOTE: this section should be updated to define terms specific to gno.land
- Preamble
- Proposed Initial Structure:
Open Questions:
- What are the core goals of the Constitution?
- We call out “specifically for GovDAO members” what is the vision for them?
- What should walk away with after reading this constitution that wasn’t clear before?
- The Genesis repo has a
CONSTITUTION.mdbut it also has supporting documents that live outside of the constitution. What is our vision for CONSITITUION vs supporting documents (such asPHILSOPHY.md, etc) that will go with this document, but aren’t included?
- We have the opportunity to draw a lot of inspiration from AtomOne, which parts are we most interested in re-using? What Parts would we like to avoid or are not applicable to gno.land?
- Are we happy with the overall “shape” of the ATOMONE constitution?
- Are there specialized sections or articles we’d like to include specific to gno and/or gno.land?
- AtomOne had its first draft of the constitution as a WIP. https://github.com/atomone-hub/genesis/commits/main/CONSTITUTION.md, Should we do the same in a working branch based on a structure we agree to, but annotate WIP sections?
- Maybe we can assign “owners” to various Articles so that we can work on this in Parallel.
- Plan of action:
- Nail down Article Structure we want for first draft
- Edit existing language, where applicable, for gno.land
- Assign “owners” and “reviewers” for a articles and sections to ensure that they are drafted properly
- Have some sort of clear “TBD” or “WIP” syntax to indicate a section is not ready yet
- Iterate, iterate, iterate.
- Plan of action:
We should draft a v0 document as a foundation for collaboration, with an agreed structure, section titles, and TODO placeholders for parallel work. Some sections can be fully drafted for early feedback, while others remain flexible to edits.
The genesis repo is ideal for this, enabling separate discussions, issues, and PRs with different paces. Initially, we can create a clear README that outlines what’s known, what’s missing, and tasks to address—keeping it up-to-date.
Next, let’s use a collaborative tool like HackMD or Google Docs to start with a structure, relevant content from Atom One’s constitution, and a list of tasks. We can workshop this toward a complete v0, then refine internally before sharing for community input, either in sessions or async review of the repo.