Sunsetting Implementation for the $TEC Token

[rex]

Executive Summary

This proposal operationalizes the TEC wind-down with clear roles, deadlines, and safeguards. It establishes the consolidation of all assets to the Common Pool, mandates the conversion of all recovered assets to rETH, and funds a minimal claims mechanism for $TEC holders.

Legacy, deprecated contracts (Reserve and Common Pool) are upgraded by Guardians to freeze the Commons in a recoverable state and enable direct flows from the Common Pool to the claim contract. All other TEC-related multisigs/EOAs have 14 days to return funds to the Common Pool. Any $TEC held by participating multisigs will be burned through the ABC to avoid circular accounting. OP RPGF funds vesting via Superfluid will, upon vesting, be routed by default to the Common Pool and converted to rETH, unless governance directs otherwise between passage and execution.

There will be a four-week process for the community to verifiably raise any hacked addresses so those assets can be frozen and credited back to verified owners.

Closure logic: The claim period is indefinite by default; a future proposal (e.g., a the Severance and Postmortem Proposal) may define an end date and the treatment of unclaimed funds.

**Validity: ** This proposal, after going through the proper review process, will only be valid if a successful Tao Vote is reached.

---

Purpose & Principles

• Stewardship of a Common-Pool Resource: Preserve value and reduce leakage by consolidating fragmented control into a single, accountable executor.
• Clear Collective-Choice Arrangements: Named actors, timelines, and bounded mandates replace ambiguity with explicit, monitorable instructions.
• Monitoring & Transparency: Upgrades and transfers are on-chain; progress updates will be posted at each major state change.
• Graduated Sanctions (Minimal): A time-bound path (14-day remit window) followed by default routing prevents indefinite drift without adversarial posture.
• Proportionality & Finality: Minimal technical scope (rationalized contracts, single claims flow) to limit operational and contract risk; no new programs.

---

Scope

This proposal covers:

1. Asset recovery from legacy Aragon contracts and other TEC-related multisigs/EOAs into the Common Pool.
2. Mandatory rETH conversion in the Common Pool prior to claims funding (executed by Guardians or via authorized adaptor).
3. Build and deployment of a minimal claim contract + UI for $TEC holders (quoted at $5,000 USD).
4. Handling of OP RPGF assets vesting via Superfluid (default → Common Pool → rETH).
5. Token handling rules (burn TEC held by participating multisigs).
6. Claims eligibility & disputes, including a four-week hacked-wallet intake window.
7. Closure logic (indefinite by default; future proposal may define end and unclaimed handling).

Severance and post-mortem budgets are not in scope of this proposal, but stipulations are made in the case that they do or do not pass in a future proposal in order to maintain proposal independence.

---

Governance & Roles

Guardians

• Mandate:
  • Pass upgrades to legacy Aragon contracts (Reserve and Common Pool) to freeze the Commons in a recoverable state (MiniMe and ABC as needed).
  • Enable Reserve → Common Pool and Common Pool → Claim Contract transfers per the Implementation Partner’s technical design.
  • Execute rETH conversions for inbound assets in the Common Pool.
  • Pay the $5,000 USD claim build to the Implementation Partner.
  • Execute contingencies described below and administer the hacked-wallet dispute process per this proposal.

Multisig Signers (other TEC-related units)

• Pre-Step: Withdraw TEC-OP liquidity prior to any transfer.
• Also: Burn any $TEC held (preferably via the bonding curve) before or at remittance to avoid circulars.

Implementation Partner

• Mandate: Build and deploy a lightweight claim contract + UI.
• Budget: $5,000 USD (fixed).

---

Asset Recovery Plan

A) Reserve & Common Pool (Legacy Aragon)

• Action: Guardians execute upgrades that (i) freeze the system in a recoverable state (MiniMe and ABC as required) and (ii) enable direct transfers from Reserve to Common Pool and from Common Pool to the Claim Contract per Implementation Partner design.
• Pre-Step: Withdraw TEC-OP liquidity before moving principal to avoid value leakage.

B) Other TEC-Related Multisigs/EOAs

• Notice: Each unit is formally requested to remit remaining balances to the Common Pool within 14 days of notification.
• If no action by Day 14: The unit is marked dormant and documented publicly; recovery efforts may continue, and any later-recovered funds will be returned pro-rata to tokenholders by topping up the Claim Contract (see “Top-ups” below).
• Conversion Policy: All inbound assets to the Common Pool must be converted to rETH on receipt (hard requirement, executed by Guardians).

C) OP RPGF (Superfluid Vesting)

• Status: Vests over time via Superfluid.
• Rule: On each vesting withdrawal, route to the Common Pool by default and convert to rETH at that day’s rate, unless governance specifies otherwise between passage and execution.

---

Token Handling (Avoiding Circulars)

• Any TEC held by participating multisigs/EOAs must be burned (preferably via the ABC bonding curve; otherwise to the zero address) prior to or at the time of remittance.
• Rationale: Prevent circular accounting and supply feedback.

---

Claims Mechanism (Implementation Partner)

• Budget: $5,000 USD from the Common Pool (fixed).
• Mechanics:
  1. Confirm MiniMe and ABC are frozen or parameterized as required for claims.
  2. Snapshot balances via balanceOf at the frozen block.
  3. Maintain a claimed[address] mapping.
  4. Publish a TEC→rETH rate derived from total rETH committed to claims.
  5. Provide a simple web UI for wallet claims.
  6. Addresses under active hacked-wallet dispute are temporarily frozen until resolution.
• Funding Flow:
  Common Pool converts assets to rETH → pays USD 5,000 for the build →
  If Proposal Three passes: deduct approved severance and postmortem budgets →
  send the remainder to the Claim Contract.

Top-ups from Late Recoveries (Dormant Units)

• If funds from dormant units are recovered after the Claim Contract is funded, they will be:
  • converted to rETH by Guardians and
  • deposited as a new tranche into the Claim Contract.
• The contract should credit all snapshot addresses pro-rata for each top-up; addresses that already claimed become entitled to a second (delta) claim equal to their pro-rata share of the new tranche.

Claims Eligibility & Hacked Wallets Dispute Process

• Four-week intake window (pre-claims): For the first 4 weeks after passage, the community may raise hacked cases; addresses reported during this window are temporarily held from claiming pending review.
• Intake details: The holder opens a forum thread using the Hacked Wallet Case template with tx evidence, incident description, Seal911 due-process proof, and prior-ownership proof.
• Review Panel: 3 reviewers — 1 Guardian, 1 independent steward, 1 additional reviewer designated by Guardians. Standard: preponderance of evidence. Decision and rationale published with PII redacted. SLA ≤14 days (one 7-day extension allowed).
• Remedies:
  • Approved: blocklist compromised address; allowlist a new address for the same amount.
  • Denied or no decision: hold expires; original address may claim.
• Appeal: One time to a broader panel designated by Guardians; majority decision is final.
• Ongoing reports: After the initial four-week window, no further hacked cases may be filed.

---

Timelines & Service Levels

• Day 0: Proposal passes.
• Days 0–2: Guardians queue/execute Aragon upgrades; issue formal notices to all other multisigs/EOAs.
• Day 14: Deadline for remittance to Common Pool; non-remitting units are marked dormant; process continues with available assets.
• Weeks 0–4: Hacked-wallet intake window open; reported addresses held from claiming pending review.
• Rolling: Convert each inbound asset to rETH on receipt.
• Within 2 weeks of funding the build: Implementation Partner deploys Claim Contract + UI, and Guardians fund it from the Common Pool.

---

Closure Logic

• Default: The claim period is indefinite and funds remain claimable by tokenholders.
• Change by governance: A future proposal (including, but not limited to, Proposal Three) may set an end date and define unclaimed handling.

---

Risk Management & Operational Hygiene

• Minimize legacy surface area: One-time Aragon upgrades; avoid bespoke extensions on deprecated contracts.
• Credential hygiene: All signers follow the multisig credential guidelines (key security, rotation discipline).
• Transparency: Public updates at each state change (upgrades executed, transfers received, conversions completed, claims live).

---

Decisions Requested (Snapshot Items)

1. Authorize Guardians to execute Aragon upgrades that (a) freeze MiniMe and ABC as needed and (b) enable Reserve → Common Pool and Common Pool → Claim Contract transfers.
2. Mandate a 14-day remittance window for all TEC-related multisigs/EOAs to the Common Pool; non-remitting units are marked dormant and disclosed, and any late recoveries will be returned pro-rata via top-ups.
3. Require rETH conversion for all inbound assets to the Common Pool prior to claims funding (executed by Guardians).
4. Fund the USD 5,000 claim contract and UI build from the Common Pool.
5. Set OP RPGF default routing: on vesting, to Common Pool and convert to rETH, unless governance specifies otherwise.
6. Adopt the TEC burn policy for any TEC held by participating multisigs/EOAs prior to remittance.
7. Adopt the four-week hacked-wallet intake and the ongoing dispute process described above.
8. Confirm closure logic: indefinite claim period by default; any change requires a future governance decision.

Appendix 1: Multisig Actions Table

Unit	Primary Action	Deadline	If No Action	Notes
Reserve (Aragon)	Guardians upgrade → Reserve → Common Pool	ASAP	—	Withdraw TEC-OP LP first
Common Pool (Aragon)	Guardians enable Common Pool → Claims Contract	ASAP	—	Conversion to rETH enforced
Coordination Team	No Action Required	N/A	N/A	N/A
TECAN	Transfer → Common Pool	14 days	Mark dormant	Convert to rETH on receipt
TE Grants Program	Transfer → Common Pool	14 days	Mark dormant	Convert to rETH on receipt
Lasertag	Transfer → Common Pool	14 days	Mark dormant	Convert to rETH on receipt
TEC GG	Transfer → Common Pool	14 days	Mark dormant	Convert to rETH on receipt
TEC Giveth Donations EOA	Transfer → Common Pool	14 days	Mark dormant	Convert to rETH on receipt
Transaction Team	Transfer → Common Pool	14 days	Mark dormant	Convert to rETH on receipt
ABC EOA	Transfer → Common Pool	14 days	Mark dormant	Convert to rETH on receipt
OP RPGF Superfluid	On each vest route → Common Pool, convert	Rolling	—	Default unless governance reroutes

[linuxiscool]

Well I see this proposal as a scholarly contribution to the TEC. @rex has essentially proposed a graceful shutdown protocol for all TEC token infrastructure. I think it would take a team of domain experts to review and validate the proposal and to execute the scope. I think people like @sem @laurenluz @Griff @divine_comedian @JeffEmmett @JessicaZartler @octopus @curiousrabbit.eth @mzargham (and many others, post is limited to 10 tags) would have excellent domain expertise relevant to this consideration and may have interesting perspectives to share as stakeholders.

Thank you @rex for writing this up, I found it generally very educational from a token infrastructure perspective and I appreciate the level of detail.

[DecentralizeSDGs]

Dear @rex

Thank you for the highly detailed proposal. Would very much appreciate some points of clarification on the following:

1. How are tokenholders’ governance rights preserved or altered once all assets are moved to the Common Pool and the bonding curve (ABC) is frozen or deprecated?
2. Will TEC holders retain any formal voting power or proposal rights after the wind-down, particularly over decisions like future claims closure or unclaimed fund allocation?
3. How does the proposal ensure that the Guardians remain accountable to tokenholders, given their central role in executing upgrades, asset conversions, and dispute resolutions?

Thank you and look forward to your reply.

[rex]

@DecentralizeSDGs

How are tokenholders’ governance rights preserved or altered once all assets are moved to the Common Pool and the bonding curve (ABC) is frozen or deprecated?

I prefer a $TEC burn mechanism, which requires a temporary governance freeze. This is because one person claiming affects the percentage holdings of remaining participants over the Common’s Assets, and also opens up the space for an attack there if governance were still active.

The $TEC contracts themselves would remain recoverable in case governance unpauses are desired.

@DecentralizeSDGs

Will TEC holders retain any formal voting power or proposal rights after the wind-down, particularly over decisions like future claims closure or unclaimed fund allocation?

I propose a month-long process from the date of this proposal passing to its execution in which to amend the claims closure and unclaimed fund parameters. I am open to alternative viewpoints on how to define these, but do not think that defining them as part of this proposal makes sense.

@DecentralizeSDGs

How does the proposal ensure that the Guardians remain accountable to tokenholders, given their central role in executing upgrades, asset conversions, and dispute resolutions?

Since the OP upgrade, Guardians have had the rights to freeze any proposals in Tao, as well as any technical upgrades for any part of the Commons. Despite this, they have always remained loyal, so I believe that the overwhelming social negative backlash of going against the Commons continues to be a sufficient deterrent.

Nevertheless, I would propose that the process continue to be transparent, with the Implementation Partner making detailed forum posts for community feedback before Guardians execute any code, as per previous upgrades.

A further note: I believe that the current Guardians multisig is a 3/7. Motioning to increase that threshold to 4 or 5 may be of interest as part of this proposal, as it raises the cost of attack and makes Guardians take an active look at these sensitive proposals.

---

Here is relevant information on the Guardians:

Introducing TEC Guardians

Introduction As part of the likely migration of the TEC to Optimism, it is important to share some of the thoughts and recommendations that the TECAN has been discussing regarding the purpose and role of the “Guardians” once the TEC has migrated to OP. We want to continue this conversation with the community for advice and further refinement of the proposal through this forum post. About Guardians Celeste, the arbitration method for resolving proposal disputes, is not available on Optimism. H…

TEC Guardians Nominations

The vote is closed and final results are: Guardians: Tam, Griff, Sem, PhilH, Enti, Bear, Gideon Alternates (will automatically become, in this order, a Guardian in the event of any departure): Ygg, Nate, Juanka

[rex]

Some have asked for reference on the current status of Commons funds. Here are the latest details to the best of my knowledge:

Request for Accounts Transparency

I’d like to formally request that the full list of TEC-associated multisigs with remaining funds be made public, along with their current balances. This information was not included in the H2 2025 Strategic Proposal nor in the Sunsetting the TEC Proposal, yet it is critical for both coordination and accountability; and for the first step of either: the return of unused funds to the common pool. To my knowledge, @bear100 maintained a CSV of the multisigs and their signers as of last month. I re…

[DecentralizeSDGs]

Dear @rex

Thank you for the clarifications. Would like to understand still how this will play out in a scenario where less than all $TEC token holders claim and remain active. How then is the TEC governed once the claims process had ended and who retains control over the Commons Pool allocation? What rights will $TEC holders who have not claimed have retained? What will $TEC rights be if there is a second Hatch or some sort of funding mechanism? Your clarifications on these points would be greatly appreciated. Thank you.

[natesuits]

@DecentralizeSDGs with this proposal, there would be nothing left to govern for remaining $TEC holders. All funds from both the Reserve of the ABC, and the Common Pool would simply be converted into rETH, and put into a claims contract for an indefinite period of time.

The exchange rate between $TEC and $rETH would be established, and at any point in time, a $TEC token-holder can exchange it directly for $rETH at the established rate. Those funds will remain in the contract until all of it is gone.

I believe if there were to be another hatch, or fund-raise at some point in the future it would be with a completely different set of stakeholders, utilizing a different token architecture, and separated from the functions of any remaining $TEC tokens.

For those wanting to continue with the efforts of the TEC, the Coordination Team is available and willing to facilitate what may be a set of constructive next steps in terms of both funding and direction. With that being said, there is nothing to gain from holding onto $TEC after the claims contract goes live, as there will be no utility for it.

[DecentralizeSDGs]

Dear @natesuits @rex

Thank you for the clarifications. However, this proposed approach undermines the rights of active $TEC token holders. Dissolving those rights without a clear and legitimate claim to the remaining assets beyond the claim in rETH in Commins Pool is problematic, especially when there’s ambiguity about who will be able to re-monetize them. Whether it’s an unspecified group or the Guardians with non-tokenized authority, this isn’t how a managed wind-down should work. Token holders should absolutely retain a stake in any future value gained from a re-Hatch, if realized, and any decision around the future should involve transparency and accountability to the community that helped build it.

[c-georgen.eth]

I very much agree with @DecentralizeSDGs here. I can’t understand the desire to remove any sort of optionality from those who still wish to see TEC succeed. I see the open ended claim window (even if it is modified in the future) coupled with a full conversion back to rETH as a forced end of TEC.

There should be a way to just let people exit the system if they want without paying an exit tax for some limited window.

[DecentralizeSDGs]

Dear @c-georgen.eth

Fully agree as I cannot support a displacement of token holder interest through forced liquidation with no claim to future TEC assets and governance.

Kindly ask @rex to consider the foregoing in a modified proposal that will protect residual $TEC token holder rights. Thank you.

Cc: @natesuits @gideonro