Submit a Cooperative Project for Community Investment
EarthCoop lets eligible users and groups create projects and submit them into the current review lifecycle. A project begins as a draft. Submission moves it into formal review; review may approve it, reject it, request revision, or archive it according to the current workflow.
A project record, a support threshold, a positive review decision, and a monetary transfer are separate events. This page keeps those boundaries explicit.
How to submit a project
Create the project
Open the current Projects area and create a new project for yourself or, where your current responsibility permits, for a group. Creation records the project as a draft.
Choose the project scope
Select the valid governance area that represents the project's target or operating scope. The location/governance selector can stop at the valid level that matches the project; it does not require you to descend to a household-level address when a broader scope is intended.
Describe the project
Provide the project title, category information and the descriptive, operational, risk and financing information exposed by the current form. Category choices are validated against the configured hierarchy.
Review economic terms
Monetary amounts are expressed in Bahar. Gol is the subunit of Bahar (1 Bahar = 100 Gol). Financing terms should be read together with the applicable project contract and ECON rules rather than as a guaranteed return.
Submit for review
Submitting a valid draft changes the project to pending. A reviewer can then move it to under_review and record a formal decision. A rejected project may be corrected and submitted again where the current service permits it.
Required fields
The exact form evolves with the product, but the current project domain records the following classes of information:
- project identity and title;
- a valid category path;
- governance scope;
- project type, visibility and stage where applicable;
- summary and project description;
- financing method and the fields required by that method;
- risk, oversight, reporting and transparency information where exposed by the current workflow;
- supporting attachments where applicable.
Do not infer that every possible project type requires the same financing fields. The service distinguishes project and investment methods and validates the fields applicable to the selected method.
Project statuses
| Status | What it means |
| --- | --- |
| draft | Created but not formally submitted. |
| pending | Submitted and waiting for formal review. |
| under_review | Review is actively in progress. |
| approved | The project review decision is positive. Approval is not Transfer. |
| rejected | The project was not approved or requires revision and may be eligible for resubmission. |
| archived | The project has been removed from the active workflow. |
Support and formal review
A project discussed through a group or public-assembly proposal may have to reach an applicable support threshold before it enters the formal institutional workflow. Support does not approve the project. Crossing the threshold creates the basis for formal referral/review and, where the workflow applies, registration in the secretariat trail with its own case history.
That distinction protects both participants and project owners: members can support further examination without being treated as having authorized a payment.
Approval and money movement
Approval does not transfer Bahar. A positive project decision is not permission to silently debit members or to credit the project owner automatically.
For a public project, the ECON reference architecture separates the later monetary stages: legal approval, Liability Snapshot, Commitment, Committed Dim, satisfaction of Activation conditions, Activation, Transfer, and arrival of Active Bahar in the Active Project Fund. Each stage must leave the appropriate record.
A project page showing approved must never be interpreted as evidence that a Commitment, Activation, or Transfer has already occurred.
Revision and resubmission
When the current review service rejects a project or requests revision, the reason and review action are recorded. Eligible rejected projects can be edited and resubmitted, returning to pending for another review cycle. Earlier review history remains part of the project audit trail rather than being erased.