<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Crypto Law Tactics & Observations: DeFi]]></title><description><![CDATA[Protocol structuring, governance mechanics, and the legal architecture behind decentralized finance . How to navigate liquidity pools, DAO liability, staking arrangements, and composability risk when the regulatory playbook doesn't have a chapter for any of it. Practical analysis of where existing securities, commodities, and banking frameworks apply to DeFi.]]></description><link>https://jemhs.substack.com/s/defi</link><image><url>https://substackcdn.com/image/fetch/$s_!8HhG!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3146705e-42cb-41d4-b647-a358386a3fc4_176x176.png</url><title>Crypto Law Tactics &amp; Observations: DeFi</title><link>https://jemhs.substack.com/s/defi</link></image><generator>Substack</generator><lastBuildDate>Thu, 07 May 2026 00:14:48 GMT</lastBuildDate><atom:link href="https://jemhs.substack.com/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[James Williams]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[jemhs@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[jemhs@substack.com]]></itunes:email><itunes:name><![CDATA[James Williams]]></itunes:name></itunes:owner><itunes:author><![CDATA[James Williams]]></itunes:author><googleplay:owner><![CDATA[jemhs@substack.com]]></googleplay:owner><googleplay:email><![CDATA[jemhs@substack.com]]></googleplay:email><googleplay:author><![CDATA[James Williams]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[The Bounded Authority Problem]]></title><description><![CDATA[Governance Design in the Shadow of KelpDAO/Arbitrum]]></description><link>https://jemhs.substack.com/p/the-bounded-authority-problem</link><guid isPermaLink="false">https://jemhs.substack.com/p/the-bounded-authority-problem</guid><dc:creator><![CDATA[James Williams]]></dc:creator><pubDate>Sat, 25 Apr 2026 13:02:33 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!HoTJ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="captioned-image-container"><figure><a class="image-link image2 is-viewable-img" target="_blank" href="https://substackcdn.com/image/fetch/$s_!HoTJ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png" data-component-name="Image2ToDOM"><div class="image2-inset"><picture><source type="image/webp" srcset="https://substackcdn.com/image/fetch/$s_!HoTJ!,w_424,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 424w, https://substackcdn.com/image/fetch/$s_!HoTJ!,w_848,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 848w, https://substackcdn.com/image/fetch/$s_!HoTJ!,w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 1272w, https://substackcdn.com/image/fetch/$s_!HoTJ!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 1456w" sizes="100vw"><img src="https://substackcdn.com/image/fetch/$s_!HoTJ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png" width="1456" height="816" data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/f148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:null,&quot;imageSize&quot;:null,&quot;height&quot;:816,&quot;width&quot;:1456,&quot;resizeWidth&quot;:null,&quot;bytes&quot;:1414138,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:&quot;image/png&quot;,&quot;href&quot;:null,&quot;belowTheFold&quot;:false,&quot;topImage&quot;:true,&quot;internalRedirect&quot;:&quot;https://jemhs.substack.com/i/195298173?img=https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png&quot;,&quot;isProcessing&quot;:false,&quot;align&quot;:null,&quot;offset&quot;:false}" class="sizing-normal" alt="" srcset="https://substackcdn.com/image/fetch/$s_!HoTJ!,w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 424w, https://substackcdn.com/image/fetch/$s_!HoTJ!,w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 848w, https://substackcdn.com/image/fetch/$s_!HoTJ!,w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 1272w, https://substackcdn.com/image/fetch/$s_!HoTJ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff148e2d0-c88d-417a-804b-1c2b7e63508e_1456x816.png 1456w" sizes="100vw" fetchpriority="high"></picture><div class="image-link-expand"><div class="pencraft pc-display-flex pc-gap-8 pc-reset"><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container restack-image"><svg role="img" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke-width="1.5" stroke="var(--color-fg-primary)" stroke-linecap="round" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg"><g><title></title><path d="M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882"></path></g></svg></button><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container view-image"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-maximize2 lucide-maximize-2"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg></button></div></div></div></a></figure></div><p></p><p><em>Nothing herein constitutes legal advice. These resources are for informational purposes and should only be used in consultation with licensed attorneys.</em></p><h1>From Debate to Design</h1><p style="text-align: justify;">On April 18, 2026, attackers exploited a verifier-infrastructure weakness in the LayerZero-powered bridge that supports KelpDAO&#8217;s rsETH liquid restaking token. They minted unbacked rsETH and ultimately drained assets valued at approximately $292 million. Within roughly sixty hours, nine of twelve members of the Arbitrum Security Council voted in favor of moving 30,766 ETH (then worth approximately $71 million) from an exploiter-controlled address on Arbitrum One into an intermediary wallet that can only be moved by further governance action.</p><p style="text-align: justify;">The action was coordinated with law enforcement, which provided input as to the exploiter&#8217;s identity. The Arbitrum Foundation disclosed it in a forum post the following day.<a href="#_ftn1">[1]</a> The recovery represented a meaningful fraction of stolen value. It also represented one of the most publicly discussed invocations of a rollup security council to date, and a clear demonstration that the Council, in its current form, can both reach into user-controlled state and effectively reverse the consequences of an onchain transaction.</p><p style="text-align: justify;">The response on X has split along familiar lines. Defenders characterized the action as a textbook use of a publicly disclosed control mechanism, executed transparently and with appropriate process. Critics characterized it as definitive proof that the &#8220;decentralization&#8221; of major Layer 2 networks is, at present, marketing copy stretched over a multisig.</p><p style="text-align: justify;">Both readings are partly right. The disagreement is not really about Arbitrum. Rather, it is about what we mean by decentralization, what we mean by a &#8220;DAO,&#8221; and what kind of legal entity (formal or informal) sits behind a token that purports to confer governance over consequential infrastructure. Those questions have been theoretical for several years. KelpDAO crystallizes them in three ways at once. It is a question of governance legitimacy: did the Council have the political authority, as distinct from the technical capability, to freeze user assets? It is a question of internal duty: to whom did Council members owe duties when they voted, and how were those duties to be enforced? It is a question of user expectation: what should holders of bridged or restaked assets reasonably have expected about the conditions under which their positions could be unilaterally altered?</p><p style="text-align: justify;">My views on decentralization are on the record for anyone who cares to seek them out. Having said that, I consider myself, first and foremost, a frontline tactician, not a policy guy. For those in my shoes, our work is not to debate whether the prevailing architecture is ideologically pure; it is to guide clients as to how (or whether) they reconcile the goal of decentralization with the operational need for unilateral emergency response, in a way that holds up to scrutiny from users, delegates, regulators, and eventually courts.</p><p style="text-align: justify;">This piece takes a narrower thesis than the generalized decentralization debate. Stage 1 is where the economically significant rollups are. It is where they will remain for the foreseeable future. Counsel advising Stage 1 protocols, and counsel advising projects that deploy on them, have specific drafting and structuring work to do. </p><p style="text-align: justify;">The problem reduces to design. Like any design problem, it resolves into element-level choices, each with its own tradeoff profile. Council composition. Enumerated powers. Evidentiary thresholds. Sunset triggers. Time delays. Exit windows. Enforcers. Purpose trusts. The KelpDAO/Arbitrum action is a useful stress test for each of these, and it surfaces throughout. My goal is not a verdict on the Arbitrum action, but rather <em><strong>to frame the design choices counsel must consider in structuring bounded Stage 1 emergency authority that balances pragmatic intervention</strong></em> <em><strong>needs against the credibility of decentralization claims.</strong></em></p><h1>Why Governance Design Needs Its Own Treatment</h1><p style="text-align: justify;">KelpDAO, and the broader pattern of security-council activity across 2025 and 2026, have made it clear that governance-architecture choices have consequences largely independent of the securities-classification question that has dominated protocol-structuring discussions. The design choices catalogued in this piece are driven by a different set of considerations. Capture resistance. Credible commitment. Operational effectiveness under stress. Political legitimacy with users and delegates. Fiduciary exposure for the individuals who sit in governance seats. The ability of the architecture to produce predictable outcomes under stress rather than ad hoc discretion. The securities analysis, to the extent it is relevant for a particular protocol, is assumed to be addressed in a parallel workstream.</p><p style="text-align: justify;">One caveat. &#8220;Security Council&#8221; in the abstract covers meaningfully different structures across production rollups. Arbitrum&#8217;s 12-member body with a 9-of-12 emergency threshold is one point in a design space, not the defining one. Scroll recently proposed dissolving its Security Council entirely in favor of a smaller multisig. Optimism&#8217;s structure differs in composition, thresholds, and interaction with delegate governance. Base sits inside a different governance architecture altogether. I use the Arbitrum structure as a point of reference because it is the structure that has produced such vigorous debate in connection with the KelpDAO action. Most of the design principles apply across rollup types, but counsel should verify specific provisions against the charter of the rollup they actually advise on.</p><h1>Rollup Maturity as a Governance Constraint</h1><p style="text-align: justify;">Vitalik Buterin&#8217;s 2022 essay proposing milestones for rollups &#8220;taking off the training wheels&#8221; is the foundational text for what L2BEAT subsequently formalized as the Stage 0 / 1 / 2 framework.<a href="#_ftn2">[2]</a> The framework is technical in form but governance in substance. It asks how much trust users must place in identifiable parties for the security of the rollup, and it provides a clear taxonomy for that trust.</p><p style="text-align: justify;">At Stage 0, the rollup operates with full operator control. Upgrades are typically effected by a multisig with no time delay. Fraud or validity proofs may not yet be in production. The operator can, in principle, censor, pause, or rewrite state. Stage 0 means users are fully dependent on operator discretion. There is no credible constraint on unilateral action, no time delay that lets users exit before an upgrade takes effect, no onchain record of bounded authority that the operator has publicly committed to honor.</p><p style="text-align: justify;">Stage 1 introduces meaningful constraints. Fraud or validity proofs are live in production. The operator can no longer unilaterally rewrite history. Upgrades pass through a Security Council with bounded powers and, typically, some delay window. The Security Council, however, retains emergency powers. This is precisely the configuration that produced the KelpDAO action.</p><p style="text-align: justify;">Stage 2 removes the training wheels. Permissionless proving is enabled. Governance can effect protocol changes only through long delays. The security council&#8217;s remaining role is reduced to a narrow bug-fix backstop with strictly limited scope. A Stage 2 rollup is, in a strong sense, the configuration that the &#8220;sufficient decentralization&#8221; discourse has always implicitly described. It is also a configuration that very few production systems have actually achieved.<a href="#_ftn3">[3]</a> All major general-purpose rollups, including Arbitrum One, Base, and OP Mainnet, remain at Stage 1 as of this writing. The handful of rollups classified by L2BEAT as Stage 2 are narrow-purpose appchain deployments, not economically significant infrastructure.</p><p style="text-align: justify;">The practical implication is that, for the foreseeable future, most production rollups will retain at least one identifiable group (the security council) capable of taking actions that materially affect user state. That fact must be reflected in how the council&#8217;s charter is drafted, how its mandate is communicated to users, and how its decisions are constrained procedurally. It cannot be addressed by characterizing the council as &#8220;merely advisory.&#8221; The onchain authority is real, and users will correctly judge the protocol by what the council is empirically capable of doing, rather than by what the documentation says it is supposed to do.</p><h1>The KelpDAO Action in Detail</h1><h3>Factual Chronology</h3><p style="text-align: justify;">On April 18, 2026 (Saturday), attackers exploited a weakness in the LayerZero verifier infrastructure underlying KelpDAO&#8217;s rsETH liquid restaking token. They minted approximately 116,500 unbacked rsETH and ultimately controlled assets valued at approximately $292 million.<a href="#_ftn4">[4]</a> LayerZero subsequently attributed the attack to the Lazarus Group in a public post-mortem. Funds tied to the exploit moved across multiple chains, with a meaningful portion temporarily resting in addresses on Arbitrum One.</p><p style="text-align: justify;">On April 20, the Arbitrum Security Council voted, with nine of twelve members in favor, to take emergency action.<a href="#_ftn5">[5]</a> The vote authorized the movement of 30,766 ETH (approximately $71 million) from an exploiter-controlled address on Arbitrum One into an intermediary wallet that can be moved only by further Arbitrum governance action. The Foundation disclosed the action in a forum post on April 21. The Foundation has stated the action was coordinated with law enforcement.</p><p style="text-align: justify;">Within hours of the freeze, the exploiter is reported to have moved approximately 75,700 ETH across two new addresses.<a href="#_ftn6">[6]</a> This shows both the scale of remaining attacker resources and the limits of after-the-fact intervention. KelpDAO publicly thanked the Council and credited the SEAL 911 incident-response collective for coordinating the response.</p><h3>Why the Action (in Some Ways) Attracted Less Backlash Than Predicted</h3><p style="text-align: justify;">The Arbitrum action involved the use of privileged powers to transfer funds out of a user-controlled address- a powder keg scenario that should provoke the strongest user-trust reaction.  The response, however, was more tempered than I would have expected.  </p><p style="text-align: justify;">Four factors stacked in favor of the action&#8217;s defensibility. The target was a clearly identified bad actor: a sanctioned nation-state group with a documented history of crypto theft. The evidentiary basis included law-enforcement coordination on identity, which provided an external accountability hook. The technical execution was surgical. No other chain state, user position, or contract was affected. The Foundation disclosed the action promptly, transparently, and with specific procedural detail: the transaction hash, the vote tally, and the rationale.</p><p style="text-align: justify;">Those four factors together created a defensible narrative. Counsel advising a Council considering emergency action should treat them as a checklist. Where the target is an identified bad actor, the evidentiary record is externally anchored, the execution can be surgical, and the disclosure will be prompt and detailed, the action is more likely to be seen as defensible. Where any of those conditions fails, the action becomes materially harder to defend, regardless of what the charter appears to authorize. The Arbitrum action is not a template for emergency authority generally. It is the narrow case in which emergency authority works. Harder fact patterns should be stress-tested against it.</p><h3>Legal Characterization</h3><p style="text-align: justify;">The most consequential doctrinal question may also be the hardest to answer simply. What kind of action was this? Several characterizations are available, each with different doctrinal consequences.</p><p style="text-align: justify;">It can be described as an emergency upgrade. The relevant frame is the constitutional law of the protocol: the charter under which Council members hold their authority and the procedural conditions on its exercise. It can be described as a hard fork limited to the affected addresses. The analogy is the 2016 DAO fork on Ethereum, and the long-standing intuition that protocol-level intervention against onchain code is qualitatively different from intermediated reversal. It can be described as a custodial reversal. The relevant frame is bailment, or less charitably, conversion. It can be described as a permissioned override of otherwise-final onchain settlement. The relevant frame is the broader question of what users have been promised about the finality of their onchain positions and who bears the residual authority to alter those positions after the fact.</p><p style="text-align: justify;">The framing is non-neutral. If the Council&#8217;s action is a &#8220;custodial reversal,&#8221; the natural inference is that ETH on Arbitrum One was, at all material times, held subject to the Council&#8217;s effective control. That proves too much. It implies a custodial characterization for every asset on every Stage 1 rollup. If the action is a &#8220;hard fork,&#8221; the analogy is more comfortable, but it is also imprecise. The action was targeted at a specific actor based on offchain information about identity, and it used a concentrated multisig rather than the protocol&#8217;s ordinary upgrade path. The truthful answer is that the action was <em>sui generis.</em> An emergency invocation of bounded but real authority, against a clearly identified bad actor, executed through a publicly disclosed mechanism. The answer is doctrinally inconvenient because it does not tie out cleanly to any pre-existing category.</p><h3>Lessons for Charter Drafting</h3><p style="text-align: justify;">First, scope-of-authority limitations matter, and they should be drafted with the actually encountered fact patterns in mind. Theft from an identified bad actor. Theft from an unidentified actor. Exploit of a contract within the protocol. Exploit of a contract outside the protocol but resting funds on it. Adversarial governance capture. Each scenario stresses the charter differently.</p><p style="text-align: justify;">Second, transparency conditions should be spelled out. Required disclosure timing. Required documentation of the vote. Required publication of the operative transaction hash and the rationale. The Arbitrum Foundation&#8217;s forum post substantially complied with what one would draft as a best-practice disclosure provision. That compliance is part of why the action has been defended even by some skeptics.</p><p style="text-align: justify;">Third, sunset and review provisions. A council that takes an emergency action without any subsequent process for ratification, review, or appellate challenge invites criticism that the &#8220;bounded&#8221; authority is functionally unbounded. Charters should consider post-action ratification by the broader DAO, periodic re-election or re-confirmation of council members, and explicit provisions for the return of frozen assets if identification proves erroneous.</p><h3>The &#8220;Credibly Neutral but Not Really&#8221; Problem</h3><p style="text-align: justify;">The deepest critique of the Council&#8217;s action is not that it was wrong. The critique is that it exposed a tension the marketing of decentralized infrastructure has tended to obscure. A network that can intervene against bad actors is, by definition, a network that can in principle intervene against any actor. The credibility of the assurance that it will not is a function of charter design, member selection, public commitment, and reputational stake. None of which are absolute.</p><p style="text-align: justify;">Protocol documentation aimed at users, delegates, and downstream integrators should describe this honestly. The governance architecture should be presented to users in terms of what the council is empirically capable of doing, not merely what the documentation says it is supposed to do. Protocol teams should resist any temptation to describe Stage 1 rollups as &#8220;permissionless&#8221; without qualification.</p><h1>Legal Containers as Design Constraints</h1><p style="text-align: justify;">Wrapper choice matters for governance design in three specific ways. </p><p style="text-align: justify;">First, it sets the liability shield and indemnification regime for individual council members, enforcers, and oversight-body participants. An unwrapped DAO whose members coordinate on shared decisions carries meaningful general-partnership exposure for its participants.<a href="#_ftn7">[7]</a> No wrapperless structure can credibly indemnify the natural persons whose personal exposure is a primary concern here.</p><p style="text-align: justify;">Second, wrapper choice determines whether treasury, protocol IP, and upgrade keys can be orphaned into a purpose trust. That orphaning is itself a governance-design primitive. The Cayman Foundation Company, the Wyoming DUNA, and the Swiss Association each support meaningfully different separations between the operating entity and protocol-level assets.<a href="#_ftn8">[8]</a></p><p style="text-align: justify;">Third, wrapper choice structures the operational relationship between the entity that holds IP and treasury, the entity that runs day-to-day operations, and the governance body that sets policy. Different wrapper architectures enable different kinds of separation among these roles, which shapes what the governance design can actually accomplish and what practical constraints attach to each component.</p><h1>The STAR Trust and Orphan Structures</h1><h3>Cayman STAR Trusts</h3><p style="text-align: justify;">The Cayman Special Trusts (Alternative Regime) Act enables the creation of a vehicle that is unusual in trust law: the STAR trust. It permits a trust to be established for non-charitable purposes, with no human beneficiaries, enforced not by beneficiaries but by a separately appointed &#8220;enforcer.&#8221;<a href="#_ftn9">[9]</a> In the protocol context, the STAR trust has emerged as a natural vehicle for holding upgrade keys, treasury reserves, IP and trademarks, and other assets that a protocol wishes to place outside the operational control of the founding team but does not wish to vest in any identifiable beneficiary.</p><p style="text-align: justify;">The mechanics are powerful but unfamiliar. The trustee holds the assets in trust for the defined purpose. The enforcer has standing to compel performance. The founder typically has no continuing role. Properly structured, the STAR trust can hold assets in a manner that is genuinely orphaned from the protocol&#8217;s contributors. That is a result hard to achieve cleanly with a foundation, an LLC, or any conventional ownership vehicle. Improperly structured, it can be opaque to the point of inviting suspicion, particularly in U.S. enforcement settings.</p><h3>Comparative Purpose Trusts</h3><p style="text-align: justify;">The Cayman STAR is not the only purpose-trust regime available. Jersey and Guernsey both have well-developed non-charitable purpose trust regimes. Bermuda has its own statutory variant. The choice among them turns on familiarity, regulatory environment, the relative comfort of trustees in the jurisdiction with crypto-native assets, and the need for ancillary structures (e.g., underlying companies to hold operational assets).</p><h3>The Enforcer&#8217;s Role</h3><p style="text-align: justify;">The enforcer is the legal innovation that makes purpose trusts viable for delegations of bounded authority. Because there is no human beneficiary with standing to enforce the trust, the enforcer takes on that role. The enforcer owes fiduciary duties <em><strong>to the purpose itself</strong></em>, rather than to a class of persons. The choice of enforcer is therefore consequential. A global law firm can serve but creates concentration of influence. A board of independent professionals can serve but raises governance questions of its own. A &#8220;council of enforcers&#8221; can be drafted into a charter at the cost of complexity and slower decision-making.</p><h3>U.S. Tax and Reporting Tradeoffs</h3><p style="text-align: justify;">STAR trusts and other offshore purpose vehicles raise familiar U.S. issues. U.S. persons treated as owners of foreign trusts may face Form 3520 and 3520-A filing obligations. Controlled foreign corporation rules may apply to underlying companies. Passive foreign investment company rules may apply to assets held in or through the structure. Opacity is sometimes a feature for protocol purposes. It is reliably a problem for U.S. holders without careful planning.</p><h1>Governance Design Primitives</h1><p style="text-align: justify;">KelpDAO/Arbitrum surfaced design questions that had been largely theoretical. What follows is a catalogue of design options organized around the Security Council as the focal primitive, then the surrounding structural primitives that do most of the actual work of making Council authority credible. Each subsection is a set of choices, not prescriptions. The right configuration is protocol-specific. The choices themselves are now reasonably well-defined.</p><h2>Council Composition</h2><p style="text-align: justify;">The threshold question is how small to make the Council, and what threshold to require for action. Arbitrum&#8217;s 12-member body with a 9-of-12 emergency threshold illustrates the tradeoff. Large enough that the vote itself is meaningful (no single member can trigger action, and a minority can defeat it). Small enough that coordination within a short timeframe is feasible. Smaller councils (5-of-9, 7-of-11) shorten coordination time at the cost of making capture cheaper and individual votes more determinative. Larger councils invert the tradeoff. Below roughly seven members, the body becomes difficult to distinguish from a multisig, and the political claim that it functions as an independent governance body, rather than a rubber stamp for whichever faction assembled it, may be hard to sustain with users, delegates, and downstream partners.</p><p style="text-align: justify;">The composition rules that make a Council defensible are mostly about reducing correlated failure. Affiliation independence limits both capture risk and the attribution argument that the Council is a mere arm of the operating entity. A reasonable default is no more than N members from any one protocol team, investor, delegate organization, or jurisdiction. Geographic and regulatory diversification matters both for operational continuity (a single-jurisdiction Council is easier to compel or enjoin) and for the optics of credibly independent deliberation. Term limits and rotation prevent the Council from becoming a permanent governance body. A two-year term with a one-term cooling-off period is a defensible baseline, with staggered expirations so institutional memory is preserved across rotations.</p><p style="text-align: justify;">Public identification is the norm and should remain so. Pseudonymous Council membership makes post-action accountability to users, delegates, downstream partners, and the protocol&#8217;s own forum community substantially harder to effectuate. The perceived benefits of pseudonymity tend to erode the first time the Council faces a real challenge. Conflict-of-interest and recusal rules should be written down, publicly disclosed, and actually enforced. An unrecused vote on a matter touching a member&#8217;s affiliated entities is exactly the kind of incident that erodes Council credibility most quickly and most durably. Emergency and routine thresholds should be decoupled. A higher threshold for emergency action prevents small-faction action under time pressure. A lower threshold plus a time delay for routine action substitutes process for speed-as-legitimacy.</p><p style="text-align: justify;">One more thing on composition: council members selected by token-holder vote, empowered to move user assets in defined circumstances, and operating under a public charter occupy a role that looks like a fiduciary relationship in any conventional sense. No court has yet had occasion to confirm that characterization in the rollup context. The intuition that Council members, by default, are fiduciaries is widely shared, and I think it is more likely than not correct. Counsel should assume the answer is yes and draft accordingly.</p><p style="text-align: justify;">That assumption produces a number of practical consequences. A fiduciary selection process that produces predictable capture is a liability-creating event. Personal liability is real. D&amp;O insurance becomes baseline rather than a best-practice luxury. Indemnification from the Foundation or treasury is not optional, and it must be structured carefully so the indemnity is enforceable and funded. Conflicts of interest implicate fiduciary duty not merely a governance hygiene. A member who participates in a vote touching an affiliated entity creates both a governance defect and potential personal liability. Charters should reflect that. Indemnification should expressly exclude conduct outside the charter&#8217;s enumerated scope, so members are clear on where the shield stops.</p><h3>Scope: Enumerated Powers and Triggers</h3><p style="text-align: justify;">Enumerated powers are the core design choice. The default posture should be that the Council has no authority except what is enumerated, and each enumerated power should be paired with a specific factual trigger. Five scenarios have emerged post-KelpDAO as the canonical fact-pattern taxonomy, and each calls for a distinct Council authority (or its absence).</p><p style="text-align: justify;"><em>On-protocol exploit with identified attacker.</em> The clearest case. Authority to freeze or redirect funds belonging to the identified attacker&#8217;s address, pending further governance action, is defensible and should be explicitly enumerated. This is the narrow case Arbitrum acted on.</p><p style="text-align: justify;"><em>On-protocol exploit with unidentified attacker.</em> Substantially harder. Charters should require independent third-party forensic attestation that the funds are traceable to the exploit, a longer minimum deliberation period, and an automatic reversal mechanism if identification ultimately proves erroneous within a defined window.</p><p style="text-align: justify;"><em>Off-protocol exploit where funds rest on the protocol.</em> The KelpDAO fact pattern. The exploit was of LayerZero and KelpDAO infrastructure, but the funds moved to Arbitrum. Charters should state expressly whether the Council has authority in this configuration and, if so, require a formal assistance request from the affected protocol&#8217;s governance body and contemporaneous law-enforcement coordination.</p><p style="text-align: justify;"><em>Governance capture or Council malfunction.</em> Where the attacker is, or has effective control over, a sub-DAO, operating entity, or faction of the Council itself. Charters should provide emergency powers that cannot be invoked by the captured entity, typically routed through an independent enforcer, purpose-trust trustee, or second chamber.</p><p style="text-align: justify;"><em>Non-exploit disputes.</em> The &#8220;the Council should not act&#8221; category. Ordinary user errors. Phishing losses. Disputed commercial transactions. Contested offchain claims. Charters should affirmatively prohibit Council action in these scenarios. An express and explicit prohibition is what makes the Council&#8217;s narrowness credible. This is the single most important drafting lesson from the criticism the Arbitrum action attracted.</p><p style="text-align: justify;">Scope should also be temporally bounded. Emergency powers should expire automatically absent ratification, and the sunset should be written into the charter rather than left to subsequent governance. An emergency freeze that persists for six months without DAO ratification is, functionally, an ordinary governance action taken unilaterally. The Council&#8217;s political legitimacy with users and delegates erodes materially the longer an emergency posture persists without democratic confirmation.</p><h3>Process and Evidentiary Discipline</h3><p style="text-align: justify;">Process discipline is what separates a defensible exercise of bounded authority from a discretionary intervention. Five process elements deserve explicit charter treatment.</p><p style="text-align: justify;">The charter should specify what evidentiary record is required before action. The minimum package post-KelpDAO includes onchain transaction traces confirming the exploit path, an independent forensic attestation from a qualified third party (Chainalysis, TRM Labs, or an equivalent), and, where feasible, a formal request for assistance from the affected protocol&#8217;s governance body or from law enforcement. The Council&#8217;s own minutes should reflect which elements were relied on and which were unavailable.</p><p style="text-align: justify;">Law enforcement coordination was central to the defense of the Arbitrum action.<a href="#_ftn10">[10]</a> Charters can make law-enforcement engagement a prerequisite for action in the unidentified-attacker fact pattern, while acknowledging in the charter itself that the requirement cannot always be met on short timelines. The honest drafting approach is to specify what substitutes (for example, two independent forensic attestations plus a supermajority threshold) suffice when engagement is unavailable in time.</p><p style="text-align: justify;">Even emergency action benefits from a defined minimum deliberation period, say six or twelve hours, during which the evidentiary record is assembled and circulated to Council members. A charter that requires this, and requires the Council to document having met it, materially reduces the ad-hoc-action critique.</p><p style="text-align: justify;">Post-action disclosure should follow a defined schedule (24 hours is a reasonable default) and format. A forum post. The operative transaction hash. The rationale. The evidentiary basis. Identification of voting members. A summary of the charter provisions relied on. The Arbitrum forum post is a workable template. Charters should make something like it mandatory rather than customary.</p><p style="text-align: justify;">All materials relied on by the Council should be preserved and made available to subsequent reviewers. Forensic reports. Communications with law enforcement. Legal memoranda. Whether that review comes from the DAO, a court, or a regulator, the record should be there.</p><h3>Accountability, Reversibility, and Sunset</h3><p style="text-align: justify;">Bounded authority that is never reviewed is functionally unbounded. Three mechanisms, used in combination, address this.</p><p style="text-align: justify;">A charter can require that emergency Council actions be ratified by the broader DAO within a defined window (30 days is a common choice), and that, absent ratification, the action be reversed to the extent technically feasible. The mechanism is imperfect. Reversal of a freeze is easier than reversal of a forced redirection. It provides a democratic backstop that is otherwise absent, and it forces the Council to explain itself publicly with a concrete, time-bounded consequence.</p><p style="text-align: justify;">For actions where reversal is impracticable, charters should provide a standing review mechanism. An independent panel, a designated enforcer, or a second chamber empowered to hear challenges to Council action and publish findings. Findings need not be binding to deliver value. The prospect of reasoned public review disciplines the Council&#8217;s reasoning at the decision point.</p><p style="text-align: justify;">The most important accountability mechanism is the explicit retirement path. Charters should tie the Council&#8217;s existence (or at least its emergency powers) to specific technical milestones. Permissionless proving. Long governance delays. Narrowed upgrade authority. Stage-2 retirement should be a written commitment with objective triggers, not an aspiration.</p><p style="text-align: justify;">Sunset provisions should be drafted as fulfillment events, not aspirational timelines. A commitment that the Council retires &#8220;as decentralization matures&#8221; is a commitment to nothing. A commitment that the Council retires upon permissionless proving going live, a specified reduction in upgrade authority, and a defined governance delay becoming binding is a commitment counsel can actually enforce. The drafting principle is that &#8220;fulfillment&#8221; must be defined publicly and in advance. What the specific test is. Who attests to completion. What objective onchain or procedural conditions count as done. A dated handover event, publicly announced and technically executed, is materially more defensible in practice than a gradual transition that leaves the allocation of authority permanently ambiguous. The alternative is a Council that remains &#8220;temporary&#8221; indefinitely while accumulating political authority it was never chartered to have. That is the most common failure pattern in practice, and the one that most reliably erodes user and delegate trust in the protocol&#8217;s stated decentralization posture.</p><h3>Time-Based and Structural Primitives Around the Council</h3><p style="text-align: justify;">Alongside the Council, several protocol-level primitives do much of the actual work of making governance credible. They are substitutes for Council authority at the margin. Every unit of credible commitment these primitives supply is a unit of discretionary authority the Council does not need.</p><p style="text-align: justify;"><em>Upgrade delays paired with user exit windows.</em> A seven-day governance-to-execution delay is a routine Compound-era choice. The same delay paired with an explicit user exit window, where users may withdraw funds during the delay with the withdrawal mechanism itself outside the scope of governance control, is a substantially stronger guarantee. It converts governance authority from something users must trust into something users can plan around. The underuse of paired exit windows is, in my view, the single biggest missed opportunity in current rollup governance design. A Council with a long delay and a hard exit window is structurally less dangerous than a Council with a short delay and no exit, regardless of the Council&#8217;s composition rules.</p><p style="text-align: justify;"><em>Optimistic governance and vetoes.</em> Optimistic governance regimes assume proposals pass absent veto within a defined window. Three choices define the regime. Who holds the veto (a delegate chamber, an enforcer, a designated multisig). The veto&#8217;s scope (narrow and exploit-related, or broad policy). The veto&#8217;s duration (a pause pending further process, or a hard block). A veto held by a party with bounded authority and a narrow mandate is among the strongest checks available without the centralization cost of a general-purpose Council. The veto-holder is structurally passive. It intervenes only to stop, not to direct. It has a much narrower attack surface for both capture and legitimacy claims than a body that acts affirmatively.</p><p style="text-align: justify;"><em>Bicameralism.</em> Two chambers with distinct constituencies, token holders and delegates, or token holders and a council, can check both majoritarian capture and insider concentration. The useful design question is what each chamber is competent to do. A council-as-second-chamber with veto rights over token-holder votes on a narrow class of technical changes is more defensible than a council with original authority over the same class. The veto framing preserves democratic primacy while supplying a technical-expertise check.</p><p style="text-align: justify;"><em>Protocol-level circuit breakers.</em> Some of the recovery function a Council performs can be moved into the protocol itself, through pre-committed automatic pauses triggered by objective onchain conditions. TVL drop of X percent in Y blocks. Oracle deviation beyond Z. Unusual withdrawal patterns. A circuit breaker that pauses the protocol during the Council&#8217;s deliberation window, without redirecting state, reduces pressure to act quickly on an incomplete record. Circuit breakers are imperfect. False positives are costly, and attackers will probe the triggers. They substitute rule-based for discretionary emergency response for a meaningful class of cases.</p><p style="text-align: justify;"><em>Time locks with priced risk.</em> A more subtle primitive, gaining adoption in 2025 and 2026, is combining long governance delays with onchain insurance or coverage products that pay out on specified adverse governance events. This converts governance risk into a priced variable users can hedge. It is the deepest available form of credible commitment. The cost of insurance becomes a real-time market signal on governance credibility, visible to the protocol and to regulators alike.</p><h3>Enforcers, BORGs, and Sub-Structures</h3><p style="text-align: justify;">Two developed frameworks address the same underlying problem from different angles. The enforcer concept, drawn from Cayman foundation and trust law, asks who holds legal standing to police an operational entity&#8217;s conduct. Under the Cayman Foundation Companies Act 2017, a foundation company operating without members must appoint a Supervisor, who holds statutory standing as an &#8220;interested person&#8221; to bring enforcement actions on the foundation&#8217;s behalf. The related term &#8220;enforcer&#8221; appears in the Special Trusts (Alternative Regime) Act, where an enforcer holds standing to compel a STAR trustee to perform a non-charitable purpose. It also appears in foundation-company practice, where Cayman foundations frequently serve as enforcers of associated trusts. Either way, the core idea is the same. A party distinct from management and beneficiaries, with express legal standing to hold the entity to its charter.</p><p style="text-align: justify;">The BORG (cyBernetic ORGanization) framework, originated by Gabriel Shapiro at Delphi Labs and now at MetaLeX, is the most developed translation of this architecture into protocol governance. A BORG wraps an operational construct, most often a multisig, in a legal entity whose charter implants autonomous-technology rules directly into the entity&#8217;s governance and designates parties with enforcement standing. The canonical Security BORG uses a Cayman foundation, populated with directors who hold the multisig keys, with the parent DAO granted express legal standing to sue the BORG or its managers for deviation from the charter mandate.</p><p style="text-align: justify;">Shapiro&#8217;s Security BORG writing identifies the precise structural gap the Arbitrum action exposes. A security multisig is typically described as having the power to &#8220;freeze the protocol in security emergencies.&#8221; The smart contract itself cannot distinguish a security emergency from any other set of facts. If the multisig can freeze in an emergency, it can freeze at any time, for any reason or no reason. Absent a wrapper that legally binds the multisig&#8217;s powers to bona fide security incident response and gives affected parties express standing to enforce that limit, the only sanction for deviation is social censure. Social censure creates pressure to publicly identify signers, which is the opposite of what operational security requires.</p><p style="text-align: justify;">Read against that framework, the Arbitrum action is less a critique of security councils than an illustration of what security councils need. The freeze is defensible on the facts. What the fact pattern exposes is the gap between the Council&#8217;s onchain technical capabilities and the legal-architectural constraints that would let users, delegates, and counterparties treat those capabilities as genuinely bounded rather than merely claimed to be bounded.</p><p style="text-align: justify;">The tactical design defaults follow in three parts. </p><p style="text-align: justify;">First, an enforcer or Security BORG wrapper does its useful work as a narrow veto. The wrapper holds the right to stop a defined set of actions on a defined set of triggers, with its own accountability mechanism behind it (a trustee, a court, a standing panel, or a DAO with express legal standing). In that configuration, it functions as a non-Council circuit breaker that the operating entity cannot suppress and that the token-holder body cannot capture. </p><p style="text-align: justify;">Second, the same wrapper fails when it is repurposed as a general oversight body. That repurposing reproduces the ad-hoc-authority problem at a different level of the stack. </p><p style="text-align: justify;">Third, two configurations have emerged as defensible starting points. A Cayman STAR trust holding protocol IP and upgrade keys, with an enforcer drawn from a pre-approved panel of crypto-native law firms and technical advisors. A Security BORG holding emergency-response functions, with the parent DAO granted express legal standing and scope limitations preventing the BORG from accumulating cross-mandate authority over time. Neither configuration substitutes for getting the Council charter right in the first instance. Both substitute for discretionary Council authority at the margin.</p><h1>What Counsel Should Commit To</h1><p style="text-align: justify;">The Arbitrum freeze was defensible on its facts. It is not a template. The four conditions that made the action defensible (identified nation-state bad actor, externally anchored evidentiary record, surgical execution, prompt and detailed disclosure) will not stack this cleanly in most future fact patterns. Counsel should treat those four conditions as a checklist. Where any of them fails, the action is materially harder to defend, regardless of charter language.</p><p style="text-align: justify;">Unwrapped emergency multisigs are indefensible at scale. The architecture that produced the Arbitrum action is one where bounded authority is asserted in documentation and executed by a multisig that is, as a matter of code, entirely unbounded. The gap between claimed bounds and real bounds is precisely the gap that legal wrappers, purpose trusts, and Security BORG structures exist to close. Counsel advising protocols that operate Stage 1 security councils should be recommending wrappers. Treating wrappers as exotic is a mistake.</p><p style="text-align: justify;">Council members are fiduciaries. Draft and insure accordingly. The combination of token-holder selection, charter-defined authority, and the power to move user assets looks like a fiduciary relationship. Courts are more likely than not to eventually say so. D&amp;O insurance and enforceable, funded indemnification are baseline, not optional. Conflicts recusal is a fiduciary-duty question, not just a governance-hygiene question.</p><p style="text-align: justify;">Exit windows are underused and structurally superior to composition fixes. A Council with a long delay and a hard user exit window is structurally less dangerous than a Council with a short delay and no exit, regardless of composition. If you have to pick one structural lever to advise a client on, it is exit windows paired with governance delays.</p><p style="text-align: justify;">Sunset must be a fulfillment event, not an aspiration. &#8220;As decentralization matures&#8221; is a commitment to nothing. Specific technical milestones, objectively attestable, with a dated handover event, are what counsel should be drafting.</p><h1>Open Questions</h1><p style="text-align: justify;">Several questions are genuinely unresolved and likely to drive the next phase of the discussion.</p><p style="text-align: justify;">Is Stage 2 reachable for protocols with real-world dependencies? A rollup with onchain settlement of fiat-backed assets, oracle dependencies, or deep integration with offchain systems may have legitimate operational reasons for retaining some emergency authority. The framework as currently articulated does not fully accommodate that case, and the line between &#8220;narrow bug-fix backstop&#8221; and &#8220;custodial counterparty&#8221; is not always crisp.</p><p style="text-align: justify;">Can a DAO ever be meaningfully decentralized if it can pause, upgrade, or fork? The honest answer is that full decentralization is not reachable in the strict sense for as long as the relevant authority resides in identifiable persons. What can be achieved is a structure in which the residual authority is bounded, publicly disclosed, and exercised under procedural constraints that are visible to users and delegates in advance. Such a structure does not eliminate the gap between marketing and reality, but it narrows the gap materially and makes the gap itself an object of explicit design rather than a latent embarrassment.</p><p style="text-align: justify;">International convergence will not be uniform. MiCA, the UK Financial Services and Markets Act regime, and Singapore&#8217;s Payment Services Act all bring different definitions and different obligations to bear on broadly similar facts.<a href="#_ftn11">[11]</a> Forum selection is therefore part of structuring, not separate from it. Protocols that intend to make tokens available across jurisdictions will need either to satisfy the lowest common denominator or to tier access geographically.</p><h2>Conclusion: Pragmatism as the Honest Form of the Ideal</h2><p>The post-KelpDAO discourse has settled into two camps that talk past each other. One camp treats every invocation of bounded authority as a falsification of the decentralization claim. The other treats every successful intervention as vindication that &#8220;real-world&#8221; infrastructure cannot operate on purist terms. Both positions are intellectually tidy. Neither is useful to a client that is looking to ship a protocol next quarter.</p><p>The frontline view is different. Networks progressing toward decentralization are not subject to a binary pass/fail characterization. Decentralization is a property that emerges from the interaction of charter language, structural primitives, legal wrappers, and credible commitments to retire authority on objective triggers. A protocol with a 12-of-12 multisig and aspirational documentation is not decentralized. A protocol with a 9-of-12 Council, a chartered scope of enumerated powers and duties, a STAR-trust-held treasury, paired exit windows, and a dated Stage 2 handover is meaningfully more decentralized than the first, even if neither is decentralized in the strict ideological sense. </p><p>That framing reconciles the ideological and pragmatic positions without collapsing either. The ideologue is right that any residual authority is, in principle, an attack surface: for capture, for compulsion, for mission creep. The pragmatist is right that <em>most </em>protocols with real users, real assets, and real adversaries cannot operate in 2026 with no residual authority at all. </p><p>The synthesis is that residual authority should be bounded, disclosed, exercised under procedural constraints, and on a public path to retirement. </p><div><hr></div><p><a href="#_ftnref1">[1]</a>Arbitrum Foundation forum, &#8220;Security Council Emergency Action &#8211; 21/04/2026,&#8221; forum.arbitrum.foundation (post-action disclosure); see also Decrypt, &#8220;Arbitrum Security Council Freezes $71.5M in Ethereum linked to $292M KelpDAO Exploit&#8221; (Apr. 21, 2026).</p><p><a href="#_ftnref2">[2]</a>V. Buterin, &#8220;Proposed milestones for rollups taking off training wheels&#8221; (Nov. 2022); L2BEAT, &#8220;Stages framework&#8221; (current methodology).</p><p><a href="#_ftnref3">[3]</a>L2BEAT classifies a small number of narrow-purpose rollups as Stage 2. No economically significant general-purpose rollup has reached Stage 2 as of this writing.</p><p><a href="#_ftnref4">[4]</a>KelpDAO / LayerZero post-mortem (Apr. 2026).</p><p><a href="#_ftnref5">[5]</a>Arbitrum Foundation forum, &#8220;Security Council Emergency Action &#8211; 21/04/2026,&#8221; forum.arbitrum.foundation; Unchained, &#8220;Arbitrum Security Council Freezes $71 Million in ETH Tied to Kelp DAO Exploit&#8221; (Apr. 21, 2026) (&#8221;Nine of the Security Council&#8217;s 12 members voted to execute the action.&#8221;).</p><p><a href="#_ftnref6">[6]</a>CoinDesk, &#8220;Arbitrum freezes $71M in ether tied to Kelp DAO exploit&#8221; (Apr. 21, 2026); Coinpedia, &#8220;KelpDAO Exploiter Moves 75,700 ETH Across Two New Wallets Minutes After Arbitrum&#8217;s Freeze&#8221; (Apr. 21, 2026).</p><p><a href="#_ftnref7">[7]</a>Sarcuni v. bZx DAO, 2023 (S.D. Cal. Mar. 27, 2023) (declining to dismiss claims that DAO token holders constituted a general partnership for liability purposes); see also CFTC v. Ooki DAO,  (N.D. Cal. June 9, 2023) (default judgment treating DAO as an unincorporated association).</p><p><a href="#_ftnref8">[8]</a>Wyoming Stat. &#167; 17-32-101 et seq. (Decentralized Unincorporated Nonprofit Association Act); Cayman Islands Foundation Companies Act (2017, as amended); Swiss Civil Code art. 60 et seq. (Vereinsrecht).</p><p><a href="#_ftnref9">[9]</a>Cayman Islands Special Trusts (Alternative Regime) Act (2017 Revision) (the &#8220;STAR Act&#8221;).</p><p><a href="#_ftnref10">[10]</a>See note 1.</p><p><a href="#_ftnref11">[11]</a>See Regulation (EU) 2023/1114 on Markets in Crypto-Assets (MiCA); UK Financial Services and Markets Act 2023; Singapore Payment Services Act 2019.</p>]]></content:encoded></item></channel></rss>