131 lines
6.4 KiB
Markdown
131 lines
6.4 KiB
Markdown
# Proposing a change to Aere Network
|
|
|
|
This document is for someone who is not part of the Aere Foundation and wants to
|
|
change how Aere Network works. It tells you what to do, what happens next, and
|
|
who decides. The last of those three is the one most projects are vague about, so
|
|
it is answered first.
|
|
|
|
## Who decides
|
|
|
|
**The founder decides.** Today, ratification of an AIP is one person's decision,
|
|
exercised through the Aere Foundation account
|
|
`0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`. That account is a single key. It is
|
|
not a multisig, it is not a timelock, and there is no on-chain vote that binds it.
|
|
|
|
There is a governance stack deployed on chain 2800 (a Governor, a Timelock, and a
|
|
governance token). **It controls nothing.** No production contract on chain 2800
|
|
is owned by a timelock, and the governance contracts hold no authority over the
|
|
protocol. They exist as deployed, inert infrastructure for a future in which they
|
|
do. Do not read their existence as a claim that Aere has on-chain governance.
|
|
|
|
The network runs seven QBFT validators, all operated by the Foundation, on one
|
|
live client, with no external security audit. The effective Nakamoto coefficient
|
|
is 1.
|
|
|
|
This is worth stating plainly rather than implying a governance that does not
|
|
exist. If you are deciding whether to invest engineering effort in an Aere
|
|
proposal, that paragraph is the fact you need, and finding it out later would be
|
|
worse for you and for us.
|
|
|
|
**What this means in practice for you:**
|
|
|
|
- A good technical argument can win. There is no stake threshold, no token
|
|
requirement, no membership, and no fee. Your proposal is judged on whether it
|
|
is correct and worth doing.
|
|
- There is no appeal. If the founder declines your proposal, that is the end of
|
|
it inside this process. Aere's proposals are CC0, so forking the record and
|
|
implementing your version elsewhere is always available to you, and nobody here
|
|
will treat that as hostile.
|
|
- A rejection will be written down. If your AIP is rejected, it keeps its number,
|
|
moves to Withdrawn, and stays in the repository with the reason recorded. We do
|
|
not delete proposals we disagreed with.
|
|
|
|
## What we will not do
|
|
|
|
Two commitments, so you know what you are relying on:
|
|
|
|
1. **We will not renumber or reuse your number.** Once your proposal is assigned
|
|
AIP-N it is AIP-N permanently, including if it is withdrawn (AIP-1 section 2).
|
|
2. **We will not silently edit your proposal after it is accepted.** A Final AIP
|
|
is frozen. Corrections are appended as dated errata that leave the original
|
|
text visible (AIP-1 section 5).
|
|
|
|
## How to propose
|
|
|
|
### Step 0: check it belongs in an AIP
|
|
|
|
**In scope:** a protocol or consensus change (block time, fee routing,
|
|
precompiles); a new contract standard or interface others integrate against; a
|
|
token or account standard convention; a process or governance change.
|
|
|
|
**Out of scope:** bug-fix redeploys that preserve an existing interface, routine
|
|
parameter tuning inside an already-ratified bound, and pure documentation. A
|
|
security vulnerability is **not** an AIP: do not publish it. Report it privately
|
|
first.
|
|
|
|
If you are unsure, propose it anyway. The editor will tell you.
|
|
|
|
### Step 1: write it
|
|
|
|
Copy `aip-template.md`. Fill in every section. Do not delete a header; write
|
|
"None" if a section does not apply, because "Security Considerations: None" is a
|
|
claim a reviewer can challenge and a missing section is not.
|
|
|
|
The rules that get proposals bounced fastest:
|
|
|
|
- **Cite addresses verbatim** from `sdk-js/src/addresses.ts`. Do not retype them.
|
|
- **Label every number** as **measured** (reproducible from the chain or a repo
|
|
fixture), **spec** (a configured or standardized value), or **estimate**.
|
|
- **Write "to be measured"** rather than guessing. A guessed gas figure is worse
|
|
than an absent one, because the reader cannot tell it is a guess.
|
|
- **Do not claim post-quantum consensus.** Aere consensus is classical secp256k1
|
|
ECDSA QBFT. Aere's post-quantum work is at the signature, account and
|
|
application layers. A proposal that blurs this will be sent back.
|
|
|
|
### Step 2: submit it
|
|
|
|
Open a pull request against `aere-research/aips/` adding `AIP-N.md`, where N is the
|
|
next free integer, plus a row in `README.md`. If you cannot open a pull request,
|
|
send the document by any route that reaches the Foundation; the format matters,
|
|
the transport does not.
|
|
|
|
### Step 3: what happens next
|
|
|
|
| Stage | What happens | Who | Typical time |
|
|
| --- | --- | --- | --- |
|
|
| Well-formedness check | The editor checks the template is complete, the number is right, and every cited address, hash and number is real. This is not a merit review. | Editor (the Foundation today) | days |
|
|
| **Draft** | Your number is assigned. You own the document and can keep changing it. | You | as long as you want |
|
|
| **Review** | You declare it ready for scrutiny. Open questions are tracked inside the document itself, not in a side channel. | You, plus anyone who comments | open-ended |
|
|
| **Last Call** | A final review window, 14 days by default, with the end date written into the document. | Editor | 14 days |
|
|
| **Final** | Ratified. Frozen under AIP-1 section 5. | Founder | one decision |
|
|
|
|
You can stop at any point by withdrawing. The editor moves a proposal to Stagnant
|
|
after six months of inactivity in Draft or Review; anyone, including you later,
|
|
can revive it.
|
|
|
|
### Step 4: honestly, about "review"
|
|
|
|
Aere has **no external technical community commenting on AIPs yet**. This is not
|
|
a modesty statement, it is the current state: decentralization is thin and
|
|
external usage is thin. If you file a proposal today, the review you get is from
|
|
the Foundation, and it may be the only review you get.
|
|
|
|
We record that rather than inventing the alternative. There are no fabricated
|
|
comment threads in this repository, no invented "the community debated", and no
|
|
imagined participants. When real external comment arrives it will be recorded as
|
|
it happened. Until then, do not expect a crowd, and do not mistake an empty
|
|
comment section for consensus.
|
|
|
|
## Reporting a vulnerability instead
|
|
|
|
If you found a security bug, this is the wrong document. Do not file an AIP, do
|
|
not open a public pull request, and do not include the vulnerability in any
|
|
public issue. Report it privately to the Foundation first. Publishing a live
|
|
vulnerability against a chain with a single operator and no external audit
|
|
endangers users who have no way to react.
|
|
|
|
## Copyright
|
|
|
|
Everything you submit here is CC0, released to the public domain. If that is not
|
|
acceptable to you, do not submit it.
|