Most contract designs for a tokenized security specify how a token is issued, gated and traded, and nothing about how the holder is paid. That is a gap, not a simplification. Income distribution, buy-back, and the income half of appreciation-plus-income are value movements to holders. Each of them is a way around the transfer gate if it is built as a payment rather than as a transfer.

This article covers the layer that carries investor economics, and it is a smaller layer than most designs make it. Two contracts, DistributionAgent, which pays holders, and BuybackAgent, which repurchases from them. Section 6 takes the two arithmetic cases, a bond's coupon and a tranched structure's waterfall, and sets out where each of those calculations belongs, which turns out not to be on-chain. No single regulation owns any of it, and the first section explains why. The rules the buy-back module implements are in the market-abuse regulation for tokenized securities article. The gate it reuses is in the transfer-restrictions article; the wider architecture is in the EU-Compliant Tokenized Securities: Smart Contract Architecture pillar.

1. Why this layer has no regulation name

Applies to every reader. It is the reason the compliance basis below is cited four ways.

The obligations that reach a payout come from four places, and none of them is about payouts:

Limb	Where it comes from	Owning article
Who may be paid, and the rule that the reason for exclusion is never disclosed	The anti-money-laundering regime for obliged entities; targeted financial sanctions for everyone	Transfer restrictions; identity
Fees and costs borne by investors	AIFMD Article 23(1)(c), where the token is a fund unit	Fund structures
The buy-back safe harbour, closed periods, and surveillance of the issuer's own trading	The Market Abuse Regulation, where the instrument is admitted to trading	Market abuse
Withholding tax	Tax law — outside the compliance library entirely	Nobody. See section 5

Naming this article after the market-abuse regime would have been wrong: that regime owns the safe-harbour rules. This layer owns the modules that implement them, and three of the four modules never touch it.

2. A distribution is a gated transfer, not a payment

Applies to every income-bearing token. This is the property the module exists for.

A wallet that cannot receive a single unit of the token must not be able to receive the income those units produce. If the issuer pays holders from a treasury wallet in a batch, that is exactly what happens. A restricted wallet, a lapsed due-diligence record, a missing claim, none of it is consulted, and the payout is a bypass.

We build DistributionAgent to run the same mandatory checks as an ordinary transfer before it pays anyone.

Two reads are unconditional.

• The identity registry's eligibility check, which catches an expired record or a missing claim,
• and the restriction store, which catches every wallet-level stop there is. They are two reads rather than one because the wallet stop no longer lives on the identity record. Folding it back would recreate the two-store leak the transfer-restrictions article describes.

Together they are the whole of what the anti-money-laundering regime and sanctions law require on this path. Article 21 for the incomplete-due-diligence exclusion, Article 75 for a suspicion block, and the sanctions regime regardless of licence.

The rule modules are opt-in per distribution, and that is deliberate. 

Most of them were written to reason about a movement of units. A concentration counter or a holding-period clock asked to adjudicate a cash payment either misfires or answers a question nobody asked. Turning them on for an instrument whose modules are payout-aware is correct. Turning them on by default would block income on rules that were never about income. What must never be opt-in is the two reads above. Which is why the module holds the restriction store as a constructor argument that rejects a zero address rather than as a removable module.

The gate returns a result; it does not revert. A revert would abort a batch and let one restricted wallet stop everyone else's income and it would leak, through the failure, exactly what the next section says may not be disclosed.

3. No reason disclosed

Applies to every platform inside the anti-money-laundering regime, and is good practice for the rest.

Article 76 prohibits disclosing to the customer or any third party that a suspicious-transaction report has been filed, is being prepared, or that the customer is under analysis. The transfer gate honors that with one generic refusal for every block class. An "excluded from dividend" event is a tipping-off risk on the same basis. If it only ever fires for compliance reasons, it is a disclosure with extra steps.

So when the gate declines a holder, the module records the amount as unclaimed and emits one event. The same event, with the same shape, whether the cause was a restriction, an expired record, a missing claim, or a rule module. One event, several causes, no reason code. The indistinguishability is the control.

The fourth cause is the one that makes the other three safe. 

A payout can also fail for a reason with no compliance content at all. The recipient is a contract that reverts on receipt, or is out of gas. The natural implementation reverts on that and holds only on a gate failure. And the moment it does, the exclusion event fires only for compliance reasons, which is the "excluded from dividend" tell this section exists to remove.

So the push is attempted first and a delivery failure is held exactly like a veto. Same event, same unclaimed balance, same redemption path afterwards. The population of held entitlements has to contain boring cases, or its membership is the disclosure.

A payout that cannot be pushed is not extinguished. 

The issuer still owes it. The unclaimed balance is held per holder, and the holder collects it themselves through redeemUnclaimed() once whatever blocked them is resolved, the restriction lifted, the record refreshed. Callable by the holder deliberately. A withheld payout that only the operator can release is a liability the holder cannot enforce.

After a claim deadline the issuer may sweep the remainder back, and the sweep does not extinguish the debt either. Whether an unclaimed dividend lapses is a question of the issuing Member State's prescription and unclaimed-property law, not of a contract function. A deadline of zero, the safer default, disables the sweep.

Held is a state the holder has to be able to leave, and a lost key is what makes that hard. 

The snapshot captures whichever wallet held units at the record block. So if the investor loses that key and the token moves them to a new one, the payout sits held against an address they can no longer sign for. We build the claim to resolve the same investor across wallets, by the test the token's own recovery path uses.

It publishes no link that recovery has not already written permanently into block history, and opens no path around a live restriction, the eligibility and restriction reads still run on the wallet being paid. One refusal covers every cause, including "not the same investor". A distinct one would answer "are these two wallets one person" for anyone who asked, about anyone.

And a distribution cannot close while any holder is unaccounted for. 

closeDistribution() refuses unless paid plus held equals what the pool committed, those being the only two places a holder may end up. Without it, pushing most of the register and closing is silent and unrecoverable. The rest reached neither state, the push path shuts when the state moves, nothing is held for them to claim. And their share sits inside the contract's own reserve figure owed to someone who cannot reach it and unwithdrawable by the issuer at the same time. ⚠️ It is also the only on-chain test of the anchored unit total there can be, because a Merkle root commits to its leaves and cannot be summed.

4. Record date, snapshot, and full funding

Applies to every distribution. Three rules a first implementation gets wrong.

The record block is committed before it exists. declareDistribution() refuses a record block that is not in the future. An agent who can name a past block can look at the register, see who holds what, and pick the block that suits. Entitlement is then computed from balances at that block, not from balances at payout time. Otherwise a transfer between record and payment date silently redirects the money.

The holder set is anchored as a Merkle root, not iterated on-chain. Iterating every holder is unbounded gas, and checkpointing balances inside the token makes every ordinary transfer permanently more expensive to serve a function most instruments use four times a year.

The tamper-evidence is real but indirect: the leaves are derived from public chain state at a block fixed in advance. So any holder, auditor or regulator can recompute the root and prove a mismatch. What it does not do is prevent a wrong root being anchored. That is caught by reconciliation, and an operator who does not run it has an unverified number wearing a cryptographic costume.

Partial funding is refused, not tolerated. 

openDistribution() reverts unless the pool covers the snapshot in full, and the test is against gross entitlement. Fee and withholding are deducted from each holder's amount and forwarded, not skimmed off the pool to make it stretch. A distribution that pays some of the register and runs dry is a fairness problem, and in a fund an investor-treatment problem with a supervisory dimension. Any rounding remainder stays with the holder. A fee that rounds in the operator's favor on every payout is a fee the disclosure document does not describe.

A payout that names no basis cannot open. 

Alongside the funding test, openDistribution() refuses a distribution with no anchored document attached, the dividend announcement, the note's term sheet, or a tranche period's allocation statement, whichever states what is owed and why. 

We build the attach as its own step, after the snapshot and before funding, because the order is forced by arithmetic rather than taste. At declaration the record block is still in the future, so the unit count does not exist and no statement can assert a final figure.

Both the reference and the version hash current at that moment are recorded. So a later version supersedes visibly instead of quietly restating what the payout was declared against.

The requirement is universal, because verifiability and basis are different things. 

A dividend's entitlement is fully checkable from the chain, a unit count times a published rate, which makes the document look optional, and it is not. The announcement is the corporate action. A coupon's terms are anchored once at issuance, the same reference attached to every period. Only a tranched structure needs a fresh document each period, because arrears carried from an earlier shortfall cannot be re-derived from chain state. ⚠️ What the check proves is existence, currency and sequence, never correctness, and that has to be caught where the figure is computed.

The push is permissionless. Anyone may pay anyone, because the entitlement is fixed by the snapshot and the destination by the proof. A push restricted to the agent makes the holder's income dependent on the operator continuing to run a batch job.

Between funding and payout the balance is committed to identified holders, not held on the operator's account. The same posture as the subscription escrow on the way in. Whether a pool that sits in the contract for longer than that is client money the operator needs an authorization to hold is a licensing question. And the design keeps the window short rather than answering it.

5. Fees, and a deduction with no Article behind it

Applies to fund units for the fee limb. The tax limb applies wherever the issuing jurisdiction withholds, and is outside the regulatory library.

AIFMD Article 23(1)(c) requires the manager to disclose to investors the fees, charges and expenses borne by them. That is a document. Deducting the fee on-chain is evidence that the disclosed fee was what was charged; it is not the disclosure. The module takes a fee rate per distribution and forwards the deduction to a named recipient, separate from the tax recipient below. Because netting the two into one destroys the evidence that either was correctly calculated.

Withholding tax is a fed rate and an on-chain deduction, and nothing in this series cites an Article for it. Where the issuing jurisdiction requires tax to be withheld at source on a distribution, the module deducts at a rate it is given and forwards to a tax recipient. Which rate, whether treaty relief applies per holder, and how the withholding is reported are tax questions with real build consequence and no regulatory owner in this architecture. Tax counsel decides them per issuing Member State before the first distribution is declared.

6. Coupons and waterfalls — where the arithmetic belongs

Applies to debt tokens and to revenue-participation or tranched structures respectively. Neither computes on-chain, and neither pays anyone itself.

A debt token's coupon is computed off-chain, against a term sheet anchored in the document registry, and paid through the agent above. Each period's distribution attaches that same reference. So what the rate was contracted to be is provable for the life of the note without anyone holding a copy of anything. Principal at maturity is the same sequence at the principal rate, with the units burned only after the payout has settled. Burn first and the holder loses the units and the money in one transaction.

We built an on-chain coupon schedule, then removed it. The test that removed it is worth borrowing: does a refusal read the data? Put nothing on-chain unless a require or revert consults it. The schedule held the terms as immutable state and checked a declared rate against them before a period could be bound, two dozen refusals, and not one could stop a payment. Because the payout contract held no reference to it and never asked whether a period was bound. It was state whose only reader was the state machine maintaining it. ⚠️ Where the arithmetic runs and where the state lives are one decision, not two.

It expressed exactly one note shape. 

A singular fixed rate, so floating, step-up, callable, puttable, make-whole and holiday-calendar conventions were all outside it. And a schedule deployed against terms it cannot hold reverts on the payments that are correct, the fix under pressure being a fudged deployment. A wrong number on-chain wearing an immutability badge is worse than no schedule, because the immutability is what everything downstream trusts. And once every distribution had to attach an anchored document, the schedule's last offering, terms a contract could compute from without parsing a document, had no consumer, because no contract needs the rate. 

A capability with no consumer is not a feature. One rule survives, which no contract was enforcing anyway: do not repay principal while a coupon period is unresolved. Maturity runbook, with a name against it.

A tranched structure gets no contract at all. Priority ordering, accrual, arrears carried forward, capital returned, a residual split summing to the whole. All computed off-chain, with a quarterly allocation statement anchored in the document registry. Income received, each tranche's amount, arrears after, capital after, the terms reference, and the distribution ids that paid it. Each tranche is then its own distribution through the agent above, own snapshot, own pool, and the same two mandatory reads on every holder.

What an anchored statement buys is what a dispute is actually about: 

not the multiplication, but whether the declared figure was changed afterwards. A hash in block history answers that with no contract code, and answers it for any waterfall shape, including the IRR hurdles, catch-up tiers and clawbacks a fixed set of on-chain step types cannot express. 

What it gives up: a contract computing arrears from capital, rate and elapsed time cannot be told a wrong number, and an off-chain engine can. A statement records an assertion, not a derived fact. 

So one control stays in the contract and three become operational. The one that stays is §4's fence, anchored and attached before the pool opens, so an unrecorded allocation stops the payout instead of leaving a gap nobody notices until a dispute. 

The three that move need named owners.

• The conservation check, which belongs in whatever generates the statement and catches a split that does not balance but never one that is wrong but balanced
• The sub-unit remainder, which must ride its own tranche's next payment rather than flow down the waterfall, small money between parties with opposing interests
• The statement reaching holders at the time, because an anchor proves a document was not edited and proves nothing to a holder with no copy.

Both shapes are issuer-funded liabilities by construction, and that holds whether the arithmetic runs on-chain or not. 

The issuer owes the money; the token is the security the investor subscribed to. An originated-loan participation is the mirror image a third-party borrower owes, the cash flow is a pass-through, and on default the loss lands on the holder. Neither shape models a pass-through, and a loan participation is a different instrument with a separate scoping exercise. Do not stretch the coupon module, or a tranche statement, to cover it.

7. Buy-backs — a programme, never a facility

Applies to an issuer repurchasing its own instrument. Read the market-abuse article's section on Article 5 first: the safe harbour covers shares, three purposes, and nothing else.

The Market Abuse Regulation's Article 5 safe harbour exempts a buy-back programme in own shares from the manipulation prohibitions if every one of its conditions is met. It is all-or-nothing: breach one and the exemption is unavailable for that trading, which is then judged on ordinary manipulation grounds. So we build BuybackAgent with every condition as a revert and none as a warning.

The instrument class is the first condition, and the contract refuses rather than warns. 

The harbour is for own shares. So the deployment declares what the token is, as a disclosure item fixed at deployment, and opening a programme reverts on anything but a share. A parameter would be wrong here. An issuer that can configure its way into the harbour will, and the failure surfaces as an exemption relied on and not available which is the whole loss, not a reduced one.

Purpose is an enumeration of the three Article 5(2) grounds, not a free-text field. "General corporate purposes" or price support is outside the harbour, and a string field invites someone to write exactly that. A capital-reduction programme forces the repurchased units to be burned, because holding them in treasury is inconsistent with the stated purpose.

Disclosure precedes the programme, and the contract checks the order. 

discloseProgramme() requires the Article 5(1)(a) details start, end, maximum consideration, maximum number of units, maximum price to be anchored in the document registry before the start date, checked against the anchor's timestamp rather than a flag the issuer sets. The ceilings held on-chain are the machine-readable half of the same document.

Price and volume caps come from an oracle and fail closed. The delegated regulation's limits, no purchase above the higher of the last independent trade and the highest current independent bid, and no more than 25% of average daily volume over the preceding 20 trading days need market facts that are not on-chain. executePurchase() refuses when the reference is stale or missing, because a stale reading is not a degraded safe harbour; it is no safe harbour.

⚠️ No feed is usually a scope answer, not a data problem. 

On an instrument that does not trade, "last independent trade" and "highest current independent bid" are not inputs you are missing, they are facts that do not exist. The regime is reached by the instrument, nothing admitted, nothing traded and no request for admission filed on any EU venue means the market-abuse regime has nothing to attach to. So there is no prohibition to need an exemption from and this module does not deploy. 

A filed request is already enough to be in scope, before a single trade prints. The conditions bind while the price history that would satisfy them does not yet exist, so do not run a programme before trading begins. And where the instrument is admitted to a third party's venue, the repurchase normally runs through a broker there. Their systems supply the reference, their process carries the conditions, and the issuer's residual duties are discharged off-chain from the venue's records.

⚠️ Operating your own venue does not escape the regime, it is one of the ways into it, because a DLT MTF is an MTF. What running it does give you is the feed, your own order book is the independent trade and the independent bid. ⚠️ Which sharpens a word independent means independent of the issuer's own buying. So where the issuer and the venue opertor sit in one group, which prints count toward the reference is answered in writing before the first purchase, not during one.

The closed-period freeze is reused, not reimplemented. One calendar governs directors and treasury alike, and a purchase inside a closed period reverts.

No selling during the programme — and this one is a programme rule, not a contract control. 

The delegated regulation bars the issuer selling its own shares while the programme runs. Nothing on the sale path can enforce it. The treasury's units move through the instrument's ordinary transfer rules, where the treasury is a holder like any other, and a module that refused every disposal by a treasury address would also refuse the disposals a capital-reduction programme is required to make. It belongs in the programme's own operating rules with a named owner, and the honest place to say so is here.

Each execution is published within seven daily market sessions, and recordPublication() is owed per execution — a programme-level announcement does not discharge it. A single competent-authority identifier travels on every execution, because since the Listing Act the trades are reported to one authority, not to each venue's.

What the contract deliberately is not. 

It is not a stabilization contract — that is a different Article 5 harbour, with a designated manager and its own conditions, and running one through a buy-back contract because both live in Article 5 is a category error. And it is not a continuous redemption facility. A standing offer to buy holders' units back on demand against a live quote is a different regulatory posture from a disclosed, dated, capped programme.

It raises open-ended-fund characterization on the fund side and dealer or venue characterization on the market side, both of which are licence questions rather than parameters. There is no holder-initiated call path in the module, and the posture cannot be swapped after deployment by widening the dates and raising the ceiling.

For an instrument that is not a share, this module does not deploy. 

A debt token or fund unit repurchased by its issuer is outside the harbour, the repurchase is not thereby abusive, but it stands on the general prohibitions with no presumption in its favour, and the closed-period rule still reaches it. There is no non-harbour repurchase path in the architecture, and that is deliberate. A debt issuer's buy-back is a real commercial operation. Building a module that ran the same price and volume ceilings for it would imply a protection that does not exist, and the ceilings are the harbour's conditions rather than a general standard of conduct. What such an issuer owes is the closed-period gate, the ordinary transfer gate, and its own documented dealing policy. Classify the instrument before any of this is scoped, not before relying on the exemption.

Which leaves the question an operator asks first: on a token admitted nowhere, how does a holder get out? 

Through neither this module nor any other. A fund unit redeems at NAV through the liquidity-management gate, dealing-day and pro-rata, with the valuation fed in and the cash leg settled outside the gate. And a fund unit repurchased by its issuer was never inside the Art 5 harbour anyway. A share or a debt token has no exit function at all, and the absence is the design. 

The route is an ordinary transfer plus an off-chain cash leg. The company-law authorisation for an own-share acquisition anchored in the document registry with the price and equal-treatment basis beside it. The holder transfers units to the treasury through the same gate as any other transfer, the issuer settles cash, and the units are cancelled or held as that authorisation says.

⚠️ The two legs are not atomic.

The subscription escrow is inbound-only, so sequencing is a counterparty-risk decision made in writing. A residual to price, not a gap to patch. The exit needing no issuer balance sheet is worth naming first: a secondary transfer to another eligible investor, which the transfer gate already serves.

None of which stops an issuer offering holders a route back — it means the offer lives in the document rather than in a function, and the reason is sharper than the licence risk. 

Four features keep such an offer clear of open-ended-fund and dealing-on-own-account characterisation: a limited window, a capped aggregate, issuer discretion, and a documented price basis. A function expresses windows and caps as modifiers, and price as a parameter.

⚠️ It cannot express discretion at all — a contract cannot be discretionary. 

What it offers, it offers to every holder, permanently and in public, so a redeem() with a window is not a narrower facility but a facility with a window, and the thing that needed discretion has been automated away. We build the right into the subscription or shareholders' agreement instead, anchored where every other disclosure is, and exercised as a request the issuer accepts or declines against stated terms. On-chain, only what already works happens: a transfer to the treasury, and the election to cancel the units or hold them.

8. Own trading — the duty that arrives with the first buy-back

Applies to an admitted instrument the moment the issuer executes a repurchase.

A buy-back is the issuer trading its own instrument. Two consequences follow, and neither needs a dealer lane to be in play.

The closed-period prohibition covers it — Article 19(11) prohibits transactions by managers, and the freeze the buy-back module reuses applies equally to a distribution in kind or a buy-back participation by a flagged wallet.

Surveillance of the issuer's own order flow becomes necessary — the one thing here the issuer still owes and this module does not supply. Whether Article 16(2)'s suspicious-transaction reporting duty formally reaches a plain issuer's own programme is a question the market-abuse article leaves to counsel, naming both readings. The capability is needed on either reading, because the safe harbour already requires the issuer to know what its own orders and executions were.

What the buy-back module emits is executions.

That is not the surveillance surface: cancelling or amending an order placed before coming into possession of inside information is itself insider dealing. So the detection the duty asks for replays the order book and not the settled transfers. The order-lifecycle surface — created, modified, cancelled — is specified in the architecture and has no implementation in the issuer lane. An issuer running a buy-back either builds it on the programme's own order path or discharges the duty off-chain from the execution venue's records, and says which in the audit map. Treating execution events as the surveillance feed reads as covered and is not.

9. Two things this article does not settle

Applies to every deployment. Both are decisions with owners elsewhere.

The settlement asset. The modules above pay in the chain's native asset and hold no token-transfer leg. There is no stablecoin path in this build, and adding one is a change to the payout and escrow contracts rather than a configuration. Market practice, meanwhile, pushes payouts in a stablecoin, which is why the decision is live rather than settled. If that stablecoin is an e-money token, the Travel Rule reaches the payout batch. Full originator and beneficiary data, no de minimis, self-hosted-address rules for the reason the transfer-restrictions article gives. e-money tokens are treated as crypto-assets under that Regulation.

Central-bank money or an off-chain cash leg keeps it out. That is a consequence of the settlement-asset decision, and it has to be priced when that decision is made, not discovered at the first record date.

The per-wallet income record

Every payout event is a permanent, per-wallet income history bound to a verified investor, and an event log cannot be erased. The data-protection article explains why events are the worst surface for personal data rather than the exempt one. What this module does is keep the payload minimal; what it cannot do is make the history erasable.

That residual belongs in the impact assessment, and the fact of an exclusion. Inferable from the public payout set even with a generic event and is a stronger case for the automated-decision safeguards than a transfer refusal is, because it withholds money the holder is owed.

At a glance

Control	Module	Basis	Note
Two mandatory reads on every payout — eligibility and the restriction store	DistributionAgent	AMLR Arts 21, 75 for obliged entities; sanctions for everyone	Rule modules opt-in per run; the two reads never
One event for every exclusion cause — a failed delivery included	DistributionAgent	AMLR Art 76	No reason code; unclaimed balance held per holder. An event that only ever fires on a gate failure is the disclosure
Holder self-redeems; sweep after deadline does not extinguish the debt	DistributionAgent	National prescription law	Deadline zero disables the sweep
Any wallet of the same investor may claim a held entitlement	DistributionAgent	—	Resolved by the same test the token's recovery path uses. Without it, a lost key strands the payout against an address the investor no longer controls. The gate still runs on the wallet being paid
No close while a holder is unaccounted for — paid plus held must equal the committed pool	DistributionAgent	Fair treatment	Otherwise the share is owed to someone who cannot reach it and unwithdrawable by the issuer. Also the only on-chain test of the anchored unit total: a root cannot be summed
Future record block; Merkle snapshot; full funding or no opening	DistributionAgent	Fair treatment	Reconciliation is the real check on the root
No anchored basis, no opening — every distribution attaches the document stating what is owed and why	DistributionAgent	Fair treatment; corporate-action disclosure	Attached after the snapshot, before funding: the unit count does not exist at declaration. Ref and version hash pinned, so a later version supersedes visibly. Proves existence and currency, never correctness
Fee deducted and forwarded separately	DistributionAgent	AIFMD Art 23(1)(c)	Evidence, not the disclosure
Withholding at a fed rate	DistributionAgent	Tax — outside the library	Tax counsel per issuing jurisdiction
Coupon computed off-chain — no on-chain coupon contract	off-chain + DocumentRegistry	Contract terms	An anchored term sheet is already immutable and already lets a holder recompute. Terms a contract could compute from had no consumer, and a singular fixed rate could not express floating, step-up or callable notes
Tranche allocation computed off-chain, recorded as an anchored statement	off-chain + DocumentRegistry	Contract terms	Income, per-tranche amount, arrears after, capital after, terms ref, distribution ids. Works for IRR hurdles, catch-up and clawback, which fixed on-chain step types cannot express. ⚠️ It records an assertion, not a derived fact — nothing catches a split that is wrong but balanced, so the conservation check belongs in the generator, dust must ride its own tranche, and the statement must reach holders, not just the chain
Do not repay principal over an unresolved coupon period	runbook — named owner	Contract terms	The one check lost with the coupon module that has no off-chain equivalent. Issuer-funded only; not a pass-through
Every safe-harbour condition a revert, starting with the instrument class; disclosure before start; oracle caps fail closed; closed period reused; per-execution publication; single authority	BuybackAgent	MAR Art 5(1)(a), 5(2), 5(3); Del. Reg 2016/1052 — shares only	A programme on a non-share reverts. No selling during the programme is a programme rule, not a contract control. Not stabilization; not a redemption facility
Own-flow order-lifecycle surveillance — owed, not built	none in the issuer lane	MAR Art 8(1); Art 16(2) as a question	Executions alone cannot detect a cancelled or amended order. Build it on the programme's order path or discharge it off-chain, and say which

This is engineering commentary on regulatory requirements, not legal advice. Whether the buy-back safe harbour is available for a specific instrument, and what tax is withheld on a specific distribution, needs sign-off from counsel.