Category: partially-fungible token standard / partitioned-balance primitive / tranche-metadata layer
Summary: ERC-1410 is the partitioning layer inside the ERC-1400 security-token family. Its core move is to let one holder’s balance be split into named partitions, where each partition can represent a different rights bundle, lockup state, provenance trail, or transfer-restriction regime, while total balances and total supply remain visible at the aggregate token level. That makes ERC-1410 analytically useful because many regulated assets, treasury products, or structured rights systems are not fully fungible in practice even when they share one ticker. ERC-1410 turns that ambiguity into an explicit interface: which tranche are these units in, what operator rights apply to that tranche, and can a transfer change the destination partition as part of the move?
What it does:
Adds balanceOfByPartition and partitionsOf so clients can inspect a holder’s balance at the tranche level rather than only as one aggregate number
Preserves balanceOf and totalSupply across all partitions, letting the token present both a whole-asset view and a partitioned rights view
Adds transferByPartition and operatorTransferByPartition, which move tokens from a specific source partition and return the destination partition chosen by the implementation
Adds canTransferByPartition so a client can preflight partition-specific transfers and get both ERC-1066-style status signaling and an application-specific reason code
Supports operator rights globally and per partition, exposing a cleaner split between all-balance authority and tranche-specific authority
Standardizes issuance and redemption by partition, which makes tranche creation and destruction visible instead of burying it inside generic mint/burn flows
Key claims:
ERC-1410’s biggest contribution is making partial fungibility first-class. It acknowledges that balances in one token may still carry materially different rights, restrictions, or histories, and therefore should be grouped and operated on accordingly.
The destination-partition return value is especially important because it means transfer is not just movement; it can also be a state transition between rights buckets. That is a deeper control surface than a normal ERC-20-style send.
The standard is intentionally agnostic about what partition metadata means. That is analytically useful because it lets the corpus compare vesting, lockups, voting rights, provenance, and regulatory restrictions as different uses of the same lower-layer primitive.
The Security Token Standard README reinforces why partitioning mattered to the original authors: it was meant to support tranches with different restrictions, benefits, and lifecycle treatments while preserving overall token compatibility.
Polymath’s explainer makes the practical intuition clearer than the draft alone: one investor can simultaneously hold locked non-voting shares, locked voting shares, and unlocked voting shares, and different applications may care about different slices of that same balance.
ERC-1410 belongs in the corpus because it gives the tokenized-asset cluster a reusable lower-bound comparison for tranching and rights segmentation before richer identity, compliance, and issuer-admin stacks are layered on top.
Whitepaper: No standalone ERC-1410 whitepaper or litepaper surfaced in this pass. The strongest primary materials were the draft spec, the Security Token Standard repository README, and Polymath’s ERC-1400 family explainer; see ../../whitepapers/erc-1410-primary-sources-2026-05-12.md.