Supporting records
The transactions, proposals and public statements behind the power-consolidation timeline: funding received, authority retained and used, financial relationships, voting and proposed changes to the board.
1 NO* — A28 used the wrong contract. MB voted YES on corrected A29.
1. Stated handover, retained control
On 12 August 2024, Philipp Mager’s TLA launch proposal specified transfer of contract administration to Phoenix Directive Stewardship after one month and configuration ownership after three months. The original document identifies the ERIS administration and configuration wallets.
“Contract Admin will be transferred to PD Stewardship after 1 month.”
“Ownership transferred to PD Stewardship after 3 months.”
Read the terms in the original repository
The reviewed chain records show that the authority remained outside Stewardship and was repeatedly exercised. In his public reply on 19 October 2026, Philipp explained that ERIS continued to develop, maintain and operate the contracts and had not considered transferring authority appropriate because of concerns about the board.
That explanation records his decision to withhold the authority. No replacement authorization for the published transfer terms was located in the reviewed records.
The strict transaction count below uses 27 November 2024 at 06:02:52 UTC, three calendar months after proposal 4817’s voting end, as a conservative common cutoff. The launch text does not specify a start-date formula. “Ownership” here refers to contract configuration ownership; it is not a blanket transfer of all software intellectual property.
3. Separate technical powers at the 24 October snapshot
Public chain queries captured on 24 October 2026 still show the q0v wallet as migration administrator of the Phoenix Treasury, global registry and four checked TLA staking contracts. The registry’s stored owner remains the kefa wallet, with no pending owner. The launch documents attribute these addresses to ERIS; Philipp publicly explains the continuing administration.
| Role | Captured address |
|---|---|
| Migration administrator | terra1q0vny4wx2pfteh9zq323wh48c654xacpfq5tew |
| Registry configuration owner | terra1kefa2zgjn45ctj32d3tje5jdwus7px6n2klgzl |
| Phoenix board | terra1k8ug6dkzntczfzn76wsh24tdjmx944yj6mk063wum7n20cwd7lxq4lppjg |
The ordinary Treasury and delegation-controller roles point to the board. Those roles do not remove the separate registry-owner and code-replacement powers. Changing board membership alone does not complete a technical handover.
At the 24 October snapshot, Amplifier proposal 9 was passed: 70 YES weight against a 70-weight threshold, out of 90 total weight. It proposes migration-admin transfers for the ampLUNA hub and CW20-ICS20. At the captured blocks both still named the existing ERIS multisig, so execution was not shown. The proposal does not transfer the Treasury, TLA registry or the hub’s stored owner. These are dated queries at separate heights, not a live status feed.
Sources: CT-treasury_info · CT-registry_info · CT-registry_owner · CT-registry_addresses · CT-proposal9 · CT-proposal9_votes · CT-hub_info · CT-ics20_info
4. Beneficiaries also proposed, approved or executed payments
The same people appear as beneficiaries and as proposers, voters or executors in the following distributions.
| Decision | Recorded conduct |
|---|---|
| Superbolt P3 | Philipp proposed a 7,500-USDC invoice payment and voted YES; payment followed the next day. |
| Superbolt P35 | Distribution allocated 45,000 USDC to Philipp and three amounts of 15,000 USDC. Beneficiary YES votes included Philipp, MB and Rebel; MB executed. |
| Superbolt P9 | MB proposed, voted for and executed his own 7,500-USDC payment on 24 August 2024, with additional YES votes from Philipp and Straylight. |
| Superbolt P41 | Four 10,000-USDC payments. Rebel proposed, supplied the decisive third YES and executed. Philipp received a payment but had no recorded vote on this proposal. |
| ERIS → Rebel, 7 June 2026 | 7,500 USDC with an invoice memo: a paid commercial relationship relevant to disclosure and independence. |
The payments and ballots connect financial beneficiaries to the decisions releasing funds. Neutron’s records also document completed Superbolt milestones.
Selected work/invoice receipts in the attached 105-payment schedule: Philipp-associated recipients 263,555.50 USDC; MB-associated recipients 161,915.50 USDC; Rebel-associated recipients 97,475.50 USDC. This is a selected historical schedule, not complete lifetime income. Upstream project funding and downstream distributions must not be added twice.
The separate 2024 TLA grant of 384,615 LUNA was paid on 7 June 2024 at EndBlock 10,666,963. This native award has no ordinary payment transaction hash. The proposal and block records are supplied. This was project development and audit funding.
Sources: E10a · E10b · E10c · E10f · E10g · E10h · E11a · F01 · F03 · E04a · E04b
5. Milestone payments and captured delivery
A 10,000-USDC Creda analytics milestone was paid on 27 January 2026. The dedicated analytics page appeared unfinished in the 18 October capture. Other analytics screens and an API response were also captured. The linked records preserve the payment, the milestone wording and the captured product screens.
The Estima sequence runs from the rejected 150,000-USDC request to the approved 125,000-USDC arrangement, a 45,000-USDC release and an 80,000-USDC balance not shown paid in that snapshot. No Philipp ballot is recorded on the original approval (A266); he voted YES on the later release (A271). The separate 5,000-USDC migration payment had approvals by the other three directors and no recorded Philipp vote.
Sources: E05b · E05c · E05d · E05e · E05f · E05g · E07a · E07c · E07e
6. A272 would have removed the need for independent consent
A272 sought removal of a member and a threshold reduction from 75% to 60%. With three equal remaining seats, Philipp and MB could approve proposals together even if the third director voted NO. They both voted YES on A272. A272 failed; the captured current configuration remains four equal members and a 75% threshold.
The proposed structure would have made the financially connected pair sufficient to approve decisions without another member’s consent.
The later temporary voting undertaking would limit intended votes, with an exception for onboarding new directors. It would not remove the on-chain ability to authorize actions. The exception also concerns who controls the future board.
The updated Emergency Supervisor proposal allows scrutiny of any director where relevant, but remains framed around the dysfunction underlying A272 and contemplates a removal instruction. The removal process therefore sits alongside the proposed threshold change and the existing distribution of technical and financial powers.
With the present 75% configuration, explicit abstention can affect the denominator; a missing vote is not an abstention. The decisive A272 comparison is two YES votes against the third member’s NO in the proposed three-seat structure.
Sources: E09a · E09b · E09c · FR1 · FR57 · CT-board_config · CT-board_members
7. MB’s votes on Philipp’s proposals
In the retained main-board record, MB voted YES on 251 of the 252 Philipp proposals on which he cast a ballot. The record covers A1–A289, captured on 23 October 2026, and combines MB’s earlier and current board wallets. Philipp submitted 288 proposals: 251 MB YES votes, one NO and 36 with no recorded MB vote.
| MB’s vote on Philipp’s proposals | Number of proposals |
|---|---|
| YES | 251 |
| NO* | 1 |
| No recorded MB vote | 36 |
| Total recorded MB ballots | 252 |
| Total Philipp proposals | 288 |
*The one NO was on A28, which used the wrong contract. MB voted NO on A28 and voted YES on corrected A29 5 minutes 10 seconds later. The A29 proposal identifies the wrong contract and asks that A28 be vetoed.
Philipp submitted 288 of the 289 proposals in this snapshot. MB’s other YES vote was on Vini’s proposal. All 253 recorded MB ballots were matched to successful transactions in the underlying audit.
The voting record, beneficiary approvals and paid relationships must be examined together when assessing independent oversight.
Supporting comparison: shared Philipp–MB ballots
| Comparison | Matching ballots |
|---|---|
| All shared Philipp–MB ballots | 235 / 240 — 97.92% |
| Shared ballots in MB’s current-wallet period | 122 / 123 — 99.19% |
This comparison counts occasions when both people cast a ballot, rather than MB’s votes on proposals submitted by Philipp. The five differing ballots are A28, A57, A58, A85 and A284.
Download all voting rows (CSV) · Download the voting data (JSON) · Read the voting audit
Sources: VOTE
8. Pressure and economic leverage
Validators report pressure over delegation and governance positions. Preserved evidence includes undelegation threats and threats to withdraw operational support. Reports also describe repeated threats following criticism and pressure to align with proposed governance changes.
| Form of pressure | Conduct reported or recorded |
|---|---|
| Delegation | Threatened withdrawal of delegations and pressure on validator participation. |
| Operational support | Threatened withdrawal of maintenance or services during governance disputes. |
| Criticism and access | Demands to remove criticism, backed by threatened exclusion from interfaces or incentives. |
| Governance alignment | Pressure on directors and participants over their positions, including repeated threats following criticism. |
Economic dependence gives these threats force. Delegations, incentives, product access and essential services affect whether participants can challenge the people controlling those resources.
Supporting private records are retained. Reporting-source identities, dates, recipients, exact private wording and relay details are not published.
9. All 19 transactions in the strict TLA count
Transactions are grouped below; multiple privileged operations may occur in one transaction. The linked raw responses and full operation ledger permit independent checking.
| UTC date / transaction | Operations | Recorded action |
|---|---|---|
| 2024-12-18T09:23:25Z 3C9C6A6D94C6… | 1 | Admitted ERIS arbLUNA to voting escrow Added another ERIS product as eligible voting-escrow deposit collateral and selected its ERIS arbitrage vault as exchange-rate source. This changes product eligibility and voting collateral; it is more than a software-version update. |
| 2024-12-27T15:41:30Z 54724BA583C5… | 1 | Replaced voting-gauge code Exercised the power to replace the gauge implementation. Exact old/new binaries are preserved; a complete source-level explanation has not been recovered. |
| 2025-01-27T08:23:22Z 2F974A5FA9F0… | 1 | Replaced voting-incentive manager code Exercised migration authority over the contract administering voting incentives. |
| 2025-04-13T20:30:37Z D3D58602B914… | 3 | Upgraded three original staking contracts Installed code 3585 on Stable, Project and Bluechip staking. Three contract changes in one transaction. |
| 2025-08-12T11:41:56Z BA405CD3EE23… | 1 | Changed the authorized BOT operator list Added an operator to the list used by related automation. BOT is an execution permission; it is not the same as the power to set fees or replace code. |
| 2025-08-17T11:35:18Z 0DB971C43AC0… | 1 | Replaced voting-escrow code: first August upgrade Installed code 3690 in the original voting-escrow contract. |
| 2025-08-17T12:33:19Z 5A3A2B0BC68D… | 1 | Replaced voting-escrow code again Replaced code 3690 with 3692 about 58 minutes later. |
| 2025-08-17T13:33:44Z 3C4D01C64A0E… | 1 | Replaced voting-escrow code a third time Replaced code 3692 with 3694 another hour later. Three separate exercises of the retained migration key. |
| 2025-10-01T11:27:33Z DC3118AA7A0A… | 1 | Redirected incentive-creation fees to ERIS Replaced Stewardship as FEE_COLLECTOR with the ERIS fee account. The separately reconciled captured stream is 228 payments / 2,280 LUNA, approximately $159.95 at receipt-time prices; not the wider ERIS fee total. |
| 2026-09-22T09:55:22Z D3D3B6F6FA5F… | 1 | Set the destination for excluded incentive rewards Set BURN_RECIPIENT to the PF operations wallet. The exact deployed code sends excluded rewards there; the name alone does not mean the underlying value is destroyed. |
| 2026-09-22T10:13:51Z 8EDB8C8956B7… | 3 | Added asset-level incentive blacklisting Upgraded the three original staking contracts to 4033. The new interface permits the registry owner to exclude specified assets from incentive allocation and route their reward share to BURN_RECIPIENT. The same transaction also touched the later Single contract, outside this strict count. |
| 2026-09-22T11:02:18Z 4D6F5AE19115… | 1 | Excluded a Bluechip asset from incentives Called the new owner-only update_incentive_blacklist method for one CW20 asset. The ensuing reward-update transaction sent receipt tokens to the configured operations wallet. |
| 2026-09-22T11:04:44Z 10D4246C800B… | 3 | Applied broader incentive exclusions Added asset lists to all three original staking contracts. The same transaction also covered the later Single contract. This changes reward allocation without using the ordinary asset-whitelist board role. |
| 2026-09-22T13:47:12Z 3C92395B06F1… | 3 | Removed the broader incentive exclusions Removed the bulk asset lists from the three original contracts, about 2 hours 42 minutes after adding them. The ledger preserves the exact add/remove arrays rather than assuming every prior exclusion was cleared. |
| 2026-10-03T02:14:58Z D5111F8A8519… | 3 | Introduced a per-wallet staking restriction Installed code 4037, which consults ASSET_STAKING_BLACKLIST. Controlled execution of the exact binary shows listed senders fail stake, unstake and reward-claim operations before account-state checks. |
| 2026-10-03T02:17:58Z 7545CEEB62C3… | 1 | Put Philipp’s project address in the new FIX list Set ASSET_STAKING_FIX to the project address. At this moment 4037 still read the differently named BLACKLIST list, so this assignment alone did not yet activate the tested 4038 restriction. |
| 2026-10-03T02:19:17Z BB874B99728F… | 3 | Changed the restriction to read the FIX list Installed code 4038, four minutes 19 seconds after 4037. It reads ASSET_STAKING_FIX and applies the same sender-dependent failures. Both binaries report the same v1.9.10 label despite different hashes. |
| 2026-10-03T02:21:42Z 5E62BA4B9B02… | 1 | Replaced the restricted address with another wallet Replaced the project address with terra1uaspcnh3r5etr3szfmgn6ecuum00dm3l7fstvz. That entry remained effective for 15 days 12 hours 52 minutes 32 seconds. This proves the restriction was configured; no failed live attempt by that wallet after activation has been recovered. |
| 2026-10-18T15:14:14Z EDC654FA72CA… | 1 | Removed the per-wallet restriction Emptied ASSET_STAKING_FIX on 18 October 2026. This is another actual use of the retained owner key, 690 days after the common counting cutoff. Removing the entry did not transfer the owner or administrator to Stewardship. |
10. Sources, preservation and download
This public edition contains selected public documents, transaction responses, the voting audit and marked analytical summaries. Private conversations, witness identities, private corporate documents and the private counsel package are excluded.
Original source bytes and publication derivatives are distinguished in the source index. Where an identifying reference was removed from a public forum extract, that file is marked as a redacted derivative. File hashes establish consistency with this published package; they do not independently prove authorship or capture time.
The preserved public repository has a separate Git backup and an earlier independently issued timestamp over its capture manifest. That timestamp applies to that repository manifest, not to this newly prepared summary. The repository bundle was restored and checked locally on 24 October: seven commits and 295 objects.
Original repository · Independent GitHub copy · Handover and repository preservation · External forum archives