SendGovernanceMail

How a consilium ended — over a revenue payout, over a payment, over a fund's fee terms, or over a fund's NAV mark — and, under APPROVAL_TOKEN_BURNED, that one of its tokens burned.

ONE message for four subjects, additively. The burn notice already rides this shape under its own kind, so a payment consilium's outcome and burn ride it too, and so do a fee-policy consilium's and a valuation override's, rather than each growing a message of their own: network + address describe a payout, source + destination (+ tier, reason) describe a payment, fund + proposed (+ current, reason) describe fee terms, fund + mark (+ reason) describe a NAV mark, and the renderer switches on which description is filled. A caller fills exactly one and leaves the others empty.

One user's consent to a payment that moves their own money.

WHY subject_user_id EXISTS BESIDE SendGovernanceMailRequest.user_id. Every other kind is addressed to a fund owner, and "is this recipient an owner?" is a fact this plane holds independently of anything the money plane says. This kind has no such fact to check against: any user may consent to their own transfer, so "is this the right recipient?" is unanswerable from the addressing field alone. So the money plane must state, in the TYPED payload, whose money is moving — and the relay refuses unless the user it is being asked to write to IS that person. A caller that fans one consent out to a second mailbox has to contradict itself in the same message to do it.

It is a redundancy on purpose. The address is still resolved HERE from the identity record and never taken from either field.

An owner asked to approve a payment of fund-owned money.

WHY NOT PayoutApprovalMail. That template opens with "a request to pay fund revenue out on-chain" and labels its middle rows Network and Destination address. A payment is a transfer between two claims the platform holds — Piggybank → Revenue, or into a service's pooled funds, or off the platform — and rendering it through the payout copy would mail the whole roster a sentence naming the wrong claim and the wrong rail on a money move they are being asked to authorize. The one thing an approval mail must do is describe correctly what is being approved, so a payment gets its own.

The recipient rule is the payout one: a seated owner, resolved from the identity record, and nobody else. Field rules are PaymentConsentMail's — every string is bounded in bytes and refused if it carries a control character, tier is a closed set, and reason is required and rendered attributed to the operator who typed it.

An owner asked to approve new fee terms for a fund.

Shaped like PaymentApprovalMail — a seated owner, a verified address, the operator's reason set apart as theirs, a link on our origin and the code that arms it — and it describes what an owner must actually be able to check: the terms in force NOW beside the terms PROPOSED, field by field. A fee change is a change to the price of every investor in the fund, and an approval mail that showed only the new number would have the owner approve a difference they cannot see.

One investor told that the fee terms of a fund they hold are changing.

subject_user_id exists beside SendGovernanceMailRequest.user_id for the reason PaymentConsentMail gives: no seat is involved, so the only fact this plane can hold the money plane to is that the person it is writing to IS the person the notice is about. A caller that fans one investor's notice out to a second mailbox has to contradict itself in the same message to do it.

No code and no decision: the terms were set — by the operator within the house terms, or by the owners' consilium beyond them — and this is the investor being told before they take effect, with the same notice either way. link is a CABINET-RELATIVE path — the money plane names no host at all; this plane hangs it off its own cabinet origin.

A payment cancelled because its subject's consent could no longer be given.

WHY NOT PayoutOutcomeMail. That one is the consilium's record and goes to seated owners only; the people this one is FOR are the payment's subject — whose consent link was attacked, or whose sessions were just revoked — and the staff member who opened the order, who is usually an admin. Neither holds a seat.

subject_user_id exists for the reason PaymentConsentMail gives, with one widening: the relay accepts the request's user_id when it IS that subject, or when it names an admin or an owner. Which of the two it was decides the copy (the subject is told what to do about their mailbox; staff get the order's details) and whether an inbox trace is written (the subject only).

Nothing here is a secret and nothing can be a link: no URL, no code. Why the consent died is a closed word the platform phrases itself, and the amount must read as money — no money-plane text reaches a sentence of ours.