Holder communication procedure: stages and deadlines

When a token issuer needs to reach holders — for a redemption, a governance vote, a security notice or a wind-down — the process runs through four stages: preparation, notice, response window and closure. Each stage carries its own record-keeping duty. The clock starts on the day a notice reaches the holder's registered channel, not the day it leaves the issuer's system.

This page sets out how the four stages fit together, what each one requires, and where the procedure typically stalls in practice. It does not tell you what a specific counterparty actually holds, or where to sue over a failed notice — those are separate questions, covered further down.

Why the stage split matters

Token issuance and trading projects rarely run one communication file at a time. A redemption round, a covenant breach notice and a routine governance vote can all be open at once, against different segments of the same holder register. Treating them as one undifferentiated mailing list is the most common source of missed deadlines.

Splitting the work into four discrete stages fixes ownership. Preparation belongs to compliance. Notice belongs to operations. The response window belongs to the holder, but the issuer still has to log it. Closure belongs back to compliance. Once each stage has a named owner, gaps in the register surface early, while there is still time to fix them.

What changes once the clock starts

Before the notice goes out, the issuer controls the timeline entirely. Once the notice reaches the holder, the timeline belongs to both sides. A holder who stays silent inside the response window usually loses the right to object later, but only if the issuer can show the notice was actually delivered, not merely sent.

The practical risk sits almost entirely in proof of delivery. Issuers that rely on a single channel — one email address, one app notification — carry the delivery risk themselves. Issuers that combine two independent channels shift more of that risk onto the holder, because a bounce on one channel no longer excuses inaction on the other.

A holder who responds late, but before closure, usually keeps most practical options open. It is only after closure that the file becomes difficult to reopen, and reopening it typically requires a fresh notice rather than an amendment to the old one.

The four stages

Stage	What happens	Typical duration	Who runs it
Preparation	Holder register is pulled, contact channels checked, notice text drafted and approved internally	days to two weeks	issuer's compliance function
Notice	Notice is sent through the channels named in the token terms; delivery is logged	same day to a few days	transfer agent or issuer's operations team
Response window	Holders can object, elect an option, or stay silent; each response is timestamped	set in the token terms, commonly two to six weeks	holder, logged by the issuer
Closure	Non-respondents are treated under the default rule; the file is closed and archived	a few days after the window ends	issuer's compliance function

A clean file rarely moves faster than this table suggests. It can move slower, and almost always for the same reason: the holder register had gaps that only surfaced once notices started bouncing.

Where the timeline typically breaks

Three points cause most delays. First, an outdated register: addresses and wallets change, and nobody updates the file until a notice fails. Second, an undefined default rule: if the token terms never say what happens to silence, closure has to wait for a decision that should have been made earlier. Third, parallel files: running a redemption and a governance vote through the same register at the same time, without separating the two response windows.

None of these three is a legal question. All three are operational, and all three are fixable before the notice goes out, not after.

What to do

Pull the current holder register and flag every entry with an unreachable or unconfirmed contact channel — the register owner does this, not the person drafting the notice.
Fix the response window and the default outcome for silence before the notice is drafted; the issuer's compliance function sets both, in writing.
Send the notice through at least two independent channels and log the delivery timestamp for each — operations, not legal, owns this log.
Track responses as they arrive and confirm each one back to the holder inside the same window; a single named person should own this inbox.
At closure, apply the default rule to every non-respondent consistently, then archive the full file, including delivery logs, for later reference.

Who decides

The issuer's compliance function, or a body it delegates to, decides whether a given notice satisfies the procedure. Where a holder disputes delivery or the default outcome, the dispute usually moves first to whatever forum the token terms name — often an internal review, sometimes an ombudsman-style process built into the terms themselves.

If that internal forum does not resolve the disagreement, the matter moves to ordinary courts at the issuer's registered seat. Which seat that is, and whether it is even the right forum for a given holder, is not something this page settles — it depends on where the holder sits and what the token terms say.

If your situation differs

If several holders sit in different countries, treat the notice as several parallel procedures, not one. Delivery rules that satisfy a holder in one jurisdiction may not satisfy a holder in another, and closure should not be declared until every parallel file has actually closed.

If a holder's contact details bounce back, do not close that entry on the default rule alone. Log the failed attempt, try the secondary channel, and only then apply closure to that specific holder.

If the token terms never fixed a default rule for silence, stop the procedure at preparation and fix that gap first. Sending a notice without a defined default outcome only postpones the same problem to closure.

If the issuer itself changes hands during the response window, the new controller inherits the open file as it stands, including any deadlines already running against holders.

What this page does not resolve

This page describes the procedure. It does not establish what a particular counterparty actually holds or controls — that sits in a Counterparty in Singapore report, scoped to what a registry can confirm.

It also does not tell you what to do when the underlying assignment or transfer document was never signed in the first place — that gap is covered separately in a Document report when an assignment is unsigned.

And it does not decide where a dispute over a failed notice should be filed. That choice depends on the holder's location, the issuer's seat and the token terms together, and is worked through in a Jurisdiction report before choosing where to sue.

Verified

Reviewed against current operational practice as of the publication date shown on this page. It describes procedure only; it does not cite specific statutory deadlines, since those vary by instrument and by each holder's home jurisdiction. For a view of how our own response times run in practice, see Delivery statistics, published automatically overview.

Frequently asked questions

How long does holder communication procedure take in practice?

Preparation and notice usually take one to three weeks together. The response window itself is fixed by the token terms, commonly two to six weeks. Closure adds a few more days on top. A clean file, with no bounced contacts and a pre-agreed default rule, rarely takes longer than eight weeks start to finish.

Which documents are needed to start?

A current holder register, the token terms that fix the response window and the default rule for silence, and a notice text approved by the compliance function. Without a clean register, the rest of the file has nowhere to stand, no matter how well the other documents are drafted.

What happens if the other side does not respond?

Silence inside the window triggers the default rule set out in the token terms — usually treated as acceptance of the standard outcome. That only holds if the issuer can actually prove delivery; a silent holder who was never reached in the first place keeps their position open.