ERC-8378: Parametric Token

ERCs
, , ,
1

Hi everyone,

DeFi today faces a trade‑off: you can have liquidity, or you can have utility. Tokens that are highly liquid (like ERC‑20) carry no state - they are just balances. Tokens that carry state (like ERC‑721 or ERC‑1155) fragment liquidity because each variant is a separate class. Respectively, agents and structured products cannot easily build on either without choosing between the two.

I’d like to propose a new ERC-20 compatible solution: Parametric Token. It keeps tokens fungible while allowing each account to hold its own set of parameters. The parameter travels with the token, updates deterministically on transfer, and can be mutable or immutable.

The idea

A Parametric Token is an ERC‑20 with extra data attached to each balance. Think of it as a token with state that deterministically mutates with every transfer: a prediction price, a mint time, a trust score, or a bundle ratio. When a token is minted, you either set the values or get automatic initialization. Once you transfer the token, the parameters update according to their respective pure functions (e.g., weighted average, max, or advanced formulas). Neither recipient nor any special contract (engine) decides on the final parameters state - it’s processed automatically by the token contract.

This is not a new token class: it is a new property of fungible ERC-20 tokens.

If there is a variety of the same token, then how to manage it properly? For this, the standard suggests a sub-accounts structure: you CAN convert your account into a Super account with multiple sub-accounts to be able to process the same token with different parameters using the same wallet address.

In addition to sub-accounts, the standard:

  • divides allowances into Specific (used by a particular sub-account) and General (used by the rest of sub-accounts) allowances
  • introduces non-zero-sum transfers (when creditAmount != debitAmount) - they must implement an optional interface for proper balance accounting.

How it can be used:

  • Liquidity consolidation. Tokens with different parameters trade in the same pool (e.g. scalar price predictions). No necessity for fragmentation - just mint the token with price you believe in (expected BTC price as of Aug 20 will be $75400) and trade it in a single liquidity pool.

  • Velocity control. You can design tokens that effectively controls turnover (age‑based fees, tenure rewards). Construct your rewards/fees in the way you’d like to encourage/discourage token holding.

  • Advanced derivatives. Containerize value the way you prefer, with parameter‑based weights working out‑of‑the‑box.

  • Agentic systems. Pure, deterministic mutations and sub‑account isolation make parametric token a natural primitive for autonomous agents. Agents can encode reputation, trust, or strategy directly in the token state, which is preserved by the token contract.

Links:

ERC draft:
:link: https://github.com/K2eno/parametric-token/blob/main/ERCS/erc-8378.md

Implementations (prediction, tenure and bundle tokens):
:link: https://github.com/K2eno/parametric-token

PR:
:link: https://github.com/ethereum/ERCs/pull/1937

Open questions:

I would especially appreciate feedback on these points:

  1. Gas cost. The parameter mutation logic adds gas overhead per every transaction (mint/transfer/burn). In practice, for a few (1‑3) parameters, it looks acceptable. Should we make extra effort to reduce the cost?

  2. Parameter limits. uint64 is flexible, but is a fixed‑length array (uint8 NUMBER_OF_PARAMETERS) the right choice?

  3. Sub‑account deletion. There is no way to return back from Super account to Normal account; there is no way to delete a sub‑account - the owner can leave it empty, but the index remains. Are these limitations, or are they acceptable given the bounded nature of use cases?

  4. NZS detection. The optional NZS extension uses ERC‑165. Is that sufficient for indexers and wallets to reliably detect non‑zero‑sum behaviour?

  5. Engine integration. The reference implementations use an external engine for mint/burn, but the token itself does not enforce economic safeguards (collateral, caps, etc.). Should the standard recommend a specific pattern for these (like inbound allowances), or is it better left to integrators?

Any other questions or comments are welcome. I’ll open a PR shortly. Feedback is appreciated, particularly from anyone who has worked on prediction markets, RWA tokens, or agentic systems.

Thanks for reading.

Alexander Zvezdin (@k2eno)

2

@K2eno , I’m trying to make sure I understand the model correctly before getting into the implementation details.

My reading is that the proposal keeps the ERC-20 balance as the fungible accounting layer, but associates an additional parameter state with that balance.

For a Normal account, that looks roughly like:

account balance parameters
Alice 100 A
Bob 50 B

When Alice transfers some balance to Bob, the token contract determines Bob’s resulting parameter state according to the token-specific mutation function.

So for a mutable parameter, conceptually:

(Bob's current balance + params) + (incoming balance + params) → new balance + new params

while an immutable parameter instead prevents balances with incompatible parameter values from being merged.

And if an address needs to preserve several parameter states separately, it can become a Super account:

address sub-account balance parameters
Alice 0 20 A
Alice 1 80 B

with balanceOf(Alice) = 100, while the parametric interface can address each partition separately.

If that is the intended abstraction, I had two questions about where the ERC-20 boundary sits.

First, how should ERC-20 compatibility be understood once an account becomes Super?

The draft says that balanceOf(account) returns the aggregate balance across the sub-accounts, while standard transfer() is equivalent to transferring from sub-account 0.

Using the example above:

balanceOf(Alice) = 100

but sub-account 0 contains only 20.

Would a standard:

transfer(Bob, 100)

therefore revert even though an ERC-20 caller observes a balance of 100?

If so, would it make sense for the specification to distinguish between ERC-20 interface compatibility and ERC-20 spendability semantics?

I’m thinking here about a wallet or protocol that only knows ERC-20 and assumes that balanceOf(account) describes the amount that can be transferred through the standard transfer interface.

Second, I’m wondering about the guarantees expected from mutable parameter functions.

The draft requires mutation to be deterministic. But can the resulting parameter state intentionally depend on the order or partitioning of transfers?

For example:

combine(combine(A, B), C)

versus

combine(A, combine(B, C))

Do compliant implementations need those to produce the same parameter state, or is path-dependent state intentionally allowed?

I can see cases where weighted aggregation or max naturally gives order-independent results, while other deterministic functions may not.

If path dependence is allowed, perhaps it is simply part of the application-defined parameter semantics. If it is not intended, there may be an additional property of mutation functions that needs to be specified beyond determinism.

So I think the part I’m still trying to locate is the boundary between:

properties standardized by Parametric Token

and

properties defined by the particular parameter system.

Is that roughly the intended separation?

1 Like
3

Hi! Thanks for the careful and precise reading – your summary of Normal/Super accounts is precisely right. And yes, transfer(Bob, 100) must revert because it has to be equivalent to parametricTransfer(0, Bob, 0, 100) while Alice’s sub-account 0 doesn’t have enough funds. The standard does not guarantee that balanceOf reflects the amount spendable via transfer for Super accounts - this is an intentional trade-off.

Your question makes me think about a proper warning in Security Considerations, like:
"For Super accounts, balanceOf(account) returns the aggregate balance, but transfer always uses sub‑account 0. Integrators should not assume that balanceOf is spendable via transfer for Super accounts."

From a user perspective, if transactions require full compatibility with existing wallets, they have to use either Normal account or Super account with a single sub-account. Then spending and allowance behaviour won’t need any adjustments.

As for path-dependency, the standard intentionally distances from application/economics. The goal is to (a) create rails for parametrization with a very limited minimal set of must-do rules and (b) ensure unambiguous reproducibility of every change in (balance,parameters) state.

For this reason implementers have every freedom for underlying economics, including associativity/commutativity patterns. The standard has to be equally applicable to path-agnostic and path-dependent mutations. The actual meaning of parameters, the mutation formulas, and whether they are order‑dependent are outside the scope of the standard and left to the implementer.

We focus on data structure, reasonable gas efficiency, and robust sub-accounts/allowance logic.

Thank you again for the thoughtful review – it helps sharpen the proposal.

4

Small correction:

Super account with MULTIPLE sub-accounts won’t need any adjustments in terms of spending if only sub-account 0 has a non-zero balance AND Specific allowance is set to 0. It’s a part of this standard requirements.

5

I think the Super-account behavior creates an important compatibility issue for ordinary ERC-20 wallets.

If balanceOf(account) returns 100, but only 20 is held in sub-account 0, a standard wallet may:

  • display 100 as available;

  • enable a “Max” transfer of 100;

  • estimate or simulate the transaction using normal ERC-20 assumptions;

  • then have transfer(..., 100) revert.

A warning in Security Considerations documents the issue for integrators, but it does not give wallets a reliable way to handle it.

Would it be useful for the standard to expose:

  1. A machine-readable way to detect whether an address is operating as a Super account.

  2. A canonical view returning the amount spendable through standard transfer().

  3. An explicit interface or capability signal indicating that balanceOf does not necessarily represent the standard-transfer balance.

Without something like this, wallets may need token-specific handling or repeated transaction simulation just to determine whether the displayed balance can actually be sent. That seems likely to produce confusing failures for users and compatibility problems for existing integrations.

Is preserving aggregate balanceOf a firm design requirement, or could the ERC expose a stronger compatibility guarantee for standard ERC-20 callers?

1 Like
6

Hi Anzus_GemWallet,

Thanks for the comment – you are right, the Super account compatibility issue needs to be addressed more explicitly, and wallets need reliable, machine‑readable ways to detect the state.

Below is a simplified, robust, and unambiguous flow for any wallet/platform that wants to make transferFrom() on an UNKNOWN ERC-8378 token. The flow ignores NZS token option.

  1. Detecting interface: Call supportsInterface(type(IParametricToken).interfaceId). If false, use standard ERC‑20 semantics.
  2. Checking account type: Call isSuperAccount(owner). If false, treat as vanilla ERC‑20 and apply balanceOf(), allowance(), transferFrom() in the usual way.
  3. If Super account: transfer and transferFrom always use sub‑account 0. The spendable balance is parametricBalanceOf(owner, 0), not balanceOf(owner) (which is aggregate).
  4. Allowance: transferFrom uses the General allowance (total - sub), not the Specific allowance. Query allowance(owner, spender).
  5. Executing: The maximum transferable amount transferableAmount is the minimum of parametricBalanceOf(owner, 0) and allowance(owner, spender). Call transferFrom(owner, recipient, transferableAmount).
  6. Events: Both Transfer() and ParametricTransfer() events will be fired, the latter will show all involved sub-accounts and resulting parameter state.

Result: The transaction succeeds. If you skip any of these checks, it may revert unexpectedly.

The flow above reflects changes we need to make to the existing Specification:

  1. Replace the accountType() getter with isSuperAccount(). This gives wallets a simple boolean check for Super account status.
  2. Make paramConfig a REQUIRED getter. Integrators need to know mutability, name, and decimals on‑chain to handle parameters correctly.
  3. Require ERC‑165 for the main interface – add supportsInterface(bytes4) to IParametricToken so wallets can reliably detect ERC‑8378 tokens.
  4. Add a compatibility warning in the Security Considerations section about balanceOf being aggregate for Super accounts and transfer only using sub‑account 0.
  5. Keep allParametersOf as RECOMMENDED – it remains a convenience getter, not a core requirement.

We will update the specification accordingly, I will notify.
Thanks for the feedback!

7

Thanks for the detailed explanation and for taking the feedback into account. The proposed changes sound helpful, especially giving wallets a reliable way to detect Super accounts and determine the amount that can actually be transferred.

Documenting the wallet flow clearly should also help prevent users from seeing a balance they cannot send. Looking forward to the specification update.

1 Like
8

Hi Anzus_GemWallet,

Specification is now updated (first link in the original post, or PR link). Here is a summary of the key updates made in this commit:

  • ERC‑20 Compatibility: we have revised the respective section to clearly distinguish interface compatibility from semantic compatibility. The section also now includes explicit integration guidance for legacy systems:

    • supportsInterface(type(IParametricToken).interfaceId) and isSuperAccount(address) – to detect that the token is parametric and whether an account is a Super account
    • Clarifies what methods to use for Super accounts and provides a dedicated table mapping standard ERC‑20 functions to their parametric equivalents.

  • Definition of deterministic mutations: we tuned respective wording to avoid “pure” and introduce more general definition requiring fully reconstructible and verifiable transitions.

  • Security Considerations: we have added a dedicated note on Super accounts and ERC‑20 wallet compatibility, explicitly warning integrators on proper usage of balanceOf.

  • Permissions (optional interface): we added an optional _permissions structure to restrict inbound transfers based on incoming parameter values. This protects against “parameter poisoning”, which is a sensitive issue for some use cases like voting. The functionality definitely requires standardization due to numerous nuances.

  • Committed allowances: committedUntil field is added to the allowance record, if not 0 it sets commitment deadline, until which the owner can’t withdraw respective sub allowance. The feature requires minimal overhead but is pretty efficient in P2P operations.

Any suggestions/comments are highly appreciated.

Implementations will be updated shortly.

9

Thanks for the update. Clearly separating interface compatibility from semantic compatibility, along with the mapping table, should make it much easier for wallets to avoid presenting an aggregate balance as fully spendable.

The clearer integration guidance addresses the concern I raised. I don’t have any additional comments at this stage, but I appreciate you incorporating the feedback.

1 Like
10

Hi Sasha,

I’ve read through your proposal a few times, and I find the core idea compelling. While I’m not a blockchain protocol expert, from a software engineering perspective, extending ERC-20 with deterministic state and parameterization seems like a logical way to support use cases that don’t fit neatly into purely fungible or non-fungible models.

My main question is around standardization rather than technical feasibility.

Historically, ERCs have taken different approaches: ERC-721/1155 introduced new asset models, while ERC-2612 and ERC-4626 extended existing models around broadly recurring needs. ERC-4626 is particularly relevant because its value came from standardizing a pattern that multiple independent applications were already converging on.

With that in mind, do you see Parametric Token as a general-purpose primitive that addresses a recurring ecosystem-wide need, or primarily as an abstraction emerging from the specific prediction, tenure, bundle, and agentic use cases you’ve encountered?

I can see the potential, but the added semantics around sub-accounts, parameter mutation, allowances, and especially non-zero-sum transfers also create meaningful integration considerations for wallets, indexers, exchanges, and existing DeFi infrastructure.

So I’d be particularly interested in what evidence you’re seeing that this is a broadly recurring pattern—and what you see as the strongest use cases beyond the initial implementations.

Overall, I’m interested in the direction. I’m mainly trying to understand where you see the boundary between a powerful application-level abstraction and an ecosystem-level standard.

1 Like
11

Hi Tyler tspellen1,

Thank you for the thoughtful read and the careful questions. I will try to clarify the points.

Standardization vs. application-level abstraction

ERC-8378 deliberately distances itself from application logic. It does not prescribe what parameters mean, how they should mutate, or what economic policies should govern them. Instead, it introduces a minimal set of interfaces and logic that enable parametric rails – a shared language for stateful fungible tokens that any application can adopt. The standard provides the structural primitives: sub‑accounts, typed parameters, deterministic mutation hooks, allowances, and permissions. The application layer shall define the economic meaning.

Just‑in‑time ideology and encapsulation

We believe the Parametric Token has very wide applicability, but we need to be clear: it is not well‑suited for pre‑mint models. If you pre‑mine 1B tokens and distribute them arbitrarily, the parameters become meaningless and the whole idea is discredited. The token’s value should depend on the state it carries at the moment of mint and in every subsequent transfer. This naturally aligns with a just‑in‑time ideology: tokens are minted when a user engages, and the parameters reflect that engagement.

The best way to implement this is through encapsulation of the token with an engine – a separate contract that holds exclusive capabilities (e.g., minting, burning, or reward distribution) and enforces the application‑specific logic. The token remains a pure ledger; the engine provides the economic context.

Wallets as the primary interface

Parametric tokens will certainly require integration effort. But the big story behind adoption is that wallets are arguably the largest beneficiaries of this standard. They are the user‑facing interface and the primary security layer for asset management. With ERC‑8378, wallets gain an incredibly powerful low‑level interface for assets represented by parametric tokens: sub‑account balances, allowances, permissions, and transfers – all become natively accessible. For end users, this means clarity and control; for the ecosystem, it means that complex financial logic becomes accessible through the tools they already use. This will stimulate adoption of the standard.

Use cases and evidence

Prediction markets, tenure‑based governance, and bundled portfolios demonstrate pretty wide range of applicable use cases.

But the main statement is this: parametrization can add value to essentially any plain ERC‑20 solution, with minimal overhead. Every system has some ultimate goals (adoption, trading volume, loyalty, etc.), and parametrization can directly contribute to them. Account‑specific parameterization personalizes incentives. This is the mission and ultimate logic of parametrization.

To extract value from it, the project must first decide on its KPIs and align token parameters accordingly. It doesn’t necessarily solve all motivation problems, but it directly links personal interest with project goals via account‑level parameterization.

We believe this is a very efficient tool for many tasks: from liquidity consolidation to asset‑specific economic implementation (e.g., RWA tokenization). The token contract remains generic; the engine and overall implementation provide the economic intelligence.

A sample governance implementation

To illustrate the pattern, let’s consider a governance project with two soft KPIs: loyalty and active participation. We can introduce two parameters:

  • holdingTime – time since mint
  • voteCount – number of votes cast.

Both use weighted average as the mutation function. The engine registers every vote participation and increments voteCount for the respective account accordingly.

On the benefits side, the same engine then can apply discretionary treatment:

  • Accounts with longer holdingTime receive more voting power (e.g., balance * holdingTime)
  • Accounts with higher voteCount receive higher economic interest (e.g., rewards, fee discounts).

Importantly, users can trade their tokens freely and there is no need to restrict this. Thus, every token holder can capitalize on their holdingTime or voteCount. The market price will naturally reflect the parameter state.

I hope this clarifies the ideology of the standard. Thanks for your inquiry.

12

Update: token contract Router pattern, permissions, and gas benchmarks.

I wanted to share an important update on token spec and its reference implementations:

  • Tuning of all interfaces and data structure, including signed creditAmount for NZS transfers
  • Router‑proxy architecture refactoring
  • Full implementation of permissions for Prediction token
  • Gas benchmarks for all core functions across three token implementations
  • Uplift of Specification, Rationale and Security Considerations
  • Update of tests and scripts.

The draft and code are available in the reference repository (see original post).

Router‑Proxy Architecture

All tokens now use a router‑proxy pattern: Router (with Storage) + Core + Token-specific logic + Permissions (only for Prediction token). This keeps each contract well under the 24 KB size limit, makes upgrades easier, and separates concerns.

Permissions

The IParametricPermissions interface is now implemented in the Prediction token. This allows accounts to restrict inbound transfers based on parameter value ranges – protecting against parameter poisoning attacks.

Feature Description
permitForSub Set min/max ranges per parameter per sub‑account
permissionOf Query a permission
allPermissionsOf List all enabled permissions 
  struct Permission {
    bool enabled; // Enabled flag
    uint64 min; // Minimum acceptable value (inclusive)
    uint64 max; // Maximum acceptable value (inclusive)
    bool soft; // If true, owner is exempt; if false, applies to all
  }

Non‑Zero‑Sum (NZS) Transfers with Negative Credit

In NZS transfers, creditAmount can be negative, now it’s reflected in its type: int256 creditAmount. While the Bundle token implementation produces a strictly positive creditAmount, it can be negative in general case. Off‑chain systems must detect NZS via supportsInterface and use the NZS event for accurate accounting.

Gas Benchmarks

We assessed gas consumption for core functions for all implementations. All numbers are total user cost (with Router delegatecall overhead included), measured as median gas from multiple executions with warm storage, Super accounts, and non‑trivial mutations:

Operation Prediction Tenure Bundle
2 params + permissions 1 param 1 param + NZS
approveForSub 45,870 45,831 45,831
allowanceOf 14,694 14,677 14,677
parameterOf 9,537 9,498 9,498
parametricBalanceOf 11,338 11,299 11,299
transfer 90,711 76,755 113,852
transferFrom 102,241 88,175 125,383
parametricTransfer 91,427 80,189 117,397
parametricTransferFrom 109,351 95,329 132,537
mint 92,086 70,378 105,114
burn 64,100 61,242 63,018
permitForSub 41,683 n/a n/a
permissionOf 13,056 n/a n/a

All costs look as a reasonably affordable overhead.

Testing & Deployment

  • Tests are updated for new implementations
  • Scripts are reduced to deployment.

I would really appreciate any feedback on interfaces, permissions functionality, signed credit, and gas costs.