diff --git a/docs/articles/governance/Proposals/definitions.en.mdx b/docs/articles/governance/Proposals/definitions.en.mdx
new file mode 100644
index 0000000..1e2ca37
--- /dev/null
+++ b/docs/articles/governance/Proposals/definitions.en.mdx
@@ -0,0 +1,107 @@
+# Definitions and Concepts
+
+## Proposal Types
+
+### On-Chain Governance
+
+On-chain governance refers to all protocol level execution of proposals using Cosmos SDK's `gov` module. Anyone who holds or stakes EVMOS can participate in these votes, regardless of the voter's validator choices.
+
+### Off-Chain Governance
+
+Off-chain governance refers to all community decisions that do not require an on-chain protocol-level change. These types of decisions include a wide variety of topics and concepts, from passing meta-governance proposals to the formation of special task forces or workstreams.
+
+
+:::tip
+All proposals are assumed to be `On-Chain Proposals` until the necessary infrastructure and toolings for `Off-Chain Voting` is established. Cosmos SDK's `TextProposal` will be used for `Off-Chain Proposals` for the time being.
+:::
+
+---
+
+## Proposal Types by Category
+
+### Protocol Proposals
+
+| Module | Codebase | Parameters | Description |
+| -------------- | ------------ | --------------------------------------------------------------------------------- | ----------------|
+| `auth` | `cosmos-sdk` | `MaxMemoCharacters` `TxSigLimit` `TxSizeCostPerByte` `SigVerifyCostED25519` `SigVerifyCostSecp256k1` | The auth module is responsible for specifying the base transaction and account types for an application. [Ref.](https://docs.cosmos.network/v0.46/modules/auth/06_params.html) |
+| `bank` | `cosmos-sdk` | `SendEnabled` `DefaultSendEnabled` |The bank module is responsible for handling multi-asset coin transfers between accounts and tracking special-case pseudo-transfers which must work differently with particular kinds of accounts. [Ref.](https://docs.cosmos.network/v0.46/modules/bank/05_params.html)|
+| `distribution` | `cosmos-sdk` | `communitytax` `baseproposerreward` `bonusproposerreward` `withdrawaddrenabled` |This simple distribution mechanism describes a functional way to passively distribute rewards between validators and delegators. [Ref.](https://docs.cosmos.network/v0.46/modules/distribution/07_params.html) |
+| `governance` | `cosmos-sdk` | `min_deposit` `max_deposit_period` `voting_period` `quorum` `threshold` `veto` | The module enables Cosmos-SDK based blockchain to support an on-chain governance system. [Ref.](https://docs.cosmos.network/v0.46/modules/gov/06_params.html) |
+
+Additional Protocol Proposals: `slashing`, `staking`, `transfer`, `feemarket`, `claims`, `inflation`
+
+---
+
+### Community Proposals
+
+Proposals that only require to be posted as a `TextProposal` on the Cosmos SDK - *Most commonly used for meta-governance proposals.*
+
+---
+
+### Workstream & Special Initiatives
+
+Proposals that requests any type of funding from the `CommunityPool` or the DAO's treasury to form an in-house workstream (team, squad, sub-DAO, guild) or project with the direct purpose of benefiting the Evmos ecosystem.
+
+#### **Workstreams**
+
+Workstreams are typically DAO-funded teams with a recurring budget with no termination date (i.e., Community Outreach, Marketing & Creative Services, etc). More information on workstreams can be found on the [DAO Workstreams page.](/governance/workstreams/index)
+
+Workstreams are the sub-units of how Evmos DAO advances its purpose. A workstream is a group of people actively working on tasks that align with Evmos' Constitutional Values and community run initiatives. As such, ratifying workstreams sets boundaries on what is and isn't in scope for Evmos DAO's governance.
+
+Anyone may start a workstream and gather momentum behind it by posting on Commonwealth. Until a formal proposal for a budget is made, this workstream is considered “informal.” A workstream can be as broad or narrow as its initiators like, but workstream proposals must satisfy the following criteria:
+
+- Have a clear objective that aligns with Evmos' values and objectives as listed in the [Constitution](/constitution).
+- Distinguish itself from or explicitly state its improvements on existing workstreams.
+- Propose clear budgets and timelines for producing outcomes and all in line with the budget proposal flow.
+
+Workstreams have five potential states. Each of the five states and the requirements for a workstream in each state are outlined below:
+
+- **Informal:** The workstream is not funded by the DAO, and has not made a formal proposal with its goals and a budgetary request.
+- **Proposed:** The workstream has made a formal proposal to the DAO for a working budget.
+- **Active:** The workstream is active and funded by the DAO.
+- **Inactive:** The workstream has been discontinued and is no longer being funded by the DAO.
+
+#### **Special Initiatives / Projects**
+
+Special Initiatives and Projects are DAO-funded projects with a set budget and "completion" goal or date (i.e., Governance Tooling Project, Event Sponsorships, etc.)
+
+---
+
+### Protocol Incentives + Evmos Specific Proposals
+
+| Module | Codebase | Parameters | Description |
+| -------------- | ------------ | --------------------------------------------------------------------------------- | ----------------|
+| `revenue` | `evmos` | `EnableFeeSplit` `DeveloperShares` `AddrDerivationCostCreate` |[reference](https://docs.evmos.org/modules/feesplit/07_parameters.html) |
+| `incentives` | `evmos` | `EnableIncentives` `AllocationLimit` `IncentivesEpochIdentifier` `rewardScaler` |[reference](https://docs.evmos.org/modules/incentives/07_parameters.html) |
+| `erc20` | `evmos` | `register_coin` `register_erc20` |[reference](https://docs.evmos.org/modules/erc20/07_parameters.html) |
+| `evm` | `evmos` | `ExtraEIPs` `ChainConfig` |[reference](https://docs.evmos.org/modules/evm/08_params.html) |
+
+---
+
+### Network Upgrades & Security
+
+| Module | Codebase | Parameters | Description |
+| -------------- | ------------ | --------------------------------------------------------------------------------- | ----------------|
+| `crisis` | `cosmos-sdk` | `ConstantFee` |The crisis module halts the blockchain under the circumstance that a blockchain invariant is broken. [Ref.](https://docs.cosmos.network/v0.46/modules/crisis/04_params.html)|
+| `upgrade` | `cosmos-sdk` | `MsgSoftwareUpgrade` | `x/upgrade` is an implementation of a Cosmos SDK module that facilitates smoothly upgrading a live Cosmos chain to a new (breaking) software version. [Ref.](https://docs.cosmos.network/v0.46/modules/upgrade/)|
+
+:::tip
+Emergency and Network Upgrade Proposals are exempt from following the Proposal Lifecycle Framework. The community is expected to do its due dilligence when such proposals are uploaded.
+:::
+
+---
+
+## Proposal Phase & Identification Tags
+
+**You do not need to know the proposal phase and identification naming conventions! A Governance Council member will assist -- the content below is for reference.**
+
+Proposal Phases are denoted as: `[IDEATION]`, `[PRE-PROPOSAL]`, `[PROPOSAL]`, `[VOTING]` for the 4-phases, and `[PASSED]`, `[REJECTED]`, `[DEFERRED]` for proposals in the other stages. Refer to the [Proposal Lifecycle](/governance/proposals/lifecycle) page for more information on proposal lifecycle phases.
+
+
+:::tip
+Proposal Identification Tags are only required for Governance, Workstream (subDAO), and Community Treasury Related Proposals Only
+:::
+
+The `ECP-#` tag will be assigned and added by a Governance Council member in the `Phase 2: ECP Formalization` or `Phase 3: ECP Signaling` phase. **You do not have to worry about adding in the tag yourself.**
+
+These tags are for internal tracking and organization purposes. Make sure to check the [Proposal Submission Guidelines](/governance/proposals/submission) for more information on how to properly prepare your proposal for on-chain voting.
\ No newline at end of file
diff --git a/docs/articles/governance/Proposals/index.mdx b/docs/articles/governance/Proposals/index.mdx
new file mode 100644
index 0000000..9989baf
--- /dev/null
+++ b/docs/articles/governance/Proposals/index.mdx
@@ -0,0 +1,22 @@
+# Proposals Framework
+
+## Evmos Community Proposals (ECPs)
+
+ECPs are standardized proposals subject to voting that (once enacted) regulate and define the behavior of the Evmos DAO's Governance system, and provides a funding mechanism for special projects and workstreams.
+
+## The Evmos Community Proposal Framework
+
+The Evmos Community Proposal (ECP) Framework sets the guideline for all subsequent ECPs to follow. This ECP is the foundational ECP that provides the necessary templates, processes, and guidelines for working within the framework and defines the key roles required for the operation and enforcement of the ECP process.
+
+### ECP Framework Components
+
+[**1. Definitions of the ECP Framework**](/governance/proposals/definitions) - *Defines core concepts of the ECP Framework and the different types of proposals.*
+
+[**2. The ECP Lifecycle**](/governance/proposals/lifecycle) - *Defines the formal stages in the lifecycle of proposals from conception to approval, rejection, or deferral.*
+
+[**3. ECP Standards and Templates**](/governance/proposals/templates) - *Defines the processes, rules, and components required for all proposals before going to vote.*
+
+[**4. ECP Submission Guidelines**](/governance/proposals/submission) - *Defines the proposal submission procedures and guidelines for on-chain voting.*
+
+[**5. Evmos Governance Council**](/governance/workstreams/current#governance-council-wip) - *Defines the responsibilities and enforcement powers reserved to the Governance Council of Evmos DAO.*
+
diff --git a/docs/articles/governance/Proposals/lifecycle.en.mdx b/docs/articles/governance/Proposals/lifecycle.en.mdx
new file mode 100644
index 0000000..31d8142
--- /dev/null
+++ b/docs/articles/governance/Proposals/lifecycle.en.mdx
@@ -0,0 +1,77 @@
+import ContentTimeline from '/src/components/ProposalSteps';
+
+# Proposal Lifecycle
+
+
Title: Short and sweet, with the [correct tags](/governance/proposals/definitions#proposal-phase--identification-tags) prefixed.
+**Title** - Short and sweet, with the [correct tags](/governance/proposals/definitions#proposal-phase--identification-tags) prefixed.
+ +**Author(s)** - List of authors and contributors involved in the writing of the proposal.
+ +**Summary** - A brief, high-level summary of what changes are being suggested. Summary should be a single sentence, or a bulleted list.
+ +**Abstract** - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the motivation and specification sections. Someone should be able to read only the abstract to get the gist of what this specification does.
+ +**Motivation** - The motivation section should describe the "why" of this proposal. What problem does it solve? What benefit does it provide to the Evmos network?
+::: + +## B. Project/Protocol Introduction + +:::tip +