ECIP 1114: Ethereum Classic Funding Proposal Process

Simple Summary

This ECIP defines the Ethereum Classic Funding Proposal (ECFP) process — the exclusive, standardized, and permissionless mechanism for requesting and executing funding from the Olympia Treasury (ECIP-1112).

ECFPs are application-layer funding proposals that:

• are submitted by any participant without prior permission,
• are reviewed and voted on through Olympia DAO governance (ECIP-1113), and
• are executed only via the DAO’s authorized Governor → Timelock → Executor pipeline, which calls the Treasury with opaque {target, value, calldata} payloads.

This process governs the allocation of BASEFEE revenue redirected under ECIP-1111 and ensures that protocol-level funds are used in a transparent, accountable, and governance-neutral manner.

Abstract

This ECIP formalizes the Ethereum Classic Funding Proposal (ECFP) process — the standardized, permissionless, and exclusive mechanism for submitting, reviewing, and executing funding requests from the Olympia Treasury (ECIP-1112).

The Treasury is populated by BASEFEE revenue redirected at the consensus layer under ECIP-1111 and is controlled solely by Olympia DAO (ECIP-1113). ECIP-1114 defines:

• the canonical ECFP data model (identifier, recipient, amount, metadata),
• the proposal lifecycle (submission → governance vote → timelocked execution → completion),
• the hash-bound execution model that ties every disbursement to immutable off-chain metadata, and
• the interface boundary between application-layer proposal registries and the governance execution pipeline.

All funding actions are encoded as opaque {target, value, calldata} payloads to the governance system. The Treasury (ECIP-1112) and governance architecture (ECIP-1113) treat ECFP identifiers and hashes as opaque values and do not interpret proposal metadata.

This ECIP introduces no consensus-layer logic and does not modify Treasury or governance behavior. It operates entirely at the application layer and can evolve alongside Olympia DAO via standard governance procedures.

Motivation

For most of its history, Ethereum Classic has depended on centralized foundations, corporate sponsors, and private donors to fund protocol development and public infrastructure. These arrangements were often opaque, fragile, and vulnerable to gatekeeping, creating long periods of underfunding for:

• client maintenance and consensus upgrades,
• public RPC and node infrastructure,
• security audits and incident response, and
• documentation, education, and ecosystem growth.

With the activation of:

• ECIP-1111 – Olympia EVM and Protocol Upgrades, which redirects BASEFEE into a protocol-level revenue stream,
• ECIP-1112 – Olympia Treasury Contract, which provides an immutable, governance-isolated vault for that revenue, and
• ECIP-1113 – Olympia DAO Governance Framework, which defines the sole on-chain executor path for Treasury withdrawals,

Ethereum Classic gains a decentralized, non-inflationary, protocol-native funding source. What remains is a standardized, auditable process for submitting, reviewing, voting on, and executing funding proposals so that every Treasury allocation is transparent, reproducible, and resistant to capture.

The Ethereum Classic Funding Proposal (ECFP) process addresses this need by:

• defining a clear proposal lifecycle from submission to execution,
• standardizing the data model for funding requests (identifiers, recipients, amounts, metadata),
• binding disbursements to immutable, content-addressed metadata via hash-bound execution, and
• ensuring that all spending decisions flow through the Governor → Timelock → Executor pipeline defined in ECIP-1113.

ECIP-1114 thus replaces ad hoc, off-chain funding arrangements with a transparent, rules-based funding process that is native to Ethereum Classic and aligned with its principles of immutability, decentralization, and neutrality.

Specification

The Ethereum Classic Funding Proposal (ECFP) process defines the exclusive, standardized, and permissionless on-chain lifecycle for submitting, reviewing, voting on, and executing protocol-level funding proposals. It is the sole mechanism through which the Ethereum Classic community may authorize disbursements from the protocol-level Olympia Treasury defined in ECIP-1112.

ECFPs govern the allocation of BASEFEE revenue redirected at the consensus layer under ECIP-1111.
All funding decisions and all Treasury calls are enforced exclusively by the governance architecture specified in ECIP-1113.

The ECFP process is:

• Transparent — All proposal submissions, votes, approvals, queues, and disbursements are immutably recorded on-chain.
• Reproducible — All participants follow the same lifecycle, parameters, and execution path.
• Hash-bound — Every disbursement is cryptographically bound to immutable proposal metadata through the tuple
  (ecfpId, recipient, amount, metadataCID, chainid),
  ensuring integrity, replay protection, and alignment between off-chain metadata and on-chain execution.

Only successful governance actions that meet quorum, threshold, voting period, and timelock requirements MAY authorize a Treasury disbursement.
Execution occurs through the DAO’s authorized Executor, which forwards an opaque {targets, values, calldatas} payload to the Olympia Treasury. The Treasury validates disbursements via the hash-bound model defined in ECIP-1112, using the exact parameters included in the approved ECFP.

ECFP Lifecycle

The ECFP lifecycle defines how a funding proposal moves from initial submission to final execution.
This lifecycle is application-layer only; all governance logic, voting, timelock behavior, and Treasury execution are enforced solely by the Governor → Timelock → Executor architecture defined in ECIP-1113 and the Treasury contract defined in ECIP-1112.

1. Proposal Submission

• Any Ethereum Classic address MAY submit an ECFP.
• Submission is permissionless. Optional Sybil-resistance modules (e.g., BrightID, Gitcoin Passport, Proof of Humanity) MAY be added by DAO vote.
• Each proposal MUST include the following on-chain fields:
  • ecfpId – unique proposal identifier
  • recipient – address to receive funds
  • amount – requested funding amount (wei)
  • metadataCID – content-addressed hash (e.g., IPFS, Arweave) binding off-chain metadata
• Off-chain metadata referenced by metadataCID SHOULD include:
  • Title / human-readable identifier
  • Author(s) and contact information
  • Purpose, scope, intended impact
  • Disbursement structure (milestones, vesting, lump sum)
  • Deliverables and KPIs
• The tuple (ecfpId, recipient, amount, metadataCID, chainid) MUST be used to derive the hash-bound identifier required for execution as defined in ECIP-1112.

2. Proposal Statuses

All ECFPs MUST follow these standardized states:

• Draft — Submitted; open for discussion; not yet eligible for voting.
• Active — Undergoing governance voting.
• Approved — Passed quorum and threshold; queued in the Timelock for execution.
• Rejected — Failed quorum or approval threshold.
• Executed — One or more associated Treasury disbursements were successfully executed.
• Expired — Did not activate or queue within a DAO-defined validity window.

Implementations MAY define additional non-binding UX states (e.g., Cancelled, Superseded), but the above MUST be reconstructible from on-chain events and storage.

3. Voting and Quorum

• All ECFPs SHALL follow the governance logic in ECIP-1113.
• At launch, Olympia DAO operates without a governance token, using a one-address-one-vote model.
  Mitigation strategies for Sybil risk (e.g., attestations, delegated voting, reputation systems) MAY be adopted via future governance.
• The DAO MAY upgrade to alternative voting systems (stake-weighted, delegated stake, quadratic, hybrid) through standard governance without modifying this ECIP.
• A minimum quorum MUST be met.
• A configurable approval threshold (e.g., ≥60% “yes”) MUST be met.
• Voting delay and voting period parameters SHALL be DAO-configurable.
• All voting tallies and results MUST be recorded on-chain and be publicly auditable.

4. Execution and Disbursement

• Only proposals that become Approved and are successfully queued in the Timelock MAY proceed to execution.
• Execution is performed exclusively by the DAO’s authorized Executor, which forwards an opaque {targets, values, calldatas} payload to the Treasury as defined in ECIP-1113.
• One of the targets MUST be the Olympia Treasury.
  The corresponding calldata MUST encode the Treasury’s withdrawal function and include:
  • The hash-bound identifier derived from
    (ecfpId, recipient, amount, metadataCID, chainid)
  • Matching recipient and amount values
• Treasury disbursement MUST follow the validation rules defined in ECIP-1112.
• Execution MUST emit a ProposalExecuted (or equivalent) event containing:
  • ecfpId
  • hash-bound identifier
  • recipient
  • amount
  • timestamp

Non-normative note:
No helper function such as executeECFP() is defined in ECIP-1114.
Execution occurs only through Governor → Timelock → Executor as defined in ECIP-1113.

5. Amendments and Withdrawals

• Proposals MAY be modified or withdrawn while in Draft.
• Once in Active, proposal fields (recipient, amount, metadataCID) are immutable.
  Any change requires submitting a new ECFP with a new ecfpId.
• Rejected or expired proposals MAY be resubmitted as new proposals, generating a new hash-bound identifier.

6. Transparency and Indexing

• All state transitions MUST be represented on-chain via storage or events.
• ECFP registries and governance contracts SHOULD emit standardized events:
  • ProposalSubmitted
  • ProposalActivated
  • ProposalQueued
  • ProposalExecuted
• Public explorers MAY index proposal metadata, lifecycle transitions, and disbursement history for transparency and auditability.

Spam, Sybil, and Governance Capture Mitigations

To preserve openness, integrity, and resilience against manipulation, the following mitigations MAY be adopted by the Olympia DAO through on-chain governance as defined in ECIP-1113.
All measures in this section are optional, modular, and MUST preserve the permissionless nature of the ECFP process.

These mitigations SHALL NOT:

• restrict access through privileged actors or centralized authorities,
• introduce off-chain gatekeepers,
• override the standard ECFP lifecycle, or
• alter the Treasury’s execution rules defined in ECIP-1112.

Participation Thresholds

DAO-approved mitigations MAY require lightweight, permissionless submission conditions, such as:

• Refundable ETC deposits (e.g., returned if quorum is met)
• Minimal ETC or governance token holding
• Optional Sybil-resistance attestations, including:
  • BrightID
  • Gitcoin Passport
  • Proof of Humanity
  • Any future decentralized identity system approved by governance

These integrations MUST remain:

• permissionless — anyone may still participate by meeting objectively defined criteria
• modular — no hard-coded dependencies
• opt-in — sub-DAOs or workflows MAY elect to use them, but they cannot be mandatory at the consensus layer

Submission Cooldowns

• Governance MAY adopt rate limits or cooldown periods between submissions from the same address to reduce spam or flooding.
• These cooldowns MUST be enforced via DAO configuration, not via special access rights.

Draft Review Periods

• Every ECFP MUST remain in Draft for a minimum review period to allow time for community feedback and informal discussion before activation.
• The minimum review window MAY be configured through governance.

Structured Format Requirements

• All ECFPs MUST conform to the standardized template adopted by the DAO (title, description, metadata, parameters, KPIs, etc.).
• Every ECFP MUST embed a verifiable content hash (e.g., IPFS CID, Arweave digest) of its off-chain metadata.
• The metadataCID MUST match the value used in the hash-bound disbursement tuple (ecfpId, recipient, amount, metadataCID, chainid) required for Treasury execution under ECIP-1112.
• No ECFP MAY proceed to Active unless the metadata hash is well-formed and valid.

These requirements ensure that the metadata used during voting is identical to the metadata bound to the Treasury disbursement, preventing manipulation or divergence between the approved proposal and its execution payload.

Voting Model Upgradeability

At launch, the Olympia DAO operates without a governance token, using the one-address-one-vote model defined in ECIP-1113.
This ensures maximum openness and broad community participation during the initial phase of the Olympia framework.

Sybil-resistance modules and submission protections defined in ECIP-1113 are independent of the voting model itself; this section concerns only the mechanism by which voting power is aggregated and counted.

The DAO MAY, through a standard on-chain governance proposal, upgrade to alternative voting systems, including but not limited to:

• stake-weighted or delegated stake models
• governance tokens with transparent, non-allocative issuance
• quadratic voting
• identity-verified or attestation-based models
• hybrid combinations of the above

Any upgrade to the voting model:

• MUST be proposed and approved through the ECFP governance process
• MUST meet the quorum, approval threshold, and timelock requirements established by the DAO
• MUST respect the no premine, no privileged allocation, no retroactive advantage principles defined in ECIP-1113
• MUST NOT introduce centralized gatekeepers, trusted third parties, or off-chain discretionary authority

Changes to the voting model SHALL NOT modify, weaken, or bypass the execution requirements of the Olympia Treasury defined in ECIP-1112.
All disbursements remain subject to:

• the hash-bound execution model (ecfpId, recipient, amount, metadataCID, chainid), and
• authorization exclusively through the Governor → Timelock → Executor pipeline.

Voting model flexibility enables long-term governance evolution while preserving the immutability, neutrality, and isolation of the Treasury.

Child-DAO ECFPs for Infrastructure Spending

To streamline recurring or infrastructure-critical funding (e.g., client maintenance, public RPC services, security audits), the Olympia DAO MAY define Child-DAO ECFP categories through standard governance as described in ECIP-1113.

Child-DAOs are application-layer helper contracts with scoped responsibilities.
They DO NOT possess independent spending authority and DO NOT interface with the Treasury directly.

Typical infrastructure domains include:

• Client DAO — Maintains protocol clients, reviews CVEs, performs releases, and ensures consensus alignment.
• Infra DAO — Manages RPC endpoints, explorers, indexers, load balancers, and DevOps operations.
• Security DAO — Coordinates audits, formal verification, fuzzing, incident response, and bounty programs.

Child-DAO Responsibilities

Each Child-DAO:

• Is deployed as a modular contract under authority granted by the main DAO.
• MAY coordinate domain-specific workstreams, contributors, and milestones.
• Submits ECFPs to the main DAO on a scheduled or recurring basis (e.g., monthly, quarterly).
• Operates only within the scope defined by main DAO proposals (e.g., budget ceilings, reporting requirements).
• Publishes periodic progress and expenditure reports linked to the metadata of the associated ECFPs.
• MAY be renewed, modified, or sunset via new main DAO proposals.

Child-DAOs exist to organize work, NOT to control funds.

Benefits of the Child-DAO Model

• Predictable, depoliticized funding for mandatory ecosystem operations
• Reduced governance overhead for non-controversial maintenance tasks
• Clear accountability through standardized event logging, periodic reports, and recurring ECFPs
• Minimal surface area by isolating domain responsibilities

Governance Requirements

To preserve Treasury immutability and governance isolation:

• All disbursements from the Olympia Treasury MUST be authorized by the main DAO using the standard ECFP lifecycle defined in this ECIP.
• All Treasury calls MUST execute through the main DAO’s authorized Executor, using the hash-bound disbursement tuple
  (ecfpId, recipient, amount, metadataCID, chainid)
  required by ECIP-1112.
• Child-DAO proposals MUST follow the same lifecycle and constraints as all other ECFPs:
  • Draft → Active → Approved → Queued → Executed
  • subject to quorum, threshold, and timelock rules
• Child-DAOs SHALL NOT:
  • hold keys, multisigs, or privileged authority
  • execute Treasury withdrawals
  • bypass the Governor → Timelock → Executor pipeline
  • create independent budgets outside ECFP governance
  • impose off-chain or discretionary approval processes

Child-DAOs MAY streamline coordination, but only the main DAO governs funds.
Their sole purpose is to bundle repetitive or domain-specific work into clearly structured ECFPs that the community can evaluate, approve, or reject.

Governance Scope

The Ethereum Classic Funding Proposal (ECFP) process is the exclusive, on-chain mechanism for authorizing all disbursements from the Olympia Treasury, as defined in ECIP-1112.
This includes, but is not limited to:

• core protocol development
• emergency or contingency funding
• recurring maintenance or operational budgets
• multi-phase or milestone-based grant programs

The Olympia DAO, defined in ECIP-1113, SHALL be the only governance-authorized contract permitted to initiate Treasury withdrawals.
All Treasury movements MUST:

• be authorized exclusively through successful DAO proposals following the ECFP lifecycle,
• be executed through the Governor → Timelock → Executor pipeline,
• use the hash-bound disbursement tuple
  (ecfpId, recipient, amount, metadataCID, chainid)
  required for validation under ECIP-1112, and
• be immutably enforced by the Treasury contract’s internal logic.

Treasury access is immutable, governance-isolated, and non-bypassable.
No off-chain multisig, committee, foundation, service provider, or discretionary process MAY override, initiate, or modify Treasury disbursements.

The DAO MAY define proposal subtypes (e.g., operational budgets, recurring maintenance proposals, treasury management ECFPs) with domain-specific eligibility criteria or workflows, provided they adhere to:

• quorum
• approval thresholds
• voting delays and voting periods
• timelock requirements

All disbursements MUST remain subject to the standard ECFP lifecycle and the Treasury’s hash-bound validation model.
No Treasury funds MAY be allocated, redirected, or disbursed outside the ECFP process.

Additional governance safeguards MAY include:

• supermajority thresholds for sensitive funding categories
• co-signing or multi-step execution for large disbursements
• staggered execution timelines for additional oversight

These safeguards MUST be implemented via on-chain governance and SHALL NOT introduce privileged actors or discretionary authority.

Legal Interface: Ethereum Classic DAO LLC

To support fiat disbursements and necessary administrative compliance, the Ethereum Classic community MAY operate an external legal interface: the Ethereum Classic DAO LLC, a Wyoming-registered entity established under the Wyoming DAO LLC Act.

The Ethereum Classic DAO LLC exists purely as an off-chain administrative executor, and SHALL remain strictly subordinate to on-chain governance.
It holds no authority, implicit or explicit, over the Olympia Treasury or the ECFP process.

Scope and Responsibilities

The Ethereum Classic DAO LLC SHALL operate solely as a legal execution proxy for approved on-chain ECFPs.
It SHALL:

• execute only those actions explicitly authorized by a successful DAO proposal,
• follow the exact parameters specified in the approved proposal’s metadata, and
• perform no evaluative, filtering, or discretionary decision-making.

Permissible administrative tasks include:

• fiat currency conversion
• contractor onboarding and compliance (e.g., KYC, W-9/W-8BEN collection)
• tax reporting and regulatory filings
• delivery of contractual documents tied to approved ECFPs

All such actions MUST correspond directly to an approved ECFP and MAY NOT add, modify, or interpret requirements beyond those set by on-chain governance.

Traceability and Hash-Bound Consistency

All fiat-related disbursements MUST:

• correspond to a hash-bound proposal
  (ecfpId, recipient, amount, metadataCID, chainid)
  as required by ECIP-1112,
• be fully traceable to the same metadata used for on-chain execution, and
• be included in publicly accessible financial reports.

These requirements ensure that off-chain administrative actions precisely mirror their on-chain counterparts, preventing drift, reinterpretation, or discretionary alteration.

Transparency and Reporting

The LLC SHALL publish periodic public reports summarizing:

• donation receipts
• contractor onboarding logs (to the extent legally permissible)
• administrative cost summaries
• fiat conversion records and dates
• corresponding ECFP identifiers for every off-chain disbursement

These reports MUST align with the underlying hash-bound metadata to maintain auditability.

Prohibited Actions

The Ethereum Classic DAO LLC MUST NOT:

• hold or control Treasury private keys
• initiate, authorize, or route Treasury disbursements
• veto, reinterpret, or modify approved ECFPs
• circumvent the Governor → Timelock → Executor pipeline
• combine protocol-level Treasury funds with donor or operational funds
• introduce off-chain custody, signers, or multisig authority over on-chain funds
• exercise governance influence or serve as a gatekeeper

The LLC’s role is purely administrative, never authoritative.

Governance and Oversight

• DAO participants MAY, through standard governance, reassign LLC administrative roles or rotate signers via term-limited elections.
• The LLC’s scope and mandate SHALL remain narrow, revocable, and strictly limited to administrative facilitation.
• No LLC action MAY supersede, delay, or contradict an approved ECFP or its hash-bound execution parameters.

The LLC exists only to extend on-chain decisions into the off-chain legal and fiat world, without altering the immutability, neutrality, or decentralization of the Olympia Treasury.

Donation Handling and Segregation

The Ethereum Classic DAO LLC MAY receive off-chain donations in fiat or cryptocurrency.
Such donations are optional, external to the protocol, and MUST remain strictly segregated from the protocol-level Olympia Treasury defined in ECIP-1112.

All donations:

• MUST be accounted for separately from protocol-level Treasury funds, both in off-chain accounting and in any on-chain representations.
• SHOULD be routed through on-chain mechanisms when feasible, using the hash-bound execution tuple
  (ecfpId, recipient, amount, metadataCID, chainid)
  for transparency and auditability.
• MUST be spent only via DAO-approved ECFPs if routed through governance.
• MUST be included in public financial reports, regardless of whether the disbursement was routed through governance.

Use of donation funds outside the ECFP process MUST be:

• Optional — donors may choose whether to route donations through on-chain governance.
• Transparent — all off-chain disbursements MUST be publicly reported.
• Governance-neutral — donor funds MUST NOT influence or override on-chain governance decisions.
• Strictly separated — protocol-level Treasury funds and external donations MUST NOT be co-mingled.

Donated funds MUST NOT:

• override or preempt approved ECFPs,
• create preferential or accelerated execution paths,
• introduce discretionary spending authority,
• compromise governance neutrality, or
• alter or weaken Treasury access controls.

All donation handling SHALL be publicly verifiable and governed by a narrow, limited administrative mandate, consistent with ECIP-1113.

Informative Note:
The DAO MAY define a “Donation ECFP” format for donors wishing to align contributions with specific initiatives.
Donation ECFPs MUST follow the same lifecycle, quorum, threshold, and timelock rules as all other Treasury disbursements.

Strategic Donors and Institutional Funders

The ECFP framework — combined with the administrative interface provided by the Ethereum Classic DAO LLC — enables transparent participation by institutional or centralized donors, including:

• centralized exchanges
• mining pools and ASIC manufacturers
• investment trusts and ETF managers
• infrastructure and service providers (RPC, explorers, hosting)
• Web3 venture firms and protocol builders

These entities may support the Ethereum Classic ecosystem without compromising decentralization or governance neutrality.

Key properties that enable institutional participation:

• Legal execution:
  The DAO LLC provides a compliant mechanism to perform off-chain administrative tasks required for fiat-related portions of approved ECFPs.

• Transparent governance:
  All disbursements — whether protocol-level or donor-funded — require on-chain DAO approval and are immutably recorded.

• Auditable funding:
  When routed through the Treasury, donor-funded disbursements use the hash-bound execution tuple
  (ecfpId, recipient, amount, metadataCID, chainid)
  ensuring traceability to the original proposal metadata.

• Optional alignment:
  Donors MAY submit or support Donation ECFPs to earmark contributions for specific workstreams.
  These proposals MUST follow the standard ECFP lifecycle with no preferential treatment.

• No privileged access:
  Institutional donors receive no special rights regarding Treasury access, voting power, or governance influence.

Protocol-Level Donors and Fee Forwarding (Composable DeFi Stack)

Olympia also supports opt-in protocol-level donations from EVM-native applications deployed on Ethereum Classic.
Smart contracts such as DEXs, lending markets, liquid staking systems, stablecoins, or yield platforms MAY voluntarily forward a percentage of fees, rewards, or revenue to the Olympia Treasury (ECIP-1112).

This creates a self-reinforcing public-goods funding loop:

Increased protocol usage → higher fee forwarding → greater Treasury capacity → improved infrastructure → more users and applications

This mechanism mirrors established EVM patterns (e.g., Lido, Balancer, Aura, RocketPool) while preserving Ethereum Classic’s neutrality and opt-in ethos.

Benefits

• Composable, voluntary participation by DeFi protocols
• Transparent on-chain donation flows
• Sustainable infrastructure funding
• Ecosystem-wide positive feedback loop

Governance and Execution Requirements

• Once forwarded to the Treasury, such funds MUST be disbursed only via ECFPs approved through the main DAO.
• All disbursements MUST use the hash-bound execution tuple
  (ecfpId, recipient, amount, metadataCID, chainid)
  defined in ECIP-1112.
• These ECFPs MUST follow the same:
  • quorum
  • approval threshold
  • voting period
  • timelock
  • execution pathway (Governor → Timelock → Executor)
    as all other Treasury allocations.
• Donation sources SHOULD be disclosed by the donating protocol and included in DAO financial reports.
• A standardized Donation ECFP format MAY be used to align donated funds with specific deliverables or KPIs.

This opt-in structure allows decentralized and centralized protocols alike to support the ecosystem without introducing privileged access, governance influence, or Treasury bypasses.

Rationale

The Ethereum Classic Funding Proposal (ECFP) framework completes a four-part architecture that enables sustainable, decentralized protocol funding for Ethereum Classic:

1. ECIP-1111 — Redirects BASEFEE into a protocol-native revenue stream.
2. ECIP-1112 — Deploys an immutable, governance-isolated Treasury to custody that revenue.
3. ECIP-1113 — Establishes Olympia DAO as the sole authorized executor of Treasury disbursements.
4. ECIP-1114 — Defines the standardized, permissionless process for proposing, reviewing, voting on, and executing those disbursements.

Why This Is Necessary

Prior to Olympia, Ethereum Classic funding relied on centralized foundations, corporate sponsors, or informal donor arrangements. These sources were often opaque, inconsistent, or vulnerable to gatekeeping, and could not guarantee stable support for critical public infrastructure such as clients, RPC endpoints, explorers, audits, and developer tooling.

The ECFP process provides a durable replacement by:

• Codifying a transparent, rules-based allocation mechanism for all Treasury funds.
• Using ECIP-1112’s hash-bound execution model
  (ecfpId, recipient, amount, metadataCID, chainid)
  to ensure accountability, integrity, and replay protection.
• Requiring that all spending decisions flow through Olympia DAO as defined in ECIP-1113, subject to quorum, approval thresholds, and timelock safeguards.
• Offering a predictable, reproducible framework for proposers and voters, reducing ambiguity and governance fatigue.
• Preserving upgrade flexibility so governance parameters can evolve without modifying the core funding mechanism.

By separating concerns across four ECIPs — revenue (1111), custody (1112), governance execution (1113), and proposal lifecycle (1114) — the architecture remains modular, auditable, and resilient.

This ensures that Ethereum Classic’s protocol-level funding is:

• Decentralized — no single entity controls fund access.
• Immutable — Treasury disbursement rules cannot be bypassed or altered off-chain.
• Transparent — all proposals, votes, and disbursements are verifiable on-chain.
• Sustainable — funding grows proportionally with network usage, without inflation.

Minimal, Scalable, and Governance-Neutral

The ECFP framework defines a minimal but robust set of rules that scale naturally with ecosystem growth:

• Proposals MAY represent one-time grants, multi-milestone programs, or recurring maintenance budgets.
• The system does not require constant activity or continuous funding.
• Proposal formats and workflows can evolve via governance without modifying the underlying Treasury or execution logic.

This avoids reliance on discretionary or foundation-driven grantmaking and replaces it with transparent, permissionless, rule-based Treasury governance.

The ECFP process integrates directly with the Olympia Treasury (ECIP-1112) and Olympia DAO (ECIP-1113), ensuring that all disbursements are authorized on-chain and executed through the immutable governance pipeline.

Governance-Aligned Funding Infrastructure

The ECFP process formalizes a community-controlled mechanism for allocating protocol-level funds. Compared to prior funding models, it provides:

• Transparency — Every lifecycle event (submission, voting, execution) is recorded on-chain.
• Inclusiveness — Any contributor MAY submit a proposal without prior affiliation, reputation, or political capital.
• Predictability — Standardized proposal structure and lifecycle reduce ambiguity for both proposers and reviewers.
• Upgradeability — The ECFP process is governance-agnostic: it supports modular upgrades to the DAO, voting logic, or templates without altering the ECFP standard itself.

Key Design Objectives

• Clarity and Accountability
  Structured templates, explicit execution parameters, and required deliverables ensure that intent and outcomes remain well-defined and enforceable.

• Transparency and Auditability
  All metadata, voting records, and disbursement events MUST be stored or emitted on-chain to ensure full public verifiability.

• Openness and Meritocracy
  Participation in both proposal creation and voting is permissionless and not gated by token balances, off-chain influence, or privileged membership.

• Governance Modularity
  The ECFP lifecycle is defined independently of any specific voting mechanism or governance token. Future upgrades can adjust governance parameters without altering the funding process or Treasury logic.

• Alignment with Ethereum Classic Principles
  The ECFP process reflects ETC’s core values: immutability, decentralization, credible neutrality, and resistance to centralized capture. It replaces opaque, foundation-based funding with transparent, on-chain, rules-based allocation.

Related Work

The ECFP process aligns Ethereum Classic with established, DAO-governed funding models used across the broader EVM ecosystem.
These systems demonstrate the viability of transparent, on-chain treasury governance, standardized proposal lifecycles, and immutable execution logic.

Examples include:

• Arbitrum (AIP Framework) — Token-holder governance approves treasury disbursements via structured improvement proposals and a standardized review process.
• Optimism (RetroPGF) — A bicameral governance system allocates funds based on demonstrated public goods impact, using transparent evaluation and execution rules.
• Celo Community Fund — A portion of transaction fees routes directly to a community-governed treasury, funding grants through milestone-based oversight.
• Ronin DAO — Redirects EIP-1559 BASEFEE into a DAO-controlled treasury for infrastructure and ecosystem support, paralleling the revenue model defined in ECIP-1111.
• Mantle Governance — Manages a modular, DAO-controlled treasury sourced from sequencer revenue, with delegated authority for domain-specific funding.
• Polygon Funding Councils — Operate delegated, domain-specific treasuries funded by sequencer fees, with structured workflows for proposals and ecosystem grants.

Across these examples, several common design principles emerge:

• Transparent, on-chain governance controls all treasury disbursements.
• Immutable execution paths ensure funds move only through DAO-approved actions.
• Standardized proposal formats and workflows reduce ambiguity and centralization risk.
• Revenue captured at the protocol or sequencer layer provides sustainable funding for public goods.

Olympia applies these proven governance patterns to Ethereum Classic’s Proof-of-Work environment by combining:

• Sustainable, consensus-layer revenue from ECIP-1111
• Immutable, governance-isolated custody via ECIP-1112
• Sole-executor, permissionless governance defined in ECIP-1113
• Standardized, hash-bound proposal execution through ECIP-1114

Implementation

1. Proposal Submission

• Proposal submission is permissionless. Any Ethereum Classic address MAY submit an ECFP via the Olympia DAO interface, subject to governance parameters defined in ECIP-1113 (e.g., delays, thresholds, quorum).
• Optional Sybil-resistance modules (e.g., BrightID, Gitcoin Passport, Proof of Humanity) MAY be adopted by DAO vote.
• A dedicated ECFP submission repository SHALL be maintained at:
  https://github.com/ethereumclassic/ECFPs
• Each ECFP MUST include:
  • Sequential ECFP number
  • Title and rationale
  • Requested funding amount (denominated in ETC / wei)
  • Recipient address
  • Milestone schedule or disbursement structure
  • Off-chain metadata pointer (IPFS CID, Arweave URL, etc.)
    • This value MUST match the metadataCID used in the hash-bound tuple
      (ecfpId, recipient, amount, metadataCID, chainid)
      required by ECIP-1112
• Metadata MUST be:
  • Content-addressed
  • Immutable and verifiable
  • Referenced on-chain via its CID or equivalent digest

• ECFPs SHOULD follow the official Markdown template:
  https://github.com/ethereumclassic/ECFPs/blob/main/ecfp-template.md

• ECFPs MAY include supplemental materials:
  • GitHub repositories
  • Technical specifications
  • Mockups / diagrams
  • Community endorsements

// Illustrative, non-normative ECFP submission example.
// This registry records funding proposals and derives the hash-bound
// payoutId required by the Olympia Treasury (ECIP-1112) for execution.
//
// The registry DOES NOT:
// - enforce proposal quality,
// - validate deliverables,
// - perform governance actions,
// - or interact with the Treasury directly.
//
// It simply binds proposal parameters to a deterministic payoutId so
// that the Olympia Governor → Timelock → Executor flow (ECIP-1113)
// can later authorize a Treasury disbursement using the same hash.
pragma solidity ^0.8.20;

contract ECFPRegistry {
    struct Proposal {
        uint256 id;
        address recipient;
        uint256 amount;
        string metadataCID;   // SHOULD reference immutable off-chain metadata (IPFS/Arweave)
        bytes32 payoutId;     // Hash-bound identifier used during Treasury execution
    }

    mapping(uint256 => Proposal) public proposals;

    event ProposalSubmitted(
        uint256 indexed ecfpId,
        address indexed recipient,
        uint256 amount,
        string metadataCID,
        bytes32 payoutId
    );

    /// @notice Submits a new Ethereum Classic Funding Proposal (ECFP).
    /// Any address MAY submit. Domain-specific policy (KYC, membership,
    /// rate limits, etc.) must be enforced outside this minimal example.
    function submitECFP(
        uint256 ecfpId,
        address recipient,
        uint256 amount,
        string calldata metadataCID
    ) external {
        require(recipient != address(0), "ECFPRegistry: invalid recipient");
        require(amount > 0, "ECFPRegistry: amount required");

        // The deterministic payoutId that the Treasury (ECIP-1112) will verify.
        bytes32 payoutId = keccak256(
            abi.encodePacked(
                ecfpId,
                recipient,
                amount,
                metadataCID,
                block.chainid
            )
        );

        proposals[ecfpId] = Proposal({
            id: ecfpId,
            recipient: recipient,
            amount: amount,
            metadataCID: metadataCID,
            payoutId: payoutId
        });

        emit ProposalSubmitted(
            ecfpId,
            recipient,
            amount,
            metadataCID,
            payoutId
        );
    }
}

To ensure consistent hash derivation across on-chain contracts, scripts, wallets, indexers, and governance dashboards, implementations SHOULD use the canonical encoding for the ECFP payout identifier. The library below illustrates the exact tuple and encoding order used to derive payoutId from (ecfpId, recipient, amount, metadataCID, chainid) as required by ECIP-1112. Off-chain clients MUST replicate this logic exactly.

// Illustrative, non-normative helper for deriving the hash-bound payoutId
// used by the Olympia Treasury (ECIP-1112).
//
// Off-chain tooling (scripts, dashboards, wallets) MUST replicate this exact
// encoding, ordering, and type layout when computing payoutId:
//
// payoutId = keccak256(abi.encodePacked(
//     ecfpId,
//     recipient,
//     amount,
//     metadataCID,
//     chainId
// ))
pragma solidity ^0.8.20;

library ECFPHash {
    /// @notice Computes the deterministic payoutId for an Ethereum Classic
    /// Funding Proposal (ECFP), given the proposal parameters and chainId.
    /// @dev On-chain contracts MAY use block.chainid when calling this;
    ///      off-chain tools MUST pass the correct chainId explicitly.
    function computePayoutId(
        uint256 ecfpId,
        address recipient,
        uint256 amount,
        string memory metadataCID,
        uint256 chainId
    ) internal pure returns (bytes32) {
        return keccak256(
            abi.encodePacked(
                ecfpId,
                recipient,
                amount,
                metadataCID,
                chainId
            )
        );
    }
}

2. On-Chain Registry and Governance

The Olympia DAO smart contracts SHALL maintain an ECFP registry storing:

• Submission timestamp
• Proposer address
• Derived hash-bound identifier
• Voting results
• Final lifecycle state (Draft, Active, Approved, Rejected, Executed, Expired)

Governance contracts MUST:

• Enforce voting delays, voting periods, thresholds, and quorum
• Capture voting power using snapshot blocks to prevent manipulation after activation
• Emit standardized events (e.g., ProposalSubmitted, ProposalActivated, ProposalExecuted) for indexing
• Forward all execution payloads through the Governor → Timelock → Executor pipeline as required by ECIP-1113

3. Execution and Disbursement

• After approval and timelock maturity, the DAO’s sole authorized Executor SHALL trigger a Treasury disbursement.
• Execution occurs by forwarding an opaque {targets, values, calldatas} payload to the Treasury, as defined in ECIP-1113.
• All disbursements MUST use the hash-bound execution model defined in ECIP-1112: (ecfpId, recipient, amount, metadataCID, chainid)
• Execution MUST bind:
  • recipient
  • amount
  • metadataCID
    exactly as provided in the proposal submission.
• The Treasury and Executor SHOULD emit standardized ProposalExecuted events containing:
  • ECFP ID
  • Hash-bound identifier
  • Recipient
  • Amount
  • Timestamp
• Disbursement patterns MAY include:
  • One-time transfers
  • Milestone-based disbursements
  • Recurring operational budgets via multiple ECFPs
  • Escrow-based or stream-based payout contracts

The example below illustrates the final step of the Olympia execution pipeline, where the Executor forwards a governance-approved disbursement to the Treasury (ECIP-1112). The Executor does not derive payoutId, does not validate metadata, and does not issue any funds itself. These responsibilities are enforced respectively by ECIP-1114 (proposal registry), ECIP-1113 (governance), and ECIP-1112 (Treasury). This example clarifies only the expected call surface during execution.

// Illustrative, non-normative executor → treasury example.
// This snippet demonstrates ONLY the final call surface used when the
// Olympia Governor → Timelock → Executor pipeline (ECIP-1113) authorizes
// the release of funds from the Olympia Treasury (ECIP-1112).
//
// The Executor does not compute hashes, evaluate proposals, or store
// registry state. It simply forwards the calldata that the Treasury
// expects, including the hash-bound payoutId derived during submission.
//
// The Treasury will independently verify:
// - that payoutId matches the stored parameters,
// - that the call comes from the authorized Executor,
// - and that the disbursement has not already been completed.
pragma solidity ^0.8.20;

interface IOlympiaTreasury {
    function release(
        bytes32 payoutId,
        address recipient,
        uint256 amount
    ) external;
}

contract OlympiaExecutor {
    IOlympiaTreasury public immutable treasury;

    event TreasuryCallExecuted(
        bytes32 indexed payoutId,
        address indexed recipient,
        uint256 amount
    );

    constructor(IOlympiaTreasury _treasury) {
        require(address(_treasury) != address(0), "Executor: treasury required");
        treasury = _treasury;
    }

    /// @notice Final step of the governance pipeline.
    /// This function is called by the Timelock once a proposal has passed
    /// all governance checks defined in ECIP-1113.
    function executeTreasuryPayout(
        bytes32 payoutId,
        address recipient,
        uint256 amount
    ) external {
        require(recipient != address(0), "Executor: invalid recipient");
        require(amount > 0, "Executor: amount required");

        treasury.release(payoutId, recipient, amount);

        emit TreasuryCallExecuted(payoutId, recipient, amount);
    }
}

4. Transparency Dashboard

A public-facing dashboard SHALL provide:

• Active, approved, rejected, and executed proposal lists
• DAO voting outcomes and participation metrics
• Treasury balances and disbursement history

The dashboard MUST:

• Be open-source
• Mirror on-chain state verifiably
• Use standardized DAO and Treasury events for indexing

5. Community Review and Deliberation

• Proposals SHOULD undergo informal discussion prior to activation.
• Recommended venues include:
  • GitHub discussion threads
  • Ethereum Classic Discord
  • The ECIP discussion forum
• Community moderators MAY assist with formatting or technical feedback.
• Moderators SHALL NOT possess authority to approve, veto, or gate proposals.

Testing and Mainnet Rollout

• All governance and Treasury contracts SHALL be deployed and tested first on the Mordor Testnet.
• Mainnet activation SHALL require:
  • Successful simulation of the full ECFP lifecycle
  • Successful simulation of hash-bound execution
  • Community review
  • Independent third-party audits

Backwards Compatibility

The Ethereum Classic Funding Proposal (ECFP) process is implemented entirely at the application layer through smart contracts.
It introduces no changes to consensus rules, fork choice, block structure, transaction formats, opcode behavior, or EVM semantics.
As a result, ECIP-1114 is fully backward-compatible with all existing wallets, tooling, and deployed contracts.

Compatibility Notes

• No Consensus-Layer Modifications
  ECIP-1114 does not alter block validation, gas accounting, transaction encoding, or any consensus-critical rules.
  Nodes that upgrade to support the Olympia governance suite remain in full consensus with the network.

• Voluntary Participation
  Participation in ECFP governance is optional.
  Nodes, miners, and users are not required to submit proposals or vote in order to remain in consensus.

• Application-Layer Isolation
  ECFP logic is confined to governance contracts and does not interfere with unrelated smart contracts or dApps.
  All pre-existing contracts continue to function without modification.

• Client Compatibility
  • Clients implementing ECIP-1111, ECIP-1112, ECIP-1113, and ECIP-1114 will remain in consensus and be capable of participating fully in Olympia governance.
  • Clients that do not implement ECIP-1111 will diverge from the canonical chain at the activation block, as BASEFEE redirection is a consensus-layer change.
  • Clients implementing ECIP-1111 and ECIP-1112, but not ECIP-1113/1114, remain in consensus but cannot submit, vote on, or execute governance actions; they simply validate them as ordinary transactions.
• Treasury Execution Requirements
  To construct and broadcast valid Treasury disbursement transactions, a client MUST support:
  • the immutable Olympia Treasury contract (ECIP-1112),
  • the Governor → Timelock → Executor architecture (ECIP-1113), and
  • the hash-bound execution tuple
    (ecfpId, recipient, amount, metadataCID, chainid)
    required for Treasury release validation under ECIP-1112.
    Clients lacking these components may still observe governance transactions but cannot originate or process them meaningfully.
• State and Data Integrity
  All proposal metadata, voting records, and execution events are stored in governance-layer contract storage.
  No historical blockchain state is altered, and no migration or pruning of existing state is required.

By isolating governance logic from protocol consensus, the ECFP framework integrates cleanly with the Ethereum Classic stack while preserving base-layer stability, determinism, and long-term security.

Security Considerations

Although ECIP-1114 introduces no changes to Ethereum Classic’s consensus or EVM semantics, it defines a critical application-layer mechanism for allocating protocol-level funds.
The security of the ECFP lifecycle depends on the correctness, immutability, and isolation of the Treasury (ECIP-1112) and governance framework (ECIP-1113).

The following categories summarize the required security properties and safeguards.

1. Metadata and Proposal Integrity

The hash-bound execution identifier derived from
(ecfpId, recipient, amount, metadataCID, chainid)
serves as the binding link between the on-chain proposal and its off-chain metadata.
This ensures disbursements cannot be altered, replayed, or redirected without invalidating the hash.

All ECFPs MUST:

• Embed a verifiable content hash (IPFS CID, Arweave digest, etc.).
• Store metadata immutably in a content-addressed system.
• Use globally unique ecfpId values.
• Include chainid (and optionally domain separators) for replay protection across forks or testnets.

// --- PROPOSAL HASH PLACEHOLDER ---
// An illustrative metadata hash generation example will be inserted here.
// It will match the hash structure used by submitECFP(), ensuring that:
// - off-chain metadataCID
// - recipient, amount
// - ecfpId and chainid
// produce a deterministic payoutId for Treasury validation.

// Off-chain: Generate ECFP proposal hash for on-chain binding
// This must match the exact structure used in submitECFP()
// and be calculated prior to DAO voting for proposal integrity.
bytes32 proposalHash = keccak256(
    abi.encodePacked(
        ecfpId,        // Unique proposal ID (e.g., 0042)
        recipient,     // Destination address
        amount,        // Funding amount in wei
        metadataCID,   // Content hash from IPFS or Arweave
        block.chainid  // Replay protection domain
    )
);

Additional Integrity Requirements:

• Content-Addressed Metadata
  Prevents retroactive edits or hidden changes.

• Immutable References
  Voters MUST be able to confirm that metadata has not changed after submission.

• Replay Protection
  The chain ID MUST be part of the encoded hash to prevent cross-network execution.

2. Treasury and DAO Contract Safeguards

• Execution Logic Isolation
  The Treasury SHALL NOT parse proposal metadata.
  It validates only the hash-bound tuple and releases funds exclusively in response to calls from the authorized DAO Executor.

• Strict Call Permissions
  The Treasury MUST reject all calls from EOAs or unauthorized contracts.

• Deterministic Execution Path
  All disbursements MUST follow the immutable execution rules defined in ECIP-1112, with no arbitrary logic or branching.

• Immutable Lifecycle States
  Once an ECFP enters Active, its parameters MUST NOT change.

• Event Logging
  DAO and Treasury contracts SHOULD emit standardized events to support independent indexing and audit tools.

3. Governance Process Risks

• Governance Capture
  Mitigated through quorum thresholds, timelock delays, optional delegated or reputation-based mechanisms, and transparent upgrade paths.

• Replay Defense
  Governance payloads MUST include domain separation and unique proposal identifiers.

• Safe Governance Upgrades
  Any upgrade to the DAO MUST:

  • Be proposed and approved on-chain
  • Undergo third-party audits
  • Be subject to timelock enforcement
  • NOT alter Treasury immutability

4. Execution and Client Consistency Risks

• Client Validation
  Clients MUST verify that execution payloads match approved governance decisions.
  This prevents inconsistent local state or misinterpretation of Treasury calls.

• Reentrancy and Logic Review
  The Treasury and governance contracts MUST undergo extensive security review, including:
  • static analysis
  • fuzzing
  • formal verification (where possible)
  • third-party audits
• Proposal Manipulation Prevention
  Achieved through:
  • immutable metadata hashing
  • minimum draft review periods
  • off-chain discussion and community oversight
• Funding Accountability
  Milestone-based or vesting-based disbursements SHOULD be used for large or long-term proposals.

// --- EXECUTION PLACEHOLDER ---
// An illustrative Treasury execution snippet will be inserted here.
// It will demonstrate the required call forwarding from the DAO Executor
// using {targets, values, calldatas} and the hash-bound payoutId.
// This block will be filled in during the code example pass.

5. Spam Resistance and Participation Gating

• Sybil Attack Mitigation
  The DAO MAY adopt optional, permissionless sybil-resistance modules such as:
  • refundable deposits
  • submission cooldowns
  • decentralized identity attestations
• Preservation of Permissionlessness
  Any gating mechanism MUST remain:
  • modular
  • governance-controlled
  • non-discretionary
  • free of centralized approval or gatekeeper authority

Security Considerations Summary

ECIP-1114 establishes a transparent, hashed, and governance-controlled framework for protocol-level funding.
Security properties derive from:

• immutable metadata and content-addressed references
• hash-bound execution with replay protection
• strict Treasury call permissions (ECIP-1112)
• mandatory governance flow through Governor → Timelock → Executor (ECIP-1113)
• standardized event logging and auditable state transitions
• formal review, testnet deployment, and independent audits

All components MUST be deployed to the Mordor Testnet for full lifecycle simulation and reviewed publicly prior to mainnet activation.

Related ECIPs in the Olympia Upgrade

ECIP-1114 is one component of a coordinated four-ECIP architecture that introduces sustainable, decentralized, and transparent protocol-level funding to Ethereum Classic. Each ECIP addresses a distinct layer of the system and is designed to operate independently while forming a cohesive whole.

• ECIP-1111 — Olympia EVM and Protocol Upgrades
  Introduces EIP-1559 and EIP-3198 to Ethereum Classic and redirects BASEFEE to the Treasury instead of burning it, creating a protocol-native revenue stream.

• ECIP-1112 — Olympia Treasury Contract
  Specifies the immutable, governance-isolated Treasury contract that receives BASEFEE revenue and enforces hash-bound, deterministic disbursement rules.

• ECIP-1113 — Olympia DAO Governance Framework
  Defines the decentralized governance architecture and the sole authorized execution path (Governor → Timelock → Executor) for Treasury withdrawals.

• ECIP-1114 — Ethereum Classic Funding Proposal Process
  Establishes the standardized, permissionless ECFP format for requesting Treasury funds, including metadata requirements, lifecycle states, and hash-bound execution parameters.

Interdependency Summary

• ECIP-1111 — Creates the protocol-level funding source (BASEFEE redirection).
• ECIP-1112 — Provides immutable custody and enforcement of hash-bound disbursement rules.
• ECIP-1113 — Establishes the governance executor that authorizes disbursements.
• ECIP-1114 — Defines the proposal lifecycle and metadata standards required for all disbursements.

These ECIPs are designed for modular activation:

• ECIP-1111 + ECIP-1112 may be activated first to begin accumulating Treasury revenue.
• ECIP-1113 + ECIP-1114 may be deployed subsequently to enable full on-chain governance, voting, and controlled Treasury execution.

Together, ECIP-1111 through ECIP-1114 form a complete, modular, and upgradeable funding framework for Ethereum Classic.

Copyright

Copyright and related rights waived via
CC0

Appendix: EVM Precedents for Funding Proposal Processes

The Ethereum Classic Funding Proposal (ECFP) framework in ECIP-1114 draws on established patterns from other EVM-governed treasuries. These examples demonstrate that transparent, standardized, and on-chain managed funding processes can scale to large communities and significant treasury sizes while maintaining decentralization and auditability.

Funding Process Precedents

Observations

• Structured Lifecycles
  Most ecosystems employ multistage proposal processes with review, signaling, and execution phases.
  ECFP reflects this with its Draft → Active → Approved → Executed states.

• Community Review Before Voting
  Nearly all systems incorporate pre-vote discussion.
  ECFP includes an optional draft period to encourage early feedback and reduce governance errors.

• On-Chain Finality
  Every listed system culminates in a binding on-chain action—similar to ECFP’s requirement that Treasury withdrawals must pass through the hash-bound execution model
  (ecfpId, recipient, amount, metadataCID, chainid).

• Sybil Resistance & Submission Protection
  Many ecosystems employ stake deposits, identity attestations, or rate limits to reduce spam.
  ECFP includes these mechanisms as optional, governance-controlled modules.

• Milestone & Impact-Based Funding
  Several treasuries allocate funds in tranches or based on completed deliverables.
  ECFP natively supports milestone-based or multi-phase funding structures.

By adapting these proven patterns to Ethereum Classic’s design principles—immutability, decentralization, credible neutrality—ECIP-1114 delivers a funding process that is both compatible with established EVM governance practices and purpose-built for ETC’s long-term sustainability.