Registry And Servicing Model

Status: draft
Version: 0.1.0

Purpose

Define the canonical control-repo language for Meridian Registry checkpoint capture, deterministic entitlements, classified distribution declarations, expiry-aware distribution claim tracking, replayable distribution closeout, distribution funding records, payout servicing, waivers and exceptions, explicit reconciliation, redemption declaration and execution, notice publication, checkpoint-derived ballots, weighted vote capture, tally reconstruction, and replayable Registry state over settled holdings.

Registry model

• checkpoint capture records settled holdings for one instrument at one record date
• deterministic entitlements derive from a checkpoint and a classified distribution declaration
• distribution declarations classify the servicing flow through distributionType, fundingMethod, optional expiresAt, and optional relatedNoticeId
• distribution claims are tracked against holder entitlements and are rejected after expiry or explicit closeout
• replayable distribution closeout records one explicit lifecycle end through distribution.closed with completed or expired reasoning
• distribution funding records track cash or treasury readiness against claimed distribution obligations and may reference one funding proof bundle
• distribution payout servicing records pending, settled, failed, or waived holder outcomes against claimed entitlements and may carry one external payout reference or evidence bundle link
• explicit reconciliation records one governed closeout after funding and payout servicing reach a balanced state with no unresolved claimed amount
• redemption declarations bind one instrument to one checkpoint and define the eligible lifecycle-exit ratio for each holder
• redemption executions consume remaining holder eligibility and drive real instrument.redeemed lifecycle events over live holdings
• notices publish governed servicing and corporate-action communications for one instrument and may reference one checkpoint or ballot
• ballots derive eligible voter weight from checkpoint balances and record one weighted vote per holder in this phase
• replayable Registry state reconstructs from checkpoint.recorded, distribution.declared, distribution.claimed, distribution.closed, distribution.funding.recorded, distribution.payout.recorded, distribution.reconciled, redemption.declared, redemption.executed, instrument.redeemed, notice.published, ballot.opened, vote.cast, and ballot.closed events

Core records

• checkpoint
• distribution
• distribution claim
• distribution close
• distribution funding
• distribution payout
• distribution reconciliation
• entitlement
• redemption
• redemption execution
• redemption eligibility
• notice
• ballot
• ballot vote
• tally snapshot
• replay state

Required servicing references

• instrument id
• record date
• checkpoint id
• distribution id
• distribution type
• funding method
• funding id
• payout id
• payout status
• redemption id
• notice id
• ballot id
• holder id
• option id
• payable date
• expiry timestamp
• close reason
• reconciled at
• reconciled by
• related notice id
• redemption ratio
• claim event id