Skip to content

design: variant cap-table inheritance vs per-variant override #45

@Pattermesh

Description

@Pattermesh

Question

LABELTON v0 inherits the master's cap-table for every variant. Real-world remix royalties typically have different splits — the remixer gets a cut the original cap-table doesn't include.

Options

  1. Strict inheritance (v0) — variants always inherit the master's cap-table. Remixes that change splits must register a new master with a different cap-table. Matches the "root mint always lands to the same set of wallet holders" rule literally.
  2. Optional overridemintVariant accepts an alternative cap-table; original master's splits stay as the base. More flexible, more surface area, more edge cases.
  3. Variant-class default — each VariantKind carries a DAO-configured default override (e.g. Remix splits 70% to original + 30% to remixer). Compromise.

Current call (2026-05-25)

Per @Pattermesh's framing — strict inheritance, v0 keeps the invariant strict. Remixes with new splits = new master that references the original.

This issue stays open for review / dissent before LABELTON ships to mainnet.

Depends on

Part of #38.

cc @abhicris @Pattermesh

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions