The Prospectus Regulation — Regulation (EU) 2017/1129 — governs one moment: the point at which securities are offered to the public in the EU, or admitted to trading on an EU regulated market. That moment does not disappear because the security is a token. It lands on a subscription contract, and several of the duties turn out to be harder to satisfy on-chain than off it.

This is a deep-dive on one regulation. The architecture around it — capability set, module inventory, instance counts — is in the EU-Compliant Tokenized Securities: Smart Contract Architecture pillar. Two modules carry almost all of this Regulation: DocumentRegistry, which anchors a document hash and URI on-chain, and SubscriptionEscrow, which holds primary subscriptions while any statutory withdrawal window is open.

Does it apply at all?

Applies if the token is a closed-end fund unit or a direct (non-fund) security — tokenized equity, plain debt, fractional co-ownership — offered to the public in the EU or admitted to an EU regulated market above the applicable threshold.

Does not apply if the token is a unit issued by a collective investment undertaking other than the closed-end type. Article 1(2)(a) excludes those units from the Regulation altogether, on both the offer and the admission limb. That is an exclusion, not an exemption — it removes the security from the regime rather than relieving an in-scope offer of one duty.

So fund tokens split three ways. Open-ended fund tokens never need a prospectus under this Regulation. Closed-ended fund tokens — most tokenized illiquid real-world-asset vehicles — are fully inside it. Direct securities are inside on their own terms, whatever the redemption design.

Two adjacent regimes are easy to over-read out of the first case: a European long-term investment fund runs its own prospectus regime under Regulation (EU) 2015/760, and any retail investor may still be owed a key information document under PRIIPs. Both are outside this article.

The build consequence is asymmetric, and usually read backwards. For an open-ended fund token, SubscriptionEscrow's withdrawal windows and validity expiry genuinely drop out. DocumentRegistry does not — an open-ended retail fund still owes a KID, a long-term fund still owes its own prospectus and annual report, and both anchor through the same registry. SubscriptionEscrow is prospectus-specific; DocumentRegistry is not.

To know about what DocumentRegistry is, explore >> Document anchoring for tokenized securities

Everything below assumes the token has cleared that gate. No issuer owes all of it — each section opens with the fact that triggers it, because the heaviest duties here fire only on particular offer structures. Read the coverage as a map, not an estimate of the build.

How to read the three labels

Label	What it means	Test
On-chain	A contract reads the value and blocks something with it	Is there a revert that depends on it? The one carve-out is an event emitted so an off-chain watcher can catch what no contract can
Partial	The decision is on-chain, but something feeds it a value it cannot compute — a calendar, a national threshold, a publication event	Does the chain have any way to know this by itself?
Off-chain	Procedural, human, or addressed to the firm rather than the transfer — a person decides, drafts or files, or a platform system does it with no contract involved	Would a wrong answer be a judgment call rather than a bug?

The chain does three things in this Regulation and no more. Count money and persons per jurisdiction, block on an expired date or an unapproved hash, and hold cash refundable until every window has run. Everything else is a document, a calendar or a person.

1. The threshold that decides whether a prospectus is needed

Applies to the offer limb only. Admission to trading carries no size exemption, so a listing without a public offer never reaches this test.

Article 3(2) exempts offers to the public from the prospectus obligation where total consideration across the Union stays under €12,000,000 per issuer over twelve months. Unified at that figure from 5 June 2026 by the EU Listing Act, Regulation (EU) 2024/2809. A Member State may instead elect its own ceiling, with €5,000,000 as the floor. That is a binary national election, not a sliding scale. So a multi-jurisdiction offer can be prospectus-exempt in one Member State and prospectus-triggering in another at identical size, on the same day.

On-chain. One defensible implementation runs SubscriptionEscrow in one of two modes, fixed at deployment, both through subscribe():

• Exempt mode — counts money raised per offer jurisdiction against that jurisdiction's threshold. The subscription that would cross the line reverts.
• Prospectus mode — the same arithmetic against one offer-wide ceiling.

A jurisdiction nobody configured reverts too, on its own error, rather than falling back to the EU baseline. A permissive default is an uncapped offer that looks configured.

The country is not supplied by the caller. subscribe() takes no jurisdiction argument; it reads jurisdictionOf() off IdentityRegistry, where a registrar wrote it after KYC. The party being gated does not get to name the gate. An unconfigured jurisdiction is a revert, not a fallback.

To know about what IdentityRegistry is, explore >> Identity & KYC Registry for tokenized securities

The money limb is not the only limb, and the second one is per person. 

Article 1(4)(b) takes an offer outside the Regulation where it is addressed to fewer than 150 natural or legal persons other than qualified investors, per Member State. That is a headcount, and it is countable. So the exempt path spends one unit of a Member State's allowance on a subscriber's first subscription and refuses once the allowance is gone.

Three details decide whether the counter means anything. It counts persons, not subscriptions, so several wallets belonging to one investor consume one unit and a repeat subscription consumes none which only works because the identity layer resolves wallets to a person key.

⚠️ And the person key alone is not enough — the attributes have to hang off it too. If the classification tier and the jurisdiction are stored per wallet, one investor can register wallet A as retail in one Member State and wallet B as professional in another. The counter is then charged to whichever country still has room, or skipped entirely on the professional wallet. Two limbs of this exemption are decided by fields that must therefore be per person, not per address, and a second wallet must either match the person's record or be refused. Qualified investors do not count at all, per the Article 2(e) read-across to the investor-classification tiers. And an unclassified subscriber is counted: resolving that unknown in the offer's favour is how a headcount exemption quietly stops being one.

One caveat worth stating rather than glossing. 

What the contract counts is subscription attempts that reached it. The Article counts persons the offer was addressed to, which is a larger set including everyone who saw the offer and did not subscribe. The counter is therefore a floor on the real figure, and the marketing-side control in section 8 is where the rest of it lives.

Crossing the threshold does not move the contract into prospectus mode by itself. Approval comes before an offer, not after it. Switching modes is a deliberate off-chain event — a fresh, approved prospectus.

Partial. Each national threshold as configuration, one per jurisdiction, never a global constant. And which figure binds depends on when the offer launched, because the Listing Act phased in across three tranches.

Off-chain. Confirming which ceiling each offer jurisdiction elected. No register exists for a contract to read.

2. The content standard, and one decision it brings forward

Applies once a prospectus is required at all. An exempt offer still owes a national disclosure document in most Member States, but not this content standard.

Article 6(1) requires the information necessary for an informed assessment of the issuer's financial position, the rights attaching to the securities, and the reasons for the issuance. The detailed items sit in the Annexes to Commission Delegated Regulation (EU) 2019/980. Article 16(1) requires risk factors to be specific, material, substantiated, organized most-material-first, and prohibits generic risk factors used as disclaimers.

Neither Article names a token, a chain or an architecture. There is no tokenization-specific disclosure Article in this Regulation. 

The token-specific items like

• the network and whether it is permissioned,
• the consensus mechanism, the token standard,
• contract addresses and audit history,
• the identity and KYC mechanism,
• the upgrade mechanism and who can trigger it,
• recovery for lost keys and contract bugs,
• the custody model and custodian-failure path,
• post-issuance transfer mechanics,
• tax treatment per jurisdiction,
• and contract / oracle / bridge / congestion risk are how those two generic Articles read for this asset class.

This section is drafting work — nothing here gates a transfer. It produces one hard build constraint anyway. The token standard and the chain are prospectus content items. Once disclosed they are part of what the prospectus says the security is. So changing either afterwards is a material change that pulls in the supplement machinery below, withdrawal window attached. Treat both as prospectus-blocking decisions. A compliance mapping that stays portable across token standards does not make the disclosed standard portable.

And the item is the conformance claim, not just the standard's name. 

Saying a token implements a standard discloses that it implements all of it. Where a build conforms on part of a standard's surface and diverges on the rest, a common position, since these standards were not written against this rulebook. The divergence belongs in the same sentence as the claim. An unqualified claim of compliance that turns out to be partial is a defect in a disclosure document. And the cure is the supplement machinery below with its withdrawal window attached, not a patch release.

Off-chain

Contract addresses, verified source, audit history and governance state have to be extracted into the disclosure items which puts the audit report on the prospectus critical path.

3. The prospectus has a shelf life — Article 12

Bites hardest where a contract accepts subscriptions over an extended period. An offer that fills and closes inside a few weeks barely touches it.

Article 12 sets validity at twelve months from approval, and only while the prospectus remains completed by any supplements. The same cycle applies to a base prospectus and to a universal registration document used as one.

For a traditional bookbuild this is close to academic. For a tokenized offer on an open subscription contract it is not: nothing in a mint call knows the prospectus behind it expired last month, and there is no ledger-native signal that anything is wrong. A permanently-open subscription contract is the default failure mode of an on-chain primary offer.

On-chain. We build the validity date into prospectusValidUntil. subscribe() checks it first and reverts past it, however much ceiling headroom is left. Extending it is extendProspectusValidity() — a governance call recording a fresh approval, not a switch to keep the offer open.

The date is only one of three limbs, and the other two are where a naive implementation sells against nothing. 

A prospectus is valid for twelve months, and only while it stays the current anchored document, and only once the authority has approved the version that is current. So subscribe() reads currentVersionHash() — nothing anchored, and it reverts — and then reads the approval on that hash. Anchored is not approved. Anchoring writes no approval time; a current-but-unapproved version is a draft, and a contract that accepts it is selling against a document the authority has not seen. Check the clock alone and the contract keeps selling against a prospectus that was withdrawn or superseded, and passes every test while it does it.

The twelve months run from the base prospectus's approval, not from the latest approval on the slot.

Article 12's clock starts at approval, and a supplement is approved too. So a validity date anchored to whichever approval happened most recently restarts the clock every time a supplement lands, and an offer that supplements twice a year never expires. The bound is checked against the base approval at every subscription rather than only at deployment. Because the approval is normally recorded after the escrow is live.

4. Publishing it — Article 21

Applies to every approved prospectus. The six-working-day limb attaches only to an initial offer of a class of shares being admitted to a regulated market for the first time.

Article 21(1) requires the approved prospectus to be available to the public a reasonable time in advance of, and at the latest at the beginning of, the offer or admission. For an initial offer of shares admitted to a regulated market for the first time, it must be available at least six working days before the end of the offer. Article 21(2) requires publication on a dedicated, easily identifiable website section, free of charge and downloadable, and filing with the home authority's storage mechanism. Article 21(7) requires the prospectus and final terms to stay available electronically for at least ten years.

On-chain. DocumentRegistry.anchorVersion() pushes a Version onto that document's history, on the ERC-1643 pattern. The struct is worth reading because every later check in this article reads one of its fields:

struct Version {
    bytes32 versionHash;  // the document's own hash
    bytes32 uriHash;      // hash of where it is hosted
    uint64  anchoredAt;
    uint64  approvedAt;   // regulator approval; 0 = none recorded
    ...
}

The file stays off-chain — nothing in Article 21(7) argues for putting it on. currentVersionHash() gives the live version. documentStatus() gives the two fields most gates want: does this hash exist, and is approvedAt non-zero.

The ten-year duty splits cleanly. 

Keeping the document reachable is the hosting arrangement's job; proving which document it was is the anchor's. The history is append-only — there is no delete function — which is what makes the retention guarantee enforceable rather than recorded.

Partial. An offer-calendar feed for the six-working-day lead-in.

Off-chain. Hosting that lasts ten years. Publication and filing. Read with the windows below, the offer runs three independent clocks. The six-working-day lead-in, up to five working days of supplement approval, and withdrawal windows that may overlap and none is derivable from the others. Model the timeline explicitly.

5. Keeping it current — Article 23 supplements

Applies to a factor arising between approval and the later of offer close or start of trading and to nothing outside that window. This is the section most often read as permanent. It is not.

Article 23 requires a supplement whenever a significant new factor, material mistake or material inaccuracy arises between approval and the closing of the offer period or the start of trading, whichever is later. 

Then, Article 23(1) gives the competent authority up to five working days to approve it. and Article 23(2) gives investors who already agreed to subscribe before publication a right to withdraw within a minimum of three working days. Extended from two by the Listing Act, in force since 4 December 2024, and not limited to retail. 

Article 23(3) requires affected investors to be notified electronically by the end of the first working day after publication.

The engineering consequence is heavier than three days suggests. A primary subscription cannot be atomically final while a supplement window is open.

On-chain. subscribe() takes the cash, records the investor, the amount and an acceptedAt timestamp, and holds the cash in escrow. publishSupplement() opens a window over every subscription accepted before that publication; inside it, withdrawAcceptance() refunds the subscriber in full and marks the record withdrawn. Windows are held as a set of records against the offer, not one nullable window on a token, because the second window below is independent and may overlap.

The escrow issues no units, and that is worth being exact about, because the obvious design does. 

The intuitive build mints on acceptance into a pending, non-transferable state and burns on withdrawal — the pending state is a real capability, and the architecture specifies it. It is not what this contract does. It holds cash against a subscription record and refunds it; the unit mint happens at settlement, through the token's own gated path, off the escrow entirely.

Two consequences follow, and only the first is a simplification. A withdrawal is a refund, with nothing to burn and no partition state to unwind. And no transfer hook runs on the way in — so the escrow has to make the eligibility and restriction reads itself rather than inheriting them from a mint. subscribe() therefore runs the identity registry's eligibility check and the restriction store's block check on the subscriber directly. Without them the contract accepts and refunds cash from a wallet the token would have refused, which is a payment relationship with a restricted party conducted entirely inside the compliance perimeter.

SubscriptionEscrow reads DocumentRegistry before it will open the window. 

Built as two unrelated transactions, anchoring and window-opening drift apart in both directions: anchor the supplement and forget the escrow call → no withdrawal window opens, a breach the contract reports as a clean offer; open a window with nothing filed → a withdrawal period runs against a document no investor was given. So publishSupplement() calls documentStatus() and reverts unless the hash exists and carries a non-zero approvedAt.

That closes one direction only. Nothing on-chain can force the escrow call once a supplement is anchored — both sit behind the same governance key, so this is the system refusing to contradict itself, not a defense against an attacker. The other direction is made visible by an event: publishSupplement() emits the hash and approval time, and an indexer joins that against the registry's anchoring events and alarms on a supplement with no window. Caught off-chain or not at all.

Upgrades sit inside this Article too. A material change to contract behavior — transfer restrictions, fee logic, redemption mechanics — changes what the prospectus says the security is: supplement, approval, publication, window, then the change. Raising the disclosed offer ceiling is the same thing in a smaller package.

To know about what IdentityRegistry is, explore >> Transfer restrictions for tokenized securities

But note what is being approved. The competent authority approves the supplement. It never sees the contract; nothing in this Regulation has a regulator approve a deployment.

What	Who decides	What it covers
Article 23(1), five working days	the competent authority	the supplement document
the multisig signing the upgrade	the issuer	the upgrade
approvedAt in DocumentRegistry	nobody — it is a record	that the first one happened

Only the middle row authorizes a code change, and it is not a regulator's.

Nothing on the upgrade path reverts on the document, and that is deliberate. 

The gate that suggests itself — a contract holding the queuing role, reading documentStatus() and refusing an unapproved hash — is the wrong control here. Three reasons, and the second is decisive:

• It proves less than it looks. It can verify that some approved document exists, never that it describes this change — that link is a human judgment, and a signer in a hurry satisfies the gate with last month's supplement. It defeats forgetting, not rushing.
• It can be switched off without anything looking wrong. Grant the queuing role to the multisig as a fallback, or open execution to any address as most timelock tutorials show, and the check is gone with no on-chain symptom. A control that can be off without appearing off is worse than a documented manual step, because it is believed.
• The timelock already carries the evidence, for free. OpenZeppelin's TimelockController.schedule() takes an arbitrary salt and emits it. The document hash goes there. It is bound into the operation identifier — unchangeable after scheduling, and a different salt at execution derives an identifier the timelock does not recognize. A purpose-built gate adds a contract to the upgrade path to prove something the stock one already proves.

Evidence, not enforcement — and that leaves two things easy to leave unowned.

So the disclosure link survives as evidence rather than enforcement, read by an off-chain reconciliation job that alarms when a scheduled operation's salt resolves to nothing approved. Detective, not preventive. Nothing reverts. Two things are then easy to leave unowned. A reconciliation job with no named owner is a script, not a control; and a document withdrawn during the timelock delay is caught only by a guardian holding the cancel role, because nothing re-reads it. The line between this and the escrow check above is the right one. A publication event either happened or it did not, and a contract can compute that; whether a code change is described by a document, it cannot, a gate that pretends otherwise turns a judgment into a green light.

The window closing does not retire the reconciliation. 

A later upgrade owes no supplement, but the ongoing-disclosure regimes ask the same question of the same upgrades. What changes is which document belongs in the salt.

Partial. The publication event starts the clock. Notification runs off the escrow's pending set. Working-day arithmetic is fed in, not calculated, a contract cannot know a given Thursday is a national holiday.

Off-chain. A materiality assessment on every proposed change, plus the filing. The five working days is a lead time, and it does not overlap an upgrade timelock, approval and publication complete first. The critical path is five working days, plus the timelock, plus whichever window publication opens. Budget upgrade windows in weeks.

6. The second withdrawal right — Article 17

Applies where the prospectus omits the final offer price or the final amount of securities. A fixed price disclosed at filing never triggers it; a valuation-priced or book-built offer does.

This is the one most tokenized real-world-asset offers actually trigger, and it is independent of the supplement mechanism.

Where the prospectus omits final price or amount, Article 17 puts two things in play.

• a right to withdraw for a minimum period after the final price or amount is filed and published, and
• disclosure of the maximum price or the valuation method.

The filing-and-publication event — filed with the home authority, published through the Article 21(2) arrangements — starts the clock.

This fires on the offer's ordinary path, where the supplement right fires only if a supplement is published. 

A tokenized property or private-credit offer priced off an independent valuation struck at close is the ordinary fact pattern — so a contract built only for the supplement right misses this one entirely.

On-chain. publishFinalPrice() opens a second window. Reachable only if finalPriceOmittedAtFiling was set true at deployment; otherwise it reverts, because a price fixed at filing can never trigger this right. Unlike Window A, this one covers every subscription in the offer — all were accepted against an incomplete price.

Two rules follow

• a subscription is withdrawable if any window covering it is open, and
• settlement waits for all applicable windows to close.

The two durations are separate parameters and must not share a constant. 

Different Articles, different triggers; collapsing them is the bug that looks like tidiness. The statutory floor here is at least two working days, against three for a supplement. This build floors both at three, which is a conservative implementation choice rather than the Regulation's figure, and it is the conservative side to be on. Over-holding escrow costs UX, under-holding it is a statutory breach. Both durations are floors enforced on the window-opening call, and both are configurable, because a minimum is something an operator may extend and because working-day arithmetic is fed in against a real calendar rather than computed from block time.

One question for counsel before you build, because it changes the contract. The Article presents the maximum-price disclosure and the withdrawal right in a structure that reads either as cumulative or as alternatives. On the second reading, this window disappears for offers priced off a disclosed maximum — a pricing-structure decision with a direct contract consequence. Get the answer before the first prospectus offer opens.

7. Someone signs their name to it — Article 11

Applies to every prospectus, with no carve-out. There is nothing here to scope out of and nothing to build.

Article 11(1) requires a responsibility statement naming the persons responsible — the issuer or its administrative, management or supervisory bodies, the offeror, the person seeking admission, or the guarantor. Article 11(2) requires Member States to apply their civil-liability laws to those persons for information that is inaccurate or misleading.

For a tokenized security the prospectus's subject matter is substantially the contract's own behavior. The people who sign are personally exposed, under national civil-liability law, to any gap between what the prospectus discloses and what the deployed contract does.

On-chain. Nothing, and that is worth stating rather than leaving blank. Article 11 asks for a statement in a document, not a control in a contract; no contract above discharges any part of it. What it supplies is the reason the disclosure discipline above gets maintained. Personal liability attaching to named individuals is the real enforcement mechanism behind "the prospectus must match the contract," in a Regulation where the authority's approval of a supplement is expressly not an endorsement that the disclosure is correct.

It also constrains the multisig, and this is easy to miss. 

Article 11(1) names specific persons; a multisig is a set of keys. If a threshold reachable without any named responsible person can execute an upgrade that moves deployed behavior away from disclosed behavior, those persons carry liability for a change they did not authorize.

It resolves one of two ways.

The threshold cannot be met without a named responsible person, or every named responsible person holds the cancel role directly. A composition rule, not a contract feature.

Off-chain. Drafting the statement and collecting the declarations. The signatories need to understand both the disclosure standard and who holds upgrade authority, because what they are underwriting is the match between the document and the deployed bytecode.

8. Advertising it — Article 22

Applies to every communication about an in-scope offer, whether or not it was meant as advertising.

Article 22(3) requires advertisements to be clearly recognizable as such, to reference the prospectus, and not to be inaccurate, misleading or inconsistent with it. Article 22(4) extends the consistency duty to information disclosed orally or in writing about the offer, whether or not intended as advertising.

Nothing here gates a transfer, so this is a human process. What gets underestimated is the reach: founder social posts, pitch decks and podcast appearances sit inside Article 22(4) alongside the formal materials.

Off-chain. Per-country blocking on offer and marketing pages wherever no public offer is made — a platform control, not a contract one. A jurisdiction gate stops a subscription; this Article reaches the communication before it. And a marketing sign-off gate against the prospectus, scoped to the informal channels as well as the formal ones.

9. What this costs the settlement design

Applies wherever either window in sections 5 and 6 can open. An offer that can trigger neither can settle primary issuance atomically.

One consequence compounds across sections 5 and 6 and is easy to discover late. The cash leg for all primary issuance under a prospectus — professional as well as retail — has to stay refundable for every applicable window. An irreversible settlement leg at acceptance cannot satisfy that, which is why settle() is the only path that releases cash to the issuer, and why it is gated rather than automatic.

"No window is open" is not the same statement as "no window will open", and that distinction is the whole gate. 

Both withdrawal rights arise from events that happen after acceptance — a supplement published, a final price filed. So a settlement rule that waits only for windows already opened lets a subscription be released one block after it was accepted, and the right is gone before the event that would have triggered it. On a valuation-priced offer that is every subscriber in the offer.

So settlement waits on three conditions, in the order a reviewer asks them. Has the offer closed? The supplement duty, and the withdrawal right it opens, run until the offer closes or trading starts — so nothing accepted during the offer is final before then. The close is fed in by governance and can only ever be extended, and subscriptions are refused after it. So a late subscriber cannot be settled in the same block through another door. 

Where the final price was omitted at filing, has it been published? Window B cannot have run if it has not opened. And is any window covering this subscription still open or still to open? Only after all three does "no window covers it" mean what it appears to mean.

The second window compounds it because it covers the whole offer, a valuation-priced offer holds 100% of subscribed cash refundable for several working days after pricing. Size the settlement asset and liquidity arrangements for that, not for a partial-withdrawal scenario. It is a primary-issuance constraint only — secondary trading stays atomic.

If you're evaluating a compliance-first architecture like this one for a live issuance, that's the kind of build our RWA tokenization development company takes on end-to-end.

At a glance

Article	On-chain	Partial	Off-chain
Art 1(2)(a) — open-ended exclusion	SubscriptionEscrow windows and validity expiry drop out; DocumentRegistry does not	—	Settle open- vs closed-ended first
Art 3(2) — €12m/12 months, or €5m where elected	subscribe() — per-jurisdiction counter; reverts at the ceiling	National threshold per jurisdiction; tranche by launch date	Confirm which ceiling each jurisdiction elected
Art 1(4)(b) — under 150 non-qualified persons per Member State	Counted per person, spent on first subscription; qualified investors excluded, unclassified counted; never decremented	Jurisdiction and tier from the identity record, and both must be stored per person, not per wallet — otherwise the counter is charged to whichever Member State still has room	It counts subscription attempts, which is a floor on "addressed to" — the marketing control carries the rest
Art 6 / 16(1) — content and risk factors	—	—	Addresses, verified source, audit history and governance state extracted into the disclosure items; drafting. Makes token-standard and chain choices prospectus-blocking
Art 12 — twelve-month validity	subscribe() reads prospectusValidUntil, currentVersionHash() and the approval on it — anchored is not approved; validity bounded by the base prospectus's approval so a supplement cannot restart the clock. Eligibility and restriction checks run on the subscriber	—	Track the approval date; re-approve before any continuation
Art 21(1), (2), (7) — publication, ≥10 years	anchorVersion() — hash, URI hash, approvedAt; append-only, no delete function	Offer-calendar feed for the six-working-day lead-in	Hosting; publication and filing. Three independent clocks
Art 23 — supplement, 5 WD approval, 3 WD withdrawal, next-day notice. Binds only until the later of offer close / start of trading	publishSupplement() opens Window A; withdrawAcceptance() refunds the cash — no token is minted or burned; documentStatus() refuses an unapproved hash; the window has an enforced minimum duration. Upgrade path: nothing reverts — hash rides as the timelock salt	Publication event as clock start; working-day calendar; notification off the pending set. Salt reconciliation needs a named owner	Materiality per change; filing. Timelock does not run concurrently
Art 17 — second, independent withdrawal right	publishFinalPrice() opens Window B over the whole offer; separate duration floor — statutory ≥2 WD, built at 3	Final price/amount filing as clock start	Counsel: cumulative or alternative — decides whether Window B exists
Settlement — the release gate the two rights imply	Waits on a governance-fed, extend-only offer close, on the final price where one was omitted, and on every window open or pending. subscribe() refuses after the close	Offer close and final-price publication as fed events	Nothing settles the day it is accepted, and the offer close is a real date somebody owns
Art 11 — responsibility statement, personal liability	— no contract discharges any part of it	—	Drafting and declarations. A multisig threshold reachable without any named person is an unowned liability
Art 22 — advertising, extended to oral statements	—	—	Per-country blocking on offer and marketing pages; sign-off gate covering founder posts, decks and podcasts

This is engineering commentary on regulatory requirements, not legal advice. Whether and how these obligations apply to a specific offer structure needs sign-off from counsel.