{"id":5438,"date":"2026-09-15T09:57:28","date_gmt":"2026-09-15T09:57:28","guid":{"rendered":"https:\/\/www.innblockchain.com\/academy\/?p=5438"},"modified":"2026-09-16T12:23:14","modified_gmt":"2026-09-16T12:23:14","slug":"transfer-restrictions-for-tokenized-securities-smart-contract-architecture","status":"publish","type":"post","link":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture","title":{"rendered":"Transfer Restrictions for Tokenized Securities: Smart Contract Architecture"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">A compliant tokenized security has one structural feature everything else depends on:&nbsp;<strong>a call that can reject a transfer before it executes, consulting arbitrary external logic.<\/strong>&nbsp;Without it, nothing in any EU regime is enforceable on-chain \u2014 every rule about who may hold, who may receive, and under what conditions has nowhere to attach.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This article covers that gate and the modules immediately around it:\u00a0<code>SecurityToken<\/code>,\u00a0<code>ModularCompliance<\/code>,\u00a0<code>ModuleAdapter<\/code>, and the narrow per-rule gates that plug into it. The wider architecture \u2014 the capability set, the module inventory, and how many instances of each you deploy \u2014 is in the\u00a0<strong><a href=\"https:\/\/www.innblockchain.com\/academy\/eu-compliant-tokenized-securities-smart-contract-architecture\" data-type=\"link\" data-id=\"https:\/\/www.innblockchain.com\/academy\/eu-compliant-tokenized-securities-smart-contract-architecture\" target=\"_blank\" rel=\"noreferrer noopener\">EU-Compliant Tokenized Securities: Smart Contract Architecture<\/a><\/strong>\u00a0pillar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>The hook has a name, and it is worth fixing before anything else.<\/strong>&nbsp;It is&nbsp;<code>ICompliance.canTransfer(from, to, amount)<\/code>.&nbsp;<code>SecurityToken<\/code>(the token contract) calls this function on every movement and treats its answer as final,&nbsp;<code>ModularCompliance<\/code>(the rule engine) implements it. Each individual rule module plugs into ModularCompliance behind it. Where the sections below say&nbsp;<em>the gate<\/em>, that is the function they mean.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>ICompliance<\/code>&nbsp;is ERC-3643's interface, and this article assumes that choice rather than arguing it.&nbsp;<strong>Which standard to build on \u2014 and what conforming to one does and does not buy you \u2014 is its own article<\/strong>, because the answer is decided before any of the wiring below exists.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The gate is also the single easiest place in the architecture to over-build, and the mistakes are not obvious. Three of the four sections below are about what to keep&nbsp;<em>off<\/em>&nbsp;it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>1. First: check whether the anti-money-laundering rules reach you at all<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The anti-money-laundering regime binds&nbsp;<strong>obliged entities<\/strong>, and the category list is specific: investment firm, credit or financial institution, payment or e-money institution, fund manager, crypto-asset service provider, crowdfunding provider.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\"Issuer of securities\" is not on that list.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This is a test of what license the entity holds, not what the entity actually does day to day (<strong>entity test, not a conduct test<\/strong>) \u2014 verify it against the operating entity's own licence, not against the activity it performs. A genuinely unlicensed pure issuer sits outside the regime and is caught only if it is independently one of the listed entity types. The moment any licence is held, it attaches in full, and once that license is held, the obligations cannot later be dropped.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>This is a scoping correction, not permission to defer the module.<\/strong>&nbsp;Build the screening regardless \u2014 targeted financial sanctions obligations bind everyone irrespective of anti-money-laundering status, and that is a separate regime with its own basis. What changes is the citation. If your documentation maps a screening control to a specific anti-money-laundering Article (an 'Article-to-function map' \u2014 the document showing which law maps to which piece of code), but your entity isn't actually on the obliged-entity list, that citation is simply wrong \u2014 a defect your regulator will find when reviewing that document.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Note also that the current regime applies from&nbsp;<strong>10 July 2027<\/strong>. Until then the operative rules are the previous directive as transposed in your Member State. The obligations survive the transition in substance; the citations do not.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>2. The gate must not say why it refused<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is the constraint that surprises engineers, and a naive implementation commits a criminal offence rather than a compliance failure.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tipping-off is prohibited: no disclosure to the customer or any third party that a suspicious-transaction report has been filed,&nbsp;<strong>is being prepared<\/strong>, or that the customer is under analysis. In most Member States it is an individual criminal offence, and it covers the preparation stage \u2014 not just a filed report.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Now consider what an on-chain block looks like from the customer's side. A transfer reverts with a named reason, or a\u00a0<code>WalletFrozen(address, reason)<\/code>\u00a0event lands in a public block.\u00a0<strong>A specific, labeled error message (a 'typed revert reason'), or a public log entry that carries a reason, counts as a disclosure<\/strong>. And on a public ledger it is a disclosure to the customer\u00a0<em>and to everyone else watching<\/em>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Three rules follow, and each one has to survive contact with whatever the token standard does by default:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Two classes of refusal, and a module author picks one before writing an error.<\/strong>\u00a0<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The naive rule \u2014 one generic code for every block \u2014 is over-broad, and collapsing everything into \"not compliant\" throws away exactly what an audit reviewer and a support desk need and cannot recover afterwards. The line is drawn by what the block\u00a0<em>is<\/em>, not by which module raised it.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Informative.<\/strong>\u00a0A holding period, a closed period, a missing acknowledgement, a lapsed due-diligence record, a claim the investor has not yet obtained. Each is a fact about the instrument or the record, applies to everyone in the same position, and is something the holder can cure or wait out. Those errors may name their Article and what would satisfy them. An unlock date is not a suspicion, and telling a holder when they may exit is a service.<\/li>\n\n\n\n<li><strong>Opaque.<\/strong>\u00a0A sanctions listing, a suspicion block, a probate hold, a court attachment, an operational hold pending investigation.\u00a0<strong>One argument-free error, the same one for every reason in the class<\/strong>\u00a0\u2014 not even a wallet address, because on a two-sided check that says which side failed. The moment a distinct code exists for the suspicion case,\u00a0<strong>the code is the tip-off.<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A module unsure which class it is in is in the opaque class.<\/strong>&nbsp;The two mistakes do not cost the same: over-disclosing is a criminal offence, under-disclosing is a support ticket.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>A generic error is not enough on its own \u2014 the storage has to be generic too.<\/strong>\u00a0<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Write sanctions listings to one variable and probate holds to another, and anyone can read the contract's state and recover the reason from which variable is set, whatever the revert said. The error discloses nothing; the storage layout discloses everything. Every opaque-class stop therefore has to live in\u00a0<strong>one store<\/strong>, behind one flag, with the reason held off-chain.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>No reason code in freeze events.<\/strong>&nbsp;The reason belongs in the off-chain case file, not in an event topic anyone can index.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>A suspicion block and a sanctions freeze must look identical on-chain.<\/strong>\u00a0<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">You are separately required to be able to refrain from executing a suspicious transaction, and to do it without the customer learning why. Sanctions freezes are publicly justifiable; suspicion blocks are not. Same mechanism, same observable behaviour, different case file.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>The interface does this work for you, which is worth knowing before you build around it.<\/strong>\u00a0<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>canTransfer<\/code>\u00a0returns a bare boolean \u2014 pass or fail, with no room for a status code. That is an irritation for a support desk and exactly right here: the gate cannot disclose a reason to the caller even where a module author wants it to. So the interface itself makes opacity automatic because it only allows true\/false, a developer can't accidentally leak a reason even if they wanted to; it isn't a rule reviewers have to keep checking for by hand.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>But a bare boolean tells an informative-class holder nothing either \u2014 no unlock date, no Article, no cure.<\/strong>\u00a0<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Both classes have to coexist on one gate, and the way they do is two entry points on the same engine.\u00a0<code>canTransfer<\/code>\u00a0returns the boolean and is authoritative: if it says no, the movement does not happen. A second, reverting check re-runs the same module walk\u00a0<strong>only after the boolean has already refused<\/strong>, purely to recover an explanation. Where the failing module is informative-class, the holder gets its Article and what would satisfy it. Where it is opaque-class, that module's single argument-free error is all there is to recover, so the holder learns exactly nothing \u2014 which is the requirement, not a gap.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Two properties keep that safe rather than clever.&nbsp;<strong>The boolean decides and the reason path never overrides it<\/strong>&nbsp;\u2014 so an explanation path that is absent, unwired or broken is a downgrade in explanation and never in enforcement. And&nbsp;<strong>nothing in the engine enforces the classification<\/strong>: an opaque-class module that reverts with a typed error compiles and runs. The class label therefore belongs on the module itself, in source, so the audit map can be read off without reading every error in the tree.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>3. Claims expire, and expiry has to fail closed<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Periodic due-diligence refresh runs on a documented, risk-tiered cadence \u2014 annual for high risk, three to five years for low. Separately, where due diligence cannot be completed, you must stop transacting.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Together those mean the eligibility claim carries a&nbsp;<strong>validity window<\/strong>, and the gate must treat an expired claim exactly as it treats a missing one.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>The window is mandatory at the write, not per issuer.<\/strong>\u00a0<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A claim registry that accepts \"no expiry\" has made the refresh cadence opt-in for whoever writes the claim, and one issuer choosing zero disables the control for every wallet it attests. So the write rejects a zero or past expiry outright and refuses anything further out than a governance-set ceiling, and the read collapses an expired claim to \"unasked question\" rather than to a silent pass.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The failure mode otherwise is silent and one-directional: an investor onboarded in year one keeps transferring in year four on a claim nobody re-verified, and&nbsp;<strong>nothing on-chain signals it<\/strong>. There is no natural event that fires when a claim goes stale.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Claim expiry fails closed<\/strong>&nbsp;\u2014 which has an operational consequence worth pricing before you ship it. Expiry now freezes a live position rather than generating a task, so the refresh workflow needs a service-level commitment behind it. A design that fails closed without a refresh SLA has moved a compliance risk onto your support desk.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Revocation is the harder version of the same problem. When a qualified attestation is revoked, that revocation is final and must reach the gate with immediate effect on transferability. On a single token that is straightforward. Across a platform running several tokenized assets it is a&nbsp;<strong>fan-out to several compliance instances<\/strong>, and a partial propagation leaves the same investor revoked on one asset and live on another. Decide whether that propagation has to be atomic before you deploy the second asset, not after.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>4. One claim that must\u00a0<em>not<\/em>\u00a0be on the transfer hook<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Every claim so far describes a&nbsp;<strong>continuing attribute<\/strong>&nbsp;of the investor \u2014 verified, screened, due diligence current. Gating every transfer on those is correct. Classification is a continuing attribute too and still does not belong here: the hook does not read tier, because a per-transfer tier gate would stop a retail holder&nbsp;<em>receiving<\/em>&nbsp;on a secondary market that never asked the question. Tier is read where it decides something \u2014 the subscription path, and the covenant predicates below.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The key-information-document delivery duty is different, and wiring it into the gate breaks it in two directions at once. It is a&nbsp;<strong>pre-contractual event<\/strong>: the document was delivered in good time before this investor became bound.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Gate the subscription path, not the transfer hook.<\/strong>&nbsp;Wiring it into the gate would freeze the live position of an investor who&nbsp;<em>was<\/em>&nbsp;properly served, and would block secondary transfers the duty never reached. It belongs alongside the suitability claim, on the same path as subscription acceptance.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>It is not a boolean, and it does not expire on a cadence.<\/strong>&nbsp;The claim binds the&nbsp;<strong>specific document version hash<\/strong>&nbsp;anchored in the document registry. An acknowledgement of version 1 is not an acknowledgement of the version 3 in force when the investor actually subscribes \u2014 so a revision invalidates outstanding acknowledgements. That is a re-issue trigger, not an expiry window.&nbsp;<strong>A boolean&nbsp;<code>kidDelivered<\/code>&nbsp;flag passes every test you will write and breaches the duty the first time the document is revised mid-offer.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That pattern \u2014 a covenant bound to a document version rather than a claim bound to a clock \u2014 is a capability in its own right, covered in the investor-covenants article.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>5. The rule engine, its cap, and its bypass<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Rules plug into the gate as individually addable, removable and upgradable modules. That modularity is not an engineering preference: your external audit needs a&nbsp;<strong>one-to-one map from Article to function<\/strong>, and a monolithic compliance function cannot produce one.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Two properties of the engine matter more than they look:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A hard cap on the module list.<\/strong>&nbsp;An unbounded list is a gas denial-of-service on the token itself, and the party who suffers is the holder trying to exit. The cap is a holder-protection control, not an optimisation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A logged, one-module-at-a-time emergency bypass.<\/strong>&nbsp;A module that reverts blocks every transfer. That is exactly correct when the module is exercising a veto, and catastrophic when the module has a bug. Without a bypass, a defect in one narrow rule freezes the entire register \u2014 and the fix requires an upgrade, which for a disclosed contract means a supplement, regulatory approval and an investor withdrawal window before it can deploy. Weeks, to fix a bug. The bypass has to be per-module, logged, and never a global off-switch.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Which is the reason one control cannot live on this list at all.<\/strong>&nbsp;Both levers above \u2014 remove a module, bypass a module \u2014 are one governance call, and a sanctions listing binds irrespective of anything governance decides. So the wallet-stop store is read by the token directly, above the module list, on&nbsp;<strong>every<\/strong>&nbsp;path that moves units: an ordinary transfer, a mint, and the agent-operated forced transfer. Leave forced transfer to reach the store only through the module list and the seizure path becomes the bypass \u2014 an agent key placing units on a listed person with nothing on-chain looking wrong.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>6. Adapters: narrow gates, no logic<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Each rule is written against one Article and reverts with errors named after it. The rule engine, meanwhile, wants one common signature.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The wrong resolution is to widen every gate to a shared interface \u2014 that blurs the Article-to-function map the audit depends on, which is the one thing modularity was bought for.&nbsp;<strong>Adapt at the boundary instead.<\/strong>&nbsp;A thin abstract base presents each narrow, single-purpose gate onto the engine's interface, so the gates themselves never have to be widened.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The adapters hold&nbsp;<strong>no logic of their own<\/strong>, and that rule is worth enforcing in review. Anything decided inside an adapter is a second place a reader has to look to find the Article \u2014 which is the exact legibility problem the pattern exists to solve.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The one place adapters legitimately differ is which sides they gate, and the zero address is where a careless one breaks. A holding-period lock restricts&nbsp;<em>exiting<\/em>, so it binds the sender and skips mint \u2014 a burn is in scope, a mint is not. A closed-period freeze passes both sides through. A covenant gate checks the recipient on a mint and both parties on a transfer, and on a&nbsp;<strong>burn checks the sender only<\/strong>&nbsp;\u2014 nobody is receiving, the zero address resolves to no investor, and a check that has no valid input to test deaults to 'refuse'. Wire a receive-scoped covenant without that carve-out and every redemption, buy-back burn and maturity burn in the instrument reverts, from a rule that was never about exits.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>7. What is\u00a0<em>not<\/em>\u00a0on the transfer hook<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The most expensive mistake available here is wiring fund-structure limits \u2014 concentration, diversification, borrowing ratios \u2014 into the transfer gate. It looks right. It is wrong, for four independent reasons,&nbsp;<strong>any one of which is sufficient<\/strong>:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>A peer-to-peer transfer moves neither capital nor the net-asset-value denominator.<\/strong>\u00a0The hook has nothing to test.<\/li>\n\n\n\n<li><strong>A mint raises the denominator and lowers every concentration ratio.<\/strong>\u00a0Vetoing subscriptions during a breach would block the remedy \u2014 the inversion that makes the control worse than nothing.<\/li>\n\n\n\n<li><strong>A suspension flag marks a window in which the limit is deliberately\u00a0<em>relieved<\/em>\u00a0during a capital raise.<\/strong>\u00a0It is not a trading halt. Gating mint on it is exactly backwards.<\/li>\n\n\n\n<li><strong>Mint and burn take cash amounts from the subscription path, not token unit amounts.<\/strong>\u00a0The two are not interchangeable, so the hook could not advance the state correctly even if it were wired.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Fund limits are gated by&nbsp;<strong>their own reverting subscription, redemption and position-recording functions<\/strong>. That satisfies the on-chain test perfectly well \u2014 something reverts on the state \u2014 just not through the transfer hook. Do not let an adapter be written to bridge them.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>8. The topology is a star, not a chain<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A common way to draw this architecture is a chain: token, then identity registry, then compliance engine. That reads as though the engine sits behind identity and can see it.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>It does not.<\/strong>&nbsp;The token calls the identity registry and the rule engine&nbsp;<strong>independently<\/strong>, and the rule engine holds no identity reference at all. Every module that needs an identity attribute wires its own.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The transfer check is four reads in sequence, and none of them is nested in another: the whole-address freeze on both sides, the identity gate on each present side, the wallet-stop store, and only then the rule engine. Four references held by one caller. The rule engine is the last of them and can see none of the other three \u2014 which is why a revoked claim has to be propagated to it rather than inherited by it.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That is a fan-out, and it is the same fan-out behind the revocation question in section 3 \u2014 a revoked claim has to reach every module-held reference, not one. Drawing it as a chain hides the question rather than answering it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>9. What not to build<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Five controls that look mandatory, are commonly built, and should not be:<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-stripes\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Do not build<\/th><th class=\"has-text-align-left\" data-align=\"left\">Why<\/th><\/tr><\/thead><tbody><tr><td>An on-chain cumulative due-diligence value counter<\/td><td class=\"has-text-align-left\" data-align=\"left\">The threshold it implements governs&nbsp;<strong>occasional transactions<\/strong>&nbsp;\u2014 parties you have no business relationship with. Establishing a business relationship triggers full due diligence on its own with no value threshold, so every investor you onboard has already cleared it before any counter could reach any figure. It enforces nothing and adds an accumulator to the audited surface<\/td><\/tr><tr><td>The crypto-asset-service-provider onboarding trigger<\/td><td class=\"has-text-align-left\" data-align=\"left\">This platform is never one. The instruments are financial instruments, and the crypto-asset regime expressly excludes them<\/td><\/tr><tr><td>The occasional-cash trigger<\/td><td class=\"has-text-align-left\" data-align=\"left\">A securities subscription is not a cash transaction<\/td><\/tr><tr><td>The cash-payment prohibition<\/td><td class=\"has-text-align-left\" data-align=\"left\">Securities are not cash<\/td><\/tr><tr><td>Travel Rule originator\/beneficiary fields on the security leg<\/td><td class=\"has-text-align-left\" data-align=\"left\">Financial instruments sit outside crypto-asset scope. The control here is due-diligence re-verification, not transfer-of-funds data<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>One carve-out on the last row, and it is a live trap.<\/strong>\u00a0Settle in e-money tokens and the Travel Rule comes back \u2014 e-money tokens are expressly treated as crypto-assets, which pulls the cash leg into full originator and beneficiary data collection with\u00a0<strong>no de minimis<\/strong>(no minimum transaction size below which the rule doesn't apply). The security leg stays out of scope; an atomic delivery-versus-payment settles both in one transaction. That is a consequence of the settlement-asset decision, not of the token standard, and it should be priced in when that decision is made.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>At a glance<\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-table is-style-stripes\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Control<\/th><th class=\"has-text-align-left\" data-align=\"left\">On the transfer hook?<\/th><th class=\"has-text-align-left\" data-align=\"left\">Note<\/th><\/tr><\/thead><tbody><tr><td>Identity binding and the required claim set<\/td><td>\u2705<\/td><td>No identity, no transfer<\/td><\/tr><tr><td>Sanctions \/ politically-exposed-person freeze<\/td><td>\u2705<\/td><td>Opaque class \u2014 one argument-free refusal<\/td><\/tr><tr><td>Due-diligence claim expiry<\/td><td>\u2705<\/td><td>Informative class. Expiry mandatory at the write, capped at a governance ceiling; fails closed, so it needs a refresh SLA behind it<\/td><\/tr><tr><td>Suspicion block<\/td><td>\u2705<\/td><td>Opaque class \u2014 indistinguishable from every other stop in it<\/td><\/tr><tr><td><strong>Investor tier<\/strong><\/td><td>\u274c<\/td><td>Read where it decides something \u2014 the subscription path and the covenant predicates. A per-transfer tier gate blocks a retail holder from&nbsp;<em>receiving<\/em>&nbsp;on a market that never asked the question<\/td><\/tr><tr><td>Holding-period lock<\/td><td>\u2705<\/td><td>Sender side only \u2014 skips mint<\/td><\/tr><tr><td>Closed-period freeze<\/td><td>\u2705<\/td><td>Both sides<\/td><\/tr><tr><td>Investor covenants<\/td><td>\u2705<\/td><td>Bound to a document version, not a clock<\/td><\/tr><tr><td><strong>Key-information delivery<\/strong><\/td><td>\u274c<\/td><td>Subscription path \u2014 it is pre-contractual, not a continuing attribute<\/td><\/tr><tr><td><strong>Fund concentration \/ borrowing limits<\/strong><\/td><td>\u274c<\/td><td>Their own reverting functions \u2014 four reasons, any one sufficient<\/td><\/tr><tr><td><strong>Cumulative value counters<\/strong><\/td><td>\u274c<\/td><td>Do not build<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">If you're building a tokenized security and need this transfer-gate architecture designed and audited end to end, see our <strong><a href=\"https:\/\/www.innblockchain.com\/solutions\/rwa-tokenization\" data-type=\"link\" data-id=\"https:\/\/www.innblockchain.com\/solutions\/rwa-tokenization\">RWA tokenization development s<\/a><a href=\"https:\/\/www.innblockchain.com\/solutions\/rwa-tokenization\" data-type=\"link\" data-id=\"https:\/\/www.innblockchain.com\/solutions\/rwa-tokenization\" target=\"_blank\" rel=\"noreferrer noopener\">ervices<\/a><\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>This is engineering commentary on regulatory requirements, not legal advice. Whether and how these obligations apply to a specific structure needs sign-off from counsel.<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>See how transfer restrictions for tokenized securities smart contract architecture enforce EU compliance without ever tipping off a blocked investor.<\/p>\n","protected":false},"author":5,"featured_media":5441,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[177],"tags":[201,203,205,204,199,206,198,202,197,200],"class_list":["post-5438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-rwatokenization","tag-cantransfer","tag-cantransfer-function","tag-erc-1400","tag-erc-3643","tag-smart-contract","tag-smart-contract-solutions","tag-transfer-gate","tag-transfer-restriction-module","tag-transfer-restrictions","tag-transfer-restrictions-smart-contract-example"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.4 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Transfer Restrictions for Tokenized Securities Smart Contract Architecture<\/title>\n<meta name=\"description\" content=\"See how transfer restrictions for tokenized securities smart contract architecture enforce EU compliance without ever tipping off a blocked investor.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Transfer Restrictions for Tokenized Securities Smart Contract Architecture\" \/>\n<meta property=\"og:description\" content=\"See how transfer restrictions for tokenized securities smart contract architecture enforce EU compliance without ever tipping off a blocked investor.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture\" \/>\n<meta property=\"og:site_name\" content=\"InnBlockchain\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/people\/Innblockchain\/100083044795160\/\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-15T09:57:28+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-16T12:23:14+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/09\/Transfer-Restrictions-for-Tokenized-Securities.webp\" \/>\n\t<meta property=\"og:image:width\" content=\"1774\" \/>\n\t<meta property=\"og:image:height\" content=\"887\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/webp\" \/>\n<meta name=\"author\" content=\"Gayathri\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@Innblockchain1\" \/>\n<meta name=\"twitter:site\" content=\"@Innblockchain1\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Gayathri\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"15 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture\"},\"author\":{\"name\":\"Gayathri\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#\\\/schema\\\/person\\\/a1a1bc5885fb26b80e6cd52fa4e6e081\"},\"headline\":\"Transfer Restrictions for Tokenized Securities: Smart Contract Architecture\",\"datePublished\":\"2026-09-15T09:57:28+00:00\",\"dateModified\":\"2026-09-16T12:23:14+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture\"},\"wordCount\":3341,\"publisher\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/Transfer-Restrictions-for-Tokenized-Securities.webp\",\"keywords\":[\"cantransfer\",\"canTransfer function\",\"ERC-1400\",\"ERC-3643\",\"smart contract\",\"smart contract solutions\",\"transfer gate\",\"transfer restriction module\",\"transfer restrictions\",\"transfer restrictions smart contract example\"],\"articleSection\":[\"RWA Tokenization\"],\"inLanguage\":\"en-US\"},{\"@type\":[\"WebPage\",\"SearchResultsPage\"],\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture\",\"url\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture\",\"name\":\"Transfer Restrictions for Tokenized Securities Smart Contract Architecture\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/Transfer-Restrictions-for-Tokenized-Securities.webp\",\"datePublished\":\"2026-09-15T09:57:28+00:00\",\"dateModified\":\"2026-09-16T12:23:14+00:00\",\"description\":\"See how transfer restrictions for tokenized securities smart contract architecture enforce EU compliance without ever tipping off a blocked investor.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage\",\"url\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/Transfer-Restrictions-for-Tokenized-Securities.webp\",\"contentUrl\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/Transfer-Restrictions-for-Tokenized-Securities.webp\",\"width\":1774,\"height\":887,\"caption\":\"Transfer Restrictions for Tokenized Securities\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Tokenization\",\"item\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/category\\\/tokenization\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"RWA Tokenization\",\"item\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/category\\\/tokenization\\\/rwatokenization\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"Transfer Restrictions for Tokenized Securities: Smart Contract Architecture\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#website\",\"url\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/\",\"name\":\"InnBlockchain Academy\",\"description\":\"Latest Blog &amp; News About Blockchain And Crypto\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#organization\",\"name\":\"InnBlockchain\",\"url\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/test.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2023\\\/03\\\/InnBlockChain_Acadamy.png\",\"contentUrl\":\"https:\\\/\\\/test.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2023\\\/03\\\/InnBlockChain_Acadamy.png\",\"width\":960,\"height\":320,\"caption\":\"InnBlockchain\"},\"image\":{\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/people\\\/Innblockchain\\\/100083044795160\\\/\",\"https:\\\/\\\/x.com\\\/Innblockchain1\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/#\\\/schema\\\/person\\\/a1a1bc5885fb26b80e6cd52fa4e6e081\",\"name\":\"Gayathri\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/17787870143092-96x96.jpg\",\"url\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/17787870143092-96x96.jpg\",\"contentUrl\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/17787870143092-96x96.jpg\",\"caption\":\"Gayathri\"},\"description\":\"With a dedication to delivering organic content by simplifying complex concepts of Blockchain, and love to connect with your hearts and minds.\",\"url\":\"https:\\\/\\\/www.innblockchain.com\\\/academy\\\/author\\\/gayathri\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Transfer Restrictions for Tokenized Securities Smart Contract Architecture","description":"See how transfer restrictions for tokenized securities smart contract architecture enforce EU compliance without ever tipping off a blocked investor.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture","og_locale":"en_US","og_type":"article","og_title":"Transfer Restrictions for Tokenized Securities Smart Contract Architecture","og_description":"See how transfer restrictions for tokenized securities smart contract architecture enforce EU compliance without ever tipping off a blocked investor.","og_url":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture","og_site_name":"InnBlockchain","article_publisher":"https:\/\/www.facebook.com\/people\/Innblockchain\/100083044795160\/","article_published_time":"2026-09-15T09:57:28+00:00","article_modified_time":"2026-09-16T12:23:14+00:00","og_image":[{"width":1774,"height":887,"url":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/09\/Transfer-Restrictions-for-Tokenized-Securities.webp","type":"image\/webp"}],"author":"Gayathri","twitter_card":"summary_large_image","twitter_creator":"@Innblockchain1","twitter_site":"@Innblockchain1","twitter_misc":{"Written by":"Gayathri","Est. reading time":"15 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#article","isPartOf":{"@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture"},"author":{"name":"Gayathri","@id":"https:\/\/www.innblockchain.com\/academy\/#\/schema\/person\/a1a1bc5885fb26b80e6cd52fa4e6e081"},"headline":"Transfer Restrictions for Tokenized Securities: Smart Contract Architecture","datePublished":"2026-09-15T09:57:28+00:00","dateModified":"2026-09-16T12:23:14+00:00","mainEntityOfPage":{"@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture"},"wordCount":3341,"publisher":{"@id":"https:\/\/www.innblockchain.com\/academy\/#organization"},"image":{"@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage"},"thumbnailUrl":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/09\/Transfer-Restrictions-for-Tokenized-Securities.webp","keywords":["cantransfer","canTransfer function","ERC-1400","ERC-3643","smart contract","smart contract solutions","transfer gate","transfer restriction module","transfer restrictions","transfer restrictions smart contract example"],"articleSection":["RWA Tokenization"],"inLanguage":"en-US"},{"@type":["WebPage","SearchResultsPage"],"@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture","url":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture","name":"Transfer Restrictions for Tokenized Securities Smart Contract Architecture","isPartOf":{"@id":"https:\/\/www.innblockchain.com\/academy\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage"},"image":{"@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage"},"thumbnailUrl":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/09\/Transfer-Restrictions-for-Tokenized-Securities.webp","datePublished":"2026-09-15T09:57:28+00:00","dateModified":"2026-09-16T12:23:14+00:00","description":"See how transfer restrictions for tokenized securities smart contract architecture enforce EU compliance without ever tipping off a blocked investor.","breadcrumb":{"@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#primaryimage","url":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/09\/Transfer-Restrictions-for-Tokenized-Securities.webp","contentUrl":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/09\/Transfer-Restrictions-for-Tokenized-Securities.webp","width":1774,"height":887,"caption":"Transfer Restrictions for Tokenized Securities"},{"@type":"BreadcrumbList","@id":"https:\/\/www.innblockchain.com\/academy\/transfer-restrictions-for-tokenized-securities-smart-contract-architecture#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.innblockchain.com\/academy"},{"@type":"ListItem","position":2,"name":"Tokenization","item":"https:\/\/www.innblockchain.com\/academy\/category\/tokenization"},{"@type":"ListItem","position":3,"name":"RWA Tokenization","item":"https:\/\/www.innblockchain.com\/academy\/category\/tokenization\/rwatokenization"},{"@type":"ListItem","position":4,"name":"Transfer Restrictions for Tokenized Securities: Smart Contract Architecture"}]},{"@type":"WebSite","@id":"https:\/\/www.innblockchain.com\/academy\/#website","url":"https:\/\/www.innblockchain.com\/academy\/","name":"InnBlockchain Academy","description":"Latest Blog &amp; News About Blockchain And Crypto","publisher":{"@id":"https:\/\/www.innblockchain.com\/academy\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.innblockchain.com\/academy\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.innblockchain.com\/academy\/#organization","name":"InnBlockchain","url":"https:\/\/www.innblockchain.com\/academy\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.innblockchain.com\/academy\/#\/schema\/logo\/image\/","url":"https:\/\/test.innblockchain.com\/academy\/wp-content\/uploads\/2023\/03\/InnBlockChain_Acadamy.png","contentUrl":"https:\/\/test.innblockchain.com\/academy\/wp-content\/uploads\/2023\/03\/InnBlockChain_Acadamy.png","width":960,"height":320,"caption":"InnBlockchain"},"image":{"@id":"https:\/\/www.innblockchain.com\/academy\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/people\/Innblockchain\/100083044795160\/","https:\/\/x.com\/Innblockchain1"]},{"@type":"Person","@id":"https:\/\/www.innblockchain.com\/academy\/#\/schema\/person\/a1a1bc5885fb26b80e6cd52fa4e6e081","name":"Gayathri","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/05\/17787870143092-96x96.jpg","url":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/05\/17787870143092-96x96.jpg","contentUrl":"https:\/\/www.innblockchain.com\/academy\/wp-content\/uploads\/2026\/05\/17787870143092-96x96.jpg","caption":"Gayathri"},"description":"With a dedication to delivering organic content by simplifying complex concepts of Blockchain, and love to connect with your hearts and minds.","url":"https:\/\/www.innblockchain.com\/academy\/author\/gayathri"}]}},"_links":{"self":[{"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/posts\/5438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/comments?post=5438"}],"version-history":[{"count":13,"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/posts\/5438\/revisions"}],"predecessor-version":[{"id":5537,"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/posts\/5438\/revisions\/5537"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/media\/5441"}],"wp:attachment":[{"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/media?parent=5438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/categories?post=5438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.innblockchain.com\/academy\/wp-json\/wp\/v2\/tags?post=5438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}