The money limb is not the only limb, and the second one is per person.<\/strong> <\/h3>\n\n\n\nArticle 1(4)(b)<\/strong> 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<\/strong>. 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<\/em> subscription and refuses once the allowance is gone. <\/p>\n\n\n\nThree details decide whether the counter means anything. It counts persons, not subscriptions<\/strong>, 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. <\/p>\n\n\n\n\u26a0\ufe0f And the person key alone is not enough \u2014 the attributes<\/em> have to hang off it too.<\/strong> 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<\/strong>, per the Article 2(e) read-across to the investor-classification tiers. And an unclassified<\/strong> subscriber is<\/em> counted: resolving that unknown in the offer's favour is how a headcount exemption quietly stops being one.<\/p>\n\n\n\nOne caveat worth stating rather than glossing. <\/strong><\/h3>\n\n\n\nWhat the contract counts is subscription attempts that reached it. The Article counts persons the offer was addressed to<\/em>, 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.<\/p>\n\n\n\nCrossing the threshold does not move the contract into prospectus mode by itself.<\/strong> Approval comes before an offer, not after it. Switching modes is a deliberate off-chain event \u2014 a fresh, approved prospectus.<\/p>\n\n\n\nPartial.<\/strong> Each national threshold as configuration, one per jurisdiction, never a global constant. And which figure binds depends on when the offer launched<\/strong>, because the Listing Act phased in across three tranches.<\/p>\n\n\n\nOff-chain.<\/strong> Confirming which ceiling each offer jurisdiction elected. No register exists for a contract to read.<\/p>\n\n\n\n2. The content standard, and one decision it brings forward<\/strong><\/h2>\n\n\n\nApplies 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.<\/em><\/p>\n\n\n\nArticle 6(1)<\/strong> 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)<\/strong> requires risk factors to be specific, material, substantiated, organized most-material-first, and prohibits generic risk factors used as disclaimers.<\/p>\n\n\n\nNeither Article names a token, a chain or an architecture. There is no tokenization-specific disclosure Article in this Regulation.<\/strong> <\/p>\n\n\n\nThe token-specific items like <\/p>\n\n\n\n
\n- the network and whether it is permissioned, <\/li>\n\n\n\n
- the consensus mechanism, the token standard, <\/li>\n\n\n\n
- contract addresses and audit history, <\/li>\n\n\n\n
- the identity and KYC mechanism, <\/li>\n\n\n\n
- the upgrade mechanism and who can trigger it, <\/li>\n\n\n\n
- recovery for lost keys and contract bugs, <\/li>\n\n\n\n
- the custody model and custodian-failure path, <\/li>\n\n\n\n
- post-issuance transfer mechanics, <\/li>\n\n\n\n
- tax treatment per jurisdiction, <\/li>\n\n\n\n
- and contract \/ oracle \/ bridge \/ congestion risk are how those two generic Articles read for this asset class.<\/li>\n<\/ul>\n\n\n\n
This section is drafting work \u2014 nothing here gates a transfer. It produces one hard build constraint anyway. The token standard and the chain are prospectus content items.<\/strong> Once disclosed they are part of what the prospectus says the security is<\/em>. So changing either afterwards is a material change that pulls in the supplement machinery below, withdrawal window attached. Treat both as prospectus-blocking decisions<\/strong>. A compliance mapping that stays portable across token standards does not make the disclosed<\/em> standard portable.<\/p>\n\n\n\nAnd the item is the conformance claim, not just the standard's name. <\/strong><\/h3>\n\n\n\nSaying 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.<\/p>\n\n\n\n
Off-chain<\/strong><\/p>\n\n\n\nContract 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.<\/p>\n\n\n\n
3. The prospectus has a shelf life \u2014 Article 12<\/strong><\/h2>\n\n\n\nBites hardest where a contract accepts subscriptions over an extended period. An offer that fills and closes inside a few weeks barely touches it.<\/em><\/p>\n\n\n\nArticle 12<\/strong> 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.<\/p>\n\n\n\nFor 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.<\/strong><\/p>\n\n\n\nOn-chain.<\/strong> We build<\/strong> the validity date into prospectusValidUntil<\/code>. subscribe()<\/code> checks it first and reverts past it, however much ceiling headroom is left. Extending it is extendProspectusValidity()<\/code> \u2014 a governance call recording a fresh approval, not a switch to keep the offer open.<\/p>\n\n\n\nThe date is only one of three limbs, and the other two are where a naive implementation sells against nothing. <\/strong><\/h3>\n\n\n\nA prospectus is valid for twelve months, and<\/strong> only while it stays the current anchored document, and<\/strong> only once the authority has approved the version that is current. So subscribe()<\/code> reads currentVersionHash()<\/code> \u2014 nothing anchored, and it reverts \u2014 and then reads the approval on that hash. Anchored is not approved.<\/strong> 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.<\/p>\n\n\n\nThe twelve months run from the base<\/em> prospectus's approval, not from the latest approval on the slot.<\/strong><\/h3>\n\n\n\nArticle 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.<\/p>\n\n\n\n
4. Publishing it \u2014 Article 21<\/strong><\/h2>\n\n\n\nApplies 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.<\/em><\/p>\n\n\n\nArticle 21(1)<\/strong> 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<\/strong>. Article 21(2)<\/strong> 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)<\/strong> requires the prospectus and final terms to stay available electronically for at least ten years<\/strong>.<\/p>\n\n\n\nOn-chain.<\/strong>\u00a0DocumentRegistry.anchorVersion()<\/strong>\u00a0<\/mark>pushes a\u00a0Version<\/code>\u00a0onto 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:<\/p>\n\n\n\nstruct Version {\n bytes32 versionHash; \/\/ the document's own hash\n bytes32 uriHash; \/\/ hash of where it is hosted\n uint64 anchoredAt;\n uint64 approvedAt; \/\/ regulator approval; 0 = none recorded\n ...\n}\n<\/code><\/pre>\n\n\n\nThe file stays off-chain \u2014 nothing in Article 21(7) argues for putting it on. currentVersionHash()<\/code> gives the live version. documentStatus()<\/code> gives the two fields most gates want: does this hash exist, and is approvedAt<\/code> non-zero.<\/p>\n\n\n\nThe ten-year duty splits cleanly. <\/strong><\/h3>\n\n\n\nKeeping the document reachable is the hosting arrangement's job; proving which document it was is the anchor's. The history is append-only \u2014 there is no delete function<\/strong> \u2014 which is what makes the retention guarantee enforceable rather than recorded.<\/p>\n\n\n\nPartial.<\/strong> An offer-calendar feed for the six-working-day lead-in.<\/p>\n\n\n\nOff-chain.<\/strong> Hosting that lasts ten years. Publication and filing. Read with the windows below, the offer runs three independent clocks<\/strong>. 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.<\/strong> Model the timeline explicitly.<\/p>\n\n\n\n5. Keeping it current \u2014 Article 23 supplements<\/strong><\/h2>\n\n\n\nApplies 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.<\/em><\/p>\n\n\n\nArticle 23<\/strong> 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. <\/p>\n\n\n\nThen, Article 23(1)<\/strong> gives the competent authority up to five working days to approve it. and Article 23(2)<\/strong> gives investors who already agreed to subscribe before<\/em> 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. <\/p>\n\n\n\nArticle 23(3)<\/strong> requires affected investors to be notified electronically by the end of the first working day after publication.<\/p>\n\n\n\nThe engineering consequence is heavier than three days suggests. A primary subscription cannot be atomically final while a supplement window is open.<\/strong><\/p>\n\n\n\nOn-chain.<\/strong> subscribe()<\/code> takes the cash, records the investor, the amount and an acceptedAt<\/code> timestamp, and holds the cash in escrow. publishSupplement()<\/code> opens a window over every subscription accepted before that publication; inside it, withdrawAcceptance()<\/code> 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.<\/p>\n\n\n\nThe escrow issues no units, and that is worth being exact about, because the obvious design does. <\/strong><\/h3>\n\n\n\nThe intuitive build mints on acceptance into a pending, non-transferable state and burns on withdrawal \u2014 the pending state is a real capability, and the architecture specifies it. It is not what this contract does.<\/strong> 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. <\/p>\n\n\n\nTwo 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<\/strong> \u2014 so the escrow has to make the eligibility and restriction reads itself rather than inheriting them from a mint. subscribe()<\/code> 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.<\/p>\n\n\n\n