ERC-EMBER: A Funding Contract Standard for Close Source-to-Open Source Software

ERCs
1

I’m looking for technical feedback on ERC-EMBER, a draft Ethereum Funding Contract standard for software projects.

Public repo:

ERC-EMBER defines a tokenized funding lifecycle for software:

  1. A developer deploys a fixed-supply access token.
  2. Users buy tokens with a stablecoin.
  3. The app burns tokens as users consume the product.
  4. Developer funds vest with real usage.
  5. When the burn/release threshold is reached, the developer reveals committed source code.
  6. If holders remain, they redeem from a snapshotted redemption pool instead of being confiscated.
  7. The contract closes; no perpetual payment stream remains.

The core goal is to fund software without defaulting to subscriptions, VC-style incentives, or indefinite rent extraction.

What Is Standardized

The neutral core covers:

  • ERC-20 access-token behavior
  • ERC-165 detection
  • burn-on-use accounting
  • source commitment and key reveal
  • release/slash terminal states
  • quorum release with holder redemption
  • solvency-preserving redemption accounting

The core standard is fee-free and stablecoin-decimal neutral.

Reference Implementation

The repo includes a Solidity/Foundry reference implementation:

  • EmberCore: neutral reference implementation
  • IEmber: core interface
  • IEmberRecovery: optional recovery extension
  • EmberFactory: non-normative deployment/product layer
  • MaintenancePool: optional timelocked maintenance funding pool

Current verification:

  • 47 Foundry tests passing
  • CI runs fmt/build/test/contract-size checks
  • EmberFactory is under EIP-170
  • forge coverage --ir-minimum: 86.22% line coverage

Economic Disclosure

The standard itself does not require protocol fees.

The optional reference factory has disclosed product economics:

  • factory-created contracts route a 1.3% primary-sale fee to the configured standard-author address;
  • this fee is not perpetual and stops when the contract closes;
  • optional abandoned-capital recovery can sweep only idle recoverable capital outside holder redemption reserves;
  • recovered idle capital routes 90% to a treasury for startup/software ecosystem initiatives and 10% to the standard-author / commission-recipient address.

Direct EmberCore deployments can avoid the factory fee and disable recovery.

Feedback Requested

I’m especially looking for review on:

  • whether this belongs as an EFC/ERC-style standard;
  • whether quorum redemption is the right non-confiscatory answer to deadlock;
  • whether the source commitment/reveal model is strong enough;
  • whether abandoned-capital recovery should exist as an optional extension;
  • whether factory-level product economics are cleanly separated from neutral conformance;
  • whether the maintenance-pool timelock model is reasonable as optional companion infrastructure.

Thank you all in advance for your time.