{"created_at":"2026-10-17T14:41:49.845Z","post_id":159,"previous_hidden":false,"current_hidden":false,"first_revision":2,"previous_revision":null,"current_revision":2,"next_revision":3,"last_revision":4,"current_version":2,"version_count":4,"username":"maxp","display_username":"MaxP","acting_user_name":"Cordt","avatar_template":"/user_avatar/forum.phoenix.money/maxp/{size}/81_2.png","edit_reason":null,"body_changes":{"inline":"\u003cdiv class=\"inline-diff\"\u003e\u003ch1\u003e\u003ca name=\"p-159-re-appointment-of-an-emergency-supervisor-1\" class=\"anchor\" href=\"#p-159-re-appointment-of-an-emergency-supervisor-1\" aria-label=\"Heading link\"\u003e\u003c/a\u003eRe: Appointment of an Emergency Supervisor\u003c/h1\u003e\u003cp\u003eHello. Yes, I made an account just for this. Some of you know me from Telegram as Max Power — a quick background on \u003cdel\u003ewhy \u003c/del\u003e\u003cdel\u003eI\u003c/del\u003e\u003cdel\u003e’\u003c/del\u003e\u003cdel\u003em \u003c/del\u003e\u003cdel\u003eweighing \u003c/del\u003e\u003cdel\u003ein\u003c/del\u003e\u003cdel\u003e.\u003c/del\u003e\u003cins\u003emy \u003c/ins\u003e\u003cins\u003eexperience \u003c/ins\u003e\u003cins\u003ewithin \u003c/ins\u003e\u003cins\u003ethis \u003c/ins\u003e\u003cins\u003eecosystem\u003c/ins\u003e\u003cins\u003e:\u003c/ins\u003e\u003c/p\u003e\u003cp\u003eI started out \u003cins\u003ejust \u003c/ins\u003ehelping people in Telegram groups, which \u003cins\u003esort \u003c/ins\u003e\u003cins\u003eof \u003c/ins\u003e\u003cins\u003esnowballed\u003c/ins\u003e\u003cdel\u003eopened \u003c/del\u003e\u003cdel\u003edoors\u003c/del\u003e. I was a founding member of the Osmosis Support Lab — arguably the ecosystem’s longest continuously funded and most successful DAO project, and one many of you have used.\u003c/p\u003e\u003cp\u003eI later joined Sei Foundation as DevRel, running its grants program, developer and user outreach, and support, then customer success and solutions engineering at Interchain/Cosmos Labs.\u003c/p\u003e\u003cp\u003eThese were hands-on, community-facing roles: making it as easy as possible for anyone to do something on the network. That gave me a view from every side — retail users, third-party developers, and the foundations in the ivory tower.\u003c/p\u003e\u003cp\u003eI’ve watched this play out across a dozen projects. I’m a stubborn believer in DAO-governed, decentralized, trustless systems, where everyone is a faceless moniker who could be anyone — and the one certainty is that you can never be certain of anyone’s motives.\u003c/p\u003e\u003cp\u003eWhat I’ve seen here is disingenuous conduct by the accuser, drifting well beyond accountability into a witch hunt, with the outcome seemingly decided before the proposal was written, regardless of the arguments.\u003c/p\u003e\u003cp\u003eIt is clear this proposal and the overall process have been structured to produce a removal, not to impartially examine conduct or hold anyone accountable for negligent or otherwise “adverse” actions or events.\u003c/p\u003e\u003cp\u003eThe original proposal having failed with a 2–1–1 vote does not constitute an “adverse event” — if it were an adverse event, a reasonable person would expect the majority of the directors to be in agreement on that statement.\u003c/p\u003e\u003cp\u003eThis is literally the governance system working as intended; with adequate checks and balances. Without them, two members have free rein to do anything they wish.\u003c/p\u003e\u003cp\u003eLet’s go into it a bit deeper though, because… why not?\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-there-is-no-qualifying-adverse-event-2\" class=\"anchor\" href=\"#p-159-there-is-no-qualifying-adverse-event-2\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThere is no qualifying “Adverse Event”\u003c/h2\u003e\u003cp\u003eThe precondition is never met. The opening post claims A272 “has resulted in a 2–2 deadlock.” A272’s own appendix records Philipp yes, MB yes, Rose no, Vini not voting: 2–1–1. Across 283 proposals none has ever split 2–2, and 14 of the 271 before A272 failed to reach the threshold.\u003cbr\u003e\nA threshold doing its job isn’t a deadlock. Once the count was public, item 1 was downgraded from “the persistent 2–2 Stewardship deadlock on Proposal A272” to “dysfunction”, which is arguably a vague catch-all for any situation, including where one may seek to manufacture a serious issue based on potentially dubious claims or circumstances.\u003c/p\u003e\u003cp\u003eArticle 2.6.1 requires an Adverse Event, not a lost vote (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.6.1, p. 12\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.1: \"If there has been an Adverse Event, then, solely to the extent\nnecessary or desirable to resolve or mitigate the impact of such Adverse Event,\nthe Community may appoint by Emergency System Governance Process, through the\nTerra Governance Process, one or more additional Supervisors (an 'Emergency\nSupervisor') to investigate and oversee the BORG while resolution or the Adverse\nEvent is pending.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eNor is there any general mandate to address “dysfunction.” The opening post claims the Bylaws cover “circumstances where the Foundation’s governing bodies become unable to properly perform their responsibilities.” They mention dysfunction once, as an example of an Adverse Event, and only where it materially impairs the Foundation’s ability to perform its duties — the standard set in the definition of “Adverse Event” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003eBylaws, p. 30\u003c/a\u003e). One failed vote isn’t that.\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003e\"Adverse Event\" means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws, including\nwithout limitation any persistent deadlock or dysfunction of any Body or\nCommunity Autonomous System.\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eArticle 2.6.2 also caps the office, barring it from removing, replacing, or directing the Board (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.6.2, p. 12\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.2: \"The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eItem 4 nonetheless asks governance to authorize that removal. If the power is needed, then amend the Bylaws. As \u003ca class=\"mention\" href=\"/u/0xphilipp\"\u003e@0xPhilipp\u003c/a\u003e states (several times), this matter must be dealt with under the current structure. Under the current language, it cannot come through an emergency vote, and therefore must be dropped for the time being.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-voting-threshold-is-not-the-problem-3\" class=\"anchor\" href=\"#p-159-the-voting-threshold-is-not-the-problem-3\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe voting threshold is not the problem\u003c/h2\u003e\u003cp\u003e“The majority decides” is the rule, and the threshold was not met. A majority of four is three; A272 got two, and Board action through the multisig must also meet the multisig’s signing threshold (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 3.1.3.2, p. 15\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 3.1.3.2(a): \"At all meetings of the Board, a majority of the total number\nof Directors then in office shall constitute a quorum for the transaction of\nbusiness and the act of a majority of the Directors present at any meeting at\nwhich there is a quorum shall be the act of the Board, except as may be otherwise\nspecifically provided by statute or by the Charter.\"\n\nArticle 3.1.3.2(c): \"Notwithstanding the foregoing provisions of this Article\n3.1.3.2, and for the avoidance of doubt, the Board may take no action which\nrequires the use of the Stewardship Multisig as a Mandatory Autonomous System\nunless approved by at least the number of Directors constituting the minimum\nsigning threshold of the Stewardship Multisig, such approval being evidenced by\nthe successful execution of a Stewardship Multisig Proposal.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eA272 itself needed 75% to remove a director, but fell short, so its second message lowered the threshold to 0.6. The rule was fine when it was removing a sitting director; only becoming a problem when it blocked another.\u003c/p\u003e\u003cp\u003eThat leaves A272 doing two things at once: remove one member and drop the threshold to 0.6. Removal is only allowed by System Upgrade (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=9\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.4.4.1, p. 9\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.4.4.1: \"A Stewardship Multisig Member may be removed from a Stewardship\nMultisig solely by System Upgrade (which may occur at any time or from time to\ntime) causing all of the Multisig Keys of such Stewardship Multisig Member to\ncease to belong to the Multisig Key Set recognized by such Stewardship Multisig,\nit being acknowledged and agreed that any System Upgrade causing such removal\nshall be sufficient, in and of itself to legally deem such person to have ceased\nto be a member of the Stewardship Multisig as a body of the BORG.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eMB has voted identically to Philipp on all 119 proposals where both voted; Rose dissenting 11 times, and Vini three. Remove Vini, cut the threshold to 0.6, and two of the remaining three pass anything without any realistic opposition. That’s not simply fixing a deadlock; it’s changing the mechanism to produce a guaranteed result on all future proposals. Vini explained it in his reply:\u003c/p\u003e\u003cblockquote\u003e\n\u003cp\u003e“A272 was more than a removal. It had two messages: removing me from the member group, and changing the PF DAO threshold to 60%. After the removal that means 2 of 3, so two directors could pass anything on their own.”\u003c/p\u003e\n\u003c/blockquote\u003e\u003ch2\u003e\u003ca name=\"p-159-the-outcome-and-candidates-are-seemingly-predetermined-4\" class=\"anchor\" href=\"#p-159-the-outcome-and-candidates-are-seemingly-predetermined-4\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe outcome and candidates are seemingly predetermined\u003c/h2\u003e\u003cp\u003eItem 1 establishes the Adverse Event, item 3 sets the mandate, and item 4 authorizes the removal it claims to merely investigate:\u003c/p\u003e\u003cblockquote\u003e\n\u003cp\u003e“Confirm that the Emergency Supervisor may exercise the powers available under Article 2.4.5.4, including instructing the removal of a Stewardship Multisig Member where the Supervisor determines that this is necessary or desirable to resolve the Adverse Event.” — item 4\u003c/p\u003e\n\u003c/blockquote\u003e\u003cp\u003eArticle 2.4.5.4 obliges Stewardship members to facilitate a removal an Emergency Supervisor instructs (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.4.5.4, p. 10\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.4.5.4: \"If an Emergency Supervisor appointed in accordance with an\nEmergency System Governance Process instructs the Stewardship Multisig Members\n(or any subset thereof) to facilitate, allow or cause a person to be removed as a\nStewardship Multisig Member via an Emergency System Upgrade due to the Emergency\nSupervisor deeming such removal necessary or desirable to handle an Adverse Event,\nsuch Stewardship Multisig Members shall use their commercially reasonable best\nefforts to facilitate, allow or cause such person to be so removed, as applicable,\nwhich may (at the discretion of the Emergency Supervisor) include removal enacted\nvia Emergency System Upgrade.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eThe proposal claims “both outcomes must remain possible,” yet item 4 has already authorized the removal — one specific outcome. It says “I am not asking Terra Governance to accept my assessment,” while item 1 asks governance to accept that assessment as fact. And Philipp concedes the Emergency Supervisor “cannot directly remove a Director,” then item 4 asks for the removal anyway. Every assurance of neutrality is contradicted by the proposal’s own text.\u003c/p\u003e\u003cp\u003eThe candidates aren’t open either. The opening post presents two names already “acknowledged as potential candidates by three of the four current Stewardship Directors.” A later reply says it proceeds “with only 1” if no third candidate is found, and a later one still says other PF members “already engaged with this process and agreed with the options.” The mandate, the remedy, and the candidate pool are all settled before the community votes.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-conflict-and-security-charges-checked-against-the-record-5\" class=\"anchor\" href=\"#p-159-the-conflict-and-security-charges-checked-against-the-record-5\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe conflict and security charges, checked against the record\u003c/h2\u003e\u003cp\u003eA272 attacks a director over A249, a grant that “paid his own company despite a recognized conflict.” The same record shows the accuser authoring and voting yes on at least seven proposals that paid his own address — $20,450 and 3,500 LUNA — with no on-chain record of disclosure or disinterested-director approval (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.6.2, p. 23\u003c/a\u003e; \u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=20\" rel=\"noopener nofollow ugc\"\u003eArt. 3.2.5.3, p. 20\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.6.2: \"If a BORG Personnel becomes aware of an ongoing material conflict\nof interest with respect to such BORG Personnel's participation in the BORG, such\nBORG Personnel shall resign from the BORG, unless such conflict of interest has\nbeen disclosed (along with all relevant material facts and circumstances) to the\nBoard and the Community in reasonable detail and such BORG Personnel's continued\nparticipation in the BORG has been approved by a majority of the disinterested\nDirectors notwithstanding such conflict of interest.\"\n\nArticle 3.2.5.3: \"Each Stewardship Multisig Member shall ... evaluate the merits\nof each ... Proposal solely in light of the Purposes, Authorized Uses and the\nPrinciples, and, based solely on such evaluation, and without regard to any\npersonal or extrinsic interest or consideration, determine whether to vote in\nfavor of such Proposal ...\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eA272 also says written security concerns “were dismissed … potentially exposing about $4.4M,” while Philipp’s own later reply says “MB and I were the ones who identified and reported the issue and triggered the process for an immediate Neutron chain halt.” Both can’t stand unqualified. And the Bylaws impose no duty to monitor, prevent, or report security risks (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.4, p. 23\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.4: \"Without limiting the generality of Article 4.3, none of the BORG,\nDirectors, Supervisors, Multisig Members or other BORG Personnel shall have any\nduty to the Community or any member thereof to monitor, respond to, prevent,\nmitigate, or announce any actual or perceived security threat or risk, by using\nany Stewardship Multisig or otherwise.\"\n\u003c/code\u003e\u003c/pre\u003e\u003ch2\u003e\u003ca name=\"p-159-the-existing-requirement-for-a-supervisor-is-being-ignored-6\" class=\"anchor\" href=\"#p-159-the-existing-requirement-for-a-supervisor-is-being-ignored-6\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe existing requirement for a Supervisor is being ignored\u003c/h2\u003e\u003cp\u003ePhilipp calls the missing standing Supervisor “a separate governance issue,” and says structural changes “should not be mixed into this process.” Neither holds against the text: the Bylaws require one at all times, with the power to hold personnel liable for Adverse Events (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11\" rel=\"noopener nofollow ugc\"\u003eBylaws, Arts. 2.5.1–2.5.2, p. 11\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.5.1: \"The BORG shall at all times have a supervisor (the 'Supervisor')\nwho is able and willing to supervise the management of the BORG.\"\n\nArticle 2.5.2: \"Subject to the limitations in these Bylaws and the other\nGovernance Agreements, the Supervisor shall ensure that the BORG's rules are\nenforced, and shall have the right and power to hold BORG Personnel liable for\nany Adverse Event caused by such BORG Personnel.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eNo Supervisor has been appointed, despite that “at all times” requirement. Instead the proposal sets its own clock — “maximum of four weeks,” “end of next week,” “with only 1” — while the Bylaws say the Community “may” appoint and set no deadline.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-edits-and-remaining-arguments-do-not-establish-an-adverse-event-7\" class=\"anchor\" href=\"#p-159-the-edits-and-remaining-arguments-do-not-establish-an-adverse-event-7\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe edits and remaining arguments do not establish an Adverse Event\u003c/h2\u003e\u003cp\u003eThe wording changed several times as claims were challenged. Item 1 swapped “deadlock” for “dysfunction” once the count was public. A later reply swapped “Three Emergency Supervisors is fine with me” for “a single supervisor would be a more efficient way,” and removed the UN Security Council–style restructuring and joining “after the house has been cleaned.” A reply quoting the earlier text was edited; another was deleted.\u003c/p\u003e\u003cp\u003eWhat’s left — mandate, contribution, meme coins, “assets on Terra,” “catastrophic liquidity loss,” “Terra Classic” (alarmist babble), failing to establish an Adverse Event), concerns over months-old matters (A249 closed over 3 months prior to A272), or isn’t an argument at all.\u003cbr\u003e\nThe Bylaws require no fiduciary duty to any individual community member (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.2.3, p. 23\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.2.3: \"As such none of the BORG, the Directors, Officers, Stewardship\nMultisig Members, Supervisors, Emergency Supervisors, and other BORG Personnel\nare able to, or will, accept, undertake or perform a duty of loyalty to or owe\nany fiduciary obligation to any single Community member, sub-group of the\nCommunity, or the Community as a whole.\"\n\u003c/code\u003e\u003c/pre\u003e\u003ch2\u003e\u003ca name=\"p-159-conclusion-8\" class=\"anchor\" href=\"#p-159-conclusion-8\" aria-label=\"Heading link\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\u003cp\u003eThis isn’t accountability; accountability can clear someone. This process pre-establishes the charge, predefines the mandate, demands the removal, preselects the candidates, and runs even with one.\u003c/p\u003e\u003cp\u003eWhere a rule helps, it bends: a 2–1–1 vote becomes “dysfunction” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003ep. 30\u003c/a\u003e), the power the Bylaws withhold becomes the power requested (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003ep. 12\u003c/a\u003e), and the required Supervisor becomes “a separate governance issue” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11\" rel=\"noopener nofollow ugc\"\u003ep. 11\u003c/a\u003e). Where it doesn’t, it’s absolute — the 75% threshold is immovable for a removal and negotiable to 0.6 when it blocks one (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15\" rel=\"noopener nofollow ugc\"\u003eArt. 3.1.3.2(c), p. 15\u003c/a\u003e); 2.4.5.4 binds while 2.6.2’s bar on that same removal is a technicality (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10\" rel=\"noopener nofollow ugc\"\u003epp. 10–12\u003c/a\u003e); and the materiality test that demands real harm is satisfied by one vote (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003ep. 30\u003c/a\u003e). A rule is only as absolute as its convenience.\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.2: \"The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\"\n\n\"Adverse Event\" means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws...\n\nArticle 2.5.1: \"The BORG shall at all times have a supervisor (the 'Supervisor')\nwho is able and willing to supervise the management of the BORG.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eBottom line: no deadlock, no qualifying Adverse Event, no authority to remedy “dysfunction,” and none to instruct a removal. The required Supervisor was never appointed, the outcome and candidates are predetermined, and A272 pairs removing one member with cutting the threshold to 0.6 so two votes that have never differed control everything. If the question is who should sit on the Board, ask that directly — don’t relabel a 2–1–1 vote as an emergency.\u003c/p\u003e\u003c/div\u003e","side_by_side":"\u003cdiv class=\"revision-content --previous\"\u003e\u003ch1\u003e\u003ca name=\"p-159-re-appointment-of-an-emergency-supervisor-1\" class=\"anchor\" href=\"#p-159-re-appointment-of-an-emergency-supervisor-1\" aria-label=\"Heading link\"\u003e\u003c/a\u003eRe: Appointment of an Emergency Supervisor\u003c/h1\u003e\u003cp\u003eHello. Yes, I made an account just for this. Some of you know me from Telegram as Max Power — a quick background on \u003cdel\u003ewhy \u003c/del\u003e\u003cdel\u003eI\u003c/del\u003e\u003cdel\u003e’\u003c/del\u003e\u003cdel\u003em \u003c/del\u003e\u003cdel\u003eweighing \u003c/del\u003e\u003cdel\u003ein\u003c/del\u003e\u003cdel\u003e.\u003c/del\u003e\u003c/p\u003e\u003cp\u003eI started out helping people in Telegram groups, which \u003cdel\u003eopened \u003c/del\u003e\u003cdel\u003edoors\u003c/del\u003e. I was a founding member of the Osmosis Support Lab — arguably the ecosystem’s longest continuously funded and most successful DAO project, and one many of you have used.\u003c/p\u003e\u003cp\u003eI later joined Sei Foundation as DevRel, running its grants program, developer and user outreach, and support, then customer success and solutions engineering at Interchain/Cosmos Labs.\u003c/p\u003e\u003cp\u003eThese were hands-on, community-facing roles: making it as easy as possible for anyone to do something on the network. That gave me a view from every side — retail users, third-party developers, and the foundations in the ivory tower.\u003c/p\u003e\u003cp\u003eI’ve watched this play out across a dozen projects. I’m a stubborn believer in DAO-governed, decentralized, trustless systems, where everyone is a faceless moniker who could be anyone — and the one certainty is that you can never be certain of anyone’s motives.\u003c/p\u003e\u003cp\u003eWhat I’ve seen here is disingenuous conduct by the accuser, drifting well beyond accountability into a witch hunt, with the outcome seemingly decided before the proposal was written, regardless of the arguments.\u003c/p\u003e\u003cp\u003eIt is clear this proposal and the overall process have been structured to produce a removal, not to impartially examine conduct or hold anyone accountable for negligent or otherwise “adverse” actions or events.\u003c/p\u003e\u003cp\u003eThe original proposal having failed with a 2–1–1 vote does not constitute an “adverse event” — if it were an adverse event, a reasonable person would expect the majority of the directors to be in agreement on that statement.\u003c/p\u003e\u003cp\u003eThis is literally the governance system working as intended; with adequate checks and balances. Without them, two members have free rein to do anything they wish.\u003c/p\u003e\u003cp\u003eLet’s go into it a bit deeper though, because… why not?\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-there-is-no-qualifying-adverse-event-2\" class=\"anchor\" href=\"#p-159-there-is-no-qualifying-adverse-event-2\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThere is no qualifying “Adverse Event”\u003c/h2\u003e\u003cp\u003eThe precondition is never met. The opening post claims A272 “has resulted in a 2–2 deadlock.” A272’s own appendix records Philipp yes, MB yes, Rose no, Vini not voting: 2–1–1. Across 283 proposals none has ever split 2–2, and 14 of the 271 before A272 failed to reach the threshold.\u003cbr\u003e\nA threshold doing its job isn’t a deadlock. Once the count was public, item 1 was downgraded from “the persistent 2–2 Stewardship deadlock on Proposal A272” to “dysfunction”, which is arguably a vague catch-all for any situation, including where one may seek to manufacture a serious issue based on potentially dubious claims or circumstances.\u003c/p\u003e\u003cp\u003eArticle 2.6.1 requires an Adverse Event, not a lost vote (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.6.1, p. 12\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.1: \"If there has been an Adverse Event, then, solely to the extent\nnecessary or desirable to resolve or mitigate the impact of such Adverse Event,\nthe Community may appoint by Emergency System Governance Process, through the\nTerra Governance Process, one or more additional Supervisors (an 'Emergency\nSupervisor') to investigate and oversee the BORG while resolution or the Adverse\nEvent is pending.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eNor is there any general mandate to address “dysfunction.” The opening post claims the Bylaws cover “circumstances where the Foundation’s governing bodies become unable to properly perform their responsibilities.” They mention dysfunction once, as an example of an Adverse Event, and only where it materially impairs the Foundation’s ability to perform its duties — the standard set in the definition of “Adverse Event” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003eBylaws, p. 30\u003c/a\u003e). One failed vote isn’t that.\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003e\"Adverse Event\" means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws, including\nwithout limitation any persistent deadlock or dysfunction of any Body or\nCommunity Autonomous System.\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eArticle 2.6.2 also caps the office, barring it from removing, replacing, or directing the Board (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.6.2, p. 12\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.2: \"The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eItem 4 nonetheless asks governance to authorize that removal. If the power is needed, then amend the Bylaws. As \u003ca class=\"mention\" href=\"/u/0xphilipp\"\u003e@0xPhilipp\u003c/a\u003e states (several times), this matter must be dealt with under the current structure. Under the current language, it cannot come through an emergency vote, and therefore must be dropped for the time being.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-voting-threshold-is-not-the-problem-3\" class=\"anchor\" href=\"#p-159-the-voting-threshold-is-not-the-problem-3\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe voting threshold is not the problem\u003c/h2\u003e\u003cp\u003e“The majority decides” is the rule, and the threshold was not met. A majority of four is three; A272 got two, and Board action through the multisig must also meet the multisig’s signing threshold (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 3.1.3.2, p. 15\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 3.1.3.2(a): \"At all meetings of the Board, a majority of the total number\nof Directors then in office shall constitute a quorum for the transaction of\nbusiness and the act of a majority of the Directors present at any meeting at\nwhich there is a quorum shall be the act of the Board, except as may be otherwise\nspecifically provided by statute or by the Charter.\"\n\nArticle 3.1.3.2(c): \"Notwithstanding the foregoing provisions of this Article\n3.1.3.2, and for the avoidance of doubt, the Board may take no action which\nrequires the use of the Stewardship Multisig as a Mandatory Autonomous System\nunless approved by at least the number of Directors constituting the minimum\nsigning threshold of the Stewardship Multisig, such approval being evidenced by\nthe successful execution of a Stewardship Multisig Proposal.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eA272 itself needed 75% to remove a director, but fell short, so its second message lowered the threshold to 0.6. The rule was fine when it was removing a sitting director; only becoming a problem when it blocked another.\u003c/p\u003e\u003cp\u003eThat leaves A272 doing two things at once: remove one member and drop the threshold to 0.6. Removal is only allowed by System Upgrade (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=9\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.4.4.1, p. 9\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.4.4.1: \"A Stewardship Multisig Member may be removed from a Stewardship\nMultisig solely by System Upgrade (which may occur at any time or from time to\ntime) causing all of the Multisig Keys of such Stewardship Multisig Member to\ncease to belong to the Multisig Key Set recognized by such Stewardship Multisig,\nit being acknowledged and agreed that any System Upgrade causing such removal\nshall be sufficient, in and of itself to legally deem such person to have ceased\nto be a member of the Stewardship Multisig as a body of the BORG.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eMB has voted identically to Philipp on all 119 proposals where both voted; Rose dissenting 11 times, and Vini three. Remove Vini, cut the threshold to 0.6, and two of the remaining three pass anything without any realistic opposition. That’s not simply fixing a deadlock; it’s changing the mechanism to produce a guaranteed result on all future proposals. Vini explained it in his reply:\u003c/p\u003e\u003cblockquote\u003e\n\u003cp\u003e“A272 was more than a removal. It had two messages: removing me from the member group, and changing the PF DAO threshold to 60%. After the removal that means 2 of 3, so two directors could pass anything on their own.”\u003c/p\u003e\n\u003c/blockquote\u003e\u003ch2\u003e\u003ca name=\"p-159-the-outcome-and-candidates-are-seemingly-predetermined-4\" class=\"anchor\" href=\"#p-159-the-outcome-and-candidates-are-seemingly-predetermined-4\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe outcome and candidates are seemingly predetermined\u003c/h2\u003e\u003cp\u003eItem 1 establishes the Adverse Event, item 3 sets the mandate, and item 4 authorizes the removal it claims to merely investigate:\u003c/p\u003e\u003cblockquote\u003e\n\u003cp\u003e“Confirm that the Emergency Supervisor may exercise the powers available under Article 2.4.5.4, including instructing the removal of a Stewardship Multisig Member where the Supervisor determines that this is necessary or desirable to resolve the Adverse Event.” — item 4\u003c/p\u003e\n\u003c/blockquote\u003e\u003cp\u003eArticle 2.4.5.4 obliges Stewardship members to facilitate a removal an Emergency Supervisor instructs (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.4.5.4, p. 10\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.4.5.4: \"If an Emergency Supervisor appointed in accordance with an\nEmergency System Governance Process instructs the Stewardship Multisig Members\n(or any subset thereof) to facilitate, allow or cause a person to be removed as a\nStewardship Multisig Member via an Emergency System Upgrade due to the Emergency\nSupervisor deeming such removal necessary or desirable to handle an Adverse Event,\nsuch Stewardship Multisig Members shall use their commercially reasonable best\nefforts to facilitate, allow or cause such person to be so removed, as applicable,\nwhich may (at the discretion of the Emergency Supervisor) include removal enacted\nvia Emergency System Upgrade.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eThe proposal claims “both outcomes must remain possible,” yet item 4 has already authorized the removal — one specific outcome. It says “I am not asking Terra Governance to accept my assessment,” while item 1 asks governance to accept that assessment as fact. And Philipp concedes the Emergency Supervisor “cannot directly remove a Director,” then item 4 asks for the removal anyway. Every assurance of neutrality is contradicted by the proposal’s own text.\u003c/p\u003e\u003cp\u003eThe candidates aren’t open either. The opening post presents two names already “acknowledged as potential candidates by three of the four current Stewardship Directors.” A later reply says it proceeds “with only 1” if no third candidate is found, and a later one still says other PF members “already engaged with this process and agreed with the options.” The mandate, the remedy, and the candidate pool are all settled before the community votes.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-conflict-and-security-charges-checked-against-the-record-5\" class=\"anchor\" href=\"#p-159-the-conflict-and-security-charges-checked-against-the-record-5\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe conflict and security charges, checked against the record\u003c/h2\u003e\u003cp\u003eA272 attacks a director over A249, a grant that “paid his own company despite a recognized conflict.” The same record shows the accuser authoring and voting yes on at least seven proposals that paid his own address — $20,450 and 3,500 LUNA — with no on-chain record of disclosure or disinterested-director approval (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.6.2, p. 23\u003c/a\u003e; \u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=20\" rel=\"noopener nofollow ugc\"\u003eArt. 3.2.5.3, p. 20\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.6.2: \"If a BORG Personnel becomes aware of an ongoing material conflict\nof interest with respect to such BORG Personnel's participation in the BORG, such\nBORG Personnel shall resign from the BORG, unless such conflict of interest has\nbeen disclosed (along with all relevant material facts and circumstances) to the\nBoard and the Community in reasonable detail and such BORG Personnel's continued\nparticipation in the BORG has been approved by a majority of the disinterested\nDirectors notwithstanding such conflict of interest.\"\n\nArticle 3.2.5.3: \"Each Stewardship Multisig Member shall ... evaluate the merits\nof each ... Proposal solely in light of the Purposes, Authorized Uses and the\nPrinciples, and, based solely on such evaluation, and without regard to any\npersonal or extrinsic interest or consideration, determine whether to vote in\nfavor of such Proposal ...\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eA272 also says written security concerns “were dismissed … potentially exposing about $4.4M,” while Philipp’s own later reply says “MB and I were the ones who identified and reported the issue and triggered the process for an immediate Neutron chain halt.” Both can’t stand unqualified. And the Bylaws impose no duty to monitor, prevent, or report security risks (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.4, p. 23\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.4: \"Without limiting the generality of Article 4.3, none of the BORG,\nDirectors, Supervisors, Multisig Members or other BORG Personnel shall have any\nduty to the Community or any member thereof to monitor, respond to, prevent,\nmitigate, or announce any actual or perceived security threat or risk, by using\nany Stewardship Multisig or otherwise.\"\n\u003c/code\u003e\u003c/pre\u003e\u003ch2\u003e\u003ca name=\"p-159-the-existing-requirement-for-a-supervisor-is-being-ignored-6\" class=\"anchor\" href=\"#p-159-the-existing-requirement-for-a-supervisor-is-being-ignored-6\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe existing requirement for a Supervisor is being ignored\u003c/h2\u003e\u003cp\u003ePhilipp calls the missing standing Supervisor “a separate governance issue,” and says structural changes “should not be mixed into this process.” Neither holds against the text: the Bylaws require one at all times, with the power to hold personnel liable for Adverse Events (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11\" rel=\"noopener nofollow ugc\"\u003eBylaws, Arts. 2.5.1–2.5.2, p. 11\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.5.1: \"The BORG shall at all times have a supervisor (the 'Supervisor')\nwho is able and willing to supervise the management of the BORG.\"\n\nArticle 2.5.2: \"Subject to the limitations in these Bylaws and the other\nGovernance Agreements, the Supervisor shall ensure that the BORG's rules are\nenforced, and shall have the right and power to hold BORG Personnel liable for\nany Adverse Event caused by such BORG Personnel.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eNo Supervisor has been appointed, despite that “at all times” requirement. Instead the proposal sets its own clock — “maximum of four weeks,” “end of next week,” “with only 1” — while the Bylaws say the Community “may” appoint and set no deadline.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-edits-and-remaining-arguments-do-not-establish-an-adverse-event-7\" class=\"anchor\" href=\"#p-159-the-edits-and-remaining-arguments-do-not-establish-an-adverse-event-7\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe edits and remaining arguments do not establish an Adverse Event\u003c/h2\u003e\u003cp\u003eThe wording changed several times as claims were challenged. Item 1 swapped “deadlock” for “dysfunction” once the count was public. A later reply swapped “Three Emergency Supervisors is fine with me” for “a single supervisor would be a more efficient way,” and removed the UN Security Council–style restructuring and joining “after the house has been cleaned.” A reply quoting the earlier text was edited; another was deleted.\u003c/p\u003e\u003cp\u003eWhat’s left — mandate, contribution, meme coins, “assets on Terra,” “catastrophic liquidity loss,” “Terra Classic” (alarmist babble), failing to establish an Adverse Event), concerns over months-old matters (A249 closed over 3 months prior to A272), or isn’t an argument at all.\u003cbr\u003e\nThe Bylaws require no fiduciary duty to any individual community member (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.2.3, p. 23\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.2.3: \"As such none of the BORG, the Directors, Officers, Stewardship\nMultisig Members, Supervisors, Emergency Supervisors, and other BORG Personnel\nare able to, or will, accept, undertake or perform a duty of loyalty to or owe\nany fiduciary obligation to any single Community member, sub-group of the\nCommunity, or the Community as a whole.\"\n\u003c/code\u003e\u003c/pre\u003e\u003ch2\u003e\u003ca name=\"p-159-conclusion-8\" class=\"anchor\" href=\"#p-159-conclusion-8\" aria-label=\"Heading link\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\u003cp\u003eThis isn’t accountability; accountability can clear someone. This process pre-establishes the charge, predefines the mandate, demands the removal, preselects the candidates, and runs even with one.\u003c/p\u003e\u003cp\u003eWhere a rule helps, it bends: a 2–1–1 vote becomes “dysfunction” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003ep. 30\u003c/a\u003e), the power the Bylaws withhold becomes the power requested (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003ep. 12\u003c/a\u003e), and the required Supervisor becomes “a separate governance issue” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11\" rel=\"noopener nofollow ugc\"\u003ep. 11\u003c/a\u003e). Where it doesn’t, it’s absolute — the 75% threshold is immovable for a removal and negotiable to 0.6 when it blocks one (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15\" rel=\"noopener nofollow ugc\"\u003eArt. 3.1.3.2(c), p. 15\u003c/a\u003e); 2.4.5.4 binds while 2.6.2’s bar on that same removal is a technicality (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10\" rel=\"noopener nofollow ugc\"\u003epp. 10–12\u003c/a\u003e); and the materiality test that demands real harm is satisfied by one vote (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003ep. 30\u003c/a\u003e). A rule is only as absolute as its convenience.\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.2: \"The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\"\n\n\"Adverse Event\" means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws...\n\nArticle 2.5.1: \"The BORG shall at all times have a supervisor (the 'Supervisor')\nwho is able and willing to supervise the management of the BORG.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eBottom line: no deadlock, no qualifying Adverse Event, no authority to remedy “dysfunction,” and none to instruct a removal. The required Supervisor was never appointed, the outcome and candidates are predetermined, and A272 pairs removing one member with cutting the threshold to 0.6 so two votes that have never differed control everything. If the question is who should sit on the Board, ask that directly — don’t relabel a 2–1–1 vote as an emergency.\u003c/p\u003e\u003c/div\u003e\u003cdiv class=\"revision-content --current\"\u003e\u003ch1\u003e\u003ca name=\"p-159-re-appointment-of-an-emergency-supervisor-1\" class=\"anchor\" href=\"#p-159-re-appointment-of-an-emergency-supervisor-1\" aria-label=\"Heading link\"\u003e\u003c/a\u003eRe: Appointment of an Emergency Supervisor\u003c/h1\u003e\u003cp\u003eHello. Yes, I made an account just for this. Some of you know me from Telegram as Max Power — a quick background on \u003cins\u003emy \u003c/ins\u003e\u003cins\u003eexperience \u003c/ins\u003e\u003cins\u003ewithin \u003c/ins\u003e\u003cins\u003ethis \u003c/ins\u003e\u003cins\u003eecosystem\u003c/ins\u003e\u003cins\u003e:\u003c/ins\u003e\u003c/p\u003e\u003cp\u003eI started out \u003cins\u003ejust \u003c/ins\u003ehelping people in Telegram groups, which \u003cins\u003esort \u003c/ins\u003e\u003cins\u003eof \u003c/ins\u003e\u003cins\u003esnowballed\u003c/ins\u003e. I was a founding member of the Osmosis Support Lab — arguably the ecosystem’s longest continuously funded and most successful DAO project, and one many of you have used.\u003c/p\u003e\u003cp\u003eI later joined Sei Foundation as DevRel, running its grants program, developer and user outreach, and support, then customer success and solutions engineering at Interchain/Cosmos Labs.\u003c/p\u003e\u003cp\u003eThese were hands-on, community-facing roles: making it as easy as possible for anyone to do something on the network. That gave me a view from every side — retail users, third-party developers, and the foundations in the ivory tower.\u003c/p\u003e\u003cp\u003eI’ve watched this play out across a dozen projects. I’m a stubborn believer in DAO-governed, decentralized, trustless systems, where everyone is a faceless moniker who could be anyone — and the one certainty is that you can never be certain of anyone’s motives.\u003c/p\u003e\u003cp\u003eWhat I’ve seen here is disingenuous conduct by the accuser, drifting well beyond accountability into a witch hunt, with the outcome seemingly decided before the proposal was written, regardless of the arguments.\u003c/p\u003e\u003cp\u003eIt is clear this proposal and the overall process have been structured to produce a removal, not to impartially examine conduct or hold anyone accountable for negligent or otherwise “adverse” actions or events.\u003c/p\u003e\u003cp\u003eThe original proposal having failed with a 2–1–1 vote does not constitute an “adverse event” — if it were an adverse event, a reasonable person would expect the majority of the directors to be in agreement on that statement.\u003c/p\u003e\u003cp\u003eThis is literally the governance system working as intended; with adequate checks and balances. Without them, two members have free rein to do anything they wish.\u003c/p\u003e\u003cp\u003eLet’s go into it a bit deeper though, because… why not?\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-there-is-no-qualifying-adverse-event-2\" class=\"anchor\" href=\"#p-159-there-is-no-qualifying-adverse-event-2\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThere is no qualifying “Adverse Event”\u003c/h2\u003e\u003cp\u003eThe precondition is never met. The opening post claims A272 “has resulted in a 2–2 deadlock.” A272’s own appendix records Philipp yes, MB yes, Rose no, Vini not voting: 2–1–1. Across 283 proposals none has ever split 2–2, and 14 of the 271 before A272 failed to reach the threshold.\u003cbr\u003e\nA threshold doing its job isn’t a deadlock. Once the count was public, item 1 was downgraded from “the persistent 2–2 Stewardship deadlock on Proposal A272” to “dysfunction”, which is arguably a vague catch-all for any situation, including where one may seek to manufacture a serious issue based on potentially dubious claims or circumstances.\u003c/p\u003e\u003cp\u003eArticle 2.6.1 requires an Adverse Event, not a lost vote (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.6.1, p. 12\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.1: \"If there has been an Adverse Event, then, solely to the extent\nnecessary or desirable to resolve or mitigate the impact of such Adverse Event,\nthe Community may appoint by Emergency System Governance Process, through the\nTerra Governance Process, one or more additional Supervisors (an 'Emergency\nSupervisor') to investigate and oversee the BORG while resolution or the Adverse\nEvent is pending.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eNor is there any general mandate to address “dysfunction.” The opening post claims the Bylaws cover “circumstances where the Foundation’s governing bodies become unable to properly perform their responsibilities.” They mention dysfunction once, as an example of an Adverse Event, and only where it materially impairs the Foundation’s ability to perform its duties — the standard set in the definition of “Adverse Event” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003eBylaws, p. 30\u003c/a\u003e). One failed vote isn’t that.\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003e\"Adverse Event\" means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws, including\nwithout limitation any persistent deadlock or dysfunction of any Body or\nCommunity Autonomous System.\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eArticle 2.6.2 also caps the office, barring it from removing, replacing, or directing the Board (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.6.2, p. 12\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.2: \"The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eItem 4 nonetheless asks governance to authorize that removal. If the power is needed, then amend the Bylaws. As \u003ca class=\"mention\" href=\"/u/0xphilipp\"\u003e@0xPhilipp\u003c/a\u003e states (several times), this matter must be dealt with under the current structure. Under the current language, it cannot come through an emergency vote, and therefore must be dropped for the time being.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-voting-threshold-is-not-the-problem-3\" class=\"anchor\" href=\"#p-159-the-voting-threshold-is-not-the-problem-3\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe voting threshold is not the problem\u003c/h2\u003e\u003cp\u003e“The majority decides” is the rule, and the threshold was not met. A majority of four is three; A272 got two, and Board action through the multisig must also meet the multisig’s signing threshold (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 3.1.3.2, p. 15\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 3.1.3.2(a): \"At all meetings of the Board, a majority of the total number\nof Directors then in office shall constitute a quorum for the transaction of\nbusiness and the act of a majority of the Directors present at any meeting at\nwhich there is a quorum shall be the act of the Board, except as may be otherwise\nspecifically provided by statute or by the Charter.\"\n\nArticle 3.1.3.2(c): \"Notwithstanding the foregoing provisions of this Article\n3.1.3.2, and for the avoidance of doubt, the Board may take no action which\nrequires the use of the Stewardship Multisig as a Mandatory Autonomous System\nunless approved by at least the number of Directors constituting the minimum\nsigning threshold of the Stewardship Multisig, such approval being evidenced by\nthe successful execution of a Stewardship Multisig Proposal.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eA272 itself needed 75% to remove a director, but fell short, so its second message lowered the threshold to 0.6. The rule was fine when it was removing a sitting director; only becoming a problem when it blocked another.\u003c/p\u003e\u003cp\u003eThat leaves A272 doing two things at once: remove one member and drop the threshold to 0.6. Removal is only allowed by System Upgrade (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=9\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.4.4.1, p. 9\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.4.4.1: \"A Stewardship Multisig Member may be removed from a Stewardship\nMultisig solely by System Upgrade (which may occur at any time or from time to\ntime) causing all of the Multisig Keys of such Stewardship Multisig Member to\ncease to belong to the Multisig Key Set recognized by such Stewardship Multisig,\nit being acknowledged and agreed that any System Upgrade causing such removal\nshall be sufficient, in and of itself to legally deem such person to have ceased\nto be a member of the Stewardship Multisig as a body of the BORG.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eMB has voted identically to Philipp on all 119 proposals where both voted; Rose dissenting 11 times, and Vini three. Remove Vini, cut the threshold to 0.6, and two of the remaining three pass anything without any realistic opposition. That’s not simply fixing a deadlock; it’s changing the mechanism to produce a guaranteed result on all future proposals. Vini explained it in his reply:\u003c/p\u003e\u003cblockquote\u003e\n\u003cp\u003e“A272 was more than a removal. It had two messages: removing me from the member group, and changing the PF DAO threshold to 60%. After the removal that means 2 of 3, so two directors could pass anything on their own.”\u003c/p\u003e\n\u003c/blockquote\u003e\u003ch2\u003e\u003ca name=\"p-159-the-outcome-and-candidates-are-seemingly-predetermined-4\" class=\"anchor\" href=\"#p-159-the-outcome-and-candidates-are-seemingly-predetermined-4\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe outcome and candidates are seemingly predetermined\u003c/h2\u003e\u003cp\u003eItem 1 establishes the Adverse Event, item 3 sets the mandate, and item 4 authorizes the removal it claims to merely investigate:\u003c/p\u003e\u003cblockquote\u003e\n\u003cp\u003e“Confirm that the Emergency Supervisor may exercise the powers available under Article 2.4.5.4, including instructing the removal of a Stewardship Multisig Member where the Supervisor determines that this is necessary or desirable to resolve the Adverse Event.” — item 4\u003c/p\u003e\n\u003c/blockquote\u003e\u003cp\u003eArticle 2.4.5.4 obliges Stewardship members to facilitate a removal an Emergency Supervisor instructs (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 2.4.5.4, p. 10\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.4.5.4: \"If an Emergency Supervisor appointed in accordance with an\nEmergency System Governance Process instructs the Stewardship Multisig Members\n(or any subset thereof) to facilitate, allow or cause a person to be removed as a\nStewardship Multisig Member via an Emergency System Upgrade due to the Emergency\nSupervisor deeming such removal necessary or desirable to handle an Adverse Event,\nsuch Stewardship Multisig Members shall use their commercially reasonable best\nefforts to facilitate, allow or cause such person to be so removed, as applicable,\nwhich may (at the discretion of the Emergency Supervisor) include removal enacted\nvia Emergency System Upgrade.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eThe proposal claims “both outcomes must remain possible,” yet item 4 has already authorized the removal — one specific outcome. It says “I am not asking Terra Governance to accept my assessment,” while item 1 asks governance to accept that assessment as fact. And Philipp concedes the Emergency Supervisor “cannot directly remove a Director,” then item 4 asks for the removal anyway. Every assurance of neutrality is contradicted by the proposal’s own text.\u003c/p\u003e\u003cp\u003eThe candidates aren’t open either. The opening post presents two names already “acknowledged as potential candidates by three of the four current Stewardship Directors.” A later reply says it proceeds “with only 1” if no third candidate is found, and a later one still says other PF members “already engaged with this process and agreed with the options.” The mandate, the remedy, and the candidate pool are all settled before the community votes.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-conflict-and-security-charges-checked-against-the-record-5\" class=\"anchor\" href=\"#p-159-the-conflict-and-security-charges-checked-against-the-record-5\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe conflict and security charges, checked against the record\u003c/h2\u003e\u003cp\u003eA272 attacks a director over A249, a grant that “paid his own company despite a recognized conflict.” The same record shows the accuser authoring and voting yes on at least seven proposals that paid his own address — $20,450 and 3,500 LUNA — with no on-chain record of disclosure or disinterested-director approval (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.6.2, p. 23\u003c/a\u003e; \u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=20\" rel=\"noopener nofollow ugc\"\u003eArt. 3.2.5.3, p. 20\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.6.2: \"If a BORG Personnel becomes aware of an ongoing material conflict\nof interest with respect to such BORG Personnel's participation in the BORG, such\nBORG Personnel shall resign from the BORG, unless such conflict of interest has\nbeen disclosed (along with all relevant material facts and circumstances) to the\nBoard and the Community in reasonable detail and such BORG Personnel's continued\nparticipation in the BORG has been approved by a majority of the disinterested\nDirectors notwithstanding such conflict of interest.\"\n\nArticle 3.2.5.3: \"Each Stewardship Multisig Member shall ... evaluate the merits\nof each ... Proposal solely in light of the Purposes, Authorized Uses and the\nPrinciples, and, based solely on such evaluation, and without regard to any\npersonal or extrinsic interest or consideration, determine whether to vote in\nfavor of such Proposal ...\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eA272 also says written security concerns “were dismissed … potentially exposing about $4.4M,” while Philipp’s own later reply says “MB and I were the ones who identified and reported the issue and triggered the process for an immediate Neutron chain halt.” Both can’t stand unqualified. And the Bylaws impose no duty to monitor, prevent, or report security risks (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.4, p. 23\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.4: \"Without limiting the generality of Article 4.3, none of the BORG,\nDirectors, Supervisors, Multisig Members or other BORG Personnel shall have any\nduty to the Community or any member thereof to monitor, respond to, prevent,\nmitigate, or announce any actual or perceived security threat or risk, by using\nany Stewardship Multisig or otherwise.\"\n\u003c/code\u003e\u003c/pre\u003e\u003ch2\u003e\u003ca name=\"p-159-the-existing-requirement-for-a-supervisor-is-being-ignored-6\" class=\"anchor\" href=\"#p-159-the-existing-requirement-for-a-supervisor-is-being-ignored-6\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe existing requirement for a Supervisor is being ignored\u003c/h2\u003e\u003cp\u003ePhilipp calls the missing standing Supervisor “a separate governance issue,” and says structural changes “should not be mixed into this process.” Neither holds against the text: the Bylaws require one at all times, with the power to hold personnel liable for Adverse Events (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11\" rel=\"noopener nofollow ugc\"\u003eBylaws, Arts. 2.5.1–2.5.2, p. 11\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.5.1: \"The BORG shall at all times have a supervisor (the 'Supervisor')\nwho is able and willing to supervise the management of the BORG.\"\n\nArticle 2.5.2: \"Subject to the limitations in these Bylaws and the other\nGovernance Agreements, the Supervisor shall ensure that the BORG's rules are\nenforced, and shall have the right and power to hold BORG Personnel liable for\nany Adverse Event caused by such BORG Personnel.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eNo Supervisor has been appointed, despite that “at all times” requirement. Instead the proposal sets its own clock — “maximum of four weeks,” “end of next week,” “with only 1” — while the Bylaws say the Community “may” appoint and set no deadline.\u003c/p\u003e\u003ch2\u003e\u003ca name=\"p-159-the-edits-and-remaining-arguments-do-not-establish-an-adverse-event-7\" class=\"anchor\" href=\"#p-159-the-edits-and-remaining-arguments-do-not-establish-an-adverse-event-7\" aria-label=\"Heading link\"\u003e\u003c/a\u003eThe edits and remaining arguments do not establish an Adverse Event\u003c/h2\u003e\u003cp\u003eThe wording changed several times as claims were challenged. Item 1 swapped “deadlock” for “dysfunction” once the count was public. A later reply swapped “Three Emergency Supervisors is fine with me” for “a single supervisor would be a more efficient way,” and removed the UN Security Council–style restructuring and joining “after the house has been cleaned.” A reply quoting the earlier text was edited; another was deleted.\u003c/p\u003e\u003cp\u003eWhat’s left — mandate, contribution, meme coins, “assets on Terra,” “catastrophic liquidity loss,” “Terra Classic” (alarmist babble), failing to establish an Adverse Event), concerns over months-old matters (A249 closed over 3 months prior to A272), or isn’t an argument at all.\u003cbr\u003e\nThe Bylaws require no fiduciary duty to any individual community member (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23\" rel=\"noopener nofollow ugc\"\u003eBylaws, Art. 4.2.3, p. 23\u003c/a\u003e).\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 4.2.3: \"As such none of the BORG, the Directors, Officers, Stewardship\nMultisig Members, Supervisors, Emergency Supervisors, and other BORG Personnel\nare able to, or will, accept, undertake or perform a duty of loyalty to or owe\nany fiduciary obligation to any single Community member, sub-group of the\nCommunity, or the Community as a whole.\"\n\u003c/code\u003e\u003c/pre\u003e\u003ch2\u003e\u003ca name=\"p-159-conclusion-8\" class=\"anchor\" href=\"#p-159-conclusion-8\" aria-label=\"Heading link\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\u003cp\u003eThis isn’t accountability; accountability can clear someone. This process pre-establishes the charge, predefines the mandate, demands the removal, preselects the candidates, and runs even with one.\u003c/p\u003e\u003cp\u003eWhere a rule helps, it bends: a 2–1–1 vote becomes “dysfunction” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003ep. 30\u003c/a\u003e), the power the Bylaws withhold becomes the power requested (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12\" rel=\"noopener nofollow ugc\"\u003ep. 12\u003c/a\u003e), and the required Supervisor becomes “a separate governance issue” (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11\" rel=\"noopener nofollow ugc\"\u003ep. 11\u003c/a\u003e). Where it doesn’t, it’s absolute — the 75% threshold is immovable for a removal and negotiable to 0.6 when it blocks one (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15\" rel=\"noopener nofollow ugc\"\u003eArt. 3.1.3.2(c), p. 15\u003c/a\u003e); 2.4.5.4 binds while 2.6.2’s bar on that same removal is a technicality (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10\" rel=\"noopener nofollow ugc\"\u003epp. 10–12\u003c/a\u003e); and the materiality test that demands real harm is satisfied by one vote (\u003ca href=\"https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30\" rel=\"noopener nofollow ugc\"\u003ep. 30\u003c/a\u003e). A rule is only as absolute as its convenience.\u003c/p\u003e\u003cpre\u003e\u003ccode class=\"lang-auto\"\u003eArticle 2.6.2: \"The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\"\n\n\"Adverse Event\" means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws...\n\nArticle 2.5.1: \"The BORG shall at all times have a supervisor (the 'Supervisor')\nwho is able and willing to supervise the management of the BORG.\"\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eBottom line: no deadlock, no qualifying Adverse Event, no authority to remedy “dysfunction,” and none to instruct a removal. The required Supervisor was never appointed, the outcome and candidates are predetermined, and A272 pairs removing one member with cutting the threshold to 0.6 so two votes that have never differed control everything. If the question is who should sit on the Board, ask that directly — don’t relabel a 2–1–1 vote as an emergency.\u003c/p\u003e\u003c/div\u003e","side_by_side_markdown":"\u003ctable class=\"markdown\"\u003e\u003ctr\u003e\u003ctd class=\"--previous\"\u003e# Re: Appointment of an Emergency Supervisor\n\n\u003c/td\u003e\u003ctd class=\"--current\"\u003e# Re: Appointment of an Emergency Supervisor\n\n\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd class=\"--previous\"\u003eHello. Yes, I made an account just for this. Some of you know me from Telegram as Max Power — a quick background on \u003cdel\u003ewhy I\u0026#39;m weighing in.\u003c/del\u003e\n\nI started out helping people in Telegram groups, which \u003cdel\u003eopened doors\u003c/del\u003e. I was a founding member of the Osmosis Support Lab — arguably the ecosystem\u0026#39;s longest continuously funded and most successful DAO project, and one many of you have used.\n\n\u003c/td\u003e\u003ctd class=\"--current\"\u003eHello. Yes, I made an account just for this. Some of you know me from Telegram as Max Power — a quick background on \u003cins\u003emy experience within this ecosystem:\u003c/ins\u003e\n\nI started out \u003cins\u003ejust \u003c/ins\u003ehelping people in Telegram groups, which \u003cins\u003esort of snowballed\u003c/ins\u003e. I was a founding member of the Osmosis Support Lab — arguably the ecosystem\u0026#39;s longest continuously funded and most successful DAO project, and one many of you have used.\n\n\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd class=\"--previous\"\u003eI later joined Sei Foundation as DevRel, running its grants program, developer and user outreach, and support, then customer success and solutions engineering at Interchain/Cosmos Labs.\n\nThese were hands-on, community-facing roles: making it as easy as possible for anyone to do something on the network. That gave me a view from every side — retail users, third-party developers, and the foundations in the ivory tower.\n\nI\u0026#39;ve watched this play out across a dozen projects. I\u0026#39;m a stubborn believer in DAO-governed, decentralized, trustless systems, where everyone is a faceless moniker who could be anyone — and the one certainty is that you can never be certain of anyone\u0026#39;s motives.\n\nWhat I\u0026#39;ve seen here is disingenuous conduct by the accuser, drifting well beyond accountability into a witch hunt, with the outcome seemingly decided before the proposal was written, regardless of the arguments.\n\nIt is clear this proposal and the overall process have been structured to produce a removal, not to impartially examine conduct or hold anyone accountable for negligent or otherwise \u0026quot;adverse\u0026quot; actions or events.\n\nThe original proposal having failed with a 2–1–1 vote does not constitute an \u0026quot;adverse event\u0026quot; — if it were an adverse event, a reasonable person would expect the majority of the directors to be in agreement on that statement.\n\nThis is literally the governance system working as intended; with adequate checks and balances. Without them, two members have free rein to do anything they wish.\n\nLet\u0026#39;s go into it a bit deeper though, because... why not?\n\n## There is no qualifying \u0026quot;Adverse Event\u0026quot;\n\nThe precondition is never met. The opening post claims A272 \u0026quot;has resulted in a 2–2 deadlock.\u0026quot; A272\u0026#39;s own appendix records Philipp yes, MB yes, Rose no, Vini not voting: 2–1–1. Across 283 proposals none has ever split 2–2, and 14 of the 271 before A272 failed to reach the threshold.\nA threshold doing its job isn\u0026#39;t a deadlock. Once the count was public, item 1 was downgraded from \u0026quot;the persistent 2–2 Stewardship deadlock on Proposal A272\u0026quot; to \u0026quot;dysfunction\u0026quot;, which is arguably a vague catch-all for any situation, including where one may seek to manufacture a serious issue based on potentially dubious claims or circumstances.\n\nArticle 2.6.1 requires an Adverse Event, not a lost vote ([Bylaws, Art. 2.6.1, p. 12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12)).\n\n```\nArticle 2.6.1: \u0026quot;If there has been an Adverse Event, then, solely to the extent\nnecessary or desirable to resolve or mitigate the impact of such Adverse Event,\nthe Community may appoint by Emergency System Governance Process, through the\nTerra Governance Process, one or more additional Supervisors (an \u0026#39;Emergency\nSupervisor\u0026#39;) to investigate and oversee the BORG while resolution or the Adverse\nEvent is pending.\u0026quot;\n```\n\nNor is there any general mandate to address \u0026quot;dysfunction.\u0026quot; The opening post claims the Bylaws cover \u0026quot;circumstances where the Foundation\u0026#39;s governing bodies become unable to properly perform their responsibilities.\u0026quot; They mention dysfunction once, as an example of an Adverse Event, and only where it materially impairs the Foundation\u0026#39;s ability to perform its duties — the standard set in the definition of \u0026quot;Adverse Event\u0026quot; ([Bylaws, p. 30](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30)). One failed vote isn\u0026#39;t that.\n\n```\n\u0026quot;Adverse Event\u0026quot; means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws, including\nwithout limitation any persistent deadlock or dysfunction of any Body or\nCommunity Autonomous System.\n```\n\nArticle 2.6.2 also caps the office, barring it from removing, replacing, or directing the Board ([Bylaws, Art. 2.6.2, p. 12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12)).\n\n```\nArticle 2.6.2: \u0026quot;The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\u0026quot;\n```\n\nItem 4 nonetheless asks governance to authorize that removal. If the power is needed, then amend the Bylaws. As @0xPhilipp states (several times), this matter must be dealt with under the current structure. Under the current language, it cannot come through an emergency vote, and therefore must be dropped for the time being.\n\n## The voting threshold is not the problem\n\n\u0026quot;The majority decides\u0026quot; is the rule, and the threshold was not met. A majority of four is three; A272 got two, and Board action through the multisig must also meet the multisig\u0026#39;s signing threshold ([Bylaws, Art. 3.1.3.2, p. 15](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15)). \n\n```\nArticle 3.1.3.2(a): \u0026quot;At all meetings of the Board, a majority of the total number\nof Directors then in office shall constitute a quorum for the transaction of\nbusiness and the act of a majority of the Directors present at any meeting at\nwhich there is a quorum shall be the act of the Board, except as may be otherwise\nspecifically provided by statute or by the Charter.\u0026quot;\n\nArticle 3.1.3.2(c): \u0026quot;Notwithstanding the foregoing provisions of this Article\n3.1.3.2, and for the avoidance of doubt, the Board may take no action which\nrequires the use of the Stewardship Multisig as a Mandatory Autonomous System\nunless approved by at least the number of Directors constituting the minimum\nsigning threshold of the Stewardship Multisig, such approval being evidenced by\nthe successful execution of a Stewardship Multisig Proposal.\u0026quot;\n```\n\nA272 itself needed 75% to remove a director, but fell short, so its second message lowered the threshold to 0.6. The rule was fine when it was removing a sitting director; only becoming a problem when it blocked another.\n\nThat leaves A272 doing two things at once: remove one member and drop the threshold to 0.6. Removal is only allowed by System Upgrade ([Bylaws, Art. 2.4.4.1, p. 9](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=9)).\n\n```\nArticle 2.4.4.1: \u0026quot;A Stewardship Multisig Member may be removed from a Stewardship\nMultisig solely by System Upgrade (which may occur at any time or from time to\ntime) causing all of the Multisig Keys of such Stewardship Multisig Member to\ncease to belong to the Multisig Key Set recognized by such Stewardship Multisig,\nit being acknowledged and agreed that any System Upgrade causing such removal\nshall be sufficient, in and of itself to legally deem such person to have ceased\nto be a member of the Stewardship Multisig as a body of the BORG.\u0026quot;\n```\n\nMB has voted identically to Philipp on all 119 proposals where both voted; Rose dissenting 11 times, and Vini three. Remove Vini, cut the threshold to 0.6, and two of the remaining three pass anything without any realistic opposition. That\u0026#39;s not simply fixing a deadlock; it\u0026#39;s changing the mechanism to produce a guaranteed result on all future proposals. Vini explained it in his reply:\n\n\u0026gt; \u0026quot;A272 was more than a removal. It had two messages: removing me from the member group, and changing the PF DAO threshold to 60%. After the removal that means 2 of 3, so two directors could pass anything on their own.\u0026quot;\n\n## The outcome and candidates are seemingly predetermined\n\nItem 1 establishes the Adverse Event, item 3 sets the mandate, and item 4 authorizes the removal it claims to merely investigate:\n\n\u0026gt; \u0026quot;Confirm that the Emergency Supervisor may exercise the powers available under Article 2.4.5.4, including instructing the removal of a Stewardship Multisig Member where the Supervisor determines that this is necessary or desirable to resolve the Adverse Event.\u0026quot; — item 4\n\nArticle 2.4.5.4 obliges Stewardship members to facilitate a removal an Emergency Supervisor instructs ([Bylaws, Art. 2.4.5.4, p. 10](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10)).\n\n```\nArticle 2.4.5.4: \u0026quot;If an Emergency Supervisor appointed in accordance with an\nEmergency System Governance Process instructs the Stewardship Multisig Members\n(or any subset thereof) to facilitate, allow or cause a person to be removed as a\nStewardship Multisig Member via an Emergency System Upgrade due to the Emergency\nSupervisor deeming such removal necessary or desirable to handle an Adverse Event,\nsuch Stewardship Multisig Members shall use their commercially reasonable best\nefforts to facilitate, allow or cause such person to be so removed, as applicable,\nwhich may (at the discretion of the Emergency Supervisor) include removal enacted\nvia Emergency System Upgrade.\u0026quot;\n```\n\nThe proposal claims \u0026quot;both outcomes must remain possible,\u0026quot; yet item 4 has already authorized the removal — one specific outcome. It says \u0026quot;I am not asking Terra Governance to accept my assessment,\u0026quot; while item 1 asks governance to accept that assessment as fact. And Philipp concedes the Emergency Supervisor \u0026quot;cannot directly remove a Director,\u0026quot; then item 4 asks for the removal anyway. Every assurance of neutrality is contradicted by the proposal\u0026#39;s own text.\n\nThe candidates aren\u0026#39;t open either. The opening post presents two names already \u0026quot;acknowledged as potential candidates by three of the four current Stewardship Directors.\u0026quot; A later reply says it proceeds \u0026quot;with only 1\u0026quot; if no third candidate is found, and a later one still says other PF members \u0026quot;already engaged with this process and agreed with the options.\u0026quot; The mandate, the remedy, and the candidate pool are all settled before the community votes.\n\n## The conflict and security charges, checked against the record\n\nA272 attacks a director over A249, a grant that \u0026quot;paid his own company despite a recognized conflict.\u0026quot; The same record shows the accuser authoring and voting yes on at least seven proposals that paid his own address — $20,450 and 3,500 LUNA — with no on-chain record of disclosure or disinterested-director approval ([Bylaws, Art. 4.6.2, p. 23](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23); [Art. 3.2.5.3, p. 20](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=20)).\n\n```\nArticle 4.6.2: \u0026quot;If a BORG Personnel becomes aware of an ongoing material conflict\nof interest with respect to such BORG Personnel\u0026#39;s participation in the BORG, such\nBORG Personnel shall resign from the BORG, unless such conflict of interest has\nbeen disclosed (along with all relevant material facts and circumstances) to the\nBoard and the Community in reasonable detail and such BORG Personnel\u0026#39;s continued\nparticipation in the BORG has been approved by a majority of the disinterested\nDirectors notwithstanding such conflict of interest.\u0026quot;\n\nArticle 3.2.5.3: \u0026quot;Each Stewardship Multisig Member shall ... evaluate the merits\nof each ... Proposal solely in light of the Purposes, Authorized Uses and the\nPrinciples, and, based solely on such evaluation, and without regard to any\npersonal or extrinsic interest or consideration, determine whether to vote in\nfavor of such Proposal ...\u0026quot;\n```\n\nA272 also says written security concerns \u0026quot;were dismissed … potentially exposing about $4.4M,\u0026quot; while Philipp\u0026#39;s own later reply says \u0026quot;MB and I were the ones who identified and reported the issue and triggered the process for an immediate Neutron chain halt.\u0026quot; Both can\u0026#39;t stand unqualified. And the Bylaws impose no duty to monitor, prevent, or report security risks ([Bylaws, Art. 4.4, p. 23](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23)).\n\n```\nArticle 4.4: \u0026quot;Without limiting the generality of Article 4.3, none of the BORG,\nDirectors, Supervisors, Multisig Members or other BORG Personnel shall have any\nduty to the Community or any member thereof to monitor, respond to, prevent,\nmitigate, or announce any actual or perceived security threat or risk, by using\nany Stewardship Multisig or otherwise.\u0026quot;\n```\n\n## The existing requirement for a Supervisor is being ignored\n\nPhilipp calls the missing standing Supervisor \u0026quot;a separate governance issue,\u0026quot; and says structural changes \u0026quot;should not be mixed into this process.\u0026quot; Neither holds against the text: the Bylaws require one at all times, with the power to hold personnel liable for Adverse Events ([Bylaws, Arts. 2.5.1–2.5.2, p. 11](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11)).\n\n```\nArticle 2.5.1: \u0026quot;The BORG shall at all times have a supervisor (the \u0026#39;Supervisor\u0026#39;)\nwho is able and willing to supervise the management of the BORG.\u0026quot;\n\nArticle 2.5.2: \u0026quot;Subject to the limitations in these Bylaws and the other\nGovernance Agreements, the Supervisor shall ensure that the BORG\u0026#39;s rules are\nenforced, and shall have the right and power to hold BORG Personnel liable for\nany Adverse Event caused by such BORG Personnel.\u0026quot;\n```\n\nNo Supervisor has been appointed, despite that \u0026quot;at all times\u0026quot; requirement. Instead the proposal sets its own clock — \u0026quot;maximum of four weeks,\u0026quot; \u0026quot;end of next week,\u0026quot; \u0026quot;with only 1\u0026quot; — while the Bylaws say the Community \u0026quot;may\u0026quot; appoint and set no deadline.\n\n## The edits and remaining arguments do not establish an Adverse Event\n\nThe wording changed several times as claims were challenged. Item 1 swapped \u0026quot;deadlock\u0026quot; for \u0026quot;dysfunction\u0026quot; once the count was public. A later reply swapped \u0026quot;Three Emergency Supervisors is fine with me\u0026quot; for \u0026quot;a single supervisor would be a more efficient way,\u0026quot; and removed the UN Security Council–style restructuring and joining \u0026quot;after the house has been cleaned.\u0026quot; A reply quoting the earlier text was edited; another was deleted.\n\nWhat\u0026#39;s left — mandate, contribution, meme coins, \u0026quot;assets on Terra,\u0026quot; \u0026quot;catastrophic liquidity loss,\u0026quot; \u0026quot;Terra Classic\u0026quot; (alarmist babble), failing to establish an Adverse Event), concerns over months-old matters (A249 closed over 3 months prior to A272), or isn\u0026#39;t an argument at all.\nThe Bylaws require no fiduciary duty to any individual community member ([Bylaws, Art. 4.2.3, p. 23](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23)).\n\n```\nArticle 4.2.3: \u0026quot;As such none of the BORG, the Directors, Officers, Stewardship\nMultisig Members, Supervisors, Emergency Supervisors, and other BORG Personnel\nare able to, or will, accept, undertake or perform a duty of loyalty to or owe\nany fiduciary obligation to any single Community member, sub-group of the\nCommunity, or the Community as a whole.\u0026quot;\n```\n\n## Conclusion\n\nThis isn\u0026#39;t accountability; accountability can clear someone. This process pre-establishes the charge, predefines the mandate, demands the removal, preselects the candidates, and runs even with one.\n\nWhere a rule helps, it bends: a 2–1–1 vote becomes \u0026quot;dysfunction\u0026quot; ([p. 30](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30)), the power the Bylaws withhold becomes the power requested ([p. 12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12)), and the required Supervisor becomes \u0026quot;a separate governance issue\u0026quot; ([p. 11](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11)). Where it doesn\u0026#39;t, it\u0026#39;s absolute — the 75% threshold is immovable for a removal and negotiable to 0.6 when it blocks one ([Art. 3.1.3.2(c), p. 15](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15)); 2.4.5.4 binds while 2.6.2\u0026#39;s bar on that same removal is a technicality ([pp. 10–12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10)); and the materiality test that demands real harm is satisfied by one vote ([p. 30](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30)). A rule is only as absolute as its convenience.\n\n```\nArticle 2.6.2: \u0026quot;The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\u0026quot;\n\n\u0026quot;Adverse Event\u0026quot; means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws...\n\nArticle 2.5.1: \u0026quot;The BORG shall at all times have a supervisor (the \u0026#39;Supervisor\u0026#39;)\nwho is able and willing to supervise the management of the BORG.\u0026quot;\n```\n\nBottom line: no deadlock, no qualifying Adverse Event, no authority to remedy \u0026quot;dysfunction,\u0026quot; and none to instruct a removal. The required Supervisor was never appointed, the outcome and candidates are predetermined, and A272 pairs removing one member with cutting the threshold to 0.6 so two votes that have never differed control everything. If the question is who should sit on the Board, ask that directly — don\u0026#39;t relabel a 2–1–1 vote as an emergency.\u003c/td\u003e\u003ctd class=\"--current\"\u003eI later joined Sei Foundation as DevRel, running its grants program, developer and user outreach, and support, then customer success and solutions engineering at Interchain/Cosmos Labs.\n\nThese were hands-on, community-facing roles: making it as easy as possible for anyone to do something on the network. That gave me a view from every side — retail users, third-party developers, and the foundations in the ivory tower.\n\nI\u0026#39;ve watched this play out across a dozen projects. I\u0026#39;m a stubborn believer in DAO-governed, decentralized, trustless systems, where everyone is a faceless moniker who could be anyone — and the one certainty is that you can never be certain of anyone\u0026#39;s motives.\n\nWhat I\u0026#39;ve seen here is disingenuous conduct by the accuser, drifting well beyond accountability into a witch hunt, with the outcome seemingly decided before the proposal was written, regardless of the arguments.\n\nIt is clear this proposal and the overall process have been structured to produce a removal, not to impartially examine conduct or hold anyone accountable for negligent or otherwise \u0026quot;adverse\u0026quot; actions or events.\n\nThe original proposal having failed with a 2–1–1 vote does not constitute an \u0026quot;adverse event\u0026quot; — if it were an adverse event, a reasonable person would expect the majority of the directors to be in agreement on that statement.\n\nThis is literally the governance system working as intended; with adequate checks and balances. Without them, two members have free rein to do anything they wish.\n\nLet\u0026#39;s go into it a bit deeper though, because... why not?\n\n## There is no qualifying \u0026quot;Adverse Event\u0026quot;\n\nThe precondition is never met. The opening post claims A272 \u0026quot;has resulted in a 2–2 deadlock.\u0026quot; A272\u0026#39;s own appendix records Philipp yes, MB yes, Rose no, Vini not voting: 2–1–1. Across 283 proposals none has ever split 2–2, and 14 of the 271 before A272 failed to reach the threshold.\nA threshold doing its job isn\u0026#39;t a deadlock. Once the count was public, item 1 was downgraded from \u0026quot;the persistent 2–2 Stewardship deadlock on Proposal A272\u0026quot; to \u0026quot;dysfunction\u0026quot;, which is arguably a vague catch-all for any situation, including where one may seek to manufacture a serious issue based on potentially dubious claims or circumstances.\n\nArticle 2.6.1 requires an Adverse Event, not a lost vote ([Bylaws, Art. 2.6.1, p. 12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12)).\n\n```\nArticle 2.6.1: \u0026quot;If there has been an Adverse Event, then, solely to the extent\nnecessary or desirable to resolve or mitigate the impact of such Adverse Event,\nthe Community may appoint by Emergency System Governance Process, through the\nTerra Governance Process, one or more additional Supervisors (an \u0026#39;Emergency\nSupervisor\u0026#39;) to investigate and oversee the BORG while resolution or the Adverse\nEvent is pending.\u0026quot;\n```\n\nNor is there any general mandate to address \u0026quot;dysfunction.\u0026quot; The opening post claims the Bylaws cover \u0026quot;circumstances where the Foundation\u0026#39;s governing bodies become unable to properly perform their responsibilities.\u0026quot; They mention dysfunction once, as an example of an Adverse Event, and only where it materially impairs the Foundation\u0026#39;s ability to perform its duties — the standard set in the definition of \u0026quot;Adverse Event\u0026quot; ([Bylaws, p. 30](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30)). One failed vote isn\u0026#39;t that.\n\n```\n\u0026quot;Adverse Event\u0026quot; means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws, including\nwithout limitation any persistent deadlock or dysfunction of any Body or\nCommunity Autonomous System.\n```\n\nArticle 2.6.2 also caps the office, barring it from removing, replacing, or directing the Board ([Bylaws, Art. 2.6.2, p. 12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12)).\n\n```\nArticle 2.6.2: \u0026quot;The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\u0026quot;\n```\n\nItem 4 nonetheless asks governance to authorize that removal. If the power is needed, then amend the Bylaws. As @0xPhilipp states (several times), this matter must be dealt with under the current structure. Under the current language, it cannot come through an emergency vote, and therefore must be dropped for the time being.\n\n## The voting threshold is not the problem\n\n\u0026quot;The majority decides\u0026quot; is the rule, and the threshold was not met. A majority of four is three; A272 got two, and Board action through the multisig must also meet the multisig\u0026#39;s signing threshold ([Bylaws, Art. 3.1.3.2, p. 15](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15)). \n\n```\nArticle 3.1.3.2(a): \u0026quot;At all meetings of the Board, a majority of the total number\nof Directors then in office shall constitute a quorum for the transaction of\nbusiness and the act of a majority of the Directors present at any meeting at\nwhich there is a quorum shall be the act of the Board, except as may be otherwise\nspecifically provided by statute or by the Charter.\u0026quot;\n\nArticle 3.1.3.2(c): \u0026quot;Notwithstanding the foregoing provisions of this Article\n3.1.3.2, and for the avoidance of doubt, the Board may take no action which\nrequires the use of the Stewardship Multisig as a Mandatory Autonomous System\nunless approved by at least the number of Directors constituting the minimum\nsigning threshold of the Stewardship Multisig, such approval being evidenced by\nthe successful execution of a Stewardship Multisig Proposal.\u0026quot;\n```\n\nA272 itself needed 75% to remove a director, but fell short, so its second message lowered the threshold to 0.6. The rule was fine when it was removing a sitting director; only becoming a problem when it blocked another.\n\nThat leaves A272 doing two things at once: remove one member and drop the threshold to 0.6. Removal is only allowed by System Upgrade ([Bylaws, Art. 2.4.4.1, p. 9](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=9)).\n\n```\nArticle 2.4.4.1: \u0026quot;A Stewardship Multisig Member may be removed from a Stewardship\nMultisig solely by System Upgrade (which may occur at any time or from time to\ntime) causing all of the Multisig Keys of such Stewardship Multisig Member to\ncease to belong to the Multisig Key Set recognized by such Stewardship Multisig,\nit being acknowledged and agreed that any System Upgrade causing such removal\nshall be sufficient, in and of itself to legally deem such person to have ceased\nto be a member of the Stewardship Multisig as a body of the BORG.\u0026quot;\n```\n\nMB has voted identically to Philipp on all 119 proposals where both voted; Rose dissenting 11 times, and Vini three. Remove Vini, cut the threshold to 0.6, and two of the remaining three pass anything without any realistic opposition. That\u0026#39;s not simply fixing a deadlock; it\u0026#39;s changing the mechanism to produce a guaranteed result on all future proposals. Vini explained it in his reply:\n\n\u0026gt; \u0026quot;A272 was more than a removal. It had two messages: removing me from the member group, and changing the PF DAO threshold to 60%. After the removal that means 2 of 3, so two directors could pass anything on their own.\u0026quot;\n\n## The outcome and candidates are seemingly predetermined\n\nItem 1 establishes the Adverse Event, item 3 sets the mandate, and item 4 authorizes the removal it claims to merely investigate:\n\n\u0026gt; \u0026quot;Confirm that the Emergency Supervisor may exercise the powers available under Article 2.4.5.4, including instructing the removal of a Stewardship Multisig Member where the Supervisor determines that this is necessary or desirable to resolve the Adverse Event.\u0026quot; — item 4\n\nArticle 2.4.5.4 obliges Stewardship members to facilitate a removal an Emergency Supervisor instructs ([Bylaws, Art. 2.4.5.4, p. 10](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10)).\n\n```\nArticle 2.4.5.4: \u0026quot;If an Emergency Supervisor appointed in accordance with an\nEmergency System Governance Process instructs the Stewardship Multisig Members\n(or any subset thereof) to facilitate, allow or cause a person to be removed as a\nStewardship Multisig Member via an Emergency System Upgrade due to the Emergency\nSupervisor deeming such removal necessary or desirable to handle an Adverse Event,\nsuch Stewardship Multisig Members shall use their commercially reasonable best\nefforts to facilitate, allow or cause such person to be so removed, as applicable,\nwhich may (at the discretion of the Emergency Supervisor) include removal enacted\nvia Emergency System Upgrade.\u0026quot;\n```\n\nThe proposal claims \u0026quot;both outcomes must remain possible,\u0026quot; yet item 4 has already authorized the removal — one specific outcome. It says \u0026quot;I am not asking Terra Governance to accept my assessment,\u0026quot; while item 1 asks governance to accept that assessment as fact. And Philipp concedes the Emergency Supervisor \u0026quot;cannot directly remove a Director,\u0026quot; then item 4 asks for the removal anyway. Every assurance of neutrality is contradicted by the proposal\u0026#39;s own text.\n\nThe candidates aren\u0026#39;t open either. The opening post presents two names already \u0026quot;acknowledged as potential candidates by three of the four current Stewardship Directors.\u0026quot; A later reply says it proceeds \u0026quot;with only 1\u0026quot; if no third candidate is found, and a later one still says other PF members \u0026quot;already engaged with this process and agreed with the options.\u0026quot; The mandate, the remedy, and the candidate pool are all settled before the community votes.\n\n## The conflict and security charges, checked against the record\n\nA272 attacks a director over A249, a grant that \u0026quot;paid his own company despite a recognized conflict.\u0026quot; The same record shows the accuser authoring and voting yes on at least seven proposals that paid his own address — $20,450 and 3,500 LUNA — with no on-chain record of disclosure or disinterested-director approval ([Bylaws, Art. 4.6.2, p. 23](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23); [Art. 3.2.5.3, p. 20](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=20)).\n\n```\nArticle 4.6.2: \u0026quot;If a BORG Personnel becomes aware of an ongoing material conflict\nof interest with respect to such BORG Personnel\u0026#39;s participation in the BORG, such\nBORG Personnel shall resign from the BORG, unless such conflict of interest has\nbeen disclosed (along with all relevant material facts and circumstances) to the\nBoard and the Community in reasonable detail and such BORG Personnel\u0026#39;s continued\nparticipation in the BORG has been approved by a majority of the disinterested\nDirectors notwithstanding such conflict of interest.\u0026quot;\n\nArticle 3.2.5.3: \u0026quot;Each Stewardship Multisig Member shall ... evaluate the merits\nof each ... Proposal solely in light of the Purposes, Authorized Uses and the\nPrinciples, and, based solely on such evaluation, and without regard to any\npersonal or extrinsic interest or consideration, determine whether to vote in\nfavor of such Proposal ...\u0026quot;\n```\n\nA272 also says written security concerns \u0026quot;were dismissed … potentially exposing about $4.4M,\u0026quot; while Philipp\u0026#39;s own later reply says \u0026quot;MB and I were the ones who identified and reported the issue and triggered the process for an immediate Neutron chain halt.\u0026quot; Both can\u0026#39;t stand unqualified. And the Bylaws impose no duty to monitor, prevent, or report security risks ([Bylaws, Art. 4.4, p. 23](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23)).\n\n```\nArticle 4.4: \u0026quot;Without limiting the generality of Article 4.3, none of the BORG,\nDirectors, Supervisors, Multisig Members or other BORG Personnel shall have any\nduty to the Community or any member thereof to monitor, respond to, prevent,\nmitigate, or announce any actual or perceived security threat or risk, by using\nany Stewardship Multisig or otherwise.\u0026quot;\n```\n\n## The existing requirement for a Supervisor is being ignored\n\nPhilipp calls the missing standing Supervisor \u0026quot;a separate governance issue,\u0026quot; and says structural changes \u0026quot;should not be mixed into this process.\u0026quot; Neither holds against the text: the Bylaws require one at all times, with the power to hold personnel liable for Adverse Events ([Bylaws, Arts. 2.5.1–2.5.2, p. 11](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11)).\n\n```\nArticle 2.5.1: \u0026quot;The BORG shall at all times have a supervisor (the \u0026#39;Supervisor\u0026#39;)\nwho is able and willing to supervise the management of the BORG.\u0026quot;\n\nArticle 2.5.2: \u0026quot;Subject to the limitations in these Bylaws and the other\nGovernance Agreements, the Supervisor shall ensure that the BORG\u0026#39;s rules are\nenforced, and shall have the right and power to hold BORG Personnel liable for\nany Adverse Event caused by such BORG Personnel.\u0026quot;\n```\n\nNo Supervisor has been appointed, despite that \u0026quot;at all times\u0026quot; requirement. Instead the proposal sets its own clock — \u0026quot;maximum of four weeks,\u0026quot; \u0026quot;end of next week,\u0026quot; \u0026quot;with only 1\u0026quot; — while the Bylaws say the Community \u0026quot;may\u0026quot; appoint and set no deadline.\n\n## The edits and remaining arguments do not establish an Adverse Event\n\nThe wording changed several times as claims were challenged. Item 1 swapped \u0026quot;deadlock\u0026quot; for \u0026quot;dysfunction\u0026quot; once the count was public. A later reply swapped \u0026quot;Three Emergency Supervisors is fine with me\u0026quot; for \u0026quot;a single supervisor would be a more efficient way,\u0026quot; and removed the UN Security Council–style restructuring and joining \u0026quot;after the house has been cleaned.\u0026quot; A reply quoting the earlier text was edited; another was deleted.\n\nWhat\u0026#39;s left — mandate, contribution, meme coins, \u0026quot;assets on Terra,\u0026quot; \u0026quot;catastrophic liquidity loss,\u0026quot; \u0026quot;Terra Classic\u0026quot; (alarmist babble), failing to establish an Adverse Event), concerns over months-old matters (A249 closed over 3 months prior to A272), or isn\u0026#39;t an argument at all.\nThe Bylaws require no fiduciary duty to any individual community member ([Bylaws, Art. 4.2.3, p. 23](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=23)).\n\n```\nArticle 4.2.3: \u0026quot;As such none of the BORG, the Directors, Officers, Stewardship\nMultisig Members, Supervisors, Emergency Supervisors, and other BORG Personnel\nare able to, or will, accept, undertake or perform a duty of loyalty to or owe\nany fiduciary obligation to any single Community member, sub-group of the\nCommunity, or the Community as a whole.\u0026quot;\n```\n\n## Conclusion\n\nThis isn\u0026#39;t accountability; accountability can clear someone. This process pre-establishes the charge, predefines the mandate, demands the removal, preselects the candidates, and runs even with one.\n\nWhere a rule helps, it bends: a 2–1–1 vote becomes \u0026quot;dysfunction\u0026quot; ([p. 30](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30)), the power the Bylaws withhold becomes the power requested ([p. 12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=12)), and the required Supervisor becomes \u0026quot;a separate governance issue\u0026quot; ([p. 11](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=11)). Where it doesn\u0026#39;t, it\u0026#39;s absolute — the 75% threshold is immovable for a removal and negotiable to 0.6 when it blocks one ([Art. 3.1.3.2(c), p. 15](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=15)); 2.4.5.4 binds while 2.6.2\u0026#39;s bar on that same removal is a technicality ([pp. 10–12](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=10)); and the materiality test that demands real harm is satisfied by one vote ([p. 30](https://cdn.jsdelivr.net/gh/phoenix-directive/docs@main/Phoenix%20Foundation%20-%20Bylaws.pdf#page=30)). A rule is only as absolute as its convenience.\n\n```\nArticle 2.6.2: \u0026quot;The Emergency Supervisor shall not have any authority to remove,\nreplace, or direct the decisionmaking of the BORG, the Board, or the Guardians,\nbut solely shall have the investigatory and remedial powers identified above, and\nsolely in relation to the specific Adverse Event in connection with which the\nEmergency Supervisor was appointed.\u0026quot;\n\n\u0026quot;Adverse Event\u0026quot; means ... (v) any other change, event, effect, claim, circumstance\nor matter that is or could reasonably be expected to become materially adverse to\nthe ability of the BORG or BORG Personnel to perform or satisfy any of their\nrespective duties, liabilities, or obligations under these Bylaws...\n\nArticle 2.5.1: \u0026quot;The BORG shall at all times have a supervisor (the \u0026#39;Supervisor\u0026#39;)\nwho is able and willing to supervise the management of the BORG.\u0026quot;\n```\n\nBottom line: no deadlock, no qualifying Adverse Event, no authority to remedy \u0026quot;dysfunction,\u0026quot; and none to instruct a removal. The required Supervisor was never appointed, the outcome and candidates are predetermined, and A272 pairs removing one member with cutting the threshold to 0.6 so two votes that have never differed control everything. If the question is who should sit on the Board, ask that directly — don\u0026#39;t relabel a 2–1–1 vote as an emergency.\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e"},"can_edit":false}