DustEthic Whitepaper - Relayers

French version: Le Livre Blanc DustEthic - Relayeurs

Version: 1.1-draft
Date: 2025-12-10
Last updated: [2025-12-10]

Working draft - conceptual only. This is not legal or financial advice. DustEthic is, at this stage, a design proposal, not a live system.

This section of the whitepaper describes the role of relayers in the DustEthic ecosystem, the commission models being considered, technical integration options, and some high-level examples of potential revenues.

DustEthic relayers are inspired by existing building blocks of Account Abstraction on Ethereum and L2s (ERC-4337, EntryPoint, UserOperations, bundlers, paymasters), and by ongoing work around EIP-7702 which allows externally owned accounts to temporarily benefit from smart-account-like functionality.

Main goals:

• Make dust donations simple for end users.
• Optimize gas costs through specialized relayers.
• Offer NGOs traceable and auditable donation flows.
• Provide a viable business model for operators, without speculative tokens or yield promises.

“Dust” refers to small residual balances that are usually too low to be moved economically because of gas or withdrawal fees. DustEthic’s idea is to transform these dormant amounts into aggregated micro-donations for partner NGOs.

Key challenge: the fixed cost of an on-chain transaction remains significant even for very small amounts, which makes aggregation and gas optimization essential.

A DustEthic relayer is a technical operator that:

• Receives donation intents from DustEthic-compatible wallets.
• Aggregates these intents (bundling) to reduce average cost per donation.
• Submits transactions on-chain, paying gas on behalf of users (directly or via a paymaster).
• Gets reimbursed for gas and commission through a DustEthic contract and the donation flows.
• Publishes verifiable execution proofs for donors and NGOs.

In the proposed architecture, the relayer is a replaceable component. Multiple relayers can coexist and compete (fees, SLAs, supported networks, etc.).

The DustEthic relayer architecture is inspired by:

• ERC-4337: UserOperations, EntryPoint, bundlers and paymasters to implement Account Abstraction on top of the base protocol.
• EIP-7702: “setCode”-style transactions allowing an EOA to temporarily behave like a smart account during a transaction.
• Existing AA relayer infrastructures (Gelato, Biconomy, etc.) that already provide gasless and paymaster services on several networks.

DustEthic does not reinvent these building blocks. It proposes a donation-oriented standardization layer on top.

Simplified scenario:

1. The user opens a DustEthic-compatible wallet and sees their eligible dust balances (by network and token).
2. They configure a donation (for example “donate all my USDC dust on this L2 to NGO X”).
3. The wallet constructs a UserOperation or meta-transaction containing:
   1. The dust transfer instructions.
   2. DustEthic metadata (NGO, campaign, tags).
4. The DustEthic relayer receives and validates the request, then batches multiple operations into a bundle when it makes economic sense, and submits it through a DustEthic contract.
5. The DustEthic contract moves funds from donors’ accounts to a DustEthic collection address for the NGO and logs the data needed for transparency.
6. Periodically or after a threshold is reached, the contract forwards aggregated funds to the NGO (an address controlled by the NGO).

A DustEthic relayer can be decomposed into several layers:

• Layer 1 - “AA / Relay”: ERC-4337 bundler and paymaster, or equivalent, possibly operated by a third-party provider.
• Layer 2 - “DustEthic Core”: dust-donation logic (contracts, aggregation rules, limits, logs).
• Layer 3 - “API and wallet / NGO integration”: wallet endpoints, NGO dashboards and exports, monitoring.

For a given period (for example one month):

• V: total donation volume processed by a relayer (in USD equivalent).
• c: global commission rate (for example 0.5 % to 3 % of volume).
• G: total gas costs paid by the relayer over the period.
• C_infra: infrastructure and operational costs (servers, audits, support).
• R_net: relayer’s net revenue.

Generic formula:

• R_net = V × c - G - C_infra

Principle:

• For each donation, a percentage of the amount is taken to remunerate the relayer (and optionally a share for DustEthic Core).

Example:

• c = 1 % of the donated amount.
• The user sees: “You donate 1.00, of which 0.99 goes to the NGO and 0.01 to DustEthic infrastructure.”

Pros:

• Direct alignment between donation volume and revenue.
• Simple to understand.

Cons:

• Some donors may be sensitive to “fees on donations”.
• Requires clear and honest communication.

Principle:

• The NGO accepts that each DustEthic donation is credited net of fees.
• The user sees “You donate 1.00 to NGO X”, and the NGO receives for example 0.99.

Pros:

• Very simple donor experience.
• Similar to many existing PSP and donation-platform models.

Cons:

• NGOs care about overall fee levels.
• Must be justified by incremental donation flows.

Principle:

• Commission is shared between donor and NGO, for example:
  • 0.5 % on the donor side.
  • 0.5 % on the NGO side.

Principle:

• Wallets or platforms pay a subscription or buy “credits” from a DustEthic relayer for an included transaction volume.

Pros:

• Aligned with SaaS-like models used by some AA providers.
• Predictable costs for wallet partners.

Cons:

• Requires commercial agreements.
• May limit DustEthic to actors with sufficient scale.

A single DustEthic ecosystem can allow multiple models to coexist, for example:

• Default: NGO-side commission with a fee cap.
• For some premium wallets: B2B coverage of fees.
• For specific campaigns: reduced or zero commission (sponsored by a third party).

These scenarios are illustrative and do not constitute revenue promises.

Assume:

• Scenario A - low volume: V = 50,000 USD per month.
• Scenario B - mid volume: V = 500,000 USD per month.
• Scenario C - high volume: V = 5,000,000 USD per month.
• Commission rate: c = 1 %.
• Costs (gas + infra) represent 30 % of gross commission.

• Scenario A: gross commission 500, R_net ≈ 350.
• Scenario B: gross commission 5,000, R_net ≈ 3,500.
• Scenario C: gross commission 50,000, R_net ≈ 35,000.

Key factors:

• Target networks (cheap L2s vs congested L1).
• Aggregation strategy (minimum threshold per bundle).
• Throttling policy to avoid one-by-one tiny donations.

Conclusion: in practice, DustEthic relayers will likely prioritize L2s for most dust flows.

• Show eligible dust and the fee model.
• Use a DustEthic metadata schema to build donation operations.
• Explicitly reference the chosen relayer (or list of possible relayers).

• Dashboard for received amounts by campaign, token, network.
• Transaction list with on-chain hashes.
• CSV and API exports to internal tools.
• Cash-out management (crypto / fiat) via partners.

• DustEthic relayer directly operated by an AA provider.
• Or a DustEthic layer on top of several providers (routing, log normalization, unified UX).

• DustEthic contracts should be open source.
• “DustEthic - Relayers Standard” should be published and versioned.

• Each flow should be traceable: hash, amount, network, relayer, NGO.
• Public endpoints to verify donations from a DustEthic identifier.
• Aggregated reports for NGOs and, to some extent, for the public.

• Use smart accounts or multi-sig for operator accounts.
• Limits per operation, per campaign, per period.
• Pause mechanisms in case of anomalies.

• Economic viability depends heavily on global volume.
• Regulatory constraints (payments, intermediation, KYC/AML).
• Tension between maximum transparency and donor/NGO privacy.
• Fast evolution of AA and L2s imposes an evolving standard.

• Phase 0: internal prototype (1 relayer, 1-2 L2s, 1-2 pilot NGOs).
• Phase 1: public “DustEthic - Relayers Standard v1”.
• Phase 2: multi-relayer ecosystem, listing criteria, wallet-side choice.
• Phase 3: public relayer marketplace and broader governance.

These external sources do not define DustEthic but describe the technical building blocks that inspire this design.

• ERC-4337 - Account Abstraction: UserOperation, EntryPoint, bundlers, paymasters - official specification and technical overviews.
• OpenZeppelin “Account Abstraction” documentation.
• ERC-4337 overviews (Etherscan, Stackup, etc.).
• Articles and guides on paymasters and gasless transactions (Alchemy, GoldRush, Biconomy, etc.).
• Articles and documentation on EIP-7702 and the Pectra upgrade (Consensys, Alchemy, Circle, QuickNode, etc.).
• Biconomy docs on Account Abstraction, smart accounts and paymasters.
• Gelato Relay documentation and blog posts.
• General blog posts and tutorials about gasless transactions, meta-transactions and AA provider business models.