This repository contains the reference implementation for the Parametric Token Standard (ERC-XXXX), a fully ERC‑20 compatible token standard that allows fungible tokens to carry account‑specific, mutable parameters.
A parametric token is an ERC‑20 token where every balance carries additional information – parameters. Parameters can be:
- Mutable – updated during mints/transfers according to deterministic rules (e.g., weighted average, max operation)
- Immutable – fixed; tokens with different immutable parameter values can never coexist in the same account.
Parameters are account‑specific, not token‑class‑specific. This means two users holding the same token can have different parameter values, and these values evolve as tokens move between accounts.
The standard also introduces sub‑accounts – partitions within a single address that allow a user to hold multiple parameter variants without needing multiple wallets.
The standard addresses real‑world needs:
- Liquidity consolidation – tokens with different mutable parameters trade in the same pool; no segmentation by parameter value
- Velocity control – progressive age‑based fees or rewards let you design tokens for high or low turnover
- Advanced derivatives – tokenized portfolios (like the Bundle) and other sophisticated constructs work out‑of‑the‑box
- Simplified UX – sub‑accounts and fine‑grained permissions reduce wallet fragmentation.
src/
├── ERCS/
│ └── erc-xxxx.md # ERC draft
├── interfaces/
│ └── IParametricToken.sol # Core interface
├── libraries/
│ └── Lib.sol # Pure functions (weightedAverage, sqrt, combine)
├── mock/
│ └── AssetToken.sol # Simple ERC‑20 for testing
├── bundle/
│ ├── BundleToken.sol # Convex portfolio token
│ └── BundleEngine.sol # Engine managing deposits/redemptions
├── tenure/
│ ├── TenureToken.sol # Age‑based token
│ └── TenureEngine.sol # Engine with progressive fees
└── prediction/
├── PredictionToken.sol # Scalar prediction token
└── PredictionEngine.sol # Engine with rounds and rewards
script/
├── bundle/
│ ├── Deploy.s.sol
│ └── Trading.s.sol
├── tenure/
│ ├── Deploy.s.sol
│ └── Trading.s.sol
└── prediction/
├── Deploy.s.sol
└── Trading.s.sol
out/ # Build artifacts and deployed addresses
└── bundle_deployed_addresses.json
└── tenure_deployed_addresses.json
└── prediction_deployed_addresses.json
The full ERC specification is available in ERCS/erc-xxxx.md. It covers:
- Interface and data model
- Parameter semantics (mutable/immutable)
- Sub‑accounts and allowances
- ERC‑20 compatibility requirements
- Security considerations
- Rationale and comparison with existing standards (ERC‑20, ERC‑721, ERC‑1155, ERC‑3525, ERC‑4626).
https://github.com/K2eno/parametric-token/blob/main/ERCS/erc-xxxx.md
All implemetations consist of respective token and engine smart contracts, scripts include Deploy and Trading files.
All Trading scripts use an admin and 3 trading accounts. Trader 3 converts its account to Super account and executes transactions to/from/between sub-accounts.
Concept: A token where the parameter is mintTime (timestamp of mint/last transfer). The engine awards progressive rewards on redemption that are proportional to the token's age.
- Parameter:
mintTime(mutable, weighted average on transfer) - Mutation:
weightedAverage– when two holdings merge, the new mint time is a weighted average of the two - Mint: Engine‑controlled (engine calls
mint).mintTimeis set toblock.timestamporweightedAverageas applicable - Burn: Engine‑controlled (engine calls
burnwith a reward computed from age) - Rewards are proportional to
(block.timestamp - mintTime)– the older the token, the higher the reward points granted.
Use cases: B. Yield-bearing (or credentials-bearing) tokens: link rewards to the age of the token A. Utility‑bearing tokens: stimulate token turnover to avoid holding costs whenever holders don't use the token for its designated purpose (say, portfolio risk management).
Concept: A token where traders mint predictions about the price of an asset at a given future resolution time. The token has two parameters: prediction (mutable, weighted average) and round (immutable, must match when merging).
- Parameters:
prediction(mutable, weighted average on transfer)round(immutable, 0–4; tokens with different rounds cannot merge). Everyroundhas its resolution time
- Mutation:
weightedAverageforprediction; conflict check forround - Mint: Self‑mint – traders call
mintdirectly with their preferred predicted price and round - Burn: Engine‑controlled – engine calls
burnwhen traders report their predictions - The engine manages rounds (active → reporting → claiming). After the round closes, traders report by burning their tokens. Points are distributed inversely to prediction deviation
- Token contract doesn't allow to mint/transfer to an account/sub-account with a different
roundparameter.
Use case: Scalar prediction markets where liquidity is consolidated into a single pool, unlike binary markets that fragment liquidity by outcome layers.
Concept: A token representing a tokenized portfolio (bundle) of an underlying like WBTC and its inverse INV. The bundle token is called BUN. The parameter is the anchor – the WBTC price at which the portfolio's USD value is minimised (inverse pricing of INV produces strictly positive gamma of [WBTC + INV] bundle). When two BUNs with different anchors merge, both the anchor and the total balance are recomputed using the convexity formula. BUN is normalized to have 1 USD value at anchor underlying price.
- Parameter:
anchor(mutable, complex non‑linear mutation) - Mutation:
combine– a pure function that recomputes the anchor and total balance when two holdings merge - Mint: Engine‑controlled – engine computes the anchor from WBTC/INV deposit amounts and mints BUN
- Burn: Engine‑controlled – engine computes the underlying WBTC/INV amounts based on the anchor and burns BUN
- In general case the balance update is not a simple sum; it follows the convexity formula. This demonstrates the standard's flexibility for advanced financial engineering.
Use case: Advanced derivatives engineering.
All mutation logic is implemented as pure functions in src/libraries/Lib.sol:
function weightedAverage(
uint64 p1,
uint256 b1,
uint64 p2,
uint256 b2
) external pure returns (uint64 newParameter);
function combine(
uint64 a1,
uint256 b1,
uint64 a2,
uint256 b2
) external pure returns (uint64 newAnchor, uint256 newBalance);This emphasises their stateless, deterministic nature – they depend only on their inputs, never on contract state. This is a core requirement of the ERC for mutable parameter mutation functions.
git clone https://github.com/k2eno/parametric-token
cd parametric-token
forge installforge buildDeployment and trading scenarios scripts are provided for each implementation.
Use following command to deploy prediction contracts;
export PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
forge script script/prediction/Deploy.s.sol --broadcast --rpc-url http://localhost:8545 --slow --via-irAfter deployment, the contract addresses are saved to out/prediction_deployed_addresses.json.
Use the same pattern for bundle and tenure contracts.
Use following command to run trading script for prediction contracts;
forge script script/prediction/Trading.s.sol --broadcast --rpc-url http://localhost:8545 --slow --via-ir -vvUse the same pattern for bundle and tenure contracts.
- Specification: Public domain via CC0 1.0 Universal.
- Code Implementations: MIT License.
If you use this software or reference the Parametric Token Standard in an academic publication, please cite it as follows:
@misc{zvezdin2026parametric,
author = {Alexander Zvezdin},
title = {ERC-XXXX: Parametric Token Standard},
year = {2026},
publisher = {GitHub},
journal = {GitHub Repository},
howpublished = {\url{https://github.com/k2eno/parametric-token}}
}