Primary source document, preserved from the TEC archive. Personal names, handles, and emails have been redacted to
[REDACTED]; content otherwise unchanged (export formatting cleaned).
TEC Forum Timeline
2020-10-30 — Step by Step Guide to Interact with the New TEC Conviction Voting Platform
Forum thread: Step by step guide to help you interact with the new TEC CV (Conviction Voting) platform Category: Conviction Vote / Archive Archive theme: Conviction Voting, test interface onboarding, wallet setup, proposal submission, governance participation
October 30, 2020
A practical guide was published to help community members interact with the new TEC Conviction Voting test platform. The thread was not a debate or a funding discussion. It was an onboarding document meant to reduce friction for people who wanted to test the governance interface and learn how to participate in proposal support and submission.
The guide walked participants through the basic infrastructure needed to use the test system. It began with setting up MetaMask, configuring the xDai network, selecting or importing the correct wallet address, and optionally adding the TESTTEC token to the wallet so that balances could be viewed directly. The guide also explained that the test platform used xDai because it followed an Ethereum-style architecture while keeping transaction fees very low.
The thread then explained how participants could fund their wallet with a small amount of xDai in order to transact on the test interface. The amount required was described as minimal, with a faucet suggested as the easiest way to receive enough xDai for many test transactions. If the faucet failed, the guide directed participants to ask the community for help.
Once the wallet setup was complete, the guide explained how to enable an account in the TEC interface, connect the correct wallet, and verify that voting power appeared on the webpage. It then introduced the core action of the Conviction Voting system: selecting a proposal and assigning voting power to support it. The guide clarified that voting power could be added or withdrawn, and that the interface would show both total and inactive balances.
The final part of the guide described how to submit a proposal. The process connected the forum to the voting platform by instructing participants to use a proposal template, publish the proposal information in the forum, and then include the forum link when creating the proposal in the interface. The thread closed by pointing participants toward an explanatory Conviction Voting video for more context on how the system worked.
This thread captured an early operational moment in TEC governance: the community was preparing people to move from discussion into hands-on experimentation with Conviction Voting. It helped translate the governance mechanism into concrete user actions: configure a wallet, obtain test funds, connect to the interface, allocate voting power, and link proposals back to the forum.
2020-10-31 to 2020-12-05 — TEST Research DAO Chat Bot
Forum thread: TEST - Research: DAO Chat Bot Category: Conviction Voting / Archive Archive theme: Test proposal, DAO notifications, social media bot, onchain event monitoring, open source tooling
October 31, 2020
A test research proposal was opened to explore whether a DAO chat bot could notify community channels when relevant onchain properties changed. The basic idea was to create a tool that could watch for events such as proposal updates, DAO property changes, token status changes, or other metrics, and then publish formatted updates into channels such as Discord or Telegram.
The rationale was practical: not everyone would be sitting at a laptop watching governance interfaces, but many people could receive mobile notifications from a subscribed channel. The proposed bot would allow people to follow DAO activity in a more ambient way, while also letting them mute the channel if they did not want constant updates.
The proposal also framed the tool as potentially useful beyond TEC. If open sourced, the same pattern could serve other Aragon, 1Hive, or DAO-adjacent projects. The initial scope was research rather than a funded build, with an expected research window ranging from a few days to a few weeks depending on the complexity discovered. The requested funding amount was zero, making this a lightweight test proposal and exploratory contribution.
The technical sketch imagined a small server application that would connect to the chain through websockets, watch specific addresses for events, and forward relevant messages into social channels. The likely skills required were identified as web development and JSON-RPC experience, though the details were expected to become clearer through research.
November 7, 2020
The proposal passed, confirming that the community was willing to support experimentation with notification infrastructure even at a small or zero-budget scale. This marked the thread as an early example of using the Conviction Voting process to validate lightweight research and tooling ideas.
November 19, 2020
A working document was shared for the project. This moved the proposal from a conceptual research idea into an active documentation and design phase. The thread began to function as a public progress log for the bot work.
December 5, 2020
Code was shared from an early implementation branch. The technical direction was still being explored, but the conversation had moved into concrete architecture decisions. The bot was being considered as an event-based system, with Go and goroutines identified as a promising route for handling onchain event streams, even though much of the surrounding industry tooling still leaned heavily toward Node.js.
The scope expanded from a single chat bot to a more extensible notification framework. Two design goals were identified: a plugin API that could support multiple DAO systems, such as Aragon, Compound, Ocean, or others, and support for multiple social platforms, especially Discord and Telegram. This suggested that the project was not just a TEC-specific alert bot, but potentially a reusable infrastructure component for DAO operations.
The thread also captured an architectural tradeoff between GraphQL and JSON-RPC. GraphQL, especially through services like The Graph, was described as powerful because it connected IPFS and Ethereum data and allowed the application to consume processed results. But it also introduced concerns around vendor dependence, documentation quality, and implementation friction. JSON-RPC over websockets was described as more broadly available and easier for teams to run themselves, though it might require more custom work, including handling IPFS logic directly.
By the end of the thread, the DAO chat bot had evolved from a simple notification idea into a broader research question about how DAO systems should expose activity across social channels. The thread captured early TEC experimentation with making governance activity more visible, mobile-friendly, and operationally accessible through open source tooling.
2020-11-04 to 2021-07-25 — GitHub Activity Channel on Discord
Forum thread: Have a github-activity channel on discord Category: Ideas / Archive Archive theme: GitHub activity, Discord integration, coordination tooling, webhooks, GitHub Actions, project management visibility
November 4 to November 15, 2020
An idea thread was opened to create a Discord channel that would automatically show GitHub activity such as pull requests. The proposal was inspired by another community’s Discord setup and framed the integration as a simple way to make development activity more visible to the broader community.
The first discussion focused on implementation questions. The community considered whether TEC would eventually move into its own Discord, how easy it would be to add new repositories, and whether there should be separate channels for general GitHub activity and project-management activity. The coordination repository was specifically mentioned as a possible source of updates because it was being used to organize general work.
The thread then clarified that GitHub webhooks usually need to be added repository by repository rather than to an entire GitHub account. This made the idea feasible but somewhat manual. The conversation also briefly surfaced a broader question about whether TEC should separate from the larger token engineering Discord environment or remain embedded in a more comprehensive community space.
December 14 to December 15, 2020
A small correction clarified that Discord itself was not open source, even though it was commonly used by open source communities. The thread then went quiet for several months.
July 12 to July 25, 2021
The thread was later revived with a more concrete implementation path. Instead of relying only on outgoing GitHub webhooks, the community considered using GitHub Actions triggered by issues, pull requests, pushes, or other repository events. A simple workflow file in the .github/workflows folder could send messages into Discord through a webhook, making the integration easier to reproduce across repositories.
The idea of separate channels returned. One channel could track all activity in the coordination repository, giving people a way to follow ZenHub and GitHub updates while staying inside Discord. More advanced notification use cases, such as mention-specific alerts or direct messages, were identified as possible but more complex.
The thread ended with the integration being set up for the coordination repository. The resulting channel did not track mentions, but it did send event updates whenever activity happened in the repository. This gave TEC a lightweight bridge between development/project-management activity and Discord visibility.
By the end of the thread, a simple tooling idea had turned into implemented coordination infrastructure. The thread captured TEC’s effort to make GitHub work more legible to non-developers and to reduce the gap between repository-based work, ZenHub-style project management, and the Discord spaces where contributors spent their time.
2020-11-05 — Hatch Parameters General Discussion Thread
Forum thread: Hatch Parameters General Discussion Thread Category: The Hatch / Archive Archive theme: Hatch design, parameter coordination, test Hatch results, bonding curve, Impact Hours, vesting, Hatch tribute, holistic commons design
November 5, 2020
A general Hatch parameters discussion thread was opened to collect and coordinate the many smaller parameter discussions involved in designing the TEC Hatch. The thread began by emphasizing that the Commons had multiple technical and cultural components, and although it was useful to break those components into parameters, the Commons ultimately needed to be designed holistically. All components had to work together to create a healthy economy for coordinating value production in token engineering public goods.
The thread summarized the first Rinkeby Test Hatch. That test had a minimum goal, a time limit, a fixed exchange rate between test contribution tokens and TESTTEC, and a Hatch Tribute. Because the raise did not reach the minimum goal, the Hatch entered a return state and participants could convert their TESTTEC back into the original test contribution token at the original rate. This made the test useful for understanding failure and refund behavior.
The Rinkeby test also illustrated how funds would have been split if the Hatch had succeeded. Part of the raise would have gone to the non-redeemable pool for token engineering projects and operations, while the rest would have gone to the redeemable pool. The thread also explained how TESTTEC would have been minted for contributors, how Impact Hours would have been converted into tokens, how vesting would have locked tokens at first and then gradually unlocked them, and how the opening bonding curve price and reserve ratio would have shaped the initial economics.
The thread then pointed to the second test Hatch on xDai as the first full rehearsal test launch, with parameters available in the implementation scripts. This positioned the general thread as a place to compare test results, document assumptions, and connect practical rehearsals to parameter decisions.
The post also served as an index of smaller deep-dive discussions. It linked to topics on Hatch goals, Hatch time limit, Hatch return, CSTK ratio, Impact Hour rewards, Hatch Tribute, and vesting. Each of those subthreads examined a specific parameter or design area, while this general thread was meant to collect the most important points and eventually help merge them into one coherent Hatch design.
By the end of the thread, the Hatch parameter process had been framed as a systems design problem rather than a set of isolated choices. The community needed to understand each parameter, but also how minimum and maximum goals, time limits, refund behavior, membership ratios, contribution rewards, tribute percentages, vesting, bonding curve settings, and cultural incentives fit together into the overall Commons design for the next test deployment.
2020-11-05 to 2021-05-07 — Hatch Goals Deep Dive
Forum thread: Hatch Goals Deep Dive Category: The Hatch / Archive Archive theme: Minimum goal, maximum goal, target goal, Hatch funding design, bonding curve initialization, whale risk
November 5, 2020
A Hatch parameter deep dive was opened to explain the Hatch Goals. The thread identified two main goals: the Minimum Goal, meaning the amount that needed to be raised during the Hatch to initialize the bonding curve, and the Maximum Goal, meaning the maximum amount of funds that could be sent to the Hatch.
The thread noted that the test configuration had set both goals to the same value. This made the math simpler, created clear expectations for Hatchers, and removed variables from the Hatch, especially the opening price and redeemable pool ratio. But the post also explained that this approach did not fully match the original Commons Stack design, which had intended to keep Hatch Price and Open Price constant while allowing the amount raised to vary.
The discussion raised several foundational questions. Could Hatch Price and Open Price remain constant if the Hatch goal was not both the minimum and maximum? Should the system use a combined minimum and maximum, separate minimum and maximum values, only a minimum, or a minimum with a very high maximum? If the amount raised was variable, how should the system handle that variability? And what information should the community use to decide the actual values?
November 15 to November 17, 2020
The thread then explored how Hatch Goals related to the reserve ratio, open price, Hatch Price, Hatch Tribute, and funding pool. One clarification was that the reserve ratio could be modified through Dandelion Voting after the Hatch and before the bonding curve opened, which meant the community could still preserve a predetermined Open Price.
The conversation emphasized that the Minimum Goal and Hatch Tribute together would determine the minimum reserve ratio and the minimum amount of funding available in the funding pool when the Commons launched. This made the Minimum Goal a critical parameter: it was not just a fundraising target, but a constraint on whether TEC would begin with enough funds and enough collateralization to operate responsibly.
The thread also connected Hatch Goals to the decision to begin as a Hatch DAO and then upgrade later. This structure made it possible to separate the initial fundraising and guaranteed donation logic from the later bonding curve launch.
May 7, 2021
Several months later, the thread was updated with clearer parameter explanations. The Minimum Goal was described as the amount of wxDai required for the Hatch DAO to deploy. If the minimum was not reached, all contributed funds would be refunded, the Hatch DAO would not deploy, and Impact Hours would have no value. The update explained that setting the minimum too low would make deployment easy but might reduce fundraising motivation, while setting it too high would create a serious risk of failure.
The Maximum Goal was described as the cap on how much wxDai could be collected during the Hatch. Once reached, the Hatch would end and the Hatch DAO would deploy. The update emphasized the governance implications of this cap. If the maximum were effectively unlimited, large contributors could receive substantial TECH voting power. This risk was partly mitigated by Trusted Seed alignment and the rule limiting how much voting power any single contributor could receive.
The Target Goal was then described as the amount the community expected to raise. Unlike the minimum and maximum, the target functioned partly as a social parameter. It helped inform dashboard design and gave the community a rallying point for outreach and fundraising. A target set slightly beyond expected fundraising capacity could motivate contributors to organize more actively and push for greater participation.
By the end of the thread, Hatch Goals had evolved from a simple minimum-versus-maximum design question into a full discussion of fundraising strategy, contributor expectations, token distribution risk, collateralization, funding pool adequacy, and community motivation.
2020-11-05 to 2021-05-07 — Hatch Period Deep Dive
Forum thread: Hatch Period Deep Dive Category: The Hatch / Archive Archive theme: Hatch duration, fundraising window, communication strategy, trusted participation, FOMO, co-vesting
November 5, 2020
A Hatch parameter deep dive was opened to explain the Hatch Period. The thread defined it as the amount of time the Hatch would remain open for collecting funds. Before the Hatch, no one could join TEC through the Hatch process. During the Hatch, Hatchers could contribute xDai and receive TEC. After the Hatch, Impact Hours would be rewarded and the bonding curve would be deployed so that anyone could mint TEC through the open curve.
The initial question was simple: what information should TEC use to decide the length of the Hatch Period? This made the thread a discussion about campaign timing, contributor readiness, outreach, urgency, and the type of participants TEC wanted to attract.
November 13 to November 30, 2020
The thread began comparing the Hatch to other fundraising events. One line of thinking looked to crowdfunding campaigns, where shorter campaigns often perform better because donations tend to cluster at the beginning and just before the deadline. From this perspective, a concentrated campaign around thirty days could be enough, especially because the Hatch was focused on the Trusted Seed rather than the entire public.
Other comments compared different durations, such as two weeks, thirty days, or forty-five days. A shorter period could create urgency and focus attention, but it would only work if the community had already prepared materials, outreach, and communication channels before the Hatch opened. A longer period would give people more time to understand the project and prepare funds, but it could also dilute urgency and cause people to lose interest.
December 3 to December 6, 2020
The discussion then moved into the social dynamics of urgency and FOMO. Some participants questioned whether a Hatch should rely on fear of missing out, especially if TEC wanted value-aligned stewards rather than short-term opportunists. The thread raised the concern that designing around FOMO could attract the wrong mindset for long-term governance.
At the same time, the discussion acknowledged that people often need deadlines to act. A Hatch Period needed to be long enough for the message to resonate and for contributors to organize, but short enough that attention and momentum did not fade. The thread framed the parameter as a tradeoff between urgency and thoughtful participation.
The thread also clarified who could participate in the Hatch. There was initial confusion about whether anyone could contribute or whether only Trusted Seed members could participate. The discussion eventually clarified that the Hatch was the co-vesting phase for aligned members, while the later open phase would allow broader participation through the bonding curve. This distinction reinforced why the Hatch Period was not just a generic fundraising window, but a curated membership and governance initialization period.
May 7, 2021
The thread was later updated with a user-facing definition. The Hatch Period was described as the number of days Trusted Seed members would have to send wxDai to the Hatch. Setting it too short could prevent members from organizing their finances and participating. Setting it too long could cause people to lose interest and deprioritize the Hatch.
The suggested range was fourteen to forty-five days. By the end of the thread, the Hatch Period had been framed as a timing parameter with cultural consequences. It affected fundraising capacity, urgency, contributor readiness, communication strategy, and the balance between value-aligned co-vesting and broader post-Hatch participation.
2020-11-05 to 2021-05-07 — Hatch Tribute Deep Dive
Forum thread: Hatch Tribute Deep Dive Category: The Hatch / Archive Archive theme: Hatch Tribute, redeemability, Rage Quit, funding pool, public goods funding, backer-builder incentives
November 5, 2020
A Hatch parameter deep dive was opened to explain the Hatch Tribute. The thread defined the Hatch Tribute as the percentage of funds raised during the Hatch that would not be redeemable by TECH token holders. All other funds would remain redeemable by Hatchers.
The thread explained that if the Commons Upgrade occurred, the funds collected through the Hatch Tribute would go to the Funding Pool. Those funds would then support token engineering public goods and DAO operations through Conviction Voting. In this framing, the Hatch Tribute operated like a tax on Hatchers that guaranteed some portion of the Hatch would become committed public goods funding.
The discussion framed the parameter as a tradeoff. A high Hatch Tribute would guarantee more funds for the final Commons and its public goods mission, but could discourage people from contributing to the Hatch because less of their contribution would be redeemable. A low Hatch Tribute would make the Hatch more attractive to backers because they could exit with more of their funds if they disliked the Commons Upgrade, but it would also leave less guaranteed funding for the Commons.
The thread therefore centered on one main question: what information should TEC use to determine the Hatch Tribute? The post also noted that the definition had been updated to reflect the two-part launch structure, where the Hatch DAO would come first and the Commons Upgrade would happen later.
May 5 to May 7, 2021
The thread was later revived with a sharper framing of the tradeoff: collective commitment versus money-back flexibility. The Hatch Tribute was described as one of the more contentious parameters because it shaped the social contract between community backers and community builders.
A high Hatch Tribute was described as a stronger commitment device. If someone funded the Hatch under a high tribute, they were more fully committing to the project regardless of the exact form of the eventual Commons Upgrade. This could help preserve consensus and force participants to resolve disagreements at the table rather than exiting. But it could also reduce flexibility for backers who disagreed with later parameters, make exit less appealing, increase internal conflict, and reduce the amount of funding people were willing to risk.
A low Hatch Tribute was described as a stronger money-back guarantee. It gave backers more flexibility to exercise Rage Quit rights if they disliked the Commons Upgrade parameters. This could make larger contributions more likely because contributors knew they could reclaim more funds if they disagreed with the final design. But it also created a risk that large backers could use the threat of exit or their funding power to influence the Commons Upgrade.
By the end of the thread, the Hatch Tribute had been framed as a core political and economic parameter. It was not merely a percentage in the Hatch configuration. It determined how much funding was irreversibly committed to TEC’s public goods mission, how much exit protection backers retained, and how the community balanced trust, commitment, negotiation, and fundraising capacity.
2020-11-10 to 2021-02-16 — Contribution Reward
Forum thread: Contribution Reward Category: Community Updates Archive theme: Praise, Impact Hours, SourceCred, contribution accounting, reward distribution, decentralization, identity, post-Hatch rewards
November 10, 2020
A community update was opened to examine alternative contribution reward systems. The thread began by recognizing that Praise had been working well as a broad cultural method for recognizing contributions, but that the system was beginning to face scaling problems as more work happened, more contributors joined, and more Praise was created.
Three major challenges were identified. First, manual quantification was becoming time-consuming. Second, there was not yet a clear post-Hatch process for distributing token rewards based on Impact Hours once the Commons was running. Third, subjective quantification created centralization risk because only a few people had enough context to evaluate the value of contributions across the whole system.
The thread introduced research into contribution, rewards, roles, and possible alternatives. SourceCred was proposed as an experiment that could coexist with Praise and potentially create a more automated system. At the same time, another line of thinking explored a Praise 2.0 or credit system that could better structure how contribution recognition might work as TEC scaled.
A set of imported comments suggested a more distributed approach to recognizing value. The proposal was to let individuals distribute recognition subjectively, then use relative distribution and peer weighting to decide how much influence different recognizers should have. The idea was that people closest to the experience of value should be able to recognize it, while network-based weighting and later sybil-resistance methods could reduce manipulation as the system grew.
November 13 to November 30, 2020
The thread then moved from theory into implementation. Work began on a SourceCred experiment, and an initial TEC SourceCred instance was created. The next steps were to decide parameters, determine how to avoid double rewards between Praise and SourceCred, think through sanctions for abuse, draft social contract language, explore identity tools such as BrightID, and design a minimum viable approach for testing before launch.
The discussion also surfaced doubts about SourceCred. Some participants worried that it might encourage team play, popularity dynamics, or gaming, while Praise still felt more culturally aligned even though fewer people were involved in deciding what counted. The idea of electing or rotating people who could dish or quantify Praise was raised as one possible way to reduce centralization while keeping human judgment.
December 3 to December 11, 2020
Testing preparations began. The SourceCred instance would pull activity from Discord, the forum, and GitHub, which required consolidating people’s handles across services. This made identity mapping a practical requirement for contribution accounting.
The discussion then focused on hybrid designs. One concern was that SourceCred could over-reward chat activity if Discord participation became too heavily weighted. Another concern was that simple reactions or emojis could turn contribution measurement into a popularity contest. A proposed alternative was to use Praise as the underlying signal while SourceCred helped scale and automate the tracking, with reactions acting as trust signals rather than direct measures of value.
A possible bridge between Praise and SourceCred was proposed: different reactions could correspond to contribution types or impact tiers, and a contribution would need a minimum level of trusted confirmation to receive the corresponding credit. The design attempted to preserve the qualitative judgment of Praise while using SourceCred infrastructure for scalability.
The thread also discussed risks from self-reporting and gaming. If contributors had to report their own work, forgotten reports could go unrewarded while over-reporting could be exploited. This led to a preference for continuing to rely on Praise rather than pure self-reporting, with a very limited and slowly expanding circle of trusted recognizers.
January 14, 2021
The discussion returned after additional SourceCred progress. Two guiding questions were raised. First, how should the community reward what SourceCred tracked? Options included distributing TEC tokens directly through the SourceCred instance, dishing Praise according to SourceCred scores, or creating a template for people to request SourceCred-based rewards from the Commons. Second, how should the community distinguish what Praise should recognize from what SourceCred already tracked?
A fake-token distribution test was prepared so the community could observe how contributions from GitHub and the forum were being tracked and rewarded before deciding whether or when to implement the system for real. This treated SourceCred as something that needed shared understanding and community review before it could become part of actual compensation.
January 30 to January 31, 2021
The thread explored the idea of working-group-level statistics. If each working group had internal contribution metrics, the community could better understand whether Praise was being dished consistently and whether the recorded data reflected actual work. This opened the possibility of comparing contribution signals with working group goals and using metrics to support governance analysis over time.
February 12 to February 16, 2021
The thread then developed a broader post-Hatch theory of contribution rewards. One view argued that the purpose of contribution rewards should be to recognize members for executing functions within TEC, rather than trying to perfectly quantify every individual contribution. SourceCred was seen as useful, but not as a complete objective measure of value. The community did not need a perfect reward system from the beginning; it needed a system that worked with TEC’s current setup and served the functions it was designed to accomplish.
The discussion questioned whether Praise and Cred were fundamentally different or mostly different languages for contribution recognition. The cultural value of the term Praise was emphasized, and the idea was raised that TEC should preserve Praise even if the underlying technical system changed. Praise was described as culturally powerful because it encouraged broad recognition and intrinsic motivation.
A possible class-based reward structure was proposed, where different ranges of Praise or Cred could place contributors into classes that shared portions of a general distribution. These classes could also connect to non-monetary forms of recognition, responsibility, access, or role titles. This reframed contribution rewards as a possible basis for administrative structure, not only compensation.
Another parallel system was imagined where working groups would define tasks and allocate Cred to the execution of specific goals and functions. This would require planning, budgeting, and stronger administrative processes. The thread recognized that the administrative burden of tracking Praise in spreadsheets was itself a major problem, and that identity integration plus SourceCred-style automation might be necessary infrastructure if TEC wanted to preserve Praise at scale.
The final discussion returned to the tension between automation and qualitative judgment. Fully automating Praise quantification could remove the human weighting that made the system meaningful and could make it easier to game. One alternative was to fractalize the quantification process rather than fully automate it, or to use Impact Hours in structured reward classes while preserving human evaluation where it mattered. Identity integration remained an open question.
By the end of the thread, contribution rewards had become one of TEC’s most important cultural and operational design problems. The thread captured the transition from manually quantified Praise toward possible hybrid systems involving SourceCred, trusted recognition, identity, Impact Hours, fake-token testing, working group metrics, post-Hatch distribution, and role-based recognition. The central challenge was how to scale contribution accounting without losing the cultural and qualitative value that made Praise effective in the first place.
2020-11-11 to 2022-01-03 — Intrinsic Motivation
Forum thread: Intrinsic Motivation Category: Community Updates Archive theme: intrinsic motivation, reward systems, Praise, accountability, onboarding, reciprocity, care, belonging, engagement metrics
November 11, 2020
This community update summarized a Soft Gov discussion about how TEC could create an environment where reward and punishment mechanisms remained secondary, while intrinsic motivation became the primary driver of collaboration. The thread treated incentives as necessary but insufficient: the deeper question was how to cultivate a community where people wanted to contribute because they cared about the mission, each other, and the public goods being created.
The reflections connected intrinsic motivation to care, reciprocity, recognition, trust, belonging, and empowerment. Contributors described motivation as emerging when people feel that their ideas matter, that they can actually participate and change things, and that they are part of a community exploring a shared purpose. Gratitude and recognition were described as trust-building practices, while reciprocity was framed as a flow between giving and receiving that makes contribution feel natural rather than forced.
The discussion also explored how intrinsic motivation translates into action. One important idea was that people do not want to let others down, but that obligation can damage relationships if contribution becomes burdensome. The proposed response was to make participation easy to enter and exit, break work into smaller pieces, and encourage contributions regardless of size. This connected intrinsic motivation to lightweight accountability: people should be able to help when they are genuinely motivated without being trapped by excessive obligation.
The thread linked motivation to value creation and onboarding design. The community needed clear pathways for newcomers to understand how they could contribute, evolve, and receive recognition. Game design, ecosystem value flows, and structured onboarding were raised as ways to transform care and curiosity into actual contributions. An action item emerged to translate these reflections into engagement metrics and system design.
November 15, 2020
A follow-up response deepened the philosophical framing. It argued that intrinsic motivation gives meaning to the work and that communities become life-changing when they help people find something important to do with others. The response emphasized welcoming and inclusive culture, experimentation without fear, and sustainability based on how much people truly care.
January 3, 2022
More than a year later, the thread was revived with a question about whether the action item on engagement metrics and system design had progressed. By the end of the thread, intrinsic motivation had been documented as an early TEC cultural principle: reward systems mattered, but the Commons would only remain healthy if contributors felt care, trust, recognition, purpose, and a low-friction path from motivation into action.
2020-11-15 to 2020-11-28 — Vesting Cliff and Vesting Complete Periods Deep Dive
Forum thread: Vesting Cliff and Vesting Complete Periods - Deep Dive Category: Conviction Vote / Archive Archive theme: Hatch parameters, vesting design, token lockups, bonding curve, long-term alignment
November 15, 2020
A deep dive was opened to clarify two Hatch vesting parameters: the vesting cliff period and the vesting complete period. The vesting cliff was defined as the period after the Hatch when newly minted tokens would be fully locked and could not be converted back into xDai through the bonding curve. The vesting complete period was defined as the period after the Hatch over which those tokens would become fully unlocked.
The thread used the Rinkeby Hatch test as an example. In that test, tokens would have been completely locked for three days and then would have begun unlocking linearly until all tokens were unlocked by day twenty one. This example helped translate an abstract Hatch parameter into a concrete timeline of when participants would or would not be able to exit through the bonding curve.
The thread then compared the current implementation with the original Commons Stack design. The existing implementation was time based, but the earlier design imagined vesting as being tied to how much capital had been allocated from the funding pool toward projects that benefited the commons. That alternative would have created an incentive for Hatch participants to actively govern and allocate funds, because their tokens would unlock as capital moved into public goods and commons-supporting work.
Because the implemented system was limited to time-based vesting, the thread proposed a framework for comparing different options. For the vesting cliff, it separated short cliffs of one to four weeks, medium cliffs of one to three months, and long cliffs of three to twelve months. For the vesting complete period, it separated short periods of one to eight weeks, medium periods of two to twelve months, and long periods of one to four years. The thread asked the community to consider the benefits, drawbacks, and information needed to choose values for each parameter.
The discussion then explored whether tokens should unlock linearly or gradually increase the unlock percentage over time. A concern emerged that simply copying a ratio from a test environment, such as making the full vesting period seven times longer than the cliff, might become unreasonable if the community chose a much longer cliff. Longer lockups were seen as potentially helpful for token price stability and investor confidence, but also as a restriction on participants’ access to their tokens.
Later that day, the conversation turned to the incentive effects of vesting design. The original idea of tying vesting to funding allocation was recognized as elegant because it would encourage Hatch participants to use Conviction Voting and support projects. But the thread also identified a possible problem: the mechanism might incentivize people to spend funding pool money quickly, even if proposals needed more time to mature or be evaluated. This raised the distinction between encouraging governance activity and encouraging good governance decisions.
A long vesting period was proposed as a way to give the community time to learn Conviction Voting, grow sustainably, and avoid pump-and-dump behavior. The discussion compared DAO vesting to startup vesting, while also recognizing that crypto moves faster and is shaped by bull and bear market cycles. One position favored a short cliff paired with a very long vesting complete period, emphasizing sustainable growth and long-term commitment over short-term liquidity.
November 28, 2020
The thread later returned to the practical tradeoff between protecting the project and keeping participation attractive. A short vesting period was viewed as risky because funds could leave before the project had time to consolidate. Since Hatch participants were expected to be known and aligned members of the community, waiting a few months was framed as reasonable.
At the same time, very long vesting periods measured in years were also seen as risky because crypto moves quickly and excessive lockups could discourage larger contributions. A mid-term vesting period was suggested as a compromise, especially because the community would retain the ability to revise the initial parameters through governance if the chosen settings later proved wrong.
By the end of the thread, vesting was understood as one of the major alignment mechanisms of the Hatch. The discussion did not only ask how long tokens should be locked. It asked what kind of behavior the lockup should encourage, how much exit pressure the bonding curve should face early on, how much liquidity Hatch participants should have, and whether the community should prioritize flexibility, investor confidence, long-term commitment, or rapid experimentation.
2020-11-19 to 2021-02-19 — Launching in Two Parts: Hatch and Dandelion First, then ABC and Conviction Voting
Forum thread: Launching in 2 parts: First Hatch + Dandelion, then Vote to add ABC & CV Category: The Hatch / Archive Archive theme: Hatch launch strategy, Dandelion voting, Augmented Bonding Curve, Conviction Voting, legal risk, critical path, governance sequencing
November 19, 2020
A thread was opened to propose launching TEC in two stages. The first stage would deploy only the Hatch and Dandelion DAO. The Hatch Tribute would still split funds into two pools: a non-redeemable pool dedicated to token engineering projects and TEC operations, and a redeemable pool dedicated to creating the DAO’s economic system. The Augmented Bonding Curve and Conviction Voting apps would then be added later by a vote of TEC token holders.
The proposal argued that this staged launch had several advantages. It would give the most complicated and fund-controlling applications more time for review, while allowing the technical team to focus efforts through a staggered launch. It could also reduce legal complexity by initially launching as a Moloch-style charity DAO where contributions functioned more like donations, potentially reducing KYC requirements and making participation easier. Finally, the staged launch would filter for Hatch participants who cared about governance and public goods rather than short-term token speculation.
The thread also identified downsides. Onboarding and communications would become harder because the community could no longer promise that participants would immediately receive a token connected to a bonding curve. A smaller Hatch might result from this uncertainty. The community would also need to immediately test its social governance capacity by educating Hatch participants about what they would vote on when deciding whether to add the ABC and Conviction Voting.
November 24, 2020
The discussion raised several concerns about moving forward too quickly. The main worry was not opposition to launching in two parts, but whether the community had enough clarity around what would count as a successful, fair, and inclusive Hatch. Questions were raised about KPIs, diversity of participation, maximum or target raise amounts, whether a second Hatch would be possible if the first did not meet broader success goals, how CSTK would affect participation, whether the Trusted Seed was sufficiently engaged, and whether onboarding and communications had enough timeline certainty to prepare.
The replies acknowledged these concerns and expanded the discussion. One important distinction emerged: financial parameters alone could determine whether the Hatch technically completed, but they might not capture whether the Hatch was healthy for the community. If TEC wanted broader success criteria, those would need to be identified before launch. The discussion also clarified that CSTK was expected to determine proportional Hatch participation and that further debate might be needed around minimum or maximum participation caps.
The thread then sharpened the question of inclusion. One position argued that the Hatch should not simply maximize inclusivity or participation volume. Instead, the Hatch should prioritize aligned participants who cared about advancing token engineering public goods, and should actively avoid speculators seeking governance power for financial upside. This framed the Hatch less like an ICO and more like the founding process for a mission-driven public goods organization.
The discussion also treated the proposal as a directional governance decision rather than a full launch plan. The community still needed to identify critical path work, risks, timelines, and dependencies. A process was suggested for working groups to label Hatch-critical issues so the community could understand what work was blocking launch and what timeline was feasible.
December 4 to December 22, 2020
The staged launch proposal passed through TEC’s decision process. A Hatch process diagram was shared to help explain the launch flow. Later, a new version of the diagram added Impact Hours minting, showing how the launch architecture continued to evolve as details were clarified.
February 19, 2021
An updated Hatch DAO diagram was shared, reflecting further iteration of the launch architecture. The thread therefore continued to serve as a living reference point for the staged Hatch design and its implementation details.
By the end of the thread, TEC had decided to launch in two stages: first with the Hatch and Dandelion DAO, then later through token holder approval of the Augmented Bonding Curve and Conviction Voting. The thread captured a major strategic decision in TEC’s launch design, balancing technical readiness, legal risk, social governance, Hatch participant quality, onboarding clarity, and the need for the community to vote on the economic infrastructure after launch.
2020-11-19 to 2020-11-25 — Principles 1&2: Rules and Boundaries
Forum thread: Principles 1&2 - Rules and Boundaries Category: Community Updates Archive theme: Soft governance, Ostrom principles, commons boundaries, governance rules, token design, TEC scope
November 19, 2020
A discussion was opened after a soft governance conversation about the first two of Ostrom’s commons principles: clearly defined boundaries and rules that fit local circumstances. The thread asked how these principles should be interpreted in a cyber commons, where the boundaries are less obvious than they would be in a physical commons.
The conversation began by returning to TEC’s stated values: a prosocial, human-centered orientation; high standards for safety, resilience, and integrity; openness, non-hierarchy, creativity, transparency, and accountability; and support for public goods and ethical economic systems. The thread asked whether these values were actually functioning as shared expectations, whether anything should be added or modified, and whether there had already been unmet expectations related to values or conduct.
The post framed rules and boundaries as a way to reduce ambiguity before conflicts emerge. The basic idea was that many conflicts arise from unclear expectations or different interpretations of the same subject. Because TEC was designing its own governance system, the community needed simple and accessible language for rules and boundaries, and each rule or boundary needed to be examined carefully until its meaning was as clear as possible.
An early brainstorm separated possible rules from possible boundaries, while also recognizing that some items could function as both. Possible rules included the code of conduct, exit tribute, Conviction Voting, graduated sanctions, different expectations across tools such as the forum or Discord, Dandelion voting, Hatch tribute expectations, and proposal templates. Possible boundaries included communication channels, exit tribute, reward systems, token launch, token holding, hard governance, active membership, technical expertise, and proposal templates.
The thread invited the community to continue expanding and refining the list before proposing a more developed version back to the wider community. It also encouraged people to think about rules and boundaries in everyday contexts, such as households, social groups, relationships, and informal agreements, as a way to make the abstract governance discussion more concrete.
November 20, 2020
The discussion moved toward a technical interpretation of boundaries. A key point emerged: boundaries are what allow rules to apply. In the TEC context, one clear technical boundary was the TEC token itself, because the community could define the rules that applied to that token. The token could be transferable or non-transferable, redeemable or non-redeemable, tied to a bonding curve, or governed through other mechanisms.
The bonding curve was described as a kind of membrane between the internal TEC economy and the external xDai economy. This made token design a governance boundary, not only a technical implementation detail. The community’s ability to govern depended partly on where the system drew the line between what TEC could control and what was outside its control.
November 23, 2020
The thread then proposed that some of these technical boundaries might need deeper explanation and dedicated voting rounds. Questions were raised about the implications of transferable versus non-transferable tokens, whether TEC tokens should also exist in the funding pool, and what it meant to have a bonding curve with a reserve.
This shifted the discussion from a broad values conversation into a more specific design process. The community needed to understand how each technical choice would affect the commons before deciding which rules and boundaries to adopt. A combined technical specification and soft governance conversation was suggested as a way to bridge the social and technical sides of the design.
November 24, 2020
The thread developed a more detailed explanation of token-related governance boundaries. Transferable tokens were described as behaving more like money, because they could move between accounts, be given away, sold, or bridged elsewhere. Non-transferable tokens were described as more like account-bound shares that could only be minted or burned through DAO-approved mechanisms. Locked or vested tokens were distinguished as a separate design choice: they could preserve voting rights while restricting transfer or burn actions for a period of time.
The discussion weighed the tradeoffs. Non-transferable tokens would give the community more control over how the token could be used and would prevent secondary markets, but they would also restrict experimentation and individual creativity outside the DAO’s boundaries. Locking or vesting tokens could encourage long-term commitment by preserving voting rights while reducing short-term market manipulation.
The conversation also compared whether a DAO funding pool should use the governance token or a stable asset. A simpler design could use the same token for both voting and funding, but this would expose proposers and the DAO treasury to token price volatility. A stable funding pool would provide a clearer unit of account and support longer-term planning, but it would require a more complex system involving a bonding curve and tribute flows. The thread treated token price, market conditions, and external crypto cycles as boundaries because they shape what the DAO can do even when the DAO does not control them.
The same day, the discussion returned to TEC’s scope and identity. Concerns were raised about whether the boundary between the Token Engineering Commons and the broader Token Engineering community was being drawn too narrowly. The thread surfaced tension between focusing resources on launching TEC successfully and supporting the wider ecosystem of existing token engineering public goods, educational efforts, and community projects.
A response clarified that the narrower launch boundary was intended to protect focus before TEC was fully launched. The argument was that TEC could support the wider token engineering community after launch, but before launch it needed to avoid diluting attention across too many worthy projects. At the same time, the discussion acknowledged that there were already mechanisms, such as praise and project proposals, that could recognize and support broader token engineering work.
November 25, 2020
The conversation closed by revisiting the unresolved tension around where TEC’s boundary should be drawn. One position held that TEC needed a focused boundary around launch readiness and capital formation. Another view emphasized that the commons already included existing token engineering public goods, models, tutorials, books, and educational work, not only the future funding capacity TEC might create.
By the end of the thread, the discussion had expanded Ostrom’s first two principles into a practical design problem for TEC. Rules and boundaries were not treated as abstract governance theory. They were connected to values, conflict prevention, communication channels, proposal processes, token transferability, bonding curves, funding pool design, launch focus, and the relationship between TEC and the broader token engineering ecosystem. The thread captured an early attempt to define the social and technical perimeter of the commons before the system was fully launched.
2020-11-20 to 2020-12-03 — Hatch Return Deep Dive
Forum thread: Hatch Return - Deep Dive Category: The Hatch / Archive Archive theme: Hatch failure state, minimum raise, refunds, impact hour compensation, non-redeemable pool
November 20, 2020
A short deep dive was opened to clarify what should happen if the Hatch failed and entered a return state. The thread began from the practical question of what “Hatch return” should mean: if the raise did not meet its minimum goal, should participants simply receive their contributions back, or should some portion of the funds still be directed toward impact hour compensation, the non-redeemable pool, or another commons-oriented destination?
The discussion used the first test Hatch as the example. In that test, the Hatch had a target amount and a fixed exchange rate between the contribution token and TESTTEC. Because the test did not reach the required target, the system entered a return state. Participants were then able to exchange their TESTTEC back for the original contribution token at the original rate.
The thread identified the main condition under which the Hatch should not complete: the minimum goal amount was not reached. It then surfaced the key design question that followed from that failure condition. If the Hatch failed, should there be any compensation for prior contribution work, any allocation to the non-redeemable pool, or should the system return all contributed funds to Hatch participants?
The default option at the time was a full refund to Hatch participants. This framed the failed Hatch state as a clean reversal of the contribution process rather than a partial allocation event. The thread therefore highlighted a boundary between a successful Hatch, where funds could be distributed into the post-Hatch economic system, and a failed Hatch, where the system should likely avoid making discretionary allocations.
November 30, 2020 to December 3, 2020
The later replies suggested that the minimum threshold for continuing with the project should be set low enough that failing to reach it would be unlikely. This shifted the emphasis from designing complex failed-Hatch allocations toward parameterizing the Hatch so that the return condition would only happen under clear and serious underfunding.
By the end of the thread, the Hatch return mechanism was treated as an important safety and clarity feature. The thread did not settle a complex alternative distribution scheme. Instead, it captured the early assumption that if the Hatch failed to reach its minimum, the cleanest and most legitimate outcome would be to return funds to participants, while using the minimum goal parameter to define when the project had enough support to proceed.
2020-11-21 to 2021-05-07 — Impact Hour Rate Deep Dive
Forum thread: Impact Hour Rate Deep Dive Category: The Hatch / Archive Archive theme: Cultural Tribute, Impact Hours, Praise, builder rewards, Hatch incentives, dynamic ownership allocation
November 21, 2020
An Impact Hour Rate deep dive was opened to explore one of the most important and difficult parts of the Hatch: how to reward the people who contributed to TEC’s Cultural Build. The thread explained that cultural contributions were measured through Praise, which recorded acknowledgements of work and then translated them into Impact Hours through a scoring process.
The thread described three parts of the contribution measurement process. Acknowledgement captured work through the Praise system. The boundary process determined how much Impact Hour credit each praise instance should receive. The single reward principle reduced Impact Hour credit for work that had already been directly compensated elsewhere, helping avoid double payment.
The initial framing explained that Impact Hours would translate into Hatch contributions, with a portion of funds raised during the Hatch creating tokens for Cultural Build contributors. The more funds raised, the higher the hourly value of Impact Hours would become. The more total Impact Hours existed, the lower the payout per hour would become. This made the Impact Hour Rate a dynamic mechanism linking builder rewards to fundraising success and total recognized work.
December 6 to December 13, 2020
Follow-up discussion shared educational resources and called for more feedback on how the Impact Hour Rate should connect to Hatch Goals. The thread raised several unresolved questions: how minimum and maximum Hatch Goals should relate to minimum and maximum Impact Hour rates, what equation should determine the rate, what minimum wage was appropriate, and what should happen to Impact Hours if the Hatch failed.
The thread emphasized that if the Hatch failed, builders would receive nothing from this mechanism. This made the Impact Hour Rate not merely a compensation formula, but a design problem involving risk, fairness, morale, and incentive alignment.
December 14 to December 22, 2020
The discussion then became more mathematical. A formula was introduced where the independent variable was the amount of funds raised and the dependent variable was the Impact Hour Rate. The formula used total Impact Hours, a slope-like parameter representing expected raise per Impact Hour, and a maximum Impact Hour Rate that the curve approached as an asymptotic limit.
The community explored how different parameter settings changed the curve. A high slope made the function nearly linear, while a lower slope made the function more curved and increased the share of raised funds allocated to Impact Hours. The thread also explored how to set bounds around the results, such as ensuring a minimum hourly rate and constraining the percentage of the Hatch allocated to the Cultural Build.
The conversation clarified that the slope parameter could be understood as the raise level at which Impact Hour holders receive half of the maximum rate. This made the parameter conceptually important but difficult to name and explain. The thread began moving toward a tension that would remain central: the formula needed to be mathematically sound, but also understandable enough for community members to use when proposing parameters.
April 25 to April 28, 2021
During user testing, the Impact Hour Slope concept proved difficult for participants to understand. A proposal was made to introduce a more user-facing variable called Curvature, derived from the relationship between maximum rate and slope. The goal was to let users reason visually about how curved the Impact Hour Rate line should be instead of forcing them to understand a less intuitive mathematical parameter.
The thread then debated whether the math should prioritize conceptual clarity or user experience. One approach defined curvature as a direct relationship to the maximum rate, while another preferred an inverse formulation because it had clearer mathematical meaning. The discussion showed the practical difficulty of turning token engineering formulas into interface controls that normal Hatch participants could understand.
A later simplification suggested using the Target Goal directly in the formula. If the Target Goal was reached, Impact Hour holders would receive half of the maximum rate. This reduced the number of parameters and connected the formula to a funding goal the community was already discussing. Another option defined the curve from two intuitive points: the maximum rate at infinity and the rate at the minimum or target goal. This approach was welcomed because it let users choose a meaningful point on the line and the asymptote, making the curve easier to reason about.
May 7, 2021
The thread was later updated with clearer user-facing definitions. The Impact Hour Rate at Target Goal was described as the amount of wxDai allocated for each Impact Hour when the Hatch reached its target. This parameter determined how much builders were rewarded relative to their recognized contributions and depended on the amount raised during the Hatch.
The Impact Hour Rate at Infinity was described as the theoretical maximum rate that Impact Hours could approach. It served as an asymptote for the curve and helped define the incentive strategy of the Hatch. A higher maximum increased the possible reward for builders as the Hatch raised more funds, but also affected the distribution of voting power between builders and backers.
By the end of the thread, TEC had transformed a difficult builder compensation question into a more mature Hatch design mechanism. The discussion connected Praise, Impact Hours, fundraising outcomes, builder rewards, backer incentives, target goals, maximum rates, and user-interface simplicity into one evolving parameter design problem.
2020-12-01 — Dandelion Voting Parameters General Discussion
Forum thread: Dandelion Voting Parameters General Discussion Category: Dandelion Voting / Archive Archive theme: Dandelion Voting, hard governance, DAO upgrades, support required, quorum, vote duration, proposal buffer, rage quit, tollgate fee
December 1, 2020
A general discussion thread was opened to coordinate the Dandelion Voting parameters. The thread framed Dandelion Voting as the hard governance layer of TEC, with the power to upgrade the DAO, add applications, change parameters, adjust roles and permissions, and handle operational decisions not covered by Conviction Voting. The first major decision expected for this layer was whether to upgrade the DAO to include the Augmented Bonding Curve and Conviction Voting apps.
The thread emphasized that, like the Hatch parameters, Dandelion Voting needed to be understood both as a set of individual settings and as part of the overall Commons design. The community could break the system down into parameters for clarity, but the whole governance stack needed to work together to create a healthy token engineering public goods economy.
A test Dandelion Voting deployment on xDai was summarized. Its parameters included support required, minimum quorum, vote duration, vote proposal buffer, rage quit period, and tollgate fee. These values gave the community a concrete test configuration to analyze before deciding which settings should be used in the real TEC launch.
The post also served as an index for smaller parameter deep dives. It linked to discussions on support required, minimum quorum, vote duration, vote proposal buffer, vote execution delay or rage quit period, tollgate fee, and the number of Dandelion Voting instances. Each subthread was meant to unpack a specific design decision, while this general thread tied the pieces together.
By the end of the thread, Dandelion Voting had been established as TEC’s mechanism for high-authority governance decisions. The thread clarified that Conviction Voting would handle public goods funding, while Dandelion Voting would govern upgrades, permissions, parameter changes, and other foundational actions. It created a central reference point for understanding the parameters that would control TEC’s hard governance process.
2020-12-01 to 2021-05-07 — Support Required Deep Dive
Forum thread: Support Required Deep Dive Category: Dandelion Voting / Archive Archive theme: Dandelion Voting, Disputable Voting, support thresholds, supermajority, consensus, governance configuration
December 1, 2020
A Dandelion Voting parameter deep dive was opened to explain Support Required. The thread defined Support Required as the percentage of voting tokens that must vote yes, out of the tokens participating in the vote, for a proposal to pass. The post emphasized that Dandelion Voting and Disputable Voting were token-weighted systems, not one-person-one-vote systems.
The initial framing suggested that a reasonable range was somewhere between a simple majority and a strong supermajority. Below a majority threshold, a proposal could pass even if most voting power opposed it. But if the threshold was too high, a small minority could block nearly any decision. This made Support Required a parameter about the balance between consensus and governability.
The thread asked what information TEC should use to choose the parameter, what benefits came from high support requirements, and what benefits came from lower support requirements. It also raised the possibility that different kinds of decisions might need different thresholds.
December 1 to December 3, 2020
The discussion then explored the role of supermajorities. One perspective argued that ordinary decisions should use lower-friction thresholds, while strategic or long-term decisions should require broader consensus. The thread also raised the idea that too many thresholds could make governance unnecessarily complicated, and that a small number of decision levels might be easier for participants to understand.
Another idea was to handle high-stakes decisions through stakeholder groups rather than simply raising the support threshold. This would be similar to systems where different chambers or constituencies must approve a decision. In TEC’s context, this pointed toward the broader problem of matching voting rules to the type of permission or decision being made.
The thread connected this directly to the idea of multiple Dandelion Voting instances. Some permissions would be basic, while others would be critical. TEC might therefore need different voting configurations for different decision classes, with different minimum quorum and support requirements depending on the impact of the action.
May 7, 2021
The thread was later updated with a clearer user-facing definition. Support Required was described as the percentage of yes votes out of the vote total required for a proposal to pass. It was presented as an important part of responsible voting configuration because it reflected the degree of consensus required among token holders.
The update framed high Support Required as a way to ensure stronger consensus around major decisions like the Commons Upgrade. A low Support Required would allow a smaller majority to determine the outcome. The suggested range was set broadly, and the related parameters were Minimum Quorum and Vote Duration.
By the end of the thread, Support Required had been framed as a core governance parameter for deciding how much agreement TEC should require before taking action. It connected voting thresholds to legitimacy, speed, minority veto risk, proposal impact, and the possibility of using different voting instances for different kinds of decisions.
2020-12-01 to 2021-11-26 — Central Database: Django REST Framework
Forum thread: Central Database - Django Rest Framework Category: Conviction Voting / Archive Archive theme: central database, Django REST Framework, backend API, data infrastructure, Praise quantification, Commons Simulator, maintainers, technical funding
December 1, 2020
This funding proposal introduced the idea of building a central database using Django REST Framework. The goal was to let TEC systems connect through a shared backend so the community could store and access data about Hatchers, community activity, technologies, development, and other operational needs. Django REST Framework was presented as a robust Python-based API framework suitable for backend database services.
The proposal argued that a shared database would make it easier for any TEC system to get or post data through web requests. Example use cases included Praise quantification and tracking Commons Simulator results over time. The initial estimate was small: roughly four development hours for an initial launch, with additional one-hour batches to add new tables as the community clarified what data it wanted to maintain.
December 3, 2020 to January 5, 2021
Early replies supported the idea and treated it as a useful infrastructure investment. The discussion then shifted from initial build cost to sustainability. A follow-up clarified that the database would need enough community interest to be maintainable and usable, along with several community members comfortable acting as maintainers and handing off responsibility if they stepped away.
The cost estimate was revised to include redundancy and ongoing support. Instead of a four-hour one-off project, the thread proposed involving three programmers for development, deployment, maintenance, and upgrades over six months. This produced a much larger estimated budget and reframed the proposal as both infrastructure development and knowledge dissemination: the project would fund community developers while teaching them how to operate Django REST Framework.
November 26, 2021
Much later, the thread was revived when the database idea was connected to conversations about tools like HubSpot for tracking information. This showed that the original data-infrastructure question remained relevant as the TEC’s operations became more complex.
By the end of the thread, the central database proposal had moved from a simple backend build into a broader question of institutional data stewardship. The TEC needed shared data infrastructure, but it also needed maintainers, documentation, handoff plans, recurring support, and clarity about which data belonged in a community database versus other operational tools.
2020-12-03 to 2020-12-16 — Proposal Questions
Forum thread: Proposal Questions Category: Feedback and Questions / Archive Archive theme: Proposal guidance, TEC thesis, vision, mission, values, funding scope
December 3, 2020
A general question thread was opened for people who needed help understanding how to submit proposals. The thread served as a lightweight support space for proposal authors and created a place where uncertainty about proposal scope, expectations, and process could be surfaced publicly.
December 10, 2020
The thread quickly moved from procedural questions into a deeper question about TEC’s thesis. The central issue was not just how to submit a proposal, but what kinds of proposals TEC wanted to see. The discussion asked what value was most needed in the near term, what would matter in the mid term and long term, and whether a concise statement of TEC’s vision would help proposal writers understand how to orient their work.
This was an important governance moment because it showed that proposal infrastructure alone was not enough. For people to write useful proposals, they needed a shared understanding of the commons’ purpose, priorities, and funding scope. The thread therefore revealed a need to connect proposal-making with mission clarity.
December 15, 2020
The question was acknowledged as timely, and a broader post was being prepared to gather more feedback on the topic. This suggested that the community recognized the need to clarify proposal direction rather than treating it as a one-off question.
December 16, 2020
The thread then provided a concise restatement of TEC’s vision, values, near-term mission, and long-term mission as guidance for proposal authors. The vision described a world with safe digital socio-economic public infrastructures that are diversely designed and aligned with collective needs. The values emphasized a prosocial human-centered perspective, safety, resilience, integrity, open-source culture, non-hierarchy, creativity, transparency, accountability, public goods, and ethical economic systems.
The near-term mission was defined as launching TEC with a resilient culture. The immediate focus was on creating the technical and cultural conditions for a successful launch, including a Trusted Seed, an Augmented Bonding Curve or similar mechanism, a community funding pool, Conviction Funding, and upgradeability so the system could improve after launch. Until that work was complete, the cultural and technical build remained the primary focus.
The long-term mission was described as gathering and stewarding funds for projects in token engineering, with the goal of encouraging robust and ethical tokenized infrastructures. TEC was framed as a system that would curate and connect projects to resources while maintaining its own regenerative infrastructure, where capital supports contributions, contributions create value, value empowers token engineers, and people who appreciate that value contribute capital back into the system.
By the end of the thread, the proposal question had become a mission-alignment question. The thread helped clarify that early proposals should support the launch, culture, infrastructure, and readiness of TEC, while the longer-term purpose of TEC was to fund and steward token engineering public goods.
2020-12-05 to 2020-12-11 — Principle 3: Participatory Decision Making Is Vital
Forum thread: Principle 3 - Participatory decision making is vital Category: Community Updates Archive theme: Ostrom principles, participatory governance, advice process, forum polls, Dandelion voting, Conviction Voting
December 5, 2020
A community update was opened after a soft governance discussion on Ostrom’s third principle: participatory decision making is vital. The thread framed participatory governance as one of the central promises of DAOs, because these systems are meant to increase inclusivity, autonomy, and the ability of people inside a commons to shape the rules that affect them.
The discussion connected Ostrom’s work to the problem of people being trapped inside systems where they cannot coordinate or change the rules of the game. Dandelion voting was described as an important hard governance mechanism because it gave the community the ability to change governance constraints directly. But the thread also emphasized that hard governance alone was not enough. The community also needed informed participation, good coordination, and decision-making practices that could help people reach better collective outcomes.
The thread urged participation in the Hatch parameter discussions because technical parameters were being opened to community input. This was treated as an unusual and valuable opportunity: instead of leaving technical governance design to a small group, the community was being invited to understand the parameters and help shape the system before launch.
The thread then mapped different decision types to different tools. Dandelion voting was framed as the mechanism for changing hard governance constraints. Conviction Voting was framed as the mechanism for funding proposals and possibly signaling. Forum polls were proposed for smaller offchain decisions, lightweight signaling, and early feedback before proposals moved into Conviction Voting. This created a layered decision-making model rather than pushing every decision into the same mechanism.
The working group notes surfaced several open questions: not all decisions should go to Conviction Voting; voter apathy needed to be addressed; the community needed to understand whether the people voting were sufficiently informed; voting incentives could help participation but also risked gamification; data-driven research and voting psychology could improve the process; reputation systems might matter; collective ownership needed to be cultivated; regular voting rituals could help; and future mechanisms might include liquid democracy or quadratic conviction voting.
The thread proposed reviving and normalizing the advice process as a cultural practice. The advice process was presented as a way to reduce voter apathy and improve decision quality by asking proposal creators to seek input from people who would be affected by a decision and from people with relevant expertise. The proposal was to move more decision-making activity from Discord into the forum, where discussions could be more visible, structured, and connected to future Conviction Voting proposals.
A forum poll was included to test the polling tool and ask whether the advice process should be used for all decisions, including those that would eventually go to Conviction Voting. The thread therefore served both as a governance argument and as a live experiment with the forum as a decision-making venue.
December 10, 2020
The follow-up discussion clarified how the community should move from emoji voting toward forum polls. The thread proposed that the forum poll tool should replace Discord emoji votes, while keeping a familiar structure for yes, neutral, and block options. The forum was preferred because it allowed people to explain their reasoning, add context, and engage more deeply with the proposal before a vote.
A practical process was outlined: publish a proposal in the proposal category, tag people whose advice would be useful because they had relevant expertise or would be affected, incorporate feedback where appropriate, edit the post to add a poll, and update the title with the voting deadline. Voting would continue to happen over the weekend, with results collected after the weekend.
The thread also clarified a blocking rule. If more than 15 percent of voters blocked a proposal, then the blockers would win and the proposal would need to be revised to incorporate their concerns. This preserved the idea that blocking was not just a symbolic vote, but a signal that the proposal needed meaningful revision before moving forward.
December 11, 2020
The thread closed with minor interface clarification around the forum polling tool. By that point, the important outcome had already emerged: TEC was formalizing a shift from informal Discord reactions toward a more deliberate forum-based process for advice, discussion, signaling, and lightweight decision making.
By the end of the thread, participatory decision making had been translated into an operational workflow. The community was not only affirming that participation mattered in principle. It was deciding which tools should handle which kinds of decisions, how proposals should seek advice, how voting should be structured, when votes should happen, and how blocks should force revision. This thread captured TEC’s early attempt to build a participatory governance culture before the Hatch and to prepare the forum as the shared space where offchain governance would mature.
2020-12-06 to 2021-05-07 — Tollgate Fee Deep Dive
Forum thread: Tollgate Fee Deep Dive Category: Dandelion Voting / Archive Archive theme: Proposal spam prevention, public proposal access, Dandelion Voting, Tollgate Fee, proposal cost, attack resistance
December 6, 2020
A Dandelion Voting parameter deep dive was opened to investigate the Tollgate Fee. The thread began by noting that the parameter was not immediately obvious from the Dandelion documentation, but that it appeared in the test Hatch as a fee required for creating a proposal. The thread then identified the Tollgate app as an Aragon forwarder that requires a user to deposit a fee before executing an action.
The initial purpose of the Tollgate Fee was framed as spam prevention. It allowed proposal creation to be public or more open while still imposing a cost on low-quality, malicious, or spammy actions. The thread asked whether the fee should be constant, whether it should only apply to public participants, whether it could be used to manipulate outcomes, how independent the parameter was, and what other factors should shape it.
The discussion then considered the fee as a resistance parameter against external influence. If proposal creation were too cheap, external actors or bad-faith participants could create proposals too easily. If it were too expensive, legitimate participation could be discouraged. The thread also asked where the fee would go, whether it entered the funding pool, and whether any part of it would be returned to the proposer.
Follow-up discussion clarified that wxDai should be understood as equivalent to xDai and DAI at a one-to-one rate, while STAKE was a separate governance token for the xDai network. This helped correct confusion about the actual value of the fee.
March 1, 2021
A later comment connected the Tollgate Fee to Vote Proposal Buffer and Vote Execution Delay. The concern was that if the tollgate fee were low and voting timing parameters were too short, a malicious actor could undermine Rage Quit protections by creating harmful proposals too quickly. But if timing parameters were too long and the tollgate fee remained low, someone might be able to cheaply spam proposals and delay the execution of important governance actions such as the Commons Upgrade.
This reframed the Tollgate Fee as part of a wider attack-resistance system. It was not only a simple spam filter; it interacted with the speed of proposals, execution timing, and the ability of token holders to exit safely.
May 7, 2021
The thread was later updated with questions about whether the fee could be returned once a proposal was confirmed as legitimate. The final definition described the Tollgate Fee as the required cost for submitting any proposal within the Hatch DAO. The funds associated with the cost would go to the non-redeemable pool and could be returned to the proposal creator through a community vote.
The final parameter explanation described the Tollgate Fee as a customizable cost used to prevent spam when an organization wants proposal actions to remain open. Because of its importance for preventing attack vectors, the suggested range was much higher than the early test value. The related parameter was Vote Proposal Buffer.
By the end of the thread, the Tollgate Fee had been framed as a governance security parameter. It shaped who could create proposals, how costly spam would be, how proposal access balanced openness and safety, and how the DAO could protect itself from delay or manipulation attacks.
2020-12-06 to 2021-05-20 — Ragequitting, Ragequit Delay and How They Work
Forum thread: Ragequitting, Ragequit Delay and How They Work Category: TEC / Archive Archive theme: Rage Quit, Ragequit Delay, vote execution delay, exit rights, backer protection, dispute timing
December 6, 2020
A thread was opened to explain Ragequit Delay and how Rage Quit works in the Hatch DAO context. Ragequit Delay was defined as the period of time after a vote passes before that vote can be executed. For example, if a proposal passed with a twenty-four-hour delay, it could not be executed until twenty-four hours later.
The thread explained that yes voters have their tokens locked until the end of the execution delay. This matters because Rage Quit is meant to give people time to exit if they disagree with a decision before it changes the DAO. But people who voted yes on the proposal cannot exit before execution, because their tokens are committed to that pending decision.
The thread distinguished Dandelion Voting from Disputable Voting. In Dandelion Voting, Ragequit Delay gives people time to exit before parameters or funds are changed. In Disputable Voting, there is no equivalent Rage Quit mechanism because, after the Augmented Bonding Curve launches, participants can exit through the curve instead.
The discussion then broadened into the relationship between execution delay and dispute resolution. Smart contracts cannot verify human context on their own, so human judgment is still needed to identify harmful actions, resolve disputes, and decide whether an action should proceed. Execution delay was presented as one possible tool for giving the community time to evaluate and respond before execution.
The thread raised several governance questions: how long is long enough, whether a resolved issue still needs a minimum delay, how block timing affects real-world time, how many voters should be involved in dispute resolution, and whether conflict resolution could accidentally concentrate power in a small group.
May 7 to May 20, 2021
The thread was later updated with user-facing parameter language. Ragequit Delay was described as the required amount of time after a proposal passes before execution. It was important because token holders needed time to evaluate the implications of a proposal and decide whether to maintain their financial position in the DAO or exercise Rage Quit.
The update suggested a short range for the parameter and identified Vote Duration and Vote Proposal Buffer as related parameters. Another addendum explained that several Hatch parameters affected how much backers could recover if they rage quit. Hatch Tribute, Impact Hour Rate, Target Goal, and Minimum Goal all influenced the percentage of a backer’s original contribution that remained redeemable.
By the end of the thread, Ragequit Delay had been framed as an exit-rights and safety parameter. It protected backers by creating time between decision and execution, but it also interacted with proposal timing, token locking, dispute resolution, and the broader economic design of redeemability inside the Hatch.
2020-12-06 to 2021-04-13 — Number of Dandelion Voting Instances
Forum thread: Number of Dandelion Voting Instances Category: Dandelion Voting / Archive Archive theme: Voting architecture, permission grouping, governance complexity, high-impact decisions
December 6, 2020
A Dandelion Voting discussion was opened to decide how many voting instances TEC should use. The thread explained that a voting instance is a subset of Dandelion voting apps with its own parameters, such as required support, quorum, vote duration, and proposal buffer. Different permissions could be linked to different voting instances, meaning that some kinds of votes could require more demanding conditions than others.
The thread framed the decision as a balance between simplicity and flexibility. A single voting instance would make the system easier for participants to understand because all votes would follow the same rules. Multiple voting instances would allow higher-impact decisions to require stronger thresholds, longer durations, or higher quorum. But too many voting instances could confuse participants and make it harder to understand which voting rules applied to which decisions.
The discussion raised several questions for the community: what information should determine the number of voting instances, which permissions should count as low impact or high impact, and how permissions should be grouped. Examples of high-impact decisions included actions affecting the Augmented Bonding Curve, changes to Conviction Voting parameters, adding new apps, or upgrading the DAO to include major governance components.
December 7, 2020
The thread then explored how support requirements, quorum requirements, and voting duration should relate to one another. One view was that high-impact decisions should probably require high support, high quorum, and longer voting periods, while lighter decisions could use lower thresholds and shorter durations. The thread also questioned whether support and quorum should always move together or whether one of them could do most of the work in certain situations.
A deeper concern emerged around who chooses which voting instance applies to a proposal. If the proposer can select the voting instance, they might choose the path most favorable to their desired outcome. The thread therefore raised the possibility of nested governance problems, such as whether the community would need a separate process to decide which voting instance should be used before voting on the underlying decision.
December 9, 2020
The conversation moved toward the idea that TEC would likely need at least two voting instances, but should avoid creating too many. A rough range of two to five instances was suggested as a possible balance between flexibility and understandability. The thread also identified a prerequisite: before the number of instances could be chosen intelligently, the community needed to map the full set of permissions and understand what each permission could change.
December 10, 2020
Further discussion clarified that unusual parameter combinations might still make sense in some cases. For example, high support, high quorum, and short duration could be useful for emergency action, while low support, low quorum, and long duration could be useful for low-stakes planning decisions far in advance. This helped the thread move beyond simple “important equals long and strict” assumptions and toward a more nuanced view of governance parameter design.
April 13, 2021
A later follow-up added a reference from the implementation side, suggesting that the discussion remained connected to the actual configuration work. By the end of the thread, the key conclusion was not a final number of voting instances, but a clearer framing: TEC needed a governance architecture that matched permissions to risk levels while remaining simple enough for participants to understand and trust.
2020-12-06 to 2021-05-07 — Vote Proposal Buffer
Forum thread: Vote Proposal Buffer Category: Dandelion Voting / Archive Archive theme: Dandelion Voting, proposal rate limits, concurrent voting, Rage Quit protection, spam prevention
December 6, 2020
A Dandelion Voting parameter thread was opened to explain the Vote Proposal Buffer. The thread defined it as the amount of time that must pass between the start of subsequent votes. This parameter determined how many votes could occur within a given period and whether votes could run concurrently.
The thread framed the parameter through edge cases. If the buffer were very high, it would greatly limit the number of votes the DAO could process. If the buffer were very low, new votes could be created frequently and multiple votes could overlap, depending on the vote duration. The initial question was therefore how TEC should balance governance throughput against participant attention and safety.
January 11 to February 16, 2021
A later technical follow-up explained how the buffer worked in the vote creation function. The next vote’s start block had to be at least a specified number of blocks after the previous vote’s start block. This made the parameter a rate limiter on when new votes could begin.
The discussion later clarified one of the deeper reasons for the buffer. If a participant voted yes on one proposal, they might be blocked from rage quitting until that proposal executed. If a second, harmful proposal appeared almost immediately after the first, the participant might not have enough time to exit before the second proposal passed. The buffer was therefore partly designed to protect Rage Quit functionality by preventing proposals from being stacked too tightly together.
The thread also clarified that this parameter was specific to Dandelion Voting. Conviction Voting allowed many proposals to exist at the same time, so the same proposal-buffer logic did not apply in the same way.
May 5 to May 7, 2021
The thread was later updated to correct confusion between Vote Proposal Buffer and Rage Quit Delay. Vote Proposal Buffer was described as a proposal rate limiter. If it were set to ten days, then a new vote could only be proposed every ten days, regardless of how quickly any single vote passed or failed. Rage Quit Delay and Vote Duration were the parameters more directly tied to whether participants had enough time to exit before a proposal executed.
A final user-facing definition described the Vote Proposal Buffer as the time that must pass between the start of subsequent votes. It was presented as a way to limit rapid proposal creation, reduce spam, and avoid delaying governance with too many overlapping proposals. A high buffer would reduce the number of votes over time, while a low buffer would allow more votes and possible concurrency. The related parameters were Vote Duration and Tollgate Fee.
By the end of the thread, the Vote Proposal Buffer had been framed as a governance pacing parameter. It controlled proposal throughput, helped prevent spam, shaped whether votes could overlap, and interacted with Rage Quit protections even though it was not the primary Rage Quit delay mechanism.
2020-12-06 to 2021-05-07 — Minimum Quorum Deep Dive
Forum thread: Minimum Quorum Deep Dive Category: Dandelion Voting / Archive Archive theme: Minimum quorum, token-weighted voting, turnout, proposal validity, Dandelion Voting, Disputable Voting
December 6, 2020
A Dandelion Voting parameter deep dive was opened to explain Minimum Quorum. The thread began with the general meaning of quorum as the minimum participation needed for a decision-making process to be valid. In Dandelion Voting, this was defined as the percentage of total token supply that needed to participate in a vote before a proposal could pass.
The thread used an example to show that a proposal could fail even if all participating voters supported it, if not enough total voting power participated to satisfy quorum. This made quorum distinct from support. Support Required measured how much of the participating vote was in favor, while Minimum Quorum measured whether enough voting power had participated to make the vote valid.
The thread also clarified that the exact quorum calculation differed between Dandelion Voting and Disputable Voting. In Disputable Voting, quorum was calculated based on yes votes relative to total token supply, which raised additional questions about whether this design encouraged or discouraged voter turnout.
The discussion also explained why token-weighted voting was being used. Since blockchain systems cannot easily distinguish one person from many addresses, one-address-one-vote would be vulnerable to sybil attacks. Token-weighted voting avoided that problem, but it also meant that a small number of people could pass a vote if they held enough tokens and met the relevant support and quorum thresholds.
The thread asked the community to consider the advantages and disadvantages of high and low quorum, how independent the parameter really was, which other parameters connected to it, and how quorum affected turnout and legitimacy.
May 7, 2021
The thread was later updated with a clearer user-facing definition. Minimum Quorum was described as the percentage of yes votes from the total TECH supply required for a proposal to pass. It was framed as a baseline support requirement that ensured enough token holder participation existed for a proposal to be considered valid.
The update emphasized the downside of setting quorum too high: a proposal might fail even after meeting the Support Required threshold. Because low quorum was seen as carrying limited risk, the suggested range was relatively low. The related parameters were Support Required and Vote Duration, since longer voting periods and different support thresholds could change the practical effect of quorum.
By the end of the thread, Minimum Quorum had been framed as a participation-validity parameter. It protected against proposals passing with too little total support, but if set too high, it could make governance brittle and prevent otherwise supported proposals from executing.
2020-12-07 to 2021-05-07 — Vote Duration Deep Dive
Forum thread: Vote Duration Deep Dive Category: Dandelion Voting / Archive Archive theme: Vote duration, Dandelion Voting timing, participation window, parameter interdependence, proposal execution
December 7, 2020
A Dandelion Voting parameter deep dive was opened to explain Vote Duration. The thread defined Vote Duration as the maximum amount of time it takes for a vote to pass or fail. Most votes would take the full duration, but a proposal could pass or fail sooner if the relevant support and quorum conditions were already mathematically satisfied.
The thread used an example with support, quorum, vote duration, proposal buffer, Rage Quit period, and Tollgate Fee to show how a proposal could be resolved early. If enough no votes were cast to make passage impossible, it could fail before the full duration. If enough yes votes were cast to satisfy the requirements under full quorum assumptions, it could pass before the full duration.
The discussion clarified that Vote Duration is chosen in advance and cannot be changed for a vote already underway. It can be changed later through Dandelion Voting itself, or the DAO can choose to route a permission through a different Dandelion Voting instance with a different configuration. This connected Vote Duration to the broader idea of using multiple voting instances for different levels of decision importance.
The thread also raised practical participation concerns. If the voting period were too short, people might miss important votes because they were offline, traveling, or unavailable for a few days. This made Vote Duration a participation-access parameter as much as a technical timing parameter.
May 7, 2021
The thread was later updated with a clearer definition. Vote Duration was described as the amount of time token holders have to vote on a proposal. It established the maximum period required for a vote to pass or fail, although early resolution remained possible when support and quorum conditions were met.
The suggested minimum was at least three days, based on the desire to give token holders adequate time to participate. The related parameters were Vote Proposal Buffer, Minimum Quorum, Support Required, and Rage Quit Delay.
By the end of the thread, Vote Duration had been framed as a governance timing parameter that balanced speed, participation, proposal finality, and the practical realities of coordinating token holders across time zones and availability constraints.
2020-12-08 — Parameter Assumptions Review
Forum thread: Parameter Assumptions Review Category: TEC / Archive Archive theme: Hatch simulation assumptions, cadCAD modeling, correlation assumptions, what-if matrix, community validation
December 8, 2020
A short review thread was opened to invite the community to examine the correlation assumptions being used in the cadCAD simulator for the Hatch. The post pointed to a what-if matrix and asked whether anyone wanted to initialize surveys, game-based exercises, or other methods to evaluate and expand the assumptions.
The thread highlighted that parameter design was not only a matter of choosing values, but also of questioning the assumptions behind the simulations used to reason about those values. The what-if matrix was presented as a way to structure experiments, define variables and ranges, and evaluate scenarios that could affect the Hatch design.
By the end of the thread, TEC had a small but important reminder that modeling assumptions needed review and social validation. It connected the technical simulation process to broader community sensemaking, encouraging contributors to test whether the assumptions behind Hatch modeling were credible before using them to guide decisions.
2020-12-08 to 2021-05-07 — Membership Ratio Deep Dive
Forum thread: Membership Ratio Deep Dive Category: Dandelion Voting / Archive Archive theme: Membership Ratio, CSTK, Trusted Seed, Hatch contribution caps, value alignment, funding capacity
December 8, 2020
A Membership Ratio deep dive was opened to explain how Trusted Seed membership score would limit Hatch participation. The thread defined the Membership Ratio as the amount of wxDai each CSTK holder could send to the Hatch per CSTK token they held. In practice, this parameter created an individual contribution cap for each Trusted Seed member.
The thread explained that the Membership Ratio also shaped the maximum amount TEC could raise. If the total supply of CSTK was fixed and the Membership Ratio was set at a certain level, then the maximum raise depended on how much CSTK existed and how many members contributed up to their caps. This made the parameter a bridge between membership curation, fundraising capacity, and governance distribution.
The post also explained the relevant assets and infrastructure. wxDai was described as the wrapped ERC-20 version of xDai, used because many dApps and smart contracts were easier to build around ERC-20 tokens. CSTK was described as a non-transferable token representing membership score in the Trusted Seed. It was not meant to have monetary value, but rather to identify members of the Trusted Seed and represent a combination of trust, reputation, and skin in the game.
The thread emphasized why CSTK mattered for Hatch participation. First, Trusted Seed membership provided legal protections through the Commons Stack association structure. Second, because Hatchers would initialize the governance system controlling future token engineering public goods, the community wanted early governance power to be held by people who were more value-driven than profit-driven.
The discussion then explored the relationship between altruism, speculation, and public goods. Hatchers were not expected to be purely altruistic, but they were expected to care more about advancing token engineering than extracting short-term profit. Speculators were not rejected entirely; the thread argued that they could join after the Hatch and help provide market feedback. But the founding phase needed a curated group with stronger value alignment.
The thread also argued that Membership Ratio, Hatch Tribute, and Minimum Hatch Goal should be designed together. The community would need data from projects requesting funding and from Hatchers making soft commitments. These data points could help estimate how much funding TEC needed and how much it could realistically raise.
May 5 to May 7, 2021
The thread was later updated with references to the current CSTK distribution and the activation of Trusted Seed memberships. It noted that on-chain CSTK held by people who had not activated membership would eventually be burned, meaning the actual usable CSTK supply would matter for final Membership Ratio decisions.
A later explanation connected Membership Ratio to Trusted Seed dues. Each Trusted Seed member would have at least a minimum CSTK score, giving them a baseline contribution cap. If someone wanted to contribute more than their score allowed, they would need additional CSTK, which could require paying additional membership dues. The thread framed this as a small tribute to the Trusted Seed and as an additional alignment mechanism for larger contributors.
The final user-facing definition described the Membership Ratio as the parameter that creates an individual cap on how much wxDai each Trusted Seed member can send during the Hatch. It emphasized that the cap depends on each person’s CSTK score and that the parameter directly affects how much funding the Hatch can receive. The suggested range connected this parameter to the Minimum Goal, Maximum Goal, and Target Goal.
By the end of the thread, the Membership Ratio had been framed as more than a contribution formula. It was a governance safety mechanism, a fundraising constraint, a legal and membership filter, and a way to balance openness with the need for value-aligned founding governance.
2020-12-10 to 2021-05-16 — Praise Quantification Update and Proposals
Forum thread: Praise Quantification Update and Proposals Category: Conviction Voting / Archive Archive theme: Cultural proposal, Praise quantification, Impact Hours, contributor rewards, rotating quantifiers, reward fairness
December 10, 2020
A cultural proposal thread was opened to update the Praise quantification process. The background explained that the first rounds of Praise had been quantified by a small set of people, but the community wanted to make quantification a standard practice with a rotating group of quantifiers. The main blocker was that the reward mechanism for quantifiers needed to be adjusted so power could rotate fairly.
The thread explained how the Praise process had evolved. The amount of Praise had grown significantly, making quantification take multiple hours. Earlier tiers had been removed because they took time and were not as useful as expected. The process also began accounting for whether contributors were already paid for the work being praised, reducing Impact Hours for work that had already received direct compensation.
The main proposal was to add more Praise quantifiers. The community had tested additional quantifiers and found the experiment successful. The thread proposed first opening the role to Community Stewards and eventually expanding it more widely. The goal was to share the power of quantification while still maintaining the administrative support needed to manage the spreadsheet and process.
The thread then focused on how to reward Praise quantifiers. The earlier approach gave quantifiers the median Impact Hours for each round, based on the assumption that quantifiers should not score their own Praise. But this created a problem for quantifiers who were not otherwise paid: receiving only the median amount could be too strong a negative incentive for taking on the work.
The proposed solution was to reward each Praise received by a quantifier at the average Impact Hours per Praise for that period, excluding Praise they gave to themselves. The same paid-work adjustments would then apply to quantifiers as to everyone else. This was meant to reward quantifiers based on how much the community praised them, without letting them score their own contributions.
December 23 to December 24, 2020
A follow-up noted that the new method had already been used for recent rounds, but could still be changed if the vote failed. The thread shared example calculations showing how average Praise values translated into Impact Hours after excluding self-praise and applying paid-work adjustments.
A concern was raised that the system could be gamified by rewarding people who accumulated many small Praise instances more than people who completed larger deliverables. The response suggested that selecting quantifiers from people who had already received substantial Impact Hours in previous weeks might reduce this problem, because strong quantifiers likely needed broad perspective across multiple workstreams rather than a narrow single contribution.
May 16, 2021
A later follow-up added the original Impact Hours blog post as a reference. This connected the thread back to the broader explanation of how Praise and Impact Hours supported TEC’s Cultural Build.
By the end of the thread, TEC had documented a key governance problem inside its contribution accounting system: how to reward the people who measure contributions without concentrating power or creating perverse incentives. The thread captured the movement from a small informal quantification process toward a more rotatable, standardized, and incentive-aware system for converting Praise into Impact Hours.
2020-12-10 to 2020-12-29 — Pictosis: NFTs for the Common Good
Forum thread: Pictosis - NFTs for the Common Good Category: Conviction Voting / Archive Archive theme: Funding proposal, NFTs, digital commons, attribution, creator revenue, publishing infrastructure, budget clarification
December 10, 2020
A funding proposal was opened for Pictosis, a project intended to build infrastructure, toolkits, and dApps for collaborative peer-to-peer creation, distribution, and impact-based funding of tokenized digital works. The proposal positioned Pictosis as a response to the economic problems of digital content: digital goods are easy to reproduce, while the labor and time required to produce them remain scarce.
The thread argued that conventional approaches to digital content often create bad tradeoffs. Intellectual property enforcement, DRM, access controls, and legal protections can help creators capture revenue, but they can also reduce reach, increase enforcement costs, introduce friction for users, and limit remixing or downstream production. The proposal described this as a shift from a tragedy of the commons toward a tragedy of the anti-commons, where too much exclusion and fragmentation undermines shared value creation.
Pictosis was presented as an attempt to complete a sustainable loop between creators and consumers. Instead of relying only on scarcity, provenance, or enforcement, the system would create NFTs and eventually “Non-Fungible Systems” that could support attribution, collaboration, configurable policies, interoperability, and automatic revenue flows based on impact metrics. The proposal emphasized that creators needed more than proof of ownership: they needed ways to sustain themselves while allowing digital work to circulate and generate value.
The proposal also framed the project as useful for TEC. With an MVP, TEC members could curate books, signal which works should be published as TEC-aligned content, and define rules for how engagement revenue might flow back to TEC reserves or related contributors. The platform was also presented as a knowledge-management tool for decentralized communities, enabling collaboration-centered publishing, incentivized knowledge production, courses, smart books, applications, and interactive content.
The proposal requested 140,000 in stablecoin funding for a four-month MVP. The budget was divided across MVP development, integration with publishing and distribution channels, customization features for books and bundles, and advanced customization for media such as video, audio, and other text-based content. The first intended publication use case was connected to the Hitchhiker’s Guide to Token Engineering. A slide deck was later shared to support the proposal.
December 24 to December 27, 2020
The discussion turned to the size and clarity of the funding request. The proposal was broadly appreciated, but questions were raised about the scale of the grant and whether comparable projects or benchmarks could help justify the amount. The response clarified that Pictosis was not simply turning intellectual property into NFTs. It was presented as an alternative to conventional IP logic, designed to reduce friction and risk in open distribution and continuous collaboration.
The proposal’s scope was described as broader than provenance or NFT ownership. It aimed to create a protocol and application layer where people could invent new classes of digital goods, microeconomies, distribution methods, publishing houses, games, blogs, communities, websites, and applications. Similar projects in adjacent verticals were referenced as examples of the broader funding environment, with comparable efforts ranging from hundreds of thousands to millions in funding.
The thread then focused on budget transparency. A concern was raised that early funding proposals would set standards for later proposals, so it was important to clarify how money would be used and what calculations supported the budget. In response, the proposal budget was reformatted into a clearer spreadsheet style modeled after another proposal’s budget breakdown. This turned the thread into an early example of proposal feedback improving the quality and accountability of funding requests.
December 29, 2020
The final discussion addressed project uncertainty and buffers. The proposal acknowledged that unforeseen circumstances were likely, especially given the complexity of the work. Some budget items included small overestimates to account for complications, but the thread also emphasized that execution would ultimately depend on the team’s judgment, effort, and ability to adapt when unexpected problems appeared.
The discussion closed by asking for the Conviction Voting proposal link to be added so that participants could move directly from forum discussion to voting. The proposal link was then shared, completing the path from forum proposal to voting interface.
By the end of the thread, Pictosis had been presented as a large, ambitious funding proposal for NFT-based digital commons infrastructure. The thread also became an example of the proposal process in action: a project posted its vision, the community questioned budget scale and clarity, the proposal responded with a more transparent budget, and the forum discussion was connected to the Conviction Voting proposal.
2020-12-13 to 2020-12-17 — Conviction Voting Minimum Threshold
Forum thread: Conviction Voting Minimum Threshold Category: Conviction Vote / Archive Archive theme: Conviction Voting parameters, minimum threshold, minimum conviction, small proposal protection, threshold calculation
December 13, 2020
A deep dive was opened to explain the Minimum Threshold parameter in Conviction Voting. The thread defined the minimum threshold as the minimum percentage of tokens used when calculating the conviction required for any proposal to pass. It compared the concept to quorum in Dandelion voting, while clarifying that Conviction Voting is continuous and token-weighted rather than a single discrete vote.
The thread explained that the threshold needed to pass a proposal depends partly on the amount of funds requested. The minimum threshold creates a floor so that very small funding requests cannot pass with a trivial amount of conviction. Without this floor, someone could potentially request very small amounts many times and pass those requests with very little token support.
A simple example was used to show the effect. If the minimum threshold were set at one percent and 100,000 tokens were actively voting, then even a very small proposal would still require the equivalent of at least 1,000 tokens of conviction to pass. This meant that proposals requesting very small amounts from the funding pool would still need to demonstrate a baseline level of community support.
The thread also pointed to the Conviction Voting smart contract implementation where the threshold calculation was handled. This connected the governance discussion to the underlying code and made clear that the parameter was not merely a social norm, but a value embedded in the mechanism that determines whether proposals can be executed.
The thread then invited discussion about what other factors should be considered when choosing the minimum threshold. This framed the parameter as a design choice about spam resistance, proposal quality, accessibility, and the minimum level of support that any funded action should require.
December 17, 2020
The later discussion connected the minimum threshold to the Max Ratio/Beta parameter and to interactive modeling tools. The tools showed how changing beta and the minimum threshold affected how much conviction was required for proposals of different sizes, and how conviction accumulated over time alongside half life.
By the end of the thread, the minimum threshold had been framed as a protective parameter for Conviction Voting. It prevented tiny proposals from bypassing meaningful governance support, while also shaping how accessible the funding system would be for small requests. The thread helped the community understand that even the smallest funding proposals should still meet a baseline conviction requirement, and that this requirement needed to be tuned alongside beta and half life rather than chosen in isolation.
2020-12-13 to 2020-12-17 — Conviction Voting Max Ratio/Beta Deep Dive
Forum thread: Conviction Voting: Max Ratio/Beta - Deep Dive Category: Conviction Vote / Archive Archive theme: Conviction Voting parameters, max ratio, beta, proposal thresholds, funding pool spending limits
December 13, 2020
A deep dive was opened to explain the Conviction Voting parameter known as Max Ratio, or beta. The thread defined beta as a value between zero and one that determines the maximum percentage of the total funding pool that can be discharged at any given moment. In practical terms, beta set an upper ceiling on how much a proposal could request relative to the commons’ total available funds.
The thread explained that beta affects the threshold a proposal must reach before it can be funded. In Conviction Voting, a proposal becomes fundable only after enough conviction has accumulated behind it. The threshold calculation depends on several variables, including the amount requested, the total size of the funding pool, the effective supply of voting tokens, and the minimum effective supply parameter. Beta shapes how difficult it is for larger funding requests to pass.
The core governance question was whether TEC should choose a large max ratio, allowing proposals to request and potentially receive a larger share of the pool, or a small max ratio, which would constrain individual proposals and preserve funding capacity for many smaller proposals. This framed beta as a treasury pacing and capital allocation parameter, not merely a mathematical constant.
December 14, 2020
The discussion emphasized that Conviction Voting parameters needed to be evaluated together rather than in isolation. A low max ratio would slow spending through Conviction Voting by making large proposals harder to pass, but that effect could be counteracted by other parameters such as a low half life, which would allow conviction to accumulate more quickly. This made it clear that beta’s impact depended on the broader parameter configuration.
The thread therefore pointed toward the need for modeling. Instead of choosing defaults through intuition alone, the community needed to see how beta, half life, minimum threshold, requested funding amounts, and voting supply interacted across different scenarios.
December 17, 2020
Interactive tools were shared to help the community understand how beta and related parameters shape proposal thresholds. One tool showed how much conviction would be required depending on how much funding a proposal requested, while allowing beta and the minimum threshold to be adjusted. Another tool showed conviction accumulating over time while allowing people to explore half life, beta, and minimum threshold together.
By the end of the thread, Max Ratio/Beta had been framed as a parameter that determines how aggressive or conservative TEC’s funding system can be. A higher beta would make it possible to fund larger proposals, but could allow the pool to be depleted more quickly. A lower beta would preserve funds and encourage smaller allocations, but could make major initiatives harder to support. The thread helped translate a technical parameter into a question about spending discipline, proposal size, treasury resilience, and the community’s appetite for funding concentration.
2020-12-13 — How to Get Hatch Tokens
Forum thread: How to get Hatch Tokens Category: Welcome to the TEC / Archive Archive theme: Hatch participation, TEC tokens, Praise, Impact Hours, Trusted Seed, CSTK Score
December 13, 2020
An onboarding thread was published to explain how people could receive TEC Hatch tokens. The post clarified that there were two main paths: contributing wxDai into the upcoming Hatch or contributing work to the core mission of the TEC. This framed the Hatch not only as a funding event, but also as a mechanism for recognizing earlier labor and participation.
The thread explained the work-recognition path through the Praise system. Praise was described as a way for community members to recognize each other’s contributions through bots and communication channels. Those recognitions were collected and later evaluated through a tiered process, with open meetings used to convert Praise into Impact Hours.
The post listed many kinds of work that could earn Praise: participating in weekly calls, supporting working groups, completing surveys, submitting or editing work and proposals, giving feedback, sharing research or community news, contributing to token engineering work, creating videos or art, and even adding value through humor, memes, and community culture. This gave new participants a broad understanding of what counted as contribution before the Hatch.
Impact Hours were described as convertible into TEC Hatch tokens at launch. The thread noted that the community had voted on an intention for each Impact Hour to correspond to a range of value equivalent to contributing wxDai into the Hatch. This connected recognized labor to token distribution and made contributor work part of the pre-Hatch economic design.
The thread also explained the relationship between Hatch participation, the Trusted Seed, and CSTK Score. CSTK Score was described as a non-transferable reputation score connected to participation in the Commons Stack mission. The Trusted Seed was presented as a curated membership group whose activated members could hold CSTK Score onchain and were likely to be eligible for Commons Hatches.
The legal and membership boundary was made clear: the Legal Working Group had recommended that only Trusted Seed members should be able to participate in the Hatch. The thread therefore connected token access to legal structure, membership activation, reputation, and contribution recognition. It also directed readers toward applying for the Trusted Seed and activating membership through the Swiss Membership DApp.
By the end of the thread, the Hatch token process had been explained as a hybrid of financial contribution and recognized work. It helped new participants understand that TEC tokens were not only purchased through the Hatch, but also earned through documented contribution, Praise, Impact Hours, and participation inside the Trusted Seed membership boundary.
2020-12-14 — Commons Swarm Working Group
Forum thread: Commons Swarm Working Group Category: Working Groups / Archive Archive theme: Working group coordination, TEC software implementation, Gardens Swarm, launch readiness, GitHub repositories
December 14, 2020
A working group thread was published to define and coordinate the Commons Swarm, also described as the Gardens Swarm working group. The group’s responsibility was to make sure the TEC software implementation was ready and sturdy for launch through a series of tests. This made the thread a technical coordination reference rather than a discussion-heavy proposal thread.
The post established basic working group logistics: meeting time, meeting location, lead role, discussion channel, and manifesto reference. It also gathered the relevant GitHub repositories into one place so contributors could find the software components involved in the TEC launch.
The repositories were organized into frontend and smart contract work. Frontend repositories included the TEC interface, conversion flow, and Hatch interface. Smart contract repositories included the Hatch oracle, marketplace app, token manager app, Conviction Voting app, and TEC template. This mapped the working group’s scope across the user-facing applications and the underlying contracts required for the Hatch and post-Hatch governance system.
By the end of the thread, the Commons Swarm working group had a public coordination page that clarified where technical implementation work was happening, how contributors could find meetings and discussions, and which codebases were part of the launch stack. The entry captured the technical build side of TEC’s pre-Hatch preparation.
2020-12-14 to 2021-11-12 — Soft Gov Working Group
Forum thread: Soft Gov Working Group Category: Working Groups / Archive Archive theme: Soft Gov, governance practices, social collaboration, contribution rewards, Ostrom principles, sociocracy, working group formation
December 14, 2020
This thread introduced the Soft Gov Working Group as the TEC group responsible for researching and applying best practices for governance, social collaboration, and contribution rewards. Its foundation was explicitly tied to Ostrom’s eight principles for governing commons, positioning Soft Gov as the place where the TEC’s social and governance practices would be shaped alongside its technical mechanisms.
The post shared the group’s weekly meeting time, Discord coordination spaces, manifesto documents, Ostrom principle materials, meeting agendas, Miro work, and GitHub coordination. In this early working group formation period, the thread functioned as a public doorway into Soft Gov’s process: where to meet, where to discuss, where to find working documents, and how the group organized its governance design work.
November 10 to November 12, 2021
Nearly a year later, the thread received a new contribution pointing Soft Gov toward Sociocracy 3.0 as a pattern-based approach to organizational governance. The comment highlighted S3’s principles, such as effectiveness, accountability, empiricism, continuous improvement, consent, transparency, and equivalence, and suggested that its modular patterns might save time when developing governance best practices.
A brief follow-up welcomed the contribution and invited participation in the next meeting. By the end of the thread, Soft Gov had been framed as an evolving governance laboratory: initially grounded in Ostrom-inspired commons governance, but open to adjacent governance frameworks such as sociocracy, agile, and consent-based organizational patterns.
2020-12-14 to 2020-12-17 — Half Life Conviction Voting Deep Dive
Forum thread: Half Life (Conviction Voting) Deep Dive Category: Conviction Vote / Archive Archive theme: Conviction Voting parameters, half life, alpha, voting power accumulation, governance timing
December 14, 2020
A deep dive was opened to explain the half-life parameter in Conviction Voting. The thread defined half life as the number of days it takes for voting power to accumulate by 50 percent or decay by 50 percent. It used simple examples to show how a three-day half life would let conviction accumulate quickly, while a thirty-day half life would make conviction accumulate much more slowly.
The thread explained that half life matters because it determines how quickly preferences gain force in the system and how quickly they fade when support is removed. A higher half life creates slower accumulation and slower reduction. A lower half life creates faster accumulation and faster reduction. This made half life a governance tempo parameter: it shaped how reactive or deliberate the funding system would be.
Conviction Voting was described as using time-weighted preference rather than a one-time vote. The longer tokens support a proposal, the more conviction accumulates behind that proposal, up to a limit. If support moves away, conviction drains over time rather than disappearing instantly. This temporal dynamic was presented as a way to reduce abrupt vote swings without relying on arbitrary lockups.
The thread then introduced the simplified math behind conviction. Conviction at the next time step was described as the prior conviction multiplied by an alpha parameter, plus the current stake. The alpha parameter controlled the decay curve and therefore the effective half life. When alpha is low, conviction follows stake more quickly. When alpha approaches one, conviction changes more slowly and prior support remains influential for longer.
The thread invited discussion around how to choose an appropriate half life. It asked what factors should be considered, what the advantages and disadvantages would be for fast accumulation over days, what would happen if conviction accumulated and decayed over much longer periods, and which other Conviction Voting parameters needed to be considered at the same time. This framed half life not as an isolated setting, but as part of the larger governance design of the funding mechanism.
December 17, 2020
An additional visualization tool was shared to help people understand how different half-life settings change the shape of conviction growth and decay. This reinforced the thread’s educational purpose: the goal was not only to define the parameter, but to make it intuitive enough for the community to discuss and eventually decide on values.
By the end of the thread, half life had been established as a central design variable for TEC’s Conviction Voting system. The discussion translated a mathematical parameter into a governance question: should funding decisions respond quickly to new preferences, or should they require sustained support over time? The thread helped prepare the community to reason about Conviction Voting settings as social and political choices, not only technical configuration values.
2020-12-14 to 2021-06-20 — Govbase: A Database for DAOs and Other Online Communities
Forum thread: Govbase: a database for DAOs and other online communities Category: Conviction Voting / Archive Archive theme: Funding proposal, DAO database, computational constitutions, governance documentation, online communities, interoperability
December 14, 2020
A funding proposal was submitted for Govbase, an open-source and crowdsourced database of projects, tools, and organizations in online governance. The proposal described the existing work as a comprehensive database for DAO and online community infrastructure, intended for developers, researchers, and community operators.
The next phase proposed building a registry of computational constitutions. This would allow different tools, platforms, and DAOs to publish structured governance information in a common format. The proposal argued that such a registry would make it easier to compare governance systems, share best practices, promote interoperability, and create open governance data as a public ecosystem service.
The work plan included expanding the existing project and organization tables, researching different governance representations and publishing practices, adding tables for documents and policies, designing a standard for computational constitutions, creating two reference implementations with community partners, and building the registry as a query over organizations, documents, and policies.
The proposal connected Govbase directly to the token engineering ecosystem. It argued that governance best practices should be easier to share between DAOs, that non-technical contributors should have meaningful ways to participate in community engineering through governance design and documentation, and that DAO communities needed better tools for constitutional moments: periods when they revisit and upgrade their socio-technical architecture.
The requested funding was for a four-month prototype, with a public release and reference constitutions planned later. The funds would support research, engineering, and governance design work.
December 24, 2020
A follow-up response praised the clarity of the proposal and budget, noting that the proposal itself could serve as a good template for other projects seeking funding. This turned the thread into both a funding request and an example of how to present a structured proposal to the TEC community.
June 8 to June 20, 2021
The thread was later revived when a related DAO ecosystem database effort was brought into the discussion. The follow-up explored whether the projects might be complementary, since one effort was mapping DAO organizations and ecosystem data while Govbase had initially focused more on software projects and governance tools. The exchange opened the possibility of collaboration or contribution rather than duplication.
By the end of the thread, Govbase had been presented as a public-good infrastructure proposal for the broader DAO ecosystem. The discussion connected databases, computational constitutions, governance documentation, DAO comparison, non-technical contribution pathways, proposal quality, and later collaboration around DAO ecosystem mapping.
2020-12-14 to 2021-07-06 — Comms Working Group
Forum thread: Comms Working Group Category: Working Groups / Archive Archive theme: Communications working group, public narrative, content platforms, roadmap, contributor onboarding, Hatch communications
December 14, 2020
A working group reference thread was opened to define the role of the Communications Working Group. The thread described Comms as the group responsible for creating the narratives TEC presents to the world, setting up communication platforms, and promoting token engineering projects focused on public goods.
The post provided basic operating information: meeting time, Discord voice channel, working group discussion channel, manifesto, shared agenda, narrative board, GitHub issues, and the main TEC communications platforms. These included Discord, Medium, GitHub, LinkedIn, Twitter, YouTube, and the forum. The thread functioned as a public entry point for people who wanted to understand or join TEC’s communications work.
June 3 to June 20, 2021
The thread was later updated with a new Comms manifesto and roadmap. This reflected that Comms had matured from an initial working group description into a more organized function with a clearer strategic direction. The update also thanked contributors who had supported the working group and framed the coming period as an important time for TEC.
Follow-up discussion showed new contributors expressing interest in joining Comms, requesting access to the roadmap, and engaging with the working group’s content and distribution flow. The roadmap and content flow were described as more organized than expected and useful for filtering lower-quality content away from the group’s stated goals and targets.
June 27 to July 6, 2021
The discussion then shifted into practical Hatch communications. A suggestion was made to post simple social content reminding the broader community that TEC was working behind the scenes and that the Hatch was approaching quickly. The response pointed toward onboarding interested contributors into a Twitter planning spreadsheet.
By the end of the thread, the Comms Working Group had been documented as TEC’s public narrative and media coordination layer. The thread captured the group’s role in platform management, content planning, roadmap development, contributor onboarding, social media coordination, and the communication push surrounding the Hatch.
2020-12-16 to 2021-09-17 — Hatch Outreach Working Group
Forum thread: (Retired WG) Hatch Outreach Working Group Category: Working Groups / Archive Archive theme: Hatch Outreach, working group formation, hatcher engagement, proposal guidance, stakeholder mapping, onboarding research, working group retirement
December 16, 2020
A working group thread was created for Hatch Outreach. The post defined the group’s responsibility as reaching out to prospective Hatch backers and helping guide projects toward submitting proposals for funding. It pointed community members to the dedicated Discord channel, weekly meeting time, voice channel, coordination resources, and a collection of reference materials.
The working group’s reference base included a Hatcher Outreach manifesto, weekly agenda notes, GitHub coordination, TEC Curate materials for tracking Hatchers and potential proposals, onboarding research, stakeholder and ecosystem mapping, crypto-economics documents, interview materials, typeform responses, and an interviews folder. This positioned Hatch Outreach as both a relationship-building group and an operational coordination function for moving interested participants toward the Hatch.
September 17, 2021
A later update marked the working group as retired at the close of the Hatch.
By the end of the thread, Hatch Outreach had been archived as a time-bound working group created for the pre-Hatch period. The discussion connected Hatcher recruitment, project proposal guidance, onboarding research, stakeholder mapping, Discord coordination, weekly meetings, tracking documents, and eventual retirement after the Hatch into one lifecycle record for the group.
2020-12-17 to 2021-01-05 — Multisig Brainstorming
Forum thread: Multisig Brainstorming Category: TEC / Archive Archive theme: Multisig governance, emergency powers, treasury safety, signer rotation, technocracy concerns, Dandelion oversight
December 17, 2020
A brainstorming thread was opened around the role of a multisig in TEC. The discussion began with concerns about what powers a multisig might have, who would choose the signers, and whether emergency control mechanisms could undermine the community’s claims of decentralization. The thread raised a core governance concern: if a small group could recover funds or control key actions, what prevented that group from becoming a technocratic authority over the system?
The initial concern was later corrected to clarify that the multisig itself was not the mechanism capable of minting tokens. That power was associated with the Dandelion Voting app. Even so, the thread remained focused on trust, accountability, signer selection, and the difference between technical safety mechanisms and centralized control.
The discussion then brought in operational experience from another DAO. A multisig was described as a group of keyholders who sign major transactions and handle important value flows. The lesson was that multisigs can be made less risky through clear boundaries, signer rotation, transparent proposals, accountability for transactions, and shared understanding of what each transaction is for. This reframed multisigs as governance infrastructure that requires process design, not just trusted people.
Later in the thread, the intended TEC multisig role was clarified. The multisig had not yet been fully specified, but the initial idea was that a small group of trusted people could act quickly in case of a smart contract bug or attack. The multisig would not be designed to mint or burn tokens or transfer funds freely. Instead, it would have narrow emergency powers such as pausing minting, burning, or transfers for a limited time.
The discussion also emphasized that multisig powers should be subordinate to token holder governance through Dandelion Voting. Token holders could undo multisig actions, abolish multisig powers, or change the members if the group misbehaved. This positioned the multisig as a temporary safety mechanism under democratic oversight rather than an ultimate authority.
The thread also explored whether TEC might need more than one multisig for different functions. For example, one group could pause token operations in an emergency, while another group could cancel proposals that violated community terms. The key point was that any such powers would still be removable or alterable by token holder governance.
January 5, 2021
A later response framed the multisig primarily as a security issue that would belong to the Commons Upgrade. The Commons would ultimately need to vote on whether to include multisigs and what powers they should have.
By the end of the thread, TEC had surfaced a key tension in decentralized governance: emergency response requires some fast-acting authority, but that authority must be narrow, transparent, accountable, and removable. The thread helped distinguish multisig safety powers from unchecked control, and it laid groundwork for thinking about emergency governance in the Commons.
2020-12-18 — Gravity: General Process
Forum thread: “Gravity” - General process Category: Ideas / Archive Archive theme: Gravity, conflict management, alternative dispute resolution, community trust, shared boundaries, graduated sanctions, social governance
December 18, 2020
A thread was opened to describe Gravity as a general conflict-management process for TEC. The post began from the idea that a decentralized community cannot pursue meaningful collective work without shared understandings, clear boundaries, and legitimate processes for addressing conflict. Gravity was proposed as an alternative dispute resolution system tailored to TEC’s social structure.
The thread framed Gravity as a proactive and reactive support layer for the community. Its goals included promoting trust, setting expectations, identifying areas of potential dispute, recognizing explicit boundary violations, supporting communication between individuals and groups, and encouraging participation across the community. It also connected conflict management to resilience, long-term relationships, shared values, and the cultural habits needed for a commons to function.
The proposal also introduced graduated sanctions as part of the system. Rather than treating conflict only as interpersonal friction, the thread described it as something that should be addressed through collective agreements, expected behavior, advice processes, and clear steps that preserve dignity while implementing solutions.
By the end of the thread, Gravity had been framed as TEC’s social governance and conflict-resolution infrastructure. The discussion connected community culture, rules, boundaries, legitimacy, trust, alternative dispute resolution, graduated sanctions, and shared values into a general process for helping the community manage disputes without abandoning its decentralized ethos.
2020-12-18 to 2021-09-06 — Gravity: Role Design
Forum thread: Gravity - Role design Category: Ideas / Archive Archive theme: Gravity, role design, mutual monitoring, alternative dispute resolution, graduated sanctions, confidentiality, rotation, commons governance
December 18, 2020
An Ideas thread was opened to describe the role design for Gravity. The post framed rules, boundaries, and monitoring as essential for managing Common Pool resources and maintaining trust, legitimacy, and collective goodwill. It proposed a mutual-monitoring system in which community members could report issues through a Gravity intake form to a designated group responsible for conflict support and, when necessary, graduated sanctions.
The role design separated individual and collective responsibilities. As individuals, Gravity members would promote dialogue and help manage conflicts through alternative dispute resolution. As a collective, the group would make decisions about implementing graduated sanctions. Both individually and collectively, Gravity members were expected to practice dispute prevention, contextualization, and resolution through regular community practice.
The post laid out ethical expectations for Gravity members: voluntary participation, self-determination by the parties in conflict, attention to conflicts of interest, competence in both mediation and the relevant subject matter, confidentiality, impartiality, neutrality, professional responsibility, and rotation. Rotation was proposed as a way to bring new people into Gravity and prevent accumulation of power, with new training and selection processes three times per year and a limit on consecutive service.
The design also introduced layers of confidentiality. Information inside an ADR process would stay with the parties and mediator, while only limited notes or agreements would be stored for follow-up and accountability. Raw typeform intake would be restricted to a small number of Gravity members, who would convert reports into cases for assignment. Broader Gravity group discussions about cases, sanctions, and review would remain confidential within the group, with the exact voting mechanism still to be decided.
December 24, 2020
Follow-up notes explored how Gravity should make decisions. The thread distinguished between decisions that could be handled by a mediator and decisions that needed broader checks, balances, monitoring, or collective review. It also noted that voting on everything would be too slow for fast responses, so some trust in responsible role-holders would be necessary. Payment and budget-handling questions were also raised, with rotation suggested as a safeguard for sensitive responsibilities.
September 6, 2021
A later response praised the ethical and intellectual rigor of the Gravity design and treated it as an example of TEC’s values in practice.
By the end of the thread, Gravity had been framed as a conflict-resolution and accountability layer for the Commons. The discussion connected mutual monitoring, ADR, graduated sanctions, confidentiality, mediator ethics, role rotation, case intake, democratic review, fast response, checks and balances, accountability records, and power-limiting safeguards into one early design for community governance and conflict management.
2020-12-18 to 2021-05-29 — Gravity Onboarding
Forum thread: Gravity - Onboarding Category: Ideas / Archive Archive theme: Gravity, mediator onboarding, conflict resolution, training process, code of conduct, graduated sanctions, community facilitation
December 18, 2020
An onboarding thread was opened to describe how TEC could train and select conflict managers through the Gravity process. The proposal described an open and inclusive onboarding process that would run periodically to bring interested people into mediator training and selection.
The intended role was broader than reactive conflict resolution. Mediators would also facilitate proactive and reactive participatory activities, support practice groups, help maintain forum posts and Discord channels, and provide feedback on policy and procedures to relevant working groups when needed. This framed Gravity as a social infrastructure layer for community health, not simply a response mechanism for disputes.
The thread outlined expectations for the training process. Participants were expected to help improve the TEC code of conduct, engage with the Gravity working group and manifesto, understand the soft governance context, and learn how rules and sanctions would be applied through the Gravity process. Requirements included attending a minimum number of sessions, agreeing to a mediator code of conduct, and demonstrating familiarity with alternative dispute resolution, nonviolent communication, TEC, and Gravity processes.
The proposed training program would run for four to six weeks, with eight to ten hours of sessions. Topics included theories of conflict, different perspectives, spiral dynamics, nonviolent communication, negotiation, alternative dispute resolution, individual conflict cases, antifragility, Ostrom’s commons principles, mediator confidentiality agreements, the Gravity process, forms, graduated sanctions, and group conflict practice.
The thread invited suggestions for facilitators, missing topics, and corrections. This made the onboarding plan itself participatory, consistent with the idea that conflict-resolution infrastructure should be shaped by the community it serves.
May 15 to May 29, 2021
Later replies expressed appreciation that TEC was actively developing these competencies and showed interest in joining future Gravity training. The discussion suggested that Gravity had become visible not only as an internal governance process, but also as part of what attracted people to TEC from the broader ecosystem.
By the end of the thread, Gravity onboarding had been documented as a structured pathway for developing community mediators. The thread connected conflict theory, nonviolent communication, alternative dispute resolution, Ostrom-inspired commons governance, codes of conduct, confidentiality, graduated sanctions, and practical facilitation into one onboarding process for TEC’s social governance layer.
2020-12-21 to 2022-03-15 — Gravity Working Group
Forum thread: Gravity Working Group Category: Working Groups / Archive Archive theme: Gravity, conflict resolution, nonviolent communication, Gravitons, working group formation, community wellbeing, restorative practice, SEEDS collaboration
December 21, 2020
This working group thread established Gravity as TEC’s conflict-resolution and community wellbeing group. The post described Gravity’s purpose as helping maintain equilibrium in decentralized communities through nonviolent communication, transformational approaches to conflict, and accessible protocols for managing social issues. It framed Gravity as both preventive and responsive: fostering dialogue for smoother coordination, helping resolve non-harmonious situations, and training participants to become conflict-management agents called Gravitons.
The post offered a practical pathway for people seeking help. Anyone involved in a conflict or in a non-harmonious situation, even a small one, was invited to reach out through a Gravity intake form. The thread also listed the meeting rhythm, Discord spaces, working group lead, manifesto, initial conflict-management documents, graduated sanctions map, GitHub coordination, and related discussions on onboarding, role design, and general process.
December 23, 2020 to April 8, 2021
A follow-up provided a booking link for people who wanted dialogue support. Several months later, the thread was updated with a revised Gravity manifesto and a note that the group had entered its second roadmap, which would be reviewed in July. This showed Gravity moving from initial formation into a continuing working group with evolving strategy and documentation.
February 13 to March 15, 2022
More than a year later, the thread was revived around the question of whether the post needed updating, since Gravity had expanded its meeting cadence. The revived discussion emphasized the importance of building communities capable of supporting sensitive and talented people rather than pushing them out through unmanaged conflict. It argued that TEC and DAOs generally needed better ways to recognize, document, and address disputes while protecting the people involved.
One response suggested that TEC should transparently log and address internal disputes, ideally through third-party and anonymized resolution processes. It proposed that each side independently record the essence of the issue so a mediator could understand the upset on both sides and work toward common ground. The Observation, Feelings, Needs, Request process was recommended as a useful framework, and the thread noted that Gravity was already receiving inquiries about this kind of support.
The discussion then expanded into a cross-community training opportunity connected with SEEDS. A participant shared an invitation for twelve people to join training in heart-based communication, empathic organizing, community counseling, transformative facilitation, conflict resolution, and restorative practice. The training was described as a foundation for developing caring-based culture in SEEDS and beyond, with a possible longer path toward certified mediation counseling.
Follow-up replies welcomed the SEEDS connection and connected it back to Gravity’s aspiration to spread nonviolent communication and conflict-resolution capacity beyond TEC. Interest in the training was expressed, and the thread became a bridge between Gravity’s internal conflict-resolution mission and broader ecosystem learning opportunities.
By the end of the thread, Gravity had been documented as both a TEC working group and a wider social technology project. The discussion connected community wellbeing, conflict management, Graviton training, nonviolent communication, transparent but privacy-preserving dispute records, restorative practice, SEEDS collaboration, and the long-term ambition of making decentralized communities better at caring for conflict rather than avoiding it.
2020-12-21 to 2021-10-03 — Legal Working Group
Forum thread: Legal Working Group Category: Working Groups / Archive Archive theme: Legal Working Group, Hatch legal strategy, bonding curve legal design, proposal distribution, legal documentation, Hatch documents
December 21, 2020
This working group thread introduced the Legal Working Group as the team responsible for designing and executing a coherent legal strategy for the TE Commons Hatch, bonding curve mints and burns, and proposal distribution. The post also described a research function: the group would look at legal strategies and relevant smart-contract structures used by similar projects.
The thread positioned legal work as part of the core operational foundation for the Hatch rather than an external compliance afterthought. It listed the group’s meeting cadence, Discord coordination spaces, manifesto, agenda, Hatch phase diagram, steps to become a Hatcher, and a GitHub issue board. The scope also included mapping the necessary documents for Token Engineering activities such as TEbook and TE Academy before the Hatch, so that the broader ecosystem could maintain consistency and coherence.
March 23 to October 3, 2021
A later update shared the TEC roadmap with Legal Working Group updates, showing that the legal work continued as part of the broader Hatch preparation timeline. Months later, the thread was used to locate the legal document produced for the Hatch when the main Hatch site was not loading, and a direct document link was provided.
By the end of the thread, the Legal Working Group had been established as a foundational infrastructure group for the TEC. Its work connected legal strategy, Hatch participant documentation, bonding-curve mechanics, proposal distribution, and the practical documents needed for people to safely understand and participate in the Commons launch.
2020-12-22 to 2021-04-12 — Scaling Decentralized Administrative Functions
Forum thread: Scaling Decentralized Administrative Functions Category: Ideas / Archive Archive theme: Commons administration, working group scaling, decentralization, organizational design, contribution recognition
December 22, 2020
An idea thread was opened to explore how decentralized administrative functions could scale inside TEC and future commons-based organizations. The thread framed administration through two concepts: differentiation and integration. Differentiation meant breaking organizational work into clear functional units, while integration meant coordinating those units into collective, purposeful action.
The thread observed that TEC had already differentiated itself through working groups, but that integration required conscious effort. Coordination tools, shared standards, operational processes, and trusted early members were described as necessary for turning distributed effort into coherent action. The discussion treated administration not as bureaucracy for its own sake, but as the practical system that lets decentralized contributors work together without losing direction.
The post argued that decentralized communities are living communities. Their membership changes, incentives shift, new contributors arrive, and culture can become unstable if operational rules and social norms are not maintained. Drawing on commons governance ideas, the thread suggested that durable commons need both soft governance and hard governance: cohesive working group practices on one side, and technical tools that standardize processes on the other.
A central tension in the thread was the tradeoff between uncertainty and complexity. More rules and tools can reduce uncertainty, but too much complexity can discourage participation. The thread therefore treated good administration as a balancing act: reducing confusion without making participation too difficult.
The thread proposed a possible scaling model for working groups. Working groups could stay small enough to remain cohesive, with members committing more deeply to one group instead of spreading themselves across many groups. When a working group became overloaded, it could divide into subgroups, with experienced members helping transmit knowledge, culture, and procedures to new contributors. This was presented as a way to preserve institutional memory while expanding capacity.
The proposal also imagined rotating subgroups through different functional areas so contributors could develop a broader understanding of the working group’s responsibilities. Contribution recognition tools were discussed as possible ways to measure experience or readiness for new responsibilities, although the thread treated this cautiously and emphasized the need for meaningful contribution signals rather than simplistic scoring.
April 12, 2021
A later reply connected the thread to broader organizational design ideas, including viable systems thinking and chaordic organizations. The response reinforced the importance of cohesion, purpose, direction, and group self-awareness. It also questioned whether existing contribution quantification tools were mature enough to support the deeper coordination needs of decentralized communities.
By the end of the thread, the discussion had opened a broader line of thought about TEC administration: decentralized governance still needs administrative structure, but that structure must preserve adaptability, cohesion, and human judgment. The thread captured an early attempt to think beyond individual tools and toward a scalable system of commons management.
2020-12-23 — TEC Parameters
Forum thread: TEC Parameters Category: Working Groups / Archive Archive theme: Parameter education, working group coordination, Hatch configuration, technical onboarding
December 23, 2020
A working group reference thread was created for TEC Parameters. The thread described the group’s responsibility as educating the community about the technical parameters that needed to be set in order to Hatch the Commons. It also framed the group as a place for helping participants understand the technical side of what TEC was building.
The thread directed community members toward regular Hatch Parameters meetings, the Discord, the shared calendar, weekend work sessions, and forum writing sessions. It encouraged people who wanted to contribute to the parameter process to join calls, read the relevant forum subcategories, and participate in the work of translating complex technical configuration choices into community understanding.
The post also gathered several linked resources, including call materials for Hatch Parameters, Conviction Voting, Impact Hours, Dandelion Voting, a working group manifesto, and the TEC roadmap. This made the thread less of a debate and more of an orientation hub for the parameter workstream.
By the end of the thread, TEC had a simple landing page for the parameter education effort. It marked the parameter process as an organized working group function rather than a scattered set of technical discussions, and it helped connect the many individual parameter deep dives into a coordinated community-learning process.
2020-12-23 to 2020-12-26 — Luna Swarm: Modelling the 1Hive Ecosystem in cadCAD
Forum thread: Luna Swarm - Modelling the 1Hive Ecosystem in cadCAD Category: Conviction Voting / Archive Archive theme: Funding proposal, cadCAD modeling, 1Hive, Gardens Swarm, computer-aided governance, reusable commons infrastructure
December 23, 2020
A funding proposal was opened for Luna Swarm, an initiative to model the 1Hive ecosystem in cadCAD. The proposal described Luna Swarm as a collaboration focused on building rigorous models that could support operational decision-making, future design choices, and governance decisions. The work was positioned as an extension and improvement of existing cadCAD Conviction Voting models, with additional modeling of mechanisms and subsystems specific to 1Hive and the Gardens Swarm smart contract template.
The proposal framed the work as an ongoing initiative, with model iterations to be prioritized by the 1Hive community. The initial request was for one to three months of work, with the possibility of later proposals to continue the modeling effort. The requested funding amount was 15,000 xDAI, to be held in a dedicated DAO and allocated based on contributor hours.
The thread explained the benefit to token engineers through the concept of computer-aided governance. cadCAD was presented as a complex systems design methodology and Python package for designing, testing, and validating systems through simulation, including Monte Carlo methods, A/B testing, and parameter sweeps. The proposal argued that modeling a live ecosystem like 1Hive could help governance communities reason more rigorously about mechanism behavior and improve future design decisions.
December 24 to December 26, 2020
The initial response was supportive, but the discussion soon asked for more clarity on how modeling 1Hive would benefit the broader Token Engineering community and TEC specifically. The key question was whether the work would produce reusable knowledge or whether it would primarily serve 1Hive. There was also interest in whether community members could observe meetings, listen to the modeling process, learn from the methodology, and access recordings.
The response clarified that TEC and 1Hive shared overlapping infrastructure through the Gardens Swarm tools and templates, including mechanisms such as Augmented Bonding Curves and Conviction Voting. Because both ecosystems used similar tooling, modeling 1Hive could produce reusable open source models and insights that would benefit TEC and other future commons built with similar components.
The thread also clarified that the work was open to broader participation. Discussions, weekly calls, public calendars, contributor opportunities, and cadCAD learning pathways were made available to interested participants. This positioned the proposal not only as a modeling contract, but also as a learning opportunity for people who wanted to understand cadCAD and commons modeling more deeply.
A final clarification noted that the initiative had also received funding from the 1Hive community and Gitcoin Grants, with those funds also collected in the Luna DAO for compensating modeling and related work. This made the proposal part of a broader multi-source funding effort rather than an initiative funded only by TEC.
By the end of the thread, the Luna Swarm proposal had been framed as a cross-commons modeling effort. Its value to TEC came from the reuse of models, the shared technical foundation between TEC and 1Hive, the development of computer-aided governance practice, and the opportunity for TEC contributors to observe or join rigorous cadCAD modeling work.
2020-12-27 to 2021-01-20 — Tokenlog: Token-Weighted Backlog
Forum thread: Tokenlog - Token-weighted backlog Category: Conviction Voting / Archive Archive theme: Funding proposal, governance tooling, token-weighted prioritization, open source backlogs, GitHub integration, offchain voting
December 27, 2020
A funding proposal was opened for Tokenlog, a governance tool designed to create token-weighted backlogs for open source software projects. The proposal described Tokenlog as a way for projects to gather continuous feedback from token holders and let supporters signal which backlog items mattered to them, rather than only voting on isolated proposals one at a time.
The thread explained that Tokenlog began as a hackathon project and had already received attention, prizes, and interest from several projects. It was being trialed by a few communities, including Commons Stack. The proposal framed the tool as part of a broader shift toward new development models for open source software, where token holders and communities could participate more directly in prioritizing product and protocol work.
The problem identified was that many governance systems were expensive, slow, or difficult to access because of gas fees, high proposal thresholds, and formal submission requirements. This could reduce participation or push smaller stakeholders to delegate their tokens to a smaller group of concentrated decision makers. Tokenlog was presented as a lighter-weight coordination layer that could help communities collaborate continuously around product direction.
The tool was described as permissionless, free to set up, integrated with GitHub workflows, based on gasless offchain Ethereum signature voting, supportive of one-token-one-vote or quadratic voting, and fully open source. The initial MVP proposal focused on improving the product from a hackathon prototype into a more robust tool over roughly three months.
The planned work included expanding data sourcing beyond GitHub to other community and product management tools, improving data storage by moving away from a centralized database toward more decentralized and verifiable storage, experimenting with additional voting mechanisms both offchain and onchain, and improving the user interface and user experience. The project also planned to continue interviews, trial runs, and research with product and community managers, while dogfooding Tokenlog through its own governance token and contributor rewards.
The proposal requested 5,720 EUR in stablecoin, calculated from a part-time work estimate over thirteen weeks plus a contingency buffer. This made the proposal relatively small compared with some of the larger funding requests in the same period, and it included a clear hourly basis for the budget.
December 29, 2020
The discussion expanded into future roadmap possibilities. The proposal emphasized that future versions would depend on research, interviews, and lessons from earlier trials, but several directions were already under consideration. One was deeper native GitHub integration through GitHub apps or actions so that Tokenlog could stay close to where open source work actually happens.
Another direction was adding richer voting mechanisms. At the time, votes were mostly fixed upvotes on issues, but feedback suggested that users might need to downvote or remove votes. Existing open source governance practices, such as committee-style voting with support, neutrality, or opposition, were also discussed as possible references.
A third direction was adding onchain activity. The proposal treated offchain voting as useful for early idea collection and prioritization, but suggested that more mature items could eventually move into more official onchain votes through integrations with existing governance systems. This could also open the door to bounties, sprints, or money streams connected to backlog items.
January 19 to January 20, 2021
The later discussion showed interest from another community that had a similar need for collaborative prioritization, though not necessarily tied to GitHub issues. This surfaced the possibility that Tokenlog’s value could extend beyond software repositories if it became easier to pull in other data sources. The response connected that need back to the proposed data-sourcing improvements, which were intended to make Tokenlog more adaptable in future versions.
By the end of the thread, Tokenlog had been framed as a lightweight governance and product-management tool for open source communities. The proposal connected token-weighted signaling, backlog prioritization, GitHub workflows, offchain voting, and future onchain integrations into a possible coordination layer between informal community feedback and formal governance decisions.
2020-12-28 — Submit a Proposal for Funding
Forum thread: Submit a Proposal for Funding Category: Welcome to the TEC / Archive Archive theme: Proposal onboarding, funding submissions, advice process, Conviction Voting preparation, public goods funding
December 28, 2020
An onboarding thread was published announcing that TEC was accepting funding proposal submissions from token engineering and related open source projects focused on token engineering public goods. The post explained that project leaders could submit proposals to the forum, receive feedback from the TEC community, and later, after the Commons was hatched, submit revised proposals for a Conviction Voting decision by token holders.
The thread laid out the basic proposal submission process. Proposal authors were directed to the proposals category, asked to create a new topic using the proposal template, and encouraged to share the forum link in the community Discord so people could find and discuss it. This connected forum publication with live community engagement and made proposal submission a visible, social process rather than a private application.
The forum submission was framed as entering the Advice Process. This meant the purpose of the forum post was not only to present a funding request, but to collect feedback, create transparency, and allow the community to ask questions before the proposal moved toward a final funding decision. The thread positioned the Advice Process as a preparation stage before formal Conviction Voting.
The post also explained that after the Commons Upgrade, proposal authors would be able to revise their proposals and submit final versions for Conviction Voting. This made the forum a staging ground for proposals before the onchain funding mechanism became fully active. It also directed readers to a demo of the test app so they could understand how Conviction Voting would work once proposals reached that stage.
The thread listed several proposals that had already been submitted, showing that the process was beginning to produce an early pipeline of possible public goods projects. It also offered proposal authors the opportunity to give a short project pitch during the weekly community call, connecting written proposals with synchronous community presentation and discussion.
By the end of the thread, TEC had created a clear public pathway for funding proposals: submit in the forum, enter the Advice Process, collect feedback, revise after the Commons upgrade, and then move into Conviction Voting. This thread helped translate TEC’s funding mission into an operational process for project leaders and gave the community a repeatable structure for moving from idea to proposal to potential funding decision.
2020-12-29 to 2021-05-07 — Hatch Minting Rate
Forum thread: Hatch Minting Rate Category: The Hatch / Archive Archive theme: TECH minting, exchange rate, token supply, token psychology, Hatch parameter design
December 29, 2020
A Hatch parameter thread was opened to explain the Hatch Minting Rate. The thread defined it as the number of TEC Hatch tokens sent to Hatchers for each DAI or wxDai contributed during the Hatch. The post used the test Hatch as an example, where a specific exchange rate meant that one wxDai created a large number of test Hatch tokens.
The thread noted that this parameter was relatively less important to the underlying economics than many other Hatch parameters. Its main effect was psychological. It shaped how many tokens participants saw in their wallets, how people perceived the price of the token, and how the eventual token supply felt to the community.
January 8 to January 9, 2021
Follow-up discussion clarified the technical meaning of the exchange rate. The rate referred to the relationship between organization tokens and contribution tokens, expressed in parts per million. Because the relevant tokens used the same decimal precision, the calculation was straightforward in the TEC case. The discussion also noted that if tokens had different decimals, the formula would need to account for that difference.
This exchange made the thread useful as both a conceptual explanation and an implementation note. It connected the user-facing idea of “tokens per wxDai” to the smart contract representation of the exchange rate.
May 7, 2021
The thread was later updated with a clearer user-facing definition. The Hatch Minting Rate was described as the amount of TECH minted for each wxDai raised during the Hatch Period. It established the TECH token supply and could be evaluated against the minimum, target, and maximum raise parameters.
The update emphasized the psychological effect of token supply. A low minting rate would create fewer tokens and therefore a higher apparent token price. A high minting rate would create more tokens and therefore a lower apparent token price. The suggested range was broad, reflecting that this was largely a preference parameter rather than a core economic safety parameter.
By the end of the thread, the Hatch Minting Rate had been documented as a parameter that mostly shaped token denomination and participant perception. It mattered less for economic fundamentals than for token supply, token price framing, and how accessible or meaningful token amounts felt to participants.
2020-12-30 — TEC Funding Proposals: What Kinds of Projects Should Apply?
Forum thread: TEC Funding Proposals: What kinds of projects should apply? Category: Community Updates Archive theme: Funding scope, proposal eligibility, token engineering public goods, open source tools, research, education, narratives, outreach
December 30, 2020
A community update was published to clarify what kinds of projects should apply for TEC funding. The thread explained that TEC had opened funding proposal submissions for token engineering and related open source projects focused on token engineering public goods. It framed the forum proposal process as the first step: projects would gather community feedback, then later submit proposals to the Commons for a funding vote.
The thread grounded proposal eligibility in TEC’s mission: gathering and stewarding funds for projects in the emerging field of token engineering in order to encourage robust and ethical design of tokenized infrastructures. It acknowledged that although the mission was clear, there were many possible paths for allocating resources, and the community would ultimately decide which projects were highest leverage through proposals and voting.
Three major funding areas were identified. The first was open source tools and research, including cadCAD development, core technology, models and analysis, DAO and commons modules, governance tools and models, market mechanism iterations, bonding curve innovation, cryptoeconomic building blocks for Web3, legal research, and academic papers. The second was education, including standards, articles, courses, books, and organizing the token engineering knowledge base. The third was token engineering narratives and publicity, including conferences, events, presentations, ambassadors, academic influencers, media, public relations, and advisory work for open source or unpaid nonprofit projects.
The thread also summarized community input about what TEC should and should not fund. There was support for funding work that created broad public value, addressed fundamental needs, advanced general-purpose technology, developed fundamental research, produced creative open source cryptoeconomic mechanisms, built models and simulations, supported education, and created applications for resource management.
The thread also drew boundaries around what might not be aligned. Concerns were raised about funding efforts without feedback mechanisms, projects too broad to be specifically tied to token engineering challenges, and work primarily oriented around economic profit. This clarified that TEC funding was not meant to be a general startup financing pool. It was meant to support token engineering public goods and projects with clear alignment to the Commons’ mission.
The post concluded by inviting the community to discuss what was missing from the list, what additional work should be funded, and what kinds of projects should fall outside TEC’s mission. This made the thread both guidance and an open boundary-setting conversation.
By the end of the thread, TEC had a clearer funding scope for early proposal authors. The community had identified a preliminary map of eligible work across tools, research, education, standards, narratives, and outreach, while also signaling caution around profit-seeking projects, overly broad startup requests, and initiatives disconnected from token engineering public goods.
2020-12-30 — Glossary of Terms
Forum thread: Glossary of Terms Category: Welcome to the TEC / Archive Archive theme: Onboarding, shared vocabulary, governance terminology, Hatch terminology, Conviction Voting, commons infrastructure
December 30, 2020
A glossary thread was published to create a shared vocabulary for people entering the TEC ecosystem. The thread gathered important terms across token engineering, commons governance, Hatch design, Conviction Voting, DAO infrastructure, and web3 tooling. Its purpose was not to debate a specific proposal, but to reduce confusion and make the community’s technical and governance discussions more accessible.
The glossary defined core mechanism terms such as Augmented Bonding Curve, bonding curve, Conviction Voting, Dandelion Voting, Exit Tribute, Hatch parameters, Half Life, Max Ratio, Minimum Threshold, Minimum Quorum, Support Required, Vote Duration, Vote Proposal Buffer, and Vote Execution Delay. These definitions helped connect the forum’s many parameter deep dives into a single reference point that participants could use while following the Hatch and governance configuration process.
The thread also defined broader concepts needed to understand TEC’s mission and culture, including commons, public goods, tragedy of the commons, Ostrom’s principles, Praise, Impact Hours, Trusted Seed, CSTK Token, CSTK Ratio, Cultural Build, and the Token Engineering Commons itself. This made the glossary a bridge between the social side of the commons and the technical side of the mechanism design.
The glossary also introduced technical and ecosystem vocabulary such as cadCAD, computer-aided governance, DAO, DeFi, MetaMask, smart contracts, staking, WalletConnect, Web3, xDai Chain, Rinkeby, Ethereum, SourceCred, Sybil attacks, and token curated registries. These terms were important because TEC participants needed to navigate not only TEC-specific processes, but also the broader infrastructure stack around wallets, chains, modeling tools, and decentralized applications.
Many definitions linked outward to deeper explanations, related forum threads, articles, documentation, or prior deep dives. In that sense, the glossary acted as an index for the early TEC knowledge base. It connected newcomers to more detailed materials while giving them enough context to participate in conversations without needing to already know the entire vocabulary of DAOs, commons, and token engineering.
By the end of the thread, TEC had a public reference document for its operating language. The glossary helped standardize terms across governance, culture, funding, and technical design, making it easier for participants to understand proposals, parameter discussions, Hatch documentation, and onboarding materials.
2020-12-30 to 2022-04-12 — TEC Legal Strategy Proposal and Vote
Forum thread: TEC Legal Strategy Proposal & Vote Category: Conviction Voting / Archive Archive theme: legal strategy, Swiss Association, Trusted Seed, HatchDAO, member liability, non-transferable tokens, sufficient decentralization, legal protection
December 30, 2020
This Conviction Voting thread presented the Legal Working Group’s proposed launch strategy for TEC after several months of research with DAO legal experts. The core recommendation was an intentionally middle-way structure: TEC itself would launch without its own formal legal entity, preserving flexibility for the bonding curve and future evolution, while founding Hatch participants would join the Trusted Seed and become members of the Commons Stack Swiss Association.
The post explained the tradeoff clearly. Avoiding a dedicated TEC legal entity would reduce requirements on members and preserve the Commons’ ability to change structure as it evolved. The downside was that, without a legal distinction between the DAO and its participants, members could potentially be treated as general partners and exposed to liability. The proposed mitigation was for Hatch participants to become members of the Swiss Association, which could provide support for members acting in good faith if legal issues arose.
The strategy was paired with other risk-reduction measures: launching in two stages as part of a “sufficiently decentralized” approach, beginning with a non-transferable token, and using terms of service before interactions with TEC. The post then asked the community to vote on whether it supported the legal strategy recommended for TEC’s launch.
December 31, 2020 to January 7, 2021
Follow-up discussion clarified the scope and limits of the Swiss Association approach. Questions focused on whether association membership protected members from TEC-related liabilities, whether membership dues were required, whether membership tokens created voting power inside the association, and whether there was a legal distinction between the earlier DAO structure and the HatchDAO.
The response clarified that the Commons Stack Association was not deploying TEC and would not hold TEC tokens. It could support software and community-building work before deployment, but the actual TEC would be controlled by its participants. Membership dues were described as a practical funding mechanism for the association, not as the thing that legally made the association exist. The discussion also distinguished between several non-transferable tokens: a reputation-like Trusted Seed token, the Hatch DAO token used before the Commons Upgrade, and the later TEC token after migration to the full Commons.
The thread emphasized that the legal structure did not eliminate all participant liability. Rather, it created a support mechanism: TEC participants would still own and control their tokens, but by joining the association they would have an aligned organization willing to help if good-faith participation created legal issues.
April 12, 2022
Much later, the thread received a follow-up critique of the chosen legal strategy. The comment argued that using a nonprofit association could reduce fluidity, scalability, and openness by introducing membership screening and permissioning through the Trusted Seed. It suggested an alternative custodian or trust-like model that could absorb liability while allowing governance and participation to remain more open and flexible.
By the end of the thread, TEC’s early legal strategy had been recorded as a pragmatic compromise between decentralization, launch flexibility, capture resistance, and legal protection. The community chose not to wrap TEC itself in a dedicated legal entity, but instead to combine Trusted Seed membership, the Commons Stack Swiss Association, staged launch design, non-transferable tokens, and terms of service as a risk-management approach for the Hatch and early Commons.
2020-12-31 — What Is the TEC?
Forum thread: What is the TEC? Category: Welcome to the TEC / Archive Archive theme: TEC identity, onboarding, vision, mission, values, token engineering, commons
December 31, 2020
An onboarding thread was published to define the Token Engineering Commons for newcomers and establish the project’s basic identity. The thread described TEC as an open source, collectively governed project designed to create a token economy that would accelerate the responsible and ethical creation of public goods within the token engineering community.
The thread explained token engineering as an emerging discipline focused on holistic systems design, the theory and practice of designing tokenized ecosystems, and the use of tools such as cadCAD to simulate and verify cryptoeconomic systems. It also framed token engineering as a discipline of responsibility, tied to ethical conduct, and as a community pushing the field forward in both theory and practice.
The thread also defined the “commons” side of TEC. A commons was described as a resource created and managed by a group for both individual and collective benefit, held collectively rather than privately. This connected TEC’s identity to broader commons theory and positioned the project as more than a token or funding mechanism.
The vision was stated as enabling the creation of ethical, safe, resilient, and diverse economic systems that benefit societies around the world. The mission was to become a Schelling Point for the token engineering community. TEC’s economic layer would fund projects that discover, develop, and proliferate best practices for engineering safe tokenized economies, while aligning collective success with the individual benefit of token holders.
The thread emphasized that TEC’s social layer was even more important than the economic layer. The social layer was described as the force that would unite the token engineering field around ethical principles, standards, tools, and methodologies as the field developed. This clarified that TEC was not only trying to fund token engineering work, but also to help form the culture and shared standards of the discipline.
The values section emphasized a prosocial, human-centered perspective, the advancement of token engineering over short-term profits, integrity, curiosity, constructive inquiry, presence, gratitude, mutual respect, radical open source practice, non-hierarchy, transparency, and accountability. The thread also pointed readers toward the Code of Conduct as part of the cultural foundation.
By the end of the thread, TEC had a concise public-facing identity statement. It explained what token engineering meant, what a commons meant, why TEC existed, how its economic and social layers related to one another, and what values were meant to guide participation. This thread served as a foundational onboarding reference for people trying to understand the purpose and ethos of TEC.
2021-01-04 to 2022-11-01 — Retired Working Group: Transparency Working Group
Forum thread: 🕵️♀️ (Retired WG) Transparency Working group Category: Working Groups / Archive Archive theme: Transparency Working Group, openness, mutual monitoring, transparency audits, meeting coordination, working group retirement
January 4, 2021
A working group thread was opened to introduce the Transparency Working Group and explain its role within TEC. The group’s purpose was to promote transparency, openness, and mutual monitoring as high-level ideals for the Commons. Rather than treating transparency as only a principle, the thread framed it as something that required shared practices, accessible information, and community members who could help make organizational activity visible to everyone.
The thread identified transparency audits as a key method for moving toward that ideal. The goal was to empower people to participate in the transparency process and to make relevant information easier for the community to access. The post also provided practical participation details, including a recurring meeting schedule, the Discord voice channel where meetings would happen, the working group discussion channel, and links to the group’s manifesto and agenda.
A follow-up announced a session to help participants set up OBS and improve audio quality by reducing background noise. This connected the working group’s mission to practical media and documentation skills. Transparency was not only about publishing information after the fact; it also depended on contributors being able to record, stream, document, and share community activity more effectively.
January 5, 2021
The thread added a calendar link for the OBS session, turning the announcement into an actionable onboarding opportunity. This continued the thread’s role as a coordination point for people who wanted to contribute to transparency work.
March 11, 2021
The working group’s manifesto and roadmap were updated. This indicated that the group’s scope and plans were still being refined after its initial formation, and that the thread was being used as a reference point for its evolving direction.
November 1, 2022
The thread was later updated to mark the working group as retired. This changed the status of the post from an active working group invitation into an archival record of a former TEC working group.
By the end of the thread, the Transparency Working Group had been documented as an early attempt to operationalize openness inside TEC. The group focused on mutual monitoring, transparency audits, shared documentation practices, and practical media tooling. Its later retirement marked the end of the working group as an active structure, but the thread preserved the role it played in TEC’s early organizational development.
2021-01-05 to 2021-01-11 — TEC Labs Production Team Funding
Forum thread: TEC Labs! Production Team Funding Category: Conviction Voting / Archive Archive theme: TEC Labs, contributor education, Hatch preparation, token engineering practice, funding proposal
January 5, 2021
A proposal was opened to fund the TEC Lab as a practical learning and production space for the Token Engineering Commons. The thread began by framing token engineering as a field that required not only theoretical study, but repeated practice with real tools, workflows, models, and collaborative methods. The intended purpose of the lab was to create a recurring space where community members could learn token engineering by doing it together, while also producing useful educational material, technical artifacts, and support for TEC’s own infrastructure.
The initial proposal described the lab as an accessible but technically meaningful environment for people at different skill levels. It positioned the lab as a bridge between education and contribution: participants would learn by working with tools such as Python, Jupyter notebooks, git, cadCAD, parameter modeling, and other token engineering methods. The lab was also described as a way to support the upcoming Hatch process by helping participants understand and model Hatch parameters before making governance decisions.
The proposal explained that the lab had already begun in an alpha phase, with early sessions focused on setting up development environments and helping participants overcome the basic technical hurdles that often prevent people from entering token engineering work. It then described a plan for several months of recurring labs in 2021, with a possible schedule of 16 to 24 sessions. The expected archive of the lab would include Notion pages, data sheets, GitHub repositories, video recordings, notebooks, and other materials that could serve future token engineers.
The proposed funding range was introduced as 15,000 to 30,000 DAI. The funds were intended primarily for hosts, organizers, teaching assistants, and people contributing creative or educational work to the lab. The proposal was left open for continued development, with the expectation that the thread would evolve through community discussion around the team, funding structure, and use of funds.
The first responses were supportive and began expanding the possible content of the lab. The discussion quickly moved from a single technical training proposal into a broader educational programming idea. Suggestions included game-based simulations, moral philosophy for token engineers, motivation psychology, community engagement methods, and other sessions that could make the lab more interdisciplinary.
January 6, 2021
The thread shifted from the basic idea of the lab into the question of how to coordinate a recurring program. A set of 16 lab events had been created in a shared planning space, but there was not yet a clear process for filling the schedule, selecting topics, or deciding who would host sessions. This raised the question of whether the lab needed some kind of lightweight governance or coordination role to manage scheduling.
The discussion explored whether a steward, champion, committee, or rotating role would make sense for coordinating the lab. The broader issue was how to avoid over-formalizing the work while still making sure the program could operate reliably. The conversation recognized that the lab would need someone or some process to invite hosts, maintain the schedule, and decide which sessions were in scope.
Later that day, the conversation incorporated earlier suggestions into a more concrete queue of possible lab topics. The lab began to take shape as a flexible program where contributors could propose sessions, enter a topic queue, and coordinate around available dates. The focus remained on building practical learning capacity while allowing the community to shape the curriculum over time.
January 7, 2021
The discussion continued to expand the range of possible lab topics. Motivation psychology and community engagement were suggested as additional content areas that could help token engineers understand not only technical systems, but also participation, incentives, user behavior, and community dynamics.
There was also interest in supporting promotion, community engagement, presenter outreach, and contributor recruitment for the lab. This showed that the lab was not only a technical training initiative. It was also becoming a community programming effort that would need communications, coordination, and facilitation work in order to succeed.
January 8, 2021
The lab planning process became more concrete. Suggested contributors and potential topics were added to the emerging queue. The conversation reinforced that promotion, outreach, and community engagement were important operational functions for the lab, not secondary tasks.
At this point, the thread had moved from a funding proposal into a living coordination space. It was being used to gather possible presenters, identify useful session themes, and clarify the kinds of labor required to run the lab. The educational program was increasingly understood as a combination of technical learning, community facilitation, scheduling, contributor support, and archive creation.
January 11, 2021
The thread turned toward governance design for the lab itself. The conversation connected the lab’s coordination problem to common pool resource theory, especially the distinction between those who provide resources to a commons and those who access or use those resources. This helped frame the TEC Lab as a shared resource that would need operational rules, mutual monitoring, and scope-setting in order to remain useful and sustainable.
A possible coordination model emerged: instead of relying on a fixed committee, the lab could use a rotating responsibility for inviting hosts and shaping the schedule. This would allow the work of curation and coordination to move between people while preserving shared agreement over what belonged within the lab’s scope. The idea was compared to existing TEC community practices where potential presenters were proposed, discussed, and informally approved through group alignment.
By the end of the thread, the TEC Lab had been framed as a funded educational and production initiative, a practical Hatch support mechanism, a community knowledge archive, and an experiment in lightweight commons governance. The thread captured the early formation of a recurring program that aimed to help people become practicing token engineers while also producing artifacts, models, recordings, and coordination processes that could support the TEC over time.
2021-01-08 — Upgrade Impact Hours App
Forum thread: Upgrade Impact Hours App Category: Conviction Voting / Archive Archive theme: Impact Hours, demo Hatch, contract upgrade, Dandelion voting, governance execution
January 8, 2021
A thread was opened after a successful demo Hatch revealed a problem with the Impact Hours conversion process. The issue required a contract upgrade to fix the Impact Hours app, which meant the community needed to vote through Dandelion governance in order to approve and apply the update.
The thread linked the code fix and the corresponding Dandelion vote that would upgrade the app. The fix itself was small, but the thread was important because it showed the governance process being used to correct a live problem in the Hatch tooling. The community was not just discussing governance in theory; it was using its governance stack to execute a technical upgrade.
The post also explained the parameters of the vote. Creating the vote required a tollgate fee, the proposal needed a minimum quorum of token holder support, it required a defined percentage of votes in favor, and the vote would remain open for a set duration. A note clarified that the Aragon frontend could display misleading timing because xDai block times were shorter than expected.
The discussion that followed confirmed that participants were voting with test tokens. The thread therefore captured a practical governance rehearsal: a bug emerged in the demo Hatch flow, a code fix was prepared, an upgrade vote was created, and the community was asked to participate in approving the correction.
By the end of the thread, the Impact Hours app upgrade had become an example of hard governance in practice. It demonstrated how TEC’s tooling, test tokens, Dandelion voting, quorum, support thresholds, tollgate fees, and contract upgrade process worked together when the community needed to fix an operational issue.
2021-01-12 to 2021-08-10 — First Graviton Training
Forum thread: First Graviton training Category: Working Groups / Archive Archive theme: Gravity, Graviton training, nonviolent communication, conflict transformation, ADR, Ostrom principles, graduated sanctions, mediator practice
January 12, 2021
A working group thread was opened to announce the first Graviton training program. The training was scheduled to run from January 21 to March 11 across eight weekly sessions, totaling roughly twelve hours. Its purpose was to help people in TEC understand the cultural principles the community wanted to reproduce, and to build capacity around nonviolent communication, conflict understanding, and conflict-management techniques at individual, internal, and collective levels.
The thread defined Gravitons as community members who would help mediate the social force of the commons. They were expected to be present and accessible, improve relationships, separate people from problems, support empathy between conflicting parties, remain calm and diplomatic in difficult situations, propose alternatives for handling paradoxes, and act according to shared regulations such as terms, codes of conduct, and graduated sanctions.
The study plan was structured around preparation, attendance, questions, and follow-up resources. The sessions covered trust creation, nonviolent communication, spiral dynamics, theories of conflict, antifragility, conflict transformation, BATNA, negotiation, mediation, alternative dispute resolution, practical individual conflict cases, soft governance, culture, Ostrom’s commons principles, TEC’s Code of Conduct, Gravity role design, the Gravity process, onboarding, forms, graduated sanctions, and group conflict practice.
March 19, 2021
After the training period concluded, the thread recorded the first generation of Gravitons. This marked the transition from designing Gravity as a concept to having a trained cohort capable of supporting the community’s conflict-management and social governance processes.
August 6 to August 10, 2021
The thread later announced that a second Graviton training was being prepared for the fall. Follow-up discussion clarified that the training would be open to everyone, free to attend, and accessible through registration and participation in the TEC Discord server.
By the end of the thread, TEC had documented Gravity as a recurring education pathway rather than a one-time working group concept. The discussion connected mediator training, nonviolent communication, conflict transformation, commons governance, graduated sanctions, community culture, training cohorts, and open participation into an institutional practice for maintaining social trust inside the TEC.
2021-01-18 to 2021-01-20 — Transparency Audit Proposal
Forum thread: Transparency Audit Proposal Category: Advice Process / Archive Archive theme: Transparency, working group accountability, mutual monitoring, audits, documentation practices
January 18, 2021
A proposal was opened to gather feedback on creating a transparency audit process for TEC working groups. The thread began from the premise that TEC was a value-driven community and that transparency was central to practicing integrity. Existing transparency work already included documenting calls and making project updates publicly available through videos, but the proposal argued that the community could go further.
The goal of the audit was not to impose mandatory transparency across working groups, but to provide guidance on how groups could be transparent in their actions and decisions. Participation would be strongly encouraged rather than required. The audit was framed as a tool for mutual monitoring, accountability, and community engagement.
The desired outcome was a report measuring the transparency level of each participating working group against a set of criteria. The report would help identify areas where transparency could improve, and the transparency group would provide recommendations for raising the group’s transparency score.
The proposed process began with creating an audit checklist or criteria set, reviewed by subject experts and working group representatives. The plan was to perform trial audits with a few selected working groups before rolling the process out more broadly. Audits would use questionnaires or forms so participants could complete them asynchronously. After reviewing responses, the transparency group would provide feedback and determine a future audit schedule based on what was learned from the trials.
The timeline proposed a trial audit before the Hatch and an official audit after the Hatch. This positioned the process as part of TEC’s pre-launch cultural build, with a fuller transparency practice to follow once the Commons was live.
January 20, 2021
The follow-up discussion supported the idea as an example of mutual monitoring, but suggested that the audit criteria should be added to the thread before it moved to voting. This would allow the community to understand exactly what would be implemented and give more informed feedback before approving the process.
By the end of the thread, the transparency audit proposal had established an accountability practice for working groups. It connected TEC’s values to concrete documentation, review, scoring, and feedback processes, while also showing the Advice Process at work: a proposal was shared early, feedback was requested, and the community asked for clearer criteria before formal approval.
2021-01-19 to 2021-10-10 — Habitat: Your Home on Layer 2
Forum thread: Habitat - Your Home on Layer 2 Category: Conviction Voting / Archive Archive theme: Habitat, Layer 2, optimistic rollups, DAO infrastructure, community platforms, governance tools, funding proposal, liquidity provision
January 19, 2021
This funding proposal introduced Habitat as a community-owned, all-in-one organization platform built on a rollup. The project was presented as an environment where communities could live, grow, and coordinate together, using decentralized infrastructure to support self-management, fair participation, and new forms of community engagement.
The technical foundation was NutBerry, a permissionless optimistic rollup framework that was described as EVM-compatible and able to migrate existing smart contracts from Ethereum mainnet. Habitat’s core idea was that each community could have its own independent domain while sharing a common Layer 2 infrastructure where transactions and votes were aggregated. The benefits listed included much lower gas costs, better user experience without custom RPC setup, easier onboarding from existing governance tokens, instant votes and transactions, and support for proposals with on-chain execution and verification.
The proposal also described Habitat as gradually decentralizing into a DAO governed by its own token. A priority-signaling tool would allow users to stake on desired features, parameters, or protocol actions, and all open-source feature development would be shared across communities. For the TEC, the proposed value included lower-cost DAO hatching, shared Ethereum infrastructure, token-voted upgrades, reusable community features such as discussion forums and fund management, and a place to experiment with DAO structures and token economics.
The funding ask was 40,000 DAI for roadmap and scope-of-work hours, with funds potentially sent to a multisig or Droplet contract. The proposal also floated the idea of TEC becoming a liquidity provider for the Habitat token launch, supporting the project’s long-term development while potentially benefiting from swaps and fees.
January 21 to October 10, 2021
A follow-up shared a presentation for people who wanted a more visual explanation of the project. Much later, another comment returned to the thread and asked what had happened to Habitat, noting that many of the original project links and GitHub resources no longer worked.
By the end of the thread, Habitat had been archived as an early example of the TEC’s interest in Layer 2 governance infrastructure. The proposal connected rollup scalability, DAO tooling, community ownership, tokenized infrastructure governance, and TEC’s need for low-cost experimentation, even though the later state of the project appeared uncertain from the thread itself.
2021-01-21 to 2021-05-26 — TEC TEST Hatch Implementation Specification
Forum thread: TEC TEST Hatch Implementation Specification Category: Dandelion Voting / Archive Archive theme: Test Hatch DAO, Dandelion permissions, TECH token, redemption, Impact Hours, Hatch Oracle, deployment specification
January 21, 2021
A technical implementation specification was published for the TEC TEST Hatch DAO. The thread clarified that the document covered only the initial Hatch DAO deployment, not the later Commons Upgrade into the Augmented Bonding Curve and Conviction Voting system. The test deployment used real money, but it was explicitly framed as a test with no expectation that the DAO itself would become the final TEC.
The specification described the Hatch DAO as having two main phases. First, the Hatch would collect funds and mint TECH tokens. After the Hatch, the DAO would be live and TECH holders would be able to vote on how to use the collected funds to execute the mission.
The governance structure centered on TESTTECH holders. These token holders would collectively and individually control the funds sent to the Hatch. Through Dandelion Voting, they could control the redeemable and non-redeemable agent applications, upgrade the underlying smart contract system, and redeem their tokens for a proportional share of the redeemable pool as long as they had not voted yes on an unexecuted proposal.
The thread then documented the application configuration in detail. It specified the TESTTECH token, the Hooked Token Manager, transfer restrictions, and the Dandelion Voting app. Dandelion Voting was described as the “god-mode” governance application because it controlled almost everything in the DAO. Its parameters included support required, minimum quorum, vote duration, proposal buffer, and rage quit period.
The specification also described the Tollgate app, which controlled the cost of creating voting proposals. The tollgate fee was sent to the funding pool vault, meaning that proposal creation itself was tied to a small economic commitment.
The Hatch configuration defined the minimum goal, maximum goal, target goal, Hatch period, minting rate, and Hatch Tribute. These parameters governed how much could be raised, how long the Hatch stayed open, how many tokens were minted per contribution, and what portion of raised funds became non-redeemable.
The Hatch Oracle was included to enforce contribution limits based on membership score tokens. This connected Hatch participation to Trusted Seed reputation and prevented participants from contributing more than their score allowed. Impact Hours were also included as a separate distribution mechanism, minting TECH tokens for the community members who had helped build the TEC culture and infrastructure.
The thread then explained the two agent applications. One agent represented the non-redeemable pool, controlled by Dandelion Voting and used to advance token engineering. The other represented the redeemable pool, also controlled by Dandelion Voting but redeemable by individual TESTTECH holders on a proportional basis. The Redemptions app allowed token holders to redeem from this second pool, while preventing redemption of tokens blocked by governance participation.
A large part of the thread was dedicated to permissions. The specification mapped which app could perform which action, who held each permission, and who managed it. This made the post a deployment blueprint rather than a conceptual overview. It showed how the Hatch, Impact Hours, Redemptions, Dandelion Voting, Tollgate, Token Manager, ACL, and Agent apps would relate to one another at the smart contract permission level.
January 25 to March 4, 2021
Follow-up discussion identified a missing permission related to redemptions and one of the agents. The original post was updated to correct this. Later discussion clarified that creating a Dandelion Voting proposal did not require holding TECH directly, because the CREATE_VOTE role was routed through the Tollgate app and only required paying the proposal fee. This was accepted as a useful feature, allowing anyone willing to pay the tollgate cost to make a proposal.
The specification was also edited to reflect an Impact Hours app reimplementation, an added transfer permission, and updated parameter names. These edits show that the implementation spec was a living document, revised as the technical architecture evolved and the vocabulary became more standardized.
March 29 to May 26, 2021
A later edit added a description of the Target Goal. In May, the thread was updated again to explain that the original TEC TEST Hatch DAO had bugs corrected in later deployments and that the Migration Tools app had been added. A final permission specification was posted, including additional migration-related permissions, changes to how Hatch close and Impact Hours permissions worked, and a revised CREATE_VOTES restriction.
The May update also noted that a previous timestamp-based restriction for creating votes had not worked well when the DAO open date was unknown at creation. It was changed to an ACL oracle instead. This captured an important implementation lesson: governance timing assumptions needed to be encoded in a way that worked with the realities of deployment.
By the end of the thread, TEC had a detailed technical record of its test Hatch architecture. The thread documented not just the intended governance flow, but also the specific app configuration, token mechanics, vault structure, oracle logic, redemption rules, permissions, bugs, and revisions that shaped the path from test Hatch toward production readiness.
2021-01-27 to 2021-02-22 — How We Choose the Hatch Parameters
Forum thread: How we choose the Hatch parameters Category: The Hatch / Archive Archive theme: Hatch parameters, cadCAD modeling, Tokenlog voting, CSTK, Impact Hours, quadratic voting, soft governance approval
January 27, 2021
A thread was opened to define how TEC would choose its Hatch parameters. By this point, the TEC Test Hatch DAO had launched, and a full implementation specification existed that clarified which parameters and permissions needed community decisions before the Hatch could be completed. The thread framed the remaining challenge as process design: the community needed to decide exactly how parameter proposals would be submitted, compared, and selected.
The proposed process relied on several pieces of infrastructure. A cadCAD model would allow technical and non-technical participants to experiment with Hatch design choices and understand their effects holistically. A website would make the model easier to use, and participants could submit their chosen parameter sets as GitHub issues with explanations of their design choices. A dedicated forum thread would then allow broader discussion of the proposals.
For voting, Tokenlog would be adapted to the Hatch parameter use case. Anyone who had earned CSTK tokens or Impact Hours would be able to vote on the parameter proposals. Voting power would be split evenly between CSTK holders and Impact Hours, giving both prior Commons Stack reputation and TEC contribution labor a role in the decision. Voting would be quadratic, meaning that concentrating more voting power on a favorite parameter set would become increasingly costly.
The proposed final selection process was that once the cultural and technical sides were ready, the community stewards would choose a date and time, and the parameter set with the most votes at that moment would become the Hatch parameter set. This made the process a combination of open modeling, proposal submission, discussion, quadratic signaling, and a fixed decision moment.
February 7 to February 17, 2021
The discussion refined where proposal-specific conversation should happen. It was questioned whether each parameter proposal needed both a GitHub issue and a separate forum post. The response clarified that individual parameter proposals could be discussed directly in their GitHub issues, while a shared forum thread would be useful for voters to compare proposals against one another, discuss preferences, and understand tradeoffs across the full set of options.
A working Hatch dashboard and repository were shared, showing that the tooling for parameter selection was actively being built. The thread then introduced a forum poll asking whether the community supported the proposed strategy for choosing Hatch parameters.
February 22, 2021
The vote closed unanimously, and the parameter-selection process was approved. The approval was recorded in the soft governance decision tracker.
By the end of the thread, TEC had approved a structured process for choosing Hatch parameters. The process combined cadCAD modeling, GitHub proposal submission, forum comparison, Tokenlog voting, quadratic allocation, and a voting body split between CSTK and Impact Hours. This thread captured a major governance milestone: the community was not only choosing parameters, but choosing how it would choose them.
2021-01-28 — Scale of Conflicts and Graduated Sanction Guideline
Forum thread: Scale of conflicts - Graduated sanction Guideline Category: Community Updates Archive theme: Gravity, conflict resolution, graduated sanctions, conflict scale, mediation, conciliation, arbitration, community wellbeing
January 28, 2021
This thread documented early Gravity Working Group reflections on how the TEC might identify the scale of conflicts and respond with graduated sanctions. The post made clear that the framework was not intended as rigid criteria, but as a way to understand the size of possible conflicts and suggest proportionate mechanisms for protecting the wellbeing of the community and its members.
The framework distinguished between small, mid, and big scale conflicts. Small scale conflicts were described as issues involving only a few people, often without a formal registry, where communication had not fully broken down. Examples included strong language, unwanted nicknames, taking credit for someone’s work, coordination issues, biased praise, burnout-related stress, private issues becoming public, and misunderstandings. Mid scale conflicts were described as private but latent issues with some record, multiple stakeholders, or repeated unwanted behavior. Examples included contradictions of TEC values, bullying, discrimination, impersonation, doxing, abuse of SourceCred or Praise, inappropriate proposals, and avoidance of Gravity calls. Big scale conflicts were defined as public and manifest issues involving public or external stakeholders, failed management processes, violence, harassment, or exploitation of bugs or errors.
The thread then mapped conflict-management mechanisms to graduated responses. Negotiation was framed as the lightest intervention, where a Graviton could witness a direct agreement between parties, often with no formal sanction, informal calls, follow-up, or reconciliation rituals. Mediation involved a Graviton facilitating communication without proposing the solution, potentially including warnings, evidence gathering, written management, private warnings, restorative work, and formal calls.
Conciliation was described as a stronger intervention where a Graviton proposes and helps implement a suggested solution when the parties cannot reach agreement on their own. Possible responses included public warnings, deleting posts or proposals, graduated bans from Discord, gathering evidence, restoring affected parties, and swarming the conflict for solutions. Arbitration was the strongest level, used when an external point of view was needed, when privileges might be lost, when external stakeholders were involved, or when legal action could become relevant.
By the end of the thread, Gravity had begun translating TEC’s values into a practical conflict-response ladder. The entry connected community wellbeing, conflict scale, restorative practices, evidence gathering, warnings, mediation, sanctions, and external escalation into one early framework for how the TEC could handle harm without jumping immediately to either inaction or severe punishment.
2021-01-29 to 2021-02-01 — TEC Transparency Audit Proposal
Forum thread: TEC Transparency Audit Proposal Category: Conviction Voting / Archive Archive theme: Cultural proposal, transparency audit, working group documentation, mutual monitoring, community voting
January 29, 2021
A formal transparency audit proposal was opened after the earlier advice-process discussion. The proposal repeated the core rationale: TEC was a value-driven community, and transparency was important for exercising integrity. Existing transparency work had focused on documenting meetings and making updates publicly available through video channels, but the proposal argued that the community could reinforce transparency through a more structured audit process across working groups.
The goal was to conduct transparency audits that would guide working groups in documenting their actions and decisions without making participation mandatory. The audit was framed as a mutual monitoring and accountability tool, not as a punitive enforcement process. Its intended output was a report measuring each participating working group’s transparency level against a defined set of criteria, followed by recommendations for improvement.
The proposed process had become more concrete than in the earlier advice thread. A criteria/checklist had already been created and reviewed by some working group representatives. The plan was to run trial audits with a few selected working groups before rolling out the process more broadly. Participants would complete questionnaires or forms asynchronously, and the transparency group would review the responses, provide feedback, and use the trial audits to determine the cadence and schedule of future audits.
The proposal included a poll asking whether the transparency group should conduct the audit. This moved the idea from preliminary feedback into a formal community decision. The planned timing remained the same: trial audits before the Hatch and official audits after the Hatch.
The discussion raised a practical concern about whether the audit could slow down work that had already been identified as critical to the Hatch. The response clarified that the first trial audits were expected to involve working groups where the process could produce useful feedback and build trust without interfering with roadmap timelines. The audit was described as guidance for keeping documentation up to date, not as work that should shift existing priorities.
The thread also suggested treating the first audit as a snapshot of TEC’s current transparency state rather than as a pass-fail judgment. The value of the process would come from establishing a baseline and then improving transparency scores over time. Another suggestion was to use actual links to documents, Discord messages, or timestamped videos rather than screenshots, so the audit would create a connected web of context and evidence rather than isolated proof artifacts.
February 1, 2021
The voting session closed and the proposal was approved. A decision-tracking document was linked to record the outcome.
By the end of the thread, the transparency audit had moved from an idea in the Advice Process to an approved cultural governance practice. The thread showed TEC turning its values into an operational mechanism: define criteria, run trial audits, document evidence, create transparency reports, recommend improvements, and use community voting to authorize the process.
2021-02-04 — Best Practices for Decentralized Communities
Forum thread: Best Practices for Decentralized Communities! Category: Community Updates Archive theme: Soft governance, decentralized community design, cultural practices, trust, transparency, participation, stewardship
February 4, 2021
A community update was published to collect lessons from TEC’s soft governance work and lived experience building decentralized communities. The guiding question was what advice the community would give to someone starting a decentralized community. The thread gathered practical cultural guidance rather than proposing a technical mechanism or funding request.
The advice emphasized starting from a strong sense of purpose. A decentralized community needed to understand what it was uniquely driven toward, establish a shared vision, and develop a common language for communication. The discussion also stressed the importance of trust, clear goals, shared values, and alignment between the organization’s values and its objectives.
The thread highlighted participation design as a core responsibility. Communities should create clear paths for participation, choose platforms intentionally based on how they support the work, maintain open meetings where people can observe or join, and give people agency to lead working groups or initiatives. At the same time, the discussion recognized the need for stewardship and curation at the beginning, especially when launching a decentralized economy where value alignment matters.
Several points focused on culture. The community should promote thought diversity, gratitude, warmth, learning, mutual care, transparency, and long-term strategy over short-term profit. Impact Hours were presented as a way to make contribution visible despite differences in personal circumstances or work styles. The thread also emphasized that small tasks should be encouraged and valued because they help people build confidence toward larger contributions.
The discussion drew from commons theory and governance practice. Ostrom’s principles were recommended as a way to understand things that are difficult to reduce to equations. The thread warned against the tyranny of structurelessness and encouraged communities to understand roles, social dynamics, objectives, and social agreements. It also emphasized that open source practice, transparency, and nested ecosystems were important for decentralized communities.
By the end of the thread, TEC had created a compact cultural reference for decentralized community building. The advice centered on trust, shared purpose, values, welcoming stewardship, transparent documentation, participatory pathways, role clarity, gratitude, learning, open source practice, and long-term commons stewardship. The thread captured TEC’s evolving belief that decentralized infrastructure depends as much on cultural practices as on governance mechanisms.
2021-02-16 — Hatch DAO Machine State Diagram
Forum thread: Hatch DAO Machine State Diagram Category: Dandelion Voting / Archive Archive theme: Hatch DAO states, machine state diagram, smart contract actions, refunds, Impact Hours, migration vote, redeemability
February 16, 2021
A technical reference thread was opened to explain the machine states of the TEC Hatch DAO from deployment through migration into another DAO. The diagram distinguished between normal user actions and administrative actions. Normal actions were the common actions most users would take, while administrative actions could be called by anyone only when the correct requirements were met and usually advanced the DAO into a new state.
The thread described the first state as Pending. In this initial state, the DAO had been deployed but the Hatch had not been opened. The main available action was to open the Hatch, which would move the system into the Funding state. Other actions, such as redemption, could technically be called but would fail because no contributed or organization tokens existed yet.
In the Funding state, people could contribute to the Hatch. Contributions were made with the contribution token in exchange for organization tokens, and contributions were held by the Hatch contract. The thread clarified that participation depended on the Hatch Oracle, which limited the ability and amount of contributions based on membership score tokens, such as CSTK in the TEC context.
The next state was GoalReached. This occurred when the minimum goal had been reached and the Hatch period had ended, or when the maximum goal had been reached. At that point, Impact Hours rewards could be claimed, and the Hatch could be closed only after all Impact Hours tokens had been burned through the reward-claiming process. Closing the Hatch would split funds between the Redeemable and Non-Redeemable pool contracts.
If the minimum goal was not reached by the end of the Hatch period, the DAO entered the Refunding state. In that state, contributors could recover the funds they had contributed. The thread clarified that redemption actions outside the intended refund path would not work meaningfully because there would be no reserve funds available.
Once the Hatch was closed, the DAO entered the Closed state. At that point, a new vote could be created to migrate the funds from the Redeemable and Non-Redeemable pools into a new DAO. Token holders could vote, passed votes could be executed, and users could redeem their organization tokens for a proportional share of the reserve unless they had voted yes on an active vote. This restriction was enforced by Dandelion Voting acting as an access-control oracle for redemption.
The final state was Migrated. In that state, funds had moved to the new DAO’s reserve and funding pools, and the new DAO was controlled by a cloned token representing the TEC Hatch token at the moment of migration. After migration, users could still burn tokens through redemption, but because the old reserve would be empty, redemption would no longer return contributed tokens.
The thread also explained the migration vote itself. The vote would deposit a tollgate fee into the Non-Redeemable Pool, transfer all contribution tokens from the reserve and funding pool agents to the new DAO, clone the token manager token, and initialize the new DAO’s token manager with that clone. From the user perspective, tokens remained redeemable in the Closed state unless the user had voted yes on an active migration vote, in which case redeemability was paused until the vote ended.
By the end of the thread, the Hatch DAO lifecycle had been translated into a state machine: Pending, Funding, GoalReached, Refunding, Closed, and Migrated. The thread clarified which actions were valid in each state, how Impact Hours and refunds fit into the flow, how funds moved between pools, and how Dandelion Voting prevented people from both supporting migration and redeeming out while the vote was active.
2021-02-19 to 2021-07-01 — TEC Is Looking for Writers and Content Producers
Forum thread: TEC is looking for Writers and Content producers Category: Community Updates Archive theme: Communications working group, contributor recruitment, content production, Impact Hours, onboarding, public storytelling
February 19, 2021
A community update was posted to recruit writers and content producers for TEC’s Communications Working Group. The thread explained that TEC was growing and needed more people to support content production across several formats.
The call invited contributors to help with articles, forum posts, newsletter content, video production, and similar communications work. It also connected this work to TEC’s contribution recognition system: people who helped could receive Praise and earn Impact Hours. This framed communications not as informal volunteering outside the system, but as recognized community labor.
The thread also asked the community to spread the word through Twitter and other social media channels. This showed that communications work was both an internal need and an outward-facing growth function: TEC needed to explain itself, produce regular content, and attract people who could help tell the story of the project and the token engineering ecosystem.
February 26 to July 1, 2021
A follow-up reminder confirmed that the call for writers and content producers was still active and directed interested people toward the Comms Discord channel. Months later, a contributor returned to the thread to say that they were trying to produce content through Comms, while noting that it was not always easy to figure out how to help TEC.
The final response pointed toward the Comms weekly sync and content workshops as the best way to get involved, because those calls were focused specifically on content work.
By the end of the thread, TEC had documented a simple but important contributor pathway for communications work. The thread captured the need for writers, content producers, articles, newsletters, videos, social media support, Comms onboarding, and clearer routes for new contributors who wanted to help but did not yet know where to begin.
2021-02-24 — Community Stewards WG
Forum thread: Community Stewards WG Category: Working Groups / Archive Archive theme: Stewards working group, coordination, sprint planning, blocker resolution, community temperature, cross-workstream visibility
February 24, 2021
A working group reference thread was opened to define the purpose and operating rhythm of the Community Stewards Working Group. The thread described the group as a coordination layer meant to provide visibility across TEC’s separate workstreams so that the Stewards could move together toward shared high-level goals.
The thread framed the weekly Stewards meeting as a place to check the temperature of the community, identify and resolve blockers, raise questions that affected Stewards or the wider community, and use collective intelligence to address them. This positioned the working group as a connective tissue between distributed teams rather than as a narrow task group.
The thread also described the working style as agile, using a two-week sprint cadence. It pointed members to the meeting time, Discord channel, manifesto, agenda, sprint board, and contribution pathway. By doing so, it turned the forum post into an operational entry point for people who needed to understand how TEC’s stewardship coordination functioned.
By the end of the thread, the Community Stewards Working Group had been documented as a central coordination body for TEC. The entry captured how the community organized cross-workstream visibility, planning cadence, blocker resolution, and shared accountability during the Hatch preparation period.
2021-03-01 to 2021-05-26 — TAO Voting Parameters General Discussion
Forum thread: Tao Voting (formerly Disputable Voting) Parameters General Discussion Category: Disputable Voting / Archive Archive theme: TAO Voting, Disputable Voting, delegation, quiet ending, Celeste disputes, Commons Upgrade, governance powers
March 1, 2021
A general discussion thread was opened to introduce the voting system then called Disputable Voting and later referred to as TAO Voting. The thread explained that the TEC Hatch DAO would use Dandelion Voting, but that after the Commons Upgrade the full Commons would use this newer voting system from the 1Hive Gardens template.
The thread framed TAO Voting as a voting app with three major additions. The first was delegation, allowing token holders to vest voting power to a delegate while retaining the ability to veto that delegate’s vote and vote directly instead. The second was disputability, meaning proposals could be challenged and potentially escalated to Celeste or another court-like mechanism. The third was wait-for-quiet, which added time to a vote if the outcome flipped near the end of the voting period.
The post gathered links to related parameter discussions rather than treating TAO Voting as a single isolated mechanism. Vote duration, support required, minimum quorum, delegated voting period, quiet ending, and execution delay were all presented as parts of the larger governance configuration. The thread also clarified that there was no separate Rage Quit mechanism in this system because the Augmented Bonding Curve would provide an exit path after the Commons Upgrade.
March 1 to March 10, 2021
The discussion then clarified how TAO Voting related to other TEC governance tools. A question was raised about whether this system added features to Conviction Voting or existed as a separate voting instance. The thread clarified that it was a separate instance, intended for parameter changes and other major decisions in the Commons. Dandelion Voting would belong to the Hatch DAO stage, while TAO Voting would govern the post-upgrade Commons.
This led into a broader discussion of scope and power. TAO Voting was described as the high-authority voting app for the Commons, capable of changing nearly every economic parameter and even changing permissions. This made it the mechanism for major future upgrades and parameter adjustments, but it also made the community agreement around valid proposals extremely important.
The thread also raised questions about Celeste and juror requirements. The discussion asked who could become a juror, whether jurors should go through community conflict-resolution training, whether TEC would vote to implement the system, whether it would use TEC tokens, and how juror reward mechanisms worked. These questions showed that dispute resolution was not just a technical add-on; it raised cultural, legal, and legitimacy questions about who interprets community agreements.
May 26, 2021
A later clarification emphasized the breadth of TAO Voting’s power. The system could move funds out of contracts, mint and burn tokens, and exercise the kinds of permissions that matter most for the Commons economy. It could not literally rewrite smart contracts, but with enough authority over funds, tokens, and permissions, it did not need to do so in order to reshape the DAO.
The thread framed this power as a normal but serious feature of DAO governance. Token holders ultimately have the power to make very large changes, which is why the community needed strong shared expectations about what qualifies as a legitimate proposal. The expectation was that this power might be used more often during the early scaling period, while parameters and features were still being tuned, and then less frequently once the Commons reached a steadier state.
By the end of the thread, TAO Voting had been positioned as the post-Hatch governance mechanism for major Commons decisions. The discussion connected delegation, veto rights, quiet ending protections, dispute resolution, Celeste, execution delays, parameter governance, and the extraordinary power of token-holder votes into one larger design question: how can a Commons give itself enough authority to evolve while keeping that authority bounded by shared agreements and legitimate process?
2021-03-04 to 2021-03-07 — Disputable Conviction Voting and Celeste Demo
Forum thread: Disputable Conviction Voting and Celeste Demo Category: Conviction Vote / Archive Archive theme: Celeste, disputable Conviction Voting, community covenant, subjective oracle, DAO moderation, Commons Upgrade
March 4, 2021
A thread was opened to invite TEC members into a testing phase for Celeste and disputable Conviction Voting. The discussion explained that 1Hive was preparing a major launch and upgrade involving Celeste, a subjective oracle, paired with a community covenant that would apply to DAO votes, including Conviction Voting and yes/no votes.
The thread framed the demo as relevant for TEC because TEC planned to use Celeste as part of the Commons Upgrade. In the envisioned upgrade, funds from the Hatch would migrate into a DAO governed by a community covenant, with token holders able to enter and exit through the Augmented Bonding Curve. Funds would be distributed through a modified Conviction Voting system where proposals could be disputed if they violated the DAO’s principles.
The demo was described as a two-week testing period to identify and fix frontend bugs. It involved a Celeste dashboard and a disputable funding interface on Rinkeby. TEC members received test tokens so they could participate in the test.
The thread identified several learning goals for TEC. Members could learn what Celeste was, how a subjective oracle could moderate DAOs in a decentralized way, what a Community Covenant was, how such a covenant would operate in a DAO context, and how someone could become a Celeste keeper and earn rewards for moderating according to covenant rules.
March 7, 2021
Follow-up posts pointed people toward the disputable voting interface and shared screenshots from the test. The discussion remained focused on exploring the interface and understanding the new dispute-resolution tooling.
By the end of the thread, Celeste and disputable Conviction Voting had been introduced as important components in TEC’s future governance architecture. The thread connected dispute resolution, covenants, decentralized moderation, proposal enforcement, and Commons Upgrade planning into one practical testing opportunity.
2021-03-04 to 2022-03-14 — SourceCred in the TEC
Forum thread: SourceCred in the TEC Category: Community Updates Archive theme: SourceCred, Cred, Grain, contribution accounting, GitHub, Discourse, rewards, TECDROPS, anti-gaming, reward distribution
March 4, 2021
This community update introduced SourceCred as a tool for measuring and rewarding value creation inside TEC. The post explained that SourceCred could gather contribution data from two of TEC’s main platforms, GitHub and Discourse, and use that data to support a more automated layer of contribution recognition. It emphasized that SourceCred would not replace Praise, but would support the broader rewards system by adding another source of contribution data.
The thread explained SourceCred’s two core concepts: Cred and Grain. Cred was described as a measure that accumulates when people do things for the community, while Grain was an asset-like distribution that contributors could opt into receiving. The post used the metaphor of rain and buckets: the more Cred someone has, the wider their bucket is, and the more Grain they can catch when distributions occur.
The post then turned to the main community design decision: how different actions should be weighted. It explained that SourceCred uses weight configurations to decide how much Cred flows from one node or action to another, and that the community needed to decide which GitHub and Discourse actions deserved more recognition. The examples included creating GitHub issues, making comments, authoring or merging work, creating Discourse topics, posting replies, giving likes, being mentioned, and having posts or topics referenced.
The initial implementation plan was experimental. Cred data would update automatically each week, while instance updates and Grain distributions would happen manually. The post also raised the question of how to balance recognition between current activity and past contributions, suggesting that a committee could make these decisions with enough safety and agility to prevent the graph from being gamed or misconfigured.
June 10 to June 15, 2021
Several months later, the thread was updated with implementation progress. A DAO similar to 1Hive’s Polen had been deployed to distribute SourceCred rewards to the TEC community. The plan was for TEC proposals to send funds to this DAO, after which the DAO would handle distributions. A Discord channel and bot would collect contributor addresses and handles, feed a spreadsheet, and allow DAO members to review and vote on each distribution.
The update described the DAO’s governance protections. It had eight members, a twenty-four-hour vote duration, forty-one percent quorum, and eighty-one percent support required, meaning distributions would need meaningful agreement and could be blocked if there were concerns. Inactive DAO participants could have their tokens burned so new people could join the distribution oversight process. This human review layer was explicitly framed as protection against people gaming SourceCred.
The next implementation step was to finish an app for listing addresses and amounts and transferring distributions more elegantly. A first test distribution was expected soon. A follow-up also suggested that Discord entries could eventually be added automatically to the SourceCred instance, though the SourceCred API made automation difficult.
March 14, 2022
A final later reply noted that the old SourceCred explorer link was broken and provided the GitHub repository for TEC’s SourceCred instance instead. By then, SourceCred had become part of the larger Rewards Working Group context, but this original thread still served as the conceptual and operational foundation for why SourceCred mattered in TEC.
By the end of the thread, SourceCred had evolved from an explanatory post into a reward-distribution infrastructure plan. The discussion connected contribution graph design, GitHub and Discourse activity, Cred and Grain mechanics, manual distribution oversight, Discord address collection, anti-gaming protections, and eventually the broader TEC Rewards system.
2021-03-04 to 2021-03-08 — SourceCred Committee Proposal
Forum thread: SourceCred Committee Proposal Category: Conviction Voting / Archive Archive theme: Cultural proposal, SourceCred, contribution rewards, committee governance, parameter management, transparency, reward distribution
March 4, 2021
A cultural proposal was opened to create a SourceCred Committee responsible for decisions around SourceCred reward distribution and parameter management. The proposal emerged from earlier work on contribution rewards, where SourceCred was being tested as an additional layer that could coexist with Praise.
The proposed committee would decide which tokens could be distributed, how much would be distributed in each period, how often distributions should occur, how rewards should be split between older and recent contributions, how the community should interact with parameters, and which parameters should be changed over time. In the short term, distributions would happen in Impact Hour tokens, but the proposal left open the possibility that future distributions could use other DAO-held tokens after the Commons was fully upgraded post-Hatch.
The thread explained why a committee was needed. SourceCred was a complex tool with quantitative parameters, while Praise remained better suited for subjective and qualitative contribution recognition. The data produced by SourceCred would provide useful cultural information, but it would also need interpretation, maintenance, and protection against gaming. The committee would analyze this data and share cultural insights with the community.
The proposal framed the committee as a trusted group responsible for fairness and non-manipulative stewardship of the SourceCred system. It compared this to the Praise quantification process, where people with high context and strong cultural understanding were invited to help evaluate contributions. Transparency practices, including audits, recorded meetings, and frequent forum updates, were presented as ways to keep the committee accountable.
The proposed working style was lightweight. Rather than meeting regularly, the committee would be summoned when the data suggested that something needed attention. SourceCred interaction data would be evaluated every two weeks, and meetings would happen when something looked unusual. The committee would also create a template for parameter-change proposals, maintain the system, publish functionality information in the handbook and forum, onboard new TEC members into the SourceCred Contribution program, and publicly document each reward distribution.
The implementation plan began from the existing SourceCred instance, which was already running for Discourse and GitHub using initial parameters discussed in soft governance. The first step was to experiment with those parameters and evaluate how accurately Cred was flowing. The committee would then help standardize contribution reward distribution by combining generated Grain and Impact Hours.
March 8, 2021
The voting session closed and the proposal was approved. The outcome was recorded in the soft governance decision tracker.
By the end of the thread, TEC had approved a committee to steward SourceCred as part of the contribution reward system. The thread marked a shift from experimental discussion toward operational governance: SourceCred would not simply run automatically, but would be managed through a transparent, accountable committee responsible for parameters, distributions, data review, community onboarding, and protection against gaming.
2021-03-05 to 2021-04-17 — The Hatch TL;DR
Forum thread: The Hatch TL;DR Category: The Hatch / Archive Archive theme: Hatch overview, TECH token mechanics, redeemable pool, non-redeemable pool, Commons Upgrade, Rage Quit
March 5, 2021
A concise Hatch overview was published to explain the initial launch phase of TEC and what happens to the wxDai contributed during the Hatch. The post framed the Hatch as the critical first stage of TEC, while noting that specific numerical parameters would still be chosen by the community. The goal was to make the core mechanics understandable before people participated.
The thread described the first phase as the Hatch Period. During this limited window, legal members of the Trusted Seed could contribute wxDai and mint TECH tokens. The Hatch needed to meet a minimum funding goal. If that goal was not reached, the Hatch would fail and the funds would be returned.
The post then explained what would happen after the minimum goal was reached and the Hatch Period ended. The contributed wxDai would be split into two pools. The redeemable pool would hold funds that TECH holders could reclaim by burning their TECH tokens. The non-redeemable pool would hold funds reserved for advancing the goals of the TEC Hatch DAO and could only be moved by DAO vote. The size of the non-redeemable pool was determined by the Hatch Tribute.
The thread also explained TECH token minting. Hatchers would mint TECH when contributing wxDai, while contributors who earned Impact Hours would receive TECH at the end of the Hatch Period. This made the Hatch a combination of financial contribution and cultural build recognition.
The second major phase was the Commons Upgrade. TECH holders would vote on whether to upgrade the Hatch DAO into the full TEC Commons with a bonding curve. If the upgrade passed, the Hatch DAO’s wxDai would move into the TEC Commons and TEC tokens would be minted. If someone voted against the upgrade or did not vote, they would have the option to exit before execution by burning TECH and redeeming their share of the redeemable pool. The non-redeemable portion would not be reimbursed.
March 13 to March 14, 2021
Follow-up discussion praised the explanation and suggested that it should be required reading before someone became a Hatcher. A later edit clarified the phase numbering so that the terminology matched other Hatch documentation, especially the use of Phase 2 for the Commons Upgrade.
March 30 to April 1, 2021
The thread then clarified the role and value of TECH tokens. A question was raised about whether TECH was used both for voting and for redemption, and whether the Hatch DAO should pursue revenue mechanisms to increase TECH value. The response clarified that TECH was specific to the initial Hatch phase. Its value was tied to the funds contributed during the Hatch and to the right to exit through the redeemable pool before the Commons Upgrade. The purpose of the initial phase was not to generate revenue, but to set up the Commons for long-term success through sound parameter choices. The more expansive economic dynamics would begin after the Commons launched with TEC tokens and the Augmented Bonding Curve.
April 17, 2021
A final follow-up reaffirmed that the overview was clear and useful. By the end of the thread, TEC had a compact explanation of the Hatch that connected funding, TECH tokens, Impact Hours, redeemability, Rage Quit, the Hatch DAO, and the Commons Upgrade into a single launch narrative.
2021-03-09 — Delegated Voting Period
Forum thread: Delegated Voting Period Category: Disputable Voting / Archive Archive theme: Disputable Voting, delegation, delegate voting window, veto rights, voter verification
March 9, 2021
A short parameter discussion was opened to explain the delegated voting period in Disputable Voting. The thread introduced delegation as a major feature: a voter could vest their vote to another person, allowing that delegate to cast votes on their behalf. At the same time, voters retained the ability to veto the delegate’s vote and recast it themselves. Both voters and delegates could only vote once.
The delegated voting period was defined as the window of time during which delegates could cast the votes entrusted to them. Once that period ended, delegates could no longer vote. The main reason for having a separate delegate voting period was to give voters time to inspect how their delegates voted and decide whether they needed to veto and reclaim their vote.
The thread invited the community to think through the risks and benefits of delegation. Delegation could improve participation by allowing trusted people to vote for others, but it also introduced risks around misaligned representation, voter attention, and the need for a meaningful review period. The length of the delegated voting period therefore mattered because it shaped how much time voters had to verify delegate behavior before the vote finalized.
By the end of the thread, the delegated voting period had been framed as a governance safety parameter. It balanced convenience and participation through delegation against the need for accountability, voter oversight, and the right to override a delegate’s decision.
2021-03-09 — Quiet Ending Period and Quiet Ending Extension
Forum thread: Quiet Ending Period and Quiet Ending Extension Category: Disputable Voting / Archive Archive theme: Disputable Voting, quiet ending, vote extensions, last-minute flips, outcome stability
March 9, 2021
A short parameter discussion was opened to explain the quiet ending period and quiet ending extension in Disputable Voting. The quiet ending period was defined as the final section of the voting duration. If the expected outcome of a vote flipped from yes to no or from no to yes during that final period, the quiet ending extension would trigger and extend the vote by a specified amount of time. If the outcome flipped again during the extension, the extension could continue triggering.
The thread framed this parameter as a protection against last-minute vote flipping. The core concern was that if an outcome changed at the very end of a vote, participants should have enough time to see that the situation changed and respond before the decision finalized. The extension mechanism created a cooling-off period when the vote outcome became unstable near the deadline.
The discussion invited the community to consider how long the quiet ending period and extension should be, how those choices would affect voting, why recent outcome changes should extend the vote, and how the rule interacts with the fact that voters and delegates can only vote once and cannot change their vote once cast.
By the end of the thread, quiet ending had been framed as a procedural safeguard for Disputable Voting. It was meant to protect legitimacy by preventing surprise last-minute reversals from finalizing before the community had a chance to notice and react.
2021-03-10 to 2021-05-07 — Dacade: Peer-to-Peer Learning Platform
Forum thread: Dacade: Peer-to-Peer Learning Platform Category: Conviction Voting / Archive Archive theme: Funding proposal, token engineering education, peer learning, challenge design, incentives, community growth
March 10, 2021
A funding proposal was submitted for a peer-to-peer education platform focused on helping TEC grow its learning community. The proposal framed active learning as a public good and suggested creating a TEC-specific learning challenge where participants would learn token engineering concepts, build a toy economy, and receive peer feedback.
The proposed challenge would use curated learning materials from existing token engineering education resources. Participants would study the basics of token engineering, learn how to model a conceptual economy with value flows, and then apply that knowledge by creating their own toy economy. Submissions and peer feedback would be incentivized with tokens, turning education into an interactive and contribution-generating process rather than a passive course.
The deliverables included curating learning materials, creating a tutorial with video, code, and text, designing the challenge with TEC, implementing the materials on the platform, creating an evaluation rubric for submissions and feedback, and using marketing to attract relevant developers. The proposal argued that peer review and incentives could improve completion rates, increase practical experimentation, and create measurable outputs like repositories or submissions.
The thread positioned the platform as complementary to TEC’s broader educational mission. It aimed to broaden the token engineering community by helping newcomers learn through practice, feedback, and project-based engagement. It also suggested that TEC projects could eventually create their own challenges using project tokens as rewards, making the platform a possible tool for ecosystem growth beyond a single course.
The proposal requested funding for learner rewards, learning material curation, tutorial production, challenge creation, platform implementation, evaluation work, payment issuance, performance marketing, and operational costs. This made the proposal both an education initiative and a community growth experiment.
April 27, 2021
A follow-up question asked why learners would use this platform instead of going directly to existing education providers. The discussion suggested that the most distinctive parts of the proposal might be the challenge structure, peer feedback, and marketing layer rather than the learning content itself. The thread raised the possibility that the platform could work best in partnership with existing token engineering education groups, where the platform would provide the social learning and engagement layer around materials already being developed elsewhere.
May 7, 2021
Later replies reinforced the value of peer learning and social feedback. The discussion noted that asynchronous access, peer review, and the ability to keep learning outside the fixed schedule of academy courses could help people who missed deadlines or wanted to continue building after a course ended.
By the end of the thread, the proposal had been framed less as a replacement for existing education efforts and more as a possible extension of them. Its value was in turning token engineering education into a challenge-based, feedback-rich, incentive-supported learning environment that could grow the contributor base and help learners produce practical work.
2021-03-12 to 2021-04-01 — Mutual Accountability Methods
Forum thread: Mutual Accountability Methods Category: Conviction Voting / Archive Archive theme: Cultural proposal, Ostrom principles, transparency practices, peer accountability, advice process
March 12, 2021
A cultural proposal was opened to describe how TEC would practice mutual accountability, framed around the fourth Ostrom principle. The thread positioned accountability not as a single enforcement mechanism, but as a set of community habits that made work visible, made responsibilities clearer, and gave people ways to address conflict or disagreement before problems escalated.
The proposal identified recorded meetings as one accountability method. Recording calls was presented as a way to help people catch up, preserve transparency, and make community activity easier to review. The thread also recognized that this practice needed more shared responsibility, suggesting that more people should volunteer to record calls and help maintain the recording process.
The proposal then discussed assigning one coordinator to GitHub issues. The intent was to reduce confusion by making one person responsible for coordinating progress and closing each issue. This was not described as a way to centralize all work, but as a way to clarify who was accountable for moving a task forward. The suggested improvements focused on better issue refinement and more frequent status updates.
The thread also described Gravity as the community’s accountability mechanism for social agreements. The proposal connected Gravity to TEC’s values, rules, boundaries, expected behaviors, and graduated sanctions. It treated conflict resolution as part of accountability, especially given the complexity of the community’s structure and activities. Suggested improvements included making the Gravity intake path more visible and offering easier ways for people to reach out and understand next steps.
Transparency audits were included as another accountability practice. These audits were intended to help working groups become clearer about their documentation, actions, and decisions. The thread proposed periodic reviews that would make information available to the community, increase trust, and give working groups better guidance on transparency. A suggested improvement was to build a database that could track audits alongside the soft governance decision tracking process.
The proposal also connected the advice process to mutual accountability. Open advice requests gave people affected by a decision a place to express views before the decision was finalized. The proposer could decide how to incorporate feedback, but the public discussion made the reasoning and feedback visible. The thread treated this as especially useful for decisions that did not require formal voting but still needed transparent participation.
March 16, 2021
A follow-up confirmed that the proposal had been approved and linked it to the soft governance decision tracking system. This turned the thread from a general reflection on accountability into a recognized community decision about how TEC would practice mutual monitoring, transparency, and peer-to-peer responsibility.
April 1, 2021
A final light follow-up appeared after the decision. By that point, the substance of the thread had already been settled. The thread stood as a cultural governance record explaining the community’s accountability stack: recorded meetings, clearer task ownership, Gravity for conflict and social agreements, regular transparency audits, and more consistent use of the advice process.
2021-03-14 to 2021-03-15 — State of the Hatch and Beyond
Forum thread: State of the Hatch and Beyond Category: The Hatch / Archive Archive theme: Hatch readiness, contract freeze, migration tools, Hatch template, Commons Upgrade, bonding curve integration, post-Hatch roadmap
March 14, 2021
A detailed state-of-the-Hatch update was published to summarize a technical sync about where the Hatch stood and what remained before launch. The thread stated that Phase 1 of TEC, the Hatch DAO, was almost ready to launch, but that the contracts still needed to be frozen and formally audited for security vulnerabilities. The immediate focus was on finalizing the last technical pieces before the freeze.
The update identified three things needed for the freeze: testing the migration tools, documenting the migration tools, and adding tests for the Hatch template. The migration tools were described as custom contracts that would upgrade TEC from the Hatch DAO into the TEC DAO, moving the system from Phase 1 to Phase 2. Because these tools would govern the transition between DAOs, the post emphasized the need for careful review, more eyes on the code, formal tests, and documentation.
The Hatch template was described as the repository that would launch the Hatch DAO. Hatch parameters would be plugged into the deployment scripts, and the thread gave an example test flow: open the Hatch, contribute, claim Impact Hours, close the Hatch, hold TEC tokens with funds in the vaults, and then migrate. This helped translate the launch process into a testable sequence.
The thread then shifted to the Commons Upgrade, or Phase 2. It explained that the base DAO template would come from the 1Hive honey-template and be forked into a commons-template. Several changes would be needed: modifying the new DAO deployment script, swapping out the dynamic issuance policy for a bonding curve, removing the BrightID registry, and adding migration tools. The template already included Disputable Voting and Disputable Conviction Voting connected with Celeste.
The update also explained how the bonding curve would be assembled. The existing marketplace app would provide the bonding curve components that could be combined into the commons-template. The relevant components included the Bancor formula, the market maker, the marketplace controller, and the presale logic, though the thread clarified that TEC would not use the presale because reserve funds from Phase 1 would be sent directly to the Phase 2 reserve.
The summary of remaining work separated near-term Hatch needs from post-Hatch work. For the Hatch, the community needed migration tool tests and documentation, plus Hatch template tests and documentation. After the Hatch, the community needed the Commons template with bonding curve integration, plus parameter modeling for entry tribute, exit tribute, reserve ratio, virtual supply, and virtual balance.
The thread also acted as a call for help. It encouraged community members to read documentation, run tests, ask questions, support the development team, and contribute to review and testing before launch.
March 15, 2021
The follow-up discussion recognized the post as a useful and high-quality summary of the project’s current state. The thread served as a shared coordination point for people trying to understand what was finished, what remained, and how Hatch launch work related to the later Commons Upgrade.
By the end of the thread, TEC had a clear snapshot of its launch readiness. The Hatch DAO was nearing launch, but migration tools, Hatch template tests, documentation, audit preparation, and Phase 2 bonding curve integration still needed attention. The thread connected the immediate Hatch launch to the larger roadmap of migrating into a full TEC DAO with an Augmented Bonding Curve, Disputable Voting, Disputable Conviction Voting, and Celeste.
2021-03-18 to 2021-05-20 — Use Case Based Token Analytics Framework
Forum thread: Use Case Based Token Analytics Framework Category: Advice Process / Archive Archive theme: Token modeling, analytics framework, token system design, best practices, cadCAD pre-modeling, research proposal
March 18, 2021
An advice process proposal was opened for developing a token analytics framework. The proposal argued that token engineering still lacked shared best practices and analytic frameworks for designing token systems. While cadCAD could simulate token economies, the proposal suggested that the field also needed a conceptual framework that could help token engineers decide what kind of system they were trying to model before entering the simulation phase.
The proposed framework would analyze existing token systems to identify common patterns and design principles for future token systems. It was compared to a business model canvas for Web2 business development, but adapted for Web3 tokenized systems. The goal was to create a reusable analytical building block for conceptualizing token systems.
The framework aimed to identify token properties and their technical, legal, economic, and ethical implications. It would evaluate token system best practices, identify recurring patterns across different token economies, and produce a decision-tree framework for designing new systems. The proposal drew on existing research around token design, purpose-driven tokens, and cryptoeconomic systems.
The expected outputs included an analytics tool and a series of written analyses of token best practices, potentially bundled into a book under a Creative Commons license. The proposal requested funding for research and development over a six-month period.
April 3 to April 29, 2021
Follow-up discussion responded positively to the inclusion of legal and ethical categories, suggesting that these dimensions were important for token engineering frameworks. Another response connected the proposal to related efforts that tried to bridge high-level ecosystem value flows into cadCAD model specifications. This reinforced the idea that token engineering needed tools to move from macro-level system purpose to meso-level mechanisms, micro-level token design, and eventually formal simulation parameters.
May 20, 2021
A later response supported the effort to identify first principles and best practices, especially for communities exploring participatory economic systems. The ethical dimension of incentive engineering was highlighted as an area of particular interest.
By the end of the thread, the proposal had framed a key gap in the token engineering field: the need for structured conceptual tools that sit between abstract theory and technical simulation. The thread positioned token analytics as a way to make token design more comparable, teachable, ethically aware, and reusable across projects.
2021-03-25 to 2021-04-15 — Mission, Vision and Values Tokenlog Session
Forum thread: Mission, Vision and Values Tokenlog Session Category: Community Updates Archive theme: Mission, vision, values, Tokenlog voting, quadratic voting, Cultural Build, Hatch preparation
March 25, 2021
A community update was published to reopen TEC’s mission, vision, and values process using Tokenlog. The thread explained that TEC had already worked on mission, vision, and values early in the Cultural Build, but the community had grown significantly since then. With many more contributors and Hatchers involved, the thread argued that the community should have another opportunity to shape the statements that would guide TEC into launch.
The post framed Tokenlog as a decision-making tool that fit the mission, vision, and values use case because it allowed proposing and voting with quadratic voting. The session also served a secondary purpose: it helped the community become familiar with Tokenlog before using it to choose Hatch DAO parameters.
The thread provided the earlier TEC statements for reference. These described TEC as an effort to create safe digital socio-economic public infrastructure, operate from a prosocial human-centered perspective, uphold safety, resilience, integrity, openness, accountability, and public goods orientation, and launch a resilient culture and token economy capable of supporting token engineering public goods.
The thread then explained the process. In the proposing phase, community members could submit a GitHub issue through Tokenlog containing one mission statement, one vision statement, and one values statement. The process allowed people to remix or fork parts of other submissions, as long as credit was given. Small wording suggestions could be left as comments, but if the original proposer did not incorporate them, participants were encouraged to create a forked proposal.
The voting phase was open to Trusted Seed and Impact Hour token holders. Voters were asked to connect on xDai and distribute their votes among preferred proposals. The thread explained that a proposal with more than half of total voting power would win. If no proposal crossed that threshold, the top submissions would move to another voting round. If a polarized scenario emerged with several evenly split proposals, the leading authors would be invited to a hack session to merge their proposals.
April 12, 2021
A reminder was posted shortly before the voting session closed. The community was encouraged to keep submitting proposals and voting before the deadline, reinforcing that this was an active participatory process rather than a static announcement.
April 15, 2021
The first round of the mission, vision, and values process closed. The thread reported that ten submissions had been made, votes came from eighteen unique addresses, and the voting process used a large amount of voting power. Because the top four proposals were close, the community planned a runoff and collaborative session to prepare a final voting round.
The thread then listed the leading submissions. Across the proposals, several themes appeared repeatedly: advancing token engineering for the benefit of humanity, supporting ethical and robust design, funding open-source tools and research, creating standards and educational resources, becoming a Schelling point for the field, maintaining a nourishing culture, and aligning individual benefit with collective advancement.
By the end of the thread, TEC had turned its mission, vision, and values into a participatory governance exercise. The process combined open proposal drafting, forking, quadratic voting, runoff planning, and collaborative synthesis, making the community’s cultural foundations part of the Hatch governance process rather than a fixed statement handed down from a small group.
2021-03-26 to 2021-06-19 — How to Request Time Off from the Organization
Forum thread: How to requests time off from the organization Category: Community Updates Archive theme: Time off, offboarding, contributor rotation, Gravity, Stewards, sprint planning, workload transition
March 26, 2021
A community update was posted to explain how contributors could request short-term or long-term time off from TEC. The thread framed time away as a normal and healthy part of organizational life. Rather than treating absence as a failure, the process recognized that people need to care for other priorities and that the organization should provide safe ways to rotate responsibilities and manage transitions.
The proposed process began with notification. Contributors could communicate their intention to take time off verbally or in writing, but they were encouraged to inform Gravity, a Community Steward, or a Graviton, ideally one or two weeks in advance. This gave the organization enough time to prepare without surprising working groups or overloading others.
The second step was to confirm the transition date with Stewards. Once the time-off request was known, it could be added to the next Stewards call so the group could discuss which tasks needed to be covered, who might take responsibility for them, and what decisions needed to be made for the transition.
The third step was to transition work and shift priorities during sprint planning. The Stewards would communicate the offboarding contributor’s current projects, identify high-priority work, and assign one or more people to cover those tasks. If no one was formally delegated, the work could be moved into the queues of people in similar roles. The thread emphasized that the goal was not to dump extra work on the team, but to identify what was critical, stretch temporarily if needed, and return to normal workloads as quickly as possible.
The process also described how to handle short-term and long-term coverage for Community Stewards. In the short term, another member could temporarily fill the role. In longer-term cases, Stewards could look for replacements in the broader ecosystem or promote an interim delegate after a trial period. The departing contributor would ideally help with a transition session so the delegate could understand critical projects and complex issues.
The fourth step was communication. The thread recommended announcing the departure or time off first to Stewards or Gravity, then to the working group, and then to the broader community if needed. It also emphasized privacy and consent: the contributor should be asked how they want the news framed, and if they prefer to keep details private, others should respect that and communicate only that the transition is being handled privately.
The final step was follow-up. Gravitons or Community Stewards could check in with the contributor, learn how the offboarding process felt, ask whether anything could be improved, and make clear that the door remained open for future contribution.
June 19, 2021
A later follow-up described the process being used in practice for a contributor taking a two-week trip. The follow-up showed how advance notice, sprint planning, delegation, async collaboration, and working group empowerment could make time off healthy for both the person and the organization.
By the end of the thread, TEC had documented a humane operational policy for temporary offboarding and time away. The thread connected care, transparency, workload management, privacy, sprint planning, contributor rotation, Gravity, and Stewards into a process designed to keep the organization resilient without treating contributors as always-on resources.
2021-03-28 to 2021-03-29 — Conviction Voting TL;DR
Forum thread: Conviction Voting TL;DR Category: Conviction Vote / Archive Archive theme: Conviction Voting overview, funding proposals, conviction growth, spending limit, minimum conviction, Celeste disputes
March 28, 2021
A concise reference thread was published to explain Conviction Voting for the TEC community. The thread described Conviction Voting as a continuous, token-weighted decision process that allows a community to allocate funds to approved projects in a way that resembles natural systems rather than traditional one-time votes.
The overview explained that multiple proposals can be considered at the same time without fixed voting deadlines. Voters can distribute their token preference across different proposals, and the longer tokens remain allocated to a proposal, the more conviction accumulates. If voters remove their tokens, conviction does not disappear instantly; it decays gradually over time. A proposal passes when its accumulated conviction reaches a threshold based on the amount of funds it requests.
The thread summarized why Conviction Voting was useful. It allowed people to vote when convenient, supported multiple simultaneous outcomes, rewarded consistent preferences without locking people permanently, dampened abrupt vote swings, reduced reliance on majority consensus, made the process transparent and predictable, and resisted sybil attacks through token-weighted voting.
The post also defined several important terms. The Common Pool was the pool of funds available for community projects. Conviction was the accumulated voting power behind a proposal. Spending Limit, previously called Max Ratio or beta, was the dynamic cap on how much of the funding pool could be withdrawn at one time. Conviction Threshold was the amount of conviction required for a proposal to pass. Conviction Growth, previously called Half Life, described how long it takes voting power to accumulate or decay by half. Effective Supply was the amount of tokens actively voting. Minimum Conviction, previously called Minimum Threshold, set a baseline amount of active voting support needed to prevent tiny proposals from passing with trivial support.
The thread also noted that Conviction Voting had become disputable through integration with Celeste. This meant proposals could be challenged if community members believed they violated the community covenant. Proposals could be challenged after voting finished, but not after execution. This connected Conviction Voting to the broader move toward covenant-based dispute resolution.
March 29, 2021
A follow-up reply confirmed that the explanation was clear. The thread therefore functioned as an accessible reference point for participants who needed to understand the core logic and vocabulary of Conviction Voting without reading all of the deeper parameter threads.
By the end of the thread, TEC had a clear TL;DR for its funding mechanism. It condensed months of parameter discussions into a readable overview of how proposals gather support, how conviction grows and decays, how spending limits and thresholds work, and how Celeste-based disputes fit into the system.
2021-03-28 to 2021-06-11 — Updated Impact Hour Rate
Forum thread: Updated Impact Hour Rate Category: The Hatch / Archive Archive theme: Impact Hour Rate, Hatch parameters, builder rewards, formula clarification, Impact Hour tokens, technical implementation
March 28 to March 30, 2021
A Hatch parameter update was published to clarify the Impact Hour Rate after several changes to the original formula. The thread explained that the updated calculation connected three variables: the target amount of funds expected or raised, the maximum Impact Hour Rate, and the Impact Hour Slope. Together, these variables determined how Impact Hours would translate into Hatch token rewards for builders.
The post explained the intended incentive logic. As the target funding goal increased, the hourly value of Impact Hours would rise. At the same time, as more funds were raised, the proportion of tokens allocated to Impact Hours would decrease. This meant working Hatchers were incentivized to help raise more funds, while funding Hatchers were incentivized to contribute more funds.
The thread then moved into formula review. A possible denominator error was identified, and the implementation was checked against the Impact Hours app repository and smart contract code. The formula was corrected shortly afterward, and the error was described as a formatting issue that occurred when converting the formula into LaTeX.
The discussion also clarified the meaning of the variable used for the Impact Hour Slope. The parameter represented the expected raise level at which the rate would be half of the maximum rate. A lower value created a more curved function, while a higher value flattened the curve. This helped translate the formula into a governance choice about how quickly builder rewards should approach the maximum rate as Hatch fundraising increased.
March 30 to June 11, 2021
The thread also discussed what happened to Impact Hour tokens during the reward process. A concern was raised that burning Impact Hour tokens might erase a meaningful record of intellectual or community contribution. The clarification was that the system burned a token snapshot for the purpose of claiming rewards, while people retained their Impact Hours as a kind of record or souvenir.
A later question reopened the issue from a legal and social perspective. If Impact Hours represented intellectual investment rather than purely technical infrastructure work, the thread questioned whether there was a strong reason to burn or restrict them, especially if holding TEC tokens did not itself create the same legal concerns as participation in the membership structure.
By the end of the thread, the Impact Hour Rate had been updated from an abstract parameter into a more precise technical and economic design. The discussion clarified the formula, corrected an implementation detail, explained the relationship between fundraising and builder rewards, and raised deeper questions about how Impact Hours should function as both compensation inputs and records of contribution.
2021-04-01 to 2021-04-02 — Latest Voting Template Has Arrived at the TEC
Forum thread: Latest Voting Template Has Arrived at the TEC Category: TEC / Archive Archive theme: Community humor, voting templates, governance culture, April 1 post
April 1, 2021
A humorous community thread announced a fictional new voting template called Applause Voting. The post described it as a system where proposal outcomes would be decided through live cheering, clapping, costumes, video participation, and an applause threshold. It invented parameters such as minimum claps per minute, visible support required, and a tribute attached to the fee system.
Although playful, the thread reflected TEC’s governance culture during a period of serious voting infrastructure design. The community was actively discussing Dandelion Voting, Disputable Voting, Tokenlog, Conviction Voting, and Hatch parameters, and this post turned those technical conversations into an inside joke about mechanism design.
The imagined voting process exaggerated the logic of governance parameters by translating them into physical enthusiasm and social performance. In doing so, it showed how comfortable the community had become with the language of thresholds, voting templates, proposal outcomes, tollgate fees, and mechanism configuration.
April 1 to April 2, 2021
Follow-up replies played along with the joke, reacting to the imagined voting system and its fictional parameters. By the end of the thread, it stood as a light cultural artifact in the archive: a reminder that TEC’s governance work was not only technical and economic, but also social, playful, and community-building.
2021-04-01 — How to Rock the Vote with Tokenlog’s Quadratic Voting
Forum thread: How to Rock the Vote with Tokenlog’s Quadratic Voting Category: Community Updates Archive theme: Tokenlog guide, quadratic voting, voting power, CSTK, Impact Hours, Hatch parameter voting
April 1, 2021
A community education post was published to explain how to use Tokenlog and how quadratic voting affected a participant’s influence. The thread was written as an accessible guide for people who might be intimidated by Tokenlog or quadratic voting.
The guide instructed participants to connect to the TEC Coordination Tokenlog with MetaMask on xDai. Once connected, participants could see their voting power, which reflected a combination of CSTK score and Impact Hours. That voting power could then be staked on open issues to signal preference, helping determine which issues would be highlighted and prioritized in community planning.
The central educational point was that Tokenlog converted staked voting power into votes through a square-root formula. Staking all voting power on one issue produced fewer total votes than spreading the same voting power across multiple issues. The thread used simple examples to show how distributing voting power could increase total voting expression across several proposals.
The post explained that quadratic voting reduced the influence of large token holders and encouraged more strategic distribution of voting power. Instead of only rewarding the largest single stake, the mechanism gave participants a reason to express multiple preferences and reveal intensity across different issues.
The thread ended with a call to participate in final Hatch parameter voting. By the end of the post, TEC had a plain-language guide that connected CSTK, Impact Hours, Tokenlog, voting power, quadratic voting, and the Hatch parameter process into one practical voter education artifact.
2021-04-07 to 2021-12-15 — Commons Swarm: How Are We Doing?
Forum thread: Commons Swarm - How are we doing? Category: Ecosystem / Archive Archive theme: Commons Swarm, TEC-1Hive collaboration, Hatch frontend, Commons Upgrade, Gardens, Augmented Bonding Curve, EVMcrispr, technical updates
April 7 to April 28, 2021
This long-running Ecosystem thread opened as a weekly update channel for Commons Swarm work. Its stated purpose was to build a bridge between the TEC and 1Hive communities through a shared technical effort. Early updates reported work on the Hatch subgraph, Aragon connector documentation, 1Hive’s migration related to Celeste, content support for TEC communications, and community education materials around the Commons Simulator and Web3 ethics.
As April continued, the thread shifted into Hatch and Commons Upgrade preparation. Updates noted that the Hatch had closed and that a Commons Upgrade vote had been performed in demo form. The Commons Swarm was working on the Hatch Configuration Dashboard, Gardens Template integration, code review, test DAO migration, redemption app integration, Hatch goal front-end design, ragequit demos, and Impact Hour formula discussions. The thread captured a period where the Hatch, Commons Upgrade, and 1Hive Gardens architecture were being actively tested and translated into working software.
May to June 2021
Through May and June, the updates became more implementation-focused. The thread reported xDai fixes for Aragon Connect, improvements to the Hatch demo, smart contract changes to prevent votes during the hatch and refund periods, validation of contracts, new contributors joining dashboard and simulator work, final Test Hatch preparation, release candidates for Hatch smart contracts, app logos, and plans for a rehearsal using the winning parameters.
June updates marked an important technical convergence. The Swarm adapted 1Hive’s marketplace bonding curve into an independently usable Bancor Market Maker repo, ran a Hatch dress rehearsal, worked toward making Commons compatible with Gardens, advanced the TEC Convert frontend, improved Conviction Voting and Augmented Bonding Curve models, and began building tooling to make Commons Upgrade votes easier to create. By late June, the thread was already connecting parameter specifications, Conviction Voting models, ABC models, TEC Convert, and Gardens-based upgrades into a broader Commons Upgrade toolchain.
July to September 2021
After the Hatch went live, the thread recorded the transition from Hatch delivery into Commons Upgrade infrastructure. Updates covered the dress rehearsal recap, TEC Convert improvements, entry and exit tribute handling, virtual supply and virtual balance calculations, slippage protections, and the emergence of EVMcrispr as a library for generating EVM scripts that let DAOs modify themselves. By August, the Hatch was described as released and functioning, and the Swarm began focusing on migrating the Hatch DAO into a 1Hive Garden and replacing dynamic issuance with a bonding curve.
September updates documented the release of Augmented Bonding Curve installation documentation, the alpha version of EVMcrispr, and preparations for Params September. The thread then tracked Hooked Voting Aggregator work, EVMcrispr testing, security improvements to Hatch and ABC contracts, and the connection between that infrastructure and governance proposals such as the governance giveback and TEC-Agave collaboration. By late September, the Commons Upgrade implementation had advanced far enough to expose blockers around the xDai Aragon version and ACL oracles.
October to December 2021
The final phase of the thread followed EVMcrispr and Commons Upgrade work toward production readiness. October updates described a domain-specific language for EVMcrispr, successful execution of votes using the tooling, the release of an online EVMcrispr terminal, and experiments around Osmotic Funding. The thread also reported that the Commons Upgrade was nearing readiness, with work on the ABC, Gardens frontend support, Hatch DAO vote testing, and cross-DAO applications of the toolchain.
In November and December, the focus narrowed to the Augmented Bonding Curve and Commons Upgrade demo. Updates reported security improvements, integration with BrightID/Gardens, new ABC deployments on test networks, frontend updates, an ABC demo, Params Parties, and final ABC contract revision. The December update noted that the bonding curve was ready for DAOs that wanted to issue tokens through the mechanism, and that a Commons Upgrade demo was live using a test template with sequential votes for fund transfer and ABC opening.
By the end of the thread, Commons Swarm had used a single recurring update channel to document the technical bridge between TEC and 1Hive across nearly the entire Hatch-to-Commons-Upgrade arc. The thread showed the progression from Hatch support, dashboarding, redemption, and parameter modeling into Gardens compatibility, ABC deployment, TEC Convert, EVMcrispr, vote scripting, security review, demo upgrades, and final Commons Upgrade preparation.
2021-04-07 to 2021-08-28 — Grant Request for Attracting Creative Writers
Forum thread: Grant Request for Attracting Creative Writers Category: Advice Process / Archive Archive theme: creative writing, grants, storytelling, onboarding, NFTs, public education, Mirror, creative economy
April 7, 2021
An advice process thread was opened to explore whether TEC grant funding could attract creative writers into the broader token engineering and commons ecosystem. The proposal argued that many grants naturally focused on crypto-specific work such as development, infrastructure, technical writing, and media, but that creative writing might be an underused way to bring more people into the space.
The starting example was a story-based project connected to NFTs and a treasure hunt. The idea was not to hire someone to explain NFTs technically, but to invite writers who might not even know what an NFT is to create engaging stories that could introduce these concepts indirectly. This reframed storytelling as an onboarding and cultural bridge rather than a purely promotional activity.
The post proposed funding not only one isolated story, but a broader effort to attract creative people into Web3 communities and related projects. Early discussion saw this as a provocative expansion of what grant funding could support: instead of only funding tools or technical education, TEC could help fund fiction and creative narratives that make token engineering concepts more accessible to the general public.
August 7 to August 28, 2021
Later discussion revisited the idea and suggested that a single grant might not be the best structure. Instead, the thread considered whether TEC could support a creative economy mechanism that rewards audience appreciation, praise, likes, or other signals around creative work. The goal would be to avoid one-off dependency and create a self-perpetuating system that could support writing, gamification, visual media, or other storytelling formats.
The thread also mentioned external writing platforms and community publishing mechanisms as possible paths for funding and coordinating creative work. Later comments supported creative writing as a high-leverage way to expand TEC’s mission, vision, and values, and suggested experimenting with existing creator-funding platforms rather than building everything internally.
By the end of the thread, creative writing had been framed as a serious contributor pathway and outreach strategy. The discussion connected grants, fiction, NFTs, public education, audience-driven rewards, SourceCred-like signals, praise, Mirror-style publishing, creative economies, and cross-DAO collaboration into one proposal for broadening TEC’s cultural reach.
2021-04-08 to 2021-04-14 — How YOU Can Hatch the TEC
Forum thread: How YOU Can Hatch the TEC Category: The Hatch / Archive Archive theme: Hatch onboarding, founding membership, Trusted Seed, Impact Hours, commons upgrade, public participation
April 8, 2021
A public onboarding guide was published to explain how someone could become a founding member of TEC. The thread began by asking whether a potential participant wanted to advance token engineering, help create standards, support education and tooling, and join the broader effort to move the field forward. If so, the guide framed the Hatch as the path into founding membership.
The thread described TEC as an emerging engineering society for token engineering, with the long-term aspiration of becoming a Schelling point for the field. It emphasized that TEC was intended to be governed by its members and sustained by a regenerative token economy that could fund community projects without relying only on donations.
The guide then explained what it meant to be a Hatcher. A Hatcher was described as a founding member who would help initialize the bonding curve and receive early governance rights over the new token economy. The thread stressed that the Hatch was closed because TEC wanted initial governance power to sit with people who cared about advancing token engineering, rather than pure speculation. Speculators could join later, but the founding phase was meant to be community-aligned.
The thread laid out a prerequisite phase for becoming a Hatcher. Participants needed to apply to the Trusted Seed, activate membership, earn Impact Hours and reputation through Praise, learn more through community calls, and participate in choosing the mission, vision, values, and Hatch parameters. This framed the Hatch as both a financial and cultural onboarding process, where contribution and understanding mattered before launch.
The next phase explained the Hatch itself. Participants would check their reputation score, set up xDai in their wallet, obtain wxDai, and contribute to the Hatch when it opened. Contributions would mint TECH tokens, which would govern the Hatch DAO. The thread also explained that Impact Hours would convert into TECH at the end of the Hatch period through the Cultural Build Tribute.
The guide then described the Commons Upgrade. After the Hatch, the community would use the Commons Config Dashboard and Tokenlog to choose economic parameters, then ratify the upgrade through the Hatch DAO. If completed, TECH holders would receive TEC, the Augmented Bonding Curve would collateralize the TEC token, and Conviction Voting would become the funding mechanism. The thread also made clear that the upgrade was not automatic; TECH holders could choose not to upgrade and could remain a simpler DAO instead.
Finally, the thread described the post-upgrade phase as the point where TEC would be fully alive and open to the broader public through the Augmented Bonding Curve. The purpose of the economy was framed as sustaining the social layer: aligning incentives, rewarding value creation, following Ostrom-inspired principles, and coordinating the token engineering community around shared tools, standards, and public goods.
The thread ended with a glossary of key terms, defining TEC, Commons Stack, DAOs, token engineering, the Hatch, Impact Hours, and Cultural Build. This made the post both an onboarding guide and a conceptual bridge for newcomers trying to understand how the Hatch, Trusted Seed, Impact Hours, TECH, TEC, and the Commons Upgrade fit together.
April 13 to April 14, 2021
Follow-up discussion focused on the visual walkthrough attached to the guide. The graphic was praised as helpful for explaining the process, and higher-resolution versions were requested and shared. This reinforced the thread’s role as a public-facing explanatory artifact, meant not only to document the Hatch process but to make it understandable for people preparing to participate.
By the end of the thread, TEC had a clear step-by-step entry point for prospective Hatchers. The post translated a complex launch sequence into a practical journey: join the Trusted Seed, earn reputation and Impact Hours, prepare technically for the Hatch, receive TECH, help choose the Commons parameters, and eventually participate in the fully launched TEC economy.
2021-04-09 to 2021-04-20 — Commons Upgrade Vote Demo
Forum thread: Commons Upgrade Vote Demo Category: The Hatch / Archive Archive theme: Commons Upgrade testing, Hatch demo, redemption mechanics, Impact Hours minting, migration, quorum, technical issues
April 9, 2021
A demo thread was opened to walk the community through a test Commons Upgrade vote after a Hatch demo had ended. The post summarized the demo results: contributions had been made, wxDai had been raised, a portion had gone to the non-redeemable vault through the Hatch Tribute, and the remaining funds could be redeemed proportionally by test token holders.
The thread then explained how Impact Hours affected token distribution in the demo. Using the selected Impact Hours parameters, the post calculated the Impact Hours rate, the amount of test governance tokens minted from Impact Hours, and the resulting cultural tribute. This made the demo a practical example of how contributed funds and recognized community labor combined to shape Hatch token supply.
The post also clarified redemption mechanics. Test tokens could be redeemed for wxDai at a calculated rate, and there was no distinction between tokens minted through Hatch contributions and tokens received through Impact Hours. Both were redeemable equally. The thread explained that redeeming at that stage would only make sense in limited cases: if an Impact Hours holder wanted liquidity immediately, or if someone disagreed with the upgrade vote outcome and wanted to exit before migration.
Because the full Commons Template was not ready, the demo planned to migrate funds into a normal DAO with two vaults and a new test token. The thread explained the parameters being used for the demo Commons Upgrade, including the funding pool tribute and the token locking schedule. Participants were invited to vote during a short voting window and were reminded that they could rage quit before migration unless they had voted yes.
The post also documented known interface issues. Some dates and remaining-time displays were incorrect because of message formatting and xDai block timing assumptions. This made the thread not only an instruction guide, but also a testing report that surfaced user-interface and network-specific problems before the real launch process.
April 9 to April 15, 2021
Follow-up comments clarified that redemption could not happen immediately because participants needed to wait one day after the Hatch period. Later updates reported infrastructure issues involving the xDai default node, the Aragon IPFS default node, and the redemption forwarding path. The first vote also failed because it did not reach quorum, so the vote had to be created again.
The thread then provided alternative xDai and IPFS node options for people who had problems interacting with the vote. This turned the demo into a troubleshooting exercise for the tooling stack around voting, redemption, Aragon, xDai, and IPFS.
April 20, 2021
A final update reported that the second vote had been executed and the migration had been performed. The post described how the demo funds were split between the funding pool and reserve, how old test Hatch tokens were converted into the new DAO’s test token based on a migration snapshot, and how the new tokens were locked for one year according to the vote.
The thread also documented an important failure: nobody was able to redeem during this demo because an older redemption contract had a bug and lacked the permissions needed to burn tokens. A new contract had been redeployed with the bug fixed and the required permissions checked, with the expectation that redemption would work in the general rehearsal.
By the end of the thread, TEC had a detailed record of a Commons Upgrade test run. The thread captured the mechanics of contribution accounting, Impact Hours minting, token redemption, rage quit logic, voting quorum, migration execution, vault allocation, token locking, and the technical issues that needed to be fixed before production launch.
2021-04-12 to 2022-10-06 — 0mega Working Group
Forum thread: Ωmega Working Group Category: Working Groups / Archive Archive theme: 0mega, TE ethics, ethos, self-sovereignty, participatory action research, TE Consilience Library, worldviews, informed participation, regenerative workflows
April 12, 2021
This Working Groups thread introduced 0mega as a space for examining the ethos and ethics of token engineering, along with the shared vision and diversity of the token engineering community. The group’s purpose was not only to debate values abstractly, but to create an open space where token engineers and participants in token economies could explore ethical dilemmas, worldviews, and the inner work involved in building token networks.
The post described 0mega’s work as an intentional exploration of TE Ethics and Ethos using participatory action research. The group identified several ethical principles through an early focus group on ethical dilemmas: hosting multiple worldviews, navigating dynamic landscapes, being aware of social engineering, and enabling informed participation. These principles later became linked to 0mega’s broader claim that the work was really a course in self-sovereignty.
The thread also positioned 0mega as a home for ongoing research into the practical applicability of the TE value system and the tension between private profit and public benefit. Focus groups would be conducted and analyzed by social scientists, with the results shaping TEC’s understanding of token engineering as an emerging field and of the people participating in it.
A second major branch of 0mega’s work was the TE Consilience Library. The post explained that the principle of enabling informed participation led to the library initiative, which would connect token engineering knowledge across computer science, law, political economy, cryptoeconomics, arts, sciences, and lived participation in token economies. The library was described as a consilience experience, not just a collection of links.
October 6, 2022 update
The post was later updated to describe 0mega’s recurring meeting structure and its shifted emphasis. Weekly Wednesday sessions alternated between TE Consilience Library updates and a newer focus called “A Course in Self-Sovereignty.” This newer framing included self-knowledge, key and wallet management, socio-technical literacy, and self-leadership in Web3, weaving TE ethical principles into the broader art of being human in a tokenized environment.
The update described each area as an experiment in self-organization and regenerative workflows. Participation remained self-funded, while the group also pointed toward possible experiments with TEC distribution through Conviction Voting. The thread linked outward to how to join and contribute, the TE Consilience Library, and the TE Ethics Participatory Research initiative.
By the end of the thread, 0mega had become the container for TEC’s most explicitly reflective and ethical work. It connected token engineering ethos, participatory research, ethical dilemmas, multiple worldviews, self-sovereignty, informed participation, Consilience Library development, regenerative workflows, and the attempt to make ethics a lived practice inside TEC rather than a static statement of values.
2021-04-20 to 2021-08-10 — How to Get wxDAI: A Bridging Story
Forum thread: How to get wxDAI; A Bridging Story Category: Community Updates Archive theme: Hatch onboarding, wxDAI, xDAI network, bridging, MetaMask, DAI, BSC, Ethereum mainnet, Polygon, fiat onramp
April 20, 2021
A practical community guide was published to help people acquire wxDAI for the Hatch. The post explained that wxDAI would be important for full Hatch participation and began by clarifying the relationship between the xDAI network, xDAI, DAI, and wrapped xDAI. It also reminded readers to set up MetaMask and connect it to the xDAI network before attempting to bridge funds.
The guide then walked through several paths for getting into wxDAI. One route used a centralized exchange and Binance Smart Chain as a lower-cost path: convert funds into DAI or USDC, withdraw them to a BSC-connected MetaMask wallet, bridge them to xDAI through OmniBridge, and then swap into wxDAI. Another route avoided Binance and centralized exchanges by bridging from Ethereum mainnet to xDAI, either by moving DAI directly or bridging eligible ERC-20 tokens and then swapping on xDAI.
The thread emphasized caution and user safety. It encouraged people to read the full instructions before acting, test bridges and swaps with small amounts, confirm networks and destination addresses, and ask the community for help if they were unsure. The guide treated bridging as a necessary but confusing piece of Hatch onboarding and tried to make the process understandable for a broader range of users.
April 20 to August 10, 2021
Follow-up discussion added more routes and kept the guide current. Suggested additions included using an exchange with a direct xDAI pair, bridging from BSC or Polygon through cross-chain tools, using a direct fiat onramp, and updating dead links. These additions turned the original walkthrough into a broader reference for multiple user situations and changing bridge infrastructure.
By the end of the thread, TEC had a practical, community-maintained onboarding guide for obtaining wxDAI. The discussion connected Hatch participation, MetaMask setup, stablecoin conversion, centralized and decentralized bridge options, BSC, Ethereum mainnet, Polygon, fiat onramps, small test transactions, and community support into one technical onboarding resource.
2021-04-20 to 2021-05-03 — MVV Runoff Results Are Up
Forum thread: MVV Runoff Results Are Up Category: Community Updates Archive theme: Mission, vision, values runoff, Tokenlog voting, quadratic voting, cultural governance, final MVV statements
April 20, 2021
A follow-up thread announced the runoff stage for TEC’s mission, vision, and values process. The top submissions from the first round had been collectively edited and placed back on Tokenlog for a final vote. The proposals were submitted anonymously by number rather than title so that voters would focus on the content rather than the authors.
The thread gave practical instructions for voting. Token holders were told to switch their wallet to xDai, open the numbered issues, choose their preferred proposal, and vote. The post also clarified that Tokenlog used quadratic voting as a soft governance tool. Although token balances shaped voting power, the vote itself did not execute anything on chain. Once submitted, votes could not be changed.
The runoff represented a more refined stage of the earlier mission, vision, and values process. The first round gathered broad input and identified the strongest directions. The runoff narrowed those directions into a final choice that the community could use as a shared cultural and strategic reference.
April 21 to April 25, 2021
Follow-up activity focused on helping people participate. A short video was shared to explain the voting process, and additional guidance was provided for adding the xDai network to wallets. The thread also included light community encouragement and memes to keep participation visible and active.
May 3, 2021
The final polished version of the winning mission, vision, and values was posted. The thread also shared voting data from the full process, including participation across the first round and runoff. The results showed substantial engagement from token holders and demonstrated that TEC’s cultural statements had been selected through an open participatory process.
The final vision stated that TEC aimed to enable the creation of ethical, safe, resilient, and diverse economic systems for the benefit of societies around the world. The final mission positioned TEC as a Schelling point for the token engineering community. It described the economic layer as a way to fund projects that discover, develop, and spread best practices for safe tokenized economies, while aligning collective success with individual token holder benefit. It also emphasized that the social layer was even more important, because it would unite the field around ethical principles, standards, tools, and methodologies.
The final values described the Commons as prosocial and human-centered, prioritizing the advancement of token engineering over short-term profit. They emphasized integrity, curiosity, constructive inquiry, presence, gratitude, mutual respect, open source practice, non-hierarchy, transparency, and accountability.
By the end of the thread, TEC had completed a major cultural governance process. The mission, vision, and values were no longer just draft statements or early Cultural Build artifacts. They had gone through proposal drafting, collective editing, Tokenlog voting, a runoff, and final polishing, creating a shared language that could be used to explain TEC and check whether the community was moving in the right direction.
2021-04-27 to 2021-08-09 — Gravity Easy Step by Step
Forum thread: Gravity easy Step by Step Category: Community Updates Archive theme: Gravity, alternative dispute resolution, mediation steps, conflict management forms, graduated sanctions, community education
April 27, 2021
A community update was published to explain Gravity’s dispute-resolution process in a simple step-by-step format. The thread translated the broader Gravity concept into a practical mediation pathway for DAOs.
The process began with identification, where one party could approach Gravity to request mediation, or Gravitons could identify issues that needed discussion. It then moved into screening, where the parties would provide relevant information and be invited into a mediation process. The third step focused on looking for solutions by framing disputes in a non-adversarial way and guiding the parties toward a settlement agreement. The final step was post-mediation follow-up, where Gravity would act as a witness and facilitator while tracking agreements and responsibilities. If an issue persisted, it could escalate to other dispute-resolution mechanisms such as arbitration or litigation.
The post also linked the process to practical forms and materials, including a scale of conflicts, graduated sanctions guidance, an observation form, and a mediation form. This turned Gravity from a general cultural principle into a usable operational workflow.
July 12 to August 9, 2021
Later updates added improved communications materials and infographics for the Gravity process, including visual explanations of the conflict management cycle. These updates made the process easier to communicate to the broader community and helped people understand how to seek support when conflict emerged.
By the end of the thread, Gravity had a public-facing procedural guide. The discussion connected identification, screening, mediation, settlement follow-up, forms, graduated sanctions, escalation paths, and visual education into a simplified conflict-management process that community members could understand and use.
2021-04-28 to 2021-07-09 — An Organic Decision-Making Mechanism for DAOs
Forum thread: An organic decision-making mechanism for DAOs Category: Advice Process / Archive Archive theme: DAO governance design, sociocracy, holacracy, holonic stigmergy, threefold social organism, domain representation, organic decision-making
April 28, 2021
An advice process thread proposed an organic decision-making mechanism for DAOs. The thread began with a terminology primer covering sociocracy, the threefold social organism, holacracy, and holonic stigmergy. These frameworks were introduced as ways to think about distributed consent, sovereign domains, overlapping membership, self-organizing systems, and the balance between cultural, economic, and legal dimensions of collective life.
The proposal argued that healthy governance should create authority and accountability through inclusive decision-making. It warned that organizations, including DAOs, can drift toward monocracy, technocracy, extrovertocracy, or polarized democracy. The proposed alternative was a trinary governance model designed to prevent any one domain from overrunning the others.
The thread suggested categorizing members, working groups, and protocols into three top-level social domains: economic, cultural, and legal. Governance would only proceed when a balanced tripartite quorum was present. If that quorum could not be reached, then sociocratic or holacratic procedures could temporarily apply. Once convened, the trinary DAO could choose whatever voting mechanism fit the decision at hand, including direct voting, quadratic voting, federated voting, or even giving temporary executive authority to one domain for specific issues.
The proposal used TEC working groups as an example, mapping them into legal, cultural, and economic domains. The point was not only to impose a new structure, but to make visible how different forms of organizational life already appeared within the community. The thread argued that some TEC decisions, such as Praise quantification or community narrative work, could have benefited from explicit three-domain representation.
April 29 to May 4, 2021
The discussion then compared the proposed threefold grouping with another possible grouping based on commons governance: protocols, resources, and community. This alternative suggested that TEC’s working groups could also be understood through Ostrom-inspired categories. The thread recognized that almost every working group could fit into multiple dimensions, which made mapping difficult but also useful as a way to reveal interdependence.
Questions were raised about implementation and tooling. The discussion clarified that the model could use a mixture of on-chain and off-chain tools, including governance, economic, and cultural tokens. This positioned the proposal as a broad governance architecture rather than a single voting app.
July 8 to July 9, 2021
The thread was later revived with deeper questions about why the three selected domains should be used and how they should map onto a digital knowledge commons. The discussion suggested that categories such as culture, economy, and legal order needed more explanation before they could be applied cleanly to working groups. For example, Gravity could be cultural because it deals with conflict, legal because conflict has procedural implications, and economic because conflict affects resource allocation and contributor capacity.
The final responses emphasized that organic systems do not have clean black-and-white boundaries. Each domain influences and is influenced by the others. The thread connected Steiner’s threefolding, Ostrom’s groupings, the cryptoeconomic flower, Spiral Dynamics, and other models as different attempts to understand the human condition and preserve healthy social dynamics in digital systems.
By the end of the thread, TEC had explored a speculative but serious governance model for DAO decision-making. The discussion did not settle on an implementation, but it surfaced a recurring TEC theme: governance mechanisms should not only count votes, but should represent the different social functions that make a commons healthy. The thread connected sociocracy, holacracy, domain balance, Ostrom-inspired grouping, cultural/economic/legal representation, and the challenge of translating organic human governance into digital systems.
2021-05-04 to 2021-05-07 — New Hatch Demo
Forum thread: New Hatch Demo Category: The Hatch / Archive Archive theme: Hatch front-end, smart contract demo, UX testing, xDai wallet support, migration vote, launch rehearsal
May 4, 2021
A new Hatch demo thread was opened to announce an improved version of the Hatch front-end and smart contracts. The post invited the community to test the demo and highlighted several changes that had been made since earlier test runs.
The improvements included new Hatch goal indicators, front-end polish, theme and responsive design fixes, better reliability for the Hatch Aragon connector and Aragon Connect, a feedback button with screenshot support, and one-click xDai network addition through wallet support. The thread also noted smart contract changes that prevented votes from being created during the Hatch period or during closing and refund periods.
The post included the relevant contract addresses for the Hatch Template and Hatch DAO, along with a timeline for the demo. This made the thread both an announcement and a technical reference point for the current rehearsal deployment.
The community was asked to report bugs through the feedback button. This positioned the demo as a real user-testing stage before the production Hatch, focused on polishing both the user interface and the underlying contract flow.
Later the same day, feedback surfaced around wallet fee displays. Some users saw large displayed fees, but the thread clarified that this was a MetaMask user-interface issue caused by the wallet using the ETH price to calculate displayed USD cost, even though the transaction was actually using xDai underneath. This helped distinguish a confusing wallet display from an actual high transaction cost.
May 7, 2021
A follow-up shared the test migration vote for the demo Hatch and noted that the vote message still needed to be fixed so participants could better understand what the migration vote was doing. This linked the Hatch demo to the next step in the launch rehearsal process: testing not only contributions and token minting, but also the migration path from the Hatch DAO toward the Commons Upgrade.
By the end of the thread, TEC had another concrete testing milestone. The demo brought together front-end improvements, wallet onboarding, Aragon reliability, feedback tooling, vote restrictions, and migration-vote testing into a more production-like rehearsal of the Hatch experience.
2021-05-04 to 2021-05-10 — Parameters Party Voting Strats
Forum thread: Parameters Party Voting Strats Category: Community Updates Archive theme: Hatch parameter voting, Tokenlog strategy, proposal visibility, consensus sensing, voter education
May 4, 2021
A community update thread was opened to discuss voting strategy for the Hatch parameter process. The post reflected that the parameter vote was moving quickly and that participants were trying to decide how to use their votes effectively.
The thread identified two possible strategies. One strategy was to vote early for a preferred parameter configuration so that it would appear near the top and gain visibility, acceptance, and perceived robustness. Another strategy was to wait until the end, read more of the discussion, observe which proposals were gaining support, and then vote among the leading options so the vote would have more influence on the final outcome.
This made the thread a useful record of how Tokenlog voting created strategic behavior. Participants were not only deciding which parameter configuration they preferred; they were also thinking about timing, visibility, momentum, and whether to vote sincerely early or tactically later.
May 6, 2021
A follow-up expanded the discussion from individual voting strategy to collective sensemaking. The thread raised the possibility of analyzing the submitted parameter configurations with mean, median, or mode calculations to identify consensus patterns across proposals. This could help the community compare many submissions and understand where agreement was already emerging.
The discussion also suggested that the process needed more objective analysis and clearer communication. A short writeup or video explaining the high-level meaning of the parameter choices could help people engage without being overwhelmed. The thread also raised outreach questions, such as whether emails or broader communications should be used to encourage participation before the runoff.
May 10, 2021
A later reply pointed toward a broader explanatory post and suggested that the debates would be a good place for analysis and collective sensemaking. The idea of an email for the runoff was also supported because it would give participants a clear action item.
By the end of the thread, the conversation had moved from voting tactics to process design. It captured the community learning how to vote on complex parameter configurations, how to interpret many competing submissions, and how to support participation through analysis, communication, and structured debate.
2021-05-04 to 2021-05-10 — Evolving Economics via Hatch Param Parties
Forum thread: Evolving Economics via Hatch Param Parties Category: TK log Params / Archive Archive theme: Bottom-up economic design, Hatch parameter parties, Tokenlog, Hatch Config Dashboard, community education, runoff voting
May 4, 2021
A thread was opened to invite the community into the Hatch parameter selection process through a series of Hatch Param Parties. The post framed TEC’s approach as a break from the usual top-down economic design process, where a core team chooses the parameters of an economy before others use it. TEC instead intended to let the community that would use the economy participate in designing its initialization.
The thread connected this process to the earlier mission, vision, and values vote. After choosing TEC’s cultural direction through a decentralized process, the next step was to choose the Hatch configuration. The Hatch parameters would determine the initial token distribution and the acceptance criteria for proposals in the Hatch DAO.
The post encouraged participants to use the Hatch Config Dashboard and Tokenlog together. People could look at existing Hatch Config proposals, open them in the dashboard, and then fork or improve them. This made the parameter process iterative rather than static: participants were expected to experiment, remix, and debate configurations.
The thread acknowledged that the dashboard could be intimidating, so it proposed making economic design social. Hatch Param Parties would create spaces where people could ask questions, play with parameters, listen to music, and learn how the variables interacted. The post framed this as a way to make serious economic design more approachable and sustainable.
The thread then listed a schedule of parameter parties across multiple time zones, followed by dedicated parameter debates. Participants were encouraged to bring their favorite Hatch Config and present it to the community. The plan was for the first round of voting to be counted during a community call, then reviewed for possible vote splitting caused by forks, with the top configurations moving to a runoff vote.
May 10, 2021
A follow-up directed people to an external post for the updated parameter party schedule. This indicated that the original forum thread had become part of a broader communications campaign around the Hatch parameter vote.
By the end of the thread, TEC had turned parameter selection into a participatory civic ritual. The post captured the transition from parameter education to community-wide economic design: contributors were no longer only learning what parameters meant, but gathering to debate, remix, campaign for, and vote on complete Hatch configurations.
2021-05-05 — Macro Hatch Param Discussion
Forum thread: Macro Hatch Param Discussion Category: Archive Archive theme: Hatch parameter proposals, community debate, Tokenlog/GitHub proposal comparison, Commons Upgrade confidence
May 5, 2021
A discussion thread was opened for people to share and debate their preferred Hatch parameter proposals. Rather than focusing on one isolated parameter, the thread invited comparison between full parameter configurations. It functioned as an informal debate space alongside the more formal proposal and voting process.
Participants posted links to their parameter proposals and forked versions of existing proposals. The discussion showed how the community used the Hatch Configuration Dashboard and GitHub proposal flow not only to submit finished choices, but also to remix, compare, and argue for different approaches before voting.
One major theme was how much consensus should be required for the Commons Upgrade. The thread raised the argument that a very high support requirement could protect TEC from moving forward if a large minority opposed the upgrade. In this framing, a successful Commons Upgrade should not merely pass by a thin majority; it should show strong confidence from the Hatch DAO before the community crossed into the next stage.
The thread also surfaced concerns about membership ratios and speculative behavior. If membership requirements were too permissive, someone could potentially obtain enough membership score to participate meaningfully in the Hatch without being deeply aligned with the community. This connected Hatch parameter design back to the earlier concern that the closed Hatch should prioritize mission-aligned participation over pure speculation.
The conversation also showed that different people could choose opposite parameter settings for similar underlying reasons. For example, one proposal might choose a low Hatch Tribute to keep redemption strong, while another might choose a higher setting to reinforce commitment and confidence in the Commons path. This made the thread useful as a record of how parameter choices expressed values, risk preferences, and launch strategy.
By the end of the thread, the community had a lightweight forum space for comparing macro Hatch configurations. It captured the shift from parameter education into parameter campaigning: participants were no longer only learning what each variable meant, but actively advocating for different economic and governance designs for the Hatch.
2021-05-05 to 2021-05-22 — Design Your Economy; Make Your Choice
Forum thread: Design Your Economy; Make Your Choice Category: TEC / Archive Archive theme: Hatch Dashboard guide, parameter education, simulations, GitHub proposal submission, Tokenlog voting, community economic design
May 5, 2021
A Hatch Dashboard guide was published to help the community design and submit Hatch parameter proposals. The thread introduced the dashboard as the tool TEC was using to decide pre-Hatch parameters, compare results, and battle-test configurations before launching the Hatch DAO.
The guide pointed participants toward Param Parties and the TEC calendar, making clear that the dashboard was not meant to be used in isolation. Participants were encouraged to learn from parameter experts, ask questions, and work through the design process with others.
The post then summarized the main Hatch parameters. The first section covered the parameters that shaped Impact Hours and Hatch fundraising: Minimum Goal, Maximum Goal, Target Goal, Hatch Period, Hatch Minting Rate, Hatch Tribute, Membership Ratio, Impact Hour Rate at Target Goal, and Impact Hour Rate at Infinity. This gave participants a practical map of how funding, contributor rewards, token supply, and contribution caps connected.
The second section covered Dandelion Voting initialization: Support Required, Minimum Quorum, Vote Duration, Vote Proposal Buffer, Tollgate Fee, and Rage Quit Delay. This connected the Hatch parameter process to governance design, showing that the Hatch was not only about token distribution but also about the initial decision-making rules for the Hatch DAO.
The guide walked participants through using sliders and input fields, running simulations, reviewing output tables, and interpreting how parameter choices affected builders, backers, TECH minted, and wxDai value. It encouraged people to add explanations for their choices so others could understand the reasoning behind each configuration.
The final step was sharing results to GitHub. Once participants were satisfied with a configuration, they could generate a GitHub issue in the TEC-Hatch-Vote repository containing the details of their Hatch proposal. Other members could then review, critique, comment, or iterate on the proposal before the process moved to Tokenlog voting.
May 10 to May 22, 2021
The thread was automatically bumped several times while the Hatch parameter process was active. This suggests the guide remained useful as a live participation resource during the parameter proposal and voting period.
By the end of the thread, TEC had a practical user guide for bottom-up economic design. The post translated the many parameter deep dives into an actionable workflow: learn the parameters, experiment in the dashboard, run simulations, explain the choices, publish the configuration to GitHub, and prepare for Tokenlog voting.
2021-05-11 to 2021-09-21 — Pre-Hatch Impact Hours Distribution Analysis
Forum thread: Pre-Hatch Impact Hours Distribution Analysis Category: Community Updates Archive theme: Impact Hours, Praise analysis, Hatch preparation, reward distribution, legitimacy, data science, Tokenlog voting, governance initialization, SourceCred
May 11 to May 19, 2021
The thread opened with a concern that the pre-Hatch Impact Hours distribution looked more skewed than expected when viewed through the Hatch dashboard. The initial post argued that the community had established Praise as a way to track and quantify contributions, but had not yet performed enough quality assurance on whether the outputs matched the community’s sense of fair and accurate recognition. The central concern was that many small, frequently praised actions could accumulate more governance power than larger, less visible pieces of work, even when those larger tasks were individually scored higher.
Early responses framed the issue as a tension between fairness, legitimacy, and process continuity. One side emphasized that Impact Hours had become legitimate through participation, transparency, and repeated use: anyone could give praise, join quantification, propose the Impact Hour Rate, and participate in voting if they had earned enough recognition. From that perspective, changing the distribution immediately before the Hatch risked breaking the social contract created by the process. Another side argued that legitimacy could not be reduced to the existence of a process, especially if the process was experimental, untested, and now producing visible distributional effects that the community had not fully understood when earlier decisions were made.
The discussion quickly became a deeper governance debate over whether the community should simply accept the output of an algorithmic recognition process or pause to examine the ruler before using it to initialize governance power. Several posts supported data analysis as a learning exercise even if no intervention ultimately occurred. Others warned that retroactively changing Impact Hours would create distrust, undermine expectations, and introduce interpersonal conflict at the most sensitive moment before the Hatch. By mid-May, the thread had produced a proposal for basic data analysis, a well-advertised community discussion, and a more formal process for deciding whether any intervention should be considered.
May 20 to June 16, 2021
The thread then moved from abstract debate into data work. Contributors began cleaning and standardizing the Praise data, resolving name inconsistencies, discussing identity mapping across Discord, Telegram, GitHub, forum accounts, and wallet addresses, and creating shared repositories, HackMD notes, and spreadsheets. The data work became both a technical exercise and a governance exercise: the community needed cleaner data to understand the distribution, but it also needed shared confidence in the process by which that data would be interpreted.
Several work sessions were organized around Praise analysis, including categorizing contributions, examining distribution patterns, and inviting outside or less-interested data analysts to help reduce bias. The thread explored whether work in the broader Token Engineering field, including work happening outside the TEC’s immediate channels, had been under-recognized because it was less visible to the Praise process. This broadened the question from “who got praised inside TEC?” to “what kinds of labor does this system see, and what kinds of labor does it miss?”
By mid-June, preliminary analysis had surfaced concrete questions about retweets, meetings, contribution categories, Gini coefficients, possible UBI-style smoothing, paid-contributor deductions, and the treatment of less visible foundational work. One analysis found that retweets made up a noticeable share of praise instances but a smaller share of total Impact Hours, while other work began to test hand-labeling and categorization methods. The thread increasingly framed Praise as useful but imprecise: good at producing a culture of recognition, but difficult to use as a precise instrument for allocating initial governance power.
June 16 to June 24, 2021
The conversation then turned toward the decision process itself. Community members discussed whether the analysis should only inform future reward system improvements or whether it could justify changing the already quantified Impact Hour set before the Hatch. This became the central split: one path protected continuity and trust in existing agreements, while the other path argued that new information could make it legitimate, even necessary, to adjust the distribution.
The decision space expanded into possible intervention categories. Proposed areas included restoring some governance power to paid contributors whose Impact Hours had been heavily reduced, using category analysis to address over- or under-represented types of work, exploring UBI or Gini-based smoothing, and acknowledging hidden work or legacy contributions. The community also debated how to vote on intervention versus non-intervention without splitting votes unfairly, and whether one-person-one-vote, token-weighted voting, quadratic voting, or capped voting would best reflect the affected stakeholders.
A structured Tokenlog process was then proposed. The community would submit intervention proposals, vote using quadratic voting, and, if no proposal clearly won, move the top proposals into a runoff. In the case of a polarized outcome, the leading proposal authors would be invited to merge their approaches. This transformed the thread from a forum argument into a formal pre-Hatch governance process, complete with dashboards, analysis sessions, proposal templates, and voting timelines.
June 24 to July 8, 2021
As the vote approached, the thread continued to wrestle with the human side of algorithmic governance. Some responses argued that Praise had mixed gratitude and monetary or governance value in a way that made the system emotionally difficult and philosophically confused. Others argued that the practical question remained how to reward contributors with sweat equity in the TEC, and that any reward system would need to balance subjective recognition, quantifiable work, trust, and timing.
The proposal process produced multiple intervention options, including no-intervention style proposals, distribution reshaping, bucket-based approaches, paid-contributor adjustments, and composite augmentation proposals. Voting analysis then became a second layer of the thread. Participants examined raw Tokenlog data, the relationship between voting power and votes cast, how quadratic voting behaved when addresses voted multiple times, and whether a relatively small number of high-power voters could still dominate outcomes. The thread therefore became not only a debate about Impact Hours, but also a live case study in the limitations and tradeoffs of DAO voting tools.
By the runoff stage, the vote had become highly polarized between two major approaches. One approach sought to preserve much of the existing Impact Hour distribution while addressing specific issues such as paid-contributor governance deductions and additional recognition for Token Engineers. The other argued for a broader reshaping of the distribution through activity buckets and equity-oriented adjustments. As the outcome tightened, the discussion shifted toward compromise: rather than let one polarized side win outright, the thread explored a blended result weighted by the support each proposal received.
July 8 to September 21, 2021
After the final voting cycle, the thread documented the compromise. The full voting cycle included 60 unique addresses and 12,920 votes. The top two proposals were close enough that a winner-take-all outcome would have left a large part of the community unsatisfied. The agreed path combined both approaches proportionally: one proposal would affect 52 percent of the Impact Hour distribution and the other would affect 48 percent. The compromise preserved part of the original distribution, included additional recognition from a TE praise party, left open a future proposal around paid-contributor governance restoration, and applied bucket-based distribution logic for the reshaped portion.
The thread also reflected on the emotional cost of the debate. Several participants described the process as difficult, polarizing, and painful, but also as a major learning moment for the Commons. Later comments suggested that future governance should avoid binary voting structures that force polarization and should instead design processes that turn several strong proposals into a negotiated synthesis. The thread became a lesson in how proposal structure, voting mechanics, community psychology, and economic stakes interact.
After the main decision concluded, later comments connected the experience to future reward-system design. Praise was described as useful for acknowledging qualitative contribution, but hard to use as a precise measurement instrument. A later update pointed toward a separate vote to restore a portion of governance rights to people whose rights had been deducted, showing that the Impact Hours debate continued to shape post-Hatch governance. By the end of the thread, the TEC had transformed a legitimacy crisis over initial governance distribution into a data-driven, emotionally intense, but ultimately compromise-oriented governance process that influenced later thinking about Praise, SourceCred, voting design, contributor recognition, and the limits of algorithmic allocation.
2021-05-18 to 2021-05-21 — Hatch Lessons and Moving Forward
Forum thread: Hatch Lessons and Moving Forward Category: Community Updates Archive theme: Hatch parameter voting, process legitimacy, Tokenlog lessons, forked proposals, runoff design, Commons Upgrade preparation
May 18, 2021
A community update was published to reflect on the Hatch parameter process and explain the path forward. The thread described the previous month as an attempt to make history by letting a diverse community propose and vote on the parameters that would initialize a collectively designed token economy.
The post summarized the process. The Hatch Dashboard helped experts, novices, and new participants learn about the parameters that shaped the Hatch DAO. Hatch Parties gave participants guided walkthroughs and encouraged them to submit their own parameter sets. Those proposals were then voted on through Tokenlog by Trusted Seed members. The process produced many events, many parameter submissions, several debate sessions, and thousands of votes.
The initial plan had been to select the top proposals and move them into a final runoff vote, where the winning proposal would become the initialization parameters for the Hatch DAO. After the vote, Community Stewards held a sensemaking meeting to examine the data, review the leading proposals, and determine next steps. The agenda included questions about whether the runoff should be political or apolitical, whether winning parameters should be attributed to individuals, whether memes should be included, whether parameters could be altered, how to make proposals digestible, when the vote should run, and how many proposals should be included.
The thread explained that after the formal meeting ended, the conversation shifted into deeper questions of legitimacy. The group reviewed voting data, compared the top proposals, and noticed that the top three were relatively similar across most parameters. Only a few parameters showed substantial differences. This raised concerns about whether the runoff would actually capture the diversity of design strategies present in the wider proposal set.
The thread identified several lessons. First, the voting structure needed improvement. Tokenlog allowed proposals and voting to happen simultaneously, and once votes were cast they could not be changed. This became frustrating when new attractive proposals appeared later. Quadratic Voting helped distribute influence more representatively, but it did not prevent votes from being spent on proposals that had no chance of reaching the final round. The thread raised ranked-choice voting as a possible future improvement, while acknowledging that the community did not yet have the technical capability to implement it directly.
Second, the thread examined the effects of forked proposals. The ability to fork proposals was valuable for education and participation because people could start from existing configurations and adjust them. But it also created many similar proposals, split votes across related options, and made it difficult to know whether results reflected true design preference, presentation, popularity, or small variations between forks.
Third, the thread addressed legitimacy. Changing the process after announcing it could undermine the “Your Economy, Your Choice” principle. At the same time, following the original plan mechanically could produce a runoff that failed to represent meaningful design diversity. The discussion considered whether to remove or replace a leading proposal, include additional proposals, or restart the process entirely.
The final decision was to add the fifth-place proposal into the final runoff while acknowledging that the process had flaws and would need to be improved for the Commons Upgrade. The post framed this not as a failure, but as part of the work of building an economy designed by its stakeholders. The Hatch parameter process had revealed what needed to be improved before the next major governance design process.
May 18 to May 21, 2021
Follow-up responses recognized the value of the reflection and the importance of learning from the process. The thread stood as a postmortem and transition document: it celebrated the participatory achievement of the Hatch parameter process while being honest about its shortcomings.
By the end of the thread, TEC had documented one of its most important governance lessons. Bottom-up economic design created legitimacy, education, and participation, but also required careful process design around proposal timing, vote mutability, forks, runoff criteria, voter education, and representative outcomes. These lessons were explicitly carried forward into the upcoming Commons Upgrade process.
2021-05-20 to 2021-06-01 — How Do the Hatch Param Proposals Stack Up?
Forum thread: How do the Hatch Param Proposals Stack up? Category: The Hatch / Archive Archive theme: Hatch parameter runoff, proposal comparison, Tokenlog voting, economic democracy, parameter education, final pre-Hatch decision-making
May 20, 2021
A comparison thread was published during the final stretch of the pre-Hatch phase to help the community understand the remaining Hatch parameter proposals. The thread announced that the Hatch runoff vote had been extended to June 1, giving participants more time to review the final options and cast votes through Tokenlog.
The post framed the previous month as a community-wide economic design process. People had designed, debated, forked, and voted on Hatch configurations, producing several major proposal families and a final runoff between the top proposals. The thread treated this as economic democracy in practice: the community was not merely approving a prebuilt system, but choosing the parameters that would shape the initial TEC economy.
The thread also invited people to debate parties where the four final proposals could be discussed in more depth. These events were positioned as a final chance to become informed before voting. The post linked back to the Tokenlog quadratic voting guide for anyone who needed help understanding how to participate.
The main body of the thread compared the four final Hatch proposals across several dimensions. It listed the minimum, maximum, and target funding goals; the share of total supply minted for backers at different funding levels; the Impact Hour Rate; the percentage of funds that backers could redeem through Rage Quit; the distribution of control over wxDai between backers, builders, and the non-redeemable Hatch Tribute; the membership ratio and maximum contribution capacity; support and quorum settings; vote duration and execution time; and the combined anti-spam effect of the Vote Proposal Buffer and Tollgate Fee.
The thread’s most important function was translation. It took complex parameter sets from GitHub issues and dashboards and made them easier to compare side by side. Instead of asking voters to judge isolated numbers, the post showed how each proposal would affect backers, builders, redemption rights, governance thresholds, contribution limits, proposal spam resistance, and control over Hatch funds.
By the end of the thread, TEC had a final voter-education artifact for the Hatch parameter runoff. The thread connected the earlier deep dives, dashboard simulations, proposal parties, GitHub proposals, and Tokenlog voting process into a side-by-side comparison designed to help voters make an informed choice before the Hatch.
2021-06-03 to 2021-06-07 — Using Celeste as TECommons Arbitrator
Forum thread: Using Celeste as TECommons arbitrator Category: Conviction Voting / Archive Archive theme: Celeste, arbitrator selection, Community Covenant, Disputable Voting, manifesto-based governance, Commons Upgrade
June 3, 2021
A cultural proposal was opened to decide whether TEC should use Celeste as its arbitrator after the Commons Upgrade. The thread explained that the post-upgrade Commons would use Disputable Voting and Disputable Conviction Voting, meaning proposals could be challenged while they were being voted on. If a challenge occurred, an arbitrator would decide whether the proposal should be canceled or allowed to continue based on the TEC Community Covenant.
The proposal framed this as a major governance decision. TEC needed to decide both what kind of Community Covenant it wanted and what arbitrator should interpret that covenant. Choosing Celeste would make TEC a manifesto-based organization where hard governance decisions made through token-holder votes would be constrained by soft governance agreements expressed in the covenant.
The thread explained the purpose of an arbitrator in DAO governance. Since token governance can be bought or captured, an arbitrator could help prevent whales or majority coalitions from funding proposals that violated the community’s values. It could also defend against classic DAO 51 percent attacks where a majority votes to move all funds into a new structure they control. In this framing, Celeste would act as a decentralized legal layer on top of TEC’s smart contract governance.
The proposal also acknowledged the risks. Using Celeste would shift some power away from TEC token holders and toward Celeste keepers. The thread asked whether this could allow outside actors to block TEC proposals. The answer given was that Celeste keepers are supposed to rule according to each DAO’s covenant, not according to their own values. The covenant remains the responsibility of the DAO, and both the arbitrator and covenant could later be changed by community vote, although those changes could themselves be challenged under the existing covenant.
The proposal argued that Celeste could provide the benefits of a decentralized admin or court-like service without concentrating censorship power in a committee chosen by the DAO. It also connected TEC more deeply to the 1Hive Gardens ecosystem, making TEC compatible with future tools developed for Gardens while maintaining TEC’s special Augmented Bonding Curve token policy.
The implementation path was described as participatory. If the proposal passed, TEC would decide Celeste parameters and the Community Covenant through a process involving soft governance, Gravity, and Commons Swarm. The resulting arbitrator choice would then be included in the Commons Upgrade vote.
June 7, 2021
A final reminder was posted before the vote closed. Later that day, the voting round closed and the proposal was approved.
By the end of the thread, TEC had approved the use of Celeste as its proposed arbitrator for the Commons Upgrade. The thread marked an important moment in TEC governance design: the community chose to pair token-holder voting with covenant-based dispute resolution, using Celeste to help enforce the values and agreements that token votes alone could not reliably encode.
2021-06-10 to 2021-08-06 — Credential Management
Forum thread: Credential management Category: Advice Process Archive theme: credential management, password sharing, access permissions, security practices, admin roles, audits, DAO operational security
June 10, 2021
An advice process thread was opened to discuss how TEC should manage credentials and access to shared platforms. The starting point was a concern that the existing practice of sharing credentials through Keybase and tracking access manually could become risky as the organization grew. A credential manager was proposed as a possible temporary solution because it would allow access to be shared or revoked without repeatedly sharing passwords directly.
The thread framed credential management as a tension between security, access, decentralization, and bureaucracy. On one side, better tooling could improve security, make it easier to revoke access when contributors became inactive, and reduce risk if conflicts or Code of Conduct issues emerged. On the other side, credential management could centralize power, add process overhead, and still leave contributors with significant practical control once access had been granted.
The discussion then expanded beyond a single tool into a broader question of access governance. It asked how many admins were really needed across Discord, GitHub, GitBook, and other platforms; how access requests should be approved; whether a request form and short objection period would be too bureaucratic; and how TEC could balance operational speed with security.
June 11 to June 20, 2021
Follow-up discussion emphasized that the organization needed to map its current security and access structure before making major changes. The thread surfaced concerns that TEC was not yet using enterprise-level security practices, that shared or consumer-grade tools created risks, and that the organization needed clearer standards for two-factor authentication, named accounts, service accounts, admin permissions, contributor access, and auditability.
A layered access model was proposed, distinguishing top-level super admins, admins or stewards, provisional admins, general editor users, and ordinary community members. The purpose was to clarify who should have what kind of access, how sensitive accounts should be protected, and which roles should require stronger identity validation and two-factor authentication.
The thread also proposed practical habits regardless of which tool was chosen: recurring audits of who had access, security best practices for members, better documentation in GitBook, and clearer rules for each platform. It also recognized a real contributor-experience issue: people could be blocked from doing useful work if they did not have timely access to the tools or information they needed.
August 6, 2021
The thread later returned to the broader risk-management question. Instead of choosing a tool first, the discussion suggested identifying the specific failure modes TEC was trying to prevent, such as inactive credential holders, compromised machines, unclear permissions, or excessive reliance on shared accounts. It also argued that security changes should remain as simple as possible because unnecessary complexity can create new attack surfaces and governance confusion.
By the end of the thread, credential management had become a larger discussion about DAO operational security. The thread connected password managers, access revocation, admin roles, 2FA, platform permissions, audits, service accounts, contributor onboarding, decentralization tradeoffs, security culture, and formal decision-making into one operational challenge: how TEC could stay open and contributor-friendly while protecting shared infrastructure and sensitive accounts.
2021-06-16 to 2021-12-07 — Pseudo-Code and Permission Tables for the Commons Upgrade
Forum thread: Pseudo-code and permission tables for the Commons Upgrade Category: ABC / Archive Archive theme: Commons Upgrade, permission tables, EVM scripts, Gardens, ABC reserve, bonding curve, migration tools, EVM-Scripter, Hardhat
June 16, 2021
This technical thread documented how a Gardens DAO could be transformed into a Commons through the Commons Upgrade. It began with a default Gardens permission table and then described the permissions that would need to change when the TEC moved into its full Commons architecture.
The proposed Commons Upgrade script would install and initialize a new agent for the ABC reserve, install and initialize the bonding curve, install and initialize migration tools, add bonding curve and migration permissions, disable issuance by removing permissions, and add wxDai as a collateral token with a reserve ratio. The resulting Commons permission table showed how authority would shift from the original Gardens token toward the TEC token, with Disputable Voting managing high-authority permissions and Conviction Voting controlling proposal funding flows.
The thread was important because it made the Commons Upgrade concrete. The upgrade was not only a social vote or economic parameter choice; it was a sequence of contract installations, permission grants, permission revocations, token-manager changes, migration-tool roles, and reserve-agent capabilities. An edit later clarified that the design had been simplified to use one disputable voting instance and a third agent instead of a vault.
June 22 to July 4, 2021
A follow-up shared a preview of an EVM-Scripter library that Commons Swarm was building to make EVM scripts more manageable. The example showed how the Commons Upgrade vote could be constructed programmatically: connect to the DAO, install the new agent, install the market maker, install migration tools, add permissions, revoke dynamic issuance permissions, and call the bonding curve to add the collateral token.
Responses welcomed the clarity of the API and the value of seeing technical posts that exposed how the upgrade would work. The thread therefore doubled as both implementation planning and community education, showing the permission architecture behind the governance process.
December 7, 2021
A final update pointed to an updated version of the script in a Commons Swarm GitHub repository using Hardhat to upgrade a Garden into a Commons DAO. By the end of the thread, the Commons Upgrade had evolved from permission-table planning and pseudo-code into a more formal implementation repository, preserving the technical path from Gardens infrastructure to TEC’s ABC-backed Commons.
2021-06-17 to 2021-07-04 — The Hatch Live Data
Forum thread: The Hatch Live data Category: Ideas / Archive Archive theme: Hatch communications, live dashboard, launch momentum, public data, community updates, website metrics
June 17, 2021
An idea thread was opened around how TEC should communicate live data during the Hatch. The thread argued that communication would be critical during the launch period, even though Hatch participation was limited to Trusted Seed members and people close to the project. The concern was that the broader community still needed to understand how the Hatch was progressing and feel the momentum of the collective effort.
The thread framed the Hatch not only as a technical or financial process, but as a social moment. People respond to signals, sentiment, and visible progress. Showing how the community was moving toward the minimum goal, target goal, and beyond could help build confidence and energy around the launch.
The proposal suggested creating a communications group to decide what data should be shared, how it should be presented, when updates should be posted, and where the information should live. The thread emphasized that the data should be communicated in an engaging, graphical way so that even people who could not contribute directly could still follow the process, amplify it, and influence potential Hatchers.
June 19 to July 4, 2021
Follow-up discussion suggested creating a dedicated Hatch page on the website. Possible live metrics included the number of Hatchers committed, percentage progress toward the minimum goal, percentage progress toward the target goal, the maximum goal, time left until the Hatch closed, transaction history, and a Twitter feed around a Hatch hashtag.
A later response suggested pairing website updates with regular Telegram summaries, possible tweets, pinned messages, and clear community guidance about where to find the latest update before and during the Hatch. This emphasized the need for a single reliable source of truth and a predictable communications rhythm.
By the end of the thread, TEC had identified live Hatch data as an important launch communications need. The discussion connected dashboards, website pages, transaction history, social media updates, Telegram summaries, pinned announcements, and momentum-building into one communications strategy for making the Hatch visible and emotionally legible to the community.
2021-05-24 to 2022-04-27 — Electric Circus: Game-Based Ecosystem Valueflows Course
Forum thread: Electric Circus - Game-based version of Ecosystem Valueflows course Category: Conviction Voting / Archive Archive theme: Ecosystem Valueflows, game-based learning, token model generation, participatory design, simulations, Miro prototype, education tooling
May 24, 2021
This Conviction Voting thread introduced Electric Circus, a proposed game-based version of the Ecosystem Valueflows course. The proposal aimed to make it easier for diverse communities to create a game or dynamic-system model of their ecosystem, either asynchronously or synchronously. The intended benefit was to help communities document assumptions, co-create with stakeholders, and run game-based simulations that could inform token model generation.
The proposal framed Electric Circus as both an education product and a design tool. It would make the Ecosystem Valueflows course more accessible to distributed teams and larger ecosystems that could not easily attend sparse live course offerings. It would also support token engineers working inside their own ecosystems, especially where participatory design and co-creation mattered more than having a system designed by only one or a few experts.
The planned work included a playable Miro prototype over roughly three weeks, followed by a longer implementation phase. The prototype would also serve as a specification for later development. The requested funding was approximately 75,000 DAI, with a rough split across design, play-testing, and development. The proposers described themselves as designers of the Ecosystem Valueflows course and its game-based content, with experience in knowledge-management systems, game-based systems, and token engineering course design.
May 25 to May 26, 2021
Early replies supported the idea, especially for people who had missed prior Valueflows offerings or who had real ecosystem use cases but only moderate technical skills. A follow-up exchange connected the proposal to a movement-building ecosystem trying to map complex social, cultural, and organizational value flows across many groups. This grounded the proposal in a concrete use case: helping a network-of-networks understand itself well enough to design shared funding, coordination, and token systems.
April 27, 2022
Nearly a year later, the thread was revived with a call for intrinsically motivated designers and developers. The update suggested that the idea remained valuable, but that coordination would be too difficult without people who were strongly motivated to help design and build it.
By the end of the thread, Electric Circus had been framed as a potential bridge between token engineering education, ecosystem mapping, participatory design, game-based simulation, and real-world community coordination. The project did not appear to move directly into implementation through the thread, but it captured a recurring TEC theme: making token engineering methods more accessible by turning abstract system modeling into collaborative, playful, and practical learning tools.
2021-06-17 to 2021-06-27 — cadCAD Education Working Groups
Forum thread: cadCAD education working groups! Category: Conviction Voting / Archive Archive theme: Funding proposal, cadCAD education, token engineering training, study groups, peer learning, modeling literacy
June 17, 2021
A funding proposal was submitted to coordinate weekly cadCAD study sessions for the TEC community. The proposal aimed to guide new and aspiring token engineers through existing cadCAD educational content, making the material more accessible through structured peer learning rather than leaving people to navigate it alone.
The proposed curriculum included several modules. The first was a short cadCAD bootcamp intended to help beginners and non-technical participants work through engineering design, systems thinking, Python basics, and the cadCAD education modules. A second module would take participants through the Robots and Marbles tutorial. A third week would operate like a reading group, with small teams studying foundational papers on cryptoeconomic systems, systems engineering, or economic games and sharing what they learned.
The later modules moved from study into practice. Participants would fork and modify existing cadCAD models, then eventually create their own models. The proposal treated this as a progression from guided learning, to modification, to original modeling work. Bonus sessions would involve Q&A with cadCAD education contributors, with recordings made available publicly.
The proposal framed the work as a response to a major bottleneck in token engineering: the limited supply of people who can actually perform modeling and systems analysis. It argued that token engineering is not the work of isolated superhuman generalists, but of coordinated groups with different backgrounds who need a shared language. cadCAD was presented as one important piece of that shared language because it helps encode and simulate generalized dynamical systems.
The expected outputs included not only weekly sessions but also reusable learning resources: FAQs, common bugs, common installation issues, and other materials that would help future onboarding into token engineering. The requested funding was relatively small and intended to compensate preparation, course maintenance, and session facilitation for an eight-week cohort.
June 20 to June 27, 2021
Follow-up discussion supported the proposal and connected it to broader token engineering education efforts. The study groups were described as a natural next step after ecosystem value-flow courses, and as a potential complement to peer-learning platforms. The thread also emphasized the importance of helping non-technical or becoming-technical participants gain programming, GitHub, and modeling confidence.
By the end of the thread, TEC had a proposal for turning cadCAD education into a community learning pathway. The thread connected modeling literacy, peer learning, token engineering capacity building, study groups, reusable onboarding materials, and the broader need to create a common language across the token engineering field.
2021-06-19 to 2021-06-27 — TEC Working Groups Weekly Update, June 18
Forum thread: TEC Working Groups Weekly Update, June 18 Category: Community Updates Archive theme: Working group updates, Hatch readiness, cross-team coordination, community communications, operational transparency
June 19, 2021
The first weekly Working Groups update was published to give the TEC community a consolidated view of activity across the organization. The post invited people to join working group calls for real-time updates, but also created a written summary for anyone who could not follow every channel or meeting.
The update showed how many parallel workstreams were active as TEC approached the Hatch. Communications had launched Token Engineering Scouts as a liaison effort between TEC and other ecosystem organizations, published walkthrough material, and prepared outside guest content. Commons Swarm was focused on TEC becoming a 1Hive Garden with the Augmented Bonding Curve as its special feature, and pointed people toward the Gardens demo.
Gravity reported work on nonviolent communication, upcoming decolonization-oriented discussion, conflict support pathways, process improvement surveys, and the time-off/offboarding process. Hatch Outreach emphasized that Impact Hours not associated with Trusted Seed membership would be irredeemable from the first day of the Hatch, reported progress contacting Impact Hour holders, and noted that most higher-IH contributors had activated Trusted Seed membership.
Labs reported modeling work around Conviction Voting, continuous issuance, and bonding curve buy/sell impacts. It also described crossover sessions where people from ecosystem value-flow programs could present projects to mathematicians and systems modelers. Praise analysis continued, including work on an interactive dashboard for exploring Praise data.
Legal reported that final parameters had been added to legal documents, covenant work had begun, and documentation for SourceCred and Celeste implementation was under review. 0mega reported work on TE Consilience and the Ethos of Token Engineering. Params reported progress on the Commons Configuration Dashboard, including design validation and a Python backend.
Soft Gov focused on next steps for Praise analysis. Stewards reported that the organization was counting down to the Hatch and tracking each working group’s readiness. The post also gave a snapshot of TEC at that moment: fifteen Stewards, eleven working groups, and more than four hundred contributors. Transparency reported work on platform-specific code of conduct documentation and recording infrastructure for Discord calls.
June 19 to June 27, 2021
Follow-up replies appreciated the summary, corrected a broken link, and reinforced that the community was getting closer to Hatch readiness. The responses also showed that the update format was useful for people who felt lost in the volume of weekly activity.
By the end of the thread, TEC had created a working-groups digest format for operational transparency. The post captured the organization in the final approach to the Hatch: many teams were active at once, legal and governance infrastructure were being finalized, contributor onboarding and membership readiness were being tracked, modeling and dashboard work were progressing, and Stewards were coordinating the final green lights needed before launch.
2021-06-20 — TEC Hatch and Commons Upgrade
Forum thread: TEC Hatch and Commons Upgrade Category: Welcome to the TEC / Archive Archive theme: Hatch, Commons Upgrade, Hatcher onboarding, Trusted Seed, Impact Hours, TECH, TEC, Augmented Bonding Curve, Conviction Voting
June 20, 2021
This thread served as a foundational orientation document for the TEC after the Hatch had succeeded and the community was moving toward the Commons Upgrade. It opened by stating that the TEC had completed the Hatch process and was now in the next phase, then reframed the post as a step-by-step guide for becoming a founding member and understanding the transition from HatchDAO to Commons.
The thread described the TEC as an emerging engineering society for token engineering, aspiring to become a Schelling point for the field and to support public-goods funding through a regenerative token economy. It explained that Hatchers were founding members who helped initialize the bonding curve and received significant governance rights over the future economy. The Hatch was intentionally closed so that early governance power would go to people aligned with advancing token engineering rather than pure speculators.
The onboarding path emphasized the Trusted Seed, Trusted Seed membership, Impact Hours, Praise, and participation in learning and proposal work. Prospective Hatchers were asked to apply to the Trusted Seed, activate membership, earn Impact Hours through contributions, learn about the TEC, and help choose or iterate on mission, vision, values, and Hatch parameters. The post connected reputation, legal protection, contribution records, and governance rights into one process for forming the initial community.
The thread then explained the two-phase deployment. Phase One was the HatchDAO: members would check their CSTK score, configure xDai and wxDai, send funds to the Hatch, receive TECH, and retain ragequit rights over the redeemable pool. Impact Hours would also convert into TECH at the end of the Hatch through the Cultural Build Tribute. Phase Two was the Commons Upgrade: the community would use the Commons Configuration Dashboard to design the TEC economy, TECH holders would choose parameters, and the Hatch DAO would vote on whether to upgrade into a full Commons.
The Commons Upgrade was presented as a meaningful governance choice rather than a foregone conclusion. If ratified, funds would move into the smart contracts that made up the TEC, TECH holders would receive TEC, TEC would be collateralized by an Augmented Bonding Curve, and the Commons would use Conviction Voting to allocate funds. If the vote failed, the Hatch DAO could remain a simpler DAO structure.
By the end of the thread, the TEC’s transition plan had been summarized in one place: a values-aligned founding community, a closed Hatch to establish accountable governance power, Impact Hours as recognition of cultural work, TECH as the temporary Hatch governance token, and TEC as the future Commons token supported by the ABC and Conviction Voting. The post framed the economy as secondary to the social layer, with the real goal being to coordinate and sustain the token engineering community.
2021-06-20 to 2021-06-25 — Universal Python Library for TE Models
Forum thread: Universal Python Library for TE Models Category: Conviction Voting / Archive Archive theme: Funding proposal, token engineering models, Python library, reusable components, cadCAD compatibility, model interoperability, open-source standards
June 20, 2021
A funding proposal was submitted to create a universal Python library for token engineering models. The thread argued that token engineering needed a shared library of reusable DeFi and governance components, and that TEC could become an important steward of this emerging standard if it organized existing models into a package that token engineers could install and use.
The proposed library imagined a future where common token engineering components such as Praise, Augmented Bonding Curves, Conviction Voting, continuous issuance, multisigmoid functions, cashflow models, and skill trees could be imported directly into Python environments. The goal was not to build another simulation framework, but to create a modular modeling framework whose components could be used inside simulation tools such as cadCAD or TokenSPICE.
The thread proposed using parameterized Python classes as a standard way to implement token engineering components. This would allow model parameters to be declared clearly, validated, documented, serialized, and reused. In this framing, models would become modular building blocks that could be connected, inspected, and passed into larger simulations.
A more ambitious architecture was also proposed. Instead of one monolithic repository, the library could function like a bootloader or registry of model repositories. A netlist could point to different repositories containing models from TEC, Commons Stack, 1Hive, Longtail Financial, TE Academy, or other ecosystem projects. The library could clone those repositories, verify their hashes, and potentially record model authorship or provenance. This would create a network of models rather than a single closed package.
The proposal emphasized interoperability. If smart contract inputs and outputs could be mapped to Python class inputs and outputs, token engineers could model systems as interconnected components and study how they behave together. The example showed how controllable and uncontrollable models could be combined inside a cadCAD simulation, with different systems interacting through shared metrics, market assumptions, and state updates.
The proposal requested funding for a short implementation sprint to organize existing work, create the modular library structure, make the models highly available, and compensate contributors through a vault based on hours logged, commits pushed, and models authored.
June 20 to June 25, 2021
Follow-up discussion emphasized that the most valuable part of the proposal was interoperability. If model components could be standardized and connected, tokenomic systems could be modeled and visualized more easily as networks of small, reusable pieces.
Another follow-up connected the idea of model hashing and attribution to broader work on digital content distribution and value flow. The thread suggested that if token engineering models became shared digital artifacts, their creators might need attribution and reward mechanisms similar to those being explored for educational content.
By the end of the thread, TEC had a proposal for turning scattered token engineering models into reusable open-source infrastructure. The discussion connected Python packaging, parameterized classes, model registries, hash-based provenance, cadCAD compatibility, component interoperability, authorship recognition, and the possibility of TEC becoming a standard source of token engineering modeling tools.
2021-06-24 to 2021-07-06 — TEC Hatch Rehearsal Implementation Specification
Forum thread: TEC Hatch Rehearsal Implementation Specification Category: Dandelion Voting / Archive Archive theme: Hatch rehearsal, implementation specification, Dandelion Voting, TESTTECH, Hatch DAO deployment, permissions, launch readiness
June 24, 2021
A technical implementation specification was published for the TEC Hatch Rehearsal DAO. The thread explained that TEC intended to launch first as the Hatch DAO and potentially upgrade later into a full Commons with an Augmented Bonding Curve and Conviction Voting. This document focused only on the initial Hatch DAO deployment, not the later Commons Upgrade.
The specification described the Hatch DAO as having two main phases. First, during the Hatch, funds would be sent into the DAO and Hatch tokens would be minted. After the Hatch, the DAO would be live and token holders would be able to vote on how to use the funds to advance the mission. The rehearsal DAO used real money, but the document emphasized that it was only a test and that no future expectation should be attached to it.
The governance structure gave Hatch token holders collective and individual control over the funds sent to the Hatch. Token holders could use Dandelion Voting to control funds in both redeemable and non-redeemable agents, vote to upgrade the smart contract system, and redeem tokens for a proportional share of the redeemable pool as long as they had not voted yes on a pending proposal.
The thread then specified the application configuration. The TESTTECH token was non-transferable and controlled by the Hooked Token Manager. Dandelion Voting was described as “god-mode” inside the Hatch DAO because it controlled nearly everything, including fund use and smart contract permissions. The rehearsal used high support requirements, quorum, vote duration, proposal buffer, and rage quit delay settings. A Tollgate controlled the cost of creating Dandelion Voting proposals.
The Hatch configuration defined minimum, maximum, and target goals, Hatch period, minting rate, and Hatch Tribute. The Hatch Oracle limited how much each address could contribute based on membership score tokens. The Impact Hours app handled the Cultural Build Tribute, minting Hatch tokens to people who had earned Impact Hours during the cultural and technical build process.
The specification also described the two Agent applications. The non-redeemable pool held funds set aside to advance token engineering and was controlled by Dandelion Voting. The redeemable pool held funds used to create the TEC economy and could be redeemed pro rata by Hatch token holders. The Redemptions app enabled those token holders to burn tokens in exchange for their proportional share of redeemable funds.
Finally, the thread listed the planned permissions in detail. These permissions showed which apps could manage other apps, transfer funds, open and close the Hatch, mint and burn tokens, migrate funds, create votes, change voting parameters, and enforce restrictions such as contribution limits and vote-related redemption locks. The specification clarified how Hatch Oracle and Dandelion Voting oracles were used to control access to certain actions.
July 6, 2021
A later edit corrected one permission detail: the Hatch contract did not need the token mint role; the Impact Hours app needed it instead. This showed that the rehearsal specification was being actively reviewed and refined before the real deployment.
By the end of the thread, TEC had documented the technical structure of its Hatch rehearsal in a way that connected governance rights, token configuration, Dandelion Voting settings, Hatch parameters, membership-score contribution limits, Impact Hours rewards, redeemable and non-redeemable pools, redemptions, migration tools, and app permissions. The thread served as a launch-readiness artifact for testing the Hatch DAO before the real Hatch.
2021-06-25 to 2021-06-29 — Upala: Price of Forgery Digital Identity
Forum thread: Upala - price of forgery digital identity Category: Conviction Voting / Archive Archive theme: Funding proposal, digital identity, proof of personhood, anti-Sybil systems, forgery cost, MultiPassport app
June 25, 2021
A funding proposal was submitted for Upala, a proof-of-personhood and digital identity system. The thread described Upala as a way to assign human uniqueness scores to user accounts, with the score valued in dollars and interpreted as the cost of forging the account. Rather than treating identity verification as a binary pass/fail status, the proposal framed identity as a measurable economic signal based on the cost of attack.
The proposal argued that Upala could provide dApps with clearer metrics about how much a user values their identity. Existing anti-Sybil systems such as BrightID, Idena, Proof of Humanity, SMS checks, CAPTCHAs, GitHub membership, and other verification methods could use Upala as an additional incentive and quality-control layer. In this model, different human-verification methods could become part of a broader economic identity system.
The specific funding request focused on building the front end, called the MultiPassport app. The app would let users create an Upala ID, monitor their scores across groups, and delete their ID for money if they chose to forfeit or “break bad,” which was described as part of the protocol’s mechanism design. The broader roadmap included smart contracts, user-facing tools, dApp libraries, group manager tools, storage, and audits.
The thread connected the proposal to token engineering by emphasizing the importance of reliable anti-Sybil systems for voting, universal basic income, advertising, lending, and quadratic funding. If identity systems became stronger and more economically legible, quadratic funding could become fairer, lending systems could use identity as a form of collateral, and decentralized applications could open new use cases beyond crypto-native contexts.
The proposal also framed decentralized identity as a major societal infrastructure question. Because identity is sensitive and powerful, the thread warned that failing to build it carefully could result in control shifting to the wrong entities. Grants and public-good funding were presented as important because identity infrastructure should not be shaped only by private or centralized interests.
June 28 to June 29, 2021
Follow-up discussion welcomed the proposal to the forum, and the proposal author clarified that it should be treated as a draft and invited feedback from the community.
By the end of the thread, Upala had been introduced to TEC as a draft funding proposal for anti-Sybil and digital identity infrastructure. The discussion connected proof of personhood, forgery cost, incentive design, dApp identity metrics, quadratic funding fairness, lending, UBI, and the political importance of decentralized identity into one proposal.
2021-06-28 — TEC Working Groups Weekly Update, June 28
Forum thread: TEC Working Groups Weekly Update, June 28 Category: Community Updates Archive theme: Working group updates, Hatch rehearsal, Commons configuration, Praise analysis, legal readiness, transparency, operational coordination
June 28, 2021
A second weekly Working Groups update was published to summarize the prior week of TEC activity as the organization moved closer to the Hatch. Like the earlier update, it gave community members a single place to catch up across multiple working groups without needing to attend every call.
Communications continued the Token Engineering Scouts work, maintaining a recurring hack session as a bridge between TEC and the wider token engineering ecosystem. Commons Swarm reported a new Hatch rehearsal, ongoing refinement of Conviction Voting and bonding curve models, work on an EVMScripter library, and frontend improvements to the conversion interface.
Gravity reported a session on decolonization, while Hatch Outreach repeated the operationally important reminder that Impact Hours not associated with Trusted Seed membership would be irredeemable from the first day of the Hatch. Scholarship availability for membership dues was also highlighted.
Labs reported the kickoff of TE Services and pointed to Praise analysis materials, including dashboards and explanatory videos. The update emphasized that the Praise analysis data was complicated and that no single measurement could capture all dimensions of contribution, fairness, decentralization, compensation, or task value. This showed the community trying to interpret contribution data carefully rather than treating metrics as simple truths.
Legal reported work on the Covenant, consideration of third-party service posting terms, and review of legal documents so everything would be ready for the Hatch. 0mega reported work on a manifesto, TE Consilience, a Common Knowledge Hub, the Ethos of Token Engineering, research methods, and questions around who owns token engineering ethics. The update described an effort to turn working group meetings into focus groups or participatory research on TE ethics.
Params reported continued work on the Commons Configuration Dashboard, including design validation and the Python backend. Soft Gov summarized the June 22 Praise analysis presentation and the creation of Praise dashboards. It also recorded a timeline for the Praise analysis process: proposal submissions and voting would close July 1, runoff proposals would begin July 2, runoff submissions and voting would run July 2 to July 6, and the Hatch would begin the following week.
Transparency reported a credential-management discussion and a rundown of working group transparency levels. Together, these updates showed TEC continuing to finalize not only the technical and legal pieces of the Hatch, but also the social, ethical, data, and process infrastructure surrounding it.
By the end of the thread, the weekly update format had become a useful operational snapshot. This entry captured TEC in the final stretch before the Hatch: rehearsals were underway, dashboards and backend systems were being refined, Praise analysis was becoming part of launch readiness, legal documents and covenant work were progressing, and working groups were being coordinated through visible weekly reporting.
2021-07-03 — TEC Working Groups Weekly Update, July 3
Forum thread: TEC Working Groups Weekly Update, July 3 Category: Community Updates Archive theme: Working group updates, Hatch countdown, EthCC, Hatch testing, Impact Hour outreach, SourceCred distribution, pre-Hatch analysis runoff
July 3, 2021
A weekly Working Groups update was published as TEC entered the final approach to the Hatch. The update announced that TEC would be present at EthCC in Paris later that month, showing that the project was beginning to connect the internal Hatch process with broader ecosystem visibility.
Communications reported that Hatcher campaign content was being finalized, a community video was coming, Token Engineering Scouts were moving forward, and a practical guide on getting wxDAI was highlighted. Commons Swarm reported a 47-hour Hatch test over the weekend, requested feedback, asked for comments on the EVMScripter API specification, and described progress on the conversion interface with a new contract, entry and exit tributes, virtual supply and balance, and a minimum return amount.
Gravity hosted a discussion on equality versus equity. Hatch Outreach reported the results of the Impact Hour outreach campaign, noting that a large share of contributors with significant Impact Hours had joined the Trusted Seed. The group was also finishing the Hatch Handbook and preparing to wind down at the end of the Hatch period, with a post-Hatch social call planned to celebrate the close.
Labs continued work on TE Services, Praise analysis, TEC Labs, and Sunday hack sessions. Legal continued work on the Community Covenant and reviewed legal documents before the Hatch. 0mega continued work on TE Consilience, the Common Knowledge Hub, the Ethos of Token Engineering, and research methods. Params continued work on the Commons Configuration Dashboard.
Soft Gov reported the first SourceCred distribution and summarized the pre-Hatch Impact Hours Distribution Analysis process. Proposals had been submitted and voted on, the voting period was extended by community request, four proposals were selected for a runoff, and voting would remain open until July 6. The update linked to the four runoff proposals, showing that contributor reward analysis remained one of the final unresolved pieces before the Hatch.
Stewards reported that TEC was nearly ready. Pending final results from Soft Gov and Commons Swarm, the Hatch could begin as early as the following week. Transparency continued credential-management discussions and work on platform-specific code of conduct documentation.
A follow-up response expressed excitement for the Hatch. By the end of the thread, the weekly update captured TEC on the edge of launch: technical rehearsals were active, Hatch campaign content was nearly ready, legal and covenant work was being finalized, Impact Hour outreach and reward analysis were moving through final votes, and Stewards were waiting for the last working group green lights.
2021-07-04 to 2021-08-12 — Virtual Supply and Virtual Balance
Forum thread: Virtual Supply and Virtual Balance Category: Advanced CCD Parameters / Archive Archive theme: Advanced Commons Configuration Dashboard parameters, Augmented Bonding Curve, virtual supply, virtual balance, reserve balance, token supply, economic mechanism design
July 4, 2021
An advanced Commons Configuration Dashboard parameter thread was published to explain Virtual Supply and Virtual Balance within the Augmented Bonding Curve. The post described these parameters as projected values that the bonding curve can use instead of the actual token supply or reserve balance. In other words, the real reserve balance or token supply could differ from the values used in the curve’s calculations.
The thread explained that Virtual Supply represents an inflated or deflated projection of token supply attributed to the bonding curve, while Virtual Balance represents an inflated or deflated projection of the reserve balance. These parameters could be useful when a commons wanted to partition, manipulate, earmark, or withdraw parts of the reserve or supply without letting those changes directly affect the curve’s pricing calculations.
The post gave several possible use cases. A commons might earmark part of the reserve for future savings or investment strategies, stream funds out of the bonding curve into another pool, or mint non-transferable vested governance tokens without letting those tokens affect the ABC’s calculations. The thread also warned that changing these parameters would drastically affect ABC initialization and should only be done by people who fully understood the bonding curve design. The suggested default was to leave them unchanged unless a specific advanced use case required modification.
August 12, 2021
Follow-up discussion explored whether virtual supply could support initial secondary-market liquidity. The idea was that inflating projected supply might lower the reserve ratio, reduce price sensitivity on the curve, earmark funds for liquidity provision, and help the DAO sustain liquidity incentives during periods of volatility. The comment was framed as exploratory mechanism brainstorming rather than a settled recommendation.
By the end of the thread, Virtual Supply and Virtual Balance had been framed as powerful but risky advanced parameters. The discussion connected ABC initialization, reserve accounting, supply accounting, earmarked funds, vested governance tokens, liquidity design, price sensitivity, reserve ratio effects, and secondary-market support into one advanced economic design topic.
2021-07-04 — Conviction Voting: Spending Limit (aka Max Ratio/Beta)
Forum thread: Conviction Voting - Spending Limit (aka Max Ratio/Beta) Category: CCD Parameters / Archive Archive theme: Conviction Voting, Spending Limit, Max Ratio, Beta, Common Pool risk management, proposal funding caps
July 4, 2021
A Commons Configuration Dashboard parameter thread was published to explain the Conviction Voting Spending Limit, formerly known as Max Ratio or Beta. The post defined Conviction Voting as a token-weighted decision protocol where tokens are staked on proposals and voting power accumulates over time.
The Spending Limit was described as the maximum percentage of Common Pool funds that could be withdrawn at one time. Because it is based on the amount remaining in the Common Pool, it acts as a relative cap on spending rather than a fixed currency amount. This means the maximum size of a proposal changes as the Common Pool changes.
The thread explained the central tradeoff. A higher spending limit makes it possible to fund larger proposals and ambitious projects, but also increases the risk that a malicious or poorly designed proposal could extract a large share of the Common Pool. A lower spending limit limits large projects but allows more smaller proposals and slows the overall rate at which the Common Pool can be spent. The suggested range was five to forty-five percent, with Conviction Growth and Minimum Conviction named as related parameters.
By the end of the thread, the Spending Limit had been framed as a funding-safety parameter for Conviction Voting. The discussion connected large-project funding, Common Pool preservation, malicious proposal risk, proposal quantity, spending speed, and related conviction parameters into one decision about how much capital any single proposal should be able to access.
2021-07-04 to 2021-10-03 — Proposal Deposit and Challenge Deposit
Forum thread: Proposal Deposit and Challenge Deposit Category: Advanced CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, Proposal Deposit, Challenge Deposit, Tao Voting, Conviction Voting, Disputable Voting, proposal spam, griefing protection
July 4, 2021
This advanced Commons Configuration Dashboard parameter entry explained two collateral settings used in Tao Voting and Conviction Voting. The Proposal Deposit was defined as the amount of funds a proposal creator must lock in order to submit a proposal. The deposit is returned when the proposal passes or fails, but its presence creates a cost to proposing.
The design tradeoff for Proposal Deposit was framed as accessibility versus seriousness. A higher deposit increases friction and may filter out low-effort proposals, but it also makes proposal creation less accessible. A lower deposit allows more people to submit proposals, but can increase proposal volume, governance overhead, and congestion.
The Challenge Deposit was described as the amount someone must lock in order to challenge a proposal they believe is malicious, erroneous, or misaligned with the Community Covenant. Its design tradeoff was similar but inverted: a higher Challenge Deposit discourages frivolous or profit-seeking challenges, while a lower Challenge Deposit makes community veto power more accessible but can enable griefing, where someone repeatedly challenges another person’s proposals as harassment.
July 29 to October 3, 2021
A follow-up clarified that these deposits would be denominated in xDai but paid in TEC. In practice, if the deposit were set at a fixed xDai value, the required number of TEC tokens would depend on the TEC price at the time of proposal creation or challenge. Later comments noted that this TEC-denominated payment detail was important and also raised a naming cleanup around Disputable Voting and Disputable Conviction Voting.
By the end of the thread, Proposal Deposit and Challenge Deposit had been framed as governance-access and anti-abuse parameters. They shaped who could propose, who could challenge, how much friction existed in the process, and how the Commons balanced openness against spam, congestion, malicious proposals, and challenge-based harassment.
2021-07-04 to 2021-09-23 — Settlement Period
Forum thread: Settlement Period Category: Advanced CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, Settlement Period, Disputable Voting, Disputable Conviction Voting, Celeste, proposal challenges, settlement offer
July 4, 2021
This advanced Commons Configuration Dashboard parameter entry explained the Settlement Period used in Disputable Voting and Disputable Conviction Voting. The post described the situation where a community member believes a proposal is malicious, contains an error, or violates the Community Covenant and therefore challenges it.
Once challenged, the proposal creator has a defined amount of time, the Settlement Period, to choose between escalating the dispute to Celeste by paying dispute fees or resolving the challenge by accepting the Settlement Offer and removing the proposal. If the proposer takes no action before the end of the period, the proposal is automatically considered settled, is taken down, and the proposer receives their deposit back minus the Settlement Offer.
The design tradeoff was framed as one of speed versus deliberation. A longer Settlement Period gives proposers more time to decide whether to defend the proposal, but it can also slow down resolution. A shorter period creates faster conclusions, but can cause proposals to be removed prematurely if the proposer does not have enough time to respond. The post also clarified that the Settlement Offer is set by the challenger and can be zero if the challenge is minor and the challenger does not seek compensation from the proposer’s deposit.
July 29 to September 23, 2021
Later comments asked whether the Gardens default, possibly five days, was an appropriate benchmark and whether people with experience using Celeste had enough evidence to judge the parameter. The follow-up answer was cautious: there had not yet been enough Celeste disputes to provide a strong data-backed recommendation, though a few days could be useful if a challenged proposer needed time to prepare a defense.
By the end of the thread, the Settlement Period had been framed as a small but important procedural safeguard. It determined how much time proposal creators had to respond to challenges before a proposal was removed, and therefore sat at the intersection of governance speed, proposer due process, challenger incentives, and dispute-resolution design.
2021-07-06 to 2021-07-11 — Hatch Dress Rehearsal Recap
Forum thread: Hatch Dress Rehearshal Recap Category: The Hatch / Archive Archive theme: Hatch dress rehearsal, live test recap, Impact Hours formula, Rage Quit, Commons Upgrade rehearsal, migration testing, launch debugging
July 6, 2021
A recap was published after the first Hatch dress rehearsal. The rehearsal ended with thirty one contributions and more than one million TDAI raised. A two percent Hatch Tribute was sent to the non-redeemable vault, while the rest of the funds remained redeemable by TESTTECH holders. The post explained how TESTTECH had been minted for Hatch backers at one token per TDAI contributed.
The recap then examined the Impact Hours calculation and identified a serious configuration error. The formula used the selected Impact Hour parameters, but the expected raise value had been misconfigured as an extremely small number instead of the intended value. As a result, the Impact Hour Rate was calculated at the maximum rate rather than the expected lower rate. This caused far more TESTTECH to be minted for Impact Hours than intended and dramatically increased the cultural tribute share.
The thread compared what actually happened with what should have happened. In the actual rehearsal, total supply rose to more than three million TESTTECH. Under the intended formula, total supply should have been closer to 1.37 million TESTTECH. This made the recap an important debugging artifact: it showed not only the numbers, but the economic consequences of a parameter error.
The recap also walked through Rage Quit. Because of the inflated token supply, redeeming TESTTECH returned much less TDAI per token than expected. The post explained the two rational reasons someone might redeem at that stage: an Impact Hour holder might prefer immediate TDAI instead of locked future tokens, or a Hatcher might disagree with the Commons Upgrade terms and choose to exit before migration. The thread also noted that some redemption attempts failed because the addresses had voted yes in Dandelion Voting, which made Rage Quit unavailable to them until the vote resolved.
The Commons Upgrade portion of the rehearsal was also documented. Because the full Commons Upgrade script was still being developed, the test migrated funds to a normal DAO with two vaults and a new TESTTEC token. The rehearsal used temporary upgrade parameters, created several votes, transferred funds from the Hatch DAO into the new DAO’s reserve and funding pool, and allowed TESTTEC tokens to be claimed from a snapshot of TESTTECH. The post documented token locking and the beginning of linear unlock after migration.
A follow-up added the Hatch DAO contract addresses and launch parameters, making the thread a detailed technical record of the rehearsal environment.
July 11, 2021
A new recap was added after another dress rehearsal fixed the Impact Hour parameter misconfiguration. In the corrected rehearsal, contributions raised nearly two million TDAI, the Hatch Tribute was sent to the non-redeemable vault, the remaining funds stayed redeemable, and backer tokens were minted as expected.
This time, the Impact Hour formula produced the expected rate and total token supply, with only negligible rounding error. The Rage Quit calculation also behaved as expected, producing a much higher redemption value per TESTTECH than the misconfigured rehearsal. The rehearsal then migrated funds to the simulated Commons DAO, claimed TESTTEC tokens from the snapshot, and documented the launch parameters for the third rehearsal.
By the end of the thread, TEC had a detailed postmortem of its Hatch rehearsal process. The discussion documented the full path from contributions and token minting to Impact Hours, Rage Quit, migration, vault transfers, token locking, and Commons Upgrade simulation. Most importantly, the thread showed the rehearsal doing exactly what it was supposed to do: reveal a critical Impact Hours configuration error before the real Hatch and confirm the corrected setup in a later test.
2021-07-06 — Welcome to the Transparency Audit Index
Forum thread: Welcome to the Transparency Audit Index! Category: Audits / Archive Archive theme: Transparency audits, working group accountability, mutual monitoring, audit index, transparency levels
July 6, 2021
An index thread was created to gather all working group transparency audits in one place. The purpose was to make it easy for community members to access the audits, compare working group transparency levels, and support mutual monitoring across TEC.
The thread explained that the Transparency Working Group would update the index whenever working groups conducted new audits. Each entry included the working group, the date of its audit, and a transparency level. The index listed Comms, Gravity, Legal, Hatch Outreach, Parameters, Soft Gov, Stewards, and Transparency itself.
The post also defined the meaning of the transparency levels. A green level meant that 80 to 100 percent of the criteria were met and the working group was considered very transparent. A yellow level meant that 50 to 79 percent of the criteria were met and the working group was considered somewhat transparent. A red level meant that less than 50 percent of criteria were met and the working group was encouraged to improve transparency.
By the end of the thread, TEC had a central reference point for working group transparency audits. The thread turned transparency from a one-off report into an ongoing index, making accountability easier to track and giving community members a simple way to monitor how visible each working group’s operations were over time.
2021-07-08 to 2021-08-13 — Using Dashlane as TEC Credentials Manager
Forum thread: Using Dashlane as TEC credentials manager Category: Conviction Voting / Archive Archive theme: credential management, Dashlane, Keybase, access control, Comms accounts, admin permissions, audits, advice process
July 8, 2021
A Conviction Voting thread was opened to decide whether TEC should use Dashlane as its credential manager. The proposal built on the earlier credential-management advice process and framed Dashlane as a practical interim tool until more decentralized access-management systems became available.
The post explained that TEC had been using Keybase to share credentials and maintain a registry of who had access to each platform. Dashlane was proposed because it would allow access to be shared without directly sharing passwords, make it easier to revoke access from inactive contributors, and support regular password changes without disrupting workflows. The thread also proposed an access-request process using a form, steward review, and a short objection period before access would be granted.
The tradeoffs were made explicit. Dashlane could increase security and make contributor onboarding more stable, especially for communications accounts like Twitter, YouTube, Medium, HubSpot, Google Analytics, and Gmail. But it could also centralize power, add bureaucracy, and still leave access-holders with meaningful control over shared platforms. The proposal asked whether TEC should add Dashlane and a new process, add Dashlane without the process, or continue using Keybase.
July 9 to July 17, 2021
Follow-up discussion supported the move toward a more stable credential-management process but questioned whether two admins would be enough for the relevant accounts. The discussion clarified that having only a few admins did not mean only those people would work on the platforms; contributors could still be granted platform-specific access while credential administration remained limited. Additional admin access was added in response to the feedback, showing that the process was already adapting based on community concerns.
August 3 to August 13, 2021
The thread was revisited after the Dashlane trial. The discussion suggested that the tool had been one of the smoother ways TEC had handled credentials and raised the possibility of requesting funding for continued use. At the same time, the conversation broadened beyond the choice between Dashlane and Keybase. It argued that different platforms carry different levels of risk, and that monitoring and tracking platform activity may be more important than the exact tool used to distribute access.
By the end of the thread, credential management had moved from abstract concern to a practical governance decision. The discussion connected password sharing, admin concentration, platform risk levels, contributor access, audits, monitoring, communications operations, advice process legitimacy, and tool selection into one operational security proposal for TEC.
2021-07-09 — TEC Working Groups Weekly Update, July 9
Forum thread: TEC Working Groups Weekly Update, July 9 Category: Community Updates Archive theme: Working group updates, Hatch readiness checklist, community video, dress rehearsal recap, Impact Hour intervention, Commons Configuration Dashboard, launch countdown
July 9, 2021
A weekly Working Groups update was published as TEC moved into the final launch countdown. The update again reminded the community that TEC would be present at EthCC in Paris, connecting the Hatch period to broader ecosystem visibility.
Communications reported that it had signaled readiness for the Hatch and released a community video showing people around the world preparing for the Hatch. Token Engineering Scouts held sessions with other communities, and practical wxDAI guidance remained a forum highlight. Commons Swarm highlighted the dress rehearsal recap, which summarized test tokens moving through the Hatch smart contracts, including minting, Impact Hours, Rage Quit, and the simulated Commons Upgrade.
Gravity reported preparation for the next round of Graviton trainings. Hatch Outreach announced that a Hatcher Checklist and Hatcher Handbook were coming soon to help people confirm their readiness. Labs reported work related to the Impact Hour and Praise intervention proposals, as well as ongoing development of TokenSPICE as a tool for designing, tuning, and verifying tokenized ecosystems.
Legal continued work on the Community Covenant. 0mega prepared future work on token engineering ethics, focus groups, and processing useful results. Params reported progress on the Commons Configuration Dashboard, including design validation, the Python backend, and parameter documentation.
Soft Gov reported that the final votes had been cast for the Impact Hour and Praise intervention runoff. Two proposals received most of the votes and would be chosen, integrated, and implemented collectively. The update also noted that the token engineering book club had restarted with Ostrom’s Governing the Commons, and that a Soft Gov call had been used to discuss decision-making policies. The pre-Hatch Impact Hours Distribution Analysis was highlighted as the longest-running forum thread in TEC history at that time.
Stewards shared a transparency link for the Impact Hour intervention voting process, reported updated community statistics of eleven working groups, sixteen Stewards, and more than five hundred fifty TEC participants, and showed a working group checklist tracking readiness for Hatch. Transparency highlighted the credentials-management discussion.
A follow-up noted that only two boxes remained before the Hatch could begin. By the end of the thread, TEC was visibly in final launch mode: working groups were signaling readiness, the dress rehearsal had been documented, the Impact Hour intervention decision was moving toward implementation, contributor readiness materials were being prepared, and the organization was watching the final checklist before opening the Hatch.
2021-07-12 — Asset Token: Transferability
Forum thread: Asset Token - Transferability Category: Advanced CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, asset token, transferability, bonding curve, secondary markets, tribute capture, token design
July 12, 2021
An advanced Commons Configuration Dashboard parameter thread was published to explain asset token transferability. The thread defined transferability as the setting that determines whether a token can be freely transferred by users. Transferable tokens can be sent, exchanged, bridged, or traded outside the original system, while non-transferable tokens can only be minted and burned through the bonding curve contract unless additional uses are later whitelisted.
The thread described the implications of setting transferability to yes or no. If the token is transferable, it behaves more like regular money. It can move between accounts, be given to others, sold on exchanges, or bridged to Ethereum mainnet. This expands the design space and allows innovation outside the direct control of the DAO. It also makes the Commons economy easier to access through secondary markets.
The thread then described the benefits and tradeoffs of non-transferability. A non-transferable token is more like a share tied to a particular address. This narrows the design space, but it also ensures that buying and selling must pass through the bonding curve, which guarantees tribute collection on those transactions. It can also make the token function more like an identity or reputation signal because interactions remain easier to trace, and it simplifies modeling the TEC economy.
The thread emphasized that non-transferability does not necessarily mean permanent restriction to the original bonding curve. Additional uses could be whitelisted later, but only if they were specified and approved by DAO governance.
By the end of the thread, transferability had been framed as a foundational economic design choice for the Commons. The discussion connected liquidity, secondary markets, tribute capture, identity-like behavior, modeling simplicity, DAO control, and future whitelisting into one parameter that would shape how TEC tokens could circulate after the Commons Upgrade.
2021-07-12 — Asset Token: Token Name and Symbol
Forum thread: Asset Token - Token Name & Symbol Category: Advanced CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, asset token, token name, token symbol, public identity, branding
July 12, 2021
An advanced Commons Configuration Dashboard parameter thread was published to explain the token name and symbol settings. The thread defined the token name as the full name the community wanted the asset token to be known by, and the symbol as the short ticker-like shorthand that would accompany the token across interfaces and public information sources.
The thread explained that these parameters would be simple text inputs, with the symbol expected to be between two and five characters. Although technically straightforward, the post emphasized that the name and symbol mattered because they determined how the token would be recognized by the world.
The discussion framed the choice as a communication and identity question. The token name and symbol should be clear, memorable, and expressive of what the token stands for. The symbol should also avoid conflicts with major existing projects or confusing overlaps in the broader crypto ecosystem.
The suggested default was the already broadly accepted Token Engineering Commons token with the TEC symbol, while leaving room for alternative submissions if someone had a different idea and could justify it.
By the end of the thread, token name and symbol had been framed as small but meaningful design choices. The parameter did not change the internal mechanics of the Commons, but it shaped public recognition, branding, discoverability, and how the TEC asset token would be understood outside the community.
2021-07-12 to 2021-08-12 — Open Farewell Letter
Forum thread: Open farewell letter Category: Community Updates Archive theme: contributor exit, Impact Hours intervention, governance trust, voting power analysis, quadratic voting, community repair, exit rituals
July 12, 2021
A community update thread was opened as an open farewell letter from a core contributor who decided to step back from TEC stewarding. The letter was written in response to the recent decision to change how contributors would be rewarded shortly before the Hatch. It explained that the decision itself was less troubling than the process by which it had gained traction, divided the community, and changed prior expectations.
The post argued that contributor trust depends on honoring previous agreements, telling the truth in public debate, and avoiding misleading claims about governance power. It challenged claims that a very small number of people controlled half of the voting power and emphasized that quadratic voting had reduced the influence of large holders. The letter framed the Impact Hours intervention not only as a rewards issue, but as a governance trust issue: if contributors believe that accumulated rewards can be reinterpreted or reduced by later collective action, then confidence in the system may weaken.
The letter also clarified that the contributor would still complete critical Commons Swarm work because of respect for the people involved and the importance of the Hatch, even while stepping back from the broader community after the Commons Upgrade. This made the thread both a farewell and a governance critique.
July 12 to July 16, 2021
The first responses expressed appreciation, sadness, respect, and disagreement without trying to erase the seriousness of the departure. The discussion became a public reflection on whether the Impact Hours process represented harmful intervention, necessary democratic correction, or a difficult but valuable experiment in participatory governance.
A major part of the thread focused on the difference between token distribution, voting power, active voting participation, and actual control. Participants debated whether claims about concentration were accurate, whether abstention should be interpreted as concentrated control, and whether the process generated useful data even if it was painful. The thread also surfaced the idea that exit itself can be a strong signal in a commons: a person leaving may be giving the community important feedback about governance, trust, and the need for better coordination mechanisms.
July 21, 2021
The original analysis was later corrected after additional research showed that a block explorer had returned misleading data. A revised calculation using direct token data found that the top combined holders had less voting power than originally claimed in the farewell letter, and that it took a larger group of addresses to reach roughly half of the total voting power. The correction also reiterated that quadratic voting reduced the influence of large holders and distinguished token concentration from turnout-weighted voting influence.
This correction became an important archival moment because it showed the community working through data quality, interpretation, and accountability in public. The thread did not simply preserve a conflict; it documented how governance claims were checked, revised, and contextualized.
August 12, 2021
Later discussion shifted toward how communities should handle departures. The thread proposed that dedicated contributors leaving a community can act as important advisors, and that TEC might need better exit procedures, appreciation rituals, alumni pathways, and ways for people to spiral out of responsibility without severing all connection. It also recognized that departures can involve grief and repair, not only governance disagreement.
By the end of the thread, the farewell had become a larger reflection on TEC’s social and governance maturity. The discussion connected Impact Hours, prior agreements, data accuracy, voting power analysis, quadratic voting, contributor trust, voice and exit, governance experimentation, emotional repair, alumni pathways, and rituals of appreciation into one of the more human records of the Hatch-era governance process.
2021-07-12 — TAO Voting: Vote Duration
Forum thread: Tao Voting - Vote Duration Category: CCD Parameters / Archive Archive theme: TAO Voting, vote duration, quiet ending, delegated voting period, execution delay, Commons Configuration Dashboard, governance timing
July 12, 2021
This Commons Configuration Dashboard parameter entry explained the Vote Duration setting for TAO Voting. Vote Duration was defined as the period, usually measured in days, during which TEC holders could vote on a proposal. During that period, each holder could vote only once and could not take back their vote.
The thread clarified that Vote Duration is not a standalone timing parameter. In Disputable Voting, it contains other voting-period mechanisms, including the Quiet Ending Period and the Delegated Voting Period. If the Quiet Ending Extension is triggered, it can extend the overall voting duration by the length of that extension, potentially more than once.
The entry also distinguished Vote Duration from the Vote Execution Delay, which happens after a proposal has passed and is not counted as part of the voting period itself. The main design consideration was accessibility: the TEC needed a voting window long enough for participants across time zones and with different levels of attention or availability to review proposals and vote responsibly.
By the end of the thread, Vote Duration had been framed as a governance-access parameter. The suggested range was three to nine days, connecting the need for timely decisions with the need to give a globally distributed community a fair opportunity to participate.
2021-07-12 to 2021-11-19 — TAO Voting: Minimum Quorum
Forum thread: Tao Voting - Minimum Quorum Category: CCD Parameters / Archive Archive theme: TAO Voting, minimum quorum, voter participation, proposal validity, support required, vote duration, Commons Configuration Dashboard
July 12, 2021
This Commons Configuration Dashboard parameter entry explained Minimum Quorum for TAO Voting. Minimum Quorum was defined as the percentage of all TEC tokens from the total supply that must participate in a vote for the proposal to be considered valid.
The post described quorum as a baseline participation requirement. Even if a proposal satisfies the required support threshold, it should not pass unless enough voting power participates. The parameter could be set between zero and one hundred percent, but the suggested range was relatively low, between one and fifteen percent, because very high quorum could prevent proposals from passing even when support among active voters was strong.
The thread connected quorum to other governance timing and threshold parameters, especially Support Required and Vote Duration. In this framing, quorum was not the same as agreement; it was a legitimacy floor that determines whether enough of the token supply has participated for a vote to count.
November 19, 2021
A later question challenged the idea that low quorum had limited risks, asking whether a low Minimum Quorum could create manipulation opportunities for ill-intentioned members. The response clarified that very low quorum can create vulnerabilities, but that the risk depends on related parameters and the broader configuration of the governance system. The community was pointed back to the Commons Configuration Dashboard as a way to test how quorum interacts with other settings.
By the end of the thread, Minimum Quorum had been framed as a participation-safety parameter. The discussion showed the tension between keeping governance passable and preventing small groups from making valid decisions with insufficient participation.
2021-07-12 — TAO Voting: Quiet Ending Period and Quiet Ending Extension
Forum thread: Tao Voting - Quiet Ending Period and Quiet Ending Extension Category: CCD Parameters / Archive Archive theme: TAO Voting, quiet ending, quiet ending extension, vote duration, whale protection, contentious votes, governance timing
July 12, 2021
This Commons Configuration Dashboard parameter entry explained Quiet Ending as one of the distinctive features of Disputable Voting, later referred to in the TEC as TAO Voting. Quiet Ending checks whether the vote outcome flips during the final portion of the vote duration and, if it does, adds more voting time so the decision does not close immediately after a last-minute reversal.
The Quiet Ending Period was defined as the specified amount of time near the end of the vote duration. If the outcome changes from yes to no or no to yes during that window, the Quiet Ending Extension is triggered. If no outcome change happens during the Quiet Ending Period, the vote closes normally. The entry also clarified that the Quiet Ending Period can happen only once during a vote.
The Quiet Ending Extension was defined as the added voting time triggered by an outcome flip during the Quiet Ending Period. During the extension, voters other than delegates can continue voting. If the outcome flips again during the extension, another extension can be triggered, with no fixed limit on the number of extensions. The vote closes only once the outcome remains unchanged through an extension period.
The parameter discussion framed Quiet Ending as a protection against last-minute capture or manipulation, especially if a large holder tries to flip a proposal at the end of the vote. It also helps contentious votes receive more input before closing. The suggested Quiet Ending Period was between 50 percent and 10 percent of total vote duration, rounded to whole days for simplicity, while the suggested Quiet Ending Extension was one to three days to account for time zones and availability.
By the end of the thread, Quiet Ending had been framed as a governance-safety timing mechanism. It connected vote duration, contentious decisions, whale resistance, delegate limitations, and global participation into one design question: how much extra time should a Commons give itself when a vote’s outcome changes at the last moment?
2021-07-12 to 2021-09-05 — TAO Voting: Support Required
Forum thread: Tao Voting - Support Required Category: CCD Parameters / Archive Archive theme: TAO Voting, support required, consensus threshold, Commons Upgrade voting, quorum, vote duration, governance safety
July 12, 2021
A Commons Configuration Dashboard parameter thread was published to explain the TAO Voting Support Required setting. The post defined Support Required as the percentage of yes votes out of total votes needed for a proposal to pass. The parameter would be set between fifty and one hundred percent.
The thread framed Support Required as a direct measure of consensus. A higher support requirement would mean that a stronger degree of agreement was needed before a Commons Upgrade proposal could pass. A lower support requirement would allow a smaller majority to set the parameters of the upgrade. The suggested range was sixty to ninety-five percent, with Minimum Quorum and Vote Duration named as related parameters.
September 5, 2021
Later discussion revisited the parameter through the lens of governance culture and conflict. Participants argued that a decision passing by only a small majority could signal unresolved misunderstanding, poor communication, or misaligned values. Rather than using voting only to move quickly, the thread suggested that votes should confirm that the community is broadly on the same page, and that close splits should prompt more deliberation.
The discussion also reframed the parameter from the opposite perspective: instead of asking what percentage should be required to pass, the community could ask what percentage of voters should be able to block a proposal. This made the parameter easier to reason about as a safety threshold. The thread noted that TAO Voting was expected to be used rarely and that many DAO votes tend to have strong yes bias, making the meaning of opposition especially important.
By the end of the thread, Support Required had been framed not merely as a pass/fail percentage, but as a cultural signal about consensus. The discussion connected yes-vote thresholds, deliberation, communication, conflict, voter disagreement, delegation, yes bias, blocking power, and upgrade legitimacy into one governance-parameter decision.
2021-07-12 — TAO Voting: Execution Delay
Forum thread: Tao Voting - Execution Delay Category: CCD Parameters / Archive Archive theme: TAO Voting, execution delay, proposal execution, voter review window, Augmented Bonding Curve, Commons Configuration Dashboard
July 12, 2021
A Commons Configuration Dashboard parameter thread was published to explain the TAO Voting Execution Delay. The post defined the execution delay as the required amount of time between a proposal passing and that proposal being executed.
The thread explained that the parameter would be measured in hours and could theoretically be set anywhere from zero upward. Its purpose was to give token holders time to evaluate the implications of a successful proposal before it took effect. During that delay, holders could decide whether they wanted to maintain their TEC holdings, buy more TEC, or sell TEC through the Augmented Bonding Curve.
Because TAO Voting, formerly Disputable Voting, could have significant power within the DAO, the thread encouraged a generous review window. The suggested range was eight to twenty-four hours. Related parameters included vote duration, entry tribute, exit tribute, Token Freeze, and Token Thaw.
By the end of the thread, Execution Delay had been framed as a governance safety buffer. The discussion connected proposal passage, delayed execution, voter review, market exit or entry decisions, ABC liquidity, and related timing parameters into one post-vote protection mechanism for the Commons Upgrade.
2021-07-12 to 2021-07-31 — Conviction Voting: Conviction Growth (aka Half Life)
Forum thread: Conviction Voting - Conviction Growth (aka Half Life) Category: CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, Conviction Voting, conviction growth, half life, proposal timing, voting power accumulation
July 12, 2021
A Commons Configuration Dashboard parameter thread was published to explain Conviction Growth, also described through its half-life output. The thread defined conviction as the voting power that accumulates when tokens are staked on proposals, combining both the amount of tokens staked and the length of time they remain staked.
The post explained that the Conviction Growth parameter determines how quickly conviction accumulates through a logarithmic curve. In the dashboard, the parameter would be adjusted with a slider, allowing the community to see how many days it would take staked tokens to reach a certain percentage of their maximum conviction. The output of that setting was expressed as a half-life: the number of days needed for conviction to increase or decrease by fifty percent.
The thread framed the design tradeoff clearly. Faster conviction growth would make voting power accumulate quickly and allow proposals to move faster, but it would also make voting power decrease quickly when tokens were removed. Slower conviction growth would make governance more gradual, reducing the impact of abrupt token movements and helping prevent last-minute vote swings. The suggested range ran from half a day to sixty days, with spending limit and minimum conviction named as related parameters.
July 31, 2021
Follow-up discussion leaned toward a slower and steadier setting, with a half-life around one week proposed as a reasonable starting point. That setting would allow conviction to build meaningfully over several weeks without making decisions instant or overly reactive.
By the end of the thread, Conviction Growth had been framed as a pacing parameter for TEC governance. The discussion connected proposal responsiveness, resistance to sudden voting swings, token staking duration, half-life math, dashboard simulation, and the community’s desired governance tempo into one Conviction Voting configuration decision.
2021-07-12 — Conviction Voting: Minimum Conviction (aka Minimum Threshold)
Forum thread: Conviction Voting - Minimum Conviction (aka Minimum Threshold) Category: CCD Parameters / Archive Archive theme: Conviction Voting, Minimum Conviction, Minimum Threshold, effective supply, malicious proposal protection, Common Pool funding
July 12, 2021
A Commons Configuration Dashboard parameter thread was published to explain Minimum Conviction, formerly called Minimum Threshold. The post defined conviction as the voting power that grows when tokens are staked on proposals, combining both the number of tokens staked and the time they remain staked.
Minimum Conviction was described as the minimum amount of TEC voting support needed to pass a proposal, no matter how small the funding request is. In the dashboard, it would be set as a percentage of effective supply, meaning the number of tokens actively voting on proposals. The mechanism ensures that funding requests below a certain size all require the same base level of conviction to pass.
The thread explained the security purpose of the parameter. Without a minimum, an attacker could submit many small proposals that each require very little conviction, potentially draining funds from the Common Pool. A low Minimum Conviction makes it easier to fund useful proposals even when voter participation is low, but increases exposure to this attack. A high Minimum Conviction requires more serious engagement, but can make proposals difficult to pass and slow the Commons down.
The suggested range was 0.1 percent to 3 percent, and the thread named Spending Limit, Conviction Growth, and Minimum Effective Supply as related parameters. By the end of the thread, Minimum Conviction had been framed as a baseline security and governance-participation parameter that protects the Common Pool while preserving the ability to fund legitimate initiatives.
2021-07-12 to 2021-10-28 — Augmented Bonding Curve: Entry and Exit Tribute
Forum thread: Augmented Bonding Curve - Entry & Exit Tribute Category: CCD Parameters / Archive Archive theme: Augmented Bonding Curve, Entry Tribute, Exit Tribute, Common Pool, speculation, minting, burning, TEC liquidity, Commons Configuration Dashboard
July 12, 2021
This Commons Configuration Dashboard parameter thread explained the Entry Tribute and Exit Tribute in the Augmented Bonding Curve. The post described the tributes as percentages deducted when agents mint or burn TEC through the ABC, with the deducted amount flowing to the Common Pool. This made the tributes both a funding mechanism for the Commons and a way to shape speculative behavior around TEC.
The Entry Tribute was defined as the percentage of reserve currency sent to the Common Pool during a minting event. When someone bought TEC through the ABC, they would send wxDai to the curve, the Entry Tribute would be routed to the Common Pool, the rest would enter the Reserve, and TEC would be minted for the buyer. The post noted that a high Entry Tribute could discourage speculators and arbitrageurs, but could also reduce new funding for the Common Pool if it made purchases unattractive. A very low tribute would encourage entry and possibly more funding, but could also increase speculative volatility. The suggested Entry Tribute range was zero to five percent.
The Exit Tribute was defined as the percentage of reserve currency sent to the Common Pool during a burning event. When someone sold TEC back into the ABC, their TEC would be burned, the reserve currency due to them would be calculated, the Exit Tribute would be deducted into the Common Pool, and the remainder would be sent to the seller. The post noted that a higher Exit Tribute could reduce speculative exits, but might also discourage people from entering the economy in the first place. It suggested that the Exit Tribute would generally be higher than the Entry Tribute, with an initial suggested range around three to fifteen percent.
October 28, 2021
A later follow-up revisited the parameter after Params Party discussions. The response expressed interest in a high Entry Tribute at launch because it could keep early buyers more values-aligned, send more of the initial buy into the Common Pool, and take advantage of the fact that there would not yet be other ways to get TEC. The suggestion was that this could be changed after a few weeks once other liquidity pools emerged.
The same follow-up paired a higher Entry Tribute with a lower Exit Tribute. The reasoning was that a lower exit cost would reduce the spread between tributes once liquidity pools existed and would allow the market price to float within a smaller band. It also noted that a high Entry Tribute and low Exit Tribute could make the market price sit above the minting price, which might create a psychologically positive effect. The comment ended by recommending analysis of trading volume and parameter adjustments after one or two months.
By the end of the thread, the tributes had been framed as active economic levers rather than static fees. The discussion connected Common Pool funding, speculation control, early buyer alignment, liquidity formation, market psychology, and post-launch parameter adjustment into one design question: how should the TEC use entry and exit costs to balance openness, stability, funding, and long-term market health?
2021-07-13 to 2021-09-05 — Augmented Bonding Curve: An Introduction to the ABC
Forum thread: Augmented Bonding Curve - An Introduction to the ABC Category: CCD Parameters / Archive Archive theme: Augmented Bonding Curve, bonding curves, Hatch Phase, Commons Upgrade, Open Phase, Common Pool, Reserve, token freeze, token thaw
July 13, 2021
A Commons Configuration Dashboard education thread was published to introduce the Augmented Bonding Curve. The post first explained token bonding curves as crypto-economic systems where tokens can be minted and burned on demand according to preset rules. It described three core properties: dynamic supply, deterministic pricing, and instant liquidity through a contract that acts as the counterparty for minting and burning.
The thread explained that a bonding curve contains a reserve currency and an asset token. In TEC’s case, wxDAI would serve as the reserve currency and TEC would serve as the asset token. The bonding curve contract links reserve, supply, and price so that when reserve currency is deposited, asset tokens are minted, and when asset tokens are burned, reserve currency is returned.
The post then explained what makes the bonding curve augmented. The Augmented Bonding Curve adds mechanisms for fundraising, incentive alignment, a Common Pool, token lockups, and feedback loops. It described the system as unfolding across three phases: the Hatch Phase, the Commons Upgrade, and the Open Phase.
During the Hatch Phase, initial contributors pool capital to bootstrap the Commons and receive non-transferable Hatch tokens for governance. During the Commons Upgrade, some of the Hatch funds are placed into the Common Pool for mission funding and the rest are placed into the Reserve to initialize the bonding curve and opening price. During this phase, tokens distributed to Hatchers are frozen to reduce early speculation while still preserving governance participation. In the Open Phase, anyone can mint transferable tokens by depositing wxDAI, and entry or exit tributes send a portion of transactions to the Common Pool. Over time, frozen Hatcher tokens thaw until all tokens become liquid.
September 1 to September 5, 2021
Follow-up discussion asked whether the Open Phase had Common Pool funding mechanisms beyond exit tribute and whether TEC tokens would be tradeable on exchanges. The response clarified that both entry tribute and exit tribute could fund the Common Pool, alongside direct donations and treasury management, and that secondary-market transferability would depend on the Transferability parameter chosen by TECH holders. Another response suggested that the Commons could later vote to create additional revenue streams, such as projects or products that direct some proceeds back to the Common Pool.
By the end of the thread, the ABC had been framed as the economic engine of TEC’s post-Hatch system. The discussion connected bonding curve fundamentals, wxDAI reserves, TEC token minting and burning, Hatch governance, Common Pool funding, Reserve initialization, token freeze, token thaw, entry and exit tributes, secondary market transferability, and future revenue streams into one introductory explanation of the Augmented Bonding Curve.
2021-07-13 to 2021-07-26 — New Discord Onboarding Journey
Forum thread: New Discord Onboarding Journey Category: Ideas / Archive Archive theme: Discord onboarding, anti-spam, captcha verification, onboarding automation, Code of Conduct acknowledgement, SourceCred gaming prevention
July 13, 2021
An advice-process style idea thread was opened to redesign TEC’s Discord onboarding journey. The post began by identifying problems with the existing onboarding process: spam bots entered periodically, voice-channel invites sometimes produced confusing error screens for new people, and the rules acknowledgement message could be missed.
The thread connected spam prevention to future governance and contribution systems. At the time, bots were mostly an annoyance and a scam risk, but if TEC later used SourceCred or another interaction-measurement system on Discord, similar bots could be used to game contribution metrics. This made onboarding security part of both community safety and contribution-accounting integrity.
The proposed solution used a dedicated onboarding site at discord.tecommons.org. New members could log in through Discord, authorize the automation, complete a captcha, and then enter the server through the #join-here channel. The bot would also send a welcome message with key information, reducing the manual burden of welcoming every new person as the community grew.
The thread also described what would happen if someone entered through a normal Discord invite link. If they had not completed the captcha before, the bot would direct them to the onboarding site. The post recognized a difficult edge case: people with closed direct messages could not easily receive the bot’s instructions, but allowing them through could also create a loophole for bots.
A major section addressed safety and privacy. The automation was open source, and the post listed the code repositories for the OAuth site and Discord bot module. It explained what data the automation could access and store: Discord username, discriminator, user ID, avatar, join time, captcha completion time, and verification status. The thread emphasized that the system did not log email addresses or other private information.
The advice request asked several implementation questions. Would the new journey make onboarding more confusing? Should the system remove the “join servers for you” permission? What should happen to people with closed DMs? Should Code of Conduct acknowledgement be built into the site? Should the design be simplified? And most importantly, would the new process feel unwelcoming?
July 16 to July 26, 2021
Follow-up feedback supported trying the system in practice, while suggesting that the permissions should be reduced if possible. It also suggested that acknowledgement of community rules might fit into a broader orientation flow on the website.
Later feedback asked for a clearer explanation of the user journey and suggested a more welcoming, personalized onboarding message. Instead of one generic message, the onboarding flow could offer different paths for different types of newcomers: people who want to ask questions live, people who prefer reading, people who want a community overview, people who already know which working group they want to join, people interested in TEC’s design and values, people who want to watch recordings, and people who need one-on-one guidance.
The thread then clarified the user journey with screenshots: a landing page, Discord authorization, captcha completion, and redirection into the server. It also refined the behavior for normal invite links. People who had not completed the captcha could be removed and redirected, while people with closed DMs could receive limited access to orientation, help, policy acknowledgement, and announcements channels rather than full server access.
The discussion also explored whether the system could become a server-agnostic onboarding API. If generalized, it could support related Discord servers and cross-verify people as human across a shared database, making the tool reusable beyond TEC itself.
By the end of the thread, TEC had developed a more sophisticated approach to Discord onboarding. The discussion connected spam prevention, captcha verification, privacy, open-source automation, SourceCred gaming risk, Code of Conduct acknowledgement, orientation design, newcomer learning styles, and reusable infrastructure into one onboarding journey proposal.
2021-07-17 — TEC Working Groups Weekly Update, July 17
Forum thread: TEC Working Groups Weekly Update, July 17 Category: Community Updates Archive theme: Hatch launch, working group updates, Hatcher guidebook, EthCC, Commons Swarm security, Sprint 14, post-launch coordination
July 17, 2021
A weekly Working Groups update was published with the major announcement that TEC had officially hatched two days earlier. The post invited people to contribute to the Hatch and framed the launch as part of TEC’s mission to advance token engineering ethically and collectively. It also reminded the community that TEC would be present at EthCC in Paris and would remain there afterward for an unconference-style gathering.
Communications reported a guest article on TEC, a Hatch animation video in production, expected EthCC coverage, and a content index for the Hatch campaign. Commons Swarm reported that EVM-Crispr was already functional, pointed people to the Hatch rehearsal recap, and noted that code review had applied defensive programming changes to improve security.
Gravity described a meditation held after the opening of the Hatch during the community call, followed by planning for the next Graviton training in September. Hatch Outreach shifted into active launch support, contacting potential Hatchers who had previously soft-committed to TEC. The group also produced a Hatcher Guidebook and Checklist explaining how to create a Web3 wallet, join the Trusted Seed, acquire wxDai, review the Hatch process, understand Hatch DAO parameters, and engage with the future Commons Upgrade.
Labs reported Sunday modeling and analysis sessions with Params, weekly sync work on the Impact Hours analysis retrospective and Labs roadmap, and continued TokenSPICE development. Legal continued working on the Covenant and third-party service posting terms. 0mega prepared work on token engineering ethics topics, focus group timelines, and results processing.
Params reported new parameter documentation in the forum, including explanations of Commons Configuration Dashboard parameters and advanced parameters, while continuing work on design validation and the Python backend. Soft Gov focused on the processes TEC used to adopt proposals, including when to use voting versus the advice process, and highlighted a summary of the Impact Hour intervention process.
Stewards described Sprint 14 as “The Hatch Sprint,” after which the community would take a sprint break until August. They also noted that many Stewards and active contributors would be in Paris, that some meetings were canceled because of travel, and that an advice process was requested around anti-spam improvements for Discord onboarding. Transparency reported that Hatch privacy policy terms were available on GitBook, that Dashlane was ready, and that credential-management work remained a highlighted topic.
By the end of the thread, TEC had shifted from preparation into live Hatch operations. The update captured the first post-launch organizational moment: outreach turned toward active Hatcher support, communications moved into launch campaign mode, technical teams were securing and documenting the system, governance teams were preparing future proposal processes, and Stewards were coordinating travel, sprint timing, and post-Hatch community rhythm.
2021-07-21 — Opening Price: Price Floor Mechanism
Forum thread: Opening Price - Price Floor Mechanism Category: CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, opening price, price floor, token freeze, token thaw, TEC token economics
July 21, 2021
A Commons Configuration Dashboard parameter thread was published to explain the opening price and price floor mechanism for TEC after the Commons Upgrade. The thread defined the opening price as the price at which TEC tokens would be sold once the Commons Upgrade was complete.
The post explained the relationship between Hatch tokens and TEC tokens. During the Hatch, TECH had been minted at a value of one wxDAI per TECH. At the Commons Upgrade, Hatchers would receive TEC tokens at a one-to-one TEC to TECH ratio. This made the opening price an important bridge between the Hatch phase and the post-upgrade TEC economy.
The thread then introduced the price floor as the guaranteed minimum possible price at which TEC tokens could be priced at a particular point in time. Early buyers would benefit from this floor because it would reduce the risk that the token price could fall below a known threshold.
The mechanism for guaranteeing the floor was tied to the Token Freeze and Token Thaw design. By controlling how tokens became transferable or liquid over time, the Commons could engineer a price floor that reduced perceived investment risk, made TEC tokens more attractive relative to other digital assets, and increased the likelihood of reaching the community’s funding goals.
By the end of the thread, the opening price and price floor had been framed as part of the post-Hatch economic design. The discussion connected Hatch token conversion, TEC token pricing, early buyer confidence, Token Freeze, Token Thaw, and fundraising strategy into one parameter concept for the Commons Upgrade.
2021-07-21 to 2021-09-20 — Token Freeze and Token Thaw
Forum thread: Token Freeze & Token Thaw Category: CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, Token Freeze, Token Thaw, vesting, price floor, Augmented Bonding Curve, token liquidity, governance rights
July 21, 2021
This parameter thread explained Token Freeze and Token Thaw as a vesting process built into the Augmented Bonding Curve design. The post framed the purpose of vesting as early economic stability: tokens would remain locked long enough for the Commons to develop economic activity through the bonding curve before backers and builders could fully liquidate their positions. Rather than treating liquidity as an immediate right after launch, the design used delay and gradual release to protect the early TEC economy.
The post connected Token Freeze and Token Thaw to Opening Price, arguing that the three parameters together helped establish a price floor. Token Freeze determined how long TEC tokens would remain locked in a smart contract before any release began. A shorter freeze would give participants earlier liquidity but leave less time for the Common Pool and bonding curve economy to build activity. A longer freeze would provide more runway for economic development but could reduce participant interest and limit the use of capital in secondary markets or other future use cases.
Token Thaw was described as the period after the freeze during which tokens are released linearly until all tokens become available. A short thaw could create price volatility by releasing too many tokens into the market too quickly, while a long thaw could reduce volatility but delay capital availability. The suggested range for both parameters was 24 to 76 weeks, and the post encouraged the community to compare combinations such as short freeze with long thaw, or long freeze with shorter thaw, as part of a broader economic design debate.
August 27 to September 20, 2021
Follow-up comments initially treated the post as a useful newcomer-friendly explanation of the freeze and thaw process. Later, a governance question clarified that locked tokens would still count for voting power during the freeze period, meaning Hatchers could participate in governance even before they could withdraw or transfer their tokens.
The final substantive question pushed the discussion toward the underlying economic assumptions of the ABC. If freeze and thaw timelines were meant to support long-term token value, then the community needed a clearer explanation of how Common Pool investments, project utility, bonding-curve activity, and demand for TEC tokens were expected to interact. This moved the thread from parameter education into a broader request for an explicit theory of TEC economic value creation.
By the end of the thread, Token Freeze and Token Thaw had been framed as more than simple vesting settings. They were presented as economic coordination parameters balancing stability, liquidity, governance participation, participant confidence, price-floor design, and the community’s theory of how the TEC economy would generate value after the Hatch.
2021-07-21 — Token Thaw: Token Release Cliff
Forum thread: Token Thaw - Token Release Cliff Category: CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, Token Thaw, Token Freeze, liquidity release, price floor, Commons Upgrade economics
July 21, 2021
A Commons Configuration Dashboard parameter thread was published to explain the Token Thaw period and Token Release Cliff. The Token Thaw period was defined as the time between the end of the Token Freeze and the point when all TEC tokens become liquid and available.
The thread explained that as tokens thaw, the price floor descends linearly. The floor eventually reaches zero when one hundred percent of TEC tokens are liquid, marking the end of the Token Thaw period. The underlying assumption was that by the time the floor had fully declined, the Commons should already be sufficiently established, advancing token engineering, and supported by real value rather than only by the engineered price floor.
The Token Release Cliff was described as the graph showing the relationship between time and the corresponding price floor. In other words, it made visible how the minimum possible TEC token price would change as more time passed and more tokens became liquid.
By the end of the thread, Token Thaw had been framed as a transition mechanism between launch protection and mature liquidity. The discussion connected token release timing, liquidity, price floor decline, investor confidence, and the expectation that the Commons should build real value before the engineered floor fully disappears.
2021-07-26 to 2021-09-12 — The Power of Defaults in the Commons Configuration Dashboard
Forum thread: The Power of Defaults in the Commons Configuration Dashboard Category: Advice Process / Archive Archive theme: Commons Configuration Dashboard, default settings, parameter scope, advanced area, Commons Upgrade, user experience, governance transparency
July 26, 2021
An advice process thread was opened to explain how defaults would be used in the Commons Configuration Dashboard. The post described the dashboard as the next major product from the Params Working Group, inspired by the Hatch Config Dashboard and Commons Simulator, and intended to help TEC and future commons configure a Commons Upgrade. Its scope included the Augmented Bonding Curve, Token Thaw, Disputable Conviction Voting, and Disputable Voting applications.
The central problem was complexity. The Commons Upgrade involved more than thirty parameter choices, but not every parameter had the same importance, complexity, or ripple effects. The thread proposed reducing the interface burden by emphasizing the parameters most important for the community to understand while moving lower-impact, highly technical, or overly complex parameters into an Advanced Area. These parameters could still be changed, and their impacts would still appear in the dashboard, but they would not be emphasized in the main user experience.
The post explicitly acknowledged the power and risk of defaults. Defaults could help non-expert users avoid overwhelming complexity, but they could also be abused to steer outcomes in ways that contradict TEC’s goal of ending crypto technocracy. For that reason, the thread made the default-setting process visible and proposed open discussions with working groups about who should decide which defaults.
The thread listed the parameters expected to be highlighted for community configuration: Token Thaw settings, Augmented Bonding Curve tributes, Conviction Voting settings, and Disputable Voting settings such as support required, quorum, vote duration, delegated voting period, quiet ending, and execution delay. It also listed parameters proposed for the Advanced Area or exclusion, including transferability, token name, virtual supply, virtual balance, minimum effective supply, proposal and challenge deposits, settlement period, permissions, estimated Hatchers that ragequit, initial buy, minting rate, token decimals, and Gardens-specific parameters. Responsibility for defaults was distributed among Stewards, Commons Swarm, Params, and related technical groups depending on the parameter.
July 26 to July 29, 2021
Follow-up discussion clarified that the post was not meant to become a formal vote unless there was contention. It was intended to gather feedback and raise awareness before defaults were selected. One suggestion was to let people explicitly choose “default to the expert recommendation” for parameters they did not understand, allowing them to participate where they felt informed without needing to master every parameter. Another response argued that completeness mattered, and that the dashboard should maximize transparency and individual control while protecting dangerous options through warnings or advanced sections.
A later reply explained that the dashboard would likely begin from a full design and allow people to fork configurations by changing only the parameters they cared about. Because the parameters were interconnected, creating separate defaults for each choice would be complicated.
September 12, 2021
A later edit updated units and names and incorporated initial buy considerations from the bonding curve discussion.
By the end of the thread, the Commons Configuration Dashboard had a clear product-design philosophy: simplify the main experience without hiding the system. The discussion connected defaults, the default effect, expert configuration, community education, advanced parameters, transparency, parameter interdependence, interface scope, technical stewardship, and Commons Upgrade legitimacy into one design approach for helping a broad community make complex economic and governance decisions.
2021-07-26 to 2021-07-29 — Market Data and Transparency Around the Common Pool
Forum thread: Market data and Transparency around Common pool Category: Advice Process / Archive Archive theme: Common Pool transparency, Dune Analytics, bonding curve market data, treasury reporting, fund-use dashboards, working group accountability
July 26, 2021
An advice process thread was opened to explore better transparency around the Common Pool and TEC’s bonding curve market data. The idea came from an unconference discussion and proposed using Dune Analytics to make bonding curve data easier to see and understand.
The thread also proposed a recurring transparency report every six months showing movements of funds from the Common Pool. Instead of relying only on raw blockchain data, the report would translate fund movements into a spreadsheet with charts and statistics. It would show how funds were being used, how much was going to projects, how much was associated with different working groups, and what patterns could be observed over time.
The post emphasized that even though the information was already available on-chain, transparency improves when data is presented visually and in a way the community can interpret. The goal was to reach broader participation in the discussion, gather advice, compare possible tools, and decide whether a formal vote would be needed only if someone requested one.
July 29, 2021
Follow-up discussion supported bringing more data expertise into the conversation and welcomed the idea as a useful transparency effort for the community. The thread framed data itself as a form of power, especially when it helps community members understand how shared funds are being used.
By the end of the thread, TEC had surfaced a concrete post-Hatch transparency practice: combine on-chain market and treasury data with accessible reporting. The discussion connected Dune Analytics, Common Pool fund movements, spreadsheet-based transparency reports, visual charts, project and working group spending, and community oversight into one proposal for making treasury activity more legible.
2021-07-29 — Augmented Bonding Curve: Commons Tribute
Forum thread: Augmented Bonding Curve - Commons Tribute Category: CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, Commons Tribute, Augmented Bonding Curve, Common Pool funding, Reserve Pool collateralization, Hatch funds allocation
July 29, 2021
A Commons Configuration Dashboard parameter thread was published to explain the Commons Tribute within the Augmented Bonding Curve design. The Commons Tribute was defined as the percentage of funds raised during the Hatch that would be allocated to the Common Pool rather than bonded to minted TEC tokens in the Reserve Pool.
The thread explained the core tradeoff. A higher Commons Tribute would give TEC more immediately usable capital for projects, initiatives, and mission-aligned work. This would allow more funding to flow into the community early, potentially supporting more participation and more productive activity. However, because those funds would not remain bonded to TEC tokens, a higher tribute would also reduce the initial Reserve Pool balance and make TEC less collateralized.
The post warned that setting the tribute too high could significantly weaken token value by leaving the system under-collateralized, while setting it too low could leave the organization without enough working capital to fund useful projects. The suggested range placed the parameter between fifteen and thirty-five percent, with opening price and reserve ratio named as related parameters that should be considered together.
By the end of the thread, the Commons Tribute had been framed as one of TEC’s most important economic design choices. The discussion connected Common Pool funding, Reserve Pool backing, token collateralization, Hatch fund allocation, project funding capacity, and the long-term health of the Augmented Bonding Curve into a single parameter decision.
2021-07-29 to 2021-12-15 — Augmented Bonding Curve: Opening Price and Reserve Ratio
Forum thread: Augmented Bonding Curve - Opening Price & Reserve Ratio Category: CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, Augmented Bonding Curve, opening price, reserve ratio, initial buy, price sensitivity, primary AMM, Commons Market Maker
July 29, 2021
A Commons Configuration Dashboard parameter thread was published to explain how the Augmented Bonding Curve’s Opening Price, Initial Buy, and Reserve Ratio fit together. The opening price was defined as the desired TEC token price before the initial buy, while the initial buy was described as the large first purchase that would mint tokens for Commons collective governance and likely shift the actual launch price through slippage. The reserve ratio was described as the fixed relationship between the Reserve Pool balance, total TEC supply, and TEC token price.
The thread emphasized that choosing an opening price was not an isolated decision. In combination with the Commons Tribute, the opening price would determine the reserve ratio, and therefore the token’s price sensitivity. A higher reserve ratio would make buys and sells move the token price less dramatically, while a lower reserve ratio would make the curve more volatile. The post walked through an example using an 800,000 wxDAI raise, a twenty percent Commons Tribute, a 640,000 wxDAI Reserve Pool, and an opening price that would produce a reserve ratio of one.
The main design tension was accessibility versus early economic strength. A high opening price could discourage newcomers from buying into the TEC economy, especially because many Hatchers received TEC near the one wxDAI range. A low opening price could increase accessibility and potential demand, but it could also risk leaving the economy underfunded or more volatile. The suggested range placed the opening price between 0.60 and 6 wxDAI, with Token Freeze, Token Thaw, and Commons Tribute identified as closely related parameters.
September 20 to December 8, 2021
A later update adjusted the example numbers to reflect the actual Hatch raise of 1,571,223.57 wxDAI. As the Commons Upgrade approached, the thread reopened around the question of why the reserve ratio had to be fixed and whether a variable reserve ratio could better manage price sensitivity, liquidity concerns, whale behavior, or market manipulation.
The responses clarified that the reserve ratio had not yet been selected because Commons Upgrade proposals were still being designed. The fixed reserve ratio was framed as the mathematical relationship that defines the bonding curve itself. Because the curve functions as an automated market maker with variable token supply, price sensitivity is a byproduct of the chosen curve. Changing the reserve ratio after launch would effectively change the shape of the curve. Dynamic bonding curves were acknowledged as possible in theory, but the discussion pointed to added complexity and attack-vector concerns.
The thread also clarified that the bonding curve itself was intended to act as the system’s market signal. Large buys would become increasingly expensive, with some value captured into the Common Pool through tributes. A hostile large buyer might raise the token price dramatically, but would not necessarily capture the organization’s social layer, and the fixed curve could itself deter manipulation because participants would understand the rules of entry and exit in advance.
December 8 to December 15, 2021
The later discussion broadened into a conceptual distinction between the Augmented Bonding Curve as a primary market mechanism and secondary AMMs as liquidity venues. The ABC was described as a primary market AMM because it issues and burns tokens against reserve assets, producing a “breathing supply” that expands and contracts with demand. The Common Pool and entry/exit tributes made this mechanism more specifically a Commons Market Maker, because it did not merely support liquidity or issuance but also created continuous fundraising for shared work.
Participants also explored whether future bonding curve designs could support dynamic reserve ratios. Dynamic curves were treated as promising research territory, especially for modeling in cadCAD or comparing against risk-adjusted bonding curve designs. At the same time, the thread emphasized that modifying the reserve ratio or curve shape after launch should not be treated casually. Even if governance could technically affect the curve through virtual supply, virtual balance, minting, burning, or reserve movements, doing so would undermine the purpose of having an invariant bonding curve unless there were very strong justification.
By the end of the thread, Opening Price and Reserve Ratio had become more than dashboard parameters. The discussion connected launch accessibility, reserve collateralization, price volatility, initial buy slippage, fixed versus dynamic curve design, AMM taxonomy, Common Pool funding, whale-resistance, and the long-term meaning of a bonding curve commitment into one of the most important economic design conversations in the Commons Upgrade.
2021-07-29 to 2021-09-15 — DAOs: A Good Fit for All
Forum thread: DAOs: A Good Fit for All Category: Advice Process / Archive Archive theme: DAO onboarding, belonging pathways, inclusion, working groups, small teams, mentorship, DAO HR, newcomer experience
July 29, 2021
An advice process thread was opened to ask whether DAOs are designed in ways that allow many different kinds of people to find belonging and meaningful participation. The opening post argued that decentralized organizations can be exciting alternatives to hierarchy, but that the “create your own journey” experience can cause some people to fall through the cracks after onboarding.
The thread described a recurring pattern: some newcomers thrive when asked to explore working groups, self-select into roles, and propose their own path, while others feel lost, uncertain, or socially exposed. The post avoided reducing the issue to introversion versus extroversion and instead framed it more broadly as a question of personality styles, social ease, information processing, learning preferences, and contribution pathways.
The post identified several friction points inside TEC and similar DAOs. Large working group calls could be energizing for some but intimidating or confusing for others. Rounds and open discussion could put unwanted spotlight on newcomers. Individual task assignment could leave people working alone without being woven into the community. The absence of a norm around small, self-organising teams meant that people who learn through deep, specific, collaborative work had fewer routes into meaningful participation. The post also noted that unclear expectations in working group meetings could make it difficult for newcomers to know whether questions, comments, or suggestions were welcome.
The opening proposal was to spark a conversation and potentially form a small group under Gravity or Soft Gov to explore better pathways for people who find DAOs challenging. Ideas included DAO school, DAO academy, DAO HR, clearer contribution pathways, and small groups that let people become useful while forming stronger relationships.
August 2 to August 12, 2021
Early responses agreed that onboarding and guidance could be improved, while also debating whether some degree of self-navigation is part of what makes someone a fit for decentralized work. The discussion explored whether DAOs should adapt to more kinds of people or whether DAOs naturally attract people who can tolerate uncertainty, ambiguity, and new forms of work.
The thread then refined the idea of “fit.” Rather than treating fit as a fixed personality trait, the discussion reframed it as an organizational design problem: DAOs can create multiple pathways of contribution, autonomy, agency, teamwork, coordination, and cooperation. Gravity training was suggested as a possible starting point for teaching how to create more inclusive pathways and improve the human experience in decentralized communities.
A later contribution argued that public accessibility requires stronger onboarding infrastructure across the whole DAO ecosystem. It proposed an HR DAO or decentralized job-posting/on-ramp system where newcomers could learn about decentralized work, identify their motivations, and be matched with DAOs that need their skills. Within TEC, the thread suggested developing onboarding metrics and creating a mentor program where contributors, stewards, and subject-matter experts could meet regularly with newcomers to answer questions and guide them through participation.
Another response described the problem as an “on-ramp economy” for DAOs: a commons problem that would benefit all DAOs but would be hard for any one DAO to build alone. Education, peer mentoring, DAO academy functions, and HR-like matching were discussed as complementary missions.
August 23 to September 15, 2021
A newcomer later responded positively to the idea of an entry-level program where participants could watch, learn, and contribute inside small groups based on skillset, personality, available time, and interests. This reinforced the idea that people want to feel useful early, but may need training wheels before they can confidently move into the broader TEC ecosystem.
Later discussion clarified that onboarding and long-term belonging are related but distinct phases. The first phase is joining and receiving support as a new member. The second phase is becoming a long-term community member after formal onboarding ends. The thread argued that TEC had started to focus on onboarding, but still needed more attention on the second phase: organizational design, information pathways, different working preferences, diversity, and inclusion.
By the end of the thread, the question had shifted from “Are DAOs a good fit for all?” to “How can DAOs create many kinds of fit?” The discussion connected onboarding, long-term belonging, small teams, working group design, mentorship, DAO HR, DAO academy concepts, newcomer metrics, peer learning, contribution pathways, personality differences, information flows, and inclusive organizational design into one broad reflection on how TEC could help more people become active participants rather than passive observers.
2021-07-30 to 2021-08-06 — Creating Spanish Community
Forum thread: Creating Spanish Community Category: Ideas / Archive Archive theme: Spanish-language community, translation, internationalization, contributor growth, education access, Discord channels
July 30, 2021
An ideas thread was opened to propose building a Spanish-speaking TEC community. The proposal began with translation as the first practical step: papers, articles, and relevant token engineering information could be translated into Spanish so that more people could learn from and participate in TEC.
The thread also proposed creating Spanish-language community channels similar to the existing English channels. The motivation was that different countries and cultures face different conditions, and adding another language could expand the reach of token engineering beyond the English-speaking community.
The post framed language access as a way to strengthen the commons. By helping qualified and interested people learn through translated documents and active Spanish channels, TEC could grow its contributor base and increase the robustness of the broader token engineering community.
August 6, 2021
Follow-up discussion supported the idea and noted that a Spanish Discord channel had already begun being promoted. The thread invited interested Spanish speakers into the existing community space and raised the possibility that a proposal could be created if more resources or coordination were needed.
By the end of the thread, TEC had surfaced a concrete path for internationalization: translate important materials, support Spanish-language discussion spaces, invite Spanish-speaking contributors, and potentially formalize the effort through a community proposal.
2021-08-01 to 2021-09-02 — A Culture of Self-Organising Small Teams and Sharing the Responsibility
Forum thread: A culture of self-organising small teams and sharing the responsibility Category: Community Updates Archive theme: organizational design, self-organising teams, steward capacity, contributor agency, information flow, time-bound roles, shared leadership
August 1, 2021
A community update thread was opened to reflect on TEC’s organizational design and how it could better support shared responsibility. The post examined visible and invisible systems, information pathways, contributor needs, agreements, expectations, shared values, and whether the organization’s structures were helping work happen efficiently and joyfully.
The reflection focused heavily on the steward role. It praised the idea of stewardship as care and responsibility, but argued that stewards were often working beyond capacity and had unintentionally become gatekeepers for information, decisions, and contributor action. This created risks: contributors could be blocked or slowed when stewards were unavailable, stewards could become overburdened project managers, and TEC’s stated values of autonomy, agency, accountability, and non-hierarchy could drift away from actual practice.
The main proposal was to cultivate a norm of self-organising small teams alongside larger working groups and individual task ownership. Small teams of three to five people could form around a specific focus for a defined period, create a mandate, share updates with the relevant working group and community, and become temporary caretakers of a particular domain. The thread argued that this would deepen belonging, improve information flow, help contributors build confidence, reduce steward workload, increase shared leadership, and allow TEC to respond more fluidly than it could through static working group structures alone.
A second proposal suggested making steward roles time-bound. Time-bound stewardship was presented as a way to reduce role fatigue, create opportunities for newer members, distribute leadership, and prevent decentralized organizations from recreating hidden hierarchies. Together, small teams and time-bound stewardship were framed as small organizational changes with potentially large cultural benefits.
August 11 to September 2, 2021
Follow-up discussion supported the idea that self-organising around concrete problems could free steward time while helping contributors build relationships and find meaningful work. The thread also touched on Discord role labels and clarified that some roles represented acknowledgement of consent conditions for participation. Later responses strongly supported both small teams and time-bound stewards, suggesting that the time-bound steward idea should move toward an advice process or proposal and could connect with other work on organic DAO decision-making.
By the end of the thread, TEC had a detailed organizational design reflection on how to scale care, responsibility, and agency. The discussion connected steward workload, contributor autonomy, invisible hierarchy, information flow, working group limits, small teams, time-bound mandates, role rotation, shared leadership, belonging, and accountability into one proposal for making the organization more self-organising and less dependent on overworked stewards.
2021-08-04 to 2021-08-09 — How Do I Participate in the Hatch? TL;DR
Forum thread: How do I participate in the Hatch? TL;DR Category: The Hatch / Archive Archive theme: Hatch onboarding, MetaMask, Trusted Seed, wxDAI, TECH minting, public participation guide, launch support
August 4, 2021
A Hatch onboarding thread was published to give prospective participants a short, practical guide for joining the TEC Hatch before it ended on August 14. The post condensed participation into four steps: set up a MetaMask wallet, apply to and activate membership through the Trusted Seed process, acquire DAI and convert it into wxDAI, and send wxDAI to the Hatch interface to mint TECH tokens.
The thread emphasized urgency because the Trusted Seed and membership process could take up to a week, even though applications were being expedited for the Hatch. It also linked the short instructions to a more detailed guidebook, tutorials for wallet and wxDAI setup, the Hatch interface, the TEC mission article, and Discord support for questions.
The thread functioned as a public participation gateway. It translated the cultural and technical requirements of the Hatch into a simple checklist that could be shared with newcomers, potential Hatchers, and aligned community members who needed to move from interest to action.
August 5 to August 9, 2021
Follow-up discussion further shortened the instructions into an even more direct message template: apply, activate membership after approval, get wxDAI, and send it to the Hatch. The thread was then pinned globally and re-pinned so it would remain visible during the final Hatch participation window.
By the end of the thread, TEC had a clear, public-facing Hatch participation script. The discussion connected wallet setup, membership curation, wxDAI acquisition, TECH minting, guidebook documentation, mission education, and Discord support into one concise onboarding pathway for late-stage Hatch participation.
2021-08-09 to 2021-09-21 — The Praise Debate Post-Action Summary
Forum thread: The Praise Debate Post-Action Summary Category: Community Updates Archive theme: Praise Debate, Impact Hours, post-action summary, Polarity Clause, No Abnormal Intervention, PRAISEMAGEDDON, compromise distribution, Hatch preparation
August 9, 2021
This post served as a retrospective summary of the Praise Debate, explaining where the conflict came from, what happened, and how the TEC moved forward. It began by clarifying why Praise had become such a sensitive issue: Praise was not merely a cultural practice of acknowledgment, because it produced Impact Hours, which translated into builder TECH tokens and eventually TEC tokens with governance power and potential market value. Once gratitude, governance, and economic upside were linked together, the distribution of praise became a serious governance matter.
The summary traced the debate back to data science explorations of the Praise system. Those explorations highlighted disparities between highly visible community participation, such as attending meetings and being active in social channels, and less visible contributions from people doing important Token Engineering or Commons-related work outside the most praise-heavy environments. The analysis also revived questions about paid contributors, whose Impact Hours had been reduced under earlier work agreements, and whether those reductions should be reassessed.
The post then summarized the two major proposals that emerged. One proposal argued against abnormal intervention in the existing Praise distribution, while still supporting two corrective actions: restoring a portion of deducted governance rights to paid contributors as non-transferable tokens and holding a Praise Party to recognize underrepresented Token Engineers. The other proposal argued that the Praise system was fundamentally unsuitable as the basis for the initial builder distribution and should be replaced with a tiered activity-based allocation that compensated unpaid contributors for their additional risk.
The voting process produced a close and polarized result, triggering the Polarity Clause. Rather than allow one side to win and the other side to lose, the TEC used the clause to merge the leading proposals into a compromise. The final result applied 52 percent of the No Abnormal Intervention distribution and 48 percent of the PRAISEMAGEDDON distribution, producing a binding final Impact Hours distribution that aimed to respect both due process and the intentions behind each proposal.
August 12 to September 21, 2021
A follow-up comment treated the summary as a clear and useful account of a difficult episode. A later update linked the Praise Debate to a subsequent vote about restoring 75 percent of governance rights to people whose rights had been deducted, showing that the compromise did not close every issue but did establish a path for additional post-Hatch governance repair.
By the end of the thread, the Praise Debate had been framed as painful but institutionally important. The post emphasized that the process revealed deep divisions, but also demonstrated the Commons’ ability to adapt, compromise, and learn from experimental governance. It positioned the episode as a lesson for future Commons: the first systems will not be perfect, but the willingness to inspect them, debate them, and iterate on them is part of the value the TEC was trying to create.
2021-08-12 to 2021-08-16 — Abstracting Complexity for Non-Crypto-Natives
Forum thread: [proposal] Abstracting complexity for non crypto-natives Category: Ideas / Archive Archive theme: onboarding, non-crypto-native users, managed minting, managed burning, UX abstraction, education, payment rails, legal and security risk
August 12, 2021
An ideas thread was opened to address how difficult it was for non-crypto-native users to participate in a commons. The post described the onboarding path as a long sequence of conceptual and technical steps: convincing someone of the project’s value, explaining tokens and bonding curves, explaining DAI, xDAI, and wxDAI, getting them to use an exchange, installing MetaMask, changing network settings, understanding gas, connecting to the curve, minting tokens, and then still needing to explain KYC, private keys, and self-custody.
The proposal suggested two kinds of abstraction. First, it proposed reusable animated educational content that could explain tokens and bonding curves in a simple way for many commons. Second, it proposed managed minting and managed burning as an optional service. Under that model, users could pay with DAI, payment processor, or wire transfer, while the platform handled the crypto steps in the background. Users could later withdraw tokens to their own wallet once they understood the system and wanted to participate more directly in governance or utility.
The proposal framed this service as both an onboarding tool and a possible revenue model. It could help commons attract more donors and participants, while TEC or the stack could charge a commission or subscription. The post also identified caveats around security, fraud, payment reversals, legal exposure, and the risk of being treated as an exchange.
August 14 to August 16, 2021
Follow-up discussion distinguished between conceptual understanding and technical UX. One response suggested that newcomers need familiar analogies to understand what backing a commons means, how ragequit or withdrawal works, why public goods funding matters, and how bonding curves reward earlier participation. Another response emphasized that wallet setup, DAI acquisition, and network configuration are UX problems, while explaining why the funds matter is a marketing and education problem.
By the end of the thread, TEC had surfaced a broader accessibility challenge: participation required both conceptual clarity and technical simplification. The discussion connected educational animations, managed wallets, payment processors, KYC, legal risk, fraud risk, bonding curve explanations, public goods analogies, example proposals, and newcomer UX into one proposal for making commons participation easier for people outside crypto.
2021-08-17 — TEC Working Groups Weekly Update, August 16
Forum thread: TEC Working Groups Weekly Update, August 16 Category: Community Updates Archive theme: post-Hatch update, Hatch close, Commons Upgrade, working group updates, Hatch Outreach wind-down, governance operations, platform access
August 17, 2021
A weekly Working Groups update was published after the Hatch closed on August 14. The post congratulated Hatchers, reported that the community had raised more than 1.57 million, and described post-Hatch acknowledgements including Hatch NFTs, SWAGTEC, and the ability to claim a Hatch t-shirt. It also invited new participants into Wednesday orientation calls and reminded everyone that weekly meetings remained open.
The update marked the organization’s shift from Hatch participation into post-Hatch operations. Communications shared an unconference aftermovie and noted ongoing content workshops. Commons Swarm reported that the Hatch had ended successfully, that TECH tokens had been minted for Builders shortly after close, and that work continued on the Commons Upgrade, including migration of the Hatch DAO into Gardens and replacement of the temporary issuance setup with the bonding curve.
Gravity highlighted the next free Graviton training and pointed back to the first training as a reference. Hatch Outreach was recognized for its role in the Hatch’s success and announced that the working group would wind down after a final celebratory call. The update also noted that a new outreach effort would focus on encouraging communities and projects to submit proposals.
Labs pointed to the Proposal Inverter specification. Legal continued covenant work. 0mega scheduled its next meeting. Params continued work on the Commons Upgrade dashboard and forum explainers, highlighting threads on opening price and reserve ratio, Commons Tribute, and Virtual Supply and Virtual Balance. Soft Gov revisited prior decisions in a decision tracker and organized open co-programming sessions. Stewards described Sprint 16 and noted that community calls were now being livestreamed for people unable to enter the Discord call. Transparency reported work on platform Code of Conduct materials and processes for requesting access to TEC platforms.
By the end of the thread, TEC’s post-Hatch operating picture was clear. The update connected Hatch closure, participant recognition, Commons Upgrade preparation, Hatch Outreach wind-down, proposal outreach, parameter education, covenant work, livestreamed community calls, platform access policies, and working group continuity into one snapshot of the organization entering its next phase.
2021-08-17 to 2021-08-28 — Requesting and Giving Access to TEC Accounts and Managing Credentials
Forum thread: Requesting and giving access to TEC accounts and managing credentials Category: Community Updates Archive theme: credential access process, Dashlane, Know Your Contributor, platform admins, Community Stewards, account audits, access revocation
August 17, 2021
A community update was published to formalize how contributors could request access to TEC accounts and how credentials would be managed. The post explained that because TEC was decentralized and contributors were distributed around the world, shared online platforms were essential for coordination and communication. At the same time, giving people access to shared accounts needed to be handled cautiously because the community relied on trust but also needed security practices.
The thread translated the earlier credential-management discussion into a concrete access process. Contributors would first contact a platform admin and discuss how they wanted to contribute. They could then submit a request through a form described as a “Know Your Contributor” process, collecting only the information necessary to evaluate the request. Credential managers would review the request, share it with Community Stewards, and Stewards would have a short poll period to object. If there were no objections within twenty-four hours, access would be granted, with an expected turnaround of roughly forty-eight hours.
The post also documented the decision to use Dashlane until more decentralized technologies became available. Only credential managers would hold passwords directly, while contributors could receive access without knowing login details. The process also required contributors to follow the Code of Conduct for platform admins. Credential managers would audit the access list every two months and could reset passwords after audits to remove inactive contributors.
August 28, 2021
A follow-up response welcomed the update and recognized the work involved in turning credential management from a loose security concern into a repeatable process.
By the end of the thread, TEC had documented a practical account-access policy. The discussion connected contributor access requests, platform admins, a lightweight contributor-verification form, steward review, Dashlane-based credential management, platform conduct rules, regular audits, password resets, and access revocation into one operating procedure for shared TEC accounts.
2021-08-22 to 2021-08-31 — TEC Working Groups Weekly Update, August 22
Forum thread: TEC Working Groups Weekly Update, August 22 Category: Community Updates Archive theme: post-Hatch operations, Hatch Outreach wind-down, Commons Configuration Dashboard, Graviton training, Gardens testing, working group updates
August 22, 2021
A weekly Working Groups update was published one week after the Hatch closed. It reminded Hatchers to claim their POAPs and Hatch t-shirts, highlighted a community call spotlight on the Governauts, and continued orienting the community toward post-Hatch activity.
Communications invited people to content workshops and shared a draft for a possible Comms funding structure. Commons Swarm reported that EVM-Crispr had reached version 1.0, TEC Gardens was live on Rinkeby, and the ragequit button in the Hatch dApp had been made more noticeable. Gravity promoted the upcoming Graviton training, asked the community to complete a survey about conflict-management needs in decentralized organizations, and reminded people that Gravity support was available for conflict management.
Hatch Outreach reported that its mission was complete and that the working group had held a farewell party. This was presented as the group’s final update, with one last reminder for Hatchers to claim swag and POAPs. Labs reported TokenSPICE development workshops and regular Labs meetings. Legal continued covenant work. 0mega announced a finished manifesto and its next meeting.
Params reported active work on the Commons Configuration Dashboard, including design validation, frontend, backend, and parameter documentation. Soft Gov highlighted the advice process for receiving project proposals, participation in the Boardroom hackathon, the list of proposals that should happen before the Commons Upgrade, and a Governauts meeting. Stewards reported a new sprint and a sprint retrospective. Transparency pointed to a Discord roles document and Transparency WG manifesto.
August 28 to August 31, 2021
Follow-up discussion pointed people toward the live Commons Configuration Dashboard and encouraged community members to try it, find bugs, suggest improvements, and open GitHub issues with screenshots. Later clarification noted that a newer August 28 weekly update had been posted, but the thread remained useful as a record of the dashboard’s early public testing moment.
By the end of the thread, TEC had entered a new rhythm after the Hatch. The update connected Hatch closure, Hatcher rewards, Hatch Outreach wind-down, Gardens testing, Gravity support, Graviton training, covenant work, 0mega’s manifesto, CCD development, proposal intake, sprint planning, Discord role documentation, and dashboard bug reporting into one operational snapshot.
2021-08-24 to 2021-11-03 — 75% Governance Giveback
Forum thread: 75% Governance Giveback Category: Advice Process / Archive Archive theme: governance giveback, Impact Hours, paid contributors, Praise Debate, Snapshot, non-transferable governance, Conviction Voting, Commons Upgrade
August 24, 2021
This advice process thread proposed a 75 percent governance giveback to paid contributors whose Impact Hours had been reduced during the Praise Analysis process. The proposal grew out of the earlier Impact Hour Intervention and Praise Debate, where the community had been divided between two claims: that paid contributors should not be double rewarded with both money and tokenized Impact Hours, and that large deductions removed governance voice from people who had contributed deeply to the TEC.
The proposed compromise would restore 75 percent of the deducted governance rights without restoring monetary value. The idea was to give back some of the voting voice that had been earned through work but removed because of financial compensation. The proposal listed the affected group, estimated the total governance giveback at about 191,876.95 TEC-equivalent voting rights, and framed the action as a governance repair rather than a token reward.
The technical section identified several possible implementation paths. A quick solution would mint governance power while locking it permanently so it would not affect the bonding curve, but this was described as inelegant and potentially confusing. A slower solution would create a separate non-transferable governance token that could work alongside TEC in Conviction Voting, but that required new tooling. The proposal left room for another better technical solution and asked that technical implementation be explored openly by the relevant development groups if the community supported the governance direction.
August 25 to September 16, 2021
Early responses raised strong technical and governance concerns. One line of feedback argued that there was no quick and safe way to implement the giveback before the Commons Upgrade without introducing risk to the bonding curve or redesigning significant parts of the governance stack. Another line of feedback supported the intention but questioned whether additional governance power should be returned to individuals at all, suggesting that a communal governance pool or expert-guided mechanism might be more strategic than individual allocation.
The discussion then expanded into a deeper debate about governance design. Some participants warned that concentrating governance power in an expert committee could create bureaucracy, privilege, or capture. Others argued that separating governance power from monetary value was an important frontier for token engineering and that the TEC should explore mechanisms that reward earned voice without granting extractable financial value.
By early September, a possible technical direction involving a hooked token manager or voting aggregator had emerged, and the proposal shifted toward a Snapshot signal vote. The question was narrowed to whether the community supported funding and implementing a technical solution for a 75 percent governance giveback, with detailed implementation left to the development process and bundled into the Commons Upgrade if ready. The voting format, threshold, and whether the decision belonged on Snapshot or Hatch DAO were also debated, because the proposal might affect technical architecture and governance rights.
September 20 to September 29, 2021
The Snapshot proposal was prepared and then published using single-choice voting to better reflect the Hatch DAO voting distribution. The final wording asked whether the community supported funding and implementation of a technical solution that would make a 75 percent governance giveback to paid contributors whose Impact Hours had been deducted before the Hatch. It specified that 5,000 wxDai would support Commons Swarm development and that the technical implementation would be proposed to the Hatch DAO because it involved token minting and bonding curve-related architecture.
As voting closed, a late round of discussion reopened concerns. Some participants worried that a permanent non-transferable governance allocation would add centralization to the TEC before it had even launched. A suggested alternative was to bind the additional governance power to a time-limited period and progressively burn it away, allowing the giveback to honor past sweat equity without permanently altering the governance system. Other comments argued that the problem had been compensation, not governance, and that solving it through permanent voting power could undermine the clean slate of the Commons.
After the vote, the thread reported strong approval, while also acknowledging that late objections should still be taken seriously. The discussion converged around further research through Soft Gov and Commons Swarm, with interest in the progressive-burn idea as a more elegant way to limit long-term centralization. The quick and dirty solution was rejected by technical review, and the likely path shifted toward a more careful implementation.
November 3, 2021
A final update stated that the proposal would not be fully implemented before the Commons Upgrade. The update also noted that Conviction Voting smart contracts were expected to be upgraded in a way that would make this and related configurations easier later. The likely path became post-upgrade configuration through TAO Voting, potentially adding a second non-transferable token as a voting token after launch, with the necessary precursors prepared in advance.
By the end of the thread, the 75 percent Governance Giveback had become one of the TEC’s most important governance design debates. It connected the unresolved ethics of paid work, Impact Hour deductions, governance voice, financial value, technical safety, centralization risk, Snapshot signaling, Conviction Voting architecture, and the Commons Upgrade timeline into a single question: how can a DAO repair an unfair distribution without permanently compromising the governance system it is trying to build?
2021-08-24 to 2021-09-17 — Reward System Moving Forward
Forum thread: Reward System moving forward Category: Advice Process / Archive Archive theme: rewards system, Praise, SourceCred, Alexandra, Reward DAO, quantifiers, TEC token rewards, contributor compensation, cultural insights
August 24, 2021
A proposal opened a broad discussion about how the TEC reward system should evolve after earlier Praise analysis revealed several operational weaknesses. The thread framed the problem as both logistical and cultural: Praise quantification was time consuming, only a small number of volunteers were doing the work, the dataset was difficult to clean, and Praise was beginning to overlap with SourceCred by rewarding some of the same types of activity. Rather than treating the existing process as sufficient, the proposal argued for a more modular reward system that could combine subjective recognition, quantitative contribution data, and more regular analysis.
The proposed system moved Praise quantification toward a partially asynchronous process. Praises would be exported, split into separate files or sheets, randomly assigned to multiple quantifiers, recombined, and analyzed with automatically generated metrics such as Gini coefficients, histograms, and other useful summaries. A short sync call would then be used for questions, reflections, and cultural interpretation, followed by a brief public report every two weeks. This was intended to reduce bottlenecks, make the process more transparent, and create a recurring rhythm of learning from reward data.
The proposal also described a more integrated tool stack. SourceCred would continue capturing activity such as GitHub and forum contributions, Praise would increasingly focus on subjective or qualitative contributions, and Alexandra would eventually capture time spent in Discord calls. Rewards would be distributed through the existing Reward DAO instance in TEC tokens, with the SourceCred Committee evolving into a broader Reward System Committee. The intended effect was not just compensation, but movement in the TEC token economy and a clearer governance voice for contributors receiving TEC through their work.
August 26 to September 1, 2021
The first responses asked how the proposed reward research would begin and whether its timeline depended on formal proposal outcomes. A follow-up suggested that the community should run dry runs before the Commons Upgrade, since the Reward DAO would not have real funding until then. This shifted the discussion from abstract design to operational rehearsal: the thread explored whether Twitter activity should be treated as quantifiable data, how praise sheets should be randomly assigned while excluding self-related praise, and how scores should become token allocations.
The discussion then focused on the full journey from a funded Reward DAO to TEC arriving in contributor wallets. One response suggested testing the process with test tokens, while another argued that a written thought exercise might be enough if it clearly documented every step. The thread also surfaced interest in becoming a quantifier, showing that the proposal could broaden participation by turning reward administration into a distributed role rather than a burden held by a few people.
A deeper critique supported decentralizing reward work and using SourceCred, while warning against simply copying an existing configuration. The point was that a TEC-specific SourceCred instance should be shaped by the Commons’ own values, culture, and desired behavior. This pushed the thread beyond tooling and into mechanism culture: reward architecture was described as something that would influence how people relate, contribute, and interpret value inside the Commons.
September 8 to September 17, 2021
By early September, the proposal had moved into modeling. A modeling session created an overview of how the proposed components connected, giving the community a shared map for further discussion. A later proposal debate captured the main unresolved questions: whether Twitter should continue to be rewarded, how qualitative inputs should be analyzed, how quantifiers should be chosen, whether quantifiers should be compensated, whether Praise could stand alone, and how SourceCred could fit without flattening or misreading qualitative work.
The debate notes emphasized mutual monitoring and transparency as the most important safeguards. SourceCred was seen as a strong incentive-alignment tool, especially if it could ingest additional sources such as Twitter through external plugins, but the community remained concerned about the balance between quantitative and qualitative signals. The phrase “set up and go” captured the practical mood of the discussion: build enough structure to test the system, but do not let unresolved perfectionism prevent experimentation.
By the end of the thread, the reward system had been reframed as a time-limited experiment rather than a permanent institutional decision. The final direction favored adding SourceCred alongside Praise, but with a finite trial window and the expectation that the community could remove, keep, or adjust it based on what happened. The thread therefore became an important bridge between the early Praise-based culture of recognition and a more integrated post-Hatch reward infrastructure that combined subjective praise, quantitative contribution data, token distribution, and recurring governance review.
2021-08-24 to 2021-11-03 — One-Time Change of TECH Addresses
Forum thread: One time change of TECH addresses (as requested by owner because access was lost or another reason) Category: Conviction Voting / Archive Archive theme: TECH address changes, wallet recovery, Hatch DAO vote, Snapshot signaling, Trusted Seed verification, burn and mint, EVM-Crispr, governance operations
August 24, 2021
This thread opened an advice process for a one-time proposal allowing TECH holders to change the address associated with their tokens if access was lost or if another legitimate reason required it. The proposal was framed as a human-centered response to wallet mistakes during the Hatch period: several people had lost keys or wanted to switch addresses, and the community wanted to preserve their ability to participate in upcoming decisions.
The proposed process was deliberately limited in scope. The community would allow a request window, burn TECH from the old addresses, remint the same amount of TECH to specified new addresses, and ask the Commons Stack to do the same for CSTK. A Snapshot signal vote would happen first to avoid paying the Hatch DAO tollgate fee without community backing; if the signal passed, a formal Hatch DAO proposal would follow. The proposal emphasized that future address-change requests would not be covered by this one-time action.
August 27 to September 4, 2021
The first round of feedback supported the intent but raised abuse and transparency concerns. One response said the proposal should only be supported if the number of wallets burned matched the number of wallets minted and if the implementation was transparent. The proposal discussion then explored whether people could sign with their old address when they still had access, while acknowledging that this would not help those who had actually lost keys.
The debate became a broader reflection on trust, identity, and care in a Web3 community. Some participants supported the proposal because wallet mistakes were likely for newcomers and the TEC still had a curated Hatcher list. Others warned that address control is closely tied to identity, that address changes could create risks of abuse or coercion, and that the exception should be one-time only. The response in favor of the proposal emphasized that an 88 percent support threshold would give the community a strong ability to block the action if it felt unsafe.
A later comment framed the decision as a “trust but verify” moment rather than a “sorry for your loss” posture. Another suggested that receiving a second chance in an irreversible blockchain environment should not be taken lightly and floated the idea of a surcharge or written explanation as a disincentive against careless or abusive requests.
September 8 to September 28, 2021
The proposal was revised to incorporate feedback. The updated version specified that requesters would share the reason for the change, the old address, and the new address with a small verification group. The plan also added a transparency step: the old and new addresses to be burned and minted would be posted publicly before the Hatch DAO vote, giving the community a chance to object.
By mid-September, three TECH holders had requested address changes. The proposal listed the corresponding burn and mint amounts and confirmed that the same amounts would be moved from old addresses to new addresses. By late September, the final addresses were reconfirmed after a delay caused by an address mismatch. The technical implementation was then shared as an EVM-Crispr script that would reimburse the 1,000 wxDai tollgate fee and burn and mint equal amounts of TECH, effectively transferring the tokens to the new addresses.
The Hatch DAO vote then went live. The thread noted that this was the TEC’s first official vote and the first vote made with EVM-Crispr, making the address-change proposal both a wallet-recovery action and a milestone in TEC governance execution.
September 29 to November 3, 2021
After the vote went live, follow-up comments helped voters work around interface bugs, reminded them to have xDai for gas, and clarified that the displayed clock was inaccurate because of xDai block timing. A later update explained that an additional vote was needed because the voting app did not yet have the permissions required to mint and burn tokens. The extra vote would reimburse the tollgate fee and grant the necessary mint and burn permissions so the earlier address-change vote could execute.
On November 3, the thread recorded that the vote had been executed. By the end of the thread, TEC had used its governance process to resolve a sensitive operational problem: preserving Hatcher voting rights while maintaining public transparency, equal burn-and-mint accounting, verification safeguards, and formal Hatch DAO execution.
2021-08-25 to 2024-07-19 — TEC Community Covenant
Forum thread: TEC Community Covenant Category: TEC Strategy & Governance Archive theme: Community covenant, social contract, governance norms, Gravity, Celeste, Guardians, accountability, transparency, Optimism migration
August 25, 2021
A draft of the TEC Community Covenant was published as a foundational social contract for the Commons. The thread framed the covenant as both a manifesto for the community and a practical reference for future dispute resolution. It was intended to help token holders understand the community’s values and to help dispute-resolution actors evaluate whether onchain proposals aligned with TEC’s norms.
The covenant described TEC as a self-governed organization advancing the field of token engineering through ethical, safe, resilient, and diverse economic systems. It emphasized the relationship between an economic layer, which funds token engineering public goods, and a social layer, which unites the field around ethical principles, standards, tools, and methods. It rooted TEC’s cultural framework in Ostrom’s commons principles and named prosocial behavior, integrity, curiosity, constructive inquiry, consistency, presence, gratitude, transparency, openness, non-hierarchy, and accountability as important community values.
The document included a pledge to make participation in TEC harassment-free and welcoming for everyone. It listed examples of constructive behavior, such as empathy, respect, constructive feedback, accountability for mistakes, and focus on the community’s wellbeing. It also listed unacceptable behavior such as harassment, doxing, trolling, personal attacks, and conduct inappropriate for a professional setting.
The covenant also described governance and enforcement. Onchain decision making was connected to the Gardens framework, Conviction Voting, and Tao Voting. Conviction Voting was described as the funding-allocation mechanism, while Tao Voting was described as the mechanism for parameter changes, technical changes, and emergency actions. Enforcement through Celeste was described as a future onchain dispute process in which proposals could be challenged if they appeared misaligned with the covenant.
Offchain governance was described through the advice process and community signaling tools. The covenant also positioned Gravity as TEC’s cultural enforcement and conflict-support mechanism, with graduated sanctions used to address violations of community norms. Transparency was described as a cultural practice supported by recorded calls, audits, credentials management, and visible administrative practices.
September 2021 to December 2021
The discussion that followed praised the covenant while focusing on clarity and enforceability. Feedback asked whether proposal deposits would be returned if a challenged proposal was withdrawn, whether “participants” in dispute resolution should be specified as Celeste keepers, and whether the advice process language needed to be clearer. The thread also questioned whether the onchain/offchain distinction was the best framing for governance, since decision making and governance are broader than the tools used to administer them.
Several suggestions pushed the covenant toward a clearer layered framing. Instead of treating onchain and offchain as the main conceptual divide, the discussion suggested distinguishing between smart-contract, funding, cultural, and governance layers. This would keep attention on the type of decision and its social meaning rather than only on where the vote or mechanism was administered.
The thread also discussed the relationship between the covenant and legal enforceability. Some feedback argued that the covenant was a strong preamble or social document, but that a legally enforceable agreement would require clearer rights, responsibilities, signatories, or assent mechanisms.
On December 7, an updated version of the covenant was posted incorporating feedback. The revised version simplified the governance section by referring to the polycentric governance framework, clarified that Celeste keepers would evaluate disputes, separated DAO enforcement from cultural enforcement, and made Gravity’s role in cultural enforcement more explicit. The updated covenant also continued to state that changes should go through the community advice process and Tao Voting.
June 2022 to June 2023
A later legal review update added proposal terms and conditions, other agreements, and an accountability section. This version made clearer that people submitting or challenging proposals were agreeing to be bound by TEC’s terms and conditions. It also expanded the covenant beyond behavioral norms and enforcement into expectations around accountability, including planning, reporting, progress updates, mutual monitoring, and stewardship of resources.
A follow-up supported the covenant update while noting that the accountability section should continue to be developed. The point was that accountability should be tied more directly to TEC’s mission and economic sustainability, and should become as clear and mature as the sections on standards and enforcement.
In June 2023, the thread was revived because IPFS issues had caused the covenant content to be lost and it needed to be reuploaded. A new vote was opened to restore the covenant with the same content.
November 2023 to July 2024
The covenant was updated again in connection with TEC’s planned migration to Optimism. The new version reflected changes the migration would introduce to TEC’s social, cultural, and governance architecture. The update removed references to Celeste as the DAO enforcement mechanism and replaced that role with Guardians in the Optimism-era Tao Voting architecture.
The revised covenant described Guardians as a safety mechanism rather than an ordinary approval body. Their role would be to protect the Commons against proposals that created legal, financial, social, or security threats, including proposals designed to extract value from the Common Pool in ways that violated TEC’s mission, vision, or values. Guardians would have the power to veto or delay proposals after a successful vote, but would need to explain vetoes publicly on the forum.
The updated covenant also removed Gravity as a TEC working group responsible for cultural enforcement, since Gravity had become its own entity. Instead, the covenant referred more generally to graduated sanctions and noted that the community could still reach out for support when needed. It also revised expectations around accountability for funded contributors and updated transparency practices.
On December 5, the vote to update the covenant for the Optimism migration went live. On December 14, the vote was reported as passed, with the new covenant set to take effect after the migration to Optimism. The thread was later pinned in July 2024.
By the end of the thread, the TEC Community Covenant had evolved from an early cultural manifesto into one of TEC’s core governance documents. It recorded the community’s shared values, behavioral standards, decision-making references, dispute-resolution assumptions, accountability expectations, transparency practices, and later the transition from Celeste and Gravity-based enforcement toward an Optimism-era Guardian model.
2021-08-25 to 2021-09-16 — Should We Do the Initial Buy Into the Bonding Curve?
Forum thread: Should we do the initial buy into the bonding curve? Category: Advice Process / Archive Archive theme: Augmented Bonding Curve, initial buy, Commons Upgrade, Reward DAO, liquidity, DAO partnerships, treasury strategy, secondary markets
August 25, 2021
The thread opened an advice process around whether the TEC should use some of its own funds to make an initial buy into the Augmented Bonding Curve at the moment of initialization. The core argument was that buying at initialization would let the DAO acquire TEC at the earliest and likely lowest price, before bots, speculators, or other market actors could move the price. Because this would use funds that might otherwise be split between the Common Pool and Reserve Pool, the question had to be considered as part of the Commons Upgrade parameter strategy.
The initial post framed the decision around use cases for the TEC tokens acquired by the DAO. Possible uses included funding the Reward DAO for SourceCred and Praise rewards, token swaps or DAO-to-DAO partnerships, strategic value-aligned partners, secondary-market liquidity pools where fees could flow back to the Common Pool, and other community-submitted ideas. The thread therefore treated the initial buy not simply as a trade, but as a strategic treasury decision that could shape rewards, partnerships, liquidity, and governance distribution.
Early comments questioned whether some proposed uses duplicated the purpose of the Common Pool. If the goal was simply to fund TEC initiatives, one argument was that the community could instead choose Commons Upgrade parameters that allocated more money to the Common Pool. Others strongly supported the idea that TEC should hold its own token in the treasury and argued that the real question was how much to buy, not whether to buy.
August 27 to September 1, 2021
The discussion then broke down the main use cases. Funding the Reward DAO was seen as a way to provide runway for contributor rewards before the Commons Pool could fund rewards more sustainably, though some preferred a lightweight multisig-managed committee over a full DAO. DAO-to-DAO token swaps were described as a way to diversify the treasury and build nested-enterprise style partnerships, but they also raised questions about whether the TEC was effectively exchanging governance rights, speculating on partner tokens, or creating extra governance overhead.
Strategic venture participation drew more skepticism because value alignment, long-term governance consequences, and the non-financial contributions of such partners were unclear. Secondary-market liquidity emerged as one of the strongest use cases. Providing baseline TEC liquidity could support a healthier market, generate fees for the Common Pool, reduce reliance on external liquidity providers, and potentially strengthen the token’s price floor. The thread also raised a scholarship or prize-style use case for exceptional Token Engineers or people seeking education through TE Academy-like opportunities.
By the end of August, the thread had shifted toward practical modeling. Contributors wanted to understand how much TEC should be bought, what amount would avoid centralization concerns, what amount would avoid excessive slippage or discouraging outside buyers, and whether liquidity should be provided directly by the TEC or through partner infrastructure such as 1Hive-style liquidity mining.
September 6 to September 16, 2021
The later discussion clarified several assumptions. One question distinguished Hatchers receiving TEC through their Hatch conversion from actual purchases through the bonding curve; the Hatch conversion itself did not count as an ABC buy. Another clarification noted that Hatchers would still have governance rights during the Token Freeze period even if they could not withdraw or transfer their tokens.
The emerging recommendation was to keep the initial-buy decision simple. Rather than decide every future use immediately, the TEC could set a total initial-buy amount, allocate a portion to a known Reward DAO budget, hold the rest temporarily, and define a later decision process for token swaps, token sales, liquidity mining, or other opportunities after the Commons Upgrade. This would give the Commons Configuration Dashboard a concrete number for modeling the Reserve Pool, Common Pool, and first buy, while preserving optionality for future partner offers.
By the end of the thread, the initial buy had been framed as a treasury strategy question with multiple moving parts: contributor rewards, liquidity, partnerships, market stability, governance risk, slippage, and Commons Upgrade parameter modeling. The thread did not reduce the issue to a single use case. Instead, it pushed the TEC toward separating the decision to buy TEC early from the later decision of how to deploy those tokens.
2021-08-25 to 2021-08-28 — The Commons Configuration Dashboard
Forum thread: The Commons Configuration Dashboard Category: TEC / Archive Archive theme: Commons Configuration Dashboard, Commons Upgrade, parameter configuration, Token Freeze, Token Thaw, Augmented Bonding Curve, Tao Voting, Conviction Voting
August 25, 2021
A TEC reference thread was published to introduce the Commons Configuration Dashboard as the next major product from the Params working group after the Hatch Dashboard. The dashboard was described as the tool the community would use to design, iterate, and propose parameter configurations for the Commons Upgrade.
The post explained that the CCD would provide educational resources for understanding how each component of the Commons works, intuitive modules for configuring launch parameters, graphs and tables for experimentation and analysis, and a standardized GitHub template for proposing and comparing Commons configurations. This framed the dashboard as both an educational interface and a governance tool.
The thread identified four main components: Token Freeze and Token Thaw, the Augmented Bonding Curve, Tao Voting, and Conviction Voting. It also noted that advanced settings would be available for power users who wanted to work with higher-level technical parameters. The post positioned the CCD as essential for moving beyond the Hatch and preparing the TEC for the Commons Upgrade.
August 28, 2021
A follow-up noted that the dashboard had already been deployed for the community to begin exploring. This turned the post from a preview into a live handoff point for community experimentation.
By the end of the thread, the Commons Configuration Dashboard had been framed as TEC’s main bridge from post-Hatch design into Commons Upgrade governance. The discussion connected parameter education, configuration modules, graphs, analysis, proposal templates, GitHub workflows, Token Freeze, Token Thaw, ABC design, Tao Voting, Conviction Voting, and advanced settings into one community-facing tool.
2021-08-27 to 2021-09-03 — TEC Labs Fall Semester
Forum thread: TEC LABS Fall Semester Category: Advice Process / Archive Archive theme: TEC Labs, fall semester, Proposal Inverter, rewards research, market models, NFT economics, lab administration, research programming
August 27, 2021
An advice process thread was opened to propose the TEC Labs fall semester program. The post outlined two primary initiatives for the semester: Proposal Inverter work from early August through late September, and rewards research from October through mid-November. It also proposed special topic labs on market models and networks, and NFT economics.
The proposal requested funding for lab administration and for the special topic labs, while noting that the larger research initiatives would have separate funding proposals and ecosystem partners. The schedule framed Labs as a structured semester with weekly Friday sessions, scopes of work, milestone presentations, research path identification, parallel research and development, collaboration, open slots, and a final semester review before a winter break.
The Proposal Inverter portion was organized around specification, models, simulations, documentation, and testing. The rewards research portion was expected to cover resource indexing, Praise data, SourceCred, additional datasets, research paths, and parallel research. This made the Labs program both educational and productive: it would teach, coordinate, and produce applied token engineering research.
September 3, 2021
A follow-up adjusted the schedule so that the planned market models session would instead begin the rewards research work, partly because a related governance panel was happening around the same time.
By the end of the thread, TEC Labs had a semester-based operating plan. The discussion connected Proposal Inverter development, rewards research, market models, NFT economics, administration funding, ecosystem partnerships, milestones, research collaboration, and semester review into one structured research and education program for the fall.
2021-08-28 — TEC Discord Roles
Forum thread: TEC Discord Roles Category: Community Updates Archive theme: Discord permissions, roles, onboarding, moderation, Gravity, Stewards, contributors, praise, terms acknowledgement
August 28, 2021
A community update was published to document the roles and permission levels used in the TEC Discord server. The post explained that as more contributors joined the server, the community needed clearer labels and permissions so people could understand who had what access and why. It framed the document as a transparency resource for Discord organization.
The thread described roles in descending order of permissions. Admins had full server permissions and were entrusted with server infrastructure. Gravitons had permissions connected to their conflict-management role and were described as people trained in nonviolent communication, Spiral Dynamics, and Ostrom’s principles. Stewards were described as community members with broad awareness of what was happening in TEC, with a nomination and approval process that allowed for blocks and Gravity mediation if concerns arose.
The document also defined Orientation Coordinators, who introduced new members into the community; Subject Matter Experts, who could be onboarded directly to specific working areas; Contributors, who were active in Discord and aware of the forum and calendar; Praise Givers, who could use the praise bot in a way that would be recorded and quantified; Acknowledged CC members, who had agreed to TEC terms and conditions; and New Members, who had joined but not yet acknowledged the terms.
By the end of the thread, TEC had made its Discord permission structure legible. The update connected server administration, conflict-resolution roles, steward nomination, onboarding coordination, expert contribution, contributor access, praise infrastructure, terms acknowledgement, and new-member restrictions into one public map of community permissions and responsibilities.
2021-08-28 — TEC Working Groups Weekly Update, August 28
Forum thread: TEC Working Groups Weekly Update, August 28 Category: Community Updates Archive theme: post-Hatch operations, education semester, Commons Upgrade dashboard, Graviton training, working group updates, Discord roles, platform admin code of conduct
August 28, 2021
A weekly Working Groups update was published with a focus on the upcoming September education period. The post emphasized that education was a core cultural practice for TEC and invited people into TEC Lab sessions on Proposal Inverters, market models, and NFT economies, as well as the next round of Graviton training for conflict-resolution skills. It also highlighted an Upala presentation on proof of personhood and reminded Hatch participants to claim their POAP and Hatch t-shirt.
Communications reported continued work on a potential Comms DAO funding model, a bi-weekly blog post, a post-Hatch “what comes next” article, and campaigns around Commons Upgrade parameters and Graviton training. Commons Swarm reviewed the Hatch to document improvements and invited testing in Gardens. Gravity promoted a ten-session Graviton training, clarified that Gravitons are access points for conflict support, and described the creation of an informal TEC Lounge.
Labs reported collaboration on the Proposal Inverter specification, rewards research with the Governauts, cadCAD study groups, and TokenSPICE development workshops. Legal noted that the Covenant was now on the forum and that treasury and sub-DAO treasury diversification discussions were emerging. Params reported a demo of the Commons Upgrade dashboard, updated Figma designs, and a forum highlight gathering the parameters people needed to know.
Soft Gov directed the community toward four important proposals that would need attention before the Commons Upgrade: the future rewards system, governance giveback, initial bonding curve buy-in, and one-time changes to TECH addresses. Stewards announced a Zenhub onboarding and a need for DevOps support for the swag shop. Transparency reported that the Discord Roles document was being finalized and that the platform admin Code of Conduct was under review by Legal and Gravity.
By the end of the thread, TEC was clearly in a post-Hatch transition period. The update connected education programming, Commons Upgrade preparation, Graviton training, proposal review, dashboard testing, rewards research, treasury conversations, tooling onboarding, swag operations, Discord role transparency, and platform access governance into one snapshot of late-August organizational development.
2021-09-02 to 2021-09-06 — TEC Twitter Tone and Community Representation
Forum thread: Question: How can our TEC Twitter account accurately represent our community? What tone do we want to portray? Category: Community Updates Archive theme: TEC Twitter, communications, social media tone, community representation, social curation, Comms WG, public voice
September 2, 2021
A community update thread was opened to ask how the TEC Twitter account should represent the community. The opening post acknowledged that one person could not easily represent the opinions of a whole group, especially on a public platform where conversations can quickly move from token engineering into unrelated or polarizing topics. The thread asked what tone, pace, and style the account should use, and where the account should draw boundaries around fringe conversations, trolls, spam, and off-topic engagement.
The post also proposed ways to make the Twitter account more community-driven. One suggested model came from another DAO’s social curation process, where community members could propose social posts in Discord, vote on them with emojis, and have successful posts published after a review window. This framed TEC’s Twitter not just as a broadcast channel, but as a possible participatory communications surface.
September 3, 2021
The discussion broadly supported the existing Twitter presence while encouraging more community voices to be brought into threads. One idea was to tag knowledgeable community members when the account did not have an answer, allowing them to speak as subject-matter authorities and grow their own visibility. Others argued that the human tone of the account was valuable and should not be replaced by a sterile brand voice, but that social media responsibilities should not fall too heavily on one person.
Several responses suggested building a small team around the question of Twitter voice, producing social media guidelines, and then seeking community agreement. This would reduce pressure on individual operators while creating a shared standard for tone. The proposed Social Curation channel received strong support as a way to gather posts, represent more voices, and make the account more collaborative. The desired account identity was clarified as a leading source of information and discussion about token engineering: informative, engaging, human, and connected to both established token engineers and the token-curious.
Later in the thread, the Comms structure was clarified: the Twitter account was managed by the Communications working group, with one person focusing especially on Twitter engagement and growth while others handled broader strategy and content. Short-term goals included community brainstorming and discussion, medium-term goals included better analytics and a Social Curation channel, and long-term ideas included contests, NFT-related experiments, and highlighting funded projects.
September 6, 2021
A final follow-up thanked the community for the feedback and invited ongoing comments, questions, and critiques about TEC Twitter.
By the end of the thread, TEC had used a social media question to articulate a broader communications governance problem. The discussion connected public voice, community representation, human tone, expertise routing, troll avoidance, social curation, Comms WG responsibilities, guidelines, analytics, SourceCred-compatible tooling, and the ambition for TEC Twitter to become a trusted token engineering discussion hub.
2021-09-04 to 2021-09-05 — Which TAO Voting Graph Is Better?
Forum thread: Which Tao Voting Graph is better? Category: CCD Parameters / Archive Archive theme: Commons Configuration Dashboard, TAO Voting, data visualization, Figma prototype, dashboard UX, parameter communication
September 4, 2021
A Commons Configuration Dashboard thread was opened to ask the community which TAO Voting graph design was better. Two visual options were shown, each representing the same general dashboard concept in a different layout, and the community was invited to compare them through a simple poll while reviewing the broader Figma prototype for context.
The thread treated parameter visualization as a governance design question. The issue was not only whether the graph looked attractive, but whether the dashboard could present complex TAO Voting information in a way that was clear enough for community members to use while making configuration decisions.
September 5, 2021
Follow-up discussion favored the nested graph design because it appeared to show the same information with less visual clutter and a more appealing visual structure. The thread also acknowledged implementation constraints: the preferred design was harder to build with the available frontend library, so it would likely be changed eventually but could be deprioritized until the rest of the dashboard modules were usable.
By the end of the thread, TEC had used a small design decision to surface a larger product-development tradeoff. The discussion connected community preference, visual clarity, graph aesthetics, Figma prototyping, frontend implementation limits, and development prioritization into one CCD user-interface decision.
2021-09-06 — TEC Working Groups Weekly Update, Sept 6
Forum thread: TEC Working Groups Weekly Update, Sept 6 Category: Community Updates Archive theme: pre-Commons Upgrade governance, Comms DAO, Params September, Commons Configuration Dashboard, Snapshot signaling, Graviton training, Proposal Inverter, rewards research
September 6, 2021
A weekly Working Groups update was published around the DAO decisions that needed attention before the Commons Upgrade. The post pointed the community toward active discussions and upcoming votes on the rewards system, governance giveback, address-change accommodations, and whether to make an initial buy into the bonding curve. It also highlighted a community call spotlight on the Comms DAO proposal.
Communications reported the Comms DAO concept as a public good for token engineering, a new post about what comes after the Hatch, and the launch of the Params September campaign. Commons Swarm shared work on a plug-and-play bonding curve and the alpha release of EVMcrispr for DAO parameter changes. Gravity continued to promote the upcoming Graviton training and the TEC Lounge as an informal community space.
Labs reported continued collaboration on the Proposal Inverter with Curve Labs, rewards research with the Governauts, cadCAD study groups, and TokenSPICE development workshops. Legal noted discussions about TEC treasury and sub-DAO treasury diversification. Params reported ongoing Commons Upgrade dashboard work, including the recent demo, design validation, frontend and backend work, and parameter documentation.
Soft Gov reported that the one-time TECH address change proposal was live on Snapshot for a community signal vote, with the possibility of moving to an official Hatch DAO vote if the signal was strong. Stewards pointed people to Sprint 17 and repeated the need for DevOps help with the TEC swag shop. Transparency reported that Snapshot was being test-driven for community signaling.
By the end of the thread, TEC’s post-Hatch work had shifted strongly toward pre-upgrade governance coordination. The update connected pending upgrade votes, Snapshot signaling, Comms DAO, Params September, dashboard feedback, bonding curve tooling, Graviton training, Proposal Inverter work, rewards research, treasury discussions, sprint planning, and community catch-up into one September operations snapshot.
2021-09-06 to 2021-10-21 — Earn Interest on wxDai With Hatch Funds: TEC x Agave
Forum thread: Earn Interest on wxDAI with Hatch Funds - TEC x AGAVE Category: Advice Process / Archive Archive theme: Agave, wxDai, treasury yield, Common Pool, Reserve Balance, ABC risk, inter-DAO collaboration, treasury diversification
September 6, 2021
This advice process thread opened as the first of several TEC x Agave collaboration proposals. It emerged from the broader discussion about whether the TEC should make an initial buy into its own bonding curve and from the launch of Agave as a borrowing and lending protocol on xDai. The proposal suggested that the TEC could deposit some Hatch funds into Agave in order to earn passive yield while also supporting another xDai-aligned protocol.
The post separated the idea into two possible funding sources. The simpler path was to deposit a portion of the Common Pool, since those funds would support TEC initiatives and were unlikely to be spent all at once. The proposal estimated that depositing a sizeable share of wxDai could generate roughly 3 to 5 percent APY, producing additional funding for token engineering while increasing Agave’s liquidity. The more complex path was to place some of the ABC Reserve Balance into Agave, potentially increasing the value of TEC as interest accrued, but this introduced major technical and cultural questions around whether the ABC should use agwxDai, two base tokens, or a hybrid reserve structure.
The opening post leaned toward caution on the Reserve Balance option. It acknowledged the token engineering potential of using interest-bearing collateral, but warned that adding unfamiliar technical and economic layers before launch could confuse users and create unforeseen consequences. The initial discussion therefore framed Agave as both an opportunity for passive income and a test case for how much complexity the TEC should introduce into its core economic system before the Commons Upgrade.
September 8 to September 12, 2021
Follow-up analysis argued that staking a substantial amount of wxDai in Agave could benefit both communities. The TEC could earn annual income for additional token engineering work, while Agave would gain liquidity and stronger borrowing markets. At the same time, the discussion emphasized risk: smart contract risk, Agave governance risk, and the possible harm of withdrawing a large amount of liquidity too quickly if Agave became dependent on TEC deposits.
A technical pathway was proposed in which the Common Pool and Reserve could hold both wxDai and agwxDai in target ratios, with supporting contract work keeping the user-facing experience in wxDai. This could allow the TEC to earn yield while periodically rebalancing without forcing ordinary ABC users to interact with a new asset. The proposal also introduced the possibility of an orderly exit mechanism to avoid a bank-run effect on Agave.
A reply pushed back on integrating Agave too deeply before launch. It argued that the TEC still had not fully introduced the basic bonding curve concept to the broader community, so adding a second base currency or interest-bearing reserve asset could become a blocker. A simpler near-term proposal emerged: use only Common Pool funds, perhaps 30 to 40 percent, to hold agwxDai, while leaving the ABC reserve and user flow unchanged.
September 14 to September 18, 2021
The debate increasingly converged around simplicity. Several responses supported keeping the first ABC launch as simple as possible and avoiding new dependencies inside the core economy. The concern was not only technical risk, but also governance risk: Agave was a young protocol, and the TEC would need to understand how Agave made decisions before making a deep dependency part of the TEC’s economic base layer.
The more conservative path was to treat Agave exposure as treasury diversification rather than ABC redesign. One favored approach was to hold agwxDai in a subDAO or external treasury-management structure outside the core ABC, with clear rules for how funds would move back into the Common Pool. This would let the TEC experiment with yield, support xDai ecosystem projects, and learn from the collaboration without complicating the initial Commons launch.
October 2 to October 21, 2021
Later updates kept the proposal alive by noting that Agave had received xDai community rewards intended to bootstrap its total value locked, which could make the opportunity more attractive from a return perspective. A follow-up clarified that the TEC still needed to settle important parameters, especially how much would be used for the initial TEC buy and how much Hatch funding would go into the Common Pool, before any Agave allocation could be estimated responsibly.
The final update reported that Agave’s TVL was growing gradually and that further reward deployment was expected. The discussion was then redirected toward the broader fund-management and initial buy-in conversation, showing that Agave yield had become part of a larger treasury-management question rather than a standalone decision.
By the end of the thread, the TEC had not committed Hatch funds to Agave, but it had clarified the likely boundary conditions: avoid modifying the ABC before launch, consider Agave exposure as Common Pool or subDAO treasury diversification, understand governance and smart contract risks, and treat inter-DAO financial integrations as promising but requiring careful sequencing.
2021-09-06 — Allow TEC to Be Lent and Borrowed: TEC x Agave
Forum thread: Allow TEC to be Lent and Borrowed - TEC x AGAVE Category: Advice Process / Archive Archive theme: TEC token utility, Agave, lending and borrowing, inter-DAO collaboration, oracle infrastructure, collateral markets, token economics
September 6, 2021
An advice process thread was opened as part of a broader exploration of economic and inter-DAO opportunities between TEC and Agave. The post explained that the earlier discussion about making an initial buy into TEC’s own bonding curve had led to further thinking about how TEC could use the momentum from a successful Hatch to explore new economic relationships. Agave had recently launched as a borrowing and lending protocol on xDAI, making it a potential partner for experimenting with TEC token utility.
This thread presented the third proposal in that collaboration set: listing TEC on Agave so that TEC could be lent and borrowed. The post argued that allowing TEC to become a borrowable and lendable asset could create new use cases, increase economic utility, and potentially increase perceived value of the token. It framed Agave’s longer-term vision as supporting more dynamic collateral bases beyond the standard pool of highly liquid assets.
The thread also identified major technical constraints. Agave relied on Chainlink oracles for token data, and Chainlink whitelisting required a level of exchange listing and daily volume that TEC could not realistically satisfy at that stage. This meant that the proposal could not be implemented in the near or medium term unless Agave developed more self-reliant oracle infrastructure. The post suggested that TEC could help with this research and development process as a token engineering contribution.
The opening questions asked what the use cases would be for borrowing and lending TEC, how the Commons would benefit, whether TEC should commit resources to help Agave solve the oracle challenge, and whether TEC should deposit its own tokens as collateral.
By the end of the thread, lending and borrowing TEC had been framed as a speculative but strategically meaningful research direction. The discussion connected TEC token utility, Agave collaboration, borrowing and lending markets, collateralization, oracle limitations, Chainlink requirements, research contributions, and inter-DAO economic experimentation into one proposed path for expanding TEC’s post-Hatch economy.
2021-09-07 to 2021-12-28 — Second Graviton Training Study Plan
Forum thread: Second Graviton training study plan Category: Community Updates Archive theme: Gravity, Graviton training, conflict transformation, mediation, organizational design, NVC, decolonization, Ostrom, restorative justice, continuous learning
September 7, 2021
This community update thread published the study plan for the second season of Graviton training. The plan described a ten-session course beginning September 21 and ending November 23, with weekly Tuesday sessions, pre-learning, facilitator-led presentations or workshops, optional homework, and POAPs for attendance. Participants who claimed at least six session POAPs could become Gravitons, meaning visible access points for community members seeking support with conflict, mediation, and difficult situations.
The methodology framed Gravity as a practice-oriented training path rather than a one-time lecture series. The goal was to give participants a study guide for processes that require continued education and practice, helping the community build competence around solving problems that arise in decentralized organizations.
The first sessions focused on contextualization, unified thinking, deliberate developmental organizations, conflict transformation, shadow integration, and dialogue. The curriculum then moved into organizational design and creating pathways for all, including flat-structure DAO dynamics, agency, role transitions, rituals of appreciation, advisor roles, supported hiatus or offboarding, knowledge-transfer tools, small groups, internal information pathways, facilitated spaces for difficult conversations, and inclusion in decentralized communities.
The training also included sessions on Nonviolent Communication, alternative dispute resolution, restorative justice, human resources in DAOs as resources for humans, and practical conflict-resolution process design. Later sessions covered decolonization, complexity, shadow work, Cynefin, psychology of human leadership, crisis and leadership, power asymmetries, Gravity process deep dives, input and observation forms, mediation forms, and mediator self-review. The final sessions addressed Ostrom’s principles, decision-taking, decision spaces, polycentric governance, TEC rules and boundaries, and mediation roleplay cases.
October 2 to November 3, 2021
Follow-up discussion clarified and supported participation. One participant asked whether an organizational-design resource was still being used after discovering a broken link. Another asked whether it was possible to join the next session, noting interest from another community and prior alternative-dispute-resolution experience. The response welcomed new participation and offered support for joining the training and related Nonviolent Communication book club.
A later question asked about a practical mediation homework resource. The response clarified that the link was intended as a continuing reference rather than a specific assigned exercise, and noted that the next session would enter into a deeper discussion of the Gravity processes being shaped.
December 27 to December 28, 2021
After the second training season had ended, a participant asked whether more Graviton programs were planned for 2022. The reply confirmed that another Graviton training was expected around the second quarter of 2022 and pointed people toward Gravity resources and the TEC Discord.
By the end of the thread, the second Graviton training had been documented as a full curriculum for conflict literacy, mediation, organizational design, leadership, restorative process, polycentric governance, and community support. The thread showed Gravity moving from informal support toward a repeatable education program for developing community members who could help DAO contributors navigate tension, harm, power, ambiguity, and decision-making.
2021-09-09 to 2021-09-16 — Decision-Making Guide
Forum thread: Decision Making Guide Category: Advice Process / Archive Archive theme: decision-making, quality consent, advice process, Snapshot, Tokenlog, voting methods, polycentric governance, governance tooling
September 9, 2021
An advice process thread was opened to gather feedback on a simple guide for how decisions should be made in TEC. The post asked whether the guide was easy to understand, whether anything was missing, and whether anything felt off. It organized TEC decision-making into several pathways depending on the kind of decision being made.
The first pathway was a Working Group Quality Consent Process. This applied to local working group decisions that could be made by the people closest to the implications, without requiring a formal advice process or community-wide vote. The thread framed this as a way to reduce attention costs for the whole community while preserving transparency through working group meetings, Discord, community calls, and steward meetings.
The second pathway was the Advice Process, where a person making an important decision seeks input from affected stakeholders and people with relevant expertise, then integrates that advice before acting. The thread described this as useful for financial proposals that may later go to Conviction Voting, as well as cultural agreements and practices. If feedback was clear and implementation was obvious, the proposer could move forward; if signal was unclear or concerns were raised, the proposal could be revised and moved to Snapshot.
The third pathway was Snapshot. The post described Snapshot as an off-chain, gasless voting tool and proposed it for cultural agreements, community signaling around on-chain proposals, ranked-choice or approval signals, and runoff votes from crowd proposal-making processes. The thread noted that TEC used an ERC20 balance-of strategy, meaning Snapshot votes were token-weighted and limited to TEC stakeholders.
The fourth pathway was Tokenlog, described as a token-weighted backlog tool that lets token holders continuously signal priorities rather than voting only on single proposals. The post connected Tokenlog to collaborative economics, Commons Upgrade parameter selection, and crowd proposal-making, where many people submit proposals on a similar topic and the top-ranked options move toward a later Snapshot decision.
September 11 to September 16, 2021
Feedback suggested that visuals or diagrams could make the guide easier to understand and that “collaborative economics” might be broader than a Tokenlog use case alone. The thread also asked for clearer guidance on when each Snapshot voting type should be used and raised the question of whether quadratic voting should be a default.
A later contribution expanded the guide with descriptions of Snapshot voting methods. Single-choice voting was framed as useful when one clear winner is needed or for simple yes/no decisions. Approval voting was framed as useful when voters can support multiple options, especially when several acceptable winners may exist, though it could distort outcomes if similar ideologies are represented by different numbers of options. Quadratic voting was framed as useful for cultural decisions that do not directly affect the financial layer, especially where the goal is to reduce the dominance of large token holders and reflect broader social preference. Ranked-choice voting was described as useful when one option must be chosen from many and the community needs a majority-supported final result. Weighted voting was described as useful for decisions affecting treasury management or token holders, where larger financial exposure may justify greater vote weight.
By the end of the thread, TEC had a practical map of decision pathways. The discussion connected working group autonomy, advice process, Snapshot signaling, on-chain voting, Tokenlog prioritization, crowd proposal-making, voting-method selection, financial versus cultural decisions, attention costs, and polycentric governance into one guide for choosing the right decision process for the right kind of choice.
2021-09-17 — Conviction Voting: Minimum Effective Supply
Forum thread: Conviction Voting - Minimum Effective Supply Category: Advanced CCD Parameters / Archive Archive theme: Conviction Voting, Minimum Effective Supply, Minimum Conviction, effective supply, edge-case protection, CCD advanced parameters
September 17, 2021
This advanced Commons Configuration Dashboard parameter entry explained why Minimum Effective Supply existed as a safeguard inside the Conviction Voting module. The post began by revisiting effective supply, defined as the number of tokens actively voting on proposals, and showed how Minimum Conviction is calculated as a percentage of that active supply. In a normal example, several active proposals together create enough effective supply that a proposal must attract a meaningful number of voting tokens before it can satisfy the Minimum Conviction requirement.
The entry then focused on the dangerous edge case the parameter was designed to prevent. Immediately after the launch of a Conviction Voting module, effective supply could be extremely small because few tokens might yet be actively voting. In that situation, a malicious or premature proposal could technically satisfy Minimum Conviction with only a tiny number of tokens, especially if the Conviction Growth parameter allowed it to accumulate conviction before the broader community could respond.
Minimum Effective Supply solved this by creating an assumed floor for effective supply. If the parameter were set to 1,000 tokens, then any proposal during a low-participation early period would still be evaluated as though at least 1,000 tokens were active, forcing it to meet a higher Minimum Conviction requirement. The post positioned this as a narrow but high-impact parameter: setting it too high could make legitimate proposals hard to pass, while setting it too low could leave the Commons exposed to early execution attacks.
By the end of the thread, Minimum Effective Supply had been framed as an advanced defensive configuration rather than an everyday governance lever. The entry connected it to Minimum Conviction, Conviction Growth, and Spending Limit, and advised that any deviation from the default should be justified as part of a broader design strategy.
2021-09-26 to 2021-09-27 — TEC Working Groups Weekly Update, Sept 26
Forum thread: TEC Working Groups Weekly Update, Sept 26 Category: Community Updates Archive theme: working group updates, Commons Upgrade preparation, orientation, Gravity training, Rewards Research, ABC legal terms, CCD demo, governance giveback, treasury management
September 26, 2021
This weekly update captured the TEC moving through a dense post-Hatch, pre-Commons Upgrade coordination period. Communications was working on a Twitter video campaign and highlighted external podcast coverage on participatory economics and public goods in DAOs. Commons Swarm reported that Gardens on xDai was live and that EVM-Crispr had reached version 1.0, signaling progress in the broader technical infrastructure surrounding the Commons ecosystem.
Communitas focused on orientation, including updates to the orientation bot and collaboration with Communications on an orientation video and dashboard. Gravity reported the successful kickoff of the second Graviton Training, with 58 people attending the first session, and noted that ZenHub would be used to manage the Gravity registry. Labs highlighted the Rewards Research Group, the Rewards Taskforce, and ongoing work on Coordinape, showing that the contributor-reward conversation had moved from crisis and debate into structured research.
Legal reported a new draft of Terms and Conditions for the ABC, while 0mega continued defining the ethos of Token Engineering and analyzing feedback from the first TE Ethics focus group. Params announced that the Commons Configuration Dashboard demo was ready and invited issue reports. Soft Gov reported cultural-concern mapping, progress on the reward system, the live 75 percent governance giveback Snapshot vote, and an upcoming change-of-addresses proposal in the Hatch DAO.
Stewards welcomed a new steward, shared a TEC timeline and working-group milestones reveal, and discussed working-group funding models during the Stewards Council. Transparency was working on a CoinGecko listing and researching DAO treasury-management best practices. By the end of the update, the TEC’s attention had spread across onboarding, governance repair, legal readiness, reward redesign, dashboard completion, treasury operations, and the broader infrastructure required for the Commons Upgrade.
September 27, 2021
A brief follow-up praised the clarity of the summary. The thread remained primarily an operational snapshot, documenting how many parallel workstreams were converging around the same transition: moving from the Hatch phase into a more fully operational Commons.
2021-09-30 to 2021-10-04 — Let’s Talk About Treasury Management
Forum thread: Let’s talk about Treasury Management Category: Community Updates Archive theme: treasury management, diversification, Hedgey, Zodiac, Gardens, Gnosis Safe, sub-DAOs, risk management, progressive decentralization
September 30, 2021
This thread opened after the Agave debate with a broader reflection on treasury diversification. The post argued that keeping all treasury savings in stablecoins carried long-term risk and that the TEC should explore strategies for managing funds in ways that fit the community’s values. The purpose was to present available treasury-management tools, compare their tradeoffs, and invite additional options.
The first option discussed was Hedgey, presented as a treasury-management and decentralized-options platform that could support stop losses, buy and sell orders, speculation, and early token purchases, while also noting the major caveat that its contracts were not audited. The second option was Zodiac, described as a progressive decentralization toolkit around Gnosis Safe that separates the asset-holding avatar from the modules, guards, and decision mechanisms that control it. This option introduced tools such as Reality, Bridge, Exit, Delay, Scope, and other modules that could allow the TEC to connect off-chain or cross-chain governance to on-chain treasury execution.
The third option was treasury management through Gardens and Conviction Voting. This path would keep more control in the hands of the community, allowing sub-DAOs or working groups to request funds through governance, while emphasizing the need for radical transparency and mutual monitoring. The thread also distinguished between a sub-DAO or working-group multisig and a larger treasury-management multisig, noting that the amount of funds controlled by each structure would matter.
A follow-up introduced a Yearn-style vault model as a favored ideal: community members could propose time-limited strategies, token holders could vote between them, and strategy creators could receive a percentage of profits. Since such a system was not readily available on xDai, the discussion returned to more feasible options, especially Zodiac and Gnosis Safe-based management. The thread also raised the question of who should sit on a treasury multisig, with one suggestion that high skin-in-the-game members could be selected because the existing process had already identified them as trusted.
October 3 to October 4, 2021
Later replies added OlympusDAO to the field of possible models and questioned whether an xDai-native Yearn fork would be realistic. Another option was to use Yearn itself through a mainnet Zodiac avatar controlled from xDai via the Bridge module, potentially with guards that strictly limited what the treasury avatar could do. This kept the discussion focused on reducing multisig discretion while still enabling more active treasury strategies.
A practical test of Gnosis Safe led to support for using it as a sub-DAO treasury tool. It was described as battle-tested, compatible with xDai dapps, intuitive, and extensible, even if not the most decentralized option. The final comments leaned toward a conservative but flexible approach: use reliable infrastructure, potentially combine Zodiac-style control with Gardens-style governance, and keep process and transparency central because the treasury would be critical to the TEC’s survival.
By the end of the thread, treasury management had been framed as both a financial and governance design problem. The TEC needed diversification and active strategy, but it also needed safeguards, clear execution processes, transparent monitoring, and a structure that balanced agility with decentralization.
2021-10-02 to 2021-12-23 — Outlining the Rewards System Process v2
Forum thread: Outlining the Rewards System Process.. v2! Category: Advice Process / Archive Archive theme: Rewards System, Praise, SourceCred, quantifiers, Reward Board, RAD dashboard, contributor rewards, ABC-funded distributions, transparency
October 2, 2021
This advice process thread outlined a second version of the TEC Rewards System. Its purpose was to create a fair way to record, reward, and analyze contributor work while also producing decentralized, real-time updates about activity happening inside the Commons. The system combined objective data streams with subjective praise and used decentralized quantification to reduce individual bias.
The first step was data collection. Contribution data would be gathered continuously and submitted for quantification on a biweekly schedule. Inputs were divided between automatically quantified streams, such as GitHub, Discourse, meeting attendance, and Twitter, and manually quantified streams, such as Discord and Telegram praise. The thread distinguished objective contributions that could be tracked automatically from subjective contributions that required community interpretation.
The second step was quantification. Automatic quantification would use SourceCred and bots to track selected actions, with the Reward Board responsible for changing weight configurations and making those weights visible. Manual quantification would use TEC-tailored praise bots and a randomly selected set of community quantifiers. Quantifiers would work asynchronously, evaluate overlapping portions of praise, and use a Fibonacci-style scoring range from zero to 144. Multiple quantifiers would score the same praise, and the average would become the final score.
The third step was analysis. After each quantification window, quantifiers could review praise data together, identify gaps in praise education or quantifier training, spot problematic quantification patterns, and use the Rewards Analytics and Distribution dashboard to cross-reference data. The fourth step was reward calculation, combining the quantified data to determine token distributions. The exact relationship between SourceCred and Praise, and the amount to distribute per round, were left for further parameter definition.
The fifth step was final approval by a Reward Board that would hold the Rewards System funds. The board would inspect final distributions, check for oversights or collusion, and vote to release funds. The initial design envisioned a three-to-seven-member board, formal nomination, inactivity-based offboarding, and community oversight through Snapshot for major changes. The board could change SourceCred weights, allocation percentages, SourceCred-to-Praise ratios, board membership tokens, and distribution percentages across contributors, quantifiers, and board members, while community votes would be required for significant metagovernance changes.
The sixth step was distribution. Rewards would be valued in DAI but paid in TEC, using the TEC Augmented Bonding Curve to convert treasury funds into TEC and inject contributors directly into the token economy. The example distribution used one percent of the Common Pool, with ninety percent going to contributors, seven percent to quantifiers, and three percent to the Reward Board, split between Praise and SourceCred. The final step was iteration: each round would produce a public forum post showing distributions and SourceCred weights, allowing the community to review and improve the system.
October 2 to October 15, 2021
Early discussion focused on who should become quantifiers, how much context quantifiers needed, and whether praise should be anonymized. One concern was that quantifiers benefit from knowing who is doing what work because it helps them understand the community, maintain continuity, and learn where contributions are happening. Another concern was that showing names could increase bias and turn praise into a popularity contest rather than a contribution assessment.
The thread settled into a tradeoff between objectivity and context. Complete anonymity could force quantifiers to focus on the work itself, but too little context could make it hard to distinguish duplicate praise, understand contributions across working groups, or support newcomer learning. The proposed compromise was pseudonymized praise receiver information during quantification, with configurable parameters later added around whether pseudonyms are used, how many quantifiers evaluate a praise receiver, and how many praise receivers each quantifier can handle.
The thread also clarified that the quantifier pool should have a low barrier to entry. The proposed requirements were simply being human, knowing what TEC is, and reading onboarding or Rules of Praise documentation. A larger and more diverse quantifier pool was expected to reduce subjectivity, prevent burnout, and give newcomers a paid way to learn what was happening in the community.
A roadmap to the first quant was then added. It included agreeing on goals, validating system design, presenting the design for community feedback, defining front-end and back-end requirements, beginning development, choosing the Reward Board, setting initial parameters, running simulations, ratifying initial parameters through Snapshot, making an initial funding request, and then running the first quantification round. The roadmap also identified open configuration questions such as total tokens per cycle, fixed versus variable budgets, contributor caps, distribution percentages, SourceCred-to-Praise ratios, SourceCred weights, pseudonym usage, and quantifier workload limits.
December 23, 2021
A later follow-up asked how the system would compare unlike contributions, such as development work versus communications work. The response clarified that the Praise system itself would not distinguish contributor types; contributions would be evaluated using the same general praise metrics. SourceCred, however, could separately weigh objective actions such as forum publishing, retweets, and GitHub commits according to what the community valued.
By the end of the thread, the Rewards System Process had become a full operating model for contributor rewards. It connected praise capture, SourceCred automation, pseudonymous quantification, quantifier onboarding, Reward Board governance, community oversight, ABC-funded TEC distributions, public reporting, and iterative analytics into a system designed to make contribution recognition fairer, more transparent, and more scalable after the Commons Upgrade.
2021-10-03 to 2021-10-04 — TEC Working Groups Weekly Update, Oct 3
Forum thread: TEC Working Groups Weekly Update, Oct 3 Category: Community Updates Archive theme: working group updates, Creative Onboarding, Hatch DAO votes, onboarding dashboard, Graviton Training, Rewards System Research, CCD validation, governance giveback, treasury management
October 3, 2021
This weekly update showed the TEC moving deeper into post-Hatch operations while preparing for the Commons Upgrade. Communications had begun a Creative Onboarding campaign to welcome artists and reduce the Web3 learning curve, continued audience analytics work, explored a new name for the Comms group, and started research on a Twitter scraping bot. Commons Swarm reported that the first Hatch DAO vote had concluded successfully, Gardens on xDai remained live, and EVM-Crispr continued improving after reaching version 1.0.
Communitas reported ongoing development of the onboarding dashboard and a new twice-monthly orientation model designed to work for both European and American time zones. Gravity continued the second Graviton Training, launched a Nonviolent Communication book club, and kept the training study plan visible. Labs focused on Rewards System Research and highlighted the Praise Evolution Task Force sync, showing that the reward-system redesign had become an active operational workstream.
Legal shared a new draft of ABC terms and conditions and invited people to join recurring legal framework discussions. 0mega worked on the Consilience Initiative, explored a Token Engineering library concept, continued processing TE Ethics focus group feedback, and prepared to use Amartya Sen’s Capability Approach as a framework for evaluating well-being. Params continued design validation of the Commons Configuration Dashboard, including a configuration summary module that could save parameter values and submit them to a GitHub issue, with a mid-October launch target.
Soft Gov reported that the Rewards System task force was ongoing, shared a roadmap to the first reward quantification, and noted that the 75 percent governance giveback vote had passed with 76 voters. Stewards noted the end of Sprint 18, the passage of the first Hatch DAO vote and governance giveback vote, and several strategic priorities: rethinking Medium’s communications role, exploring treasury management, improving onboarding, and connecting with Web3 projects for partnerships. Transparency highlighted the new treasury-management forum post and its biweekly syncs.
October 4, 2021
A brief follow-up praised the update as a strong overview of community activity. By the end of the thread, the weekly update captured a Commons in transition: governance repair had passed into implementation, the CCD was nearing launch, the reward system was being redesigned, onboarding was becoming more structured, and treasury management was becoming an explicit strategic focus.
2021-10-03 to 2021-10-20 — Communitas Working Group
Forum thread: Communitas Working Group Category: Working Groups / Archive Archive theme: Communitas, onboarding, community building, orientation, TEC Lounge, organizational design, ZenHub coordination
October 3, 2021
The thread introduced Communitas as the working group responsible for nurturing, growing, and guiding the TEC community. Its work was framed around three connected functions: new member orientation, current member community building, and organizational design. In practical terms, Communitas was meant to help people enter the TEC, understand where they fit, and navigate the community from the inside.
The post laid out recurring participation points for the working group. A weekly sync would handle agenda review, check-ins, feedback, and contributions to the growth of the group. A weekly orientation call would support new members, contributors, and anyone with questions about the TEC. A weekly TEC Lounge would provide a low-pressure social space with no work agenda, emphasizing that community building also required informal time together.
The thread also pointed participants toward the Communitas Discord channels, a working group manifesto, and ZenHub labels tracking current work around Communitas, orientation, and Hatcher relations. It made clear that the group was actively looking for contributors and that participation could begin through regular calls or by contacting working group stewards.
October 15 to October 20, 2021
A later response highlighted the energy around the TEC Lounge and the broader Communitas effort. The follow-up reinforced that the thread could also serve as a place to share the working group’s growth, not only as a static onboarding notice.
By the end of the thread, Communitas had been documented as the TEC’s dedicated community-navigation layer. It combined onboarding, social cohesion, contributor support, and internal wayfinding into a recurring set of practices that helped turn the TEC from a collection of workstreams into a more legible and welcoming community.
2021-10-06 to 2021-11-15 — Re-Imagining the Community Call
Forum thread: Advice Process - Re-Imagining the Community Call Category: Advice Process / Archive Archive theme: community call, praise, working group updates, TEC Spotlight, onboarding, call facilitation, community rhythm, Stewards decision process
October 6, 2021
This advice process thread opened a discussion about changing the TEC Community Call format. The problem was that community growth had made it increasingly difficult for the call to achieve its three goals within one hour: introduce and practice praise as part of the cultural build, communicate working group activity, and introduce the community to projects that the TEC might eventually help fund.
The post described the existing format as roughly twenty-five minutes of praise, twenty minutes of working group updates, and fifteen minutes for the TEC Spotlight. As the community grew, more people wanted to give praise, more working groups had important updates, and spotlight projects needed enough time to explain complex work. The thread framed the issue as a balance between timing, awareness, and purpose.
The proposal explored several alternatives. One option was to reduce the time for each person giving praise, though this was described as only a partial fix because transitions between speakers would still take time and timers could create social tension. Another option was alternating working group updates across weeks, which would allow more detail but might make the organization harder for newcomers to understand if they only saw a subset of working groups.
The proposed direction introduced “Super Praise,” where each person would give one specific praise during the call while being reminded to add additional praise in Discord. Working group updates would shift toward inspiration and orientation: explaining what each group does, when it meets, and how new members can contribute, while more detailed project updates would move to written posts unless they required full-community attention. The TEC Spotlight would ideally become a longer dedicated session after the Commons Upgrade, but in the near term the goal was to protect its full fifteen minutes.
October 7 to October 13, 2021
Early feedback supported the Super Praise idea and discussed possible platform and facilitation improvements. Some participants suggested shorter speaking times, a predictable order for passing the mic, and keeping all working groups represented in the same call while allowing lower-activity groups to present less frequently. Others emphasized that the call should preserve its community aspect: recognition, visibility, and the feeling of being welcomed mattered as much as efficiency.
The discussion also explored changing the call order. One suggestion was to move the spotlight earlier so it would not be squeezed by time pressure, and to end with praise so the call closed with positive energy. Another response emphasized that praise itself was a way of learning what people were doing across the organization, making it more than a ritual; it was also a form of distributed update-giving.
The advice process then moved toward decision-making. The original post committed to developing a proposed solution, soliciting input from selected subject matter experts, and bringing the final proposal to Stewards for a decision.
November 15, 2021
A later comment revived the thread with a survey to gather feedback from current members and participants. The response reframed the community call from a newcomer’s perspective: the call should make the organization understandable and help people identify which working group fits their skills and passions. Praise culture remained important, but the call’s practical objective was also recruitment and orientation.
By the end of the thread, the Community Call had been reframed as a key onboarding and coordination mechanism rather than a simple weekly meeting. The discussion connected praise culture, working group visibility, project spotlights, newcomer orientation, facilitation design, call sequencing, surveys, and Stewards decision-making into one broader question: how should a growing Commons preserve its culture while making its main community gathering scalable and useful?
2021-10-07 to 2021-12-13 — TEC Go-To-Market: DAO-to-DAO
Forum thread: TEC Go To Market - DAO to DAO Category: Advice Process / Archive Archive theme: DAO-to-DAO, go-to-market strategy, token engineering services, TEC tooling, network effects, prototyping, revenue, partnerships
October 7 to October 8, 2021
This advice process thread opened a go-to-market conversation around whether TEC should actively serve other DAOs with token-engineering tools and design support. The proposal was based on two simultaneous hypotheses. First, TEC contained deep token-engineering expertise and had developed valuable mechanisms such as praise infrastructure, Hatch parameters, and bonding curve issuance that other DAOs needed but did not yet understand well. Second, TEC might have been spending too much time dogfooding and over-engineering its own parameter design, while missing opportunities to learn faster by deploying its ideas in real external DAO environments.
The proposed strategy was to form a small three-week project team to evaluate whether TEC tooling could be offered to another DAO for income. The goal was not just consulting revenue; it was rapid prototyping. Working with an outside DAO could produce user feedback, expose TEC tools to other communities, attract token designers from those communities, generate DAO-to-DAO network effects, and potentially create sustainable income or token-swap relationships.
Early responses supported the idea and treated it as a potentially useful path for turning TEC’s internal work into external value. One response even offered a bounty-like incentive for someone to build a team around the initiative. The thread therefore framed DAO-to-DAO work as both market development and ecosystem service: the TEC could help other DAOs solve incentive problems while also testing and improving its own toolkit.
December 13, 2021
A later follow-up revived the discussion near the Commons Upgrade and asked whether the initiative had ever found an advocate or turned into an active effort. The follow-up reconsidered the original hypotheses in hindsight, suggesting that both could be true at once: TEC may have had uniquely valuable tooling and expertise, while also having spent a long time refining its own system internally.
The revived discussion asked whether TEC’s tooling assets could become a future source of revenue and exposure, whether the DAO-to-DAO idea should have been pushed harder, and whether the community might have learned more by subsidizing outside groups to test and review its tools before the Commons Upgrade.
By the end of the thread, DAO-to-DAO go-to-market work remained an open strategic question rather than a completed initiative. The thread captured an early recognition that TEC’s value might not only be in launching its own Commons, but also in helping other DAOs adopt, test, and pay for token-engineering practices in the wild.
2021-10-09 to 2021-10-10 — What Is the Kids Education Fund?
Forum thread: What is the Kids Education fund? (snapshot proposal) Category: Feedback and Questions / Archive Archive theme: Snapshot proposals, spam prevention, Hatch DAO, proposal permissions, TECH token gating, governance hygiene
October 9, 2021
The thread opened when an unexplained Snapshot proposal about a Kids Education Fund appeared without any obvious supporting context in the forum or Discord. The question was not about the merits of the fund itself so much as the governance situation it exposed: a proposal had appeared in a formal voting venue, but the community could not identify its origin, rationale, or relationship to existing TEC discussions.
The first responses treated the proposal as likely spam or a troll proposal. This quickly turned the thread from a question about one proposal into a question about proposal hygiene: how the TEC should respond when proposals appear without community context, recognizable authorship, or a clear relationship to ongoing governance work.
October 10, 2021
Follow-up checking suggested that the proposer was not on the Hatcher list. The immediate operational response was to change proposal-creation permissions so that only addresses holding at least one TECH token could create Snapshot proposals. Because TECH was only held by Hatchers at that stage, the change was expected to reduce spam while keeping proposal creation accessible to the intended community. A later version of the same idea could use a TEC threshold once the Commons was live.
The thread also raised a governance-culture question: whether suspicious proposals should be ignored, deleted, or left visible as part of learning how DAO governance works. The response leaned toward ignoring clear spam while recognizing that, in a real DAO environment, proposals cannot always simply be erased. Participants would need to learn how to identify low-quality or malicious proposals, while the system would need permission rules that made spam harder to create in the first place.
By the end of the thread, the incident had become a small but practical governance-hardening moment. The TEC moved from noticing an unexplained Snapshot proposal to adding token-gated proposal creation, while also acknowledging that on-chain and off-chain governance systems require both technical controls and community judgment.
2021-10-10 to 2021-10-11 — TEC Working Groups Weekly Update, Oct 10
Forum thread: TEC Working Groups Weekly Update, Oct 10 Category: Community Updates Archive theme: working group updates, Creative Onboarding, onboarding accessibility, Graviton Training, Rewards System, ABC terms, CCD validation, Snapshot spam, Boardroom, treasury management
October 10 to October 11, 2021
This weekly update showed the TEC continuing to refine the operational systems needed for the Commons Upgrade while also responding to immediate governance issues. Communications continued the Creative Onboarding campaign for artists, discussed a possible new working group name, and began developing a framework for communications bounties and project management. Communitas focused on making the onboarding journey more accessible and continued work on an onboarding bot and recurring orientation calls.
Gravity reported the third session of the second Graviton Training, continued Nonviolent Communication programming, and pointed participants toward recurring TEC Lounge spaces. Labs remained focused on Rewards System Research, the Praise Evolution Taskforce, DAO-to-DAO model workshops, and Tokenspice development, showing that research, rewards, and technical education were still moving in parallel.
Legal continued work on the ABC terms and conditions, aiming to finish the draft during the sprint. 0mega shared work on dilemmas, decision-making faculties, and the Capability Approach as a framework for evaluating well-being. Params reported ongoing design validation for the Commons Configuration Dashboard and noted that the backend had been prepared for the first Params party, moving the CCD from design into community testing.
Soft Gov reported that the Rewards System task force was still working through praise infrastructure and the rules surrounding praise, while also highlighting a governance and treasury-management interface initiative intended to support vote tallying and decision-making. Stewards discussed the initial buy-in for TEC tokens, Snapshot spam and possible solutions, the need for a front-end developer for the Rewards System project, and the continued use of ZenHub for community issue tracking. Transparency continued discussing improvements to the audit process and the possibility of creating a single transparency report across working groups, while keeping treasury-management research active.
By the end of the update, the TEC’s operational focus had sharpened around a few core needs: better onboarding, more reliable governance interfaces, reward-system redesign, CCD validation, ABC legal readiness, Snapshot spam prevention, and treasury-management planning.
2021-10-12 to 2021-11-03 — Changing Permissions on the HatchDAO
Forum thread: Changing permissions on the HatchDAO Category: Conviction Voting / Archive Archive theme: HatchDAO permissions, mint and burn roles, TECH address change, Dandelion Voting, Token Manager, tollgate fee, EVM-Crispr, governance execution
October 12 to October 13, 2021
This thread opened as a technical follow-up to the one-time TECH address change vote. The previous vote had passed, but the burn and mint actions could not execute because the HatchDAO voting app did not yet have permission to mint and burn tokens through the Token Manager. Since any modification to the HatchDAO required a vote, a new proposal was needed before the community’s already-approved address changes could be carried out.
The proposed action was narrow and operational. The vote would pay the 1,000 wxDai tollgate fee, reimburse that fee, and grant the Dandelion Voting app the roles needed to mint and burn TECH. The thread repeatedly clarified that the change only affected the voting app’s ability to perform the previously approved address-change action. It was not meant to alter the Commons Upgrade or expand governance powers beyond what was needed for this specific execution path.
Follow-up comments emphasized that the proposal was a technical requirement for fulfilling the community’s prior decision. The vote was created for a four-day voting window, and a more reliable Aragon client was recommended after earlier interface issues. Another clarification noted that the vote’s displayed timing might be inaccurate because of xDai block-time assumptions, but that the intended window was still four days. The proposal reached passing threshold quickly.
October 25 to November 3, 2021
A later update noted that a third vote would unfortunately be required because another permission issue remained: the voting app needed to be able to transfer funds from the non-redeemable pool. On November 3, the thread recorded that the permission-change vote had been executed.
By the end of the thread, the TEC had documented a practical lesson in DAO operations: even a seemingly simple approved action can depend on precise contract permissions. The discussion connected the address-change vote, tollgate fee reimbursement, mint and burn permissions, Dandelion Voting, Token Manager authority, xDai interface quirks, and execution sequencing into one example of how governance decisions must be matched by exact technical capabilities.
2021-10-14 to 2021-10-15 — Ethereum-Based Forum Accounts
Forum thread: Ethereum based forum accounts: good idea or…not so much? Category: Ideas / Archive Archive theme: forum infrastructure, Ethereum login, Discourse, wallet-based identity, Web3 onboarding, pseudonymous accounts
October 14, 2021
The thread opened with a question prompted by another forum’s option to create an account using an Ethereum address. The post asked whether the TEC should consider a similar feature for its own forum, what advantages or disadvantages it might have, and whether it was technically possible with Discourse.
The question framed account infrastructure as part of community design. Ethereum-based login could make the forum feel more native to the Web3 environment the TEC was helping build, but it also raised practical questions about user experience, tool compatibility, and whether wallet-based identity should supplement or replace more familiar account-creation methods.
October 15, 2021
The first responses were broadly positive. One response emphasized that Ethereum login could reduce reliance on Google or similar centralized account providers. Another argued that Ethereum sign-in could be useful as an option rather than a requirement, allowing curious newcomers to continue using familiar pathways while giving more crypto-native participants a way to connect through their wallets.
A follow-up shared a possible Discourse implementation using an Ethereum login plugin with WalletConnect support. This shifted the discussion from abstract desirability to implementation feasibility: the idea was not only philosophically aligned with TEC’s values, but also potentially available through existing Discourse tooling.
By the end of the thread, Ethereum-based forum accounts had been framed as a small but meaningful infrastructure choice. The community saw wallet login as a way to reduce dependence on centralized identity providers, support pseudonymous participation, and gradually align everyday community tools with the Web3 systems the TEC was building.
2021-10-18 to 2021-10-20 — TEC Working Groups Weekly Update, Oct 18
Forum thread: TEC Working Groups Weekly Update, Oct 18 Category: Community Updates Archive theme: working group updates, Creative Onboarding, EVM-Crispr, onboarding bot, Graviton Training, ABC terms, CCD beta testing, Snapshot proposal template, transparency reporting
October 18 to October 19, 2021
This weekly update showed the TEC continuing to operationalize the Commons Upgrade across communications, infrastructure, governance, legal work, and community support. Communications continued the Creative Onboarding campaign, worked on bounty and project-management frameworks, and prepared a post-Commons Upgrade manifesto. Commons Swarm reported a new EVM-Crispr front end and several redundant DAO-management sites, framing technical resilience as part of keeping the community’s governance infrastructure accessible.
Communitas continued improving the onboarding journey and making it more accessible, including work on an onboarding bot and recurring orientation and lounge calls. Gravity reported continued progress through the second Graviton Training, a Nonviolent Communication session and book club, and a new GitHub repository to coordinate Gravity issues. Labs continued to emphasize Rewards System Research, the Praise Evolution Taskforce, DAO-to-DAO model workshops, and Tokenspice development.
Legal reported that the current draft of the ABC terms and conditions had been finished. 0mega began a series on ethical decision-making frameworks using the Capability Approach and prepared to discuss the Cynefin framework in relation to token engineering. Params continued Commons Configuration Dashboard validation, held a beta-testing Param party, and invited community members to test the CCD and open issues when they found problems.
Soft Gov continued working through praise-giving infrastructure and the rules surrounding praise, updated the Snapshot proposal template, and implemented the new rule requiring at least one TECH token for proposal submission as a spam-prevention measure. Stewards marked the end of Sprint 19 and the start of Sprint 20, highlighted a TEC presentation at a Token Engineering Academy event, shared a new book club, and reminded contributors to use ZenHub for issues. Transparency continued work on updating the audit process, adding analytics, and creating a single transparency report across working groups rather than separate reports.
October 20, 2021
Follow-up comments suggested that the weekly updates were useful enough to share more broadly in Discord, even raising the question of whether they justified wider announcements. By the end of the thread, the working group update had become more than an internal report; it was also recognized as a useful orientation artifact for helping the wider community understand the TEC’s many parallel workstreams.
2021-10-19 to 2022-01-25 — The Initial Buy-In
Forum thread: The Initial Buy-In Category: Advice Process / Archive Archive theme: initial buy, Augmented Bonding Curve, Reward Board, LASERTAG, strategic partnerships, secondary market liquidity, multisig governance, TEC allocation
October 19, 2021
This Advice Process thread proposed that TEC become the first buyer on its own Augmented Bonding Curve. The proposal aimed to set aside a portion of Hatch funds and use them to acquire TEC at the moment the ABC initialized, before broader public trading. The goal was to let the TEC acquire tokens at the lowest possible price for strategic internal allocations.
The proposal recommended a 250,000 wxDAI initial buy, roughly fifteen percent of Hatch funds. It explained that this amount had been chosen after simulations across different reserve balances and opening prices using the Commons Configuration Dashboard. The analysis treated reserve ratio as especially important because it would affect ABC volatility, and it identified roughly twenty percent as a desirable reserve-ratio region for reasonable price movement.
The proposal described two major uses for the TEC purchased through the initial buy. The first was the Reward System, which would receive 80,000 wxDAI worth of TEC to support contributor rewards while the Reward Board matured and began making its own funding requests. The second pool combined strategic partnerships and secondary market liquidity, with 170,000 wxDAI worth of TEC available for value-aligned partnerships, token swaps, bridges, liquidity pools, and DEX liquidity.
Custody and governance were central to the thread. Reward System funds would be managed by the Reward Board, while the strategic partnerships and liquidity allocation would be managed by a seven-member Gnosis Safe multisig called LASERTAG. LASERTAG’s role was to execute proposals approved by the community through Snapshot, not to independently decide how to use the tokens. If an approved action could not be executed, the group would need to publish a transparency post explaining why.
October 20 to November 3, 2021
Discussion quickly focused on the scope and composition of LASERTAG. One response suggested not locking exact percentages between strategic partnerships and secondary market liquidity, because flexibility would allow TEC to respond to opportunities. It also suggested waiting several weeks after launch before deploying the acquired TEC so the price could stabilize. Another response introduced Agave-related context and raised the possibility of using bonding or liquidity mechanisms for TEC pairs.
The thread then developed into a governance debate over who should hold the LASERTAG multisig. One side argued for a small, trusted, available group that could execute community decisions efficiently. Another side argued that the process needed broader token-holder representation, including large holders and non-Stewards, because the multisig would control a meaningful share of the early TEC economy. The discussion clarified that LASERTAG should not have independent authority to override the community, but that its composition still mattered because it was being entrusted with execution power.
In response to that debate, the proposal was modified. The research component was removed from the formal scope of LASERTAG to make the role more clearly about execution. The strategic partnerships and secondary market liquidity allocations were merged into one flexible allocation pool. The nomination process was then clarified: anyone could nominate a set of seven TECH holders, nominees had to accept, nominations would be posted in the thread, and a Snapshot vote using Ranked Choice Voting would select the preferred signer set.
November 8 to November 29, 2021
Multiple seven-person nomination sets were submitted. After nominations closed, the thread pointed to the Snapshot signal vote for the Initial Buy-In and explained that, if the proposal passed, an on-chain Hatch DAO vote would be needed to execute the action. A later comment shared a spreadsheet to help compare nomination sets, and the final selected LASERTAG signer set was reported after the Snapshot vote closed.
December 22, 2021 to January 25, 2022
The thread was revived when a vote went live to substitute one LASERTAG multisig member. After the Commons Upgrade launch mechanics changed the initial buy amount from 250,000 to 265,000 wxDAI, a later update recalculated the allocation split. The update assumed 85,000 wxDAI would go to the Reward Board and 180,000 wxDAI to LASERTAG, yielding roughly 173,400 TEC total: about 55,619 TEC for the Reward Board and about 117,781 TEC for LASERTAG.
The final update noted that the initial buy TEC had gone to the Common Pool and that a Garden vote would move those TEC allocations to the Reward Board and LASERTAG. By the end of the thread, the Initial Buy-In had evolved from an economic design proposal into an operational mechanism for distributing early TEC to rewards, strategic partnerships, and liquidity uses, with LASERTAG serving as a community-selected execution multisig for post-launch allocation decisions.
2021-10-21 to 2021-11-03 — Technical Fix Allowing HatchDAO to Execute Payment
Forum thread: Technical fix allowing HatchDAO to execute payment Category: Conviction Voting / Archive Archive theme: HatchDAO permissions, tollgate fee reimbursement, non-redeemable pool, Dandelion Voting, TECH address change, governance execution
October 21, 2021
This thread opened as the third technical fix needed to complete the one-time TECH address change process. After the original address-change vote and the later mint-and-burn permission vote, another required permission surfaced: the HatchDAO also needed permission to execute the tollgate fee reimbursement payment associated with the vote.
The proposal was narrowly scoped. It would pay the 1,000 wxDai tollgate fee, reimburse that 1,000 wxDai, and grant Dandelion Voting permission to transfer funds from the non-redeemable pool. The purpose was not to create a new policy decision, but to supply the remaining technical authority needed to execute a decision the community had already approved.
October 25 to November 3, 2021
A follow-up announced that the third vote was live and would remain open for the full voting period. The post acknowledged the inconvenience and emphasized that this had been checked as the final vote required for this particular issue.
On November 3, the thread recorded that the vote had been executed. By the end of the thread, the address-change process had revealed another operational lesson: DAO execution depends not only on community approval, but on having every necessary permission wired correctly across voting, token management, payment, and treasury-control modules.
2021-10-21 to 2021-12-23 — Transparency Audit Report: A New Approach
Forum thread: Transparency Audit Report - A New Approach Category: Advice Process / Archive Archive theme: transparency audit, reporting, Commons Upgrade, processes, decisions, votes, fund movements, wallet data, Dune Analytics, privacy
October 21, 2021
This advice process thread proposed a new approach to the TEC Transparency Audit Report as the Commons Upgrade approached. Earlier transparency audits had focused specifically on working groups, but this proposal argued that the community needed a broader report covering important activity across the TEC. The intended audience included both new members and existing members who could not continuously follow all community channels.
The proposed report would no longer rely on working group stewards filling out transparency forms. Instead, the Transparency Working Group would gather important information and data, present it in a report, and rely on the community to monitor whether anything important was missing. Working groups that wanted a deeper transparency check could still request one.
The initial scope was broad. The report would cover processes such as submitting proposals and requesting funding, including public documentation and explanations of when processes were created or stopped. It would cover decisions made inside smaller groups that affected the broader community, as well as decisions that went through advice process. It would cover votes and results across forum activity, Snapshot, Tokenlog, TAO Voting, and Conviction Voting.
The report would also cover funding pools and fund movements: TEC inflows and outflows, total funding, fund distribution, Common Pool allocation to working groups, token engineering projects, rewards, operations, reserves, project budgets, contributor budgets, treasury management, and rewards. It proposed reporting on top TEC holders using Blockscout data, buying and selling activity, transactions that moved price by a given percentage, top buyers and sellers by token amount, and governance token supply and usage.
The thread explicitly raised a tension between radical transparency and privacy. On-chain address data was already public, but the community still needed to decide whether highlighting buying and selling activity by wallet address would be beneficial or dangerous. The post asked for feedback on what should be added or removed from the audit scope.
November 8, 2021
A response asked for a sample report before finalizing the structure. The feedback suggested that several sections were still too broad and would benefit from concrete examples, chart types, and tables. It also asked for more clarity around financial reporting terms such as total funding, fund distribution, carry-over, and the distinction between what was already available in funding proposals and what the audit would add.
The response supported reporting on token distribution and suggested reframing buying and selling activity away from “monitoring the community” and toward an ABC statistics dashboard. It also emphasized that address-based reporting should use only block explorer data and should avoid attaching names to wallets.
December 23, 2021
A later update revised the report structure in response to feedback. The Processes section was narrowed to cultural procedures relevant to the community, such as the advice process, Snapshot proposal creation, funding and cultural proposal submission, steward nomination and offboarding, and credential requests. The Decisions section focused on important non-voting decisions affecting the community, such as steward changes and default values in the Commons Configuration Dashboard, as well as advice-process decisions such as the transparency audit and Covenant.
The Votes and Results section was clarified to include all voting activity across the forum, Snapshot, Tokenlog, TAO Voting, and Conviction Voting. The financial section was reframed as funding pool, reserve, and fund movement reporting, using graphs and Dune Analytics where possible. It would cover TEC inflows from the Reserve, Common Pool outflows to working groups, token engineering projects, rewards, operations, total funding in the Common Pool and Reserve, funding proposal outcomes, excess budgets, and how funds were used after proposals passed.
The wallet analysis section was clarified to report the wallets holding the top thirty percent of TEC supply by address and percentage. Buying and selling analysis would cover market supply, token holder count, TEC in the Common Pool, wxDAI in the Reserve, transactions that moved price over a defined period, top buys and sells, and aggregate buying and selling amounts. The governance token section would cover total supply, tokens available for voting, tokens used in farming or liquidity, and where governance tokens were used.
By the end of the thread, the Transparency Audit Report had evolved from a working-group compliance exercise into a broader public accountability report for the post-upgrade Commons. The discussion defined a reporting architecture for processes, decisions, votes, fund flows, wallet distribution, market activity, governance tokens, Dune Analytics, and privacy boundaries, while positioning Transparency as both report producer and support resource for working groups and projects.
2021-10-21 to 2021-11-01 — Snapshot Params
Forum thread: Snapshot Params Category: Advice Process / Archive Archive theme: Snapshot, proposal parameters, support required, quorum, vote duration, cultural decisions, community signal, runoff votes, soft governance
October 21, 2021
This advice process thread opened a discussion about what parameters should apply to Snapshot votes. Snapshot was framed as a token-weighted voting tool for large-impact cultural decisions, community signals, and runoff votes coming from crowd proposal making on Tokenlog. At that stage, only TECH holders could submit proposals, but Snapshot itself could not enforce all of the desired governance parameters automatically.
Because the parameters could not simply be programmed into Snapshot, the post argued that Soft Gov and Transparency would need to monitor final results according to the community’s chosen rules. The proposed questions were support required, minimum quorum, and vote duration. The thread offered signal options for approval thresholds, quorum based either on token supply or number of participants, and vote duration options such as four days, six days, or proposer-selected timing.
October 22 to October 25, 2021
Early responses split between flexibility and consistency. One response argued that for treasury-management decisions, a 51 percent support threshold with at least 10 percent quorum might be sufficient, since Snapshot did not need to mirror the stricter TAO Voting system. This led to the idea that different types of Snapshot decisions might deserve different parameter sets.
Another response favored parameters similar to the Hatch, arguing that consistency across voting tools would make the governance process easier to learn and would reduce confusion. This view treated cultural-build decisions as serious enough to require strong legitimacy, not merely lightweight signaling. A later response agreed that separate parameters for every proposal type could become confusing, but suggested that Snapshot might still distinguish between community signals, cultural proposals, and runoff votes. The preferred support threshold leaned toward 75 percent, based on the concern that allowing proposals to pass with nearly half the community opposed would be unhealthy.
October 30 to November 1, 2021
Later comments continued to treat Snapshot parameter design as a balance between preventing capture and avoiding paralysis. One response favored a support threshold somewhere between 75 and 88 percent, high enough to keep whales from dominating cultural issues but not so high that the community would be blocked from making important decisions. Vote duration also became a concern: allowing proposers to pick very short windows was viewed as risky, while a six-day period was seen as more inclusive for people who could not constantly monitor proposals.
By the end of the thread, Snapshot had been framed as a soft-governance tool that still needed explicit legitimacy standards. The discussion connected support thresholds, quorum, vote duration, cultural decisions, community signaling, treasury decisions, consistency across governance tools, and the need for human monitoring into one practical question: how should Snapshot votes be treated as legitimate community decisions when the tool itself cannot enforce all of TEC’s governance norms?
2021-10-24 to 2021-10-25 — TEC Working Groups Weekly Update, Oct 25
Forum thread: TEC Working Groups Weekly Update, Oct 25 Category: Community Updates Archive theme: working group updates, Initial Buy-In, Graviton Training, EVM-Crispr, Rewards System, Communitas funding, Creative Onboarding, CCD beta testing
October 24 to October 25, 2021
This weekly update documented the TEC nearing the Commons Upgrade with more than 1.5 million wxDai in Hatch funds and a growing set of post-Hatch operational decisions. Stewards highlighted the rise of Sprint 20, the Initial Buy-In proposal to use 250,000 wxDai to buy into the TEC bonding curve, and the importance of remembering the community’s values while navigating these economic decisions.
Gravity reported the fifth session of the second Graviton Training, focused on Alternative Dispute Resolution, and prepared for a sixth session on decolonization. It also continued the Nonviolent Communication book club and issue coordination through GitHub, emphasizing that competent conflict management remained central to TEC culture. Commons Swarm highlighted the new EVM-Crispr front end, which could let non-developers craft more intricate DAO proposals, and pointed to redundant DAO-management sites intended to reduce downtime risk.
Soft Gov reported that the Rewards System Task Force was continuing to update the Praise framework, shared a visual model for how advising, voting, and structural decision-making would differ depending on scale of impact, and promoted a peer-to-peer feedback form. Communitas continued work on onboarding accessibility and invited feedback on a working group funding proposal. 0mega continued its ethical decision-making framework series, while Labs maintained its focus on Rewards System Research, the Praise Evolution Taskforce, DAO-to-DAO workshops, Tokenspice development, and an upcoming Solidity study group.
Communications prepared to rebrand as T.E.A.M., continued the Creative Onboarding campaign, looked for project managers, social media managers, graphic designers, and animators, and continued work on bounty and project-management frameworks. Transparency kept working on an updated audit process with analytics and a unified transparency report across working groups. Legal noted that the ABC terms and conditions draft had been finished. Params reported ongoing CCD validation and completion of beta version testing, inviting the community to test the dashboard and open issues.
By the end of the update, the TEC’s late-October focus was clear: finalize dashboard testing, prepare the Initial Buy-In decision, refine reward and decision-making systems, improve onboarding and communications capacity, and keep legal, transparency, and governance infrastructure aligned as the Commons Upgrade approached.
2021-10-29 to 2021-12-21 — Voting for the Final Params for the Commons Upgrade
Forum thread: Voting for the Final Params for the Commons Upgrade Category: Community Updates Archive theme: Commons Upgrade, final parameters, Commons Configuration Dashboard, Tokenlog, Snapshot, parameter parties, runoff voting, voter pamphlet, proposal quality
October 29 to November 10, 2021
This community update thread laid out the decision-making process for selecting the final parameters for the Commons Upgrade. The process used the Commons Configuration Dashboard for creating parameter sets, Tokenlog for token-weighted quadratic curation of proposals, and Snapshot for the final runoff. The opening post explained that Tokenlog would gather continuous feedback on GitHub issues, while the top community-curated proposals would later move into a Snapshot runoff.
The process was divided into phases. “Play & Learn” invited early experimentation with the dashboard and informal Param Parties. “Learn & Propose” expanded Param Parties in TEC and friendly external Discords while warning that Tokenlog votes could not be taken back and should be used lightly. “Propose & Debate” was for more serious proposal creation, forking, and discussion. “Debate & Rock the Vote” was intended for final debate participation and more deliberate Tokenlog voting. After that, a Stewards Council and voter pamphlet phase would determine which three to five proposals best represented the community signal, followed by a Snapshot runoff using quadratic ranked choice voting.
The thread also clarified operational rules: proposals were made in the Commons Dashboard, proposal deletion required Params team support, forking proposals was encouraged, forks should identify the source proposal, and Snapshot votes could be recast even though Tokenlog votes could not. A contingency was described for polarized runoff outcomes: if the top two proposals were within five percent of each other, their authors would be invited into an open hack session with community input to find a collaborative solution.
Early replies supported extending the timeline so that the community would have more time to learn, play with parameters, and make better-informed choices. A revised schedule added time for additional Param Parties, outreach, dashboard feedback, smart contract testing, standardization of runoff proposals, and creation of a digestible voter pamphlet.
November 11 to December 3, 2021
A newcomer used the thread to ask deeper design questions that revealed the practical stakes of parameter selection: what the Commons wanted to accomplish in the next few months and years, how much money it needed, how large the DAO hoped to become, how long participants were expected to hold, whether the DAO should be fully decentralized, and how risk-averse the economy should be. A response framed TEC’s mission as advancing token engineering, noted that roughly 1.5 million had already been raised, estimated early working group spending needs, and described the bonding curve as something the TEC might eventually outgrow if it succeeded in creating a regenerative token economy.
The schedule was then extended again after Stewards discussed the need for more time to create high-quality proposals, more token engineering education through Param Parties, more community attendance at debates, and more careful economic design. The revised timeline moved Propose & Debate through December 16, Debate & Rock the Vote through December 21, Stewards Council and voter pamphlet creation through January 6, and the final Snapshot runoff from January 7 to January 13.
A follow-up clarified that timeline changes should be tied to a quality metric rather than simply moving dates. The proposed metric was that at least five polished proposals should each have someone willing to campaign for them. If that metric was met by December 16, the process would move forward; otherwise, a new advice process would determine next steps.
December 9 to December 21, 2021
As proposal activity increased, the thread became a coordination space for sharing and clarifying Commons Configuration proposals. One major proposal was posted directly into the thread, aiming to create roughly one million wxDAI in the Common Pool while using Ostrom-inspired principles for a sustainable common-pool resource. It included a forty-week freeze, forty-week thaw, 0.63 wxDAI opening price, seventy-eight percent Commons Tribute, eight percent Entry Tribute, two percent Exit Tribute, 22.51 percent reserve ratio, mostly Hatch-like TAO Voting parameters, and a Conviction Voting configuration designed to support milestone-sized funding requests.
The thread also clarified how to use Tokenlog. Questions were raised about how many tokens people should put behind proposals they liked and whether authors could vote for their own proposals. Responses explained that quadratic voting creates diminishing returns for concentrating votes and that people would likely spread votes across multiple proposals. Voting for one’s own proposal was treated as acceptable if the voter genuinely believed it was the best option for the Commons.
The five-proposal quality metric was then declared met. Five distinct proposals each had a person backing them, which was treated as evidence that the community had enough diversity of polished proposals to move forward. The thread emphasized that this backing was not a final voting preference, only a signal that the process was ready to proceed and that all Tokenlog proposals remained eligible.
On December 21, the primaries closed. The top five proposals were announced as moving to the Snapshot runoff scheduled for January 7, and the thread thanked the twenty-nine unique voters who participated in what was described as a difficult session to follow while making an informed decision.
By the end of the thread, the TEC had transformed Commons Upgrade parameter selection from open experimentation into a structured governance pipeline. The process linked dashboard experimentation, proposal forking, Tokenlog curation, public debate, quality thresholds, steward synthesis, voter-pamphlet preparation, and Snapshot ranked-choice runoff into one of the most consequential governance processes in the TEC’s launch history.
2021-11-01 to 2021-11-04 — Snapshot Params Final Proposal
Forum thread: Snapshot Params Final Proposal - Go vote on Snapshot Category: Advice Process / Archive Archive theme: Snapshot parameters, quadratic voting, quadratic ranked choice voting, quorum, support required, vote duration, runoff votes, cultural decisions
November 1, 2021
This thread converted the earlier Snapshot Params advice process into a final proposal and vote. The proposal defined three official use cases for Snapshot: large-impact cultural decisions, community signal votes, and runoff votes from crowd proposal making on Tokenlog. It also proposed reducing Snapshot voting-type options to Quadratic Voting and Quadratic Ranked Choice Voting, with a high support threshold, a dual quorum requirement, and standardized vote durations.
The proposal argued that TEC’s token distribution was uneven enough that ordinary token-weighted voting could allow a small number of large holders to dominate decisions. Quadratic Voting was therefore prioritized because it could soften the effect of large token balances while still respecting token holdings. Since Quadratic Ranked Choice Voting was not yet available directly in Snapshot, the proposal suggested a temporary workaround for Commons Upgrade runoff votes: calculate the square root of each Hatcher’s holdings and mint temporary voting tokens, while also pursuing a more permanent encoded solution with Snapshot Labs.
The proposed parameters were explicit. For large-impact cultural decisions, Snapshot would use Quadratic Voting with yes/no options, 88 percent support required, a four-day vote duration, and a quorum of at least 10 percent of total token supply plus at least 10 unique voters. For community signal votes, Snapshot could use Quadratic Voting or Quadratic Ranked Choice Voting depending on the structure, with the same general support and quorum expectations for QV. For runoff votes from Tokenlog, Snapshot would use Quadratic Ranked Choice Voting with a six-day duration. If the top two ranked-choice results were within five percent, the proposal recommended inviting the authors into an open hack session to look for a collaborative solution.
The thread also reiterated that Snapshot could not enforce all of these parameters automatically, so Soft Gov and Transparency would need to monitor outcomes according to the rules chosen by the community. The proposal framed this parameter set as foundational to TEC’s decision-making legitimacy, especially for cultural decisions and Commons Upgrade-related voting.
November 4, 2021
A follow-up praised the emphasis on quadratic voting, especially for large-impact cultural decisions. By the end of the thread, Snapshot governance had moved from open-ended parameter discussion into a concrete operating standard: limited voting methods, high support requirements, minimum participation rules, longer runoff windows, and human oversight for legitimacy when the software itself could not fully enforce the governance process.
2021-11-03 — Open Letter to Hatchers: The Time Is Now to Design Our Commons
Forum thread: Open letter to all Hatchers! The time is now to design our Commons! Category: Community Updates Archive theme: Commons Upgrade, Hatchers, Commons Configuration Dashboard, parameter proposals, Params Parties, ABC, Conviction Voting, runoff vote
November 3, 2021
This community update addressed Hatchers directly and marked the beginning of the active Commons Upgrade design period. The post reminded Hatchers that the upgrade would transform the TEC Hatch DAO into a full Commons with an Augmented Bonding Curve and Conviction Voting governance system. It framed the next stage as both a collective parameterization process and a learning opportunity around DAO design and token economics.
The main announcement was that the Commons Configuration Dashboard was live. Hatchers were invited to explore the dashboard independently or attend guided Params Parties where hosts would explain the Commons Upgrade process and walk participants through the parameters, from Token Freeze for TECH tokens to the Commons Tribute in the ABC.
The post then explained the decision path. After the community submitted proposals for the Augmented Bonding Curve and Conviction Voting configurations, Hatchers would vote on the submissions, and the winning parameter set would be deployed in the Commons Upgrade. Updated key dates were provided: Learn and Propose from November 7 to 18, Propose and Debate from November 19 to 25, Debate and Rock the Vote from November 25 to 30, Stewards Council and voter pamphlet creation from December 1 to 6, and the runoff vote on December 13.
By the end of the thread, the Commons Upgrade had moved from background roadmap to active community process. The post functioned as a call to action: join the parties, learn the parameters, submit proposals, and participate in designing the economy that would replace the Hatch DAO.
2021-11-07 to 2021-11-08 — TEC Working Groups Weekly Update, Nov 7
Forum thread: TEC Working Groups Weekly Update, Nov 7th Category: Community Updates Archive theme: working group updates, Commons Upgrade parameters, TECH address recovery, ABC audit, Snapshot Params, Discord onboarding, multisig process, CCD launch
November 7 to November 8, 2021
This weekly update showed the TEC moving through the final coordination work around the Commons Upgrade. Stewards reported that the community was midway through Sprint 21, that an open letter to Hatchers had been written to explain important dates around parameter creation, deliberation, and initialization, and that an offboarding event had taken place for departing stewards. The Initial Buy-In proposal had also been updated with a nomination process for selecting seven multisig trustees, and TEC had received recognition through Optimism’s retroactive public goods funding.
Gravity continued its second Graviton Training, focusing on human leadership and preparing for a deeper Gravity session. The Nonviolent Communication book club also continued. Commons Swarm reported a new EVM-Crispr version, completion of the long-running lost-address TECH burn process after three votes, progress on ABC audit revisions, and continued work on the Gardens frontend. This made the update a clear record of the community turning painful operational lessons into better recovery processes.
Soft Gov reported that the Rewards System Task Force was still updating the Praise framework and that the Snapshot Params vote had passed. Communitas completed the first rough draft of the final Discord onboarding journey and continued pointing contributors toward its funding proposal. 0mega continued its ethical decision-making framework series, while Labs continued supporting Rewards System Research, the Praise Evolution Taskforce, DAO-to-DAO workshops, Tokenspice development, BlockScience office hours, Longtail Financial office hours, and a future Solidity study group.
Communications, soon to be renamed T.E.A.M., highlighted the active Params Party season, the continued Creative Onboarding campaign, recruitment for creative and project-management roles, bounty and project-management framework work, and the coming post-Commons Upgrade manifesto. Transparency was working on a community transparency survey, offboarding credentials, and the beginning of Transparency Debates for the multisig process. Legal called for DAO legal experts, continued work on ABC terms and conditions, and prepared a funding proposal to make legal-response capital available if needed. Params shared the new Commons Configuration Dashboard link and invited people to use the dashboard, attend Params Parties, and submit issues.
By the end of the update, the TEC was visibly converging on the Commons Upgrade. The core workstreams were no longer isolated: parameter setting, Snapshot legitimacy, address recovery, multisig trustee selection, ABC audits, dashboard testing, onboarding, offboarding, legal readiness, and contributor rewards were all becoming parts of the same launch preparation process.
2021-11-11 — TEC Offboarding Credentials and Access
Forum thread: TEC Offboarding Credentials and access Category: Community Updates Archive theme: offboarding, credentials management, Dashlane, access control, platform admins, transparency audits, contributor access
November 11, 2021
This thread established a process for removing platform access when contributors no longer needed it. It separated TEC platforms into two categories: platforms accessed through Dashlane, such as social media, website, email, video, CRM, publishing, and professional-networking accounts; and platforms where access was controlled by internal roles, such as Discord, GitBook, Forum, Snapshot, Boardroom, Telegram, onboarding data, GitHub, HubSpot, and Medium.
For Dashlane-managed platforms, the process required the lead admin of a platform to notify the credentials managers when a contributor no longer needed access, after which access would be revoked through Dashlane. Alternatively, during regular credential audits, credentials managers would ask platform admins for updates on active and inactive contributors and remove inactive access accordingly.
For role-based platforms, the platform lead could revoke access directly when a contributor no longer needed it, but would then notify Transparency for documentation. Transparency would also contact platform admins during credential audits to update records of active and inactive contributors.
By the end of the thread, offboarding had been formalized as a transparency and security process. The TEC was moving from ad hoc access management toward a recurring audit model in which platform admins, credentials managers, and Transparency shared responsibility for ensuring that contributors had the access they needed and that inactive access was removed.
2021-11-15 — TEC Working Groups Weekly Update, Nov 15
Forum thread: TEC Working Groups Weekly Update, Nov 15th Category: Community Updates Archive theme: working group updates, Commons Upgrade timeline, Initial Buy-In, ABC UI, credential offboarding, Reward Board, Discord onboarding, CCD completion
November 15, 2021
This weekly update showed the TEC entering the decisive Commons Upgrade preparation window. Stewards announced that Sprint 21 had ended and laid out the key Commons Upgrade schedule: Learn and Propose through November 18, Propose and Debate from November 19 to 25, Debate and Rock the Vote from November 25 to 30, Stewards Council and voter pamphlet creation from December 1 to 6, and a runoff vote from December 7 to 13. The Initial Buy-In Snapshot proposal had passed, a Discord tweet feed was being explored, Params Parties were being reviewed for improvements, and the Token Engineering Academy course had begun.
Gravity continued improving access to conflict-resolution services by working on a Discord sidebar interface for contacting active Gravitons. The second Graviton Training continued with a Gravity Deep Dive and an upcoming session on Ostrom’s Principles, decision-taking, and decision spaces. Commons Swarm reported a new EVM-Crispr version, a new UI demo for buying and selling through the Augmented Bonding Curve, and ABC audit revisions reaching 93.75 percent completion.
Soft Gov continued updating the Praise framework and shared a Reward Board showing the members and duties of the Rewards System Task Force. Communitas reported more than 1,200 community members, maintained recurring orientation and lounge calls, and prepared to present the first part of the Discord onboarding journey. 0mega continued weekly syncs, ethical decision-making framework work, and development of a Token Engineering Consilience Library.
Labs continued supporting Rewards System Research, the Praise Evolution Taskforce, DAO-to-DAO workshops, Tokenspice development, BlockScience office hours, Longtail Financial office hours, and a Solidity study group. Communications, soon to be T.E.A.M., reported its most attended call to date, continued Params Party promotion, ongoing Creative Onboarding recruitment, and preparation of the post-Commons Upgrade manifesto. Transparency finalized the credential offboarding process, began exploring Dune Analytics for data-driven audit insights, prepared a community transparency survey, and planned Transparency Debates for the multisig process. Legal continued work on ABC terms and a legal working group funding proposal. Params reported that the Commons Configuration Dashboard had a new link and that only one major feature remained: adding a funding request to the Conviction Voting app.
By the end of the update, the TEC was no longer simply preparing abstractly for the Commons Upgrade. The timeline, dashboard, ABC interface, audit revisions, Initial Buy-In, reward system, offboarding process, onboarding journey, legal readiness, and multisig process were all moving into concrete launch-readiness work.
2021-11-17 to 2022-06-14 — Communitas WG Three-Month Funding Proposal
Forum thread: Communitas WG 3-month funding proposal Category: Advice Process / Archive Archive theme: Communitas, onboarding, Guides, community nurturing, token holder relations, community operations, Conviction Voting, accountability review
November 17, 2021
This Advice Process thread proposed three months of funding for the Communitas Working Group, with the final version intended for Conviction Voting after the Commons Upgrade. The proposal framed community nurturing and onboarding as one of the things that set TEC apart, arguing that Communitas should keep doing that work while making the experience even better.
The proposal described Communitas as the working group responsible for nurturing, growing, and guiding the TEC community. Because community support required staying aware of what was happening across TEC, compensated roles were expected to spend significant time learning, keeping up with working group activity, and helping people navigate the Commons.
Communitas organized its work into onboarding, community nurturing, token-holder relations, and special projects. Onboarding included personal outreach to new members, improving orientation materials, designing an end-to-end onboarding experience, using surveys and feedback loops, and coordinating with Communications. Community nurturing included keeping Discord alive, responding to shared-channel messages, maintaining relationships with Hatchers and token holders, and supporting participation in key events and votes. Special projects included bounties, Discord bots and tools, social events, POAPs, swag, and other appreciation projects.
The proposed roles included Steward, Working Group Coordination Lead, Community Builder, Guides, Community Ops, and a special-projects budget. The draft used an equal weekly compensation rate for roles expecting roughly 15 to 20 hours of effort, with a lower rate for the 10-hour Community Ops role. The initial three-month request was 46,410 wxDAI, with simple monthly progress reporting: contributors would post role and work performed, objections would first be mediated inside the working group, and unresolved disputes could go to Gravity.
January 31 to February 1, 2022
After a supportive comment and a request to be added as a Guide in training, a final version of the proposal was posted for Conviction Voting. The final request remained 46,410 wxDAI, added the multisig address, and clarified that the term would include eight compensated roles. It also kept the same accountability process for monthly compensation requests and internal mediation.
The final version narrowed the team structure while keeping two community-builder positions open until the right people could be identified. The proposal was then posted to Gardens for voting, moving Communitas from advice process into formal funding execution.
June 14, 2022
A later accountability update reviewed the results of the prior funding period. Communitas reported that onboarding and outreach had been handled mainly by Guides, but acknowledged that stronger coordination with Communications could have improved outreach around Praise and proposals. For token-holder relations, the update noted that the working group had not created the intended informative materials or media to share with token holders during the term.
The review also found that a bounty system had not worked well for the first iteration because most Communitas tasks were recurring and required members to stay in the know. The group planned to try a more concrete bounty around a “Welcomer” role. It also acknowledged that appreciation projects such as POAPs and community offerings had not yet become a developed workstream, but identified them as a focus for the next term, especially for newcomers.
By the end of the thread, Communitas had turned its first three-month funding proposal into both an onboarding budget and a governance learning process. The thread connected Guide labor, personal outreach, orientation design, Discord operations, token-holder relations, monthly compensation reporting, Gravity-mediated accountability, and a later retrospective on what was achieved, what remained in progress, and what needed to change for the second term.
2021-11-21 to 2021-11-28 — TEC Working Groups Weekly Update, Nov 21
Forum thread: TEC Working Groups Weekly Update, Nov 21st Category: Community Updates Archive theme: working group updates, Commons Upgrade debate, DAO budget estimates, Rewards System WG, Discord onboarding, T.E.A.M., CCD funding simulation, parameter proposals
November 21 to November 28, 2021
This weekly update, posted late for the November 21 week, captured the TEC entering Sprint 22 with the Commons Upgrade process underway. Stewards reiterated the key Commons Upgrade timeline: Learn and Propose, Propose and Debate, Debate and Rock the Vote, Stewards Council and voter pamphlet creation, and the December runoff vote. The update also shared early DAO budget estimates, suggesting that existing working group funding proposals could require roughly 180,000 DAI for three months of operations and that current forum proposals represented a larger soft funding figure. The Stewards funding proposal was in advice process, critical Commons Upgrade work was being tracked in ZenHub, and the community was reminded that more than 500 people had contributed to the TEC.
Gravity continued the second Graviton Training with sessions on Ostrom’s principles, decision-taking, and decision spaces, while the Nonviolent Communication book club continued. Commons Swarm reported that roadblocks to the ABC demo had been cleared, although EVM-Crispr troubleshooting was still underway. Soft Gov noted that the Rewards System Initiative was becoming its own working group, that forum settings were being changed from categories toward tabs for easier navigation, and that the community was beginning to vote on final Commons Upgrade parameters.
Communitas completed the first part of the Discord onboarding journey and shared a three-month funding proposal. 0mega continued its ethical decision-making framework series, including an episode on common language, and continued developing a Token Engineering Consilience Library. Labs maintained its recurring research, Praise Evolution, DAO-to-DAO, Tokenspice, BlockScience, Longtail Financial, and Solidity study group rhythms.
Communications, soon to become T.E.A.M., continued Params Party promotion and reported that five post-Commons Upgrade teams were forming: TE Academy, HubSpot, Animation and Media, Translation, and Twitter Planning. Transparency helped update Soft Gov’s decision-tracking document, prepared a community transparency survey, and planned Transparency Debates for the multisig process. Legal continued work on ABC terms and legal funding readiness. Params reported that the Commons Configuration Dashboard now allowed users to simulate a funding request into the bonding curve, that current Commons Configuration Proposals were visible on Tokenlog, and that the debate structure would focus on five proposals with timed presentations and responses.
By the end of the update, the Commons Upgrade had moved into the proposal and debate phase. The TEC was simultaneously estimating operating budgets, refining funding proposals, preparing parameter debates, forming post-upgrade communications teams, improving onboarding, maturing rewards into a working group, and using the CCD to help Hatchers understand the practical requirements for passing funding proposals.
2021-11-25 to 2022-01-27 — Steward WG Three-Month Funding Proposal
Forum thread: Steward WG 3-month funding proposal Category: Advice Process / Archive Archive theme: Steward funding, working group coordination, WGCLs, compensation, role budgeting, Gravity mediation, Conviction Voting
November 25, 2021
This Advice Process thread proposed a three-month funding budget for the Community Stewards Working Group. The purpose was to compensate active Stewards and Working Group Coordination Leads for transversal coordination work across TEC. The proposal distinguished this work from ordinary contribution inside individual working groups, arguing that Stewards and coordination leads were doing extra work to stay aware of the entire organization and help coordinate across many working groups.
The proposal described Stewards as carriers of TEC’s mission, vision, and values; holders of organizational know-how; representatives of TEC to the larger community; and civil servants of the Commons. Working Group Coordination Leads were described as responsible for streams of work inside working groups and for surfacing dependencies between groups. Both roles were expected to involve at least ten hours per week of active participation across sprint planning, retrospectives, weekly calls, council calls, community calls, and working group calls.
The initial budget requested 45,000 wxDAI for three months. The model paid Working Group Coordination Leads 750 wxDAI per month and Stewards 500 wxDAI per month, with compensation cumulative for people holding both responsibilities. It also included a monthly special projects and bounty budget. The proposal noted that the three-month bundle might be broken into several smaller proposals depending on final Conviction Voting parameters and community signals.
The progress-sharing process was designed to remain simple and transparent. During the first week of each month, each Steward or coordination lead would post a compensation request in the Steward channel, including their role, work performed, and associated issues. If no objection was raised, payment would be transferred. If an objection arose, the issue would first be mediated inside the working group and then, if unresolved, escalated to Gravity for mediation.
January 27, 2022
A final version of the proposal was posted for submission to Conviction Voting. The updated proposal still covered three months and kept the same basic role-compensation logic, but revised the total request to 47,250 xDAI. The update reflected fourteen Stewards, nine Working Group Coordination Leads, and the launch of additional working group coordination needs, including Rewards and 0mega participation.
The final budget requested 20,250 xDAI for coordination lead compensation, 21,000 xDAI for Steward compensation, and 6,000 xDAI for special projects, for a total of 47,250 xDAI. It also provided the multisig address and simplified the monthly reporting requirement to role and work performed rather than requiring associated GitHub issues.
By the end of the thread, Stewarding had been framed as core coordination infrastructure rather than informal background labor. The proposal converted broad community stewardship, working group coordination, information flow, governance participation, and role accountability into a fundable three-month operating budget with a transparent claims and mediation process.
2021-11-28 to 2021-11-30 — TEC Working Groups Weekly Update, Nov 28
Forum thread: TEC Working Groups Weekly Update, Nov 28th Category: Community Updates Archive theme: working group updates, Commons Upgrade deliberation, bonding curve interface, LASERTAG multisig, Rewards System WG, T.E.A.M., CCD funding simulation, parameter debates
November 28 to November 30, 2021
This weekly update showed the TEC only days away from the Commons Upgrade. Stewards reported that Sprint 22 had ended and that the Debate and Rock the Vote period was being extended to allow more deliberation. The community was reminded to track critical Commons Upgrade work in ZenHub, review the Steward three-month funding proposal, and continue using shared references such as the TEC Timeline, Handbook, and retrospective board.
Gravity reported completion of the second Graviton Training, continued the Nonviolent Communication book club, and shared several support resources, including a request-support link, survey, process documentation, and weekly notes. Commons Swarm announced that a new interface was ready for buying and selling tokens directly through the bonding curve, marking a major step toward the practical user experience of the Commons economy.
Soft Gov reported that the Rewards System initiative was evolving into a working group and that a Rewards System Assemblage event would take place in December. The LASERTAG Snapshot vote was active, selecting seven people for a Gnosis Safe multisig whose role would be to execute community-approved decisions rather than make independent decisions. Soft Gov also pointed to decision-making visuals and reminded the community that final Commons Upgrade parameter voting was underway.
Communitas shared its three-month funding proposal and a “Guide for Guides” onboarding resource. 0mega had started a Notion page for the Token Engineering Consilience Library and continued ethical decision-making work. Labs continued its recurring research, Praise Evolution, DAO-to-DAO, Tokenspice, BlockScience, Longtail Financial, and Solidity programming. Communications, soon to be T.E.A.M., continued Params Party promotion, Creative Onboarding recruitment, and formation of five post-upgrade teams: TE Academy, HubSpot, Animation and Media, Translation, and Twitter Planning. Bounties were also expected soon.
Transparency continued supporting Soft Gov decision tracking, preparing the community transparency survey, and planning Transparency Debates for the multisig process. Legal continued calling for DAO legal experts, working on ABC terms, and preparing a legal working group funding proposal. Params continued directing people to the Commons Configuration Dashboard, including its funding-request simulation feature, current Tokenlog proposals, and the debate structure for five proposals with timed presentations and responses.
By the end of the update, the Commons Upgrade had become an active deliberation environment. The TEC was aligning bonding curve interfaces, multisig execution, parameter debate structure, funding proposals, reward-system institutionalization, onboarding guides, communications teams, transparency processes, legal readiness, and dashboard simulations into the final pre-upgrade governance process.
2021-11-30 to 2024-07-19 — TEC Polycentric Governance Framework
Forum thread: TEC Polycentric Governance Framework Category: TEC Strategy & Governance Archive theme: Polycentric governance, advice process, Conviction Voting, Tao Voting, Snapshot, Tokenlog, grants program, governance documentation
November 30, 2021
A governance framework thread was published to collect TEC’s decision-making processes into one polycentric governance reference. The thread organized governance around several different tools and processes instead of treating all decisions as belonging to a single voting mechanism. The initial framework included the advice process, Conviction Voting, Tao Voting, Snapshot, and Tokenlog.
The advice process was presented as the first step for decision making. Small-impact decisions could use peer-to-peer advice during normal workflows. Medium-impact decisions could be handled inside working groups, where the people closest to the work could assess the issue without requiring the attention of the whole community. Large-impact decisions required community advice through the forum, with at least five days for feedback before moving to a final decision path.
The framework then mapped different types of decisions to different governance tools. Conviction Voting was positioned as the process for financial proposals that advanced token engineering and aligned with TEC’s mission, vision, and values. Tao Voting was defined as the high-authority process for technical decisions and DAO modifications, including minting and burning TEC tokens, installing or removing applications, and modifying governance or economic parameters. Snapshot was described as the tool for large cultural decisions, community signaling, and runoff votes. Tokenlog was described as a way to curate collective intelligence through token-weighted backlogs and crowd proposal making.
The thread also documented current governance parameters for Conviction Voting, Tao Voting, and Snapshot. This made the post both a conceptual framework and an operational reference. It explained which tool should be used for which kind of decision, what process should precede formal voting, and how TEC could avoid overloading any one mechanism with every kind of governance action.
December 2021 to February 2022
The early replies treated the framework as a useful consolidation of TEC’s governance practices. A question was raised about whether Tao Voting used quadratic voting. The clarification was that Tao Voting used token-weighted voting, not quadratic voting. A follow-up asked whether Conviction Voting would support quadratic voting. The answer was that TEC did not have the technology to implement quadratic Conviction Voting at that time, and that quadratic systems would require an identity solution to reduce sybil or whale-splitting risks.
A later update suggested adding current parameters and clarifying that TEC was not using quadratic voting with Snapshot until an identity solution was available. This showed that the framework was already functioning as a living document rather than a static description.
June 2022 to November 2022
The framework continued to be recognized as a major governance reference for TEC. It was later globally pinned and briefly made into a forum banner, indicating that the community wanted the document to remain visible as a practical entry point for understanding how TEC governance worked.
November 2023 to July 2024
The thread was revived after TEC had voted to disable Conviction Voting for the time being. A note was added pointing readers to the proposal and advice process that sidelined Conviction Voting, and the governance framework was then updated to reflect the newer state of TEC governance.
The updated framework removed Conviction Voting from the active funding flow and added the Token Engineering Grants Round as a major funding stream. Community advice remained the first step for large technical, financial, and cultural decisions. Tao Voting became the process for technical proposals and larger financial proposals, while the grants program became the path for smaller token engineering projects seeking funding through Gitcoin rounds. Snapshot and Tokenlog remained part of the wider governance stack for cultural decisions, signaling, runoff votes, and crowd proposal making.
The updated Tao Voting section clarified that technical modifications and larger financial requests should go through the forum advice process before being submitted onchain, and that Tao Voting proposals required a TEC token deposit that would be returned after resolution. The Snapshot section continued to define large cultural decisions, community signal, and runoff votes, while noting the continued limitation around quadratic voting until an identity solution could be implemented.
By the end of the thread, the TEC Polycentric Governance Framework had become one of the central governance index documents for the Commons. It captured TEC’s movement from a multi-tool architecture centered partly on Conviction Voting toward a later structure that relied more on advice process, Tao Voting, Gitcoin grants rounds, Snapshot, Tokenlog, and advisory coordination. The thread documented not only the original governance framework, but also how TEC’s governance process adapted as the organization’s funding mechanisms and decision-making needs changed.
2021-12-07 to 2021-12-19 — Commons Upgrade Demo, Part 2
Forum thread: Commons Upgrade Demo (part 2) Category: ABC / Archive Archive theme: Commons Upgrade, migration demo, Hatch DAO, Garden DAO, Augmented Bonding Curve, initial buy, Conviction Voting, EVM scripts, launch readiness
December 7, 2021
This ABC thread announced a full demo of the Commons Upgrade process. Earlier testing had verified the migration process before the Hatch, and subsequent work had focused on a script capable of mutating a Gardens DAO into the future TE Commons DAO with an Augmented Bonding Curve and other parameters defined through the Commons Configuration Dashboard. The thread framed the demo as the moment when the entire process could finally be tested end to end.
The demo was structured in two stages. The first stage was a Migration Vote that would transfer funds from a demo Hatch DAO to a modified Gardens DAO and mint one new DAO token for each old Hatch DAO token at execution time, using the token freeze and token thaw settings from the leading Tokenlog proposal. The second stage was a Bonding Curve Opening Vote that would open the bonding curve with a reserve ratio derived from the leading proposal’s opening price and perform the initial buy defined in that proposal. After the first vote, participants would be able to create test Conviction Voting proposals. After the second vote, test DAI holders would be able to buy tokens through the demo bonding curve interface.
The thread included technical details for production and demo contracts, including Hatch DAO contracts, token addresses, demo Hatch and Garden DAOs, and EVM command-line instructions used to create a mock Hatch DAO from a normal Company DAO for testing. It also included a script for retrieving TECH token holders in order to mock their balances for the demo.
December 7 to December 9, 2021
The first migration vote was created after some technical complications. The parameter set used for the demo was adapted from the Tokenlog-leading proposal, with some governance timing and token details modified for testing. The vote was designed to migrate funds from the mock Hatch DAO to a staging Garden only if the Garden would mint tokens for all Hatch DAO token holders, creating a safety check around the migration. A small number of addresses were granted test tokens so they could deposit stake into the agreement and create the next vote.
The migration vote succeeded, and the new test Garden went live with 1,995,737 TestTEC. A second vote was then created to open the bonding curve. This second vote was shortened for the demo, but it surfaced several technical issues. Proposal and challenge deposit amounts were being calculated incorrectly from Commons Configuration parameters, the mock Hatch DAO had twice the test DAI it should have had, and the team discovered that delegated voting period timing had been misunderstood in relation to token freeze and thaw calculations. These issues were fixed for the TEC launch, but the demo bonding curve vote had to be repeated.
December 12 to December 19, 2021
The first attempt to open the bonding curve did not go as expected, so the team decided to close the curve, restore the prior balances, and open it again with corrected parameters. The thread then updated the community that the corrected bonding curve opening vote was live, with numbers rechecked before execution. The reserve ratio was set to 3.2056 percent so the opening price could be 1.20 wxDAI, and the 250,000 wxDAI initial buy from the Common Pool was expected to increase the price to roughly 4.89 wxDAI per TestTEC.
On December 19, the vote was executed and the bonding curve became testable through the conversion interface. The price after the 250,000 test DAI initial buy was 4.8125629 tDAI per TestTEC. The initial buy purchased 94,462.382 TestTEC, which was sent to the Common Pool, and the entry fee returned 1,875 test DAI to the Common Pool.
By the end of the thread, the Commons Upgrade demo had completed successfully after surfacing and correcting several technical issues. The thread served as a launch-readiness record for migration, token minting, Gardens mutation, Conviction Voting activation, bonding curve opening, initial buy execution, fee accounting, and user testing. Its conclusion was that all technical aspects were ready for launch after the parameter debates.
2021-12-08 to 2021-12-31 — Reward System Working Group
Forum thread: Reward System Working Group Category: Working Groups / Archive Archive theme: Reward System, Working Group formation, Praise, SourceCred, quantification, dashboard, Reward Board, contributor compensation, analysis
December 8, 2021
This Working Groups thread formally documented the Reward System Working Group through a manifesto for redesigning the TEC reward system. The thread established a weekly meeting time, pointed contributors toward the working group’s Discord channel, and explained that the manifesto should remain a living document so that new participants would have a clear source of truth for onboarding.
The mission of the group was to design, implement, maintain, and continuously improve the TEC reward system. The system was described as a combination of Praise and SourceCred: Praise would capture qualitative and subjective contributions, while SourceCred would capture more objective activity across channels such as Discourse, GitHub, Twitter, and Discord meeting attendance. The thread emphasized that both systems needed active configuration, maintenance, and analysis rather than being treated as automatic infrastructure.
A central part of the plan was the development of a dashboard. The dashboard was expected to host quantifiers, randomly pair them with praise sets, support quantification rounds, and allow quantified data to be analyzed after each round. This made the reward system not only a distribution mechanism, but also a feedback system for understanding what kinds of value were being produced inside the Commons.
The proposed Reward Board was assigned the operational responsibilities around the system. These included submitting reward-distribution proposals to the DAO, converting wxDAI received from proposals into TEC through the bonding curve, sending TEC to the Reward DAO, setting up and explaining SourceCred parameters, recruiting and onboarding quantifiers, distributing rewards to contributors, reviewing analysis reports, proposing system changes, and evaluating whether the metrics were actually measuring ecosystem health.
The thread defined success as a working dashboard, engaged quantifiers, healthy integration between Praise and SourceCred, automated analysis, regular distributions, an active reward board, and a community that felt fairly rewarded. Failure conditions included the system being gamed, quantifiers failing to participate, the TEC refusing to fund rewards proposals, quantification not being delivered on time, or the Reward Board failing to review and distribute rewards reliably.
The roadmap tied the dashboard deadline to the Commons Upgrade and aimed for a first rewards quantification before Christmas, while acknowledging that most Reward Board responsibilities would be continuous. The post also listed members and responsibilities across treasury operations, SourceCred maintenance, identity onboarding, Praise parameter management, data analysis, communications, platform support, cultural insights, and funds distribution.
December 31, 2021
A later reply added a visual slide for the TEC Rewards System and connected the working group discussion to financial-analysis work. By the end of the thread, the Reward System Working Group had been framed as a standing operational body responsible for turning Praise, SourceCred, dashboard tooling, analysis, and DAO-funded distributions into a repeatable contributor-reward process.
2021-12-12 to 2021-12-13 — TEC Working Groups Weekly Update, Dec 12
Forum thread: TEC Working Groups Weekly Update, Dec 12th Category: Community Updates Archive theme: working group updates, Commons Upgrade extension, Gardens frontend, covenant update, Rewards WG, RADD, transparency audit, legal funding, CCD proposals
December 12 to December 13, 2021
This weekly update showed the TEC extending the Commons Upgrade process to allow more deliberation. Stewards reported the end of Sprint 23 and the beginning of Sprint 24, welcomed a new steward, and shared revised Commons Upgrade dates: Propose and Debate would continue through December 16, Debate and Rock the Vote would run from December 17 to 21, Stewards Council and voter pamphlet creation would run from December 21 to January 7, and the final runoff vote would take place January 7 to 13.
Gravity continued Nonviolent Communication programming and promoted support resources, including a request-support form, the Gravity survey, step-by-step process documentation, and weekly notes. Commons Swarm reported that the Gardens frontend was live and ready and that the bonding curve buy-and-sell interface was ready. Soft Gov reported that the Rewards System initiative was evolving into a working group, that the community would choose the top five Commons Upgrade proposals and representatives for debates by December 15, and that there was a new forum post about the updated TEC Community Covenant.
Communitas shared its three-month funding proposal, a new orientation deck, and a guide for people taking on guide roles. 0mega continued building the TE Consilience Library, described a three-phase curation plan, and prepared a co-design discussion around funding and sharing assets created within the group. Labs maintained its recurring research, Praise Evolution, DAO-to-DAO, Tokenspice, BlockScience, Longtail Financial, and Solidity study group work.
Communications, still moving toward T.E.A.M., continued Creative Onboarding recruitment and organization around five teams: TE Academy, HubSpot, Animation and Media, Translation, and Twitter Planning. Transparency shared a Commons Configuration Proposal, announced that the Transparency Audit Report was live, and pointed to its working group funding proposal. Legal continued work on ABC terms and a legal working group funding proposal. Params continued guiding participants through the Commons Configuration Dashboard, including funding-request simulation, Tokenlog proposals, and the one-week debate structure.
This update also marked the kickoff of the newly minted Rewards Working Group. Rewards reported that its trial praise quantification had moved to after the new year, that a demo of the Rewards Analytics and Distribution Dashboard was planned, that survey results on the other side of praise data were available, and that quantifiers were being recruited.
By the end of the update, the TEC had moved from proposal collection into a more deliberate upgrade process. The Commons Upgrade timeline was extended, Rewards had become a working group, the covenant and transparency reports were being updated, the bonding curve and Gardens interfaces were nearing readiness, and the community was preparing to narrow proposals into a final debate and voting process.
2021-12-13 — Vote Bolshevik’s Gambit (v4) for TEC Commons Config
Forum thread: Vote Bolshevik’s Gambit (v4) for TEC Commons Config! Category: Conviction Voting / Archive Archive theme: Commons Upgrade, Commons Configuration Proposals, Augmented Bonding Curve, TAO Voting, Conviction Voting, Token Freeze, Token Thaw, parameter voting
December 13, 2021
This Conviction Voting thread announced a fourth version of a Commons Configuration proposal for the TEC Commons Upgrade. The proposal presented itself as an ideological and technical configuration centered on a low opening price, a long freeze and thaw period, a relatively high Commons Tribute, entry and exit tributes, and a conviction voting design intended to protect the Common Pool from rapid or opportunistic depletion.
The proposed Token Freeze and Token Thaw settings set a twelve-week freeze, a fifty-two-week thaw, and a one wxDAI opening price. The proposal argued that a low opening price could reduce post-freeze sell pressure and encourage Hatchers to remain aligned with the mission, while later buy pressure from newcomers could be partially captured through an entry tribute. The Augmented Bonding Curve settings included a seventy percent Commons Tribute, eight percent Entry Tribute, ten percent Exit Tribute, and an output reserve ratio of about 19.34 percent. The argument framed early volatility as a feature that could help capture value for DAO funds while the reserve balance matured.
The TAO Voting settings proposed eighty-eight percent support required, eight percent minimum quorum, a six-day vote duration, a three-day delegated voting period, a two-day quiet ending period, a three-day quiet ending extension, and a one-day execution delay. The stated purpose was to give the community enough time to react if delegate votes diverged from broader community will, while still allowing an uncontested vote to complete in roughly a week.
The Conviction Voting settings proposed a seven-day conviction growth period, four percent minimum conviction, and an eighteen percent spending limit. The proposal described this as a protective configuration for the Common Pool, informed by work on Conviction Voting settings in other token-engineering contexts.
A follow-up comment pointed supporters toward Tokenlog as a place to express support for the proposal during the final parameter-selection process. By the end of the thread, the proposal had been framed as one of the Commons Configuration options competing for community attention during the Commons Upgrade process, combining economic caution, governance responsiveness, and a protective approach to Common Pool spending.
2021-12-15 — Have You Heard About The Fledge?
Forum thread: Have you heard about “The Fledge”? — (A TEC Commons Config Proposal) Category: Conviction Voting / Archive Archive theme: Commons Upgrade, Commons Configuration Proposals, Fledge phase, impact investors, Token Freeze, Token Thaw, Augmented Bonding Curve, TAO Voting, Conviction Voting
December 15, 2021
This Conviction Voting thread introduced “The Fledge” as a Commons Configuration proposal for the TEC Commons Upgrade. The proposal framed the Hatch as a protected initialization phase and argued that the TEC might need a second developmental period before fully entering the open market. In this framing, the community had broken through the shell of the Hatch, but still needed time, funding, communications capacity, and price support before the Commons could “fly.”
The proposal’s core strategic assumption was that the TEC had spent much of the prior year looking inward, getting its own house in order, and that generating broader demand for the TEC token would require significant communication and outreach work. It also argued that the impact of TEC’s investments would not appear immediately, so the system should preserve breathing room while the value of the Commons became more visible. During this “Fledge” period, the proposal expected fewer mass-market entrants and more mission-driven impact investors who already understood and cared about the project.
The proposed configuration reflected that theory. It set a long Token Freeze of fifty-two weeks, a fifty-two-week Token Thaw, and a 1.5 wxDAI opening price. For the Augmented Bonding Curve, it proposed an eighty percent Commons Tribute, thirty percent Entry Tribute, zero percent Exit Tribute, and an output reserve ratio of 8.6 percent. The heavy Commons Tribute and Entry Tribute were justified as acceptable to impact investors who cared more about funding token engineering work than minimizing volatility or maximizing speculative upside. The zero Exit Tribute was intended to avoid making contributors effectively pay twice: once through labor and again through capital friction.
The proposal also assumed that TEC should not be transferable during the Fledge, at least while a thirty percent Entry Tribute was in place, because tradability could create major arbitrage incentives in secondary markets. The author treated later reactivation of transferability as an open question.
The governance settings proposed eighty-eight percent TAO Voting support required, forty percent minimum quorum, a ten-day vote duration, a five-day delegated voting period, a two-day quiet ending period, a two-day quiet ending extension, and a one-day execution delay. The Conviction Voting settings proposed a fourteen-day conviction growth period, three percent minimum conviction, and a four percent spending limit, creating a cautious funding environment during the proposed Fledge phase.
By the end of the thread, The Fledge had been presented as a Commons Configuration proposal built around patience, impact-investor bridge funding, communications investment, long-term contributor protection, and conservative Common Pool spending. It contrasted with proposals that prioritized immediate market openness or stronger reserve backing by arguing that TEC first needed a protected post-Hatch period to mature into a visible, fundable, and outward-facing Commons.
2021-12-15 — Reserve Ratio Matters, Change My Mind
Forum thread: Reserve ratio matters, change my mind for TEC Commons Config! Category: Conviction Voting / Archive Archive theme: Commons Upgrade, Commons Configuration Proposals, reserve ratio, liquidity, Hatchers, speculators, builders, Token Freeze, Augmented Bonding Curve, Conviction Voting
December 15, 2021
This Conviction Voting thread nominated a Commons Configuration proposal centered on the claim that reserve ratio mattered more than many competing proposals were recognizing. The opening argument warned that configurations with reserve ratios below twenty-five percent could create liquidity and confidence problems, especially if Hatchers wanted to sell and there was not enough reserve backing to support exits at reasonable prices. The proposal also framed the issue as a deeper strategic choice: whether the TEC wanted to become a broader token engineering economy or remain primarily a Hatcher-centered economy.
The proposal described itself as a middle-ground economic design intended to balance multiple actors. Hatchers should feel rewarded, speculators should be allowed to participate without being overly punished, builders should feel that the economy is stable enough to hold TEC, and the Common Pool should still have enough funding to begin work. The configuration prioritized a relatively high reserve ratio compared with other proposals, even if that meant accepting a more limited Common Pool and a governance system where funding proposals might be harder to pass.
The Token Freeze and Token Thaw settings proposed a thirty-two-week freeze, twenty-six-week thaw, and 1.05 wxDAI opening price. This was framed as a low opening price that could support a healthy economy with a higher reserve and a meaningful Common Pool, while keeping contributors visibly connected to the economy through a little more than a year of vesting.
The Augmented Bonding Curve configuration proposed a fifty percent Commons Tribute, 0.75 percent Entry Tribute, 0.75 percent Exit Tribute, and an output reserve ratio of 30.70 percent. The low entry and exit tributes were intended to encourage speculation and arbitrage activity that could still fund token engineering public goods, while the larger reserve ratio was meant to provide more stability and confidence than low-reserve alternatives.
For TAO Voting, the proposal used seventy-five percent support required, fifteen percent minimum quorum, a seven-day vote duration, a four-day delegated voting period, a half-day quiet ending period, a two-day quiet ending extension, and a half-day execution delay. For Conviction Voting, it proposed a fifteen-day conviction growth period, two percent minimum conviction, and thirteen percent spending limit, acknowledging that proposals might be harder to pass but arguing that this would help the Commons use resources more wisely.
By the end of the thread, the proposal had positioned itself as a stability-first Commons Configuration. It argued that a high Common Pool with a low reserve ratio might help in the first year but would be a poor long-term solution, while a higher reserve ratio could better support a balanced economy across Hatchers, builders, speculators, and future participants.
2021-12-15 — Ostrom’s 1 Million Dollar Baby
Forum thread: Commons Upgrade Parameter Runoff - Vote for Ostrom’s 1 million dollar baby for TEC commons config #84 Category: Conviction Voting / Archive Archive theme: Commons Upgrade runoff, Ostrom-inspired configuration, Token Freeze, Token Thaw, Augmented Bonding Curve, reserve ratio, Common Pool funding, TAO Voting, Conviction Voting
December 15, 2021
This Conviction Voting thread presented a Commons Upgrade parameter proposal inspired by Ostrom’s commons principles and framed around the image of a baby being born. The proposal argued that the TEC should continue using Ostrom as guidance for its Commons Configuration and described the option as fun, secure, and able to allow both stability and change.
The configuration set an eighty-week vesting period, split into forty weeks of Token Freeze and forty weeks of Token Thaw. This was described as short enough to remain under two years while still long enough to create a meaningful post-Hatch maturation period. The metaphor of a baby’s development was used to justify the timing, tying the vesting schedule to the idea that the Commons needed time to grow before becoming fully liquid.
The Augmented Bonding Curve settings proposed a 0.63 wxDAI opening price, a seventy-eight percent Commons Tribute, eight percent Entry Tribute, two percent Exit Tribute, and an output reserve ratio of 22.51 percent. The key argument was that the low opening price would allow the initial buy to acquire a large amount of TEC for the community while still maintaining a comparatively strong reserve ratio. After the initial buy, the post-buy price was expected to rise to about 1.01 wxDAI, close to the Hatch price, while leaving roughly one million wxDAI in the Common Pool and about 500,000 wxDAI in reserve.
The proposal also included a planned tribute transition over six months, gradually moving from an eight percent entry tribute and two percent exit tribute toward a two percent entry tribute and eight percent exit tribute. This treated the opening phase as a period where early participants contributed more to the Commons on entry, while later phases would shift more cost toward exit.
For TAO Voting, the proposal mostly kept Hatch DAO defaults: eighty-eight percent support required, eight percent minimum quorum, seven-day vote duration, four-day delegated voting period, three-day quiet ending period, two-day quiet ending extension, and one-day execution delay. For Conviction Voting, it proposed three-day conviction growth, three percent minimum conviction, and a nine percent spending limit, with an expectation that funding requests in the 20,000 to 50,000 wxDAI range could pass as accountable milestone-based proposals.
By the end of the thread, this proposal had been positioned as an Ostrom-inspired runoff configuration that combined a long but bounded vesting schedule, a psychologically low opening price, a one-million-wxDAI Common Pool target, stronger reserve backing than many low-reserve proposals, mostly familiar TAO Voting defaults, and Conviction Voting settings aimed at making medium-sized milestone funding feasible.
2021-12-16 to 2021-12-20 — Ostrom’s $1,000,000 Hatch, Fledge & Fly
Forum thread: Ostrom’s $1,000,000 Hatch, Fledge & Fly! (Commons config proposal #126) Category: Conviction Voting / Archive Archive theme: Commons Upgrade, Commons Configuration Proposals, Hatch, Fledge, Common Pool funding, scheduled tributes, ambitious proposals, Conviction Voting, Celeste
December 16, 2021
This Conviction Voting thread presented a Commons Configuration proposal that tried to synthesize lessons from several competing proposals, including The Fledge, Goldilocks-style opening-price ideas, Bolshevik’s Gambit, and Montaña Rusa. Its core metaphor was “Hatch, Fledge, Fly”: the TEC had hatched, but still needed a protected period to mature before fully entering open market conditions.
The proposal argued for a long thaw because the Hatch had been based on the premise that Hatchers were committed to long-term mission-driven goals over short-term individual gains. A thirty-nine-week freeze and sixty-five-week thaw would keep a floor above the Hatch price for the first year, while gradually making Hatcher tokens liquid. The proposal framed that year as time for TEC to build reputation, strategy, and agility in changing market conditions.
The second major design goal was to place roughly one million wxDAI into the Commons Pool for funding proposals. The post treated the psychological and operational importance of that number as significant because it meant real resources could be allocated to mission-serving work. It tried to balance Commons Tribute, Entry Tribute, and Exit Tribute across existing Hatchers and future TEC token holders. The initial proposal suggested scheduled tribute changes over time, with entry tribute stepping down and exit tribute stepping up every six weeks, turning early impact investing into a later more conventional investing environment.
The proposal also argued for a higher Conviction Voting spending limit than some cautious alternatives. Low spending limits were described as useful checks on projects, but also administratively burdensome for larger initiatives that need multi-month funding commitments. Ambitious projects such as education programs might need longer funding runways to hire contributors and execute reliably. The proposal therefore relied partly on Celeste and reporting/accountability norms as safeguards against bad-faith or failing proposals.
The original parameter set proposed a thirty-nine-week freeze, sixty-five-week thaw, 1.5 wxDAI opening price, seventy-three percent Commons Tribute, sixteen percent Entry Tribute, five percent Exit Tribute, and an output reserve ratio of 11.60 percent. TAO Voting used eighty-eight percent support required, eight percent minimum quorum, six-day vote duration, three-day delegated voting period, two-day quiet ending period, three-day quiet ending extension, and one-day execution delay. Conviction Voting used a fourteen-day conviction growth period, five percent minimum conviction, and twenty percent spending limit.
December 17 to December 20, 2021
Follow-up discussion explored the implications of staged tribute reductions. One response suggested that early high tribute phases could be treated as impact investing and recognized through POAPs, almost like price skimming for public-good investors: early participants would accept higher tributes because they wanted impact and status rather than only financial upside. Another response supported the proposal’s critique of low spending limits, arguing that large education efforts with many contributors and long timelines could not operate efficiently through very short funding cycles and that the Commons should think big while requiring reporting and accountability.
Another question asked whether larger funding commitments could be made safer through payment streams that could be suspended through Celeste if major issues emerged. This connected the spending-limit debate to broader concerns about voter fatigue, funding assurance, and risk management for ambitious programs.
After a parameter debate, the author revised the proposal into a new version. The revised version kept the thirty-nine-week freeze and sixty-five-week thaw, raised the opening price to 2.71, targeted a public post-initial-buy price of 4.20, and let go of the strict one million wxDAI Common Pool target while still preserving about 927,000 wxDAI on day one. The revised reserve ratio became 7.14 percent. The author also removed scheduled tribute step changes, arguing that they were unenforceable because future token holders would differ from current voters and might resist raising their own exit costs. Instead, the revised design set Entry and Exit Tributes to twelve and eight percent and suggested revisiting tribute changes later based on empirical data.
By the end of the thread, the proposal had evolved from a staged-impact-investor configuration into a more pragmatic revision that preserved the long Hatch-to-Fledge vision while simplifying tribute design. The thread captured a major Commons Upgrade design debate around long-term Hatcher commitment, Common Pool size, opening price psychology, tribute enforceability, ambitious funding, Celeste-backed accountability, voter fatigue, and whether the TEC should optimize for cautious small grants or large mission-building initiatives.
2021-12-19 — Montaña Rusa: The Communist Roller-Coaster v2
Forum thread: Montaña Rusa: The Communist Roller-Coaster v2 Category: Conviction Voting / Archive Archive theme: Commons Upgrade, Commons Configuration Proposals, Augmented Bonding Curve, volatility, Common Pool funding, Token Freeze, Token Thaw, TAO Voting, Conviction Voting
December 19, 2021
This Conviction Voting thread nominated “Montaña Rusa: The Communist Roller-Coaster v2” as a Commons Configuration proposal. The proposal described itself as a fork of earlier configuration ideas, combining the market-facing volatility of one approach with the Common Pool funding emphasis of another. Its central claim was that the TEC could give the market a dynamic, interactive bonding curve while still empowering the Commons with roughly one million wxDAI for initial proposals.
The economic strategy was to start with relatively volatile conditions that would encourage interaction with the bonding curve. The proposal argued that a lower reserve ratio could generate more bonding curve activity, while an eight percent entry tribute and two percent exit tribute would route value into the Common Pool. It also suggested that once the token freeze ended and secondary markets developed, the tributes could be adjusted toward an even five percent entry and five percent exit structure.
The Token Freeze and Token Thaw settings proposed a sixteen-week freeze, an eighty-eight-week thaw, and a 0.95 wxDAI opening price. The Augmented Bonding Curve settings proposed a seventy-seven percent Commons Tribute, eight percent Entry Tribute, two percent Exit Tribute, and an output reserve ratio of 15.61 percent. This made the proposal more aggressive on Common Pool funding and more accepting of early price volatility than higher-reserve configurations.
For TAO Voting, the proposal used eighty-eight percent support required, eight percent minimum quorum, a six-and-a-half-day vote duration, a three-and-a-half-day delegated voting period, a one-day quiet ending period, a two-and-a-half-day quiet ending extension, and a one-day execution delay. For Conviction Voting, it proposed a fourteen-day conviction growth period, three percent minimum conviction, and sixteen percent spending limit.
By the end of the thread, Montaña Rusa had been framed as a high-energy Commons Configuration option that embraced early volatility as a mechanism for market interaction and Common Pool funding. The proposal prioritized funding initial Commons work, encouraging bonding curve activity, and later rebalancing tributes once the TEC economy had moved beyond the freeze period and secondary markets had formed.
2021-12-20 — Balanced Modifications to Ostrom’s Hatch, Fledge & Fly
Forum thread: Please consider my balanced modifications to one of our top 3 choices! Mod’s made to Ostrom’s $1,000,000 Hatch, Fledge & Fly! Category: Conviction Voting / Archive Archive theme: Commons Upgrade, Commons Configuration Proposals, Ostrom fork, balanced parameters, reserve ratio, trading incentives, spending limits, Tokenlog
December 20, 2021
This Conviction Voting thread proposed a modified version of the Ostrom’s $1,000,000 Hatch, Fledge & Fly configuration after the Sunday parameter debates. The author described the proposal as a balanced and conservative fork that softened several of the most extreme variables while leaving the broader structure of the original intact. The goal was to keep the community thriving while making the proposal more viable for a wider range of voters.
The changes focused on reducing the length and intensity of several parameters. Token Thaw was reduced from sixty-five weeks to fifty-two weeks, while Token Freeze remained thirty-nine weeks and the opening price remained 1.5 wxDAI. This preserved the idea of a longish contributor lockup and a floor above the Hatch price for the first year, but made the vesting path less extended than the original Ostrom proposal.
The Augmented Bonding Curve changes were more substantial. Commons Tribute was reduced from seventy-three percent to fifty-five percent, Entry Tribute was reduced to three percent, and Exit Tribute was set at five percent. The stated reason was to avoid overly disincentivizing trading. This produced an output reserve ratio of 19.34 percent and a funding allocation that still left a meaningful Common Pool while strengthening the reserve compared with the more aggressive impact-investor versions.
The TAO Voting settings used eighty-eight percent support required, eight percent minimum quorum, six-day vote duration, three-day delegated voting period, two-day quiet ending period, three-day quiet ending extension, and one-day execution delay. The proposal emphasized that support required and quorum were strengthened relative to the forked baseline.
The Conviction Voting settings were also damped: conviction growth was reduced from fourteen days to ten days, and the spending limit was reduced from twenty percent to ten percent while keeping minimum conviction at five percent. This shift made the funding side more cautious than the original, reducing the risk associated with very large proposals while still allowing meaningful spending through Conviction Voting.
The thread repeated the underlying strategy from the original Ostrom proposal but inserted explicit bracketed changes to show where the fork diverged. It also included a Hatcher token release schedule, fund allocation numbers before and after the initial buy, and a graph explaining how TEC price changes with ABC reserve holdings.
By the end of the thread, this proposal had positioned itself as a compromise configuration: still inspired by Ostrom’s Hatch-Fledge-Fly vision, but with lower tributes, a stronger reserve ratio, less aggressive spending, and fewer disincentives for market participation. It captured a late-stage attempt to translate one of the top Commons Configuration choices into a more moderate option for voters.
2021-12-20 to 2022-01-10 — 4.20 Public Open Meets Ostrom’s $1M Hatch, Fledge & Fly
Forum thread: Commons Upgrade Parameter Runoff - 4.20 Public Open Meets Ostrom’s $1M Hatch, Fledge & Fly! Category: Conviction Voting / Archive Archive theme: Commons Upgrade runoff, 4.20 public opening price, Ostrom fork, Token Freeze, Token Thaw, Augmented Bonding Curve, market valuation, governance concentration
December 20, 2021
This Conviction Voting thread reposted and promoted a Commons Upgrade runoff proposal called “4.20 Public Open Meets Ostrom’s $1M Hatch, Fledge & Fly.” The proposal was explicitly presented as a modified version of the earlier Ostrom-inspired configuration, incorporating feedback from debates and several other proposals while raising the post-initial-buy public opening price to the culturally resonant value of 4.20 wxDAI.
The strategy kept the long Hatcher commitment structure from the Ostrom proposal: thirty-nine weeks of Token Freeze and sixty-five weeks of Token Thaw. The argument was that Hatchers were long-term, mission-driven participants and that the TEC needed a secure floor above the Hatch price for roughly the first year while it built reputation, strategy, and market agility. Under the release schedule, Hatcher tokens would begin thawing after nine months, with about twenty percent liquid after one year and sixty percent after one and a half years.
The ABC design raised the opening price to 2.71 wxDAI and expected the initial buy to bring the public price near 4.20 wxDAI. The proposal let go of a strict one-million-wxDAI Common Pool target, instead accepting roughly 927,000 wxDAI available on day one, with a reserve ratio of about 7.14 percent. It removed earlier ideas of scheduled tribute changes because future token holders could not be guaranteed to vote for higher exit tributes later. Instead, it set Entry Tribute at twelve percent and Exit Tribute at eight percent, treating that as a more realistic launch balance that could be evaluated later.
The TAO Voting configuration lowered support required and quorum compared with more conservative options. It proposed seventy-seven percent support required, seven percent minimum quorum, five-day vote duration, three-day delegated voting period, two-day quiet ending period, three-day quiet ending extension, and one-day execution delay. The reasoning was that the Commons should not make ordinary governance too hard to pass while still requiring meaningful opposition to block changes.
The Conviction Voting settings used fourteen-day conviction growth, five percent minimum conviction, and twenty percent spending limit. The proposal argued that ambitious projects should be able to request longer funding runways rather than constantly returning for small monthly requests. It acknowledged the risk of larger spending proposals, but pointed to Celeste and community reputation as safeguards and argued that funding votes should take more than twenty-four hours so global token holders had time to see them.
A follow-up comment supported the proposal on the grounds that TEC should not undervalue itself. It contrasted this configuration’s roughly nine-million-dollar launch valuation with lower-valued alternatives and argued that token engineering, culture, intellectual capital, and market conditions justified a higher starting valuation. Another later response supported the proposal as a way to avoid underselling TEC while giving the Commons a transition period of relative stability.
December 30, 2021 to January 10, 2022
Later discussion connected the thread back to the original Ostrom proposal and raised concerns from the voter pamphlet. One concern was that the high price could make it difficult for newcomers to gain governance weight, since fewer TEC would be minted for future contributors and buyers. A response argued that this governance concentration might moderate as Hatchers gradually sold tokens, allowing governance to open over time as part of the Fledge process.
The proposal’s author acknowledged that raising the perceived value of TEC created an unintended governance-concentration consequence. The design could make rewarded contributors receive a smaller governance stake for their work, but it also made TEC harder for a deep-pocketed actor to capture. This reframed the high-price design as a tradeoff between fairness to future participants, protection against governance capture, and confidence in TEC’s higher launch valuation.
By the end of the thread, 4.20 Public Open had become a high-valuation runoff option. It emphasized long Hatcher vesting, a higher public opening price, a near-million-wxDAI Common Pool, lower reserve ratio, realistic fixed tributes, easier TAO Voting, ambitious Conviction Voting funding, and strong resistance to outside governance capture, while openly recognizing the risk that newcomers and future contributors could receive less governance influence.
2021-12-16 to 2022-10-06 — TE Ethics Participatory Research Initiative
Forum thread: TE Ethics Participatory Research - an 0mega WG initiative Category: Conviction Voting / Archive Archive theme: 0mega, TE Ethics, participatory research, contextual ethics, focus groups, practice sessions, ethical principles, informed participation, Proposal Inverter, self-sovereignty
December 16, 2021
This Conviction Voting thread introduced TE Ethics Participatory Research as a 0mega Working Group initiative. The proposal described 0mega as trying to answer how a Token Engineering ethos could emerge from globally diverse backgrounds rather than being imposed through a single prescriptive moral framework. The initiative aimed to let token engineering ethical principles emerge through focus groups, analysis sessions, and practice sessions led by self-selected facilitators.
The proposal argued for contextual ethics in token engineering. Token networks are complex, adaptive, and global, so simple slogans or fixed rules would not be enough. The process was designed to help token engineers become more aware of tradeoffs, worldviews, and the legitimacy of algorithmic policies in token economies. It also connected the work to the “Inner Game” of token engineers, treating ethical reasoning as a practice that had to be learned through reflection, role play, and facilitated exercises.
The proposed process had several stages: collect ethical dilemma topics from 0mega sessions and chat, choose topics for focus groups, host and analyze focus groups, let ethical principles emerge through analysis, recruit facilitators to design practice sessions around each principle, and then document recordings and materials in a shared status table and the TEC GitBook.
The initial principles named in the proposal were hosting multiple worldviews, navigating dynamic landscapes, being aware of social engineering, and enabling informed participation. Each principle was paired with a possible practice session, such as a worldviews game, mental models and decision-making frameworks, “can’t be evil” and TRIZ-style exercises, and a capabilities approach session.
The proposal requested 15,000 wxDAI, with part intended to recognize focus group participants and part intended to compensate facilitators who would prepare, host, and post-process the practice sessions. Progress would be shared through recordings, documentation, focus group analysis, weekly 0mega calls, and the live current-status document.
December 16, 2021 to January 28, 2022
Early replies were supportive and asked how to help. A budget clarification followed, especially around whether the focus group participant allocation should be paid in TEC or xDAI and how much should go to facilitators versus participants. The discussion also raised the possibility that participants and facilitators might prefer TEC tokens, even though the DAO could only pay directly in xDAI and would need someone to handle conversion if recipients wanted TEC.
The thread then connected the proposal to Proposal Inverter work. A follow-up suggested that the funding numbers could be reflected in an Inverter proposal involving TE Academy, TEC, 0mega, and Longtail Financial, and another comment shared a timeline of Proposal Inverter work sessions as a way to understand the mechanism.
October 6, 2022
Months later, the thread was updated with a reference to a leaner 0mega working group proposal that was more focused on the heart of TE Ethics: finding self-sovereignty. This update suggested that the original TE Ethics participatory research process had continued to evolve and had been narrowed or reframed as 0mega adjusted its scope.
By the end of the thread, TE Ethics Participatory Research had established a process-oriented approach to ethics for token engineering. It connected focus groups, contextual ethics, practice-based learning, emergent principles, facilitator-led sessions, compensation questions, TEC-versus-xDAI payouts, Proposal Inverter experimentation, 0mega’s broader knowledge work, and the continuing effort to make ethical reasoning a living practice rather than a static code of conduct.
2021-12-17 to 2022-03-04 — TE Consilience Library Initiative
Forum thread: TE Consilience Library - an 0Mega WG initiative Category: Conviction Voting / Archive Archive theme: 0mega, TE Consilience Library, token engineering education, interdisciplinary curation, seed curators, public contribution, reputation, ethics, knowledge commons
December 17, 2021
This Conviction Voting proposal introduced the TE Consilience Library as a 0mega Working Group initiative. The proposal described token engineering as an emerging discipline at the intersection of engineering, Web3 token ecosystems, social systems, and economic systems. It argued that while cryptoeconomics was interdisciplinary in principle, much of the field had developed from a computer science perspective and had not yet fully incorporated the wider literature from economics, ethics, arts, social science, and systems thinking.
The library was framed through the ideas of consilience and integral theory: linking different forms of evidence and different paradigms into a more coherent body of knowledge. The proposed library would be a crowdsourced and curated database around the disciplines related to crypto-economic systems engineering. Its first version would begin with “seed curations” from subject matter experts, each gathering five to ten resources and explaining how their selection enriched understanding of token engineering.
The project was organized into three phases. Phase one would build a Notion-based library, produce a manifesto and contributor guidelines, coordinate seed curators, and create the initial body of curated knowledge. Phase two would open the library to public contributions, with librarians reviewing submissions and rewarding high-quality curations. Phase three, if the community wanted further development, would add a more engaging user experience, meta profiles, expertise badges, reputation points, and upvoting of curations.
The funding request focused on phase one and asked for 15,000 xDAI. The budget covered library content curation, library design, 0mega research, advisory work, and future bounties for phase two. Progress would be shared through weekly 0mega calls, forum updates, open access during phase two, and coordination with Communications to attract more curators and publicize the work.
December 17 to December 23, 2021
Early replies supported the idea as a needed learning resource for emerging token engineers. The discussion emphasized the uniqueness of the library’s transdisciplinary approach and the value of capturing not only formal technical resources, but also the oral traditions, lived stories, and contextual knowledge that had shaped token engineering communities.
The thread began to treat the library not merely as a collection of links, but as a way to inscribe and share the field’s developing culture. Supporters saw it as a research hub, a learning pathway, and a record of how people in the token engineering ecosystem had arrived at their understanding.
February 2 to March 4, 2022
The proposal was later updated with new roles and tasks as the group refined how to steward the Consilience narrative. A substantive follow-up suggested that seed curations should embody consilience more strongly by crossing two or more petals of the crypto-economic flower, rather than staying within one subject area. It also argued that annotations should include curators’ personal experiences in token engineering and token economies, so that expert and newcomer perspectives could both provide value.
Further reflections expanded the project into a more explicitly co-creative and artistic knowledge commons. The library was described as a center of the crypto-economic flower and a way to reveal assumptions and blind spots in the digital landscapes being built. The discussion connected the library to ethics, creativity, systems thinking, integral learning, and the possibility of documenting artistic and memetic processes as part of token engineering research.
The final update incorporated that feedback: seed curations would include two or more petals, and the library would also function as a living log of 0mega’s co-creative artistic processes. By the end of the thread, the TE Consilience Library had evolved from a curated resource proposal into a broader knowledge-commons initiative: a funded library, a participatory research archive, and a transdisciplinary cultural record for the token engineering field.
2021-12-20 to 2021-12-21 — TEC Working Groups Weekly Update, Dec 20
Forum thread: TEC Working Groups Weekly Update, Dec 20th Category: Community Updates Archive theme: working group updates, Commons Upgrade voting, ABC readiness, final parameter vote, RADD, T.E.A.M., legal terms, CCD proposals
December 20 to December 21, 2021
This weekly update covered the December 9 to 16 working group period while the TEC was in Sprint 24 and moving through the final Commons Upgrade deliberation process. Stewards reiterated the extended Commons Upgrade timeline: Propose and Debate through December 16, Debate and Rock the Vote from December 17 to 21, Stewards Council and voter pamphlet creation from December 21 to January 7, and the final runoff vote from January 7 to 13. The update also pointed contributors toward ZenHub issues, the Steward three-month funding proposal, the TE Academy introduction course, and a new article on permissionless DAOs.
Gravity promoted a Graviton get-together, continued the Nonviolent Communication book club, encouraged support for its Gitcoin grant, and shared support resources including the request-support form, Gravity survey, step-by-step process, and weekly notes. The update also celebrated the second generation of Gravitons, marking an expansion of the community’s conflict-resolution capacity.
Commons Swarm reported that the ABC audit had been completed, an issue had been fixed, and the team was ready “for real” this time. The Gardens frontend was live, EVM Crispr was live, and the interface for buying and selling tokens directly from the bonding curve was available. Soft Gov reported that five people had rallied behind five Commons Configuration proposals and that the community was ready to move forward with voting. A comparison chart was shared for undecided voters, and the update directed the community to vote on the final Commons Upgrade parameters.
Communitas continued its weekly sync, orientation call, and TEC Lounge schedule, promoted its three-month funding proposal, shared a new orientation deck, and sought more guides for onboarding. 0mega reported two initiatives and funding proposals: TE Ethics Participatory Research and the TE Consilience Library. It also announced a break from weekly meetings until early January.
Labs continued focusing on Rewards System Research, the Praise Evolution Taskforce, DAO-to-DAO model workshops, Tokenspice development, BlockScience office hours, Longtail Financial office hours, and the Solidity study group. Communications, soon to become T.E.A.M., continued Creative Onboarding recruitment and reported that five post-Commons Upgrade teams had formed around TE Academy, HubSpot, Animation and Media, Translation, and Twitter Planning, with bounties expected soon.
Transparency reported that the Transparency Audit Report was live, reminded the community about its funding proposal, and shared the Transparency WG manifesto and sync schedule. Legal reported work on the Covenant, proposal terms and conditions, and ABC terms, while continuing to seek DAO legal contributors. Params pointed people to the Commons Configuration Dashboard, Params Parties, the new funding-request simulation feature, Tokenlog Commons Configuration proposals, and the one-week debate format for five proposals. Rewards put out a call for backend developers, reported that the Rewards Analytics and Distribution Dashboard had been demoed, shared survey results from the other side of Praise data, and continued recruiting quantifiers.
By the end of the update, the TEC was in the final stretch before selecting Commons Upgrade parameters. The ABC and Gardens interfaces were ready, the final parameter proposals had enough support to proceed, the dashboard had matured into a voting-support tool, legal and transparency materials were live, the Rewards Working Group was building infrastructure, and communications teams were forming around the post-upgrade public face of the Commons.
2021-12-23 — Voter Pamphlets
Forum thread: Voter Pamphlets Category: Community Updates Archive theme: Commons Upgrade runoff, voter pamphlets, proposal comparison, parameter education, decision support, Soft Gov
December 23, 2021
This community update thread asked what information would help people make an informed decision about the Commons Upgrade runoff votes. It opened the design process for voter pamphlets, framing them as decision-support materials for a community trying to compare complex parameter proposals.
The thread summarized points from a Soft Gov call. The pamphlets should help voters understand how each proposal would affect the TEC’s future, whether subjective community opinions should be included, and whether there should be one objective pamphlet plus a second opinion-oriented pamphlet. The discussion suggested comparing the top five key parameters across proposals, asking proponents objective questions and publishing their answers, and presenting concise pros and cons for each proposal.
The thread also proposed mapping proposals across parameter spectrums rather than only showing tables. For example, proposals could be positioned between inclusivity for new members and longer Hatcher voting power, or assessed against worst-case scenarios. The intended audience might include people who had not participated in earlier Tokenlog voting, so the materials needed to simplify the decision one layer further without hiding important tradeoffs.
The post then listed parameter areas that the pamphlet should help voters think through. For Token Freeze, Token Thaw, and total vesting period, it asked whether the freeze-to-thaw ratio supported long-term sustainability. For opening price, it asked how psychological effects, Hatcher vesting, and new token holders should shape price selection. For Common Pool funding, it asked how the pool amount would advance token engineering and whether it would affect voter behavior.
For Conviction Voting, the thread asked how many proposals could be completed before vesting ended, how much subjective value funded proposals would need to create to secure the economy, how freeze and conviction growth interacted, whether everyone would have time to participate in votes, what proposal sizes could pass, and what different active-voter percentages could approve. It also raised entry and exit tribute tradeoffs, reserve-ratio tradeoffs between volatility and fairness for later entrants, quorum relationships to reserve ratio and token distribution, and the role of delegated voting in supporting higher quorum.
By the end of the thread, the voter pamphlet had been framed as more than a neutral summary. It was a civic education tool for the Commons Upgrade, intended to translate complex parameter sets into comparable tradeoffs, risks, scenarios, and questions that would help TECH holders vote with a clearer understanding of what each configuration implied.
2021-12-27 to 2022-01-03 — Testing the Bonding Curve for the Commons Upgrade Runoff
Forum thread: Testing the Bonding curve of the proposals for the commons upgrade the run-off vote Category: Conviction Voting / Archive Archive theme: Commons Upgrade runoff, bonding curve simulations, voter pamphlets, ABC testing, governance distribution, reserve behavior, sell pressure
December 27, 2021
This Conviction Voting thread shared bonding curve tests for the Commons Upgrade runoff proposals, intended to enrich the voter pamphlet work that was being prepared for the community. The tests compared the finalist configurations under common stress scenarios rather than only looking at their starting parameters.
The first testing condition simulated a ten-million-wxDAI buy into each proposal’s bonding curve followed by a one-million-TEC sell, roughly equivalent to half of Hatcher tokens becoming sell pressure after vesting. The second condition asked how much wxDAI would be required to mint approximately two million TEC, matching the scale of the initial Hatcher distribution. Together, these scenarios tested how much governance newcomers could acquire, how sharply token price would rise under large buy pressure, and how far price would fall if a large portion of Hatchers later exited.
The results showed sharp differences among the proposals. The 4.20 public-open configuration minted far fewer new TEC under a ten-million-wxDAI buy, giving newcomers only about one-fifth of Hatcher-scale governance, but it also produced an extreme post-buy price and a severe price crash if one million TEC were sold afterward. By contrast, Mathmematics V4, Bolshevik’s Gambit, Goldilocks, and Ostrom’s 1 Million Dollar Baby each minted far more TEC under the same buy scenario, giving newcomers a much larger governance share, but their post-sell prices remained above the initial Hatch and bonding-curve prices.
The thread also compared the amount of wxDAI needed to mint roughly two million TEC across proposals. The results ranged from around ten million wxDAI for Ostrom’s 1 Million Dollar Baby to tens of millions for other proposals and an extremely high amount for the 4.20 public-open configuration. This made the tradeoff visible: some proposals protected Hatcher governance concentration much more strongly, while others made it easier for new capital to enter and obtain a governance-relevant position.
January 3, 2022
A later update added another testing set using a fifty-million-wxDAI buy and a sell of half the Hatcher token supply. This extended the analysis beyond the voter-pamphlet scenario and continued stress-testing the runoff proposals under larger market-entry conditions.
By the end of the thread, bonding curve testing had become part of the Commons Upgrade decision process. The discussion translated abstract ABC parameters into voter-facing consequences: newcomer governance share, buy pressure, sell pressure, post-buy prices, post-exit prices, reserve behavior, and how different proposals might respond once the TEC opened to larger flows of capital.
2021-12-29 — Goldilocks’ 1M to Advance Token Engineering
Forum thread: Commons Upgrade Parameter Runoff - Goldilocks’ 1 mil to Advance Token Engineering #127 Category: Conviction Voting / Archive Archive theme: Commons Upgrade runoff, Goldilocks configuration, Common Pool funding, entry and exit tributes, reserve ratio, TAO Voting, Conviction Voting
December 29, 2021
This Conviction Voting thread presented the Goldilocks runoff proposal for the Commons Upgrade parameters. The proposal described itself as a fork of earlier configuration work, combining elements from previous Token Thaw, TAO Voting, Conviction Voting, and Augmented Bonding Curve proposals. Its goal was to find a “just right” balance: a one wxDAI opening price, roughly one million wxDAI in the Common Pool, a reserve ratio around twenty percent, a five-day TAO Voting process, and a tribute strategy that could evolve after launch.
The proposal assumed a strong community capable of coordinating around both TAO Voting and Conviction Voting. Its economic strategy used a high initial Entry Tribute as a minting tax that could attract value-aligned participants who missed the Hatch while helping fund the advancement of token engineering. It proposed beginning with a twenty-two percent Entry Tribute and two percent Exit Tribute, then gradually inverting those values over five months until the entry tribute reached two percent and the exit tribute reached twelve percent. This staged tribute strategy was framed as both a funding mechanism and a way for the community to practice governance early.
The Token Freeze and Token Thaw settings proposed a twenty-six-week freeze, fifty-two-week thaw, and one wxDAI opening price. The argument was that six months was a reasonable freeze period in crypto, and the year-long thaw would keep most Hatcher tokens locked for long enough to reduce immediate sell pressure. The schedule showed Hatcher tokens beginning to thaw after six months, with twenty-five percent liquid at nine months, fifty percent at one year, and full release by one and a half years.
The Augmented Bonding Curve settings proposed a sixty-nine percent Commons Tribute, twenty-two percent Entry Tribute, two percent Exit Tribute, and an output reserve ratio of 19.98 percent. The proposal argued that even with a relatively low reserve balance, the one wxDAI opening price preserved a healthy reserve ratio while allowing price growth and useful volatility. The 250,000 wxDAI initial buy was expected to raise the price by about thirty-eight cents, giving Hatchers an immediate paper gain while bringing the Common Pool near one million wxDAI after a modest amount of early token buying.
For TAO Voting, the proposal used eighty-five percent support required, ten percent minimum quorum, a five-day vote duration, a three-day delegated voting period, a three-day quiet ending period, a two-day quiet ending extension, and a half-day execution delay. The quorum was partly justified as preventing a single large holder from reaching quorum alone. The shorter vote duration was intended to allow faster execution, while quiet ending and delegated voting protections still gave the community time to respond to contentious delegate outcomes.
For Conviction Voting, the proposal used a seven-day conviction growth period, four percent minimum conviction, and eleven percent spending limit. The design aimed to allow meaningful funding requests while making very large proposals difficult enough that they would need broad support or should be broken into smaller milestones. The thread modeled what proposal sizes could pass under different levels of active voting power, framing the outcome as “fast possible, but not too fast.”
By the end of the thread, Goldilocks had been framed as a rounded, middle-path runoff proposal. It tried to combine a psychologically simple opening price, substantial Common Pool funding, manageable reserve ratio, high but temporary entry tribute, active governance practice, moderate TAO Voting speed, and Conviction Voting constraints that could fund serious work without letting money move too easily.
2021-12-29 — Mathmematics V4: Back to the Square Roots
Forum thread: Commons Upgrade Parameter Runoff - Mathmematics V4 back to the (square) roots, but still with 1 MEMILLION COMMON POOL #138 Category: Conviction Voting / Archive Archive theme: Commons Upgrade runoff, Mathmematics V4, Common Pool funding, numerological parameter design, reserve ratio, TAO Voting, Conviction Voting
December 29, 2021
This Conviction Voting thread presented the Mathmematics V4 runoff proposal for the Commons Upgrade parameters. The proposal leaned into a playful numerological theme built around the numbers seven and thirteen, while still targeting a serious configuration goal: launching with roughly one million wxDAI in the Common Pool. It described the final revision as returning to an earlier spending-limit approach while using seven-day conviction growth and six percent minimum conviction as counterbalances.
The Token Freeze and Token Thaw settings proposed a twenty-six-week freeze, seventy-seven-week thaw, and 0.70 wxDAI opening price. The post translated the numerological framing into practical terms as a six-month freeze and roughly one-and-a-half-year thaw. The release schedule showed no tokens liquid at three or six months, 16.88 percent released at nine months, 33.77 percent at one year, 67.53 percent at one and a half years, and full release at two years.
The Augmented Bonding Curve settings proposed an eighty-four percent Commons Tribute, 3.5 percent Entry Tribute, 3.5 percent Exit Tribute, and an output reserve ratio of 14.74 percent. The proposal argued that this combination could preserve a one-million-plus Common Pool while keeping total round-trip tribute low compared with more aggressive entry-tax proposals. The allocation table showed about 1,059,427.80 wxDAI in the Common Pool before the initial buy and 1,068,177.80 wxDAI afterward, with the Reserve increasing from about 201,795.77 to 443,045.77 wxDAI after the initial buy.
The ABC modeling highlighted a 0.70 wxDAI opening price, an expected 1.37 wxDAI price after the initial buy, and comparatively high slippage on the initial buy because of the lower reserve. The thread included example transaction data and a reserve-to-price overview to illustrate how the bonding curve would respond to different reserve levels and transaction sizes.
For TAO Voting, the proposal used ninety-one percent support required, seven percent minimum quorum, seven-day vote duration, four-day delegated voting period, three-day quiet ending period, three-day quiet ending extension, and one-day execution delay. The timeline showed that proposals could take eight days with no extensions, eleven days with one extension, or fourteen days with two extensions.
For Conviction Voting, the proposal used a seven-day conviction growth period, six percent minimum conviction, and twenty percent spending limit. The strategy described this as a balance between allowing larger funding capacity and requiring enough conviction to avoid easy passage. The funding examples showed that smaller requests could pass, while larger requests still required substantial token support.
By the end of the thread, Mathmematics V4 had been framed as a high-Common-Pool runoff option with a playful but internally consistent parameter logic. It prioritized immediate Commons funding, a long thaw, modest entry and exit tributes, lower reserve backing than some alternatives, high TAO Voting consensus, and a Conviction Voting configuration that permitted ambitious spending while raising the minimum support needed to pass proposals.
2022-01-04 — Ways to Keep the Working Group Funding Flows Transparent
Forum thread: Ways to Keep the WG Funding Flows Transparent Category: Advice Process / Archive Archive theme: working group funding, transparency, mutual monitoring, accountability, multisigs, sub-DAOs, Dune Analytics, budget sheets, contributor privacy
January 4, 2022
This Advice Process thread proposed practices for keeping working group funding flows transparent after the Commons Upgrade. It opened from the premise that TEC’s commitment to transparency required not only visible governance decisions, but also visible financial flows once working groups began requesting funds from the Common Pool to compensate contributors.
The first suggestion was that each working group use a multisig or sub-DAO to receive and manage funds. This would make working group addresses easier to monitor and add to Dune Analytics, giving the community a clearer view of how funding proposals turned into actual payments. At the same time, the thread explicitly noted the privacy tradeoff created by traceable blockchain payments and encouraged contributors to use payment addresses separate from their Hatch addresses when receiving compensation.
The second suggestion was that contributors comment under working group funding proposal posts when making compensation or bounty requests. These comments could include both the requested amount and the tasks completed, creating a lightweight public record of what was being paid for. This was framed as a mutual-monitoring practice rather than only an accounting practice, because it gave the broader community more visibility into contributor work.
The third suggestion was that working groups maintain accessible or viewable budget sheets. These sheets would help working groups organize their own funding data while also making that data ready for transparency analysis when needed. The post presented these methods as recommendations rather than requirements and invited other ideas for keeping TEC transparent.
A short follow-up added praise for contributors involved in the post. By the end of the thread, the Transparency Working Group had outlined a practical funding-transparency pattern for the post-Upgrade Commons: monitored group wallets, visible compensation requests, public budget sheets, and privacy-aware payment practices for individual contributors.
2022-01-04 to 2022-01-07 — TEC Community Covenant Proposal
Forum thread: TEC Community Covenant Proposal Category: Conviction Voting / Archive Archive theme: Community Covenant, social contract, mission and values, code of conduct, polycentric governance, Celeste, Gravity, graduated sanctions, transparency
January 4, 2022
This Conviction Voting thread proposed the TEC Community Covenant as a formal social contract for the Commons. The proposal described the Covenant as a manifesto containing the TEC’s mission, vision, values, code of conduct, governance framework, and enforcement methods. It was intended to live on-chain and to be signed by participants who interacted with the Commons. The proposal was framed as a signaling proposal that, if approved, would also be submitted to the Hatch DAO.
The Covenant defined TEC as a self-governed organization advancing the field of token engineering by supporting ethical, safe, resilient, and diverse economic systems. It described the TEC’s mission as becoming a Schelling Point for token engineering through both economic and social layers. The economic layer would fund work that discovers, develops, and spreads best practices for safe tokenized economies, while the social layer would unite the field around ethical principles, standards, tools, and methodologies.
The proposed cultural framework drew on Ostrom’s principles for governing commons and emphasized a prosocial perspective over short-term gain. The values named in the proposal included integrity, curiosity, constructive inquiry, consistency, presence, gratitude, radical openness, non-hierarchy, transparency of intentions, and accountability for actions. The Covenant framed culture as inseparable from TEC’s ability to grow: people joining the Commons were also joining a set of norms and expectations.
The pledge section committed the community to a harassment-free, open, welcoming, diverse, inclusive, and healthy environment. It described positive behaviors such as empathy, respect for differing viewpoints, constructive feedback, accountability for mistakes, and focus on the overall community. It also named unacceptable behaviors including harassment, doxing, sexualized attention or language, trolling, derogatory comments, personal or political attacks, and other inappropriate professional conduct.
The governance and enforcement sections connected the Covenant to TEC’s polycentric governance framework. On-chain enforcement would depend on Celeste and would be used inside Conviction Voting and TAO Voting through proposal and challenge deposits. Proposal creators would attest that their proposal aligned with the social contract, challengers could dispute that attestation, and Celeste keepers would judge disputes using the Covenant, evidence, and past decisions.
The cultural enforcement section assigned Gravity the role of handling actions that contradicted TEC’s mission, values, and pledge. It described Gravity as a trust creation and conflict-management group using graduated sanctions, mediation, communication support, boundary recognition, and community resilience practices. Transparency was also named as a core cultural mechanism, with calls, audits, credentials management, and admin conduct all treated as part of maintaining trust and accountability.
January 5 to January 6, 2022
A follow-up question asked what activities counted as “interacting with the Commons” and therefore required signing or complying with the Covenant. The answer clarified that on-chain signature would happen when someone connected to the Garden for Conviction Voting and TAO Voting, and that the Covenant would also appear in the Discord welcome message. It was described as the main boundary for becoming a contributor: as long as someone was respectful and mission-aligned, they were welcome in. Becoming a steward would follow a separate process, while post-Hatch praise eligibility and praise powers would be broadly available to community members under the Covenant’s expectations.
January 7, 2022
The final update reported that the Snapshot proposal had been approved. By the end of the thread, the TEC Community Covenant had moved from a cultural document into a governance artifact: a mission statement, code of conduct, enforcement framework, and onboarding boundary that connected TEC’s values to on-chain proposal processes, Gravity, Celeste, graduated sanctions, and community transparency.
2022-01-05 — Transparency WG Funding Proposal
Forum thread: Transparency WG Funding Proposal Category: Advice Process / Archive Archive theme: Transparency Working Group, funding proposal, Common Pool funding, mutual monitoring, accountability, information access, advice process
January 5, 2022
This Advice Process thread submitted a three-month funding proposal for the Transparency Working Group. The proposal stated that any unused portion of the budget would be carried forward into the next proposal, reducing the amount requested later, and that the requested budget would be divided among working group contributors.
The funding request was framed as support for the community’s transparency infrastructure after the Commons Upgrade. The working group’s role was to help uphold transparency, monitor community activities, and make actions and decisions more visible. The proposal connected this work to mutual accountability: when community members have equal access to information and can understand behavior through a shared framework, trust can be produced internally rather than requiring external enforcement.
The proposal requested 16,956 xDAI through Conviction Voting and included a task-and-budget breakdown in an attached image. For progress sharing, it pointed back to the earlier advice-process discussion about ways to keep working group funding flows transparent, signaling that the group intended to use community-suggested reporting practices rather than define its reporting process in isolation.
By the end of the thread, the Transparency Working Group had turned its post-Upgrade transparency principles into a concrete funding request. The proposal linked compensation, monitoring, information access, and the advice process into one operational package for maintaining trust in the Commons.
2022-01-07 to 2022-01-09 — Commons Upgrade Runoff Vote
Forum thread: Commons Upgrade Runoff Vote Category: Conviction Voting / Archive Archive theme: Commons Upgrade, runoff vote, Quadratic Ranked Choice Voting, Commons Config Dashboard, voter pamphlet, debates, Hatch DAO implementation
January 7, 2022
This Conviction Voting thread formally opened the Commons Upgrade runoff vote. It presented the top five parameter proposals chosen during the Tokenlog curation phase and explained that these proposals represented the community’s favorite economic designs for the TEC. The runoff would use Quadratic Ranked Choice Voting to select the final parameter set for upgrading TEC into a fully functioning Commons with Conviction Voting, TAO Voting, and the Augmented Bonding Curve.
The thread identified the five finalist configurations: Goldilocks, Mathmematics, Bolshevik’s Gambit, Ostrom’s Baby, and 4.20. It framed the vote as the next step in the collaborative design of the TEC economy, with the winning proposal to be submitted to the Hatch DAO for final implementation after the vote.
The post also gathered supporting materials and deliberation infrastructure. It linked to a voter pamphlet, listed multiple scheduled debate sessions, and described the Commons Config Dashboard and Collaborative Economics process as public goods for the token engineering field. The goal was not only to choose a parameter set, but to demonstrate a participatory process for designing a complex tokenized commons.
A follow-up comment encouraged the community to vote and shared the Snapshot link. Another question asked for an overview of the entire Commons Upgrade process and timeline, not just the runoff vote, and a later reply pointed back to the broader final-parameters thread where the process timeline had been shared.
By the end of the thread, the runoff vote had become the formal decision point for months of parameter work, dashboard modeling, proposal writing, voter education, and debate. It connected the finalist configurations, voter pamphlet, Snapshot vote, and Hatch DAO implementation path into one final governance step before the Commons Upgrade.
2022-01-07 to 2022-01-11 — Vote to Select the Start Date of the Vesting Period
Forum thread: Vote to select the start date of the vesting period Category: Conviction Voting / Archive Archive theme: Commons Upgrade implementation, vesting start date, Token Freeze, Hatchers, Snapshot, Quadratic Ranked Choice Voting, launch timing
January 7, 2022
This Conviction Voting thread opened a Snapshot vote to decide when the Hatcher vesting period should begin. The post explained that the Commons deployment would take several days after the final parameters were chosen, which created ambiguity about which event should anchor the start of the Token Freeze and later vesting schedule.
The vote presented four possible start dates. The freeze could begin at the Hatch DAO vote on January 13, when Conviction Voting opened around January 19 or 20, when the Augmented Bonding Curve opened around January 24 to 28, or at a time chosen by the implementation team. The vote was scheduled to run from January 7 to January 13 alongside the Commons Upgrade runoff and was to use Quadratic Ranked Choice Voting.
The purpose of the proposal was to avoid confusion around launch dates and give the community a direct role in deciding when the selected proposal’s vesting period would start. The thread treated timing as a governance decision because the chosen date would affect how Hatchers understood the freeze, thaw, and liquidity schedule of their tokens.
January 11, 2022
A follow-up request asked for a quick link to the call recording where the issue had been discussed, noting that more explanation of each option’s implications would help people make a better decision. A reply provided a video link.
By the end of the thread, TEC had converted a deployment-timing ambiguity into a community vote. The discussion showed that even after selecting economic parameters, implementation details like the vesting start date still needed shared understanding, voter education, and an explicit governance decision.
2022-01-08 to 2022-01-10 — Adjusting the ABC for Ragequitting Unknowns
Forum thread: How should we adjust the ABC to deal with the unknowns presented by Ragequitting? Category: Conviction Voting / Archive Archive theme: Commons Upgrade implementation, Ragequit, Augmented Bonding Curve, opening price, reserve ratio, initial buy, Commons Tribute, Snapshot
January 8, 2022
This Conviction Voting thread addressed a practical implementation problem created by Ragequitting during the transition from the Hatch DAO to the Commons Upgrade. The parameter proposals had assumed that 60,000 wxDAI and 79,497.26 TECH would be ragequit from the Hatch DAO, but the actual amount would not be known until six days after the final parameter set was chosen. At the time of the post, 35,794.758 wxDAI had already been ragequit and 47,426.42 TECH had been burned.
The thread explained that this uncertainty would primarily affect the Augmented Bonding Curve configuration. If the final amount of wxDAI and TECH remaining in the Hatch DAO differed from the modeling assumptions, the opening price, reserve ratio, initial buy, Commons Tribute, and reserve values could all shift away from what voters thought they were choosing. A recent test deployment had held several values constant and produced an opening price ten percent higher than expected, which the post said was not the intended launch approach.
Four adjustment strategies were offered for community feedback. The first option was to keep the reserve ratio constant, preserving the shape of the bonding curve while adjusting opening price, initial buy, and Commons Tribute. The second option was to keep the opening price constant, preserving the launch market cap and the amount of TEC created by the initial buy for the Reward Board and Laser Tag multisig while allowing reserve ratio, initial buy, and Commons Tribute to shift.
The third option was to keep the initial buy and Commons Tribute constant, preserving the relationship between the ABC reserve and Conviction Voting Common Pool while allowing opening price and reserve ratio to change. The fourth option was to let the developers vary all of the relevant parameters in order to stay as close as possible to the spirit of the winning proposal, rather than mechanically preserving one specific parameter.
A Snapshot vote was posted to choose among these approaches. A follow-up question asked for clarification about what the 60,000 figure represented, and the thread was edited to make the assumption clearer. Another response favored trusting the developers to choose the best route, while appreciating the educational value of showing the tradeoffs publicly.
By the end of the thread, TEC had surfaced a key post-vote implementation issue: even after a community selects a parameter set, real Hatch DAO exit behavior can change the ABC launch conditions. The discussion converted that uncertainty into an explicit governance choice about which design target should be preserved: reserve ratio, opening price, initial buy and Commons Tribute, or the broader spirit of the winning proposal.
2022-01-10 to 2022-03-23 — Dogfooding the Proposal Inverter
Forum thread: Dogfooding the Proposal Inverter - TEC as a payer(funder/sponsor) Category: Conviction Voting / Archive Archive theme: Proposal Inverter, dogfooding, TEC Labs, PrimeDAO, Longtail Financial, BlockScience, multi-DAO funding, payers, brokers, public goods
January 10, 2022
This Conviction Voting thread introduced a plan for TEC to dogfood the Proposal Inverter as a payer, funder, or sponsor. The post explained that the Proposal Inverter had been developed through a joint effort involving BlockScience, Longtail Financial, TEC, and PrimeDAO. TEC Labs had hosted a development series that later became a PrimeDAO workshop series, with contributors from several organizations helping shape the specification, modeling, development, and public communication around the tool.
The post framed dogfooding as a natural next step: if the Proposal Inverter was good enough for its creators to use, then its first real users should be the organizations building it. The Proposal Inverter’s core purpose was described as inverting the DAO-proposal relationship. Rather than one DAO managing many proposals, many DAOs could fund a single proposal that produced a public good useful across the ecosystem.
The thread explained the tool’s actor model. Owners create Proposal Inverter instances, identify the public good to be built, and manage parameters such as broker lists and governance mechanisms. Payers provide funding. Brokers are the workers who produce or deliver the public good and receive periodic compensation. The initial dogfood sketch named PrimeDAO as owner, potential payers including PrimeDAO, TEC, Gitcoin, and others, and roughly ten brokers drawn from Longtail Financial, PrimeDAO, and Trusted Seed.
The example model proposed one-month epochs, 2,000 DAI allocations per broker per epoch, ten brokers, and a two-month minimum horizon. This implied a minimum of 40,000 DAI in funding, with a rough illustration of 15,000 DAI each from TEC, PrimeDAO, and Gitcoin, leaving 5,000 DAI as buffer or future funding. The post invited feedback, recommendations, and possible contributors who wanted to become brokers or payers.
January 10 to January 21, 2022
The early discussion focused on scope, roles, and legal architecture. Questions were raised about whether the ten brokers would be regular contributors across all organizations or open slots selected through some curation process. The thread also asked what legal entity brokers would invoice, what deliverables should be expected, and whether the model looked more like a wide bounty than a contract for services.
Additional comments supported the concept of cross-DAO funding, but questioned the role labels. Terms like owner, payer, and broker were seen as potentially intimidating or unclear. Another response connected the Proposal Inverter to TE Academy’s experience coordinating multi-DAO funding for education programs, noting that the model was valuable but that communications, timelines, and transaction settlement created heavy overhead. The Proposal Inverter was presented as a way to reduce that overhead and make collaborative public-goods funding easier.
The thread also emphasized the token engineering value of the tool. Beyond smart contracts, frontends, and documentation, the Proposal Inverter included an open-source model for running simulations and finding parameter settings. This was framed as a possible standard for DAO tooling: a component should include both the code and a way to model the conditions under which it works well.
March 16 to March 23, 2022
After a Stewards call, the thread returned to TEC’s specific role as a payer in the Proposal Inverter proposal. The discussion identified two core questions: how much TEC should contribute, and what value the Proposal Inverter would create for TEC and token engineering. The latest iteration of the proposal was described as asking for a one-time 45,000 DAI contribution from TEC.
A later response supported the project but argued that 45,000 DAI was too high relative to TEC’s treasury. With about 803,000 wxDAI in the budget, 45,000 DAI represented more than 5.5 percent of available funds. The response suggested that larger treasuries such as Gitcoin, Radicle, and PrimeDAO could contribute more, while TEC might support the project at around 2.5 percent of its treasury, roughly 20,000 DAI.
By the end of the thread, the Proposal Inverter dogfood proposal had clarified both the promise and the governance tradeoff of cross-DAO funding. TEC valued the tool as infrastructure for collaborative public-goods funding and as a practical token engineering artifact, but still needed to decide how much financial responsibility it should take relative to larger partner organizations.
2022-01-13 to 2022-01-20 — The Commons Upgrade Is Live
Forum thread: The Commons Upgrade is LIVE! Category: The Hatch / Archive Archive theme: Commons Upgrade launch, TEC Gardens, Hatch DAO vote, TECH to TEC migration, Common Pool, reserve agent, bonding curve opening
January 13, 2022
This Hatch thread announced that the Commons Upgrade had been set in motion through deployment of the new TEC Gardens. The post directed the community to the new TEC Garden and announced that the next required vote was live in the Hatch DAO, asking TECH holders to vote in support of the migration step.
The vote would move Hatch funds into the new system. The plan set aside 250,000 wxDAI for the initial buy, sent sixty-nine percent of the resulting funds to the Common Pool, and placed the remainder in the reserve agent until the bonding curve opened. The new TEC token would be minted one-to-one for TECH holders, with the initial minting price set near one wxDAI per TEC. The post also reminded the community that a separate vote would still be needed the following week to launch the Augmented Bonding Curve itself.
January 14, 2022
A follow-up question asked where TECH holders could claim their TEC from the conversion. The answer clarified that holders would not need to claim manually because TEC would be sent to them. Another follow-up noticed an implementation issue: although wxDAI would be available in the Common Pool and Hatchers would have tokens to vote, proposers would still need liquid TEC to pay Proposal Deposits. That meant proposal creation would effectively have to wait until the bonding curve opened and liquid TEC could be acquired.
January 20, 2022
A final update reported that the Hatch DAO vote had passed, Hatch funds were now stored in the new TEC Gardens, and TEC had been minted to all TECH token holders at a one-to-one ratio. The update also pointed to the second vote needed to complete the Commons Upgrade by opening the bonding curve.
By the end of the thread, the Commons Upgrade had moved from design and voting into launch execution. The thread recorded the deployment of the TEC Gardens, the movement of Hatch funds, the TECH-to-TEC migration, the Common Pool and reserve split, the discovery of a proposal-deposit timing issue, and the handoff to the bonding curve opening vote.
2022-01-14 — How to Get Access to TEC Platforms
Forum thread: How to get access to TEC platforms (access management) Category: Advice Process / Archive Archive theme: access management, credentials, Credential Curators, Stewards, platform permissions, operational security, transparency
January 14, 2022
This Advice Process thread documented the process for requesting access to TEC platforms. Contributors seeking access were instructed to contact the Credential Curators or fill out a form identifying their handle, the platform they needed to access, and the task they needed to perform. This information would help determine what level of access was appropriate.
The process then moved through a Steward poll. If all responses were affirmative within twenty-four hours, access would be granted. If the vote was less than unanimous but above eighty percent, the process allowed another twelve hours for any dissenting voters to explain their concerns publicly or privately. If nobody spoke up, access would be granted after that waiting period. If someone did provide a reason, the Credential Curator would rerun the poll for another twenty-four hours with the reason included, while preserving anonymity if requested.
The second poll required at least eighty percent approval. If the initial approval level was below eighty percent, the person would not receive access at that time. To make the vote easier to evaluate, the Credential Curator would include the requester, recommender, platform, and reason for the access request in the poll.
By the end of the thread, TEC had turned platform access into a lightweight but explicit governance process. The design balanced fast access for contributors, Steward oversight, privacy for dissenting concerns, and a clear threshold for granting permissions to shared community infrastructure.
2022-01-18 to 2022-01-24 — TEC Working Groups Weekly Updates
Forum thread: TEC WGs Weekly Updates Category: Community Updates Archive theme: working group updates, Commons Upgrade launch, Goldilocks parameters, ABC opening, Gravity, Communitas, Labs, T.E.A.M., Transparency, Legal, Rewards
January 18, 2022
This community update restarted the working group weekly update cadence for the new year and encouraged community members to follow the thread for ongoing updates. It framed the updates as a way to keep people informed about what was happening across TEC’s many calls, working groups, calendars, and public archives.
The first update centered on the Commons Upgrade. Stewards noted that the community was now collectively working from the Goldilocks-winning parameters, continued sprint planning and retrospectives, and kept their three-month funding proposal open for feedback. Commons Swarm reported that the Gardens had been deployed and the Hatch DAO Commons Upgrade vote was live, with the vote designed to set aside funds for the initial buy, migrate remaining wxDAI into the conviction voting pool and bonding curve app, and mint TEC one-to-one for TECH holders. The update laid out a launch sequence: TEC minting for Hatchers, an ABC opening vote, the start of the Token Freeze period, the opening of the ABC, and a two-day delay for ragequit withdrawals.
Soft Gov reported that eighty-two people had voted in the Commons Upgrade runoff, that the Community Covenant was live on IPFS as part of the migration, that the vesting start-date vote had closed in favor of starting when the ABC opened, and that the ragequit-adjustment vote had closed with consensus to let developers use discretion to preserve the spirit of the winning proposal.
Other working groups reported operational progress. Gravity promoted its funding proposal, contributor intake form, Dework tasks, NVC book club, Gitcoin grant, support request form, survey, and step-by-step process. Communitas reminded the community of its weekly sync, orientation call, and TEC Lounge, noted that the Discord had reached 1,500 members, and reported outreach to the eighty-two voters. Labs highlighted TE Academy programming, Proposal Inverter dogfooding, DAO-to-DAO workshops, open office hours, and a Solidity study group.
The communications and outreach group reported that the Commons Upgrade had launched and that the group would henceforth be known as Token Engineering Amplify Messengers. It listed teams for TE Academy, Twitter, animation and video production, translations, and HubSpot, and noted that Dework was ready to reward contributors. Transparency reported its biweekly syncs, funding proposal, and access-management work. Legal reported work on Conviction Voting proposal terms and ABC terms. Params celebrated the end of its parameter-selection work and pointed to the Commons Configuration Dashboard and voter pamphlet. Rewards reported that the new Praise dashboard was almost ready and reminded contributors of the rewards system process.
January 24, 2022
The next update continued the post-Upgrade launch narrative. Stewards closed Sprint 25 and reported work with Dework, DAOist delegation, and PrimeDAO collaboration around the Proposal Inverter. Commons Swarm repeated the launch timeline and emphasized that the TEC Gardens had been deployed, TEC tokens would be minted to Hatchers while frozen, and the ABC would open soon.
Soft Gov reflected on lessons from the Commons Upgrade. The community had not chosen the most money-oriented proposal, which was interpreted as evidence of value alignment. The update also identified learning points: future parameter processes should explain each module more clearly, ranked choice needed deeper understanding, and the Commons Configuration Dashboard still involved a steep learning curve for nontechnical participants.
Communitas continued guide onboarding and community support. Labs reported a TEA x TEC presentation with strong attendance, future Discord bot work, the ongoing Solidity study group, Proposal Inverter dogfooding, DAO-to-DAO workshops, and open office hours. T.E.A.M. reported onboarding work, Twitter operations, video-production planning for a rewards quantification tutorial, translation review, and email-list maintenance. Transparency reported a Soft Gov decision tracking list, analytics for YouTube and Medium, and the access-management map. Legal continued terms work. Params pointed people toward the real Commons parameters and the dashboard import function. Rewards reported that more than twenty people had registered to quantify Praise and that the updated Praise dashboard was close to ready.
By the end of the thread, working group updates had shifted from pre-Upgrade preparation to post-Upgrade execution. The updates captured the launch of TEC Gardens, the Goldilocks parameter result, ABC opening preparations, role and funding proposals, communications restructuring, contributor onboarding, transparency infrastructure, legal terms, rewards tooling, and the community’s first lessons from completing a major collaborative economic design process.
2022-01-20 — Bonding Curve Opening
Forum thread: Bonding curve opening Category: Conviction Voting / Archive Archive theme: Commons Upgrade launch, Augmented Bonding Curve, initial buy, Goldilocks parameters, Ragequit adjustment, reserve ratio, Common Pool
January 20, 2022
This Conviction Voting thread documented the final operational adjustments needed to open the Augmented Bonding Curve. The post explained that once the bonding curve opened, anyone would be able to convert between TEC and wxDAI, while Hatch-minted TEC would remain locked from selling or transfer but retain full voting power.
The thread also described the planned initial buy. TEC had set aside 265,000 wxDAI to be converted into TEC and managed by the DAO immediately after the bonding curve opened. The initial opening price was expected to be roughly one wxDAI per TEC before ABC tributes, and the estimated price after the initial buy was approximately 1.41 wxDAI per TEC before tributes.
The adjustment was necessary because the Hatch migration had used Goldilocks parameters that assumed 60,000 wxDAI would ragequit, but the actual ragequit amount was lower. To preserve similar outcomes, the proposal called for increasing the initial buy from 250,000 to 265,000 wxDAI, granting TAO Voting permission to transfer tokens from the Common Pool, transferring 15,000 wxDAI to the agent set aside for the buy, sending 3,435.49 wxDAI from the reserve to the Common Pool, and slightly changing the reserve ratio from 19.98 percent to 19.82 percent.
By the end of the thread, the bonding curve opening had become a concrete launch-action proposal. It translated the earlier abstract ragequit-adjustment discussion into specific permissions, transfers, and parameter changes needed to open the ABC while keeping the launch close to the voter-approved Goldilocks configuration.
2022-02-04 to 2022-03-17 — Gitcoin Donations: What Should We Do With Them?
Forum thread: Gitcoin Donations - What should we do with them? Category: Advice Process / Archive Archive theme: Gitcoin donations, treasury allocation, LASERTAG, Common Pool, Reward Board, Snapshot, ETH Barcelona, public goods funding
February 4, 2022
This advice process thread opened around a small but symbolically important treasury question: TEC had Gitcoin grant donations sitting in a wallet controlled by one person, worth over 13,000 dollars at the time, and the community needed to decide what to do with them. The post framed the funds as belonging to TEC’s public mission rather than as idle assets that should remain in an individual-controlled key.
Several options were listed. The donations could be converted to wxDai and sent to LASERTAG for future liquidity provision; partially converted while leaving some assets such as PAN and ETH untouched; converted to wxDai and sent to the Common Pool; converted into TEC and sent to the Reward Board; left untouched; or jokingly misused for an extravagant conference party. The post suggested using ranked-choice voting on Snapshot to choose among the options, mixing a serious treasury process with a deliberately playful option to make the vote more engaging.
A reply suggested using the funds to bring people to ETH Barcelona, adding an event-focused community-building option. The original post then jokingly extended the joke option into an “embezzle and party in Barcelona” framing, keeping the tone light while continuing to surface a real allocation question.
March 17, 2022
A later follow-up asked that the joke option be updated to match the Snapshot description and expressed interest in the idea of bringing a crew to ETH Barcelona to hack together in person. The request asked for more concrete detail about what that option would look like.
By the end of the thread, the Gitcoin donations had become a small treasury-governance exercise. The discussion connected grant proceeds, individual key custody, LASERTAG liquidity, Common Pool funding, Reward Board support, Snapshot ranked-choice voting, and the possibility of using public-goods donations for in-person ecosystem coordination.
2022-01-20 to 2022-03-30 — Hatch Bot NFT in Metal
Forum thread: Hatch Bot NFT in Metal Category: Conviction Voting / Archive Archive theme: Hatch Bot NFT, physical NFTs, retroactive funding, Hatcher gratitude, metal prints, Conviction Voting, artist compensation
January 20, 2022
This Conviction Voting proposal asked the TEC to bring the Hatch Bot NFT into the physical world by printing it on aluminum and shipping it to NFT holders. The proposal had two main purposes: provide a physical token of gratitude to top Hatch contributors, and retroactively compensate the organizations and people who had made the Hatch Bot NFT and supporting dApp possible.
The post described a metal print of the NFT image, about sixteen by twenty-two point eight inches, and noted that a test print had already been made and looked strong. The requested amount was 5,500 wxDAI. The budget included 1,000 dollars for the original artist, 1,000 dollars for Blossom Labs for website coordination and data infrastructure, 1,000 dollars for General Magic for gas fees, website design, and layout, and 2,500 dollars for producing and shipping the metal prints. Any unspent physical-printing funds from recipients who did not want the item would go to the original artist.
The thread framed the proposal as both gratitude and retroactive accounting. It recognized the Hatch Bot NFT as a collaborative product of artists, builders, and support organizations, and it used Conviction Voting to close the loop by compensating contributors while offering the NFT holders a physical artifact of the Hatch.
January 20 to February 9, 2022
Early replies supported the proposal enthusiastically, praising both the artwork and the idea of crypto memorabilia connected to the Hatch. The proposal link was shared once it went live in the Garden. Later, the author announced that the proposal had passed and that the team would begin asking NFT owners where they wanted to receive their physical metal versions. A reply celebrated the successful passage as an example of Conviction Voting working in practice.
March 30, 2022
A final update reported that all physical NFTs had been shipped to holders who provided addresses. Two Hatchers preferred not to receive the NFT, and one could not be reached, though the post said they could still receive the piece if they later responded. The final spending breakdown showed 1,400 dollars for seven pieces and shipping, 1,000 dollars each to Blossom Labs, General Magic, and Funnyverse, an 800 dollar bonus to the artist, and 300 dollars for management tasks such as writing the proposal, collecting addresses, and making payments.
By the end of the thread, the Hatch Bot NFT had moved from a digital Hatcher artifact into a shipped physical object. The proposal captured TEC’s use of Conviction Voting for retroactive funding, contributor recognition, public gratitude, physical memorabilia, and post-Hatch cultural memory.
2022-01-23 to 2022-03-25 — Quantifier Onboarding
Forum thread: Quantifier Onboarding Category: Advice Process / Archive Archive theme: Rewards system, Praise, quantifiers, onboarding, Reward System Dashboard, SourceCred, duplicate praise, invalid praise, quantification periods
January 23, 2022
This advice process thread documented the onboarding process for TEC Praise quantifiers. The post defined the quantifier role as performing regular manual quantification of anonymized praise data generated by the community, following the process designed by the Rewards Working Group. Quantifiers would be placed in a pool, and for each quantification period a proportional number of people would be randomly selected based on the amount of Praise to evaluate.
The onboarding plan required people to attend a mandatory training meeting, initially every two weeks and later monthly once the quantifier pool stabilized. The post also anticipated a future explainer video and a Quantifier Support channel where people could ask questions. Responsibilities included reading the Rules of Praise and Quantification, quantifying assigned Praise, marking duplicate Praise, marking invalid Praise, and attending the final review call.
The thread defined a biweekly quantification rhythm. Quantifiers would have five days to complete assigned Praise asynchronously, followed by a final review call and submission to the Reward Board. The Reward Board would then approve or reject the quant, with rejected distributions resolved through a follow-up sync. This created a timeline intended to keep TEC rewards punctual while still leaving room for review and correction.
The post then became a detailed how-to guide for using the Reward System Dashboard. Quantifiers would log in with a Web3 wallet, navigate to the active quantification period, review Praise grouped by receiver, and score contributions using a sliding Fibonacci sequence. They were instructed to use forum search, the TEC Handbook, and direct questions to Praise givers when they needed context. Duplicate Praise would receive a small percentage-based modifier, while invalid Praise included objective actions better handled by SourceCred or Praise that violated the code of conduct.
The guide also clarified duplicate, dismissal, and quantification rules. General forum or GitHub actions expected to be captured by SourceCred could be dismissed, but the content or impact of those actions could still be quantified. A same-giver, same-week verbatim repeat could be dismissed; the same contribution praised by different people in the same week could be marked as duplicate; and the same contribution praised in different weeks could still be quantified. Meeting attendance was treated carefully because attendance automation was not yet retroactive: generic attendance Praise could be given a lower score, while more meaningful meeting contributions should receive more value.
March 25, 2022
A later clarification asked whether duplicate Praise included contributions praised by different people and restated the emerging rule set. The response confirmed the nuance: if someone is praised for doing similar work in different weeks, that should not automatically count as a duplicate because repeated work across weeks can represent repeated value creation.
By the end of the thread, TEC had a full operating manual for Praise quantifiers. The discussion connected onboarding, random quantifier selection, scoring scales, review calls, Reward Board approval, duplicate modifiers, SourceCred boundaries, invalid Praise, meeting attendance, and contextual research into one repeatable workflow for turning community recognition into reward distributions.
2022-01-25 to 2022-06-05 — Transparency WG Funding Proposal on Conviction Voting
Forum thread: Transparency WG Funding Proposal on CV Category: Conviction Voting / Archive Archive theme: Transparency WG, Conviction Voting, funding proposal, audit work, call recording, Dune dashboard, compensation requests, payout tracking
January 25, 2022
This Conviction Voting thread submitted the Transparency Working Group’s three-month funding proposal. The proposal requested 16,956 XDAI and stated that any unused portion would roll over into the next proposal, lowering the next request. The budget was intended to compensate Transparency contributors for work that supported the community’s ability to monitor activity, preserve access to information, and participate in governance using shared records.
The proposal framed transparency as a core part of TEC’s self-governance. By recording and preserving information, maintaining documentation, and making activity visible to all participants, the working group aimed to reduce reliance on external oversight and increase trust in the advice process. The budget was to be divided among contributors, with progress-sharing methods to be shaped by the broader discussion about how Transparency should present and preserve audit reports.
January 27 to February 16, 2022
Follow-up discussion strongly supported the proposal, emphasizing that TEC’s archive of working group meetings and public records had become a valuable community resource. One newcomer suggested improving proposal UX by adding direct voting links or embeddable vote buttons so people could support Conviction Voting proposals from the forum or other interfaces. After the proposal passed, the suggestion remained as feedback for Gardens and governance interface design.
By mid-February, the thread also recorded completion of a Dune dashboard for TEC analytics. The dashboard contributors agreed to split the associated payment evenly, and the thread later included transaction confirmations. This showed the Transparency budget being used not only for call recording and audit work but also for data infrastructure that could help the community monitor its own economy.
March 3 to April 7, 2022
The thread then became a monthly payment and accountability record for Transparency contributors. February requests covered recording Transparency and Legal calls, publishing and organizing YouTube content, coordinating Dune and audit work, managing multisig transparency documentation, updating decision tracking, maintaining community events, and designing or editing public-facing assets. The thread included transaction confirmations and repeatedly pointed back to the shared activity-tracking document.
March requests continued the same pattern. Contributors requested payment for thumbnails and video support, role-based Transparency stewardship, recording calls, uploading videos, audit report research and structure, Dune dashboard updates, and broader operational support. Transaction confirmations were posted after the payments, turning the thread into both a funding proposal and a living payout ledger.
May 2 to June 5, 2022
April and May requests continued to document Transparency’s expanding workload. Contributors requested compensation for structuring and finalizing the audit, producing visual audit layouts and data visualizations, designing Dune video thumbnails, recording and uploading calls, managing playlists, documenting credentials for future Commons, updating the decision tracking sheet, and supporting multisig payments and other operations.
By the end of May and early June, the thread also recorded new work around data standardization. Contributors described simplifying transaction categories, creating standardized spreadsheet tabs, building pivot tables and charts, creating metadata validation rules, and preparing the next Transparency funding proposal. Final transaction confirmations were posted on June 5, along with a reference to the tracking document for the period.
By the end of the thread, the Transparency funding proposal had evolved into an operational archive for how TEC paid and tracked transparency work. It linked Conviction Voting, audit production, video archives, Dune analytics, decision tracking, multisig documentation, data standardization, recurring contributor claims, and public transaction confirmations into one ongoing accountability record.
2022-02-07 — TEC Working Groups Weekly Update, Jan 27 to Feb 7
Forum thread: TEC WGs Weekly Update: Jan 27 - Feb 7 Category: Community Updates Archive theme: working group updates, Commons Upgrade aftermath, Gardens funding, ABC activity, decision-making system, Commons Swarm sunset, transparency analytics, rewards quantification
February 7, 2022
This community update summarized working group activity from January 27 to February 7, after the Commons Upgrade had gone live and TEC had entered its first post-launch operating cycle. Stewards reported the close of Sprint 26 and the start of Sprint 27. Several major funding proposals had moved through Gardens: Gravity and Communitas funding proposals were live, the TE Fundamentals / TE Academy proposal had passed and executed, and the Stewards three-month funding proposal had passed and executed. The Steward retrospective also surfaced a need for more work around narrative and brand storytelling.
Gravity reported that its six-month funding proposal was live, that contributor intake and Dework tasks were available, and that a three-month calendar of activities would soon be published. Commons Swarm announced that its mission was complete and that this would be its last update. It reported that the ABC had already raised more than 200,000 wxDAI, that the Garden had funded TE Academy, and that the Common Pool still held more than one million wxDAI. Before retiring, Commons Swarm still needed to fix the “Convert All” button and add user interface buttons for MetaMask and getting TEC.
Soft Gov shared a new visual diagram of TEC’s decision-making system. The diagram grouped decision processes across Advice Process, Snapshot, Tokenlog, TAO Voting, and Conviction Voting, showing how different types of decisions would move through expert advice, community signaling, proposal curation, DAO DNA changes, and funding allocation.
Communitas reported that its three-month funding proposal was live, that the community had reached 1,700 Discord members, and that an FAQ document was in progress. 0mega continued recruiting contributors for the Consilience Library and advanced funding proposals for ethics participatory research and library curation. Labs highlighted the TEA x TEC presentation, upcoming bot work, the Solidity study group, Proposal Inverter dogfooding, DAO-to-DAO workshops, and open office hours.
Communications reported that its Dework workspace was ready for bounties once funding passed, and that T.E.A.M. was operating through TE Academy, Twitter, animation and video production, translations, and HubSpot teams. Transparency reported that weekly syncs were back, that decision-tracking and analytics documents were underway, and that its Dune Analytics profile was now a highlighted resource. Legal continued work on terms and conditions for Conviction Voting proposals and ABC terms. Rewards reported that the second test quantification had suffered data-loss issues, that the group was investigating the root cause, and that SourceCred context and Praise quantification participation remained active priorities.
By the end of the thread, TEC’s working group updates had shifted from launch preparation to post-launch institutionalization. The Commons was live, funding proposals were executing in Gardens, Commons Swarm was winding down, Soft Gov was mapping the governance stack, and working groups were moving into recurring operations around funding, onboarding, analytics, legal terms, rewards, communications, and community growth.
2022-02-07 — TEC Meeting Protocols, Terms, and Disclaimers
Forum thread: PSA: TEC Meeting Protocols, Terms, and Disclaimers Category: Archive Archive theme: meeting protocols, recording consent, transparency, privacy, legal disclaimers, call norms, public communications
February 7, 2022
This archive post served as a public reminder that TEC calls could be recorded, live streamed, and published through official communication channels for transparency and social engagement. It presented the meeting protocols, terms, and disclaimers that applied to people attending TEC meetings or using the platforms where those meetings were hosted.
The post stated that by attending a TEC meeting, participants agreed to be recorded and to allow recorded material to be used according to the meeting protocol and general TEC terms of use. It also directed participants to follow the TEC call protocol.
The disclaimer section clarified several risks and expectations. Participants might not always receive a separate notification when recording was enabled, so anyone who did not consent could choose not to attend or could leave. TEC would try not to publish sensitive or confidential information, but participants were also expected to protect sensitive information when screen sharing. The post discouraged private recording of calls without Transparency Working Group consent and stated that personal opinions expressed in meetings did not represent TEC as an organization.
The post also addressed publication and platform risks. Published content should not be used for commercial purposes, and TEC disclaimed liability for cyberattacks or failures by platforms such as Discord, Zoom, YouTube, or Twitter. It also warned that once recordings were public, others might republish the content, and TEC might not be able to censor or recover it.
By the end of the post, TEC had documented a public transparency boundary for meetings: calls could be recorded and shared, but participants were responsible for consent awareness, screen-sharing privacy, and understanding that public recordings create persistent and partly uncontrollable public records.
2022-02-09 — How to Contribute to the TE Consilience Library
Forum thread: How to contribute to the TE Consilience Library - an open call for TE OGs! Category: Community Updates Archive theme: TE Consilience Library, 0mega, research curation, token engineering education, crypto-economic flower, seed curators, learning calendar
February 9, 2022
This community update opened a call for contributors to help seed the TE Consilience Library. The post described the library as an ambitious but accessible shared resource for learning about token engineering, grounded not only in technical material but also in first-principles thinking, ethics, philosophy, and the design of new socio-economic structures.
The project’s concept of “consilience” was framed as linking principles across different disciplines to form a more comprehensive theory. The library would organize token engineering learning across the areas of the crypto-economic systems flower, while also allowing contributors to define their own curation focus if they could explain the underlying principle or theory connecting their chosen resources.
The post gave seed curators a simple contribution process. First, they should choose a focus area or petal. Second, they should add resources such as academic papers, blog posts, book excerpts, videos, or their own work. The post encouraged curators to include an explanation for why each resource mattered and suggested keeping each seed curation to five to ten resources. Third, people leading relevant learning sessions were encouraged to add them to the library learning calendar. Finally, curators were asked to save their seed curation as one of the first contributions to the library.
The thread framed this as only the beginning. Once seed curations were ready, the plan was to open-source the library to the broader community, connect it with other learning and professional-practice programs, and work with like-minded DAOs and communities.
By the end of the post, the Consilience Library had been positioned as a token engineering knowledge commons: a curated, interdisciplinary, ethically grounded learning resource that would recognize both author and learner effort while helping organize the field’s emerging educational pathways.
2022-02-17 to 2022-03-10 — Create xDAI/TEC Secondary Market Liquidity: LASERTAG
Forum thread: Create xDAI/TEC Secondary Market Liquidity - LASERTAG Category: Conviction Voting / Archive Archive theme: LASERTAG, secondary market liquidity, TEC/xDAI, Honeyswap, DAO-owned liquidity, bonding curve, strategic partnerships, liquidity strategy
February 17, 2022
This Conviction Voting thread opened with concern that TEC’s secondary market liquidity was weak. The post estimated that there was only about 12,000 DAI of liquidity, mostly in the HNY/TEC pair, which was not enough for a healthy market. The proposal suggested using some of the TEC acquired through the initial buy and held by LASERTAG to create an xDAI/TEC liquidity pool on Honeyswap. A target of roughly 50,000 DAI of liquidity was presented as a reasonable base for DAO-owned secondary market liquidity.
Because LASERTAG did not have enough xDAI to create the LP directly, the proposal suggested selling some cheaply acquired TEC from the initial buy into xDAI, then pairing TEC and xDAI into the LP. The post estimated this would use a little over 20,000 TEC, about sixteen percent of the TEC held in LASERTAG. The required execution path was simple: sell TEC for xDAI, approve TEC spending, and create the TEC/xDAI LP.
The first response questioned whether TEC needed secondary market liquidity at all when the bonding curve already provided liquidity backed by wxDai. Rough simulations suggested that selling TEC for xDAI would move the price down by roughly two percent. The critique asked how acquiring more stablecoin liquidity would benefit the Commons and suggested exploring partnerships with aligned communities such as Gnosis, 1Hive, or Agave instead, potentially creating larger shared liquidity pools.
February 17 to February 23, 2022
The discussion then compared different liquidity strategies. Supporters argued that secondary market liquidity had been part of the original initial buy-in logic and that TEC should have a stake in secondary market activity, not only the bonding curve. Other possible pairings such as TEC/WETH, TEC/WBTC, or TEC/HNY were floated as alternatives to TEC/xDAI, with the general principle being that TEC should create a solid token pair while still preserving enough TEC for strategic partnerships.
Skeptical responses argued that liquidity alone would not solve the deeper issue of low trading volume and limited market awareness. If there was not much demand to trade TEC, adding liquidity might not create meaningful activity. Others suggested a DAO-to-DAO liquidity partnership, shared liquidity token model, or token swap with an aligned community before selling TEC for xDAI. The thread therefore moved from a narrow TEC/xDAI LP proposal into a broader debate about whether LASERTAG should prioritize direct liquidity, strategic partnerships, or partner-token liquidity routes.
The discussion also clarified terminology around “reserve.” One participant had referred to taking funds from the reserve to create liquidity, but later clarified that they meant LASERTAG funds, not the ABC reserve collateral. This distinction mattered because using ABC reserve funds would raise very different governance and economic questions than using the initial-buy allocation entrusted to LASERTAG.
March 9 to March 10, 2022
The thread closed by pointing the issue into a Stewards Council discussion about how to use LASERTAG funds. The agenda was opened to the wider community, with a time change announced shortly afterward. This showed that the question had grown beyond a single LP transaction and become part of the broader governance conversation about LASERTAG’s post-launch mandate.
By the end of the thread, the TEC/xDAI liquidity idea had not simply become an execution proposal. It had clarified the strategic tension around LASERTAG: whether to use its TEC for direct secondary-market liquidity, wait for DAO-to-DAO partnerships, pair TEC with aligned tokens, preserve funds for future strategy, or first build more demand for TEC before deepening liquidity.
2022-02-22 to 2022-03-08 — Token Swap TEC and GIV and Create LP
Forum thread: Token Swap TEC <> GIV and create LP Category: Conviction Voting / Archive Archive theme: TEC/GIV liquidity, Giveth partnership, LASERTAG, Honeyswap, secondary markets, token swap, DAO-owned liquidity, multisig custody
February 22, 2022
This Conviction Voting thread proposed using part of the LASERTAG multisig’s funds to create a TEC/GIV liquidity pool on Honeyswap. The proposal suggested swapping 20,000 DAI worth of TEC for 20,000 DAI worth of GIV, then pairing the received GIV with another 20,000 DAI worth of TEC to create a TEC/GIV LP position. The LP tokens would be held by LASERTAG, using about sixteen percent of the TEC then held in the multisig.
The rationale was both strategic and cultural. Giveth was described as a strong supporter of public goods and crypto-philanthropy, with significant contributor overlap and value alignment with TEC. The proposal also identified the operational steps needed if the community chose to proceed: send TEC tokens to the Giveth multisig, approve TEC/GIV spending, and create the LP position.
March 4 to March 8, 2022
A later update calculated the exact swap amounts using seven-day average prices for TEC and GIV. The revised numbers requested 43,762.69 GIV in exchange for 8,637.85 TEC, plus an additional 8,637.85 TEC from LASERTAG to pair with the GIV in a Honeyswap LP. This refined the proposal from a round-number concept into a concrete execution plan.
The discussion then focused on the purpose and custody of the LP position. Some support emerged for permanent TEC/GIV liquidity, but questions were raised about why LASERTAG should hold the funds instead of an Agent controlled directly by the DAO. The concern was that LASERTAG could become a long-term political force if it held strategically important liquidity, even if it was originally intended only as an execution multisig.
The liquidity rationale was also debated. One response asked whether there was enough demand for a GIV/TEC market, especially because a small pool could be prone to slippage and represented a meaningful allocation of LASERTAG assets. Supporters argued that pairing TEC with GIV could increase secondary market activity and route TEC into a broader liquidity network through Giveth’s larger Honeyswap markets, rather than relying only on the TEC bonding curve or TEC-to-xDai paths.
By the end of the thread, the TEC/GIV proposal had become both a liquidity strategy and a governance-custody debate. It connected public-goods alignment with Giveth, secondary-market access, DAO-owned liquidity, LASERTAG’s role, Agent-controlled funds, route quality, slippage, and the question of how much discretion an execution multisig should retain after the Commons launch.
2022-02-28 to 2022-03-10 — LASERTAG Liquidity
Forum thread: LASERTAG Liquidity Category: Archive Archive theme: LASERTAG, secondary market liquidity, DAO-to-DAO liquidity, WATER, TEC/GIV, TEC/xDAI, Gnosis, BrightID, shared liquidity
February 28, 2022
This archive thread opened as a synthesis of several active discussions about how LASERTAG should use the TEC it held for liquidity and strategic partnerships. Two existing options were identified: using TEC to buy xDAI and create a TEC/xDAI pool on Honeyswap, or swapping with Giveth and creating permanent TEC/GIV liquidity. The post then expanded the conversation to other aligned ecosystems, including Gnosis, 1Hive, BrightID, and the WATER shared liquidity proposal.
The WATER proposal was described as an untested but interesting ecosystem-level liquidity mechanism. Its potential benefit was shared liquidity across multiple values-aligned communities, including 1Hive, ShapeShift, BrightID, Giveth, Panvala, Raid Guild, Opolis, and Agave. The concern was both scale and custody: participation would require a large amount of TEC relative to LASERTAG’s holdings, and the proposal appeared to place shared liquidity under a multisig structure that the post did not fully trust.
The thread also noted that BrightID had expressed interest in a token swap to create permanent TEC/BRIGHT liquidity. Together with Giveth and Gnosis, these were presented as aligned communities where shared liquidity could produce win-win outcomes. The post asked who wanted to participate in weekly discussions to compare options and decide how LASERTAG should use its funds.
March 1 to March 10, 2022
A follow-up supported the general idea of an index-like token for projects adding value to Gnosis Chain, while also resisting the creation of endless multisigs for every LP venture. The response suggested a simpler custody structure: TEC could send liquidity into the WATER pool, mint its share of the token, and hold that token in the LASERTAG multisig. That would allow TEC to participate while retaining more direct control over its own investment and relying on social reputation rather than hard external multisig barriers.
The final reply reported that the WATER entry amount had been lowered to 100,000 dollars per community token, potentially making the option more attractive for TEC. By the end of the thread, LASERTAG liquidity had become a broader strategic design question rather than a single pool decision. TEC was weighing direct TEC/xDAI liquidity, TEC/GIV liquidity, BrightID or Gnosis partnerships, WATER-style shared liquidity, and the governance implications of who controls pooled assets.
2022-03-08 — TEC Working Groups Weekly Update, Feb 28 to Mar 7
Forum thread: TEC WGs Weekly Update: Feb 28 - Mar 7 Category: Community Updates Archive theme: working group updates, Gardens funding, TEC/GIV LP, Communitas growth, 0mega funding, Proposal Inverter, Discord Bot Army, T.E.A.M., transparency, legal terms, Rewards kickoff
March 8, 2022
This working groups update covered the week from February 28 to March 7, with a few additional updates included because the post was published slightly later than usual. Stewards reported that one sprint had ended and the next had started, that a new co-Steward had joined the Stewards Working Group, and that several funding votes were live in the Garden. These included Gravity’s six-month funding request, Comms T.E.A.M. translation and Twitter planning proposals, and the retroactive funding request for the TEC Spotlight video. The TE Academy T.E.A.M. proposal had passed, and the first Stewards compensation distribution was underway.
The update also reported a recently passed TAO vote changing bonding curve fees on buy and sell orders to eighteen percent and four percent respectively. Gravity continued to promote its six-month funding proposal, weekly Deep Democracy and Liberating Structures practice sessions, its survey, manifesto, audit, step-by-step process, and Graviton materials. Soft Gov repeated the temporary shift away from quadratic Snapshot voting and highlighted the live Snapshot vote for a 20,000 DAI TEC/GIV token swap and LP creation through LASERTAG.
Communitas reported that the Discord had reached 1,900 members, that its three-month funding proposal had passed, and that March would be its first month of Common Pool-funded work. It was also assisting a strategic partnership between RomeDAO and Labs around token engineering and gamification. 0mega reported that its funding proposal was live, that its working-style discovery board remained open, and that it continued advancing TE Ethics Participatory Research and the TE Consilience Library.
Labs reported that the Solidity Lab Series had concluded, that the Discord Bot Army development series had begun, and that the Proposal Inverter had recently been presented in a 0mega sync. The update continued to list DAO-to-DAO model workshops, Longtail Financial office hours, BlockScience office hours, and shared calendars as the main Labs rhythm. Communications reported that two funding proposals were live and that the T.E.A.M. structure was operating across TE Academy, Twitter, Animation and Video Production, Translations, and HubSpot.
Transparency pointed people toward its funding proposal, payment-transparency forum post, meeting-protocol guidelines, Dune dashboard, and updated TEC Source GitBook. Legal continued reviewing terms and conditions for Conviction Voting proposals and had revised its own funding proposal to include a retroactive bonus for prior contributors. Rewards reported that the new dashboard’s first Praise quantification would take place during March 6 to 12, that SourceCred would begin running later in March, and that the full Rewards system kickoff was expected in roughly two weeks.
By the end of the thread, the TEC’s early-March operations showed the Commons moving from launch stabilization into funded working-group execution. The update connected Garden funding votes, bonding curve fee changes, secondary-market liquidity, Communitas funding, 0mega research, Proposal Inverter work, Discord bot education, T.E.A.M. funding, transparency tooling, legal review, and the first real Rewards-system quantification into one post-launch operating snapshot.
2022-03-07 to 2022-03-14 — TE Academy Update: Looking for Program Hosts
Forum thread: TE Academy update - Looking for program hosts Category: Ecosystem / Archive Archive theme: TE Academy, Token Engineering 360, program hosts, education, community onboarding, TE Fundamentals, ecosystem collaboration
March 7, 2022
This ecosystem thread shared an update from Token Engineering Academy and opened a call for TEC community members to help host a new education program called Token Engineering 360. The post framed the program as a next-step learning experience after the successful TEC and TE Academy collaboration on Introduction to Token Engineering sessions.
Token Engineering 360 was described as a six-session discussion series giving participants a broad overview of token engineering and crypto-economic systems. The program was also tied to the larger TE Fundamentals funnel, which had already collected more than 500 signups. In that sense, the call was not only about finding operational help; it was about connecting prospective learners to the broader token engineering community.
The post asked for one or two people who wanted to learn token engineering, help further develop the program, and take over operational tasks. The expected commitment was about two hours per week, making it a lightweight but meaningful pathway for community members to support education while learning the field more deeply.
March 9 to March 14, 2022
Follow-up comments suggested presenting the opportunity at the TEC Community Call to amplify the message. A response confirmed interest from TE Academy in joining the call, and another community member expressed willingness to participate, noting that the two-hour commitment sounded approachable.
By the end of the thread, Token Engineering 360 had been introduced as another bridge between TE Academy and TEC. The discussion connected education programming, light operational hosting roles, learner onboarding, TE Fundamentals outreach, and community-call amplification into one small but practical ecosystem collaboration.
2022-03-10 to 2023-01-02 — NumFOCUS Donation: Supporting Open Source Scientific Computing
Forum thread: NumFOCUS Donation: Putting Our Money Where Our Mouth is with Regard to Supporting Open Source Category: Conviction Voting / Archive Archive theme: NumFOCUS donation, open source dependencies, scientific computing, token engineering tooling, Conviction Voting process, whale voting, grant administration, system integration
March 10, 2022
A Conviction Voting proposal was opened to donate 25,000 xDAI to NumFOCUS, a nonprofit that supports open source scientific computing projects. The proposal argued that token engineering depends heavily on open source tools such as NumPy, SciPy, pandas, Jupyter, and related data science infrastructure. Because TEC’s own work relied on these tools, the proposal framed the donation as a way for TEC to live by its stated values: if TEC expected others to fund token engineering public goods, then TEC should also fund the open source public goods it depended on.
The proposed donation would go to a Gnosis Safe multisig under NumFOCUS control, with TEC-linked advisors available to support the process. The funds were intended for small developer grants and special projects that could grow the relationship between NumFOCUS-supported open source projects and the web3 ecosystem. The proposal also described the donation as a potential beginning of a longer relationship where TEC could share knowledge about web3 while learning from NumFOCUS’s experience sustaining open source communities.
A question was raised about whether the donation should be converted into TEC and distributed that way. The response explained that this would likely be too much of a leap for NumFOCUS at that stage. The collaboration already required education around web3, self-custody, and Gnosis Safe operations. Providing xDAI rather than TEC was framed as a middle path that could make the collaboration workable while still introducing open source scientific computing contributors to TEC and web3 over time.
The proposal then moved to Gardens, with early support emphasizing that the donation could be a strong signal that web3 could materially support open source and science rather than merely talk about public goods.
March 15 to April 4, 2022
After the proposal passed quickly, the thread became a discussion about governance process, evaluation standards, and large-token-holder influence. A concern was raised that the proposal had passed before some engaged community members had enough time to evaluate it. The critique focused on several issues: the funds would be used at the discretion of a third party, the proposal lacked clear accountability metrics, and large token holders appeared able to move proposals through Conviction Voting faster than the broader community could discuss them.
The response defended the donation while agreeing that TEC’s governance parameters and whale dynamics deserved careful attention. The argument was that TEC’s large token holders were not merely wealthy outsiders, but often people with deep expertise in token engineering, open source, and organization-building. The donation amount was described as intentionally modest relative to what large holders could have pushed through if they were acting carelessly. NumFOCUS was also framed not as a competitor to TEC, but as a maintainer of critical dependencies for token engineering practice.
The discussion clarified the proposal’s deeper logic. TEC asked crypto projects to support token engineering because they depended on it. By the same reasoning, TEC had an obligation to support the scientific computing tools that token engineers used every day. The donation was therefore not outsourcing TEC’s mission, but recognizing upstream dependencies and building relationships with technical communities that could strengthen token engineering.
The concern about process was partly resolved, though not erased. The critic accepted the explanation about NumFOCUS’s role and the importance of open source scientific computing, while continuing to argue that large token holders should exercise care by allowing more time for community evaluation before using enough voting power to pass major proposals. A further response supported the proposal as potentially one of TEC’s most important public goods allocations, especially because applied token engineering depends directly on the software ecosystems NumFOCUS supports.
December 30, 2022 to January 2, 2023
Months later, the thread was revived with a request for updates and a question about whether TEC could become more involved in the collaboration. The update explained that the work had encountered many legal and accounting hurdles, especially because TEC did not have a legal entity. The project had also moved into technical and administrative work around using a grants application tool for the program. A prototype grants page had been created, but it still needed updates before going live.
The update emphasized that the funds remained in the multisig and that the administrative work to sort out the grant had been done pro bono. The main lesson was that token systems cannot be treated as isolated systems. When they interact with existing real-world institutions, such as open source nonprofits, token engineering also becomes system integration work: connecting legal, accounting, organizational, technical, and trust-based systems so that funds can actually move into useful public goods support.
A final question asked whether a donation platform could be introduced, but the response argued that adding another platform would not yet solve the core problem. The first priority was establishing the workflow, running the pilot, and building trusted relationships with the nonprofit counterparties. Only after that would it make sense to move the process onto a technical platform that could streamline future donations.
By the end of the thread, the NumFOCUS proposal had become both a public goods funding action and a governance case study. It documented TEC’s attempt to support upstream open source dependencies, build a bridge between web3 and scientific computing, confront questions about Conviction Voting speed and large-token-holder responsibility, and learn the practical system-integration work required when DAO funding meets real-world nonprofit administration.
2022-03-14 — TEC Working Groups Weekly Update, Mar 7 to Mar 14
Forum thread: TEC WGs Weekly Update: Mar 7 - 14 Category: Community Updates Archive theme: working group updates, Gardens funding, LASERTAG funds, Do-ocracy, Communitas compensation, Consilience Library, Discord bots, access audit, Rewards quantification
March 14, 2022
This working groups update covered activity from March 7 to March 14. Stewards reported that the community was halfway through Sprint 30 and had six open funding votes in the Garden: Gravity’s six-month funding, a NumFOCUS donation, the TE Consilience Library, Comms translations, the TEC Spotlight video retroactive funding request, and Comms Twitter Planning. The first Stewards compensation distribution was still in progress.
A major Steward topic was the LASERTAG pool of funds. The update reported that the previous Stewards Council had discussed how to manage LPs and how to make the best use of 118,781 TEC, valued at roughly 260,000 dollars at the time. The conversation was unfinished and would continue. Stewards also highlighted a community sensemaking article about TEC’s people and interpersonal dynamics, plus notes on Holacracy as a possible organizational management model.
Gravity’s six-month funding proposal was expected to pass, and the group had started a book club around Margaret Wheatley’s Who Do We Choose To Be? while continuing weekly Deep Democracy and Liberating Structures practice sessions. Soft Gov reported proactive work to educate the community about the advice process and its role in DAO governance, along with a co-created list of steps for embodying Do-ocracy.
Communitas reported more than 1,900 Discord members and the first compensation distribution from its Common Pool-funded working group budget. It also highlighted an Intro to Token Engineering presentation and continued work on an FAQ. 0mega reported that the Consilience Library funding proposal was live in Gardens and continued inviting contributors to the live Miro board and library effort. Labs reported the second session of the Discord Bot Army series, focused on setup, server creation, bot authorization, and basic bot code.
Comms reported that its translations and Twitter Planning proposals were live, and that its subteams were working on TE Academy outreach, Twitter planning, Rewards quantification video pre-production, a second batch of translations, and HubSpot data collection. Transparency reported the results of its credentials audit: an access document listing administrator access across TEC platforms and a spreadsheet of multisig holders across working groups. Legal continued work on Conviction Voting terms and ABC terms, and Rewards reported that the new dashboard’s first Praise quantification had taken place while continuing to recruit quantifiers.
By the end of the thread, the TEC’s March operating rhythm centered on funding execution, compensation, liquidity governance, access transparency, and formalizing community processes. The update connected Garden funding, LASERTAG strategy, Do-ocracy education, working group compensation, Consilience Library funding, Discord bot education, access audits, legal review, and Praise quantification into one snapshot of a maturing post-launch Commons.
2022-03-11 to 2022-03-15 — Praise Quantification Automation
Forum thread: Praise Quantification Automation Category: Ideas / Archive Archive theme: Praise, quantification, automation, NLP, SourceCred, Rewards system, objective quantification, intersubjective quantification, anti-gaming
March 11, 2022
This Ideas thread opened after direct experience with the Praise quantification process. The post suggested that parts of quantification could be automated by defining words, phrases, activities, or patterns that corresponded to point values. The idea was to make quantifiers first agree on a vocabulary of recognizable contribution types, then use a Python script to read logs or Google Docs and assign provisional scores based on those definitions.
The proposal also suggested using natural language processing to improve accuracy and to show how each score was determined, so the automation would not become a black box. Human quantification meetings would remain part of the process, but their role would shift toward validating the script, giving feedback, improving the rules, and manually scoring praise that the script could not confidently interpret.
March 15, 2022
A response from someone working on the Praise app clarified the current Rewards-system model. The plan separated praise into two buckets. Objectively quantifiable praise covered activities that could be explicitly or automatically identified and given fixed values, with SourceCred handling that side. Inter-subjectively quantifiable praise covered more subjective contributions, where the Praise app would support peer quantification.
The response interpreted the automation proposal as a possible third bucket: praise that is subjectively identified but objectively quantified based on language patterns. The goal of reducing quantification overhead was appreciated, but two risks were identified. First, praise-givers could game the system by tuning language to trigger higher scores, effectively turning the praise-giver into the quantifier. Second, similar language could hide very different levels of impact, flattening important context into a fixed score.
The original proposer replied that gaming risk already existed with human quantification and suggested using manually generated datasets as baselines for training, comparison, or experiments. The system could also flag unusually similar or novel praise for manual review, allowing automation to reduce workload without fully replacing judgment. The discussion ended without a firm decision, but with an open invitation to keep exploring the relationship between objective quantification and intersubjective peer judgment.
By the end of the thread, the Praise automation idea had clarified a key Rewards-system design tension: how much contribution value should be captured through objective rules, how much should remain intersubjective, and whether automation can reduce overhead without making Praise easier to game or less sensitive to context.
2022-03-15 to 2022-04-02 — cadCAD Community Funding Proposal and AMA Session
Forum thread: cadCAD Community funding proposal & AMA session Category: Conviction Voting / Archive Archive theme: cadCAD, community funding, token engineering education, operations, communications, study groups, modeling literacy, AMA
March 15, 2022
This Conviction Voting thread opened with an invitation to review a cadCAD Community funding proposal before it went live. The post paired the written proposal with an AMA session so that TEC members could ask questions about cadCAD as a tool, the cadCAD community, and the funding request itself before the proposal moved into formal Conviction Voting.
The proposal requested 54,000 wxDai to cover six months of part-time community-management work. The request was framed around three recurring needs: education, operations, and communications. Education would support a cadCAD study group and help token engineering community members improve their modeling skills while producing models, documentation, and research. Operations would maintain the cadCAD community’s coordination infrastructure, including its website and chat spaces. Communications would produce regular updates about new use cases, research, and community activity.
The proposal explained cadCAD as an open-source Python package for designing, testing, and validating complex systems through simulation. It argued that cadCAD had already become important to the TEC and nearby communities, but that the open-source community around it was increasingly dependent on volunteer labor. As the broader token engineering ecosystem grew, the post argued that cadCAD needed consistent paid support so that its education, coordination, and communication functions could scale.
The funding structure was presented as a way for TEC to reinforce its role as a schelling point for token engineering. Rather than funding a one-off deliverable, the proposal sought to support an aligned public-good infrastructure community that could help more people become competent token engineers and modelers.
April 2, 2022
A later follow-up encouraged support for the cadCAD organization and connected the proposal to a broader vision of open, legible methods and tools for model-based systems engineering. The response emphasized that software development alone was not enough; the social and educational side of the cadCAD community also needed support if the tool was going to continue serving TEC and the broader token engineering field.
By the end of the thread, the cadCAD funding request had been framed as both a practical budget proposal and an ecosystem-alignment proposal. It asked TEC to support the people and processes around cadCAD so that education, operations, communications, study groups, community updates, and modeling literacy could keep expanding alongside the token engineering field.
2022-03-18 to 2023-03-03 — Proof of Competence Funding Proposal
Forum thread: Proof of Competence funding proposal Category: Advice Process / Archive Archive theme: Proof of Competence, useWeb3, Web3 learning, onchain quests, reputation, credentials, learning modules, soulbound tokens
March 18, 2022
An advice process thread was opened for a funding proposal to develop Proof of Competence V2. The proposal combined two existing projects: a Web3 developer learning platform and an onchain quest framework for proving familiarity with specific protocols or technologies. The goal was to create a generic, open education platform where communities could design learning experiences using onchain data, modular tasks, and verifiable actions.
The proposal explained that the existing Proof of Competence project had started as a hackathon project and already provided a working framework for onchain quests and onboarding journeys. The system could verify that certain onchain actions had occurred, allowing an address to build reputation or a community score based on demonstrated familiarity with particular tools, protocols, or practices. Possible uses included developer onboarding, proof of basic protocol competence, and governance systems that used demonstrated knowledge instead of pure token weight.
The proposed V2 would expand the project from a quest-verification tool into a broader learning platform. Communities would be able to create open-source learning modules with content, onchain verifications, signed messages or transactions, quizzes, and structured learning materials. The proposal imagined these modules eventually being served through IPFS using standardized metadata, allowing any community to publish its own learning journey in a permissionless way.
A rewards module was also described, though rewards were presented as optional. Completing modules could produce badges, attestations, POAPs, NFTs, or other recognition. The proposal explicitly noted the tradeoff between rewards and intrinsic motivation: incentives might attract more learners, but they could also encourage people to seek rewards without genuinely learning.
The requested funding was 5,500 USD in stablecoins plus contingency. The budget covered development of the content and learning system, quiz module, profile integration using identity tools, an initial Web3 or Solidity course to demonstrate the platform, and collaboration with Communitas to spec out a TEC learning experience.
March 19 to March 30, 2022
Early discussion explored possible collaborations. One response connected Proof of Competence to Web3 design education and asked whether the system could be useful for designers. The reply clarified that the project’s strongest fit was verifiable data and credentials, such as contract deployment, contract interaction, or governance participation, although the coming learning and quiz modules could also support less onchain-heavy learning experiences.
Another question asked about the state of the project and the timeline for V2. The response clarified that Proof of Competence already had a functional product and that the proposal was intended to fund the next version. There were no major blockers, but the project wanted to remain permissionless and neutral so that it could serve as a public good for any Web3 community. This meant that working with additional communities to design learning journeys could become a useful role for community leads, stewards, or non-technical contributors.
The thread also surfaced overlap with questing systems in other communities. Rather than treating that overlap as a problem, the discussion pointed toward possible cross-pollination. The project was moving beyond quests alone toward learning, quizzes, and broader credentialing, but there was still room to learn from related systems.
February 14 to March 3, 2023
The thread was revived almost a year later with a suggestion that the project could connect to soulbound tokens or broader identity concepts in the token engineering ecosystem. The response pushed back on non-revocable identity models, arguing that crypto should empower people and protect personal freedom and sovereignty. From this perspective, people should be able to revoke or remove information that no longer aligned with them.
The update also explained that Proof of Competence had shifted direction and was preparing to launch a new learning and certification platform. The project remained open to designing TEC-specific modules once the new platform was live. A final exchange clarified access to a related strategy document.
By the end of the thread, Proof of Competence had been framed as an education and credentialing public good for Web3 communities. The discussion connected onchain verification, modular learning, quizzes, reputation, governance alternatives, identity, incentive design, and TEC onboarding into one proposal. It also captured a key tension around credentials: communities wanted ways to recognize competence, but those systems needed to preserve user agency and avoid locking people into permanent identity claims.
2022-03-18 — Compromised Wallets With Vested TEC Tokens
Forum thread: Compromised wallets with vested TEC tokens - How to proceed? Category: Community Updates Archive theme: compromised wallets, vested TEC, address changes, TAO Voting, advice process, Garden proposals, token custody, governance remediation
March 18, 2022
This community update documented the process for people whose wallets holding vested TEC tokens had been compromised. The post responded to recent inquiries about whether vested TEC could be moved from an old compromised address to a new safe address, and it turned that situation into a clear governance pathway.
The process began with an Advice Process post explaining the situation. Because the change would need to go through TAO Voting and meet a high quorum, the post emphasized that the community needed to understand the issue and want to support the request. People were encouraged to invite others to vouch for them and to promote the post, especially because multiple people might have similar compromised-wallet issues and could potentially submit a combined proposal.
After incorporating feedback, the requester would turn the advice-process post into a formal proposal using the forum proposal template. The most important information would be the old compromised wallet address and the new wallet address. The requester would then create a proposal in the TEC Garden, using the decision filter, and write a concise action statement requesting the transfer of vested TEC holdings from one wallet to another.
The post also noted a practical barrier: Garden proposals required a 200 liquid TEC deposit, meaning the requester might need to buy liquid TEC through the Augmented Bonding Curve or Honeyswap before submitting. By the end of the post, TEC had a public remediation pathway for compromised vested-token wallets: explain the case, gather support, formalize the proposal, pay the proposal deposit, and ask TAO Voting to authorize the address change.
2022-03-18 to 2022-04-18 — Legal WG Funding Proposal: Contingency Fund and Retroactive Bonus
Forum thread: Legal WG Funding Proposal: Contingency Fund and Retroactive Bonus Category: Conviction Voting / Archive Archive theme: Legal WG, contingency fund, retroactive bonus, external legal support, Hatch terms, Covenant, Conviction Voting terms, Gnosis multisig
March 18, 2022
This Conviction Voting thread opened a one-time funding proposal for the Legal Working Group after the Commons Upgrade. The proposal acknowledged that regular legal work had decreased after the upgrade, but argued that TEC still needed to be prepared for urgent legal issues that could not wait for the normal Conviction Voting timeline.
The request totaled 12,000 wxDAI. Of that amount, 10,000 wxDAI would be held as a contingency fund for external legal support, to remain unused unless a legal issue arose. The remaining 2,000 wxDAI would be converted into TEC and distributed as a retroactive bonus to Legal Working Group contributors who had prepared documents critical to the Hatch and Commons Upgrade.
The thread described the retroactive bonus as recognition for work on documents such as Hatch terms, the Covenant, Conviction Voting proposal terms and conditions, and related legal materials. It also clarified that the proposal did not cover future legal documents; any new work would require a new proposal or compensation through the Rewards system. Fund management was to happen through a Gnosis multisig, with fund movements shared in the forum and in Legal Working Group calls.
April 12 to April 18, 2022
A follow-up reported that the Legal Working Group funding proposal had passed and executed. The 2,000 wxDAI retroactive bonus amount was transferred, used to buy TEC through the Augmented Bonding Curve, and prepared for distribution to the earlier Legal Working Group contributors.
A later update confirmed that the retroactive bonus had been distributed in TEC and that the transactions were documented in a tracking spreadsheet. By the end of the thread, TEC had established a legal emergency reserve while also retroactively recognizing the contributors who had produced the legal infrastructure needed for the Hatch, the Covenant, and the early Commons governance process.
2022-03-23 to 2022-03-30 — Retroactive Funding for TEC at ETHDenver 2022
Forum thread: Retroactive Funding for TEC at ETH Denver 2022 Category: Conviction Voting / Archive Archive theme: retroactive funding, ETHDenver, outreach, event representation, travel reimbursement, TEC/TEA POAP, public talks
March 23, 2022
This Conviction Voting thread opened a retroactive funding request for TEC representation at ETHDenver 2022. The proposal asked for reimbursement of expenses that had already been paid in xDAI and would be sent to the address of the person who had covered them. The itemized expenses included accommodation for one person in the ETHDenver Stack House, one flight, and TEC/TEA pins, for a total request of 965.16 wxDAI.
The proposal framed the request as outreach funding. Several TEC members had attended ETHDenver and represented the community, with many costs covered by related organizations such as Giveth, General Magic, or Commons Stack. The remaining expenses were described as harder to justify under those organizations’ budgets, so the post requested that TEC reimburse them directly because the event work benefited TEC’s visibility and mission.
The supporting information pointed to talks given by TEC community members during ETHDenver, including sessions on stewardship, cultural build, and Web3 opportunities, and also noted the existence of a TEC/TEA POAP. This placed the expense request in the context of public speaking, event presence, and shared token engineering outreach.
March 30, 2022
A follow-up asked for soft consensus in the forum before moving the request into the TEC Garden. The post included a simple support poll to test whether the community agreed with submitting the reimbursement proposal formally.
By the end of the thread, the ETHDenver reimbursement request had been framed as a small retroactive funding proposal for public outreach. It clarified how TEC could reimburse event-related costs when contributors represented the Commons, produced talks, distributed community materials, and helped maintain a public presence for token engineering.
2022-03-28 to 2022-04-06 — Dogfooding the Proposal Inverter Meta Proposal
Forum thread: Dogfooding the Proposal Inverter-Meta Proposal Category: Conviction Voting / Archive Archive theme: Proposal Inverter, meta proposal, multi-DAO funding, collaborative public goods, cadCAD modeling, DAO-to-DAO coordination, accountability
March 28, 2022
This Conviction Voting thread formalized the Proposal Inverter dogfooding effort as a meta proposal. The post described the Proposal Inverter as a tool for reversing the usual DAO-proposal relationship: instead of many proposals competing inside one DAO, many DAOs could coordinate around and fund one shared proposal. The stated purpose was to reduce friction between researchers, builders, funders, and DAOs when a public-good project served multiple communities.
The proposal requested 30,000 wxDAI from TEC. It argued that the Proposal Inverter would benefit token engineering in two ways. First, the product itself used token engineering practices, including simulation and modeling with tools such as cadCAD, and its outputs would be open source. Second, the tool was meant to strengthen collaborative public-good funding across the DAO ecosystem by making it easier for multiple DAOs to pool support around shared work.
The post also framed the meta proposal as the place where funders could find the full project context: deliverables, milestones, team, building philosophy, and the labor and funding role of each participating party. This made the thread less like a simple grant request and more like an attempt to document the common reference point for a multi-DAO funding process.
April 4 to April 6, 2022
A later response raised several governance and accountability questions. The questions focused on how participating DAOs would stay informed, how each funder would know it was receiving the benefit of its contributed funds, how the proposal would avoid free-rider problems, what metrics would define success, and whether the Proposal Inverter truly reduced overhead compared with submitting separate proposals to each DAO.
The reply explained that calls were being recorded and that weekly status updates were being shared publicly, including marketing, product development, and partnership progress. The answer emphasized that the benefits were not profit distributions but open-source token engineering simulations, a useful DAO-to-DAO funding tool, and the creation of a collaborative ecosystem around the product. Success was described in both technical and ecosystem terms: completing design and backend work in the first three months, finishing the full product, documentation, and frontend in the final three months, and creating a functioning environment for collaborative funding.
The response also clarified the coordination-reduction thesis. A common Proposal Inverter interface could let multiple funders contribute to one pool, stream funds over time, manage changing contributor groups, maintain accountability, and avoid repeated bespoke payment schemas for each additional payer. By the end of the thread, the Proposal Inverter meta proposal had moved from broad public-goods framing into concrete questions about accountability, success metrics, coordination overhead, fund streaming, and the practical mechanics of multi-DAO proposal management.
2022-03-30 to 2022-03-31 — TEC Simulator: Conviction Voting Chart Display
Forum thread: TEC Simulator - can we change how conviction voting chart displays? Category: Ideas / Archive Archive theme: TEC Simulator, Conviction Voting, chart design, parameter visualization, proposal funding, conviction threshold, user education
March 30, 2022
This Ideas thread opened with feedback that the Conviction Voting section of the TEC Simulator was difficult to explain to people unfamiliar with Conviction Voting. The problem was not only the math, but the way the chart framed the information. People could eventually say they understood, but the post suggested that the visualization still did not communicate the mechanism intuitively.
The proposed change was to make the x-axis show “days until proposal passes.” Instead of selecting an arbitrary time frame, users would select a funding request amount and total Common Pool amount. The resulting chart would show how long a proposal would take to pass under those assumptions, and could include a visible conviction threshold. This was framed as the data point people most cared about: how much support and time a given proposal would need before it could pass.
The thread argued that “days until proposal passes” was a clearer mental model than “percent of Common Pool,” and that setting a concrete funding request was more understandable than choosing a time period. In other words, the proposed chart redesign would translate Conviction Voting from an abstract parameter display into a decision-support tool for proposal authors and voters.
March 31, 2022
A follow-up response treated the suggestion as worth investigating and asked whether there were technical constraints on the proposed revisions. This moved the idea from user-experience feedback into implementation review.
By the end of the thread, the TEC Simulator feedback had identified a specific usability issue in Conviction Voting education: the existing chart may have been mathematically correct but hard to interpret. The proposed redesign centered proposal amount, Common Pool size, passing threshold, and days-to-pass as more intuitive variables for helping people understand how Conviction Voting behaves.
2022-04-01 to 2022-04-04 — Retroactive Funding for TEC Comms and Communitas
Forum thread: Retroactive Funding for TEC Comms and Communitas Category: Conviction Voting / Archive Archive theme: retroactive funding, TEC Comms, Communitas, contributor compensation, Commons Upgrade, Giveth Trace, working group funding
April 1, 2022
This Conviction Voting thread opened a retroactive funding proposal for TEC Comms and Communitas contributor compensation. The request covered work performed from August 2021 through February 2022, before the Commons Upgrade and before the relevant working group funding proposals had passed.
The proposal explained that compensation had already been paid through the Giveth Trace TEC Campaign to keep critical contributors supported during a period when the TEC did not yet have a mature rewards system, direct access to capital, or approved working group budgets for this labor. It framed the request as reimbursement for funds advanced to sustain communication and community-building work during a crucial operational period.
The post included a month-by-month breakdown of payments from August 2021 through February 2022. The total retroactive funding request was 63,041 wxDAI, to be paid in monthly chunks. The proposal argued that TEC Comms and Communitas had been critical to the Commons Upgrade and to the state of the community at that point, making the reimbursement a way to recognize and regularize already-completed public-good work.
April 1 to April 4, 2022
Follow-up comments were short and supportive. They thanked the person who had advanced the funds during a critical moment and praised the decision to keep contributors going when the organization’s formal funding pathways were not yet ready.
By the end of the thread, the proposal had documented a transitional funding pattern inside TEC: contributor work was needed before governance and treasury systems could reliably compensate it. The thread turned that informal bridge funding into a formal Conviction Voting request, connecting Comms, Communitas, contributor sustainability, Giveth Trace records, and Commons Upgrade readiness into one retroactive compensation proposal.
2022-04-04 to 2022-04-05 — Presenting and Preserving Transparency Audit Reports
Forum thread: How should we present and preserve the Transparency Audit Reports? Category: Advice Process / Archive Archive theme: Transparency Audit, audit preservation, IPFS, NFTs, markdown, PDF, presentation design, public accountability
April 4, 2022
This Advice Process thread opened as TEC was finishing its first post-Hatch Transparency Audit and began asking how the audit reports should be presented and preserved over the long run. The starting idea was to write reports in markdown, upload them to IPFS, and potentially mint a non-transferable NFT held by the DAO so the reports could be collected, displayed, and preserved in a way that neither individual contributors nor the working group could later alter.
The post also suggested pairing the preserved markdown version with a PDF for accessibility and possibly a more visual presentation version that would be easier to walk through with the community. The key design tension was between permanence, simplicity, readability, and the need to include visuals or supporting data without relying too heavily on external linked files.
April 5, 2022
A follow-up response supported the IPFS and tokenized preservation idea while raising a transparency question: if charts, graphics, or source data were excluded from the preserved document, would that reduce the audit’s reliability? The response suggested that a minimal report containing the essential information could coexist with a more visual, friendly version, such as a horizontal slide-style presentation that made the audit easier to understand.
By the end of the thread, the Transparency Audit discussion had moved beyond report writing into archival design. The community was thinking about how to make audits durable, verifiable, accessible, and readable at the same time, balancing markdown permanence, IPFS storage, DAO-held document records, PDF accessibility, visual summaries, and the need to preserve enough data for the audits to remain trustworthy.
2022-04-05 to 2022-04-22 — WATER: Five Token Swaps and an Index Token
Forum thread: Water: 5 Token Swaps in 1 & an Index Token to Boot! Category: Snapshot / Archive Archive theme: WATER, shared liquidity, token swaps, index token, LASERTAG, Honeyswap, Gnosis Chain, Snapshot governance, multisig risk
April 5, 2022
This Snapshot thread brought the WATER shared-liquidity proposal from steward-call discussion onto the TEC forum. The proposal described a multi-community liquidity experiment involving several aligned DAOs on Gnosis Chain. Each participating DAO would contribute roughly 100,000 dollars worth of its own token into a shared multisig. If all communities joined, WATER would be minted and paired with each community token in Honeyswap liquidity pools.
The post framed WATER as both a liquidity boost and an index token. Because WATER would be created against the pooled community-token liquidity, holding WATER would function like holding exposure to the participating DAO ecosystem. The proposal was described as a five-way token swap that also produced an index-like asset, potentially giving participating communities liquidity and demand upside without each project having to negotiate separate pairwise liquidity arrangements.
The post also emphasized the risks. WATER was an untested mechanism, and TEC’s participation would require a large share of LASERTAG’s funds. The shared liquidity would be controlled by multisigs with representatives from participating communities, and TEC could withdraw only with a 15 percent penalty unless the overall group agreed to unwind the project. The post asked the community whether TEC should participate through a Snapshot vote.
April 19 to April 22, 2022
Later discussion raised concerns about whether the liquidity boost justified the risk. One response questioned whether TEC should commit a large amount of buy-in tokens to an unmodeled, untested mechanism, especially given TEC’s identity as a token engineering project. Another response suggested that low voting activity might reflect uncertainty rather than apathy, and asked whether WATER actually generated more liquidity or simply diversified liquidity through an index structure.
The follow-up clarified that if the project failed or the group collectively decided to end it, TEC would get its tokens back. If TEC alone wanted to exit while the rest of the multisig wanted to continue, TEC would lose 15 percent. The explanation also clarified that the index component did not create more liquidity by itself; rather, it could create demand if people chose to hold WATER, because buying WATER would draw from the underlying pools and indirectly support demand for the participating tokens.
By the end of the thread, the WATER discussion had clarified both the promise and the governance risk of the experiment. Supporters saw it as a way to boost demand, cooperate with aligned communities, diversify exposure, and pioneer a novel liquidity primitive. Skeptics focused on the lack of modeling, the novelty of the mechanism, the scale of TEC’s contribution, the unclear governance of the index, the multisig trust assumptions, and the 15 percent solo-exit penalty.
2022-04-11 — TEC Working Groups Weekly Update, Apr 4 to Apr 11
Forum thread: TEC WGs Weekly Update: Apr 4 - 11 Category: Community Updates Archive theme: working group updates, Gardens funding votes, financial audit, Graviton training, Governance Engineering Guild, Communitas growth, Proposal Inverter, Comms T.E.A.M., Transparency, Rewards
April 11, 2022
This Community Updates post restarted the TEC Working Group weekly synthesis after a brief hiatus and summarized work across the DAO from April 4 to April 11. The update opened with Stewards work near the end of Sprint 32 and noted four live Gardens funding votes: cadCAD Community Funding, the Proposal Inverter meta proposal, Comms T.E.A.M. Marketing, and retroactive funding for TEC at ETHDenver 2022. The Stewards also identified two improvement actions: gathering in-house token engineers who could consult for projects seeking TEC support, and increasing outreach around Token Engineering Academy educational events.
The update also reported that the Stewards Council had reviewed a financial audit of the Commons. The main issues on the Stewards’ agenda were TEC token utility, the Proposal Inverter, Conviction Voting parameters, schedule changes, and the formation of a financial task force. This placed financial transparency, proposal throughput, and token utility near the center of DAO operations for the week.
Gravity announced that the third Graviton Training would begin on April 26, continued weekly practice sessions on Deep Democracy and Liberating Structures, continued its book club, and maintained psychology and mental health research syncs. Soft Gov discussed ideas from commons theory, including the relationship between resources, communities, and social protocols, and noted the emergence of a Governance Engineering Guild focused on token engineering for governance.
Communitas reported that the Discord had passed 2,100 members, announced upcoming Gardening Sessions to help the community understand live Gardens proposals, and continued work on a GitHub audit and engagement-process mapping. 0mega organized sensemaking diagrams into a “Tour of the 0mega Archipelago,” continued experimenting with regenerative working styles, and kept recruiting contributors for the Consilience Library.
Labs reported that the Discord Bot Army event remained active, that Proposal Inverter DAO-to-DAO model workshops were continuing, that a recent Proposal Inverter presentation had been shared, and that pre-registration for TE Fundamentals was open. Comms noted that the Marketing T.E.A.M. funding proposal was live and summarized work across TE Academy, Twitter, animation and video production, translations, and marketing, including the release of the first bi-weekly newsletter email.
Transparency reported on the financial audit presentation, the forum discussion about preserving Transparency Audit reports, and meeting protocol guidelines. Legal welcomed new contributors and continued work on content ownership and revenue implications. Rewards reminded contributors to activate the new Praise Bot, noted that the fifth quantification round had closed, and continued work on a Reward Board proposal and task-force documentation.
By the end of the update, TEC’s early-April operating picture showed a DAO settling into post-upgrade routines: multiple funding proposals were live, financial transparency was becoming more formal, governance and token utility questions were under active review, community onboarding was growing, the Proposal Inverter was moving through both funding and education channels, and Rewards was turning Praise usage into a more structured compensation process.
2022-04-18 — TEC Working Groups Weekly Update, Apr 11 to Apr 18
Forum thread: TEC WGs Weekly Update: Apr 11 - 18 Category: Community Updates Archive theme: working group updates, Sprint 33, funding votes, treasury growth, Proposal Inverter AMA, ETHAmsterdam, ecosystem health metrics, Legal funding, Rewards, SourceCred sunset
April 18, 2022
This Community Updates post summarized TEC working group activity from April 11 to April 18. Stewards closed Sprint 32, began Sprint 33, and reported three live Gardens funding votes: cadCAD Community Funding, retroactive funding for TEC at ETHDenver, and Comms T.E.A.M. Marketing. The Stewards’ retrospective produced two operational actions: forming a working group mandated to bring more funds into the treasury, and adding expected milestones to the proposal template so that future audits could track progress more clearly.
The update showed the Stewards focusing on temperature checks, newsletters, Rewards updates, events in Amsterdam, upcoming TEC presentations, scholarship ideas for conferences, the financial audit, and the Commons Prize. TEC also hosted a Proposal Inverter AMA with PrimeDAO and prepared for ETHAmsterdam, the DAOist, Schelling Point, DevConnect, and a presentation at London Business School blockchain week.
Gravity delayed the third Graviton Training to May 3 and continued practice sessions, book club, psychology and mental health research, and conflict-support intake. Soft Gov organized cultural streams around race and gender, religion and ancient knowledge, psychology and mental health, personal development, and open-source culture and documentation, while also exploring ecosystem health metrics and a Snapshot WATER proposal.
Communitas worked on the question of what makes someone a TEC member and continued applying the TEC Engagement diagram. 0mega aggregated its workflows and ideas into a Figma file, advanced research into a dynamic energy budget for an art-and-science lab model, and hosted another Imaginarium Creative Jam session.
Labs reported that the Discord Bot Army event was still active, Proposal Inverter DAO-to-DAO model workshops were continuing, the Proposal Inverter meta proposal had passed, the NumFOCUS proposal had passed, and TE Fundamentals pre-registration was open. Comms continued operating through its T.E.A.M. structure, with work on the TE Academy outreach campaign, Twitter planning, video and animation proposals, translation coordination after a resolved conflict, meme parties, anti-spam tooling, and newsletter data collection through HubSpot.
Transparency continued work on the financial audit, meeting protocols and disclaimers audit, and the forum discussion about preserving Transparency Audit reports. Legal reported that its funding proposal had passed and executed, and that work was underway on the Covenant, content ownership agreement, Celeste enforcement possibilities, and terms and conditions for third-party services. Rewards reminded contributors to activate the Praise Bot, closed the sixth quantification round, continued work on a Reward Board proposal for future distributions, and noted that SourceCred.org was shutting down.
By the end of the update, TEC’s mid-April operations were focused on institutional maturity: treasury growth, milestone tracking, financial audits, proposal accountability, event representation, governance health metrics, legal infrastructure, Rewards continuity after SourceCred, and continued education and coordination around Proposal Inverter and TE Fundamentals.
2022-04-18 to 2022-04-25 — Governance Token Engineering Guild
Forum thread: Governance Token Engineering Guild Category: Advice Process / Archive Archive theme: governance token engineering, special interest group, modeling and simulations, DAO governance support, TE Academy, value streams, TEC token demand
April 18, 2022
This Advice Process thread proposed creating a Governance Token Engineering Guild as a new special interest group inside TEC. The guild would focus on token engineering in the context of governance, responding to a new phase after the TEC token launch in which outside projects were increasingly asking for support with simulations and rigorous governance-design processes.
The proposal argued that governance token engineering was still early and lacked shared best practices. The guild was intended to create a focused platform for engineers, data scientists, mathematicians, governance researchers, and token engineers to meet, learn, experiment, and support each other. It would also create an interface between TEC, DAOs, and governance research teams.
The proposed goals included connecting members, analyzing token and governance challenges, attracting promising junior token engineers such as TE Fundamentals graduates, helping members find internships and project collaborations, and exploring sustainable value-flow models for TEC. The proposal linked guild success to practical outcomes: establishing a group of ten members, defining collaboration policies, working on two or three governance challenges, building a network of ten DAOs or research teams, and finding a model that could create TEC token demand.
The roadmap moved through four phases. The first phase, from April to June 2022, would invite initial members, hold a kickoff, and design policies and intake processes. The second phase would start running activities around incoming governance and rewards-model requests. The third phase would evaluate value streams and possible organizational forms such as internships, consulting, temporary grant teams, or collaborator networks. A later spin-off phase could create a dedicated working group for TEC value-stream token modeling and potentially serve as a template for other special interest groups.
April 18 to April 25, 2022
A follow-up added credit for the person who had originally envisioned and drafted the proposal. Another response expressed enthusiasm and willingness to contribute.
By the end of the thread, the Governance Token Engineering Guild had been framed as a bridge between education, research, consulting, and revenue strategy. It aimed to convert TEC’s token engineering knowledge into a focused governance-design practice, while also creating pathways for skilled contributors, DAO partnerships, governance research, and longer-term TEC token demand.
2022-04-25 — TEC Working Groups Weekly Update, Apr 18 to Apr 25
Forum thread: TEC WGs Weekly Update: April 18 - 25 Category: Community Updates Archive theme: working group updates, WATER vote, Fundraising WG, Praise etiquette, Governance TE Guild, engagement process, TE Fundamentals, SourceCred shutdown, Reward Board
April 25, 2022
This Community Updates post summarized TEC working group activity from April 18 to April 25. Stewards reported that Sprint 33 was underway and that three funding votes remained live in the Gardens: cadCAD Community Funding, retroactive funding for TEC at ETHDenver, and Comms T.E.A.M. Marketing. The update also recorded the WATER Snapshot decision, in which TEC would join other aligned DAOs by contributing 100,000 dollars worth of its own token into a multisig that would mint WATER and pair it with each token in Honeyswap liquidity pools.
Stewards also reported early progress toward a Fundraising Working Group, a 6,000 dollar consulting deal for Gravity work with Aragon, and a collective document around Praise etiquette. The weekly sync covered a Rewards stewardship transition, Governance Token Engineering Guild updates, the TEC Engagement Process diagram, and the need to rerun the WATER Snapshot vote because the first attempt had insufficient quorum.
Gravity prepared for the third Graviton Training, continued Deep Democracy and Liberating Structures practice, maintained its book club and psychology and mental health research sync, and held an Aragon Discord AMA on conflict management. Soft Gov linked the WATER vote to a broader discussion about voter apathy and community engagement, continued work on ecosystem health metrics, and prepared to launch the Governance TE Guild. It also pointed to the incubating Financial Working Group and possible revenue streams for TEC.
Communitas continued developing the engagement process, including Praise activation outreach, member-stage roles, and definitions of the community’s constituents. 0mega continued its workflow mapping, Consilience Library work, dynamic energy budget research, and Imaginarium Creative Jam sessions. Labs kept the Discord Bot Army event active, continued Proposal Inverter DAO-to-DAO model workshops, promoted TE Fundamentals pre-registration, and looked for proposal contributors for TEC Lab.
Comms reported that the Marketing T.E.A.M. funding proposal was still live and summarized work across TE Academy, Twitter, animation and video production, translations, and marketing. The update included outreach to educational projects in other DAOs, Amsterdam event coverage, basic token engineering concept posts, storyboard work for Rewards and Conviction Voting videos, resumed translation work after a resolved conflict, and an upcoming newsletter.
Transparency said the financial audit was nearly ready and reminded readers of TEC meeting protocols, terms, and disclaimers. Legal repeated that its funding proposal had passed and executed, while continuing Covenant updates, content ownership work, Celeste enforcement discussion, and third-party service terms. Rewards reported a stewardship transition, closure of the seventh quantification round, a forum post on quantifier disagreement, continued Praise Bot activation, an upcoming Reward Board proposal, and the intention to keep using SourceCred while it remained usable even though SourceCred.org and its repositories were shutting down.
By the end of the update, TEC’s late-April operations were dominated by practical post-upgrade systems work: liquidity governance through WATER, quorum and voter engagement problems, fundraising and revenue strategy, financial audit readiness, Praise etiquette, Rewards continuity, event representation, education outreach, and the ongoing effort to turn working group processes into reusable organizational infrastructure.
2022-04-25 to 2023-01-10 — Measuring TEC’s Ecosystem Health
Forum thread: Measuring TEC’s ecosystem health Category: Advice Process / Archive Archive theme: Ecosystem health, Ostrom principles, DAO analytics, RAD dashboard, Karma, reputation systems, organizational metrics, community health
April 25, 2022
An advice process thread was opened to explore how TEC could measure the health of its ecosystem. The post connected this question to earlier Governauts research on reward systems and to the use of Ostrom’s principles as indicators of commons health. The Soft Gov Working Group had begun mapping how Ostrom’s principles were implemented in TEC and what metrics could be used to track whether those implementations were working.
The idea developed into a possible ecosystem health dashboard. The first step was to understand what data TEC already had and what could realistically be measured. Work had begun in shared boards and spreadsheets to map TEC practices against the eight Ostrom principles and identify candidate metrics for each principle. The concept was that each principle could have several metrics, each with thresholds that would indicate whether a given area was healthy or suboptimal.
The thread framed the central challenge as identifying TEC’s measurement apparatus. The community needed to decide what could be measured, how those metrics should be collected, and where the results should be displayed. Options included integrating the work into the Reward Analysis Dashboard, using Karma, or building another interface. The proposed benefits included better feedback loops, more granular problem identification, easier contributor handoff when core collaborators left, analytics based on Ostrom’s principles, and the possibility of combining ecosystem health metrics with reward-system scores into a broader reputation system.
The post then mapped examples of TEC implementations under each Ostrom principle. These included token governance, access rights, roles, the community covenant, Discord onboarding, Trusted Seed, vesting, entry and exit tributes, Conviction Voting, reward analysis, do-ocracy, onboarding, sprint planning, Praise quantification, monitoring through public meetings and proposals, transparency audits, graduated sanctions, Gravity conflict resolution, the legal working group, Snapshot, SourceCred, partnerships, working groups, and nested relationships with other organizations.
April 27 to May 2, 2022
Early responses focused on product and interface potential. The discussion noted that the project would require UX and UI design because the dashboard would need to display a lot of complex information in a way that users could understand. The idea was also described as potentially useful beyond TEC: a template or dashboard for showing how a DAO implements Ostrom’s principles and what data supports those claims.
The thread also connected the work to impact evaluation. Once TEC had basic ecosystem health tracking, it could potentially build theory-of-change or logic-model tools on top of it, learning from nonprofit and philanthropic evaluation methods. This suggested that ecosystem health analytics could become both an internal governance tool and a broader product or service for mission-driven DAOs.
Another contribution introduced related work on community health analytics using organizational network analysis and pulse surveys. This approach was less focused on custom metrics for each Ostrom principle and more focused on understanding the structure of the community network. The thread suggested that both approaches could be developed in parallel and compared, potentially creating richer insight into DAO health by combining network analysis, survey data, and Ostrom-based metrics.
May 23 to June 5, 2022
The discussion later proposed looking at TEC health through four main domains: the community, the Common Pool of funds, the TEC token, and the subject matter of token engineering itself. The point was that TEC could not evaluate its health only by looking at community engagement. If the Common Pool, the token economy, or the broader token engineering discipline were unhealthy, the Commons could fail to achieve its purpose even if the internal community felt active.
This framing suggested different questions for each domain. For the community, TEC could measure growth, churn, and participation. For the Common Pool, it could examine responsible fund management, burn rate, and the share of spending going toward external mission work versus internal operations. For the TEC token, it could ask whether buying TEC had become a meaningful way to support token engineering, including trade volume and contributions to the Common Pool. For the subject matter, it could ask whether token engineering as a discipline was gaining traction and whether TEC’s work contributed to that growth.
The domain-based framing was then connected to the Sampo Working Group’s work on financial health and TEC utility. The discussion suggested that token utility and the health of the token engineering field were central to understanding TEC’s broader ecosystem health.
January 10, 2023
The thread was later revived with a question about whether the resources mapped in the ecosystem health work had influenced TEC’s understanding of boundary work, both technologically and socially. This brought the discussion back to Ostrom’s first principle and the practical question of how a DAO defines, observes, and maintains its boundaries over time.
By the end of the thread, ecosystem health measurement had been framed as a major analytic and governance challenge for TEC. The discussion moved from Ostrom-based metrics to dashboard design, reputation systems, organizational network analysis, impact evaluation, token utility, treasury health, and the relationship between TEC’s internal community and the wider token engineering field. The thread captured TEC’s attempt to turn commons theory into measurable governance feedback loops.
2022-05-04 to 2022-05-24 — Third Graviton Training Study Plan
Forum thread: Third graviton training study plan Category: Community Updates Archive theme: Gravity, Graviton training, conflict management, nonviolent communication, DAO contributor support, POAPs, training curriculum, community care
May 4, 2022
This Community Updates thread published the study plan for the third Graviton Training. The post defined a Graviton as a community conflict-support role and described the training as a ten-session course on tools and skills for preventing and managing conflict among DAO contributors. Participants who claimed at least six POAPs across the sessions could become Gravitons, serving as clear access points for conflict-management support in their communities.
The training was scheduled to run weekly on Tuesdays from May 24 through July 26, 2022, for ten one-hour sessions over Zoom. The post framed the course around nonviolent communication, conflict comprehension, internal and collective conflict-management practices, and the Gravity 4Ps framework. The methodology emphasized informed consent, expectation setting, contextualized facilitation, cross-pollination among participants, and the production of new shared knowledge through practice.
The learning objectives were both interpersonal and institutional. Participants were expected to become more present and accessible to their communities, separate people from problems, recognize key conflict-management points, promote empathy, tolerate conflictive situations with calm and diplomacy, work with paradoxes, and act within community rules, codes of conduct, and transformational processes.
The curriculum was organized into modules covering propedeutics, people, problems, process, and possible solutions. Topics included decolonization and complexity, trauma-sensitive and anti-oppressive culture, nonviolent communication, the Gravity framework, Deep Democracy, decentralized dispute resolution, Liberating Structures, group case presentations, and final role-play. The thread also pointed participants toward prior Graviton trainings, a pre-registration spreadsheet, the support-request form, continued education pathways, bounty opportunities, and the possibility of becoming an Active Graviton.
May 5 to May 24, 2022
Follow-up comments responded positively to the third cohort, especially the refreshed curriculum and the new facilitators leading individual sessions. The discussion treated the course as both a continuation of Gravity’s existing practice and a way to bring more contributors into active community-care roles.
On May 24, the thread was updated with the calendar invite for the ten sessions and the Zoom link for the training. This converted the study plan from a curriculum announcement into a practical onboarding artifact for participants.
By the end of the thread, the third Graviton Training had been framed as a structured pathway from learning to practice: participants could study conflict transformation, claim attendance POAPs, become visible support points for their communities, continue through Gravity practice groups, and eventually contribute to conflict-management work through bounties or Active Graviton roles.
2022-05-12 to 2022-06-06 — Steward WG Three-Month Funding Proposal: May to July
Forum thread: Steward WG 3-month funding proposal (May - July) Category: Archive Archive theme: Steward funding, WGCL compensation, TEC token compensation, operating budget, Sampo, financial sustainability, crisis planning, Conviction Voting
May 12, 2022
This thread proposed a second three-month funding cycle for the Stewards Working Group, covering May, June, and July 2022. The proposal followed the previous February-to-April funding cycle and continued the basic purpose of compensating active Stewards and Working Group Coordination Leads for transversal coordination work across TEC.
The proposal clarified that the budget was not meant to compensate all work inside individual working groups. Instead, it covered the additional labor of staying informed across TEC’s many working groups, attending coordination calls, surfacing interdependencies, representing TEC externally, preserving organizational knowledge, and keeping the community aligned with its mission, vision, and values. Stewards and coordination leads were expected to remain active, and inactivity could lead to self-offboarding or offboarding under the Stewards’ Manifesto process.
The major design change was that this cycle would compensate Stewards and coordination leads in TEC tokens rather than xDAI. The proposal argued that paying in TEC would increase governance weight for contributors who held the token, create buy demand for TEC itself, and help the community discover the practical challenges of contributor compensation in TEC. The Stewards multisig would hold xDAI, convert the needed monthly compensation into TEC, and distribute that TEC to eligible contributors.
The requested amount was 48,750 xDAI for three months. The budget included 20,250 for Working Group Coordination Lead compensation, 22,500 for Steward compensation, and 6,000 for special projects and bounties. Compensation remained cumulative for people holding both Steward and coordination-lead responsibilities. Monthly progress sharing would remain simple: each person would post their role and work performed, objections would first be mediated internally, and unresolved issues could be escalated to Gravity.
May 12 to May 17, 2022
Discussion focused first on the mechanics and risks of converting xDAI into TEC. Questions included how to protect contributors from bad timing around TEC price fluctuations, whether the multisig would buy through the bonding curve or secondary markets, whether conversions would happen all at once or person by person, and how tributes or slippage would affect the final amounts. The response clarified that conversion would happen shortly before distribution, likely through secondary markets, and that the tribute or slippage issue would need to be factored into the process.
The thread then widened into longer-term sustainability. A participant asked whether TEC was addressing long-term budget planning, Common Pool sustainability, viable business models, crisis planning, and how the community wanted to allocate funding across operations, research and development, and other buckets. The response pointed to Sampo as the newly forming working group focused specifically on TEC financial sustainability and acknowledged that crisis planning would be pragmatic.
The conversation connected the Stewards funding proposal to broader governance infrastructure. Emergency-planning examples from Yearn were shared, and the discussion turned toward how TEC could steer a Conviction Voting-based spending process as the Common Pool shrank and proposal passage became harder. Ideas included capacity building, osmotic funding, mechanism-design brainstorming, and treating financial sustainability work as a learning opportunity for the broader token engineering knowledge commons.
June 6, 2022
A later follow-up argued that stewarding, health signaling, and “picking up the slack” require some baseline of care and compensation. The discussion also linked TEC’s internal sustainability issues to larger questions about how commons-based organizations move from market competition toward collaborative commons. The thread suggested that improving proposal engines, funding flows, and sustainability mechanisms could itself become a valuable token engineering contribution.
By the end of the thread, the Stewards funding proposal had become more than a recurring operating-budget request. It connected compensation in TEC tokens, contributor governance weight, secondary-market liquidity, Common Pool sustainability, Sampo’s formation, crisis planning, Conviction Voting limits, stewardship care, and the broader challenge of building compensation systems that support a collaborative commons without losing its mission.
2022-05-12 to 2022-05-14 — Transparency Around TEC Salaries
Forum thread: Transparency around TEC salaries Category: Advice Process / Archive Archive theme: salary transparency, common pool spending, contributor compensation, Transparency Audit, mutual monitoring, cultural Snapshot, accountability
May 12, 2022
This Advice Process thread opened a discussion about whether TEC should track and publish salary-like compensation paid from the Common Pool. The proposal emerged from the Rewards Budget Distribution discussion, where questions had surfaced about how transparent TEC should be when contributors or working groups receive recurring compensation.
The suggested approach was to create a separate document that could be updated monthly and incorporated into the Transparency Audit. The scope was deliberately limited to money coming from the TEC Common Pool and to proposals or work systems where contributor-level payment information could be tracked. The post clarified that this would not automatically apply to every Token Engineering Academy proposal, since those were being tracked by milestones rather than by individual compensation.
The proposal argued that salary transparency would require rewards distributions to be connected to recognizable contributor identities, so the community could mutually monitor compensation and workload distribution. The intended next step was a cultural Snapshot after completing the advice process. The post framed the change as potentially awkward at first, but useful for preventing larger conflicts later.
May 12 to May 14, 2022
Follow-up discussion strongly supported the general direction. One response framed salary transparency as a way to improve mutual monitoring of workload and compensation. Another emphasized that money coming directly from the Common Pool should be visible at a more granular level, because transparency can become a form of accountability when the community is trying to understand its total spending.
The discussion acknowledged that publishing compensation information could create discomfort, but treated that discomfort as manageable compared with the risks of opacity. As TEC moved into more regular post-upgrade funding and contributor-payment systems, the thread positioned compensation transparency as part of the community’s broader financial governance infrastructure.
By the end of the thread, the question had shifted from whether TEC should have financial transparency in general to how deep that transparency should go. The thread connected salaries, rewards, Common Pool spending, contributor identity, the Transparency Audit, cultural Snapshot governance, and the community’s ability to evaluate whether work and compensation were being distributed fairly.
2022-05-16 — TEC Rewards Distribution: August 2021
Forum thread: TEC Rewards Distribution - August 2021 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, August 2021 praise debt, TEC token rewards, community review
May 16, 2022
This Rewards Distribution thread published the next retroactive TEC Rewards distribution, covering Praise given between July 31 and August 31, 2021. Like the prior July 2021 distribution, it continued the process of paying down earlier Praise-based contribution recognition after the Reward System had become operational.
The Reward Board allocated 4,154 TEC tokens for this period. The distribution used a 100 percent Praise and 0 percent SourceCred split, keeping SourceCred out of this retroactive round and assigning the full reward allocation through Praise. The post noted that some Praise accounts still had not been activated, so the published distribution total could be lower than the amount originally set aside.
The allocation structure matched the standard Rewards framework: 90 percent of tokens were distributed as Praise rewards to contributors, 7 percent were distributed among quantifiers, and 3 percent were assigned to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and accompanied by a full period analysis.
The thread also stated that the post would remain open for community review for forty-eight hours before final execution by the Reward Board. By the end of the thread, the August 2021 distribution had been presented as another formal step in TEC’s retroactive Rewards process, connecting Praise scoring, quantifier review, Reward Board oversight, account activation, community review windows, and on-chain distribution execution.
2022-05-16 — TEC Working Groups Weekly Update, May 9 to May 16
Forum thread: TEC WGs Weekly Update: May 9 - 16 Category: Community Updates Archive theme: working group updates, Sampo strategy, salary transparency, TEC Rewards distribution, TE Fundamentals, Graviton training, legal services, Tokenomics DAO, Commons Prize
May 16, 2022
This Community Updates post summarized TEC working group activity from May 9 to May 16. Stewards reported that Sprint 34 had ended and Sprint 35 had begun. Three funding votes remained open in the Gardens for cadCAD Community Funding, retroactive funding for TEC at ETHDenver 2022, and the Comms animation and video production T.E.A.M. A TAO vote was also open to update buy and sell fees to 10 percent and 8 percent.
The update showed TEC continuing to move from post-launch stabilization into more structured strategy work. Stewards identified contact with Tokenomics DAO as the retrospective action item, pointed to the Stewards Working Group funding proposal in advice process, and highlighted the Commons Prize voting round. Gravity prepared for the third Graviton Training, maintained its coordination call, book club, psychology and mental health research sync, and conflict-support request pathway, while also reporting an Aragon conflict-management AMA.
Soft Gov emphasized Praise practice, especially the need to type Praise rather than rely on transcription, while also reassessing mission alignment, boundaries, ecosystem health metrics, and the newly launched Sampo Working Group. Sampo itself had prepared a nine-page strategy document and established its meeting rhythm, signaling a growing focus on financial strategy and revenue development.
Communitas reported that the Discord had reached 2,300 members and that more than 500 had been personally welcomed. It also worked on its next funding proposal, continued developing the TEC Engagement Process workflow, and created a new Orientation Deck. 0mega continued work on the Dynamic Energy Budget, behavioral modeling around community variables, and collective curation as a way to support co-creation and emerging fields of energy.
Labs continued Proposal Inverter DAO-to-DAO workshops, discussed a technical TEC Token Engineering Fellowship, promoted office hours with Longtail Financial and BlockScience, kept TE Fundamentals pre-registration open, and looked for proposal contributors for TEC Lab. Comms reported that its animation and video funding proposal was live, continued TE Academy community spotlight planning, promoted TE Fundamentals and Graviton training, managed TE Tuesdays, developed video production, resumed translations planning, and prepared both a regular newsletter and a special Transparency audit newsletter.
Transparency reported that it had authored the salary-transparency forum post and that a special newsletter would showcase the latest audit results. Legal continued work on content ownership and Covenant updates while also considering whether it could offer legal services to other DAOs in exchange for TEC, potentially evolving into a Legal Guild or a coordination point for DAO legal expertise. Rewards reported that quantification round ten had finished, the first Reward Distribution had happened, quantifier recruitment was being encouraged as a civic duty, Praise activation remained open through Discord, and a Quantifier Onboarding video was in production.
By the end of the update, TEC’s mid-May operations were organized around several converging themes: active funding votes, fee-parameter governance, salary and audit transparency, the first Rewards distribution, Sampo financial strategy, possible legal-service revenue, education programming through TE Fundamentals and Graviton training, and continued efforts to turn onboarding, Praise, and working group coordination into repeatable systems.
2022-05-23 to 2022-05-26 — TEC Rewards Distribution: September 2021
Forum thread: TEC Rewards Distribution - September 2021 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, September 2021 praise debt, data accuracy, mutual monitoring
May 23, 2022
This Rewards Distribution thread published the retroactive rewards round for Praise given between September 1 and September 30, 2021. The Reward Board allocated 4,020 TEC tokens for the period, again using a 100 percent Praise and 0 percent SourceCred split. As with prior retroactive distributions, the post noted that some Praise accounts had not yet been activated, so the total amount ultimately distributed could be lower than the total allocation.
The distribution followed the same Rewards allocation structure used in earlier rounds: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and accompanied by a full period analysis. The post also left the distribution open for a forty-eight-hour community review period before final execution.
Unlike earlier distribution posts that used wallet-address tables, this round published a username-based distribution table. The table also included several rows labeled as missing username, which became the first point of follow-up discussion.
May 23 to May 24, 2022
A follow-up question asked whether the missing-username rows were intentional. The explanation was that these rows corresponded to Reward Board members who had chosen to receive Reward Board rewards in a different wallet than the one they used for Praise rewards. The post was edited to clarify this point and to identify the relevant Reward Board rows.
This clarification showed that even when the reward calculation itself was ready, presentation and identity-linking issues still mattered. The rewards process needed not only token amounts but also clear contributor records, consistent wallet use, and readable public documentation.
May 24 to May 26, 2022
The thread then shifted into a deeper critique of data quality. One response argued that the community should focus more directly on analysis and data accuracy, since publishing a dashboard was not enough to make the tool suitable for rewarding people. The critique pointed to surprising relative rankings in the September data and argued that each iteration should be treated as a learning opportunity to improve Praise rather than simply posted as a final output.
A later response contextualized the problems. The September 2021 Praise data came from a period when Praise quality was often low, many Praise items were transcribed or lacked context, the quantification process was still under active development, the quantifier pool included many newer quantifiers, and many people who remembered the September work were no longer active in TEC or in quantification. The response also noted that SourceCred was not included in this round, so the Praise-only distribution did not capture all forms of contribution that might later be rewarded through forum and GitHub activity.
By the end of the thread, the September 2021 distribution had become more than another retroactive payout. It surfaced unresolved issues around identity records, wallet consistency, Praise quality, historical context, quantifier onboarding, dashboard usability, SourceCred exclusion, and the need for mutual monitoring and advice-process feedback before the Rewards system could be treated as a mature compensation mechanism.
2022-05-24 to 2022-06-24 — Advice on the Sampo Strategy
Forum thread: Your advice on the Sampo strategy Category: Advice Process / Archive Archive theme: Sampo strategy, economic development, capital formation, financial sustainability, token demand, capacity building, TEC micro-economy, Pol.is feedback
May 24, 2022
This Advice Process thread opened community feedback on the Sampo Working Group’s high-level strategy. The post explained that the strategy had already received initial working group input and had been presented to the Stewards Council, but now needed broader community review. A Pol.is survey was included so the community could test the level of agreement or disagreement around key ideas in the strategy.
The strategy framed TEC as a micro-economy developing over many years. It described three phases: economic security, economic momentum, and economic abundance. In the security phase, TEC would reduce risk and make careful capacity-building investments. In the momentum phase, services would begin generating value, revenue, and demand for TEC. In the abundance phase, TEC would accumulate community wealth and expand funding for external work aligned with its mission.
The strategy also used a capital-formation lens. It identified cultural, financial, social, and expertise capital as the four key forms of capital inside TEC. Cultural capital was described as TEC’s strongest current lever, financial capital as the finite medium for capacity building, social capital as the network of relationships with builders, governors, and future users, and expertise capital as the long-term resource TEC ultimately needed to cultivate and deliver.
The proposed theory of change was that TEC should leverage its cultural capital to attract new financial capital, conserve remaining financial capital, invest in capacity-building services, grow social and expertise capital, and eventually create services that produce revenue and demand for the TEC token. The post identified Token Engineering Academy partnership work and future Schelling Point Services as early priorities. It also argued that Conviction Voting proposals should be evaluated partly by whether they increase TEC’s capacity to build cultural, financial, social, or expertise capital.
May 25 to June 2, 2022
Early feedback strongly emphasized financial sustainability and token demand. One response argued that relying on market dynamics alone would not be enough and that TEC needed to actively sell the idea that buying TEC supports better token engineering. Suggested strategies included outreach to aligned organizations, Gitcoin-linked fundraising campaigns, and Wikipedia-style recurring support messaging.
Another response agreed that TEC needed more demand for the token and suggested that marketing, lobbying, added utility, and added users should all be pursued in coordinated ways. The discussion explored future parameter phases for the Augmented Bonding Curve, lowering friction as volume increased, price stability, staking, cross-held utilitarian assets, WATER-like partner treasury relationships, and whether TEC could design mechanisms that made holding TEC more attractive without losing its mission.
June 13 to June 24, 2022
Later feedback focused on milestones, impact, and clarity of mission. One response argued that achieving visible milestones toward a larger vision could itself increase interest and demand for TEC. Another suggested that sustainability should be framed in relation to impact: what the DAO is trying to achieve, how its mission and current objectives are made visible, and how TEC’s cultural advantage should show up in its public messaging.
The discussion also proposed a social sequence for DAO work: ideas, team formation, proposal, project, product, and data. This reframed capital formation as a process that begins with community sensemaking and only later becomes treasury allocation or financial product design. The final comments also suggested that TEC should survey members on what they think TEC is trying to do, and that the Augmented Bonding Curve might need clearer benefits-oriented language rather than only technical naming.
By the end of the thread, Sampo’s strategy had become a broad discussion about TEC’s economic identity. The thread connected micro-economic development, capital formation, financial runway, cultural advantage, token demand, fundraising, service design, staking and utility, Conviction Voting priorities, ABC positioning, mission clarity, and the need for community-wide feedback before TEC committed to a long-term sustainability strategy.
2022-05-30 — TEC Working Groups Weekly Update, May 23 to May 30
Forum thread: TEC WGs Weekly Update: May 23 - 30 Category: Community Updates Archive theme: working group updates, Sampo strategy, compensation expectations, Third Graviton Training, Commons Prize, treasury reporting, legal services, SourceCred activation
May 30, 2022
This Community Updates post summarized TEC working group activity from May 23 to May 30. Stewards reported that Sprint 35 had finished and Sprint 36 had begun. They encouraged voting on the Stewards funding proposal, retroactive funding for TEC at ETHDenver, and the Comms animation and video proposal. The sprint retrospective action item was to boost token holder and contributor confidence by outlining plans for what would come next. The update also noted that the Commons Prize had entered its final voting round, with several commons-oriented projects listed as finalists.
Gravity reported that the Third Graviton Training had started on May 24 and pointed readers to the study plan. It also maintained psychology and wellbeing research, Aragon umbrella coordination, Mental Health Awareness Month activity, Commons Prize participation, and its conflict-support request pathway. Soft Gov continued deeper conversations about compensation in TEC, including role rotation, accountability, and a “museum of unfinished ideas.” It also reported collaboration with 0mega on a workshop draft and continued work on the TE Governance Guild.
Communitas worked on writer’s guild needs and processes in relation to possible funding, continued developing the TEC Engagement Process workflow, and promoted its new Orientation Deck. Sampo published a clearer mission statement focused on developing and growing the value of TEC’s economic layer, aligning TEC’s micro-economy with the mission and with token-holder and contributor benefit. Its early work included a unified treasury report, a working group manifesto, feedback on a funding proposal, budgeting and spending coordination with Stewards, and defining income-producing TEC services.
0mega focused on the TE Consilience Library and invited contributors to curate resources and join the Imaginarium Creative call. Labs reported a hiatus while rethinking how to operate in a more seasonal way. Comms reported that the animation proposal was close to passing, that TE Academy had a proposal coming soon, that the animation and video team was working on character design for the quantifier tutorial, and that translation, marketing, and Twitter planning continued.
Transparency researched data standardization to scale its work, continued development of the ABC advanced page, and pointed to the salary-transparency discussion. Legal issued an open call for legal experts, continued content ownership and Covenant work, and again explored whether legal services could be offered to other DAOs in exchange for TEC, potentially turning Legal into a guild or coordination point for DAO legal expertise. Rewards reported that quantification round eleven had finished, September 2021 rewards were incoming, SourceCred activation was being brainstormed, and Praise categorization by working group was underway.
By the end of the update, TEC’s late-May operating picture centered on confidence-building and system maturation: compensation expectations, Sampo’s economic strategy, treasury reporting, legal-service revenue, SourceCred activation, Praise categorization, data standardization, contributor onboarding, and the continued transition from scattered working group activity into more explicit plans for sustainability.
2022-05-30 — Transparency WG Funding Proposal: May to July 2022
Forum thread: Transparency WG Funding Proposal (May to July 2022) Category: Advice Process / Archive Archive theme: Transparency WG, funding proposal, transparency audit, salary tracking, Sampo coordination, operational documentation, Common Pool accountability
May 30, 2022
This Advice Process thread proposed three months of funding for the Transparency Working Group covering May through July 2022. The proposal framed Transparency’s work as ongoing operational infrastructure for TEC, including call recording, the Transparency Audit, documentation, and other operations-related tasks. It also noted that new initiatives could add work if they passed, especially salary tracking and coordination with the Sampo Working Group.
The working group calculated a total three-month contributor compensation need of 16,140, but because it still had 5,601.25 WXDAI unused from the prior February-to-April budget, the proposal requested 10,538.75 XDAI through conviction voting. The proposed budget was to be divided among the working group’s contributors, with prior spending records, the previous funding thread, and the existing Transparency Audit offered as references for accountability.
The proposal argued that funding Transparency would help the community uphold transparency, monitor activity, and provide equal access to information. It linked transparency work to self-governance: if the community can observe behavior through shared frameworks, it can reduce reliance on external agents and increase participant commitment to advice-process governance.
Progress reporting was planned through the same method used previously: contributors would request funds through the proposal, work would be tracked in a shared document, and milestones would be included in the second Transparency Audit report. By the end of the thread, Transparency’s funding request connected routine documentation work with broader governance needs around salary visibility, Sampo financial coordination, audit continuity, and accountable Common Pool spending.
2022-05-30 — TEC Rewards Distribution: October 2021
Forum thread: TEC Rewards Distribution - October 2021 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, October 2021 praise debt, username records, community review
May 30, 2022
This Rewards Distribution thread published the retroactive rewards round for Praise given between September 30 and October 28, 2021. The Reward Board allocated 4,154 TEC tokens for the period and again used a 100 percent Praise and 0 percent SourceCred split. As in prior rounds, the post noted that inactive Praise accounts meant the final distributed total could be lower than the amount set aside.
The distribution followed the established Rewards allocation framework: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and linked to a full period analysis. The post also left the distribution open to the community for a forty-eight-hour review period before final execution.
The published table listed usernames and TEC amounts rather than wallet addresses. As in the September distribution, the table contained three rows marked as missing username, with a note explaining that these corresponded to Reward Board members who chose to receive Reward Board rewards in a different wallet than the one used for Praise rewards.
Follow-up comments were light and celebratory rather than substantive. By the end of the thread, the October 2021 distribution had continued the retroactive Rewards sequence while reinforcing several operational patterns: Praise-only allocations for historic periods, public review windows, quantifier and Reward Board oversight, username-based reporting, and explicit notes about identity or wallet mismatches in the distribution data.
2022-06-06 — TEC Working Groups Weekly Update, May 30 to June 6
Forum thread: TEC WGs Weekly Update: May 30 - June 6 Category: Community Updates Archive theme: working group updates, Stewards funding, Sampo services, SourceCred activation, Transparency funding, ABC advanced page, TE Governance Guild, Rewards naming
June 6, 2022
This Community Updates post summarized TEC working group activity from May 30 to June 6. Stewards reported that Sprint 36 was underway and that the biweekly Stewards Council had discussed how to boost token-holder and contributor confidence with a clearer outline of what was coming next. The Stewards funding proposal had not passed, prompting the group to rethink how it could provide the most service to the community, evolve its manifesto, and revise the corresponding funding request.
Gravity continued the Third Graviton Training, with the next session focused on trauma-sensitive and anti-oppressive culture. It also maintained psychology and wellbeing research, Aragon umbrella coordination, website design work, and its conflict-support request pathway. Soft Gov held a first joint call with 0mega to examine TEC’s place in the community and to identify proactive actions for addressing energy-giving and energy-receiving imbalances. It also planned a TE Flower session and moved the TE Governance Guild toward DAO metrics as a likely next project.
Communitas promoted its funding proposal, continued the TEC Engagement Process workflow and Orientation Deck, and joined Soft Gov in the TE Flower mapping exercise. Sampo reported that its first funding proposal had been posted, that it was preparing communications to TEC token holders about recent activity and the year ahead, and that it was defining an initial TEC service around token engineering consulting. It also explored a fundraising campaign built around a Token Engineering Hall of Fame NFT campaign.
0mega continued collaborating with Soft Gov on energy flows, incentives, contributions, and motivations within TEC, while also developing the TE Consilience Library and inviting resource curation. Labs remained on hiatus while reconsidering a more seasonal model. Comms reported that the animation proposal had passed, that TE Academy had a proposal coming soon, that the animation and video team was working on the Rewards System tutorial, that the newsletter and translations teams were moving forward, and that Twitter planning included a new collective bio.
Transparency continued work on data standardization and templates, Dune updates, the ABC advanced page, salary transparency, CoinGecko listing attempts, and its live funding proposal. Legal continued calling for legal experts and worked on the content ownership agreement and Covenant updates. Rewards reported that quantification round twelve was open, October 2021 rewards were incoming, the FAQ was live, a SourceCred activation initiative was starting, and the community was discussing what to name the Rewards System.
By the end of the update, TEC’s first week of June showed the organization trying to regain confidence after a failed Stewards funding vote while simultaneously maturing its financial, educational, legal, transparency, and rewards systems. The main themes were service to the community, token-holder communications, Sampo revenue strategy, SourceCred activation, ABC transparency tooling, data standardization, and the search for a more sustainable operating model.
2022-06-06 to 2022-10-26 — Retroactive Funding for Swag Shop Expenses: Hatch and EthCC 2021
Forum thread: Retroactive Funding for Swag Shop expenses (Hatch and EthCC 2021) Category: Conviction Voting / Archive Archive theme: Retroactive funding, swag shop expenses, Hatch outreach, EthCC 2021, reimbursement, marketing expenses, Common Pool process
June 6, 2022
A retroactive funding proposal was opened to reimburse swag shop expenses that had been paid personally before and around the TEC Hatch and EthCC 2021. The proposal explained that TEC-related swag had been purchased with a personal credit card and requested reimbursement from the Commons.
The expenses were separated into two categories. The first covered Hatch-related TEC swag orders from June 2021 through February 2022. These included eighty-six orders, with the largest spending month occurring in August 2021. The second covered EthCC Paris expenses from July 2021. Together, the Hatch swag and EthCC costs totaled 7,722.88 wxDAI, which became the amount requested through Conviction Voting.
The proposal framed swag as a community-building and visibility tool. TEC shirts and related materials were described as a way for members to represent the Commons publicly, strengthen shared identity, and make TEC visible to the wider ecosystem. In that sense, the request was not only about reimbursing merchandise expenses, but about recognizing an earlier outreach and marketing effort connected to the Hatch period.
October 7, 2022
The thread was later revived with a more reflective response about reimbursement proposals. The discussion acknowledged that the expenses had remained unresolved for a long time and that, under current conditions, the community might not make the same spending decisions again. At the same time, the response supported partial approval because the expenses had already been personally carried and because the situation belonged to an earlier stage of the Commons.
This opened a broader governance concern: reimbursement proposals can make Conviction Voting feel personal because the community is no longer deciding whether an expense should happen, but whether someone should be repaid after the fact. The thread therefore raised the need for clearer proposal guidelines and a stronger preference for approving spending decisions before money is spent, especially when the Common Pool is involved.
October 26, 2022
A final clarification placed the expenses in their original context. The costs had occurred before the Common Pool existed, making them a special case rather than a normal operating pattern. The swag and EthCC spending was described as part of the Hatch marketing effort, with the expectation that it helped attract attention and contributions during the Hatch.
By the end of the thread, the proposal had become more than a reimbursement request. It documented an unresolved pre-Common-Pool expense from TEC’s launch period while also surfacing a governance lesson for the mature Commons: future spending should ideally be proposed and approved before costs are incurred, so that Conviction Voting remains a mechanism for collective budgeting rather than retroactive personal reimbursement.
2022-06-07 to 2022-10-26 — Retroactive Funding for Servers
Forum thread: Retroactive Funding for Servers Category: Conviction Voting / Archive Archive theme: Retroactive funding, server costs, infrastructure reimbursement, forum hosting, Praisebot, operational expenses
June 7, 2022
A retroactive funding proposal was opened to reimburse server costs that had been paid personally in order to keep TEC infrastructure running. The request covered server charges from October 2020 through May 2022, with the total reimbursement amount set at 142 wxDAI.
The proposal identified two Digital Ocean server expenses. One server supported TEC bots, including infrastructure associated with Praisebot, and had been active since November 2021. The other supported the TEC Discourse forum and had been active since October 2020. The forum server represented the larger expense because it had been running for a longer period.
The proposal framed these costs as critical infrastructure expenses rather than discretionary spending. The TEC forum was described as a core space for research, governance, and community memory, while the bot infrastructure was connected to the community’s ongoing contribution-recognition experiments. The main purpose of the thread was therefore straightforward: reimburse personally covered costs for infrastructure that had been serving the Commons.
A reply supported quick approval and raised a broader operational question. Instead of relying on personal credit cards for recurring infrastructure expenses, the community discussed whether TEC could use a prepaid business card or similar arrangement to pay for services directly. This shifted part of the discussion from a one-time reimbursement into a recurring operations problem: how should a DAO pay for ordinary Web2 infrastructure when many hosting services still rely on conventional payment rails?
June 23, 2022
The discussion continued by considering alternatives to personal payment accounts. The idea of finding a reliable hosting provider that accepted crypto was raised as a simpler path than trying to route traditional server payments through personal cards or prepaid card services. The thread briefly pointed to the difficulty of paying for mainstream cloud infrastructure with crypto, reinforcing the operational gap between DAO treasury assets and conventional service providers.
September 20 to October 26, 2022
A later question asked whether the reimbursement would not happen if the proposal failed. The answer confirmed that reimbursement depended on the proposal passing, but also clarified that the proposal had gone through.
By the end of the thread, the reimbursement itself had been resolved, but the discussion captured a recurring DAO operations challenge. TEC needed ordinary infrastructure such as servers, forums, and bots, yet the practical payment process still depended on individuals bridging between the DAO and traditional service providers. The thread documented both the reimbursement of past costs and the need for better payment infrastructure for future recurring expenses.
2022-06-08 — TEC Rewards Distribution: November 2021
Forum thread: TEC Rewards Distribution - November 2021 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, November 2021 praise debt, top contributions, community review
June 8, 2022
This Rewards Distribution thread published the retroactive rewards round for Praise given between October 31 and November 27, 2021. The Reward Board allocated 4,020 TEC tokens for the period and maintained the 100 percent Praise and 0 percent SourceCred split used in the earlier retroactive distributions. As before, the post noted that inactive Praise accounts could make the final distributed amount lower than the allocation set aside.
The distribution followed the established framework: 90 percent of the allocation went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and linked to a full period analysis. The post also left the distribution open for a forty-eight-hour community review period before final execution.
The published table listed usernames and TEC amounts, with a repeated note that three missing-username rows corresponded to Reward Board members who chose to receive those rewards in wallets different from the wallets used for Praise rewards. A follow-up comment added the ten highest-rated contributions for the round, giving the community a more qualitative view into which Praise items had driven the distribution.
By the end of the thread, the November 2021 round continued TEC’s retroactive Rewards rollout while adding more context around the highest-rated contributions. The thread connected Praise scoring, Reward Board oversight, quantifier review, username-based reporting, wallet mismatches, community review, and the gradual effort to make historical contributor recognition understandable rather than simply publishing a payout table.
2022-06-10 — TEC Working Groups Weekly Update, June 6 to June 13
Forum thread: TEC WGs Weekly Update: June 06 - 13 Category: Community Updates Archive theme: working group updates, Sampo treasury policy, salary Snapshot, SourceCred activation, TE Flower, Third Graviton Training, Commons Prize, praise dashboard
June 10, 2022
This Community Updates post summarized TEC working group activity for the week of June 6 to June 13. Stewards reported that Sprint 36 had closed and that the retrospective emphasized making a list of priorities and critical work. They were discussing Sampo’s forum thread, especially limits on spending, and reassessing what TEC truly needed after the prior Stewards funding proposal failed. The Commons Prize had ended, with Grassroots Economics Commons named as the winner.
Gravity continued the Third Graviton Training and prepared for a session on Nonviolent Communication. It also encouraged remaining participation for people seeking the POAPs needed to become mediators, maintained psychology and wellbeing research, continued Aragon umbrella coordination, promoted its grant, and kept the conflict-support request pathway active. Soft Gov worked through the TE Flower as a representation of TEC’s current structure and invited the community to help revise it so it more accurately reflected what TEC was doing.
Communitas updated pinned Discord messages, began thinking about an information inventory to locate missing or outdated information, updated its community-health outreach spreadsheet, and continued pointing to its funding proposal and Orientation Deck. Sampo reported that its first funding proposal was live in Conviction Voting, that it was discussing treasury management policy, and that it was preparing communications to keep TEC token holders interested and informed.
0mega continued work on the TE Consilience Library and resource curation. Labs remained on hiatus while reconsidering a more seasonal operating model. Comms highlighted the first animation from the animation and video production team, continued preparing a TE Academy proposal, sent Newsletter #3, moved translations toward Mirror publication, and supported Gitcoin Grants Round 14 through Twitter planning.
Transparency reported that the salary Snapshot vote was live, its funding proposal had passed, and work continued on the ABC advanced page. Legal continued its call for legal experts, content ownership agreement work, Covenant updates, and a transition to monthly calls. Rewards reported that quantification round twelve had closed, November 2021 rewards were incoming, the FAQ was live, the SourceCred activation campaign was coming soon, and the Praise dashboard had added multi-wallet support through Rainbow along with dark mode.
By the end of the update, TEC’s early-June work was focused on narrowing priorities, strengthening financial discipline, improving contributor and token-holder confidence, activating SourceCred, maturing the Praise dashboard, sustaining the Graviton training, and clarifying both TEC’s organizational shape and its public-facing communications.
2022-06-14 — TEC Rewards Distribution: December 2021
Forum thread: TEC Rewards Distribution - December 2021 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, December 2021 praise debt, Commons Upgrade work, top contributions
June 14, 2022
This Rewards Distribution thread published the retroactive rewards round for Praise given between November 28 and December 26, 2021. The Reward Board allocated 4,154 TEC tokens for the period and continued the 100 percent Praise and 0 percent SourceCred split used in the prior retroactive distributions. As in previous rounds, the post noted that inactive Praise accounts could make the final distributed total lower than the allocation set aside.
The distribution followed the established Rewards structure: 90 percent of tokens were allocated as Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and linked to a full period analysis. The post also remained open for a forty-eight-hour community review period before final execution.
The published table listed usernames and TEC amounts, again including three missing-username rows explained as Reward Board members using different wallets for Reward Board rewards than for Praise rewards. A follow-up comment listed the ten highest-rated contributions for the round. These were heavily centered on Commons Upgrade smart contract development, testing, tooling, and demo work, along with broader recognition for engineering ethics and public technical leadership.
By the end of the thread, the December 2021 distribution had documented a key historical contribution period immediately around the Commons Upgrade. The thread connected Praise-based retroactive rewards, Reward Board and quantifier oversight, public review, username-based payout reporting, missing-wallet notes, and qualitative recognition for the technical work that made the Commons Upgrade functional and secure.
2022-06-20 — TEC Working Groups Weekly Update, June 13 to June 20
Forum thread: TEC WGs Weekly Update: June 13 - June 20 Category: Community Updates Archive theme: working group updates, steward transformation, Sampo Season 1, token holder outreach, data standardization, SourceCred activation, TE Flower, Communitas accountability
June 20, 2022
This Community Updates post summarized TEC working group activity from June 13 to June 20. Stewards reported that Sprint 37 was ending and that they were transforming stewardship inside TEC. They had used a Polis poll and a rose-thorn-bud retrospective to evaluate what was working and what needed improvement, and decided not to request compensation for June, and possibly the summer, while the role and working group were being reworked.
Gravity continued the Third Graviton Training, with the next session focused on conflict transformation. It also maintained psychology and wellbeing research, Aragon umbrella coordination, a tailored training for the Aragon community, website design work, its grant, and the conflict-support request pathway. Soft Gov continued the TE Flower update and identified additional areas that should be represented, including identity and demography, linguistics, memetics, semantics, semiotics, and history.
Communitas reported that its most recent Orientation call had no attendance for the first time in nine months. It pointed to its funding proposal and accountability update, reviewed suggested ZenHub template changes, and discussed token-holder outreach improvements. Sampo reported that its Season 1 proposal had passed and that it was working on token-holder updates, treasury management, internal organization, and token-gating options for services that require holding TEC.
0mega shared updates through its workspace, prepared a wiki, changed its call structure to deepen member connections, and developed a game to support building the TE Consilience Library. Labs remained on hiatus while considering a more seasonal model. Comms prepared a TE Academy proposal, continued Rewards System animation work, focused marketing on the mintTEC campaign, published the first translations on Mirror, and kept working on a new Twitter bio.
Transparency reported that the salary Snapshot vote had passed, that data standardization was nearly complete, and that the ABC advanced page was still in development. Legal continued its call for legal experts. Rewards reported that quantification round thirteen was open, December 2021 rewards were incoming, the FAQ was live, the quantifier robot design was progressing, SourceCred activation instructions were being shared, and a post about improving the Rewards System was highlighted.
By the end of the update, TEC’s mid-June operating work was centered on steward-role transformation, salary-transparency approval, Sampo’s first season, token-holder outreach, data standardization, SourceCred activation, Rewards improvement, and the ongoing effort to clarify TEC’s organizational identity through the TE Flower and related community-mapping exercises.
2022-06-20 — TEC Rewards Distribution: January 2022
Forum thread: TEC Rewards Distribution - January 2022 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, January 2022 praise debt, Commons Upgrade, onboarding and bot work
June 20, 2022
This Rewards Distribution thread published the retroactive rewards round for Praise given between December 27, 2021 and January 30, 2022. The Reward Board allocated 4,154 TEC tokens for the period and continued using the 100 percent Praise and 0 percent SourceCred split. As with prior distributions, the post noted that inactive Praise accounts could make the final distributed total lower than the amount set aside.
The allocation followed the standard Rewards structure: 90 percent went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and linked to the full period analysis. The post remained open for forty-eight hours of community review before final execution.
The username-based distribution table again included three missing-username rows, explained as Reward Board members using different wallets for Reward Board rewards than for Praise rewards. A follow-up comment listed the ten highest-rated contributions for the round, which emphasized Discord onboarding upgrades, Praise bot and data work, Hatch and Commons Upgrade launch preparation, parameter work, the first quantification process, and Rewards dashboard development.
By the end of the thread, the January 2022 distribution had captured the contribution period around TEC’s Commons Upgrade and the first operational month of the post-upgrade Rewards system. It connected Praise-based payouts, quantifier coordination, onboarding infrastructure, bot development, Commons Upgrade execution, Reward Board oversight, and the continued publication of qualitative top-contribution context alongside reward amounts.
2022-06-21 to 2022-07-04 — Proposal for Comms Stewardship
Forum thread: Proposal for Comms Stewardship Category: Conviction Voting / Archive Archive theme: Comms stewardship, working group coordination, T.E.A.M.s, TE Academy communications, funding proposal, contributor onboarding, role rotation
June 21, 2022
This Conviction Voting thread opened with a request to fund Comms stewardship for five months, from June through November. The proposal explained that Comms had developed T.E.A.M.s as a way to organize contributors and that the stewardship role had become important for onboarding, coordination, and supporting contributor initiatives inside the working group.
The post acknowledged the broader community discussion about whether stewardship should remain a compensated role, but framed this request as a circumstantial bridge rather than a permanent claim. The funding request was 1,200 wxDAI per month for five months, paired with an open commitment to explore rotation around the working group coordination lead role so Comms could reduce dependence on one person while preserving coordination capacity.
July 4, 2022
A follow-up expanded the thread into support for the TE Academy T.E.A.M. proposal for Q3 and Q4 2022. This update described the T.E.A.M.s project as a way to empower creatives in the token engineering field to provide communications services to different projects. It argued that the TE Academy communications group had demonstrated progress through community management, content planning, event presence, design support, and closer alignment between TEC and TE Academy.
The proposed next stage reinforced two earlier objectives: referring TE Academy attendees into TEC courses and contribution pathways, and strengthening internal communications through regular syncs. The new proposal was framed as a resource-optimized plan adapted to market and TEC conditions, with TE Academy contributing part of the budget directly and TEC being asked to complement that support. The total requested amount for the TEC side was 13,720 wxDAI, including monthly contributor support and a one-time merchandise budget.
By the end of the thread, the Comms stewardship request had become part of a broader discussion about how TEC should fund communications coordination, rotate stewardship responsibilities, sustain contributor onboarding, support TE Academy partnership work, and formalize T.E.A.M.s as service-oriented contributor groups under tighter budget conditions.
2022-06-23 to 2022-12-15 — Reduce Rewards for Regular Paid Contributors
Forum thread: Reduce Rewards for Regular Paid Contributors Category: Advice Process / Archive Archive theme: Praise rewards, paid contributors, unpaid contributors, contributor factor, governance power, rewards redistribution, voluntary contribution incentives, dynamic reward tuning
June 23, 2022
An advice process thread was opened to propose reducing Praise rewards for regular paid contributors and redistributing the difference to unpaid contributors. The proposal introduced a “contributor factor” that would be applied at the end of the rewards calculation to people marked as paid contributors. The reduced amount would then be redistributed to people who were not marked as paid contributors.
The initial design was intentionally simple. Paid contributors would receive a percentage of their otherwise calculated Praise rewards, proposed at 65 percent, and the excess would be distributed as a bonus to unpaid contributors. The post acknowledged that this was not a perfectly robust system because every unpaid contributor would receive the same kind of bonus regardless of contribution size, but it was presented as a workable “Robin Hood” adjustment that could reduce the gap between top and bottom recipients.
The proposal emphasized that the modification should happen at the final reward-distribution stage rather than earlier in the Praise system. This distinction mattered because the goal was to adjust token rewards, not erase or reduce the reputational recognition reflected in Praise. A simulation spreadsheet was shared so the community could test how the contributor factor would affect earlier rewards rounds.
June 24 to June 30, 2022
The discussion quickly surfaced several tensions. Supporters saw the proposal as a way to make rewards more inclusive, give more TEC to people outside the regular paid contributor group, and potentially increase governance participation by newer or more peripheral contributors. The central problem statement became that a large share of rewards appeared to be going to people who were already compensated through working group budgets or other paid roles.
Concerns focused on fairness, definitions, governance power, and unintended consequences. One concern came from TEC’s earlier Praisemageddon experience: reducing TEC rewards could also reduce governance power because TEC served both monetary and governance functions. Others asked how “already getting paid” would be defined, whether it should include payments from TEC only or also related organizations, whether bounties counted, and whether the same reduction should apply equally to people with very different levels of compensation.
Another concern was cultural. Praise was not only a payment system; it was a gratitude system. Changing rewards for paid contributors could discourage people from praising valuable work or undermine the positive social function of recognition. Some argued that the system needed more data and a clearer success metric before changing such a central part of TEC’s contribution economy. Others worried that reducing rewards for the remaining committed contributors during a lean budget period could weaken motivation without meaningfully attracting newcomers.
Alternative ideas were also raised. These included creating a separate non-monetary or high-supply reward token, improving how Praise captured smaller or unpaid contributions, or designing a more holistic engagement strategy rather than redistributing rewards away from the people doing the most visible work. By the end of the initial discussion, the idea had support in principle but no consensus on implementation.
December 4 to December 5, 2022
The thread was revived months later with renewed interest in giving volunteers a multiplier for their contributions. The discussion connected the proposal to the Coordination Team transition, where TEC was trying to distinguish paid operational work from voluntary contributions that still needed recognition. Praise was framed as especially important for work that fell outside budgeted wages, because TEC could not put everyone on payroll but still needed ways to recognize and encourage participation.
The proposal was revised from a flat unpaid-contributor bonus into a more proportional redistribution model. Instead of giving the same bonus to all unpaid contributors, the updated design redistributed the subtracted rewards among unpaid contributors in proportion to their existing Praise rewards. This meant unpaid contributors who had received more Praise would receive more of the bonus, creating a weighted solution rather than an equal split.
The discussion then moved toward a key design question: whether the system should reduce paid contributors directly or instead apply a bonus to non-contributors and normalize the result within the fixed rewards pool. This reframing mattered because the latter model changed the optics from “cutting paid contributors” to “boosting unpaid contributors,” while still redistributing relative rewards within the same total distribution.
December 7 to December 15, 2022
A new version of the model applied bonus factors to non-contributors rather than directly subtracting from paid contributors. The total would then be normalized back into the rewards amount available for the round. This approach preserved the overall distribution budget while increasing the relative share of people not receiving regular paid compensation. The community considered implementing a version of the model for Quant 24.
The discussion then explored whether contributor status should be tiered. Because not all paid contributors worked the same number of hours, a binary contributor versus non-contributor distinction seemed too blunt. A tiered model was introduced, classifying contributors by weekly hours worked and applying different factors by tier. This allowed the system to distinguish heavier paid contributors from part-time or casual contributors.
Another data-driven approach was considered using outgoing payments from TEC multisigs to create a sliding scale based on recent compensation. That approach was ultimately seen as too complex for the immediate need because payments could come from different wallets, contributors sometimes used separate wallets for Praise and finances, and TEC did not yet have consistent payment standards. The group rallied around the simpler tiered model as a more practical implementation path.
By the end of the thread, the original proposal had evolved significantly. It began as a direct reduction to paid contributors’ Praise rewards and became a more nuanced system for applying variable bonuses based on contributor status and weekly paid hours, then normalizing the results within the existing rewards pool. The thread captured TEC’s attempt to rebalance rewards toward voluntary and undercompensated contribution without damaging Praise culture, governance power, or motivation among core contributors.
2022-06-23 to 2022-07-01 — Feedback for Gardens and CV Governance
Forum thread: Feedback for Gardens and CV governance Category: Community Updates Archive theme: Gardens V2, Conviction Voting, UI feedback, proposal lifecycle, Celeste, governance reputation, quadratic voting, Sybil resistance
June 23, 2022
This Community Updates thread opened a request for feedback on TEC’s experience using Gardens and Conviction Voting. The post noted that the 1Hive team was beginning to collect feedback for Gardens V2 and invited TEC contributors to bring their lived governance experience into that design process.
The initial questions focused on usability and governance comfort: whether Gardens felt intuitive to navigate, what UI improvements were needed, whether contributors would feel comfortable using Celeste, and what features would help proposal management and voting culture. Early examples included adding a proposal time-limit parameter so proposals that never gathered enough conviction would eventually disappear, supporting ERC1155-style flexibility through combinations of tokens, and creating an easy-to-access FAQ.
June 26 to July 1, 2022
A follow-up suggestion explored a second, parallel governance or reputation token that would be issued alongside TEC but decay over time if holders stopped participating. The proposal framed this as a way to preserve financial investment while slowly returning inactive governance influence to the active community, creating a non-monetary mechanism for rewarding participation and encouraging large holders to remain engaged.
Another follow-up raised quadratic voting as an important area for Gardens and Conviction Voting improvement. The comment noted that Sybil resistance remained a central obstacle, but suggested that external fraud-detection expertise could help if the blockage was not inherent to Gardens itself.
By the end of the thread, the feedback request had turned TEC’s practical experience with Gardens into a set of product and governance-design needs: clearer interfaces, better proposal lifecycle controls, more accessible documentation, stronger token-compatibility options, active-participation incentives, reputation decay concepts, quadratic voting, and credible Sybil-resistance pathways for future governance experiments.
2022-06-27 to 2022-06-28 — TEC Rewards Distribution: February 2022
Forum thread: TEC Rewards Distribution - February 2022 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, February 2022 praise debt, ETHDenver, Proposal Inverter, TE Academy, design and events
June 27, 2022
This Rewards Distribution thread published the retroactive rewards round for Praise given between January 31, 2022 and February 27, 2022. The Reward Board allocated 3,752 TEC tokens for the period and continued using the 100 percent Praise and 0 percent SourceCred split. As in prior rounds, the post noted that some Praise accounts had not yet been activated, so the final distributed amount could be lower than the amount set aside.
The allocation followed the established Rewards structure: 90 percent went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and linked to the full-period analysis. The post was opened for forty-eight hours of community review before final execution.
The distribution table again included three missing-username rows, explained as Reward Board members using different wallets for Reward Board rewards than for Praise rewards. A follow-up comment listed the ten highest-rated contributions for the round, highlighting ETHDenver representation, DAO event coordination, TE Academy development, Praise spreadsheet export work, open-source software, Proposal Inverter education, stewardship education, Rewards Systems teaching, and design work.
June 28, 2022
A short response appreciated the qualitative contribution summary, noting that it complemented the numerical distribution. This reinforced the practice of pairing token amounts with contextual descriptions of what contributors had actually done.
By the end of the thread, the February 2022 distribution had continued TEC’s retroactive rewards publication process while tying the month’s contribution record to launch-era community work, ETHDenver visibility, TE Academy growth, Proposal Inverter outreach, open-source development, design, event coordination, and the ongoing attempt to make Rewards transparent through both data and narrative explanation.
2022-06-27 to 2022-11-29 — ABC Advance Page
Forum thread: ABC advance page Category: Conviction Voting / Archive Archive theme: Augmented Bonding Curve, converter interface, user experience, advanced dashboard, mint and burn visualization, bonding curve data, General Magic development
June 27, 2022
A Conviction Voting proposal was opened to create an advanced page for the TEC bonding curve converter. The proposal explained that the existing converter made bonding curve interactions look similar to a normal token swap on a decentralized exchange, which did not help users understand the Commons-specific mechanics behind minting and burning TEC. The goal was to create a clearer visual experience showing how the Augmented Bonding Curve worked when someone interacted with the converter.
The proposed advanced page would show where TEC was positioned on the bonding curve, display the curve’s shape, and include a swap feature with clearer money-flow information. It would also add a historical price chart with mint and burn prices, along with transaction data such as accounts, reserve value, total supply, amount in, price, tribute, amount out, and new price. The simple converter page would remain available, with a button allowing users to move into the advanced interface when they wanted more context.
The proposal requested 5,000 wxDAI for design and development work. The budget was based on an estimated ninety-five hours of work at 35 wxDAI per hour, with extra room for unexpected development needs. Any remaining funds after completion were expected to return to the Common Pool. Project management was not included in this proposal because it was already covered by the Transparency Working Group budget.
The discussion supported the idea that users needed better visual explanations of the bonding curve. The advanced page was framed not only as a user-interface improvement, but as an educational tool that could help people understand what was happening when they minted or burned through the ABC.
October 4 to October 7, 2022
The thread was updated after development had been underway since late July. A working version of the ABC dashboard was shared for testing, and the first major development payment request was posted. The update explained that there was still room for improvement, including mobile support, a dedicated subgraph to optimize bonding curve queries, better authenticated-user state management, and additional community-requested improvements.
Additional payment requests followed for design and backend support. The work included user-interface design for the advanced page and backend development support. Transaction links were shared after payments were made, keeping the proposal thread connected to actual execution and reimbursement activity.
October 15, 2022
A later response praised the page as a major improvement in making the bonding curve easier to understand. The comment suggested that this kind of interface could be useful for any organization using a similar mint-and-burn system because it helps users see how their actions affect the overall curve.
November 25 to November 29, 2022
The project was updated again with a more mature data architecture. A Graph instance for the TEC bonding curve had been created, allowing the dashboard to move away from Dune Analytics as its primary data source. The testing version was also updated with new designs. Further payment requests were posted for additional development and design fixes, and the thread closed with transaction confirmations for those payments.
By the end of the thread, the ABC advanced page had moved from a proposal for clearer bonding curve education into an implemented dashboard with improved design, transaction visualization, and a dedicated data source. The thread captured TEC’s effort to make its economic infrastructure more legible to users by turning the ABC from a black-box converter into a visual interface for understanding minting, burning, reserve flows, pricing, and token supply changes.
2022-06-28 — TEC Working Groups Weekly Update, June 20 to June 26
Forum thread: TEC WGs Weekly Update: June 20 - 26 Category: Community Updates Archive theme: working group updates, stewardship transformation, Gravity training, Sampo treasury strategy, token-holder outreach, TE ethics research, SourceCred activation, Rewards operations, transparency systems
June 28, 2022
This Community Updates post summarized TEC working group activity from June 20 to June 26. Stewards reported that Sprint 37 had just finished and that the retrospective produced action items around tokenomics exploration and stronger alignment with TE Academy. The update also pointed to an ongoing effort to transform stewardship inside TEC through a community poll and noted an upcoming TE Academy and TEC event presentation.
Gravity continued the Third Graviton Training, with the next session focused on deep democracy. It also kept running psychology and wellbeing observational research, Aragon umbrella coordination, website design work, and the conflict-support request pathway. Soft Gov continued discussing useful features for Gardens and Conviction Voting governance, while also reflecting on token-gated channels and the concern that gating could conflict with TEC’s values.
Communitas reported a steward transition, moved its funding proposal onto Gardens, posted an accountability update, reviewed proposed changes to contributor templates, and began outreach to token holders. Sampo pointed readers to the new token-holder update, continued treasury-management conversations using a unified treasury chart, began using Clarity to track commitments, and linked its strategy post as a way to make its longer-term path more legible.
0mega highlighted its internal compass and hub resources and continued TE Ethics participatory research, including planned focus groups on TEC values, private profit versus common benefit, and hosting multiple worldviews. Labs remained on hiatus while rethinking how to operate in a more seasonal way. Comms reported that its stewardship proposal was live, that the TE Academy T.E.A.M. proposal was coming soon, that animation and video production was working on Rewards System updates, and that marketing was preparing another newsletter.
Transparency worked on a data standardization master sheet, shared ABC page designs, and reminded readers of TEC’s meeting protocols, terms, and disclaimers. Legal continued its call for legal experts and pointed to a covenant-related Snapshot update. Rewards reported that quantification round thirteen for June Part 1 had closed, January 2022 rewards were incoming, SourceCred wallet activation instructions were being circulated, a Rewards System improvement post was active, quantifier participation was encouraged, and praise-giver activation remained open through Discord.
By the end of the update, TEC’s late-June operating work was centered on refining stewardship, strengthening TE Academy alignment, continuing Gravity training, expanding token-holder outreach, developing Sampo’s treasury and sustainability work, advancing TE ethics research, maintaining transparency infrastructure, updating legal covenant work, and connecting Praise with SourceCred activation inside the evolving Rewards system.
2022-07-04 — TEC Working Groups Weekly Update, June 27 to July 3
Forum thread: TEC WGs Weekly Update: June 27 - July 03 Category: Community Updates Archive theme: working group updates, paid-contributor rewards debate, Proposal Inverter updates, Gravity training, Soft Gov governance support, Sampo consulting intake, token-gating, Rewards tooling
July 4, 2022
This Community Updates post summarized TEC working group activity from June 27 to July 3. Stewards reported that Sprint 38 was underway and that the group was discussing a post about reducing rewards for regular paid contributors, with a deeper call planned. They also noted that Proposal Inverter updates were being assembled and reminded the community that simple social amplification could support TEC.
Gravity continued the Third Graviton Training, with the next session focused on decentralized dispute resolution. It also maintained psychology and wellbeing observational research, Aragon umbrella coordination, website design calls, and the conflict-support request pathway. Soft Gov focused on how to support TEC governance more effectively, including a SWOT analysis of TEC and work on reputation in the TEC.
Communitas continued encouraging votes on its funding proposal and reviewed suggested changes to the contributor template used in ZenHub. Sampo reported that it was working on specifications for a consulting intake service, exploring both technical and cultural options for token-gated Discord channels, and continuing to use its strategy post to communicate longer-term direction.
0mega prepared wireframes for a self-discovery game and continued planning three focus groups for TE Ethics participatory research. Labs remained on hiatus while considering a more seasonal model. Comms pointed readers to the Comms stewardship proposal, noted that the TE Academy T.E.A.M. proposal was coming soon, continued work on Newsletter 4, and shared the first translations from the Translations T.E.A.M.
Transparency continued work on the data standardization master sheet, shared ABC page designs, and again pointed readers to TEC meeting protocols, terms, and disclaimers. Legal reported that the proposal to update the covenant had passed while continuing its call for legal experts. Rewards reported that February 2022 rewards were incoming, SourceCred wallet activation instructions remained active, and tooling improvements were in development, including replacing drafted quantifiers, keyword search for selecting or dismissing Praise, and cross-period analysis for quantifier trends.
By the end of the update, TEC’s first week of July work was centered on contributor reward policy, Proposal Inverter communication, governance support, reputation research, consulting intake design, token-gated channel experiments, translation and newsletter production, covenant updates, and further automation of the Praise and Rewards workflow.
2022-07-04 — TEC Rewards Distribution: March 2022
Forum thread: TEC Rewards Distribution - March 2022 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, March 2022 praise debt, DAOist, ETHDenver, Rewards system development, Praise Bot
July 4, 2022
This Rewards Distribution thread published the retroactive rewards round for Praise given between February 28, 2022 and March 27, 2022. The Reward Board allocated 4,154 TEC tokens for the period and continued using the 100 percent Praise and 0 percent SourceCred split. The post again noted that some Praise accounts had not yet been activated, so the final distributed amount could be lower than the total amount set aside.
The allocation followed the established Rewards formula: 90 percent went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by quantifiers and the Reward Board, submitted to the Reward Board DAO, and linked to the full-period analysis. The post was opened for community review before final execution.
The distribution table included three missing-username rows for Reward Board rewards connected to different payout wallets. The qualitative summary of the ten highest-rated contributions emphasized event coordination and public representation at DAOist and ETHDenver, collaborative economics presentations, public-goods advocacy, Reward System development, research coordination, community events, and Praise Bot development.
By the end of the thread, the March 2022 distribution had continued the monthly retroactive Rewards process while showing how TEC’s contribution economy was recognizing public representation, ecosystem weaving, event work, Rewards tooling, research coordination, and core communications infrastructure alongside ongoing Praise and quantifier operations.
2022-09-14 to 2023-08-15 — Rewards WG Steward Role Proposal
Forum thread: [REDACTED] - TEC Rewards WG Steward: A role proposal story Category: Advice Process / Archive Archive theme: Rewards WG, steward role, Praise operations, quantification rounds, Reward Board DAO, contributor compensation, role scope reduction
September 14, 2022
An advice process thread was opened to formalize the Rewards WG Steward role. The proposal described the ongoing work required to keep TEC’s rewards system operating: facilitating Rewards WG calls, facilitating quantifier review calls, presenting Rewards WG updates during community calls, managing the quantifier pool, opening and closing quantification rounds, promoting quant rounds, supporting development and documentation of Praise and RAD, participating in Steward sync calls, and maintaining the Reward Board DAO.
The proposal estimated the role at roughly fifteen hours of work per month and requested 500 DAI worth of TEC per month, paid from the Reward Board Treasury. The compensation was requested retroactively from the beginning of September. The purpose of the thread was not to create a new community-wide funding vote, but to make the role, responsibilities, and compensation transparent through the advice process.
September 18 to September 22, 2022
The early discussion supported the role and clarified process. A question was raised about whether the budget was already covered by the Reward Board treasury and whether the proposal needed to go to a full community vote. The response clarified that the working group had autonomy to manage its own budget, so the post was intended for transparency and advice rather than community-wide approval. If no objections emerged, the role compensation would be handled through the Reward Board DAO.
By the end of the initial thread, the Rewards WG Steward role had been documented as a practical operations role needed to keep Praise and rewards distributions functioning. The thread also showed how TEC working groups handled internal compensation decisions through transparency and advice rather than always escalating to full governance votes.
August 14 to August 15, 2023
The thread was revived almost a year later to update the role scope. The Rewards WG had become much less active, and the responsibilities of the steward role were reduced accordingly. Regular Rewards WG calls, recurring quantifier review calls, community call presentations, and Steward sync participation were no longer part of the role. Rewards were now being distributed monthly, and the expected workload had dropped to about three hours per month. Compensation was therefore reduced to 100 DAI worth of TEC per month.
The update also invited anyone who felt called to take ownership of the Rewards WG to step forward. Otherwise, the role would continue in a minimal capacity to keep monthly distributions running.
A follow-up asked for a broader update on Praise and the Twitter Praise project. The response explained that distributions were still being run fairly consistently, although quant review calls and working group calls had stopped due to low attendance. Praise activity appeared to be increasing again, and Praise itself had been developing new features such as AI-generated bios and more detailed analytics.
The Twitter Praise Bot project was reported as effectively stopped. The work had not progressed well as an open-source add-on developed through TEC and Giveth, and had instead been folded into core Praise features. Professional coordination issues and a shift toward Optimism-funded priorities meant the work had paused. The allocated funds had not been used except for reimbursement of out-of-pocket Twitter API costs.
By the end of the thread, the Rewards WG Steward role had evolved from an active coordination and governance-support role into a minimal operational maintenance role. The thread documented both the importance of the Rewards WG during TEC’s active Praise period and the later contraction of rewards infrastructure as participation, working group activity, and Twitter Praise development slowed.
2022-09-27 to 2022-11-03 — Transparency WG Funding Proposal: September to October 2022
Forum thread: CV Transparency WG Funding Proposal (Sep to Oct 2022) Category: Conviction Voting / Archive Archive theme: Transparency Working Group, funding proposal, retroactive compensation, call recording, documentation, automation, cost reduction, dashboard and governance statistics
September 27, 2022
A Conviction Voting funding proposal was opened to fund the Transparency Working Group for September and October 2022. The proposal covered both retroactive compensation for September and planned work for October. It recognized that TEC was entering a period of change and that the working group needed to adapt its activities to the Commons’ evolving coordination needs.
The proposal described the group’s continuing responsibilities as recording calls, maintaining documentation, and handling other operations-related transparency tasks. At the same time, it proposed a more deliberate October review process. The group planned to analyze every task it was responsible for, seek community feedback where possible, and determine which workflows were still valuable and cost-balanced for the Commons. One explicit goal was to decide whether the Transparency Audit should continue in its existing form.
Automation and reduction of manual work became a major theme. The proposal acknowledged that many Transparency objectives were being carried out with more manual input than necessary. The group wanted to find easier and more automatic ways to preserve important outputs while reducing its monetary impact on TEC. This made the proposal partly a funding request and partly a transition plan toward a smaller, more efficient, commons-first operating footprint.
The requested budget accounted for an unused balance from the previous funding cycle. Although the working group estimated 8,220 wxDAI for September and October compensation, it still had 2,011.90 wxDAI remaining from the May to July budget. The proposal therefore requested a smaller amount through Conviction Voting, listed in the thread as 5,752.1 wxDAI. Progress would continue to be tracked through budget documents, work records, and the third Transparency Audit report.
The proposal framed transparency work as a way to support equal access to information, community monitoring, and participation in the advice process. By making activity and decision-making easier to observe, the group argued that TEC could reduce reliance on external accountability agents and strengthen trust among participants.
October 31 to November 3, 2022
After the proposal was posted, contributors added individual compensation requests for work completed during September and October. These requests documented the concrete tasks behind the group’s funding needs, including recording calls, uploading videos to YouTube with titles and descriptions, coordinating changes to the analytics section of the audit, updating decision tracking, reviewing the funding proposal, maintaining calendars, researching and testing bot automation, and supporting dashboard and data work.
The later compensation requests also showed that Transparency’s scope had expanded beyond call recording and documentation. Work included ABC advance page data extraction, migration and configuration of TEC Dune dashboards, creation of governance statistics for later dashboard inclusion, rewriting governance queries for Dune V2, correcting liquidity and transfer statistics, and testing or maintaining calendar and bot processes.
By the end of the thread, the Transparency WG funding proposal served as both a compensation request and a record of organizational transition. The group was still performing core transparency functions, but it was also trying to reduce costs, automate repetitive work, reassess which deliverables still mattered, and prepare for a smaller operational footprint by November.
2022-09-30 to 2023-03-03 — Experiment With a TEC Distribution Mechanism to Incentivize Value Creation in Token Engineering Public Goods
Forum thread: Experiment with a $TEC distribution mechanism to incentivize value creation in TE public good Category: Ideas / Archive Archive theme: TEC distribution, token utility, Conviction Voting, public goods funding, TE resources, skin in the game, matching mechanisms, Common Pool sustainability
September 30, 2022
An ideas thread was opened to question whether TEC’s existing funding and reward mechanisms were sufficiently incentivizing value creation for token engineering public goods. The post argued that TEC had spent a necessary early period focused on building and operating TEC itself, but that the Commons now needed to more directly nurture the broader token engineering public good: resources for practitioners, learning spaces for learners, and knowledge products that advanced sustainable and ethical design for token ecosystems.
The core problem was that practicing token engineers were unlikely to contribute significant time to the Commons through ordinary wages because market rates were far beyond what the Common Pool could usually support. The proposal therefore looked for a mechanism that could work through intrinsic motivation, meaningful co-ownership, and stronger connection between $TEC distribution and actual public-good creation.
The proposed experiment was simple and intentionally did not require immediate protocol upgrades. When TEC they had committed with the builders or working groups behind that proposal. Those recipients could then distribute the TEC, put governance-token ownership in the hands of people creating token engineering value, and build more skin in the game around TE public goods.
The post also argued that the original assumption behind the ABC and Common Pool economy, that there would be sufficient ongoing demand for TEC itself a receipt of contribution and co-ownership for those producing value in the token engineering commons.
October 1 to October 13, 2022
The first responses expanded the discussion into a broader reflection on what TEC should prioritize during a period of scarcity. One view argued that the strongest leverage came from supporting builders, learning resources, and the knowledge infrastructure that helps token engineers become practitioners. The discussion framed the problem as one of motivating volunteers and practitioners through significance, peer recognition, cultural capital, and public-good contribution rather than through market-rate wages.
Another response connected the proposal to matching mechanisms. If conviction could move closer to actual donations or token transfers, the Common Pool could perhaps act as a matching fund, with outside partners potentially matching as well. This shifted the discussion from a simple voluntary $TEC-sharing experiment toward a larger question of whether TEC could improve the Common Pool as a public-goods funding service, similar in spirit to Gitcoin-style matching.
The thread also considered whether the Proposal Inverter could support this kind of co-funding and matching use case. The discussion imagined a future where projects funded or supported by TEC could attract matching funds from aligned organizations, using prior trusted funders as a signal of conviction.
A practical concern was raised that requiring people to sacrifice part of their TEC directly to a proposal account. The deeper intent was not only to pay expenses, but to distribute $TEC meaningfully to people and projects that provided value to the Commons.
The discussion then returned to the larger thesis: TEC needed to find a way to fund public goods through the wealth of the network rather than relying on wealthy donors. The greatest future resource of TEC was framed as a network of smart people with well-balanced expertise around token engineering. If TEC could attract and coordinate that expertise, the Common Pool and related protocols could become a powerful re-granting mechanism for the field.
October 19 to November 4, 2022
The thread then moved into more concrete mechanism design. One idea proposed a system where TEC used in support would be burned through the ABC. The resulting wxDAI and associated tribute would go to the Common Pool, which could then fund rewards or public goods work. This would create a place where holders could spend $TEC outside the open market while also increasing Common Pool inflows.
Supporters saw this as a way to prevent whales from remaining passive holders forever, create more demand for $TEC, and make the ABC’s tribute mechanics more active. However, concerns were raised about applying a tax to expressions of conviction. Such a mechanism could disproportionately affect smaller proposals, discourage voting, create NIMBY-style resistance to funding proposals, and reward passive speculators over active participants. The specific percentage also mattered because even a small burn applied to the amount of voting power needed to pass a proposal could represent a large effective burden relative to the proposal size.
The discussion acknowledged that this was not ready as a formal protocol change. Instead, it returned to the idea of running an over-the-top experiment, possibly with a concrete proposal such as the TE Consilience Library, to learn whether added skin in the game changed supporter behavior or proposal outcomes. Only if such experiments showed promise would it make sense to analyze deeper ABC and Conviction Voting changes with designers and engineers.
By the end of the 2022 discussion, the thread had surfaced a central unresolved design challenge: TEC wanted $TEC to circulate into the hands of people creating value for token engineering public goods, but any mechanism that made voting more costly could also suppress participation. The thread therefore became a laboratory for thinking about voluntary token sharing, matching mechanisms, staking versus donation, public-goods funding, token utility, whale participation, voter apathy, and the future of the Common Pool.
March 3, 2023
The thread was briefly revived when a concrete proposal was suggested as a possible place to augment the experiment idea. This kept the concept alive as something that could be tested in connection with actual token engineering public-good work rather than remaining only a theoretical mechanism discussion.
By the end of the thread, the proposal had not become a finalized mechanism, but it had sharpened a major strategic question for TEC. If the Commons wanted to fund token engineering public goods through network wealth rather than donations alone, it needed mechanisms that distributed $TEC to value creators, increased meaningful participation, preserved voting incentives, and connected Common Pool funding to public-good outcomes without turning governance participation into a punitive tax.
2022-10-04 to 2022-11-15 — Praise System Rewards Top-Up #2
Forum thread: Praise System Rewards Top-Up #2 Category: Conviction Voting / Archive Archive theme: Praise rewards, Reward Board funding, SourceCred retroactive rewards, bonding curve purchase, LASERTAG funds, rewards sustainability, governance participation
October 4, 2022
A Conviction Voting proposal was opened to top up the Praise rewards system earlier than expected. The Reward Board explained that the previous funding request had underestimated the amount needed for retroactive SourceCred rewards because it was not yet clear how many SourceCred users would activate accounts or what amount would be fair to distribute retroactively. Once many SourceCred users were linked to Praise addresses, the system was able to distribute a larger portion of the promised rewards, causing the existing TEC reserve to run down faster than planned.
The proposal requested 21,000 wxDAI so that the Reward Board could buy TEC through the bonding curve and continue funding rewards into the first quarter of 2023. The request was intended to avoid running out of TEC around early December, especially given the time required for a proposal to pass through Conviction Voting.
The thread also explained the rationale for the retroactive SourceCred distribution. The rewards system had a calculated daily rate of 134 TEC, and the retroactive SourceCred allocation used 25 percent of that rate across the period from July 14, 2021 to July 20, 2022. This produced 12,428.5 TEC in retroactive SourceCred rewards, vested across ten bi-weekly periods. The post left room for a broader discussion about reducing the daily TEC distribution rate if the Commons believed the rewards system was too expensive.
The proposal framed Praise as core to TEC’s contributor reward process and culture of gratitude. The requested funds would be converted into TEC, held in the Reward Board DAO, and distributed to active contributors who received Praise, quantifiers who evaluated Praise, and the Reward Board members responsible for managing payouts and communications. Progress would continue to be shared through forum posts for each distribution round, with a forty-eight-hour review window before payouts.
November 8 to November 9, 2022
As the proposal was nearing passage, an alternative was introduced. Instead of spending 21,000 wxDAI from the Common Pool to buy TEC, the community considered transferring idle TEC from the LASERTAG multisig to the Reward Board DAO. The argument was that LASERTAG’s original liquidity-strategy purpose had not developed as intended, and the multisig held a large amount of TEC that could fund rewards for several more months without requiring a new purchase through the bonding curve.
This alternative raised a tradeoff. Using already-minted TEC could preserve Common Pool funds and avoid the technical overhead of bonding curve purchases, tribute fees, and Aragon agent interactions. But committing a large idle TEC balance to Praise rewards also risked locking significant governance-token resources into a system that TEC was actively reconsidering during a broader restructuring period.
November 15, 2022
The later discussion widened beyond the immediate top-up. The community considered whether idle TEC should be used only for rewards, split between rewards and Commons operations, or preserved for other strategic purposes such as compensation, partnerships, governance swaps, or other ecosystem relationships. There was support for putting idle TEC to work, but also caution about emptying a major source of TEC when the organization’s future direction was still unclear.
The thread also raised a deeper question about the purpose of the rewards system. Rather than treating TEC distributions simply as compensation, one view proposed orienting rewards toward expanding governance participation, especially among people and organizations aligned with token engineering. This suggested a possible shift from Praise as a compensation channel toward rewards as a mechanism for distributing governance power and strengthening the token engineering community’s participation in TEC.
By the end of the thread, the top-up proposal had become a broader discussion about rewards sustainability, treasury strategy, idle TEC balances, and the purpose of governance-token distribution. The immediate need was to keep the Praise and SourceCred rewards system funded, but the discussion pointed toward larger questions about whether TEC should buy more TEC, reuse idle TEC, conserve governance-token reserves, reduce reward emissions, or redesign rewards around participation rather than compensation.
2022-10-18 — TEC Reward Distribution for Late Praise Activators
Forum thread: TEC Reward distribution for late praise activators Category: Rewards Distributions / Archive Archive theme: Praise, Rewards Group, retroactive rewards, late account activation, TEC distribution, missed distributions
October 18, 2022
This Rewards Distributions thread documented a retroactive TEC payout for contributors who had received Praise before activating their accounts in the newer rewards system. Because those contributors were not active in the system when their original distributions were processed, they had missed payouts they were otherwise eligible to receive.
The Rewards Group explained that these retroactive payouts would happen regularly. This first distribution covered contributors who had activated by September 15, 2022. The payout list included twenty late activators and totaled about 866.619 TEC. The largest individual allocation was about 200.148 TEC, while the smallest was about 0.625 TEC, reflecting the different amounts of previously captured Praise attached to each account.
A follow-up comment thanked the people who had done the operational work needed to produce the list. By the end of the thread, the late-activator issue had been turned into a recurring rewards-maintenance process, connecting Praise accounting, account activation, missed distributions, and retroactive TEC payouts into a more complete reward system workflow.
2022-10-19 to 2023-06-13 — Gravity DAO Second Funding Proposal from the TEC
Forum thread: Gravity DAO Second funding proposal from the TEC Category: Conviction Voting / Archive Archive theme: Gravity DAO, conflict management, trust creation, DAOification, Graviton training, web3 wellbeing, service DAO, sustainability, TEC-born projects
October 19, 2022
A second funding proposal was opened for Gravity DAO, asking TEC to support the next phase of Gravity’s development. The proposal framed Gravity as a conflict management and trust creation initiative that had emerged from TEC and was now trying to become a more self-sustainable organization. The goal was to continue Gravity’s DAOification process while learning from TEC’s frameworks and moving toward an independent economic system around conflict management as a commons.
The proposal described two parallel needs. First, Gravity needed continued support for community development and service provision, which this proposal asked TEC to fund from the Common Pool. Second, Gravity needed to design and launch its own economy, which it intended to fund through external mechanisms. The proposal therefore positioned TEC funding as transitional support while Gravity developed its own revenue and funding streams.
The thread summarized what Gravity had achieved with its first TEC funding proposal. Gravity had mediated conflict management cases across TEC and other communities, developed psychology and mental health research in Web3, run three Graviton training cohorts, maintained active Gravitons as points of contact for conflict reporting and mediation, developed its website and communications infrastructure, onboarded contributors, participated in public goods funding opportunities, created book clubs and practice groups, appeared in events and Twitter Spaces, and rewarded contributors through Dework.
The proposal requested 25,800 wxDAI for approximately three months of continued work. The budget covered case management, a fourth Graviton training, outreach, coordination, operations, treasury management, active Graviton ambassadors, and a bounty pool. The planned milestones included launching another training, analyzing mental health and conflict resolution surveys, creating content and research, continuing trust creation and educational activities, developing funding streams, conducting DAO outreach, attending online and in-person events, continuing conflict management services, and launching the website.
The thread framed success as continued execution of Gravity’s planned activities, broader recognition in Web3, completion of its webpage infrastructure, analysis of survey results, expansion of educational resources, and greater access to conflict management and wellbeing practices across DAO communities. Gravity also committed to sharing progress through forum updates, TEC community calls, Zenhub, Dework, its calendar, future Graviton cohorts, and contributor feedback loops.
December 1, 2022
The proposal was updated with changes to the execution plan. The next Graviton training would become an online course rather than a live cohort, making it possible for people to learn asynchronously instead of waiting for scheduled cohorts. This change would also free live time for advanced trainings, role plays, practice groups, continued education, mental health support, and conflict management activities.
The update also explained that Gravity would take the final two weeks of 2022 as a holiday period and begin using the proposal funds in 2023 if the proposal passed. Some asynchronous workstreams would continue, including narrative and page design, content creation, proposal drafting for other communities, and online course preparation. The conflict management service would remain open, but urgent cases would be prioritized until 2023.
June 13, 2023
A later follow-up reviewed the execution of the proposal. Gravity reported that it had launched a free online course on conflict management in DAOs, representing the fourth iteration of Graviton training and making the material available at any time. The funding had lasted longer than originally expected because the contributor group had reduced in size and some bounties were adjusted. Gravity had also continued seeking additional funding through grants and outreach to other DAOs.
The update described Gravity as having an MVP of its DAO, including its own Twitter, Discord server, website, services, online course, and swag shop. It had maintained transparency around funds through Dework, published blog posts, facilitated trust creation and educational activities in Web3 communities, and continued supporting the implementation of its conflict management framework elsewhere.
The update also acknowledged unfinished work. Gravity had completed internal analysis of mental health and conflict management survey results, but still needed to turn those findings into a formal paper. It had expanded its reach, but not yet achieved the visibility it wanted. Most importantly, its economic engine was still not producing enough income for stable mid- to long-term sustainability, meaning operations could shrink without additional support from the wider ecosystem.
By the end of the thread, Gravity’s second funding proposal had become both a bridge and a record of transition. TEC funding helped Gravity continue services, develop an online training course, build independent infrastructure, and move toward DAO status. At the same time, the follow-up showed the difficulty of turning a TEC-born working group into an economically sustainable service commons for conflict management, wellbeing, and trust creation across Web3.
2022-10-21 to 2022-11-23 — Optimize Our Categorization of Praise
Forum thread: Optimize our Categorization of Praise Category: Ideas / Archive Archive theme: Praise analysis, categorization, keywords, quantifier guidance, historical scoring data, uncategorized Praise, rewards analytics
October 21, 2022
An ideas thread was opened to review and improve the way TEC categorized Praise in its rewards analysis. The post explained that Praise categorization had already been implemented in the cross-period analysis, but that the community had not yet taken time to examine how well the categories and keywords were working or how they could be improved.
The categorization system worked by defining categories and assigning keywords to each category. The analysis then searched Praise text for those keywords and grouped each instance of Praise into the associated category. This allowed the rewards system to show how often different kinds of Praise appeared, what average scores each category received, and which Praise instances were scored highest within a given category over a selected time period.
The thread listed the existing categories and their keyword sets, including categories for attendance, discussion, work, leadership, sharing, Twitter activity, hacking, general support, and in-person activity. The purpose of the post was to invite proposals for refining those categories and keywords. The longer-term goal was to use better categorization to support a quantification guide, giving quantifiers more accurate historical scoring data while still relying on their judgment.
Early feedback focused on ambiguity and overlap. One concern was that a keyword could appear in more than one category, which could make the analysis less precise. The thread also discussed whether categories should be treated as a guide rather than something that overrules quantifier judgment. Another question was whether the system should include a self-care category for Praise related to rest, rejuvenation, vacation, or time off, while avoiding ambiguous keywords that might capture unrelated technical failures.
October 24, 2022
The discussion continued with suggestions for improving the category set. A self-care category was proposed as a useful addition, and the group considered looking through historical Praise messages to identify reliable wording. The thread also suggested removing the separate hacking category because the language of hacking had become too similar to general work, making it less useful as a distinct category.
November 16, 2022
An updated keyword list was tested in the latest cross-period analysis. The results appeared generally reasonable, though the discussion noted that some outliers remained. A major issue was the size of the uncategorized Praise bucket, which represented roughly one-third of all instances. This suggested that even after keyword improvements, a significant portion of Praise activity still did not fit the defined categories.
November 22 to November 23, 2022
The thread then considered how to analyze uncategorized Praise more effectively. A frequency analysis tool was suggested as a way to identify recurring words or trends in uncategorized messages. However, the discussion clarified that raw word frequency was not enough. What mattered was whether a word appeared in a context that reliably matched a category. The community therefore needed a way to inspect full message context, not only count isolated words.
By the end of the thread, Praise categorization had been treated as a practical analytics and governance-support problem. The goal was not simply to label Praise more neatly, but to improve historical scoring data, support quantifier judgment, identify undervalued or ambiguous contribution types, and make the rewards system more legible as TEC moved toward more dynamic and sustainable reward distributions.
2022-10-26 to 2023-07-27 — A Report on the Distributive Impact of Praise, Part 1
Forum thread: A Report on the distributive impact of Praise. Part 1 Category: Ideas / Archive Archive theme: Praise, rewards distribution, paid contributors, unpaid contributors, governance power, reputation, financial rewards, redistribution analysis
October 26, 2022
A report was published analyzing the distributive impact of Praise in TEC. The thread was written in the context of ongoing debates about reducing rewards for regular paid contributors and broader questions about whether Praise was functioning as an alternative value system, a governance distribution mechanism, a financial reward system, or a cultural recognition practice.
The report explained that TEC had not yet reached agreement on several major questions. One question was whether Praise should value wider community contributions differently from work already paid through working group budgets. Another was how the status quo had affected TEC governance. A third was what a fairer rewards distribution model might look like. This first report focused mainly on the financial side of Praise, with a later part expected to examine governance effects.
The report reviewed Praise’s role in TEC. Praise allowed community members to recognize valuable contributions, which were then quantified by selected quantifiers and distributed as TEC rewards. It had become an important mechanism for recognizing subjective contributions, distributing governance power, and maintaining a record of what the community valued. The report noted that Praise had distributed or was scheduled to distribute a significant amount of TEC, and that the system had been viewed positively by adjacent DAOs.
The central analysis compared Praise distributions with paid working group contributions. Using Praise allocation exports and onchain/Dune data about working group payments, the report examined whether Praise was rewarding contributions distinct from those already receiving stablecoin compensation. The preliminary finding was that there was a strong positive correlation between paid contributions and Praise rewards among paid contributors. In other words, many of the people receiving the most Praise were already receiving monetary compensation from the Commons.
This finding challenged the idea that Praise was operating as a radically alternative value system. The report argued that if highly paid contributors were also receiving significant Praise rewards, then Praise might be functioning partly as a bonus for already recognized work rather than primarily capturing uncaught positive externalities. It suggested that TEC might need to account for already-paid work when designing rewards, or consider having working groups pay part of compensation in TEC rather than relying on Praise to carry the distribution burden.
At the same time, the report acknowledged that Praise also had meaningful redistributive effects. Even with skewed distributions, Praise captured a wider range of value than formal payments and helped onboard smaller contributions that might otherwise go unnoticed. The report therefore did not dismiss Praise, but called for a more honest understanding of how it was functioning financially and politically.
October 27 to October 28, 2022
The discussion that followed explored whether Praise should be treated primarily as financial compensation, reputation, governance distribution, or cultural analysis. One perspective emphasized that many contributors were not being compensated lucratively through TEC, especially after steward payments ended, and that Praise had become one of the few remaining ways to reward broad contributor labor. Another perspective suggested that Praise might be more useful as a reputation system and cultural analysis tool than as a financial reward system.
The thread also examined the relationship between governance and money. Because TEC had both governance and market value, rewards distributed through Praise could not be treated as purely symbolic. The discussion debated whether paid contributors receiving xDAI could be considered to have the same opportunity to acquire governance power as unpaid contributors receiving TEC, and whether it was realistic or fair to expect people to use stablecoin compensation to buy TEC.
A possible direction emerged around giving a positive multiplier to contributors who were not already receiving monetary compensation from the Common Pool. The discussion emphasized that any such system should be dynamic, time-sensitive, and non-retroactive so that it would not become a blame exercise or violate the spirit of Praise.
The conversation also turned toward outward-facing recognition. If TEC Praise had a broader reach into the token engineering ecosystem, the concentration of Praise around internal operations might decrease. However, expanding Praise beyond TEC raised new logistical questions: how to structure quantification, whether to silo rewards by community, how close quantifiers needed to be to the work being praised, and whether Praise should recognize only contributions to TEC or wider token engineering work.
July 27, 2023
A later comment returned to the report and suggested that labeling the plots by names and working groups could help the community reflect more directly on the effectiveness of rewards distributions.
By the end of the thread, the report had become an important analytical contribution to TEC’s rewards debates. It showed that Praise was not only a cultural recognition system, but also a financial and governance mechanism with real distributive effects. The thread helped prepare the ground for later changes that boosted non-paid contributors and for broader discussions about Praise as reputation, ecosystem recognition, and a health indicator for where value creation was concentrated.
2022-10-27 to 2022-11-03 — Dynamically Changing Rewards Distribution Amount
Forum thread: Dynamically Changing Rewards Distribution Amount Category: Ideas / Archive Archive theme: Rewards distribution, Praise volume, dynamic emissions, rewards pool sustainability, compensation transition, Praise culture
October 27, 2022
An idea thread was opened to address a mismatch between TEC’s static rewards distribution and the declining volume of Praise. The thread explained that when the TEC token distribution schedule had been designed, Praise activity was much higher. By late 2022, Praise volume had fallen by more than ninety percent, but the rewards system was still distributing the same fixed amount of TEC each two-week period.
The proposed solution was to dynamically adjust each rewards distribution based on the number of Praise instances in the period. The suggested mechanism used a linear equation with two key parameters: a maximum TEC distribution ceiling and a Praise instance cutoff required to reach that maximum. The initial parameters kept the ceiling at the existing 1,874 TEC per two-week period and set the cutoff at 800 Praise instances, roughly aligned with historic peak activity.
The proposal gave a concrete example. If a period had 141 Praise instances, the dynamic formula would distribute about 330 TEC instead of the full 1,874 TEC. The goal was to add feedback to the rewards process so that rewards scaled with actual Praise usage, while also extending the lifespan of the rewards pool. An alternative method based on total quantified Praise value had been considered, but it would have produced an even smaller distribution in the example period.
October 28 to October 31, 2022
Early replies supported the idea but also clarified its implications. The calculation was based on the number of Praise instances, not the quantified value assigned to those instances. This meant the system would set an upper bound on rewards per Praise item, regardless of how highly that item was later scored. After the Reward Board and quantifier allocations were removed, a single Praise instance would receive only a small maximum amount under the proposed curve.
The discussion then surfaced a deeper compensation issue. While the proposal could help preserve the Praise system and extend the rewards pool, it also represented a major reduction in income for contributors who had come to rely on Praise as a meaningful compensation stream. The thread noted that some working groups had shifted compensation pressure onto Praise, even though Praise had originally been intended to recognize contributions that were not otherwise compensated through regular budgets, SourceCred, stewardship roles, or other structures.
This reframed the issue from a simple rewards-pool sustainability problem into a transition problem for TEC operations. Dynamic rewards could correct an over-distribution problem, but the community needed to consider how contributors and working groups would adjust if Praise could no longer carry compensation that belonged in more explicit operational budgets.
November 1 to November 3, 2022
A smoother transition was proposed. Instead of immediately using an 800 Praise-instance cutoff, the community considered gradually increasing the cutoff over multiple rounds so that the rewards reduction would taper rather than happen all at once. This would give contributors and working groups more time to adapt and could also encourage the community to revive a healthier Praise culture.
The proposal was then revised. The 800-instance cutoff was recognized as too high for TEC’s medium-term activity level. A new method calculated a weighted average across previous Praise rounds, using Praise instances and total Praise scores to arrive at a lower cutoff of about 635. The revised proposal kept the 1,874 TEC ceiling but introduced the new cutoff gradually across three bi-weekly quantification rounds. The first round would begin with a cutoff of 158 Praise instances, then increase by 158 after each round until reaching the target cutoff.
The revised transition plan received support because it balanced sustainability with operational reality. It moved TEC toward dynamic rewards without forcing an abrupt collapse in Praise-based compensation, and it gave working groups time to shift toward more sustainable budgeting models alongside Praise.
By the end of the thread, the community had moved from a simple dynamic-emissions proposal toward a more careful transition plan. The thread captured TEC’s attempt to preserve the rewards pool, align distributions with actual Praise activity, avoid overpaying low-volume periods, and reduce the system’s accidental role as a substitute for working group compensation.
2022-11-09 — TEC Rewards Distribution: Round 20
Forum thread: TEC Rewards Distribution - Round 20! Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, SourceCred, Reward Board, quantifiers, retroactive SourceCred, account activation, contribution rewards
November 9, 2022
This Rewards Distribution thread published Round 20, covering Praise given between October 10 and October 23, 2022. The round allocated 3,155.7 TEC tokens for rewards and used a split between Praise and SourceCred, with the post describing the allocation as 59:40. The thread also noted that some Praise accounts still had not been activated, meaning the final distributed amount could be lower than the total amount reserved.
The distribution followed the established rewards structure. Of the rewards allocated through the Praise side of the system, 90 percent went to Praise recipients, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had already been reviewed by the quantifiers and the Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
The thread also included the tenth and final round of retroactive SourceCred distributions. A separate list was posted showing SourceCred recipients and their vested amounts for the period. This marked the close of the retroactive SourceCred catch-up process that had been running alongside the regular Praise-based rewards workflow.
By the end of the thread, Round 20 had documented another step in TEC’s evolving rewards system. It combined regular Praise rewards, quantifier and Reward Board allocations, active-account constraints, and the final retroactive SourceCred distribution into a single reviewable rewards post. The thread also reflected the transitional state of the rewards system at the time, as TEC was still balancing Praise, SourceCred, account activation, and community review before execution.
2022-11-16 — TEC Rewards Distribution: Round 21
Forum thread: TEC Rewards Distribution - Round 21 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, dynamic rewards ceiling, Reward Board, quantifiers, TE Fundamentals, Praise analysis, TEC restructuring
November 16, 2022
This Rewards Distribution thread published Round 21, covering Praise given between October 25 and November 6, 2022. The round allocated a maximum of 1,874 TEC tokens, with the ceiling reached at 158 Praise instances. This reflected the newly introduced dynamic rewards approach, where the amount distributed was tied to Praise activity rather than remaining a completely static emission amount.
The distribution followed the established rewards formula. Ninety percent of the tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution. The thread again noted that inactive Praise accounts could reduce the final amount distributed.
A follow-up comment summarized the ten highest-rated contributions for the round. These highlighted the launch of the TE Fundamentals educational course, in-person presentation work at Devcon, analysis of the distributive impact of Praise, long-term credential management for TEC, development of a Discord activity analytics dashboard, work on prioritizing TEC’s ongoing operations, transformation sessions related to restructuring TEC, and support for dynamic Praise token distributions in the rewards tooling.
By the end of the thread, Round 21 showed the rewards system beginning to incorporate the dynamic distribution logic discussed in earlier governance conversations. The round continued the standard Praise, quantifier, and Reward Board workflow while also reflecting TEC’s late-2022 transition period, where rewards were recognizing educational work, analytics, operational prioritization, restructuring, and tooling changes meant to make the rewards system more sustainable.
2022-11-17 to 2022-11-30 — Stewards and Working Group Learnings
Forum thread: Stewards and Working Group Learnings Category: Community Updates Archive theme: Stewards, working groups, participatory decision making, governance retrospectives, accountability, stewardship, Conviction Voting, organizational learning
November 17, 2022
A community update was opened to share learnings from a retrospective session with steward alumni and working group participants. The session focused on participatory decision making, transparency, accountability, and stewardship, with plans to later cover contributor management, doocracy, celebration culture, inclusion, boundaries, and economic management.
The first part of the thread summarized positive and negative lessons from TEC’s participatory decision-making practices. On the positive side, the community had created space for broad participation, education, and discussion around complex tools such as the Augmented Bonding Curve, Conviction Voting, and Tao Voting. Major decisions saw strong turnout, the forum became a central place for discussion, and TEC’s polycentric governance model was treated as a rich experiment in collaborative economics and governance design.
The negative reflections were more structural. The advice process had often been confusing and was sometimes used as a consensus mechanism even though that was not its purpose. Voter apathy remained a challenge, especially among important stakeholders, larger token holders, and more peripheral community members. The quality of decision-making sometimes suffered because not enough context was shared for less active members to form informed views.
The retrospective also raised concerns about Conviction Voting and Gardens. Conviction Voting was judged to have worked poorly for treasury management in TEC’s actual conditions. The volume of proposals and the funding capacity of the Commons were not high enough for the mechanism to behave as intended, and the system lacked a clear way to register negative signals short of using costly dispute mechanisms. Gardens was also described as unintuitive and technically difficult.
The thread concluded that education and governance rituals had been some of TEC’s most successful participation tools, but that too many decision pathways could become confusing and paralyzing. The working group model was also criticized for fragmenting accountability and governance into semi-independent units that could become siloed from the core community. The overall lesson was that participatory governance needed clearer boundaries, better communication, simpler decision pathways, and stronger follow-up processes.
November 30, 2022
A second update summarized the stewardship portion of the retrospective. The positive reflections emphasized that stewardship had created a strong sense of values alignment, mutual support, friendship, trust, and personal development. Nomination ceremonies, retrospectives, and shared coordination structures helped build belonging and made stewardship feel like a meaningful form of servant leadership.
The steward structure had also provided coordination benefits. It gave the community consistent guidance, created accountability, helped organize work before scaling, and made it possible to accomplish a large amount of work. The structure supported leadership development, community education, dashboard development, collaborative economics, and collective problem-solving in areas where there were few existing guidebooks.
The negative reflections focused on the risks of a steward-centric structure. Power and visibility could concentrate within the stewards group, creating an inward focus, echo chamber dynamics, complacency, and discomfort around dissent. Some stewards had limited experience with budgets and workstream management, and the group did not always have enough token engineering expertise for the responsibilities it carried.
Working group challenges were also identified. Meetings were not always well prepared, collaboration between working groups was insufficient, dynamism was low, budgets were difficult to manage, and some working groups moved beyond their original manifestos without enough recurring updates. Burnout was another major theme: too much responsibility was concentrated among too few people, and coordination work became heavy.
The conclusion was balanced. Stewardship had been a powerful bonding and coordination structure that helped TEC build resilient culture, gratitude, mutual support, and meaningful initiatives. But the same strong bonds could lead to groupthink, internal focus, and overly concentrated power. The thread suggested that stronger feedback rituals, clearer subject matter expert structures, recurring governance framework education, more solution-oriented practices, and better support for agency across the community could preserve the benefits of stewardship while reducing its risks.
By the end of the thread, the retrospective documented an important organizational learning moment. TEC was reflecting on the strengths and failures of its governance, stewardship, and working group experiments before moving into a new coordination structure.
2022-11-22 to 2022-12-01 — TEC Coordination Team Proposal
Forum thread: TEC Coordination Team Proposal Category: Snapshot / Archive Archive theme: Coordination Team, TEC restructuring, working group consolidation, operational sustainability, accountability, stewardship transition, Snapshot vote
November 22, 2022
A Snapshot proposal was opened to create a transitional TEC Coordination Team. The proposal was the result of merging two earlier forked proposals and followed several weeks of advice process through public transformation calls. It was framed as a three-month transition plan intended to simplify TEC’s coordination structures, reduce operating costs, improve accountability, and help the Commons return to a more outward-facing focus on token engineering impact.
The background section described a significant decline in community activity and forum engagement, growing pressure on the Common Pool, and the phasing out of several working groups. The proposal argued that TEC had become too inwardly focused on operations and needed a smaller, more flexible team that could maintain essential services while redirecting more energy toward the token engineering field.
The new team was designed to take over many coordinating functions previously handled across multiple working groups, including stewardship, transparency, community coordination, communications, and soft governance. Rather than defining rigid job descriptions, the proposal described a small self-directed team that would swarm around problems and organize work by functional areas such as contributor coordination, governance implementation, organizational development, strategic planning, stakeholder communications, community organizing, partner relations, economic development, technology support, finance, and token engineering needs research.
The budget was structured around three full-time-equivalent positions spread across roughly six part-time contributors. The proposed rate was 21 DAI per hour, with an estimated monthly budget of 10,080 xDAI during the transition period. Initial funding would come from remaining working group funds, with later funding expected to go through Conviction Voting. The proposal also set an intention to reduce annual operating expenses to roughly one-third of TEC’s average operating costs since launch.
The proposal emphasized accountability without adopting a centralized managerial hierarchy. It proposed monthly anonymous feedback, shared guidelines, the community covenant, and graduated sanctions as accountability mechanisms. The transition goals included maintaining essential services, defining success metrics, updating accountability language in the covenant, clarifying project management and governance processes, clarifying the relationship between Praise-recognized voluntary work and paid coordination work, and continuing the unresolved conversation about the future role of stewardship in TEC.
The proposal also clarified that open contribution would continue. Active contributors could still participate in meetings, complete smaller tasks, and receive symbolic compensation through Praise, while more substantial work could still be proposed to the Common Pool. The team would coordinate these contributions so they aligned with TEC priorities. A second path for permissionless contribution would involve clearer workflows such as participating in governance, using the bonding curve, curating knowledge, or helping with Praise quantification.
November 28 to November 29, 2022
The Snapshot vote went live, and the discussion quickly moved into concerns about how the initial team had been formed. A concern was raised that the team should have been selected through a more open process, with community members able to nominate themselves and with clearer eligibility criteria such as prior participation, token holdings, working group experience, or Trusted Seed membership. This turned the thread into a broader discussion about legitimacy, representation, and what kind of “stake” should qualify someone to help coordinate TEC during a transition.
Responses clarified that the proposed team had not been selected through a closed appointment process. Instead, it consisted of the people who had consistently shown up to the transformation calls, helped craft the proposal, and expressed willingness to take on the work. The discussion emphasized that the proposal had been open to forks and participation for weeks, and that no alternative team had formed during that process. It also challenged the idea that large token holdings or Hatch-era participation should be prerequisites for paid operational work, arguing that labor, time, skill, and commitment were also forms of stake in the Commons.
The discussion also distinguished between the Coordination Team as a working group replacement and the broader question of stewardship. If the team was simply consolidating operational work from existing working groups, then it did not necessarily need a political selection process different from prior working groups. If it was seen as replacing the stewardship of the Commons, however, then the legitimacy concern became more serious. This distinction became central to the thread.
November 30 to December 1, 2022
The later discussion clarified that the proposed team’s narrow purpose was to maintain essential services and provide stable compensation for people doing core operational work, while the larger transformation effort would remain open to community participation. From this perspective, the qualifications for the team were willingness, ability, available time, and relevant skills. Adding heavy prerequisites based on tenure or financial stake could exclude people who were already doing important work and shrink the pool of contributors at a moment when TEC needed operational continuity.
The concern that triggered the debate was eventually resolved through the discussion. After the clarification, the critic changed their Snapshot vote to support the proposal, noting that the responses had helped clarify the root of their uncertainty.
By the end of the thread, the Coordination Team proposal had become one of TEC’s clearest late-2022 restructuring documents. It proposed consolidating several working group functions into a smaller transitional team, reducing costs, maintaining essential services, clarifying accountability, and separating operational continuity from the larger unresolved question of stewardship and long-term governance. The thread also captured the community’s attempt to work through legitimacy concerns around team formation, token-holder stake, contributor labor, and open participation during a period of organizational contraction.
2022-12-01 — Retirement of Working Groups: Transparency and Communitas
Forum thread: Retirement of Working Groups - Transparency & Communitas Category: Working Groups / Archive Archive theme: Working group retirement, Transparency WG, Communitas WG, organizational transition, documentation handoff, remaining funds, archived functions
December 1, 2022
A working group retirement notice was posted to formally notify the community that the Transparency and Communitas Working Groups were being retired. The post framed the retirement as part of TEC’s broader process for closing working groups in an orderly way, rather than simply letting them fade out. Each retiring working group was expected to provide documentation explaining when operations would cease, what the group had learned, how remaining funds would be distributed, and which tasks or functions needed to be passed forward.
The Transparency Working Group was described as one of TEC’s oldest active working groups. Its contributions included creating and maintaining transparency practices, supporting documentation processes, establishing the first version of the TEC Dune Dashboard, tracking decisions across TEC, and maintaining two years of daily meetings for public access. The post linked to the working group’s retirement document and noted that its formal retirement date was October 31, 2022.
The Communitas Working Group was described as having formed in October 2021 to nurture, grow, and guide the TEC community. Its work included orientation calls for potential members, community guidance and education, and events that supported cohesion, inclusion, and respectful culture. The post linked to the Communitas retirement document, which stated that the working group had also officially phased out as of October 31, 2022 and that its documents and channels would be archived.
By the end of the thread, TEC had recorded the formal retirement of two major working groups that had supported the Commons’ internal culture and operations. The thread served as both a recognition of their contributions and a handoff mechanism, preserving learnings, archiving materials, identifying remaining functions, and documenting how TEC was consolidating its organizational structure during the late-2022 transition period.
2022-12-05 — TEC Rewards Distribution: Round 22
Forum thread: TEC Rewards Distribution - Round 22 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, dynamic rewards, Reward Board, quantifiers, Discord analytics, credentials management, document organization, Gravity, contributor wellbeing
December 5, 2022
This Rewards Distribution thread published Round 22, covering Praise given between November 7 and November 17, 2022. The round allocated 409.20 TEC tokens for rewards, showing the effect of TEC’s newer dynamic rewards approach after the community began tying distribution amounts more closely to Praise activity. The post again noted that inactive Praise accounts could reduce the final amount distributed.
The distribution followed the standard rewards formula: 90 percent of the tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. These highlighted work on Discord message analytics, credentials and access management, emotional accountability and vulnerability in the forum, Gravity facilitation around trust and dispute resolution, restructuring critical TEC documents in shared folders, external-facing community visibility work, mapping TEC’s dependencies on protocols and tools, contributor wellbeing and mental health work, translation of miscommunications, and peace-oriented project design.
By the end of the thread, Round 22 documented a smaller and more targeted rewards distribution under TEC’s evolving dynamic rewards system. The thread also showed the kinds of contributions being recognized during the restructuring period: security and access cleanup, documentation organization, analytics, cultural repair, governance support, contributor care, and efforts to make TEC more legible both internally and externally.
2022-12-09 — Retirement of Working Groups: T.E.A.M. DAO and Communications
Forum thread: Retirement of Working Groups - T.E.A.M. DAO (Communications) Category: Archive Archive theme: Working group retirement, T.E.A.M. DAO, Communications WG, decentralized communications agency, handoff documentation, organizational transition
December 9, 2022
A working group retirement notice was posted to formally notify the community that T.E.A.M. DAO and its associated communications working groups were being retired. The post followed the same retirement process used for other TEC working groups, requiring documentation of when operations would cease, what the group had learned, how remaining funds would be distributed, and which tasks or functions should be passed forward.
T.E.A.M. DAO was described as the Token Engineering Amplify Messengers, a decentralized agency that provided communications services to projects advancing token engineering. It had evolved out of the earlier Communications Working Group and contained several communications-related subgroups, including writing, marketing, translations, animation and video production, TE Academy support, and Twitter planning.
The post recognized T.E.A.M. DAO as an important experiment in TEC communications. It had helped move TEC’s communication work from a single working group structure into a broader decentralized agency model, expanding the ways contributors could support messaging, media, translation, education, and public-facing coordination. The thread linked to the formal T.E.A.M. DAO and Communications retirement document, which served as the archive and handoff record for the group’s closure.
By the end of the thread, TEC had documented the retirement of one of its major communications structures. The post marked the end of T.E.A.M. DAO as an active organizational form while preserving its role in TEC’s evolution: from communications working group, to experimental decentralized agency, to archived contributor network whose learnings and remaining functions would inform the next phase of TEC coordination.
2022-12-14 — Retroactive Funding for ABC Page
Forum thread: Retroactive funding ABC page Category: Conviction Voting / Archive Archive theme: ABC advanced page, retroactive funding, deployment costs, The Graph migration, Dune API, bonding curve visualization, infrastructure reimbursement
December 14, 2022
A retroactive funding proposal was opened after the ABC Advanced Page project had gone live. The proposal explained that the project had exceeded its original budget because the team encountered data and deployment issues while completing the page. The original proposal had requested 5,000 wxDAI, but the final project cost reached 6,580 wxDAI. Some of the additional cost was covered from the Transparency multisig, while 759 xDAI had been paid personally and became the amount requested for reimbursement.
The main reason for the cost overrun was a technical issue with the original Dune v1 deployment. The team expected that the data would break after December unless it migrated and paid for the Dune API. Instead of continuing with that path, the project moved to The Graph for deployment. This required additional work and funding, but it also improved the product by providing smoother data and reducing the risk of post-launch problems.
The proposal reiterated the purpose of the ABC Advanced Page. Before the advanced interface, interacting with the bonding curve looked too much like a simple swap and did not give users enough context about what was happening. The deployed page provided a visual representation of the bonding curve so users could better understand minting, burning, pricing, and the broader mechanics of the Augmented Bonding Curve.
By the end of the thread, the proposal documented the final funding gap for the ABC Advanced Page and explained why the project required additional deployment spending. It also served as a follow-up to the earlier ABC page proposal, showing how the project moved from interface design and dashboard development into production infrastructure decisions around reliable data sources and long-term usability.
2022-12-16 — TEC Rewards Distribution: Round 23
Forum thread: TEC Rewards Distribution - Round 23 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, dynamic rewards, Reward Board, quantifiers, Discord reorganization, Twitter Spaces, access cleanup, Gravity, external communications
December 16, 2022
This Rewards Distribution thread published Round 23, covering Praise given between November 21 and December 2, 2022. The round allocated 245.12 TEC tokens for rewards, with a 100:0 split between Praise and SourceCred. The lower allocation reflected the continued use of the newer dynamic rewards approach, where distribution amounts were increasingly tied to actual Praise activity. The post again noted that inactive Praise accounts could reduce the final amount distributed.
The distribution followed the established rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. These highlighted work on reorganizing Discord to better match TEC’s transformation direction, running the first Twitter Space community call, cleaning up passwords, authentication tokens, and admin roles, delivering educational programming, holding the Consilience Library vision, supporting Gravity’s immediate needs, pursuing grant outreach for Gravity, and representing TEC in external Twitter Spaces.
By the end of the thread, Round 23 documented another smaller, dynamic Praise distribution during TEC’s restructuring period. The recognized work reflected a shift toward operational cleanup, external communication, token engineering-facing community calls, infrastructure security, educational delivery, library development, and Gravity’s continued role in trust, conflict support, and community care.
2022-12-21 to 2023-01-31 — Retirement of Working Groups: Stewards WG
Forum thread: Retirement of Working Groups - Stewards WG Category: Archive Archive theme: Working group retirement, Stewards WG, coordination, servant leadership, shared roadmap, mission alignment, handoff documentation
December 21, 2022
A working group retirement notice was posted to formally notify the community that the Stewards Working Group was being retired. The post followed the same working group retirement process used elsewhere in TEC, requiring documentation of when operations would cease, what the working group had learned, how remaining funds would be distributed, and which tasks or functions needed to be passed forward.
The Stewards Working Group was described as the space for active, present, servant leadership within TEC. Its stated goals included maintaining a shared vision across working groups, coordinating interdependent activities, preserving knowledge about how TEC functioned, maintaining alignment with the mission, vision, and values, supporting stewards as they encountered blockers or community issues, and nurturing TEC’s broader culture and community growth.
The thread framed the working group as a place where stewards supported one another, coordinated across multiple workstreams, and helped advance TEC’s mission of advancing token engineering. A formal retirement document was submitted as part of the process, preserving the group’s learnings and handoff information as TEC moved toward a smaller and more focused coordination structure.
January 31, 2023
A later reply reflected on the retirement document with appreciation and nostalgia, recognizing the work involved in documenting the Stewards WG’s history and closure.
By the end of the thread, TEC had formally archived one of its central early coordination structures. The retirement of the Stewards Working Group marked a major step in the late-2022 organizational transition: the Commons was moving away from a multi-working-group steward model and toward a more consolidated coordination structure, while preserving the lessons, responsibilities, and cultural memory of the stewarding process.
2023-01-11 to 2023-07-04 — Upgrading Token Engineering Commons’ Operational Ecosystem
Forum thread: Upgrading Token Engineering Common’s Operational Ecosystem Category: Ecosystem / Archive Archive theme: DAO operations, operational tooling, DaoLens, project management, bounties, proposals, voting, contributor context, platform consolidation
January 11, 2023
A proposal was opened suggesting that TEC consider using the DaoLens DAO Manager platform to improve its day-to-day operational infrastructure. The thread framed the problem as one of fragmentation and lost context: TEC, like many DAOs, used multiple tools for discussions, proposals, voting, bounties, compensation, and project management, which made it harder for contributors and administrators to understand what required their attention.
The proposal identified several operational problems that a unified DAO management platform might address. These included difficulty maintaining contributor motivation, lack of rules for grouping eligible or like-minded participants into the right spaces, loss of context across bounties and proposals, lack of visibility across many tools, and the inconvenience of cross-DAO participation for contributors who were active in multiple communities.
DaoLens was presented as a unified platform for DAO operations, with modules for bounty boards, task review and compensation, discussion forums, proposal creation, onchain voting, project management, custom sections, access gating, and DAO discovery. The proposed benefit was not a specific funding request, but a possible operational upgrade that could reduce friction, consolidate workflows, and make DAO management more self-serve.
The suggested next step was for TEC to connect with the DaoLens team, run a test workspace, explore custom features, and eventually discuss whether migration of current data and workflows would make sense. The thread therefore served as an ecosystem tooling suggestion rather than a fully developed governance proposal.
June 21 to July 4, 2023
The thread received a later comment expressing appreciation for the overview and asking whether follow-up questions should be posted in the same thread or elsewhere. The response encouraged questions to be posted in the thread so that it could remain a constructive space for discussing the proposal.
By the end of the thread, the operational ecosystem proposal remained exploratory. It captured a recurring TEC concern from this period: the need to simplify DAO operations, reduce tool fragmentation, improve contributor context, and find better infrastructure for managing work, decisions, and compensation across the Commons.
2023-01-12 — TEC Rewards Distributions: Rounds 24 and 25
Forum thread: TEC Rewards Distribution(s) - Rounds 24 & 25 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-contributor bonus, dynamic rewards, Reward Board, quantifiers, reduced emissions, SourceCred sunset
January 12, 2023
This Rewards Distribution thread published two rounds at once: Round 24 and Round 25. It also marked the first distribution using the new method of providing bonus rewards for non-contributors, which had emerged from the earlier discussion about reducing rewards for regular paid contributors. Instead of only publishing ordinary Praise results, the thread documented the rewards system beginning to apply a more intentional adjustment meant to better recognize people who were not already being compensated through regular contributor roles.
Round 24 covered Praise given between December 6 and December 17, 2022. The round allocated 246.11 TEC tokens, with a 100:0 split between Praise and SourceCred. The distribution followed the standard rewards formula: 90 percent to Praise rewards, 7 percent to quantifiers, and 3 percent to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before execution.
Round 25 covered Praise given between December 20 and December 23, 2022. This round allocated 62.269 TEC tokens, also with a 100:0 split between Praise and SourceCred. It followed the same review and allocation structure as Round 24, with the same note that inactive Praise accounts could reduce the final amount distributed.
By the end of the thread, the combined Rounds 24 and 25 post showed TEC’s rewards system in a much leaner phase. The total TEC distributed was far smaller than earlier rounds, SourceCred was no longer receiving a share, and the new non-contributor bonus method had begun to shape how Praise rewards were allocated. The thread captured a practical implementation moment in TEC’s late-stage rewards redesign: smaller dynamic emissions, continued Reward Board review, and a deliberate attempt to better distinguish between paid operational work and voluntary contribution.
2023-01-26 — TEC Rewards Distribution: Round 26
Forum thread: TEC Reward Distribution - Round 26 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, TEC storytelling, curation service, strategy framework, coordination roles
January 26, 2023
This Rewards Distribution thread published Round 26, covering Praise given between January 4 and January 13, 2023. The round allocated 85.990505 TEC tokens and used the new distribution system that boosted non-paid contributors. The post again noted that inactive Praise accounts could reduce the final amount distributed.
The distribution followed the established rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. These highlighted attention to TEC’s unmet promotion and storytelling needs, drafting a weekly curation-service thread about the Inverter Network, listening and support for people returning to the community or contributing intermittently, feedback on coordinator roles and project management, Gravity contributions, and participation in the TEC Strategy Framework and January priorities discussion.
By the end of the thread, Round 26 showed the rewards system continuing in a low-emission mode while using the non-paid-contributor boost. The recognized work reflected TEC’s early-2023 focus on storytelling, recruitment, curation, contributor support, coordination roles, project management, Gravity, and strategic planning.
2023-01-29 to 2023-03-23 — One Stop Shop Bonding Curve Course
Forum thread: One Stop Shop Bonding Curve Course Category: Advice Process / Archive Archive theme: Bonding curves, educational resources, TE Academy curriculum, TEC Augmented Bonding Curve analysis, Machinations, cadCAD, Dune analytics, research group formation
January 29, 2023
An advice process thread was opened with a proposal to create a comprehensive bonding curve resource manual. The original idea was to build a one-stop educational resource for the TEC community that explained bonding curve types, structures, incentives, use cases, controllers, case studies, simulations, launch considerations, and related Web3 applications. The resource would be created in Notion and could later be adapted into a course hosted by Token Engineering Academy if TEC or TEA chose to do so.
The proposal framed bonding curves as an important primitive for token issuance, liquidity, market design, and economic control systems. It argued that a synthesized and accessible resource could help both technical and non-technical audiences understand how bonding curves work and how they could be applied in Web3 business models and token engineering contexts. The original budget was 21,000 dollars over three to four months, with an upfront payment and milestone-based follow-up payments.
January 31 to February 6, 2023
The early advice process focused on scope, usefulness, and fit with existing educational infrastructure. One concern was that much bonding curve content already existed across TEC, TE Academy, and the broader ecosystem, so the proposed work might duplicate existing materials unless it focused on synthesis, accessibility, or a clearly unmet need. Another concern was whether the deliverable should live in a public, community-owned location rather than a private Notion workspace.
The proposal author clarified that the intended value was not simply collecting links, but translating scattered technical material into a digestible framework. The discussion then became more skeptical about whether a broad course was the best use of funds. Some questioned whether the resource would actually be used, especially given the amount of existing bonding curve documentation already available.
At the same time, the thread began to identify a more TEC-specific direction. Rather than funding a generic bonding curve course, the community discussed whether the work could become an applied analysis of TEC’s own Augmented Bonding Curve. TEC had a year of operational data from its ABC, along with related liquidity pools, token freeze history, and Dune analytics. This suggested a narrower and potentially more useful project: analyze TEC’s bonding curve performance, improve visualizations and dashboards, and use that research as an educational case study.
February 7 to February 22, 2023
The conversation shifted from proposal evaluation into collaboration. A small group began coordinating to explore how the original course idea could evolve into something more directly useful to TEC. The thread discussed organizing a call, reviewing the available Dune data, and combining educational content with data analysis, modeling, and simulation work.
Additional feedback suggested that an evaluation of TEC’s ABC should start from the mechanism’s original objectives and then examine whether it had met or fallen short of those goals. The discussion also raised the possibility of developing clearer metrics for the intrinsic value of TEC and for assessing the behavior of the bonding curve against fundamentals, especially given the transparency of onchain data.
After a meeting, the thread was updated to say that the group would continue meeting weekly and work asynchronously on a revised proposal. The revised direction would integrate the advice received, respond to TEC’s needs, and create a more fundable and useful strategy around bonding curves.
March 2 to March 23, 2023
The later discussion continued to refine the proposal. A thoughtful response argued that bonding curve education could be valuable if it functioned like a real course rather than only a reading list. Courses were described as valuable because they combine presentation, feedback, practice, discussion, and objectively verifiable learning. The same response emphasized that the quoted labor cost could be reasonable if the deliverables were precise and the team had the right combination of math, coding, data analysis, writing, video production, and communication skills.
An updated proposal was then shared. The new version moved closer to a Bonding Curve Research Group model. Planned outcomes included digestible social media content, deeper analysis of the TEC Augmented Bonding Curve, suggested upgrades to Dune analytics dashboards, Python and cadCAD or simulation work, case studies, and further research questions for continuing the initiative. Success would be measured through published content, community traction, improved analytics, better methodologies for analyzing bonding curve data, and other positive research outcomes.
The final discussion focused on making the success indicators more concrete. Feedback asked for clearer definitions of subjective terms, more technical specificity around the proposed Dune dashboard upgrades, and firmer baselines for measuring improvement. The thread then moved toward a new forum post and Gardens proposal because the original forum post could no longer be edited cleanly for the updated proposal text.
By the end of the thread, the original bonding curve course proposal had transformed into a more applied research and education initiative. The discussion moved from a broad resource manual toward a Bonding Curve Research Group focused on TEC’s own ABC data, public educational content, analytics improvements, simulations, and a clearer connection between bonding curve knowledge and TEC’s strategic needs.
2023-02-07 to 2023-03-08 — Overview of the TEC Schelling Point Initiative
Forum thread: Overview of the TEC Schelling Point Initiative (SPI) Category: Archive Archive theme: Schelling Point Initiative, token engineering community, Navigation Hub, Interest Groups, Research Groups, Token Engineering Knowledge Commons, Proposal Inverter, Curation Service, Praise
February 7, 2023
A thread was opened to introduce the TEC Schelling Point Initiative, or SPI, as the internal name for a new outward-facing set of programs meant to bring the token engineering community closer together. The initiative reframed TEC’s role. Instead of trying to become the token engineering community itself, TEC would aim to serve as a navigation and resource hub for the people, projects, researchers, students, teachers, practitioners, and organizations that already made up the broader field.
The thread identified three major problems the initiative wanted to address. First, token engineering work was happening in silos, causing duplicated research and development efforts and inefficient use of public funding. Second, researchers and builders lacked a clear view of the holistic research and development needs of the field. Third, open-source progress in token engineering was often hidden inside unknown projects and GitHub repositories that lacked visibility and engagement.
The initiative was organized around three objectives. TEC would help catalyze growth for the next generation of token engineers by creating awareness of educational and research opportunities. It would facilitate solutions to token engineering problems by supporting research groups that could perform independent research, propose new onchain primitives, and develop best practices and standards. It would also aggregate case studies, research, models, frameworks, and educational resources into a Token Engineering Knowledge Commons.
The thread then described the core structures of the initiative. A Navigation Hub would act as a central resource for token engineering activities across TEC-sponsored interest and research groups, while meeting the community where it already gathered instead of requiring all activity to happen inside TEC Discord. Interest Groups would provide small spaces for people to explore specific token engineering topics for learning and growth. Research Groups would focus on solving specific token engineering problems, either as open public research groups or as more specialized research guilds made up of experienced researchers.
TEC Sponsorship was presented as the support layer for these groups. Sponsored groups could receive onboarding help, promotional resources, informational pages, and integrations with TEC products. Three key integrations were proposed: the Proposal Inverter for co-funding and cross-DAO research collaboration, the Curation Service for collecting and tagging token engineering knowledge into a shared database, and the Praise system for recognizing contributions to the token engineering field while distributing TEC to engaged participants.
The roadmap started with building interest and research groups in February and March 2023, then developing a TE Navigation Hub in April, and then creating MVPs and documentation for Proposal Inverter, Praise, and Curation Service integrations in May and June. Potential future developments included a digital token engineering conference and technical associations focused on specialized areas of the field.
March 3 to March 8, 2023
The follow-up discussion connected the initiative to the Proposal Inverter. The idea emerged that the Inverter could support Research Guilds by enabling matchmaking between industry participants with research needs and groups capable of executing research proposals. This could create opportunities for co-funding, tipping, service fees, or other forms of TEC utility.
The discussion also opened the door to beta access and a possible steering group for coordinating with the Inverter team. The thread therefore moved from a conceptual overview into early implementation thinking around how TEC-sponsored research groups might connect with external funders, research needs, and shared funding infrastructure.
By the end of the thread, the Schelling Point Initiative had been framed as TEC’s outward-facing bridge to the wider token engineering field. It proposed a path for TEC to become a navigation hub, knowledge commons, and coordination layer for education, research, practitioner collaboration, and public-goods infrastructure, while using TEC’s own products to support participation, funding, curation, recognition, and governance engagement.
2023-02-09 — TEC Rewards Distribution: Round 27
Forum thread: TEC Reward Distribution - Round 27 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, Dune dashboard migration, Public Nouns, TEA Latam, curation service
February 9, 2023
This Rewards Distribution thread published Round 27, covering Praise given between January 16 and January 29, 2023. The round allocated a small amount of TEC for rewards and continued using the newer distribution system that boosted non-paid contributors. The post again noted that some Praise accounts had not been activated, so the final distributed amount could be lower than the amount set aside.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. These emphasized a major Dune dashboard migration and query rewrite, UI refactoring for easier analytics interpretation, Public Nouns design work, securing and cleaning up TEC’s LinkedIn access, leadership of the TEA Latam study group, Gravity-style listening and support, support for newcomers in the general channel, and continued work on curation-service threads for Twitter.
By the end of the thread, Round 27 showed the rewards system operating at a very small scale while still recognizing key maintenance, analytics, design, education, community support, and curation work. The thread also reflected TEC’s early-2023 focus on preserving useful infrastructure, improving external visibility, and keeping contributor support pathways alive during a leaner phase of the Commons.
2023-02-13 to 2023-03-03 — TEC Strategic Framework
Forum thread: TEC Strategic Framework Category: Advice Process / Archive Archive theme: Strategic framework, theory of change, roadmap, TE education, TE practitioners, stakeholder study, strategic planning, Snapshot vote
February 13, 2023
An advice process thread was opened to present a strategic framework for guiding TEC over the next several years. The framework drew from earlier documents and community conversations and aimed to make implicit assumptions explicit. It was intentionally described as a directional compass rather than a detailed plan, giving TEC enough shared orientation to move forward while remaining responsive to an emerging field.
The framework was organized in two views: a theory of change and a chronological roadmap. The theory of change stated that TEC aspired to harness token engineering expertise to address global economic, social, and ecological challenges. It proposed three broad outcomes: developing token engineering expertise through education, research, and open-source tools; promoting the application of that expertise through practitioner collaboration and user advocacy; and building societal trust in the institutions and processes that house token engineering expertise.
The framework described TEC as stewarding several common pool resources on behalf of the token engineering field: financial capital, social capital, cultural capital, and intellectual capital. It then organized TEC’s work around four pillars: token engineering education, token engineering research, token engineering applications, and token engineering advocacy. These pillars were mapped to stakeholder groups including students and teachers, researchers, practitioners, and users or beneficiaries.
The roadmap proposed an initial focus on token engineering education from 2022 to 2024. This phase would build on the momentum of the Token Engineering Academy, reduce TEC’s overall spending, and direct more resources toward education as a high-leverage investment during the bear market. The framework identified a 2023 stakeholder study as an important input that would shape future planning. Later phases were framed as working assumptions, with a possible 2024 to 2026 shift toward practitioners through directories, knowledge graphs, professional services, and a more trade-association-like community of practice. Planning beyond 2026 was left intentionally open.
February 16, 2023
The discussion raised the risk that academic or educational work could become detached from real-world markets and fast-changing technological developments. The response clarified that TEC needed to become more externally oriented. A stakeholder study, an advisory network, and the curation service were identified as ways to keep TEC connected to real-world developments, practitioner feedback, and field-level change. The coordination team’s recent work to reduce burn rate and put internal systems in place was framed as a necessary precondition for returning focus to the mission.
February 28, 2023
The Snapshot vote for the framework went live. Supportive comments emphasized that the framework made TEC’s funding goals more explicit and that investing in token engineering education had already produced significant impact through TE Fundamentals and related study groups. The focus on practitioners after the stakeholder study was also welcomed as a natural next step.
March 3, 2023
The framework was reported as formally accepted by the community. The closing update expressed the hope that it would help TEC move forward with both purpose and responsiveness as the token engineering field continued to evolve.
By the end of the thread, TEC had adopted a strategic framework that clarified its theory of change, resources, stakeholder groups, work pillars, and phased roadmap. The thread marked a shift from late-2022 contraction and coordination repair toward a more explicit strategy centered on education first, then practitioner support, with field research and external orientation guiding the next phase of the Commons.
2023-02-24 — TEC Rewards Distribution: Round 28
Forum thread: TEC Rewards Distribution - Round 28 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, public goods funding options, Praise development, Gravity, trust in Web3
February 24, 2023
This Rewards Distribution thread published Round 28, covering Praise given between January 30 and February 4, 2023. The round allocated 32.20600416 TEC tokens and continued using the new distribution system that boosted non-paid contributors. The post again noted that inactive Praise accounts could reduce the final amount distributed.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. These highlighted work on options beyond Conviction Voting for distributing funds to token engineering public goods, continued Praise development and planning, technical decisions around Gravity page and course infrastructure, contributions to a trust in Web3 document, support and experience-sharing around DAOs, onboarding and care for new people arriving in TEC and Gravity, and help with administration and transparency questions.
By the end of the thread, Round 28 continued TEC’s small-scale dynamic rewards pattern while recognizing work around public goods funding mechanisms, Praise as a public Web3 tool, Gravity infrastructure, trust-building research, newcomer support, and administrative transparency.
2023-03-08 to 2023-03-21 — Token Engineering Small Grants Pilot
Forum thread: Token Engineering Small Grants Pilot Category: Conviction Voting / Archive Archive theme: Small grants, Gitcoin Allo Protocol, Grant Stack, quadratic funding, token engineering public goods, education funding, Common Pool sustainability
March 8, 2023
A funding proposal was opened for a Token Engineering Small Grants Pilot. The proposal requested 3,500 xDAI from TEC to complete a 5,000 xDAI matching pool, with the rest already secured through an ENS small grants award. The pilot was designed to let TEC test a small grants program in partnership with Gitcoin while experimenting with quadratic funding as a way to support token engineering public goods.
The thread framed the pilot as a response to TEC’s reduced Common Pool. Since the Commons no longer had the same level of funding available as it did at its peak, a small grants program was proposed as a way to keep public goods funding active while stretching TEC’s remaining resources. By using matching funds and attracting outside donations, TEC could potentially support early-stage token engineering projects without relying entirely on direct grants from the Common Pool.
The proposal also connected the pilot to the recently approved strategic framework. The pilot would prioritize educational projects in token engineering, reflecting TEC’s education-first strategy. Projects would submit proposals through a TEC-operated instance of Gitcoin Grant Stack, raise funds through their project profiles, and then receive matching funds from the TEC pool based on the results of the round.
The thread discussed the technical and strategic value of partnering with Gitcoin. The pilot would give TEC hands-on experience with Allo Protocol, Passport, and Grant Stack, while also increasing TEC’s visibility as an early partner in Gitcoin’s new grant infrastructure. The proposal noted that Allo was not likely to be enabled on Gnosis Chain in time for the pilot, and that denominating matching payouts in TEC tokens would probably create more friction than value for this first test. However, the pilot was still framed as a possible stepping stone toward future grant-program designs that could create TEC token utility.
The success conditions were concrete. TEC would receive training and support from Gitcoin, award 5,000 xDAI in matching funds to at least five small grant applicants, and gain experience running a grant-making process. All funds requested would go directly to matching payouts, while the work of developing and running the pilot would be covered by the Coordination Team budget.
March 21, 2023
The thread was later updated to say that this specific funding proposal would not move forward because of changes in the calendar. Instead, the community was directed to a revised Token Engineering Grants Program proposal.
By the end of the thread, the original small grants pilot had become a transitional proposal. It introduced the logic for using Gitcoin infrastructure, quadratic-style matching, education-focused funding, and small grants as a more sustainable public goods strategy, even though the specific proposal was superseded by an updated grants program plan.
2023-03-08 to 2023-03-27 — Engineering Praise for Twitter
Forum thread: Engineering Praise for Twitter Category: Conviction Voting / Archive Archive theme: Praise, Twitter integration, rewards infrastructure, reputation, external token engineering contributions, open-source tooling, TEC visibility, Common Pool prioritization
March 8, 2023
A proposal was opened to build a Twitter integration for the Praise system. The thread began from the history that TEC had helped build, test, and launch the first version of Praise, and that Praise had since spread to multiple communities. The proposal argued that TEC’s Rewards work could now move outward by allowing Praise to be dished through Twitter rather than only inside the TEC Discord.
The problem statement identified two related issues. Praise activity and general Discord activity inside TEC had declined, and Discord-only Praise created technical limits on recognizing token engineering value created outside the TEC server. Since much of the crypto and token engineering conversation happened on Twitter, the proposal suggested that a Twitter Praise bot could let registered community members praise anyone creating value for the token engineering field, capture those praise instances in the existing Praise database, and route them into TEC’s normal quantification process.
The proposed integration was framed as both a rewards mechanism and a visibility strategy. It would let TEC recognize contributors who were not already inside its Discord, make Praise visible to the broader token engineering community, and potentially distribute TEC to people whose work aligned with the field. The project was also presented as a reusable open-source module that other Praise communities could adopt, making it a contribution to the Praise ecosystem as well as to TEC.
The original funding request was 20,000 DAI for development and launch over roughly three months. The work included development planning, registration for praise givers and receivers, bot development, integration with the existing Praise database, QA testing, and DevOps.
March 9 to March 11, 2023
The early discussion supported the general idea but raised concerns about funding and strategic fit. One concern was whether TEC should pay for development that would also benefit Praise as a product used by other communities. This led to discussion of whether other Praise-using communities, General Magic, or future grants could share development costs.
Another concern was whether financial rewards were the right way to recognize broader token engineering contributions. The discussion suggested that peer recognition and reputation might be more aligned with the motivations of token engineers than small transferable-token payments. A possible alternative was to treat the integration as a foundation for non-transferable reputation, with future governance or signaling utility, rather than simply expanding TEC rewards distribution.
The thread also surfaced a broader strategic concern about TEC’s Common Pool. Even though the proposal aligned with TEC’s mission and could expand Praise, TEC was operating under tighter financial constraints and had recently adopted a roadmap focused on creating utility for TEC. From that perspective, expanding TEC distribution before creating stronger token utility could be poorly timed. The discussion therefore became not only about Twitter Praise, but about how TEC should set boundaries around funding proposals that were worthy but not necessarily aligned with immediate sustainability priorities.
March 17 to March 27, 2023
The proposal team updated the thread to clarify that they still wanted to move forward, but that the project could be abstracted away from the question of whether Twitter Praise rewards would be distributed in TEC or some other token. The central product was the ability to dish Praise on Twitter for token engineering contributions and beyond.
The discussion then moved toward shared funding and scope reduction. Other active Praise communities were being explored as possible contributors to development costs, and there was traction from Giveth to support development resources. This changed the economics of the proposal. By late March, the planned TEC budget was reduced from 20,000 DAI to 7,000 DAI, focused on project management, QA, and ad hoc design, with any unused funds to be returned to the Common Pool.
By the end of the thread, the Twitter Praise proposal had evolved from a TEC-funded product build into a more collaborative, lower-cost cross-community infrastructure effort. The discussion clarified the potential value of public Praise as recognition, marketing, contributor discovery, and future reputation infrastructure, while also documenting TEC’s growing caution about Common Pool spending and the need to align new projects with token utility and sustainability.
2023-03-15 to 2023-03-19 — A Proposals Roadmap for TEC/TEA Sustainability
Forum thread: A Proposals Roadmap for TEC/TEA Sustainability Category: Advice Process / Archive Archive theme: TEC sustainability, TE Academy integration, Common Pool, token utility, Tao Voting, grants program, education-first strategy, economic coordination
March 15, 2023
A roadmap thread was opened to explain a coordinated set of proposals intended to move TEC and Token Engineering Academy toward greater sustainability. The post framed the proposals as a way to generate value flows and income, grow TEC token utility, restore excitement among token holders and stakeholders, conserve and eventually replenish the Common Pool, deepen coordination with TE Academy, and carry out TEC’s strategy by investing heavily in token engineering education.
The thread began by describing TEC’s financial position. The Common Pool had fallen significantly from its early-2022 peak, and earlier work on income generation had made it clear that TEC first needed to reduce its unsustainable spending rate. After a major reduction in operational costs, TEC was running on a much smaller budget, but public goods funding requests were beginning to increase again. The thread argued that without a new strategy, TEC risked draining the Common Pool before it could create new income streams.
The roadmap connected this situation to the recently approved strategic framework. That framework identified token engineering education as TEC’s strongest lever for building the expertise needed to advance the field. The post argued that an education-first strategy was not only mission-aligned, but also TEC’s best near-term path toward economic sustainability.
The thread then focused on TE Academy. TEC had already invested substantial public goods funding into the Academy, and TE Academy had used that support to build educational infrastructure, a large student and professional community, partnerships, curriculum, programs, and systems for tracking expertise and reputation. The possibility of TE Academy becoming owned and governed by the token engineering community was presented as a major strategic opportunity, with economic integration between TEC and TE Academy as the first practical step toward a possible future merger.
The proposal roadmap described two phases. The first phase included moving from Conviction Voting to Tao Voting and funding a Token Engineering Grants Program using Gitcoin’s Allo protocol. The second phase would include a Coordination Team Season 2 operations proposal, a TE Academy operations proposal, and a TEA-TEC economic integration proposal. Together, these proposals were intended to tighten Common Pool withdrawal processes, segment expenditures into clearer budgets, fund token engineering grants, and approve the first stage of TEA and TEC economic integration.
The post described the package as an all-in strategy. The annualized cost of the proposed moves would consume a large share of the remaining Common Pool, but the argument was that deeper TEC and TE Academy integration offered the best chance to create real value for the token engineering field, generate new credibility and excitement, and eventually replenish the Commons through stronger token utility and income generation.
March 19, 2023
The follow-up discussion was supportive of formalizing the relationship between TEC and TE Academy. The replies emphasized that TE Academy had already built meaningful educational value through volunteer-led and community-driven methods, and that many people already saw TEC and TE Academy as closely connected parts of the same ecosystem. The idea of TE Academy eventually becoming community-owned and governed was welcomed as an important strategic development.
By the end of the thread, the roadmap had framed a major strategic turn for TEC. The Commons was no longer only reducing costs or preserving funds. It was considering a coordinated package of governance, grants, operations, and TE Academy integration proposals as a calculated bet that education, economic coordination, and shared token utility could become the foundation for TEC’s next sustainability model.
2023-03-16 to 2023-03-30 — Token Engineering Grants Program v1 First Round Funding Proposal
Forum thread: Token Engineering Grants Program v1 First Round Funding Proposal Category: Tao Voting / Archive Archive theme: Token Engineering Grants Program, Gitcoin Allo Protocol, quadratic funding, Tao Voting, public goods funding, Common Pool sustainability, TEC token utility
March 16, 2023
A funding proposal was opened for the first round of the Token Engineering Grants Program. The proposal requested 23,420 dollars through Tao Voting to help create a 25,000 dollar matching pool for token engineering projects, with the remaining amount coming from a previously won ENS small grant. The round would use Gitcoin’s Allo Protocol and Grant Stack infrastructure to run a quadratic funding-style grants round.
The proposal was presented as part of the broader TEC and TEA sustainability roadmap. It replaced the earlier small grants pilot after Gitcoin shifted from small March test rounds to a set of larger Partner Rounds in April. TEC had been selected as one of the early featured partners, creating a time-sensitive opportunity to launch a larger first round with more visibility.
The proposed round would be open to tooling and education projects that contributed to token engineering. The tentative schedule called for defining criteria by late March, opening grant applications in early April, and starting the round in late April. The chain had not yet been finalized, but Optimism was considered likely because the round would be coordinated with Gitcoin’s broader partner-round experience and donor flow.
The proposal also explored possible TEC utility mechanisms. Payments were likely to be made in TEC, depending on operational details, and the team was investigating whether TEC holders could receive a matching boost when donating. A similar boost for holders of Token Engineering Academy knowledge-proof NFTs was also being explored. These ideas were still tentative, but they showed how the grants program could eventually connect public goods funding with TEC membership, token utility, and education credentials.
The proposal emphasized that all requested funds would go directly to matching payouts for grant applicants. The costs of developing, launching, and running the pilot would be covered by the existing Coordination Team operating budget. The broader goal was to create a grants program that could make public goods funding more dynamic, help early-stage token engineering projects, attract outside donors and partners, and reduce long-term reliance on the TEC Common Pool.
March 19 to March 21, 2023
The early discussion supported the grants program while asking for more clarity on criteria and infrastructure choices. Suggestions included requiring projects to have a structured plan for usefulness, accessibility, inclusivity, and coherent motivation. The discussion also emphasized interest in educational projects, creative teaching and learning methods, and new token engineering tools.
The thread then clarified why the round might not run on Gnosis Chain. Gitcoin’s Allo contracts and related infrastructure were not yet deployed there, and running a partner round on a different chain from the rest of Gitcoin’s official schedule could create friction for donors and grantees. The proposal acknowledged that Gnosis Chain was important for future TEC utility, but argued that the first round should prioritize user experience, donor participation, and round growth.
Another clarification explained why the grants program should not rely financially on TEC over the long term. With a reduced Common Pool and a minimum matching-pool expectation for partner rounds, TEC could not afford to fund a large grants program indefinitely by itself. The long-term ambition was to learn how to attract external sponsors and funding partners so that TEC could steward grantmaking for token engineering without bearing the full cost.
March 24 to March 30, 2023
The proposal was posted for Tao Voting. This created discussion about governance process because the proposal was using Tao Voting before the proposal to sideline Conviction Voting had formally passed. The response explained that this was part of the transition plan: the grants proposal would serve as an early test of using Tao Voting for funding decisions before Conviction Voting was turned off. This was acknowledged as a tricky governance sequence.
Concerns were raised that moving the proposal through Tao Voting before the governance transition was complete could create a double standard or weaken process legitimacy, especially in relation to other proposals still using Conviction Voting. After the time constraints around Gitcoin’s round were clarified, the concern was left as a signal rather than a formal challenge.
The later discussion turned to application review and Sybil resistance. The round would run on Gitcoin’s platform, including the contracts and user interface. Projects would apply through Gitcoin’s system, and TEC would review applicants against its criteria before accepting them into the round. The requirements were not yet fully formalized, but the team planned to complete them soon and keep interested contributors informed.
By the end of the thread, the Token Engineering Grants Program had become a central part of TEC’s new funding strategy. It connected the move away from Conviction Voting, the shift toward Tao Voting, the desire to stretch Common Pool funds, the search for external matching partners, and the effort to create practical TEC token utility through grants, donor participation, and education-linked membership benefits.
2023-03-20 to 2023-03-30 — Proposal to Sideline Conviction Voting
Forum thread: Proposal to Sideline Conviction Voting Category: Tao Voting / Archive Archive theme: Conviction Voting, Tao Voting, Common Pool management, funding governance, sustainability, grants program, governance transition
March 20, 2023
A governance proposal was opened to sideline Conviction Voting as TEC’s active mechanism for distributing funds from the Common Pool. The proposal was presented as part of the larger coordinated roadmap for TEC and TEA sustainability, and it framed the change as an adaptive governance response to TEC’s changed financial and operational context.
The thread began by situating TEC’s governance system across three voting mechanisms: Snapshot for offchain cultural and ideation decisions, Tao Voting for smart-contract parameter changes, and Conviction Voting for Common Pool funding. Conviction Voting had originally been introduced as a way to continuously aggregate community preferences across many proposals and guide funding decisions. However, the proposal argued that the conditions under which Conviction Voting made sense had changed significantly since launch.
Two main problems were identified. The first was the lack of sufficient inflows into the Common Pool. Conviction Voting had been designed in part for contexts where a DAO had enough funding and inflows to distribute resources continuously. TEC, by contrast, was operating in a bear market with no consistent income stream and limited TEC token utility. Under those conditions, the permissionless and continuous nature of Conviction Voting created risk because it could continue draining funds before the Commons had a way to replenish them.
The second problem was procedural. Because Conviction Voting depends on effective supply and the amount of TEC actively supporting proposals, it worked differently when there were few proposals and low participation. Single proposals could pass more easily than expected, old proposals could remain open indefinitely, and token holders needed significant attention and context to use the module effectively. The proposal argued that TEC needed more direct control over Common Pool access while it worked on sustainability.
The proposed solution was to make Conviction Voting ineffective for short-term fund allocation by reducing the Spending Limit parameter to zero. This would not remove Conviction Voting permanently. Instead, it would pause its ability to allocate Common Pool funds until TEC had stronger inflows, clearer token utility, and a more sustainable funding environment.
The thread then explained what would replace Conviction Voting. Smaller public goods projects would be routed through the Token Engineering Grants Program, using Gitcoin’s Allo infrastructure and quadratic funding rounds. Larger funding requests, such as TEC and TEA operating budgets, would move through Tao Voting. The proposal noted that Tao Voting had historically been used mostly for smart-contract and parameter changes, so TEC would need to test and evaluate whether its existing parameters worked well for funding decisions.
The execution plan was staged. The Grants Program proposal would first be used as a Tao Voting test. Then a proposal would change the Conviction Voting spending limit to zero. Additional Tao Voting proposals from the roadmap would then help the Coordination Team learn how Tao Voting performed for funding governance and develop recommendations for future parameter tuning or separate voting instances.
March 21 to March 30, 2023
The follow-up discussion was generally supportive of the need to pause Conviction Voting under current conditions. One response summarized the problem clearly: Conviction Voting could work well when there were many proposals competing for support, but with few proposals it did not function as intended. Moving smaller public goods work to quadratic funding and larger operational requests to Tao Voting was seen as a better fit for TEC’s immediate needs.
The discussion also asked for more data on Conviction Voting’s historical performance, including passed proposals, TEC staked in CV, number of voters, and funds released. This framed the proposal as part of an experiment-driven governance process rather than simply an administrative change.
Later comments discussed the technical path for shutting off Conviction Voting. The proposal originally described reducing the spending limit to zero, but the conversation explored whether that should be done by changing the relevant parameter, altering the effective destination of the module, or using another technical method. The discussion also clarified timing. An amendment set April 20 as the planned expiration date for Conviction Voting if the proposal passed, giving proposals already in the pipeline a clear deadline and giving the community more transparency around the transition.
By the end of the thread, TEC had a concrete plan for moving away from Conviction Voting as its primary Common Pool funding mechanism. The proposal marked a major governance transition: TEC was shifting from continuous, permissionless funding toward a more controlled structure using grants rounds for smaller public goods and Tao Voting for larger strategic and operational allocations, at least until the Commons had stronger inflows and a more sustainable economic base.
2023-03-23 — TEC Rewards Distribution: Round 29
Forum thread: TEC Rewards Distribution - Round 29 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, stakeholder study, reputation research, token engineering education
March 23, 2023
This Rewards Distribution thread published Round 29, covering Praise given between February 13 and March 9, 2023. The round allocated 131.6087353 TEC tokens for rewards and continued using the distribution system that boosted non-paid contributors. The post again noted that some Praise accounts had not been activated, so the final distributed amount could be lower than the total amount set aside.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. These centered on support for the Token Engineering Stakeholder Study proposal, educational writing on Machinations and cadCAD, Twitter Spaces and presentations related to reputation and expertise in Web3, final publication of the Praise quantifier material, support for understanding Praise analytics, and work toward a comprehensive reputation-system framework for the token engineering community.
By the end of the thread, Round 29 showed the rewards system recognizing work tied to TEC’s early-2023 strategic direction: stakeholder research, reputation and expertise systems, token engineering education, public learning sessions, and continued maintenance of the Praise reward process itself.
2023-03-23 to 2023-03-24 — Bonding Curve Research Group
Forum thread: Bonding Curve Research Group Category: Conviction Vote / Archive Archive theme: Bonding curve research, TEC Augmented Bonding Curve, Dune analytics, simulations, education, research marathon, Conviction Voting, Tao Voting transition
March 23, 2023
A new proposal thread was opened to establish a Bonding Curve Research Group. This thread continued and formalized the work that had begun in the earlier bonding curve course advice process. The revised proposal shifted the emphasis from creating a broad course to organizing a research, data analysis, and education initiative around bonding curves, with TEC’s own Augmented Bonding Curve as a central case study.
The proposal began by identifying a broad problem in DAO economies: sustained bear markets had caused major token valuation declines, and volatile token prices could reduce an organization’s capacity to coordinate and produce work. Bonding curves were presented as a possible response because they use continuous token issuance, algorithmic reserves, and liquidity management to dampen volatility and create more resilient economic mechanisms. TEC’s ABC was framed as an important example that should be studied, explained, and used to build broader knowledge.
The research group proposed a three-month research marathon rather than a conventional development sprint. The thread emphasized that research initiatives often begin with open-ended questions and uncertain outcomes, so the proposal focused on process, research timelines, public updates, and deliverable categories rather than pretending all conclusions could be defined in advance.
The planned deliverables included six or more digestible educational media pieces on bonding curves, deeper analysis of the TEC ABC, suggestions for updated Dune Analytics dashboards and Python integrations, research into bonding curve case studies and simulations, and a set of future research questions. The group also aimed to create a sustainable flywheel for further bonding curve research and development by attracting new interest, grant opportunities, and possible deal flow to TEC.
The funding request was structured in two phases. The full proposal totaled 34,000 DAI, but the first phase requested 17,000 DAI through Conviction Voting. The second phase would be submitted later through Tao Voting once that process was available. This structure reflected the governance transition underway at TEC and allowed the research group to begin work while adapting to the new funding process.
The timeline laid out a twelve-week research plan. Early weeks would focus on research questions, bonding curve classifications, case study selection, TEC Dune dashboard review, and data integration exploration. Later weeks would cover live case study analysis, dashboard suggestions, Machinations, cadCAD or other simulations, secondary market liquidity mechanisms, emergency shutdown and safe liquidation procedures, social media releases, forum updates, and a final open Q&A with the community.
March 24, 2023
Follow-up comments clarified why the proposal had been reposted in a new thread. The earlier bonding curve course proposal had evolved substantially after receiving advice and feedback, and the new thread was meant to avoid confusion between the original course idea and the revised research group proposal. The discussion also noted that the split funding structure was influenced by TEC’s upcoming shift from Conviction Voting to Tao Voting.
By the end of the thread, the bonding curve work had been reframed as a structured research group rather than a standalone educational resource. The proposal connected TEC’s own ABC experience, public educational content, analytics improvements, simulations, and future consulting or deal-flow possibilities into one research initiative. It also showed how TEC’s funding process was adapting during a period of governance transition, with one tranche moving through Conviction Voting and a second planned for Tao Voting.
2023-03-27 to 2023-04-07 — Joint TEA-TEC Plan for AI-Powered Token Engineering and TEC Utility
Forum thread: Joint TEA-TEC Plan for AI-Powered Token Engineering and $TEC Utility Category: Tao Voting / Archive Archive theme: TEC and TEA collaboration, AI-powered token engineering, Token Engineering Grants, TEC utility, Allo Protocol, operating budget, governance transition
March 27, 2023
A joint TEC and Token Engineering Academy proposal was opened to fund four months of shared operations and begin aligning the two organizations around token engineering education, grants, AI tooling, and TEC token utility. The proposal described a shared opportunity to make token engineering expertise a commons-managed resource and to use that expertise to address social, economic, and ecological challenges.
The proposal had two main goals. The first was to explore AI-powered token engineering through a token engineering copilot built around GPT-4 and related modeling tools. The second was to launch the first Token Engineering Grants round using Gitcoin’s Allo-based quadratic funding infrastructure. Together, these efforts were presented as the first steps toward integrating TEA programs into the TEC economy and potentially moving toward a deeper merger between TEA and TEC.
The AI workstream imagined a commons-owned and commons-governed token engineering tool rather than a proprietary service. The proposal suggested convening a workshop with AI and token engineering experts, scoping a proof of concept, involving TEA students and practitioners, and beginning real-world testing by the end of July. The thread framed this as a way to position TEC and TEA early in the emerging field of AI-assisted token design, simulation, and optimization.
The grants workstream proposed using the upcoming Token Engineering Grants round to create practical TEC utility. TEA NFT proofs and TEC holdings would be used as signals in the funding process, students and graduates would be activated as donors, and future work could allow NFTs, donations, matching funds, project funding, and scholarships to move through TEC-denominated flows. The intended feedback loop was that educational credentials and TEC participation would improve grant curation, attract better projects and matching partners, support scholarships, and strengthen demand for TEC and TEA credentials.
The proposal also made fundraising a central 2023 priority. It argued that combining TEA and TEC’s reputations could improve grant-writing, matching-fund partnerships, and outreach to funders. The near-term goal was to use smaller matching grants to build credibility with larger partners, while seeking external funding for the AI proof of concept rather than relying entirely on the Common Pool.
The funding request totaled 107,000 xDAI for April through July. The budget combined TEC operational roles, TEC project support, a small miscellaneous category that included the proposed TEC airdrop, TEA staffing, and TEA infrastructure. The proposal described success as running the first token-engineering-specific Gitcoin quadratic funding round, holding an AI and token engineering workshop, submitting at least two major grant pitches, integrating TEA NFT proofs into the grant program, activating students in funding projects, and developing more scalable community organizing and advisory processes.
March 28 to March 29, 2023
Early discussion was broadly excited about the direction, especially the possibility of AI-powered token engineering and a deeper TEC-TEA relationship. The conversation connected the proposal to earlier ideas for TokenGPT or TokenGaia: a real tool built, owned, and governed by the Commons. The AI concept became more tangible as several potential use cases were discussed, including translating visual system maps into cadCAD-style code, helping analyze token models, and acting as a guided tutor for stakeholder mapping, incentives, and token design reasoning.
The discussion also surfaced questions about the feedback loop between grants, scholarships, TEA credentials, matching partners, and TEC utility. Clarifications explained that TEA NFT proofs were already being issued to students, authors, and study group hosts, and that scholarships depended on outside funding. High-quality projects in Token Engineering Grants were expected to demonstrate the value of token engineering, attract partners, and help justify more scholarship support.
A major concern then emerged around the structure of the proposal. Because it bundled several interdependent streams of work, including TEA operations, TEC operations, AI proof-of-concept scoping, and the Gitcoin grants round, the discussion questioned whether the proposal provided enough financial transparency and operational accountability. One suggested alternative was to publish a shared vision statement and then separate the work into multiple proposals with clearer scopes, milestones, and accountable parties.
The proposal side responded that the workstreams were too interdependent to separate cleanly. If only some parts passed, the remaining parts might no longer make sense, because the grants round, TEA integration, TEC operations, and AI proof of concept all depended on coordination between the organizations. The thread also invited broader participation through an AMA so questions could be addressed live.
March 29 to March 31, 2023
The conversation then moved into governance legitimacy. Because the proposal was large and was being routed through Tao Voting during a transition away from Conviction Voting, the discussion questioned whether TEC was bypassing its established governance process. The concern was not mainly opposition to the vision, but whether a large omnibus funding request should move through Tao Voting before the community had formally completed the shift away from Conviction Voting.
The governance discussion acknowledged a coordination problem. The intended sequence had been to first vote on sidelining Conviction Voting and then move other financial proposals through Tao Voting. But several funding proposals were active at the same time, and contributors needed continuity of payment. The thread therefore became part of the larger March 2023 governance transition: TEC was trying to move from Conviction Voting toward Tao Voting while still keeping operations, grants, and partner work alive.
Several responses argued that Tao Voting technically had the authority to make funding decisions, even if it had not been culturally used that way. The stricter Tao Voting parameters were seen as reducing risk, but the community also recognized that future parameter review or a separate funding module might be needed. The thread framed this as a messy but transparent transition moment, where established process, practical urgency, and community legitimacy had to be balanced.
The proposal was updated to reflect the most current team setup after forum feedback and the AMA. A clarification was also added around team inclusion and consent after one person asked not to be included in the proposal team. The proposal authors then stated that, after further discussion about governance-process concerns, the plan was to continue with the scheduled vote while acknowledging the complexity of the transition.
April 1 to April 7, 2023
The final stage of the discussion focused on practical realities. The community recognized that there was no clear opposition to moving away from Conviction Voting, that contributors needed to be paid, that the proposal’s goals were broadly desired, and that the main issue was procedural sequencing rather than the substance of the plan. The thread also connected this moment to the broader problem of legitimacy in DAO decision-making: technical authority, cultural expectations, and documented processes do not always move at the same pace.
The proposal was then posted for voting on Gardens. A later update reported that it had passed with strong support from TEC token holders. By the end of the thread, the joint TEA-TEC plan had become a major turning point in TEC’s 2023 transition. It funded shared operations, advanced the Token Engineering Grants program, began the practical exploration of AI-powered token engineering, introduced a stronger TEC utility narrative, and exposed the governance-process tensions involved in moving from Conviction Voting to Tao Voting.
2023-03-28 to 2023-03-29 — Token Singularity: Summoning TokenGPT / TokenGaia
Forum thread: Token Singularity: Summoning TokenGPT / TokenGaia Category: Tao Voting / Archive Archive theme: TEC and TEA integration, AI, LLMs, TokenGaia, TokenGPT, token engineering tooling, proof of concept, business development, strategic pivot
March 28, 2023
A proposal was opened presenting an ambitious strategic pivot for TEC and Token Engineering Academy around AI-powered token engineering tooling. The thread proposed a strategic alliance or eventual merger between TEC and TEA, a new mission charter, and the development of TokenGaia GPT, also described as TokenGPT or Gaia: an AI-driven token engineering co-pilot that could support tokenomics modeling, complex adaptive dynamics work, and implementation support for Web3 projects.
The proposal argued that TEC needed to focus on building a useful tool because tools could generate revenue, support fundraising, and give the TEC token stronger value. It suggested that TEC’s earlier goal of implementing Ostrom’s principles through tokenization had not yet produced a broadly useful product, and that the fast-moving LLM and AI landscape created a new strategic opportunity. By combining TEC’s economic layer with TEA’s educational community and token engineering expertise, the proposal imagined a pathway toward a token engineering AI product for the Web3 ecosystem.
The proposal outlined several major components. TEC and TEA would align under a new mission charter, develop a TokenGaia proof of concept with an initial budget, rebrand the joint effort around an AI-oriented identity, and pursue a rapid April to June development timeline. TEA students and token engineers were imagined as tuners, prompt engineers, and practical testers of the model, while TEA could also use the tool in education.
The thread included ambitious economic projections around increased token market capitalization, future trading through a DEX, business development with major Web3 protocols, and eventual paying clients. The initial funding request was 35,000 xDAI to begin proof-of-concept development, with an estimated six-month budget of 150,000 dollars. The proposal said that if accepted, a more detailed proposal would follow before funds were spent, with milestone documentation and thirty-day reviews.
Shortly after the initial post, a personally sponsored bounty was added to encourage people to help execute and implement the idea. The bounty was framed as a way to attract a small implementation team with operational, machine learning, marketing, community, or other relevant skills.
March 29, 2023
The proposal was then paused after internal feedback. The update explained that it would be better to first implement or vote on the broader Joint TEC/TEA proposal, which already included elements of the AI proposal. The thread was therefore reframed as food for thought rather than an immediate standalone funding action.
A follow-up response agreed that this was cleaner and acknowledged the proposal’s catalytic role. The discussion emphasized that there was urgency because the LLM field was moving quickly, and that a more tightly scoped proof-of-concept proposal would be brought forward later.
By the end of the thread, the TokenGaia proposal had not moved forward as an independent vote, but it captured an important strategic impulse in TEC’s early-2023 transition: the idea that TEC and TEA integration could be paired with AI tooling, token engineering education, product development, and revenue generation. The thread served as a bridge between broad strategic imagination and the later need for a narrower, executable proof-of-concept plan.
2023-03-30 — Gravity’s Grateful Transition: A New Chapter for Growth and Collaboration
Forum thread: Gravity’s Grateful Transition: A New Chapter for Growth and Collaboration Category: Working Groups / Archive Archive theme: Gravity DAO, working group transition, conflict management, trust creation, ecosystem collaboration, organizational spinout
March 30, 2023
A transition announcement was published explaining that Gravity was moving into a new phase outside of TEC’s main community spaces. The post expressed gratitude to TEC for serving as the environment where Gravity had been able to grow as a trust creation and conflict management initiative. It framed TEC as the original soil that allowed the project to learn, share, and evolve.
The announcement clarified that Gravity would transition its operations to a dedicated Gravity DAO Discord server. This was not presented as a break from TEC, but as a step toward greater focus and growth. By moving into its own dedicated platforms, Gravity would be able to concentrate on its core mission of providing conflict management and trust creation services for decentralized organizations, while continuing to maintain strong ties with the TEC community.
The thread emphasized that the separation could benefit both Gravity and TEC. Gravity would gain more efficient communication, specialized development, and targeted outreach to the communities it served. TEC, in turn, would retain a relationship with a project that had emerged from the Commons and could continue contributing to the broader token engineering ecosystem through nested, aligned work.
By the end of the thread, Gravity’s transition was framed as an example of project maturation rather than departure. The announcement documented a moment when a TEC-born initiative moved toward independent operations while preserving collaboration, shared values, and ongoing support between Gravity and the Commons.
2023-04-03 to 2023-06-08 — Buying ETH to Protect Against xDai Challenges
Forum thread: Buying ETH to protect against xDai challenges Category: Advice Process / Archive Archive theme: Treasury diversification, xDai risk, stablecoin depeg risk, ETH, wstETH, Common Pool, Tao Voting, treasury management
April 3, 2023
An advice process thread was opened as a temperature check on whether TEC should use Common Pool funds to buy ETH as protection against risks associated with xDai and other pegged assets. The thread was written in response to the March 2023 stablecoin stress period and argued that TEC should not keep its entire treasury denominated in xDai or similar pegged assets.
The initial proposal framed ETH as both a hedge and a long-term investment. While DAI was described as one of the safer pegged coins because of its collateral diversity and governance flexibility, the thread argued that TEC still needed to be reasonably safe under worse-case scenarios. A treasury fully denominated in xDai left the Commons exposed to depeg and stablecoin infrastructure risks.
The thread asked the community to consider several allocation sizes, ranging from 25,000 dollars to 100,000 dollars or more. It also raised a custody and location question: TEC could hold ETH directly in the Common Pool address, bridge it to Mainnet or an L2, or use liquid staking assets to earn yield. The post clarified that this was not meant to be an active treasury management strategy, but a one-time protective diversification step that would ideally only be used if needed.
April 4 to May 11, 2023
The early discussion supported exploring the idea but raised concerns about execution. One response suggested that the decision should go through both Snapshot and Tao Voting. It also noted that removing funds from the Common Pool during a period of other major proposals could be politically difficult, even if diversification made sense.
The discussion distinguished between simply buying ETH and managing interest-bearing ETH across other chains. Holding interest-bearing ETH could hedge against depeg risk while earning yield, but doing so would require infrastructure for monitoring, managing, and trusting funds on Mainnet or another L2. The thread therefore suggested avoiding unnecessary complexity at first and, if the community moved forward, buying ETH on Gnosis and committing to further diversification later.
The discussion then returned to the broader strategic value of ETH exposure. Holding some ETH was framed as a way to prepare for macroeconomic and stablecoin risks while keeping part of the treasury independent from traditional-currency-linked assets. There was also a broader ecosystem argument that TEC, as a Schelling point for token engineering, could benefit from diversifying across chains and assets over time.
June 6 to June 8, 2023
The thread was revived when new incentives for wstETH liquidity on Gnosis emerged through Agave and Balancer. This changed the practical options available to TEC: the community could potentially buy wstETH on Gnosis and deposit it directly into the DAO, reducing the need for more complex cross-chain custody.
The thread closed with a note that a formal funding proposal had been posted for buying wstETH to diversify the treasury. By the end of the discussion, the original ETH temperature check had evolved into a concrete path toward treasury diversification using liquid staked ETH on Gnosis. The thread documented TEC’s growing attention to stablecoin risk, Common Pool resilience, and the need for treasury management practices that could protect the Commons during uncertain market conditions.
2023-04-13 to 2023-04-15 — TEC Coordination Team Impact Tracker: Season 1
Forum thread: TEC Coordination Team Impact Tracker - Season 1 (November 2022 - March 2023) Category: Community Updates Archive theme: Coordination Team, impact tracking, accountability, budgeting, strategic framework, TEC-TEA integration, grants program, Schelling Point Initiative, governance transition
April 13, 2023
A Season 1 impact tracker was published to report on the TEC Coordination Team’s work from November 2022 through March 2023. The report was intended to share progress, maintain transparency, and create a basis for community accountability during a major transition period. It reviewed the goals from the original Coordination Team proposal, including maintaining essential services, creating accountability systems, clarifying project management and governance processes, defining the relationship between paid and voluntary contributions, and supporting the transformation of stewardship.
The report first summarized several major initiatives that had emerged during the season. The Coordination Team had delivered the TEC Strategic Framework, giving the Commons a clearer set of desired outcomes, resources, stakeholders, and workflows. It had also worked closely with Token Engineering Academy on a plan for deeper operational and economic integration, including legal structure research and the Joint TEA-TEC strategy for AI-powered token engineering and TEC utility.
The report also highlighted the new Token Engineering Grants Program. TEC had become an early Gitcoin Allo partner, secured an ENS small grant, and passed a proposal for a 25,000 dollar matching pool. This work was framed as a way to make funding for token engineering public goods more dynamic while using Common Pool funds as a catalyst for outside donations rather than as the sole source of grant funding.
The Schelling Point Initiative was another major area of progress. The report described it as an experiment using Research and Interest Groups to bootstrap the Curation Service and bring more activity into the token engineering field. Three groups had been onboarded: the Reputation Systems Open Research Group, the Bonding Curves Research Group, and the TE Stakeholder Research Group. These groups were beginning to use recurring meetings, Twitter Spaces, and community engagement to build momentum around research topics.
The report then reviewed the Coordination Team’s operational goals. To maintain essential services, the team had created a role system with 22 roles across strategic planning, organizational development, economic development, service operations, communications, technical support, and finance. This was meant to provide clearer task ownership while remaining flexible when contributors entered or exited.
The accountability section described work on budgeting, team agreements, sanctions, surveys, peer and self-evaluation, community feedback, and regular reporting. A major milestone was reducing essential operations to a monthly budget of 10,000 xDAI, roughly a quarter of the previous average monthly operating cost of 39,000 xDAI. The team also described ongoing work to improve role-based systems and organizational processes.
The governance process section connected the grants program and the transition from Conviction Voting to Tao Voting. The grants program was described as a way to support token engineering public goods without continuously draining the Common Pool. The move from Conviction Voting to Tao Voting was framed as a necessary but complex change in how TEC governed spending decisions, especially because the transition had to happen while several funding proposals were already in motion.
The report also discussed paid and voluntary contributions. On paid work, the team had been developing a compensation model that balanced accountability, economic security, predictability, and project-based flexibility. On voluntary contributions, progress had been more limited because of time constraints and shifting priorities, though the report pointed to SPI and the Curation Service as possible foundations for future open contribution pathways. The stewardship transformation section described early work on an advisory network and clearer contributor definitions.
The post closed by inviting the community to complete a performance poll with statements about the Coordination Team’s work. This made the report not only a retrospective, but also part of the team’s accountability process.
April 15, 2023
The follow-up discussion welcomed the report and emphasized the importance of asynchronous participation. The response noted that time zones and family commitments made synchronous meetings difficult for some contributors, and suggested that TEC’s AI-related work could be especially important because it might enable more asynchronous, time-zone-independent participation. The comment expressed encouragement about the report while also noting frustration about limited ability to participate more actively.
By the end of the thread, the Season 1 impact tracker had documented a major operational reset for TEC. It showed the Coordination Team reducing costs, creating clearer roles and accountability structures, advancing the strategic framework, preparing TEC-TEA integration, launching the grants program, supporting SPI research groups, and moving governance from Conviction Voting toward Tao Voting while inviting community feedback on the team’s performance.
2023-04-18 — Bonding Curve Research Group Update #1
Forum thread: Bonding Curve research Group Update #1 Category: Ecosystem / Archive Archive theme: Bonding Curve Research Group, TEC Augmented Bonding Curve, research updates, education content, Dune analytics, Python tooling, case studies, research workstreams
April 18, 2023
The Bonding Curve Research Group published its first progress update after the first few weeks of work. The post began by acknowledging the community’s support and the trust placed in the group to pursue bonding curve research, educational content, and analysis of TEC’s own Augmented Bonding Curve as a token engineering public good.
The update explained that the group was entering its third week of a planned twelve-week research and education sprint. To organize the work, the group had created three workstreams with corresponding weekly meetings. The Research and Ideation workstream would guide the overall direction of the initiative. The Education and Content workstream would turn research into digestible public material. The TEC Bonding Curve Analysis workstream would focus in the near term on TEC’s own bonding curve and related data.
The group also clarified its initial research scope. Rather than studying every form of bonding curve or secondary-market automated market maker, the first phase would focus on Primary Market Issuance and Redemption Bonding Curves. This narrower scope was chosen to avoid getting lost in the broader design space and to concentrate on a less explored but important area. TEC, Nexus Mutual, Gotchi DAO, DxDAO, and Gyroscope were listed as relevant case studies.
The update described several coordination and accountability tools. A Gantt chart was created to track deliverables and documents across the research period. A RACI template was being used to clarify responsibilities within the group. Meeting notes, recordings, and resources were collected in a shared workspace so the community could follow the work.
The team update noted that additional contributors and observers with backgrounds in data science, research, communications, Web3 organizations, and protocol design had joined or were following the work. Because the group had begun attracting outside attention, it described itself as semi-permeable for the moment: open to later public discussions and workshops, but limiting new entry in the short term to preserve focus and momentum.
The update then reviewed progress against the group’s four primary goals. Content work had begun through a knowledge library, case studies, a bonding curve classification notebook, and early tweets. The TEC ABC analysis team was reviewing the TEC Dune dashboard query by query, identifying important queries such as the TEC price chart, setting up Python environments, accessing a beta Dune API client, and creating a Python library to pull TEC dashboard queries into a research environment. The group was also beginning to attract potential collaborations, grant opportunities, and service possibilities, while continuing to gather future research questions for later publication.
By the end of the thread, the first update showed the Bonding Curve Research Group moving from proposal into structured execution. The group had narrowed its research scope, organized workstreams, begun educational and analytic outputs, created public tracking infrastructure, and started turning TEC’s own bonding curve into a live case study for token engineering research.
2023-04-24 — TEC Rewards Distribution: Round 30
Forum thread: TEC Rewards Distribution - Round 30 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, TEA-TEC integration, reputation systems, Twitter Praise, treasury management
April 24, 2023
This Rewards Distribution thread published Round 30, covering Praise given between March 18 and April 4, 2023. The round allocated 89.19 TEC tokens for rewards and continued using the distribution system that boosted non-paid contributors. As in earlier rounds, the post noted that some Praise accounts had not been activated, so the final distributed amount could be lower than the total amount set aside.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. The highest-rated work centered on hosting the Joint TEA-TEC AMA and the broader effort behind the joint proposal, reflecting the importance of TEA-TEC integration in this period. Other recognized work included improving the security of TEC Twitter credentials, resolving a Praise accounting issue, proposing treasury diversification into ETH, supporting the Twitter Praise proposal, participating in reputation systems discussions, and presenting TE Academy during an Optimism RetroPGF showcase.
By the end of the thread, Round 30 reflected TEC’s April 2023 priorities: TEA-TEC coordination, operational security, Praise maintenance, treasury management, reputation research, public communications, and the continued use of small rewards to recognize contributions during a period of strategic restructuring.
2023-05-17 — Bonding Curve Research Group Update #2
Forum thread: Bonding Curve Research Group: Update #2 Category: Ecosystem / Archive Archive theme: Bonding Curve Research Group, PAMMs, SAMMs, case studies, Python simulation, Dune dashboards, TEC ABC analysis, Gitcoin grants, public outreach
May 17, 2023
The Bonding Curve Research Group published its second progress update, covering work from the group’s second sprint. The update again opened by thanking the community for funding and feedback, and it reiterated the group’s purpose: creating token engineering public goods through research, educational content, and analysis of TEC’s own Augmented Bonding Curve.
The group reported that it had narrowed its research focus around Primary Automatic Market Makers, or PAMMs, which it described as bonding curves used for token issuance and redemption. The update contrasted PAMMs with Secondary Automatic Market Makers, or SAMMs, such as Uniswap and Balancer. The group argued that SAMMs were widely recognized, while PAMMs remained less understood, making them a useful focus for education and research. An introductory article on PAMMs and SAMMs was being prepared to create a foundation for future content.
The update also described progress on case studies. The group had developed a framework for analyzing PAMM examples and had already completed several case studies, with plans to refine them so they could be compared more easily. This work was intended to support deeper understanding of how primary issuance and redemption mechanisms had been used across different projects.
On the technical side, the bonding curve analysis team had developed a Python bonding curve simulation and made it available through GitHub. The group planned to pull data from Dune for both the TEC bonding curve and the Honeyswap pool, then run a historical simulation of the TEC economy from the perspectives of the bonding curve and the secondary market pool. The analysis would examine execution price, market depth, and arbitrage opportunities over time.
To support this work, the group created an additional Dune dashboard focused on bonding curve data. The data would be wrapped and pulled into Python, and the group was documenting the method for moving from Dune queries into a Python-based simulation environment. This continued the earlier goal of turning TEC’s ABC into a more analyzable case study for token engineering research.
The update also described public outreach. The group was sharing work through a public Notion document and a new Twitter page, with plans to increase engagement as more content was published. A new contributor had joined the group, and the update noted that the group had participated in Gitcoin grant rounds, receiving contributions from 23 donors and waiting on matching funds. After receiving matching funds, the group planned to apply for the next six weeks of TEC funding through Tao Voting.
By the end of the thread, the second update showed the Bonding Curve Research Group moving from setup into substantive research production. The group had clarified its conceptual focus on PAMMs, begun a case study framework, built early Python simulation infrastructure, expanded Dune-based data work, created public outreach channels, and started seeking additional funding through Gitcoin and future TEC governance.
2023-05-19 — TEC Rewards Distribution: Round 31
Forum thread: TEC Rewards Distribution - Round 31 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, TEA-TEC integration, reputation systems, Twitter Praise, treasury management
May 19, 2023
This Rewards Distribution thread published Round 31, covering Praise given between April 18 and May 5, 2023. The round allocated 261.35 TEC tokens for rewards and continued using the distribution system that boosted non-paid contributors. As in earlier rounds, the post noted that some Praise accounts had not been activated, so the final distributed amount could be lower than the total amount set aside.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. The highlighted work again centered on the Joint TEA-TEC AMA and the extensive effort behind the joint strategy. Other recognized contributions included improving the security of TEC Twitter credentials, resolving a Praise accounting issue, proposing treasury diversification into ETH, supporting the Twitter Praise proposal, and participating in reputation systems discussions and public educational sessions.
By the end of the thread, Round 31 showed the rewards system continuing to recognize the same strategic workstreams that dominated TEC’s spring 2023 period: TEA-TEC integration, operational security, Praise infrastructure, treasury management, reputation research, and public-facing discussion around the future of the Commons.
2023-06-08 to 2023-07-25 — Buying wstETH to Diversify Our Treasury
Forum thread: Buying wstETH to diversify our treasury - Funding Proposal Category: Advice Process / Archive Archive theme: Treasury diversification, wstETH, liquid staking tokens, stablecoin risk, Common Pool, Gnosis Chain, Tao Voting, treasury management
June 8, 2023
A funding proposal was opened to convert 100,000 wxDAI from TEC’s treasury into wstETH as a diversification measure. The proposal followed the earlier temperature check about buying ETH to protect against xDai and stablecoin risks. It was motivated by the March 2023 stablecoin depeg event, which exposed TEC’s treasury to the risks of holding nearly all Common Pool funds in xDai or related pegged assets.
The proposal argued that wstETH was the practical liquid staking option available on Gnosis Chain at the time. Gnosis Chain was beginning to receive incentives for wstETH liquidity through Agave and Balancer, which made the timing more favorable. The goal was not to solve TEC’s long-term revenue problem, but to protect the treasury by holding another asset that was not directly dependent on DAI or xDai while also earning staking yield.
Because 100,000 dollars was a large trade relative to available liquidity, the proposal laid out several possible execution paths. One option was to create a temporary multisig taskforce to buy wstETH gradually over roughly ten weeks, sending the acquired wstETH directly to the DAO after each purchase. Another option was to arrange a direct token swap with a large Gnosis Chain holder. A third option was to bridge wxDAI to Ethereum, buy wstETH where liquidity was deeper, and bridge it back. In all cases, the funds would remain accessible from the DAO, and future proposals could request funds denominated in wstETH.
June 9 to July 4, 2023
The early discussion supported the basic idea of treasury diversification but questioned the choice of wstETH. One concern was Lido’s share of the Ethereum staking market and whether TEC should prefer another liquid staking token such as sfrxETH. The response acknowledged the concern but explained that the practical constraint was availability on Gnosis Chain. The proposal committed to revisiting liquid staking token diversity if other options became available on Gnosis.
The discussion also clarified that the proposal should not be understood as a sustainability strategy by itself. The expected yield would not be enough to fund TEC operations. Instead, the purpose was resilience: holding another asset in case something happened to DAI, while still keeping the funds available to the DAO for future proposals.
When the proposal moved to voting, the execution plan involved a temporary 3-of-4 multisig. This raised concern because 100,000 dollars was a large amount to hold in a small multisig, even temporarily. The response explained that the plan was to purchase as quickly as practical and transfer the resulting wstETH to the DAO after each purchase. The execution strategy had also shifted toward several weekly swaps because liquidity had improved on Balancer.
The thread also clarified that after Conviction Voting had been shut down, requesting wstETH or another non-wxDAI token through governance would require more technical interfaces such as the in-Gardens EVM Executor or EVMcrispr. This meant the asset would be governable, but not especially user-friendly for ordinary proposal authors.
July 25, 2023
A later follow-up asked for an update on the status of the proposal. The response explained that the proposal had not passed. The timing was not ideal because many community members were away for conferences, and some token holders abstained because they had not had time to fully understand wstETH and its risks. The proposal author indicated that the idea would still be pursued later, but likely after waiting a few weeks or months.
By the end of the thread, the wstETH proposal had not succeeded, but it documented an important stage in TEC’s treasury-management evolution. The community had moved from a general concern about stablecoin risk to a concrete diversification proposal, while also surfacing practical governance, custody, liquidity, execution, and voter-education challenges involved in managing a more complex DAO treasury.
2023-06-16 — TEC Rewards Distribution: Round 32
Forum thread: TEC Rewards Distribution - Round 32 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, contributor recognition, continued rewards operations
June 16, 2023
This Rewards Distribution thread published Round 32, covering Praise given between May 9 and June 2, 2023. The round allocated 253.5121612 TEC tokens for rewards and continued using the distribution system that boosted non-paid contributors. As in earlier rounds, the post noted that some Praise accounts had not been activated, so the final distributed amount could be lower than the total amount set aside.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
Unlike some previous rounds, the thread did not include a separate follow-up summary of the highest-rated contributions. Its main archival value is therefore operational: it shows the Rewards process continuing into June 2023, with TEC still using Praise quantification, Reward Board review, and non-paid contributor boosts to recognize work during the Commons’ governance and strategy transition period.
2023-07-11 to 2023-07-24 — TE Grants Round 2 and 3 Funding Proposal
Forum thread: TE Grants Round 2 & 3 Funding Proposal Category: Advice Process / Archive Archive theme: Token Engineering Grants Program, Gitcoin Grant Stack, quadratic funding, matching pools, ENS grant, featured rounds, public goods funding
July 11, 2023
A funding proposal was opened to continue the Token Engineering Grants Program with two additional 25,000 dollar matching pool rounds for the remainder of 2023. The proposal built on the first grants round, which had used Gitcoin’s Grant Stack and was described as a success. In that first round, 86 unique donors helped direct a 25,000 dollar matching pool by contributing more than 6,000 dollars in donations.
The proposal argued that TEC should continue funding token engineering public goods by securing two more matching rounds. The total cost was estimated at 52,500 dollars, including two 25,000 dollar matching pools, an entry tribute associated with TEC purchases that would return to the Common Pool, and a Gitcoin fee for being a featured round. Because TEC had received 25,000 dollars from an ENS Large Grant round, the requested amount from TEC was reduced to 27,500 dollars.
The thread explained that the 25,000 dollar round size was important because it was the minimum required to qualify as a featured round organized through Gitcoin. Maintaining featured round status would help TEC benefit from Gitcoin’s broader visibility and donor flows, while continuing to test quadratic funding as a way to support early-stage token engineering projects.
The proposal framed the grants program as a way to make public goods funding more dynamic and sustainable. Matching funds could stretch the Common Pool by stimulating outside donations, attract additional funding partners, give TEC more experience running quadratic-style grantmaking processes, and increase awareness of token engineering in the broader Web3 ecosystem. All matching funds would go to grant recipients, while the Coordination Team’s existing operating budget would cover the work required to develop, launch, and run the rounds.
July 24, 2023
The thread was updated to announce that the vote for the proposal was live. By the end of the thread, the second and third grants rounds had been positioned as the continuation of TEC’s shift away from one-off direct funding toward recurring matching rounds that could combine Common Pool resources, external grants, donor participation, and Gitcoin infrastructure to support token engineering public goods.
2023-07-26 to 2023-07-27 — Results of TE Grants Round 1
Forum thread: Results of TE Grants Round 1 Category: Grants Program Archive theme: TE Grants Program, quadratic funding, Gitcoin Beta Round, TE Matching Boost, $TEC utility, TE Academy certificates, public goods funding, round results
July 26, 2023
A results thread was opened to report on the first round of the Token Engineering Grants Program. The round had run during the Gitcoin Beta Round from April 25 to May 9 as a featured round, with matching funds coming primarily from TEC’s Common Pool and additional support from an ENS small grant. The post framed the first round as a success and presented the key statistics and project allocations.
The round used a 25,000 dollar matching pool, a 30 percent matching cap, and a two-times coefficient multiplier for the TE Matching Boost. The round included 16 projects, 86 unique donors, 257 total contributions, 6,161.85 dollars raised from donors, and an average contribution of 71.65 dollars.
The thread introduced the TE Matching Boost as an experiment in using donor qualifications to influence matching outcomes. Donors who held at least 10 TEC or held a Token Engineering Academy certificate were eligible for additional matching on their contributions. The stated purpose was to recognize people who were already betting on the token engineering field and to inject a form of subject matter alignment or expertise into the allocation process. Of the 86 unique donors, 19 held TEC and 8 held a TE Academy certificate.
The results section listed the payout distribution across the participating projects. Projects receiving support included Oxcart Applied Research, Commons Stack, ITU Blockchain, a Python library for token engineering, the Bonding Curves Research Group, cadCAD, TE Barcamp at EthCC Paris, EVMcrispr, Token Launch Simulator, the Token Engineering Knowledge Commons, Index Wallets, research on a utility token for the TE ecosystem, Tokenomics Design Space, Token Research Collaborative, DeFinomics Labs, and burn-and-mint tokenomics. The total payout was reported in TEC.
The post then pointed toward the next grants round, which had already been announced with a similar configuration and matching size. It invited grantees, interested projects, and potential sponsors to contact the grants program and asked for feedback on how to improve future rounds.
July 27, 2023
A follow-up added that a Medium write-up had been published to explain the round and the role of expertise in quadratic funding, and included a pie chart showing the distribution of total funding.
By the end of the thread, Round 1 had become an important proof point for the new grants strategy. TEC had successfully run a Gitcoin-based quadratic funding round, tested a TEC and TEA-aligned matching boost, attracted donor participation, distributed funds to a broad set of token engineering projects, and established a foundation for continuing the grants program through later rounds.
2023-07-26 — TEC Rewards Distribution: Round 33
Forum thread: TEC Rewards Distirbution - Round 33 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, Stakeholder Study, Optimism Growth Grant, treasury diversification, Dune dashboard
July 26, 2023
This Rewards Distribution thread published Round 33, covering Praise given between June 12 and July 13, 2023. The round allocated 656.497 TEC tokens for rewards and continued using the distribution system that boosted non-paid contributors. As in earlier rounds, the post noted that some Praise accounts had not been activated, so the final distributed amount could be lower than the total amount set aside.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
A follow-up comment summarized the ten highest-rated contributions for the round. These focused on the Token Engineering Stakeholder Study, including its presentation at ETH Barcelona and leadership in driving the research forward. Other highly rated contributions included work on an Optimism Growth Grant for TEC, development of a future TEC roadmap and TE Academy merger direction, updates to the TEC Dune Dashboard to fix tribute calculations, and the proposal to buy staked ETH as part of treasury protection.
By the end of the thread, Round 33 showed TEC rewarding work tied to its mid-2023 strategic priorities: stakeholder research, external grant-seeking, roadmap development, TEA integration, treasury diversification, and improved analytics around TEC’s economic history.
2023-08-02 to 2024-06-19 — Strengths and Weaknesses of Conviction Voting and Other Mechanisms
Forum thread: Strengths and Weaknesses of Conviction Voting and Other Mechanisms Category: TE Discussion Archive theme: Conviction Voting, Quadratic Funding, mechanism design, low-pass filters, social choice, governance education, funding mechanism analysis
August 2, 2023
A Token Engineering discussion was opened to ask for a clearer explanation of the strengths, weaknesses, and objective function of Conviction Voting. The thread began from the premise that no mechanism is perfect and that every governance or funding mechanism works better in some contexts than others. The post argued that the token engineering community should become more adversarial and pragmatic when evaluating mechanisms, especially those it uses in practice.
The initial post used Quadratic Funding as an example of the kind of explanation being requested. It described the public goods funding problem QF tries to address, sketched the basic square-root calculation, and then listed strengths and weaknesses such as democratic weighting, sybil vulnerability, collusion risk, ethical assumptions, and cognitive complexity. The request was for a similarly concise explanation of Conviction Voting so that non-specialists could better understand what problem it was meant to solve and where it might fail.
The thread then clarified that Conviction Voting should be separated into two parts: a signal aggregation mechanism and a trigger function. The signal aggregation component was described as conceptually related to a low-pass filter, introducing inertia and smoothing into governance signals. The trigger function, by contrast, was the context-specific controller that determines when a proposal crosses a funding threshold. This distinction helped separate the broader idea of conviction accumulation from TEC’s particular use of it as a financial valve for Common Pool spending.
The discussion framed the main strength of Conviction Voting as also its main weakness: it gives proposals inertia. That inertia can filter out impulsive short-term signals and create stability, but it can also create delay, information loss, oversimplification, and tuning difficulties. The thread connected this to broader engineering ideas such as passivity, dissipation, feedback systems, and the need to tune regulatory mechanisms to their specific context.
August 2 to August 14, 2023
The conversation then broadened into social choice theory and mechanism comparison. Arrow’s Impossibility Theorem was introduced as another way to explain why no voting system can satisfy all fairness criteria at once. The discussion treated this not as a reason to avoid mechanism design, but as a reason to be explicit about tradeoffs.
The thread also examined Quadratic Funding and TEC’s use of subject-matter-expert signal boosts. A corrected formula clarified that the expertise coefficient applies to the voter or donor signal rather than directly to the project. This turned part of the thread into a practical conversation about how to express TEC’s grants mechanism clearly in code and how to make mechanism explanations accessible to both technical and non-technical participants.
The discussion then returned to TEC’s lived experience with Conviction Voting. One analysis argued that TEC’s use of an “abstain” proposal had helped slow the rate of conviction growth by increasing the pool of allocated conviction. But when voters moved conviction away from abstain to support a proposal and did not return it afterward, the system could unexpectedly speed up other proposals. This helped explain why some proposals with relatively low visible support could suddenly pass.
Another reflection argued that Conviction Voting may work best when there are many competing proposals and a well-funded or replenishing pool. Without a competitive proposal environment, conviction can concentrate on the few available proposals. Without replenishment, the mechanism may create a built-in bias toward draining the pool over time. This helped explain why TEC eventually moved toward budgeted Quadratic Funding while it worked to rebuild financial sustainability.
The thread also developed an analogy between mechanism design and automobile design. Designers, testers, manufacturers, drivers, and dealers all need different kinds of knowledge. In the TEC context, voters and proposal authors do not necessarily need to understand every mathematical detail, but they do need a kind of driver’s manual for safe governance participation. This made mechanism communication and education a central theme of the thread.
August 21 to October 17, 2023
The thread continued with more implementation-oriented discussion around Quadratic Funding calculations. Formula corrections, dataframe implementations, vectorization, and early software tooling were discussed as ways to support TEC’s QF and subject-matter-expert signal processing. This shifted the thread from conceptual mechanism explanation into the practical tooling needed to compute and inspect funding allocations.
The discussion also explored whether dataframes and spreadsheet-like interfaces could help non-programmers experiment with mechanism parameters. Rather than hiding everything behind a polished interface, the idea was that low-friction but visible data structures could help contributors understand how mechanism calculations actually work.
Later, the thread returned to the low-pass filter analogy. Charge-and-discharge systems, stocks and flows, bathtubs, capacitors, and other physical examples were used to clarify how inertia-like behavior might appear in natural and engineered systems. This led to discussion of whether Quadratic Funding is better understood as a static optimization criterion, while Conviction Voting has clearer low-pass-filter properties because it includes a temporal component.
The thread also raised the possibility of combining ideas into Quadratic Conviction Funding or other continuous funding mechanisms. One imagined design would allow participants to set ongoing preferences across workstreams, with the system remembering preferences and periodically applying quadratic calculations. This connected the discussion back to user experience, donor attention costs, streaming funding, and investable workstreams.
June 19, 2024
The thread was revived with a focused analysis of TEC’s Conviction Voting experience. The update argued that the use of effective supply as the denominator in Conviction Voting helped explain some of the unexpected behavior TEC observed. When active voting participation dropped, the effective supply decreased, which made the same amount of conviction represent a larger share of the denominator and could cause proposals to cross the threshold more suddenly.
The analysis revisited the abstain hack in this light. The abstain proposal increased effective supply and therefore raised the amount of conviction required for other proposals to pass. But if voters removed tokens from abstain and did not return them, effective supply could fall quickly and unexpectedly lower the threshold. A reply suggested that this may have created an inadvertent bypass around the intended low-pass-filter behavior, and that ramp or delay-line approaches might help address such sudden changes.
By the end of the thread, the discussion had become a rich public postmortem on TEC’s use of Conviction Voting and related funding mechanisms. It clarified the distinction between signal aggregation and trigger functions, explored low-pass-filter analogies, compared CV with QF, identified problems from abstain dynamics and effective supply, connected mechanism design to governance education, and pointed toward future research on adaptive, continuous, and more legible funding systems.
2023-09-01 — TEC Coordination Team Impact Tracker Report: April to August 2023
Forum thread: TEC Coordination Team Impact Tracker Report (April - August 2023) Category: Community Updates Archive theme: Coordination Team, impact tracking, TE Grants Program, Gitcoin, TE Matching Boost, ENS grant, advisory network, budgeting, TEC-TEA merger, Common Pool sustainability
September 1, 2023
A Coordination Team impact tracker report was published covering work from April through August 2023. The report reviewed progress against commitments from the team’s previous funding proposal while also documenting additional initiatives that had emerged during the same period. It was framed as a transparency and accountability report, and it included a community performance poll so members could provide feedback on the team’s recent work.
The report first reviewed the commitments made in the previous proposal. The Coordination Team had successfully launched and executed the first Gitcoin quadratic funding round focused exclusively on token engineering. That round supported public goods related to education, research, and tooling, distributing more than 31,000 dollars across sixteen projects. The report also pointed to a deeper analysis of the round and its lessons.
The team also integrated Token Engineering Academy NFT proofs into the grant program through a TE Matching Boost. This experiment gave boosted matching weight to donations from wallets holding TEC tokens or TEA graduate NFTs, allowing the round to incorporate a form of subject matter expertise and field alignment into quadratic funding. The report framed this as an innovation in public goods funding design.
Another major commitment was external fundraising for the grants program. The Coordination Team secured a 50,000 dollar ENS Large Grant on behalf of TEC and TEA, with proceeds split evenly between the two organizations. TEC’s share helped fund upcoming grants rounds and reduced reliance on the Common Pool. This was presented as a step toward making the grants program financially sustainable by sourcing matching funds externally rather than continuously drawing from TEC’s own treasury.
The report also noted progress toward scalable community organizing and engagement. A TEC Advisory Network was beginning to take shape through recurring calls among key community members, with less direct involvement from the Coordination Team. The report indicated that more formal communication would follow to define the network’s purpose and structure.
The additional impact section focused heavily on the growth of the TE Grants Program. The team had passed a new proposal to fund Rounds 2 and 3, then planned and executed Round 2. That round distributed a little over 30,000 dollars across fourteen projects and greatly expanded reach. Unique donors and total contributions increased dramatically compared with the first round, even though the average contribution was smaller. The report interpreted this as evidence of broader awareness and growing interest in token engineering public goods.
The grants work also improved TEC’s public visibility. TEC’s Twitter account gained followers and saw a major increase in engagement, with posts regularly passing levels of visibility that had previously been rare. The team deepened its partnership with Gitcoin, participated in Gitcoin’s promotional efforts, provided feedback on Grant Stack, and created a playbook for planning and executing future rounds more efficiently.
The report also noted that TEC submitted its own grant application during GG18 in the Web3 Community and Education round, offering a large matching pool and ranking strongly among hundreds of projects. Separately, the Coordination Team had extended its own operating budget by an extra month through conservative spending, improved budgeting, better forecasting, and a simplified compensation structure. This allowed the team to avoid interrupting grants execution with another funding request.
Finally, the report acknowledged that despite significant effort, TEC and Token Engineering Academy had not found a mutually acceptable path to merge. TEA was instead exploring a path toward being run by its students. This marked an important shift from earlier merger ambitions toward a more separate organizational direction.
By the end of the thread, the April to August impact tracker showed the Coordination Team’s focus moving from internal stabilization toward external funding, grants operations, public visibility, and ecosystem partnerships. It also documented the limits of the TEA merger effort and the emergence of the TEC Advisory Network as a possible next governance and coordination structure.
2023-09-14 to 2023-09-18 — TEC Rewards Distribution: Round 34
Forum thread: TEC Rewards Distribution - round-34 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, TE Barcamp, EthCC, TE Stakeholder Study, TE AI, conference participation
September 14, 2023
This Rewards Distribution thread published Round 34, covering Praise given between July 14 and August 21, 2023. The round allocated 766.4987833 TEC tokens for rewards and continued using the distribution system that boosted non-paid contributors. As in earlier rounds, the post noted that some Praise accounts had not been activated, so the final distributed amount could be lower than the total amount set aside.
The distribution followed the standard rewards formula: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board, submitted to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
September 18, 2023
A follow-up comment summarized the ten highest-rated Praise instances for the round. The recognized work centered heavily on TE Barcamp, EthCC presentations, and the Token Engineering Stakeholder Study. Contributions included planning and executing TE Barcamp, presenting at EthCC and TE Barcamp, sharing results from the stakeholder study, leading TEC through its transition, advancing TE Academy and decentralized education, presenting work on TE AI, and representing TEC at a major crypto conference.
By the end of the thread, Round 34 showed TEC’s rewards process recognizing outward-facing field-building work. The most visible contributions were no longer only internal operations, but public conference participation, ecosystem presentations, TEA collaboration, stakeholder research, and educational events that helped position token engineering more broadly.
2023-09-22 — Introducing the TEC Advisory Network
Forum thread: Introducing the TEC Advisory Network (TECAN) Category: Community Updates Archive theme: TEC Advisory Network, TECAN, advice process, subject matter experts, strategic planning, Coordination Team, advisory groups
September 22, 2023
A community update introduced the TEC Advisory Network, or TECAN, as a formalization of the informal advisory relationships that had grown around the Coordination Team. The thread framed TECAN as a natural evolution of TEC’s advice process: instead of relying only on ad hoc feedback, TEC would create a more structured network of committed subject matter experts who could provide strategic guidance, feedback loops, ecosystem connections, and broader perspective.
The context was that the Coordination Team was responsible for planning and executing TEC’s day-to-day work and major initiatives, including the recent Gitcoin grants rounds and experiments with incorporating expertise into quadratic funding. Without a formal advisory group, the team had been relying on individuals for strategic advice and domain knowledge. The thread argued that TEC would benefit from widening and structuring that access to expertise.
The first iteration of TECAN would be TECAN-Strategy. This group was made up primarily of people who had already been actively advising and supporting the Coordination Team. Its purpose was to help prioritize and plan projects over a three- to nine-month horizon, act as a first line of advice process before topics moved into broader forum discussion, and serve as a bridge between TEC and other ecosystem projects. An example given was that a possible migration to Optimism could first be discussed with TECAN-Strategy before moving to the wider community advice process.
TECAN-Strategy commitments included serving as an advisor for one year, attending regular strategic meetings, directly supporting Coordination Team or TEC initiatives such as the Stakeholder Study, Bonding Curve Research Group, and TE Study Groups, and participating in feedback loops with future advisory groups. A monthly call would also be open to extended advisors and subject matter experts.
The thread clarified that advisory roles would not be directly compensated. Advisors could still receive Praise from the community, but the role itself was framed as voluntary service to the token engineering community. The post also imagined future advisory groups, such as a technical token engineering group, and possibly later groups focused on governance, reputation, or AI.
By the end of the thread, TECAN marked a shift from informal advice toward more explicit advisory infrastructure. It created a way for TEC to involve trusted subject matter experts in strategic planning without making them part of the Coordination Team, while also preserving the broader community advice process for major decisions.
2023-09-27 to 2024-03-25 — Community Advice Process on TEC Migration to Optimism
Forum thread: Community Advice Process on TEC Migration to Optimism Category: TEC Strategy & Governance Archive theme: Optimism migration, advice process, Gnosis Chain, Tao Voting, Guardians, reserve currency, smart contract token holdings, WATER liquidity
September 27, 2023
A community advice process thread was opened to begin a broad discussion about migrating TEC from Gnosis Chain to Optimism. The context was that Commons Stack had received an Optimism grant to port Aragon client and Commons DAO tooling, including the Augmented Bonding Curve, to Optimism. This created the possibility that TEC could move its economic and governance infrastructure from Gnosis Chain to OP Mainnet.
The post made clear that it was not a complete assessment. Instead, it was meant to share initial thinking, identify major community decisions, describe risks and benefits, and outline a high-level sequence of events if the community wanted to proceed.
The initial case for migration focused on several advantages. First, buying TEC on Gnosis had become high-friction because users needed to be on Gnosis, acquire xDAI, wrap it, and then use wxDAI to buy TEC. Moving to Optimism could make acquisition easier depending on the reserve asset chosen for the ABC. Second, Optimism had substantially more capital and stronger centralized exchange integrations than Gnosis. Third, Optimism offered broader DeFi access. Fourth, migration could reduce exposure to concerns already raised about reliance on xDAI. Finally, Optimism’s public-goods funding culture was described as strongly aligned with TEC’s mission.
The main risks were described as manageable but real. Migration would involve moving significant funds cross-chain and temporarily placing treasury assets into multisigs on Gnosis, Mainnet, and Optimism. The thread suggested that careful bridge selection, testing, and trusted multisig configurations could reduce those risks.
The advice process identified several decisions the community would need to make. Because Celeste was not available on Optimism, TEC would need Guardians to uphold the Community Covenant and veto proposals that violated it. The community would also need to choose a new ABC reserve currency, decide whether to keep or change Tao Voting parameters, and handle TEC held inside smart contracts such as liquidity pools and Safes. Other topics, such as a future reputation token or making the ABC private to TEC, were identified as interesting but outside the immediate scope of technical migration.
The proposed timeline had three phases: advice process through October, planning in October and November, and vote and execution around late November or December. Additional votes would likely be needed for the covenant update, WATER and GIV liquidity positions, and Guardian selection.
October 3 to October 11, 2023
The early discussion was broadly supportive of exploring the migration. Replies emphasized that Gnosis Chain had become increasingly limiting for TEC because of friction, lower visibility, lower liquidity, and dependence on wxDAI. Optimism was seen as a more vibrant and mission-aligned ecosystem, although some comments cautioned that migration alone would not automatically create buying pressure or liquidity for TEC.
The discussion then turned to practical complications. One concern was whether TEC held in smart contracts needed to be handled through a coordinated migration, or whether a one-way migration contract could allow holders to migrate later at their convenience. The response explained that freezing Gnosis TEC and enabling the full token supply on Optimism would help preserve control of migrated funds, keep bonding curve pricing coherent, and avoid disruption from locked or stranded tokens.
The WATER liquidity position also surfaced as an important issue. The thread clarified that removing TEC from the WATER shared liquidity arrangement would likely require paying a 15 percent exit fee under the existing agreement. This introduced another governance and relationship consideration into the migration plan.
March 25, 2024
A later follow-up pointed readers to the post-migration announcement for updated information and congratulated the community on completing the migration.
By the end of the thread, the community advice process had served as the starting point for TEC’s Optimism migration. It framed the migration’s purpose, benefits, risks, required decisions, and timeline. It also foreshadowed many later threads: technical migration funding, reserve currency selection, Guardian nominations, WATER exit planning, token census work, covenant updates, and the final migration execution.
2023-09-29 to 2024-01-15 — Funding Proposal for Technical Migration of TEC to Optimism
Forum thread: Funding proposal for technical migration of TEC to Optimism Category: Tao Voting / Archive Archive theme: Optimism migration, technical funding, Tao Voting DAO, token census, migration rehearsal, Guardians, ABC migration, rETH reserve
September 29, 2023
A Tao Voting funding proposal was opened to support the technical work required to migrate TEC from Gnosis Chain to Optimism. The proposal argued that migration would reduce friction for buying TEC, improve access to capital, and position TEC for potential retroactive public goods funding within the Optimism ecosystem.
The proposal explained that because Gardens was not available on Optimism, TEC would need to migrate from a Gardens DAO on Gnosis to a Tao Voting DAO on Optimism. The new DAO would still be based on the Aragon OS framework and would preserve several familiar features, including token-based governance, delegated voting, and compatibility with an Augmented Bonding Curve. However, there would also be key differences. Because Celeste was not available on Optimism, TEC would need to choose Guardians who could veto proposals that violated the Community Covenant. Funding decisions would move away from Conviction Voting and toward Tao Voting with parameters suited to Common Pool management, while other decisions could use more hardened Tao Voting settings.
The migration plan also included future flexibility for multiple governance tokens, making it easier to introduce non-transferable reputation tokens if the community later chose to do so. The proposal promised a more detailed DAO architecture specification as one of the funded deliverables.
A major part of the work was a TEC tokenholder census and migration strategy. The team would identify liquidity pools, Safes, and other contracts holding TEC, then recommend strategies so owners could receive the same amount of TEC on Optimism. Some strategies could be passive, based on determining underlying owners, while others would require contract owners or LP holders to take action before migration.
The proposal requested 15,000 wxDAI in total. The first 6,000 wxDAI would fund the tokenholder census and DAO architecture specification. The remaining 9,000 wxDAI would fund the rehearsal test and actual migration. The planned tasks included preparing the census and strategies, preparing the vote to move Common Pool and Reserve funds while freezing the Gnosis TEC token, and creating the Tao Voting DAO on Optimism with matching token distribution and an Augmented Bonding Curve ready to open after funds arrived.
Success was defined as successfully migrating funds from the Gnosis Gardens DAO to Optimism, giving token holders the same TEC balances on Optimism, making the Gnosis TEC token non-transferable, and resuming normal operations after a short migration window. Progress would be shared through three deliverables: the tokenholder census and migration strategy, the new DAO specification, and the rehearsal test results.
October 2 to October 17, 2023
Early feedback supported funding the initial technical planning phase before committing to the full migration. The proposal was praised for breaking the migration into manageable pieces. The vote then went live on Gardens.
The proposal was challenged in Celeste. The challenge argued that the migration had not been fully thought through, could affect WATER liquidity, introduced Optimism-specific risks, moved away from Conviction Voting, and would require a Community Covenant revision. The response argued that the proposal being challenged was not the final migration itself, but a funding request to produce the analysis needed to migrate with less harm and more clarity. The response emphasized that the migration had been openly discussed and that the work would produce a tokenholder strategy and DAO architecture so the community could make a better-informed decision.
A follow-up acknowledged that the migration did need more detailed analysis, and argued that this was precisely why the technical feasibility study was needed. The discussion also clarified that the Conviction Voting decision had already been addressed months earlier, and that a covenant revision had already been identified as part of the migration process.
The thread then explored the technical base for the new DAO. A question was raised about whether TEC should use legacy Aragon OS or Aragon OS X. The answer clarified that the proposed system would use a well-tested Tao Voting instance based on an upgraded version of Aragon OS, rather than a completely new OS X deployment.
December 3 to December 18, 2023
After the tokenholder census and new DAO specification were delivered using the initial 6,000 wxDAI, the thread requested the remaining 9,000 wxDAI to conduct the rehearsal test and actual migration. If approved, the community would prepare to migrate into the specified Tao Voting DAO, run a rehearsal, and then create another vote to freeze the token and move all funds.
A later update linked to the results of the rehearsal tests, showing that the technical migration process had moved from planning into operational testing.
January 15, 2024
After the migration succeeded, a final update requested reimbursement for fees incurred during the migration. The reimbursement would be handled through a vote on the new DAO.
By the end of the thread, the technical migration proposal had funded the practical bridge from concept to execution. It covered the census, DAO specification, migration strategy, rehearsal, final migration preparation, and post-migration reimbursement. The thread captured the technical and governance complexity of moving TEC from Gnosis to Optimism while preserving token balances, updating dispute architecture, changing governance tooling, migrating treasury funds, and preparing the Augmented Bonding Curve for the new reserve environment.
2023-10-02 to 2023-12-12 — Should the TEC Change Its Reserve Currency?
Forum thread: Should the TEC change our reserve currency? Category: Advice Process / Archive Archive theme: Reserve currency, Optimism migration, ABC reserve asset, rETH, stETH, LSTs, stablecoins, treasury risk, token mechanics
October 2 to October 5, 2023
An advice process thread was opened to discuss what reserve currency TEC should use if it migrated to Optimism. The question was necessary because the Augmented Bonding Curve would need a reserve asset on the new chain, and the choice of asset would shape the economic behavior of TEC after migration.
The early discussion framed the decision as a two-step question. First, the community needed to decide what type of asset should back the bonding curve: a stablecoin, ETH or a liquid staking derivative, or some other token. Second, if the community chose a category, it would need to select the specific asset within that category.
Stablecoins were described as useful because they reduce exposure to crypto market volatility and simplify treasury management. The existing wxDAI reserve had helped TEC during a bear market by keeping the reserve asset relatively stable. At the same time, concerns about DAI, issuer risk, regulatory risk, and the desire for diversification created a strong argument for considering ETH or a liquid staking token instead.
An ETH or liquid staking token reserve was presented as a way for TEC to gain upside exposure to broader crypto market recovery. A yield-bearing ETH derivative could also allow the reserve to grow over time, while keeping the Common Pool in stables if needed. The discussion emphasized that whatever asset was chosen, TEC should also think about future mechanisms for swapping or diversifying the reserve, because protocols and token standards can change over time.
October 27 to November 3, 2023
A later synthesis post summarized the state of the discussion and a TEC Advisory Network conversation. The community was considering stablecoins, ETH, liquid staking derivatives such as Lido or Rocket Pool assets, and more complex portfolio or liquidity-pool-share options. The portfolio option was largely treated as too complicated for the migration scope.
The thread explored the advantages and disadvantages of liquid staking derivatives. Their advantages included yield, ETH exposure, potential outperformance relative to plain ETH, and the possibility that bonding curve tribute flows could feed the Common Pool while the reserve asset accrued value. Their disadvantages included added user friction, front-end complexity, protocol risk, withdrawal mechanics, and the need to choose between more established but centralization-concerned options and more decentralized alternatives.
The discussion also clarified that the Reserve Pool and Common Pool did not need to use the same asset. The ABC reserve could be an ETH staking derivative while the Common Pool remained in stable assets. This separated the question of collateral backing from the question of operating liquidity.
Several risks were raised for evaluating any reserve asset. These included governance risk, smart contract risk, regulatory risk, protocol failure, and emergency response planning. A core mechanical question also emerged: if TEC used a volatile or interest-bearing reserve asset, TEC’s price would remain constant relative to that asset but volatile relative to dollars. This meant TEC could become more like an ETH-correlated token, and the community needed to understand how that would affect token demand, secondary markets, entry and exit tribute, and whether the ABC should remain public or become more limited.
The discussion then examined Rocket Pool more closely after concerns were raised about its tokenomics. A Rocket Pool community member joined the thread to answer questions and clarify that even if concerns applied to the RPL token, they would not necessarily threaten rETH, which is backed by ETH inside the protocol. This helped the discussion move from broad impressions toward more specific protocol-risk evaluation.
November 17 to December 12, 2023
The later discussion went deeper into the implications of using a liquid staking token as the ABC reserve. One concern was that if TEC’s value became tightly correlated with the underlying reserve asset, the token’s price would be driven more by the reserve than by supply and demand for TEC itself. This raised questions about whether bonding curve tributes still made sense, whether the ABC should be open to the public, and whether a closed or limited-access ABC could separate the treasury function from the secondary market economy.
A possible design was sketched where the ABC would become more like a treasury mechanism that could mint or burn TEC to manage supply, while secondary markets would reflect demand for TEC utility. Current token holders would retain access to the value they held at migration, but future ABC access could be governed by the Commons. The discussion did not resolve this as a formal design, but it widened the reserve-currency question into a larger conversation about TEC’s post-migration token economy.
A response suggested decomposing the issue into stakeholders, motivations, incentives, and mechanisms, then diagramming possible scenarios so the community could understand the token design more clearly.
On December 12, the thread was updated to report that the discussion had continued in a joint Coordination Team and TEC Advisory Network call. The resulting decision was to use rETH as the ABC reserve asset when TEC moved to Optimism, and this would be reflected in the technical specification for the migration.
By the end of the thread, the reserve-currency question had become one of the central economic design discussions in the Optimism migration. TEC moved from a stablecoin reserve on Gnosis toward an rETH-backed reserve on Optimism, while surfacing deeper questions about risk, yield, volatility, protocol selection, Common Pool separation, bonding curve access, secondary markets, and the future role of the ABC in TEC’s token economy.
2023-10-10 — TEC Rewards Distribution: Round 35
Forum thread: TEC Rewards Distribution - Round 35 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, non-paid contributor boost, Reward Board, quantifiers, community review
October 10, 2023
This Rewards Distribution thread published Round 35, covering Praise given between August 28 and September 18, 2023. The round allocated 397.4931286 TEC tokens for rewards and continued using the distribution system that boosted non-paid contributors. As in earlier rounds, the post noted that some Praise accounts had not been activated, so the final amount distributed could be lower than the amount initially set aside.
The distribution followed the standard rewards split. Ninety percent of tokens were allocated as Praise rewards, seven percent went to quantifiers, and three percent went to the Reward Board. The data had already been reviewed by the quantifiers and Reward Board, submitted for distribution to the Reward Board DAO, and opened for a forty-eight-hour community review period before final execution.
The post also linked to the full period analysis and included the round’s distribution table. By the end of the thread, Round 35 continued the established Praise distribution process: review the quantified Praise data, publish it for community inspection, and route the rewards through the Reward Board process for execution.
2023-10-13 — Results of TE Grants Round 2
Forum thread: Results of TE Grants Round 2 Category: Grants Program Archive theme: TE Grants, Gitcoin Beta Round, quadratic funding, matching pool, TE Matching Boost, grant results, public goods funding
October 13, 2023
A results post summarized the second round of the Token Engineering Grants Program. The round had run during the Gitcoin Beta Round from August 15 to August 29 as a Gitcoin Featured Round, with matching funds coming from TEC’s Common Pool. The post documented the round configuration, participation data, final project payouts, and next steps for future grant rounds.
The round used a 25,000 dollar matching pool, a 20 percent matching cap, and a 2x coefficient multiplier for the TE Matching Boost. This configuration reflected TEC’s ongoing experiment with combining quadratic funding with subject-matter-expert signal boosting, allowing token engineering expertise to influence matching outcomes alongside broader donor participation.
The round included fourteen projects and drew 1,837 unique donors across 2,608 contributions. Donors contributed 5,786.48 dollars in total, with an average contribution of 3.15 dollars. These numbers showed that the grants program had continued to attract broad participation after the first round, while still operating within a predictable matching budget funded by the TEC Common Pool.
The results table distributed 48,550.1464 TEC across the participating projects. The largest allocations went to the Bonding Curve Research Group, DataBites, Dynamic Optimization Algorithm for Self-regulating Tokenomics, Index Wallets, and Commons Stack. Other funded projects included EVMcrispr, volunteer recognition for Token Engineering Barcamp, cadCAD, TurtleShell, TE Career Builder for Womxn in Web3, a Python library for token engineering, Programmable Quantitative Token Model, SymVal, and HarbergerToken.
The post closed by noting that dates for the next round were still to be determined. It invited grantees, interested projects, and possible sponsors to reach out, and asked the community for feedback on how to improve future rounds.
By the end of the thread, TE Grants Round 2 had been documented as another concrete step in TEC’s transition toward structured public-goods funding. The results showed continued participation, a growing portfolio of token engineering projects, and further testing of TEC’s approach to QF enhanced by token engineering expertise.
2023-10-24 to 2023-10-25 — Taking Advantage of sDAI’s Yield With the TEC Common Pool
Forum thread: Taking advantage of sDAI’s yield with the TEC’s Common Pool Category: Tao Voting / Archive Archive theme: Common Pool, sDAI, gsDAI, treasury yield, DAI Savings Rate, Gnosis Chain, EVMcrispr, treasury management
October 24, 2023
A treasury proposal was opened to move the TEC Common Pool’s wxDAI balance into sDAI on Gnosis Chain so that the Commons could earn yield on funds it already held. At the time of the proposal, the Common Pool held 313,454.57 wxDAI. The proposal argued that moving those funds into the Gnosis version of sDAI would allow TEC to benefit from the DAI Savings Rate, with the yield passed through to sDAI holders on Gnosis.
The thread framed the move as a relatively low-effort and low-risk way to improve TEC’s financial sustainability. The estimated yield was described as meaningfully higher than the mainnet DAI Savings Rate because of the relationship between the amount of DAI in the Gnosis bridge and the amount deposited into Gnosis sDAI. At the stated rate, the Common Pool could generate an estimated additional 1,965 DAI per month.
The proposal noted that sDAI is non-rebasing, meaning the token price rises over time as yield accrues. This created an accounting consideration for future proposals, since budget requests would need to account for the changing value of the token rather than treating it as a static one-to-one balance like wxDAI.
Early discussion supported the idea but suggested that the community should poll sentiment and consider a test vote before moving the full Common Pool. The thread raised the possibility of moving less than 100 percent of the funds, such as 50 or 75 percent, rather than converting the entire balance at once. This turned the discussion from a simple yield proposal into a risk-management question about how much of the treasury should be placed into the new instrument.
October 25, 2023
The technical discussion then focused on execution. An EVMcrispr script was provided for approving the wxDAI and depositing it through the savings adapter into sDAI. A simulation showed that the proposal could be executed through DAO voting, but it also surfaced confusion around pricing and the difference between sDAI on Gnosis and sDAI on Ethereum mainnet.
The thread clarified that the Gnosis version of sDAI was a distinct token and functioned more like a savings xDAI wrapper. Because the names were confusing, the discussion suggested referring to it as gsDAI or savings xDAI to distinguish it from mainnet sDAI. The conversation also examined apparent price differences across markets, slippage concerns, and the difference between open-market liquidity and direct contract wrapping or unwrapping.
A related concern was whether the move was worth doing if TEC was already considering a migration to Optimism and changes to its Common Pool or reserve assets. The response was that even a temporary yield source could be worthwhile, especially if a single vote could generate additional treasury income before the migration occurred. It was also clarified that interacting directly with the contract should avoid ordinary market slippage.
By the end of the thread, the proposal had developed from a straightforward treasury-yield idea into a broader discussion about DAO treasury management. The community considered yield, liquidity, execution risk, naming confusion, Gnosis versus mainnet sDAI mechanics, whether to test first, whether to move the entire Common Pool, and how the opportunity related to the planned Optimism migration.
2023-11-09 to 2023-12-11 — WATER Exit Proposal
Forum thread: WATER: Exit Proposal Category: Advice Process / Archive Archive theme: WATER, Optimism migration, shared liquidity, Snapshot vote, Gnosis Chain, liquidity withdrawal, exit penalty
November 9, 2023
An advice process thread was opened to discuss formally exiting the WATER initiative if TEC proceeded with its migration to Optimism. The proposal explained that TEC had participated in WATER as an experiment in shared liquidity and aligned-token collaboration on Gnosis Chain. Because the migration would move TEC’s core token infrastructure away from Gnosis, the thread asked what TEC should do with the liquidity it had placed in WATER.
The recommended path was to withdraw TEC’s liquidity from WATER, even though doing so would trigger a 15 percent exit penalty. At the time, TEC’s position was described as roughly 38,000 TEC, worth about 16,300 dollars, with the penalty estimated at 5,700 TEC or about 2,451 dollars. The thread acknowledged that these figures could shift.
An alternative was also presented. TEC could coordinate with WATER before the migration, remove TEC from the shared liquidity system, bridge the new Optimism-era TEC token back to Gnosis, and replace the old TEC token in WATER. The proposal did not recommend that route because maintaining liquidity on Gnosis appeared to offer limited value after migration, and because the coordination overhead would be high. Still, the thread explicitly invited arguments in favor of that option.
The opening post included a poll asking whether TEC should pay the penalty and recover the remaining TEC, or migrate the TEC token back to Gnosis Chain in order to maintain the WATER position.
November 20 to November 27, 2023
After the advice process, the proposal moved to a Snapshot vote. During the discussion, a concern was raised that the penalty should not simply be accepted as inevitable. The argument was that TEC had joined the experiment in good faith, the WATER arrangement had provided limited value to TEC, and the informal agreement around exit penalties might not justify sacrificing 15 percent of TEC’s position. A suggested alternative was to petition the WATER Board to allow TEC to exit without penalty and return the full token position.
On November 27, the Snapshot vote was reported as successfully passed. The next step would be to make a formal request to the WATER team for an exit plan.
December 11, 2023
A follow-up noted that the formal request to exit WATER had been posted on the original 1Hive forum thread. By the end of the thread, TEC had moved from internal advice process to Snapshot approval and then to an external request to the WATER team.
The thread captured one of the operational consequences of the Optimism migration. Moving TEC’s center of gravity away from Gnosis Chain required the community to unwind or renegotiate legacy liquidity relationships. The WATER exit discussion combined treasury management, partnership etiquette, migration logistics, governance signaling, and the question of whether TEC should accept contractual penalties from an experiment that no longer fit its strategic direction.
2023-11-10 to 2024-04-18 — Introducing TEC Guardians
Forum thread: Introducing TEC Guardians Category: TEC Strategy & Governance Archive theme: TEC Guardians, Optimism migration, Tao Voting, veto powers, proposal safety, Community Covenant, guardian nominations
November 10, 2023
A strategy and governance thread was opened to introduce the proposed role of TEC Guardians as part of the likely migration to Optimism. The thread explained that TEC’s previous arbitration method for resolving proposal disputes would not be available on Optimism, so the new Tao Voting architecture needed a different safety mechanism.
The Guardians were described as a final line of defense for the Commons. Their role was not to approve ordinary votes or override community governance as a matter of preference. Instead, they would protect the safety and security of the Commons by delaying or vetoing proposals that violated the Community Covenant or presented an economic threat.
The thread explained the intended veto process. If a proposal passed the community vote, Guardians would have a twenty-four-hour window to delay or veto it. If a Guardian used that power, they would need to post an explanation on the forum describing the reason for the action. Because the veto window would be short, the thread also proposed fast communication channels through Discord, Telegram, or forum tagging so community members could quickly alert Guardians if they believed a proposal was dangerous.
The proposed Guardian DAO would be independent from the TEC DAO and would include seven known public members. Guardians would be selected through an open self-nomination process followed by a ranked-choice Snapshot vote. The top seven candidates would become Guardians, while the next three would serve as reservists who could fill vacancies if needed. The proposal also described a process for replacing Guardians and for holding new elections if too much time had passed or if reservists were not available.
The thread outlined suggested eligibility requirements and commitments. Guardians would need to have held TEC for more than six months, understand the responsibilities of the role, sign the Community Covenant, pledge a Guardian oath, regularly check the Guardian DAO, and hold ETH on Optimism so they could participate in Guardian DAO votes. The thread also provided a nomination template and announced the planned timeline for nominations and voting.
April 18, 2024
A later response compared the Guardian role to protector or guardian roles in legal trusts and asked whether the Guardian DAO’s powers were merely advisory or whether they represented true emergency intervention powers. The reply argued that the community should define the conditions under which a Guardian veto could pause, return, or overturn a vote, especially when emergency powers are involved.
The response also suggested that human emergency protocols require careful design and raised ideas such as reserve members, stronger legal mapping, threshold structures, and a devil’s-advocate role when veto powers are being exercised. This extended the original proposal from a practical migration safety mechanism into a deeper question about how emergency governance powers should be bounded, justified, and reviewed.
By the end of the thread, TEC Guardians had been introduced as a replacement safety layer for TEC’s post-migration governance. The thread defined the role, proposed an election and nomination process, connected Guardian authority to the Community Covenant, and opened the broader question of how a DAO should design emergency veto powers without undermining normal community governance.
2023-11-16 to 2024-01-15 — TEC Guardians Nominations
Forum thread: TEC Guardians Nominations Category: Snapshot / Archive Archive theme: Guardians, Optimism migration, Snapshot voting, Community Covenant, Guardian DAO, governance safety, veto and delay powers
November 16, 2023
A nominations thread was opened for the first election of TEC Guardians. The Guardian role was being created as part of TEC’s migration to Optimism, where Guardians would replace the previous dispute-resolution architecture and provide a safety mechanism for the new Tao Voting DAO.
The thread described the election process as community-driven and transparent. Candidates would self-nominate in the forum using a standard template, eligible candidates would be added to a Snapshot vote, and the community would select Guardians through the voting process. Nominations were scheduled from November 16 to November 23, with the Snapshot vote originally planned to open on November 24.
Eligibility requirements included holding TEC for more than six months, understanding and accepting the responsibilities of being a Guardian, signing the Community Covenant, and sharing transaction details as proof. The commitments included pledging the Guardian oath, regularly checking the Guardian DAO for votes, being available to the community for concerns or suspicious proposals, understanding how to delay or block votes, and holding ETH on Optimism in order to participate in Guardian DAO votes.
The role carried a one-time compensation of 100 TEC. The compensation was framed as enough to recognize the service but not enough to make compensation the primary motivation for serving.
November 24 to December 5, 2023
Self-nominations were posted by candidates using the template. The nominations included contact information, proof of TEC holding duration, the Guardian commitment, and Community Covenant signature proof. After nominations closed, a Snapshot vote was opened.
The voting process then went through several adjustments. The Snapshot vote was first moved to a later date. It was then restarted after the mechanism was changed from ranked-choice voting to approval voting to make the process easier. A later vote had to be redone because quorum was not met, and the new vote was extended until December 9.
This sequence showed that the community was not only selecting Guardians but also actively refining the voting process to make the election usable and legitimate.
December 11 to December 14, 2023
The final Snapshot results were announced. Seven Guardians were selected, and three alternates were named to automatically replace Guardians in order if any Guardian later departed. A few days later, the Guardians DAO was created on Optimism using the selected Guardian addresses, with parameters following the planned DAO specification.
The creation of the Guardians DAO marked a concrete step in the Optimism migration. It established the group that would hold safety powers in the new governance architecture and participate in the migration execution process.
January 15, 2024
A later update noted that the vote to distribute the 100 TEC compensation to each of the seven Guardians had been created on the TEC DAO.
By the end of the thread, TEC had moved from a proposed Guardian role to an elected and deployed Guardian DAO. The thread documented the eligibility rules, covenant commitment, nomination process, voting adjustments, final election results, creation of the Optimism Guardian DAO, and later compensation vote. It captured the governance safety layer that replaced the previous Celeste-based enforcement model after the migration to Optimism.
2023-11-22 — TEC Rewards Distribution: Round 36
Forum thread: TEC Rewards Distribution - Round 36 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, quantifiers, Reward Board, community review, reward execution
November 22, 2023
This Rewards Distribution thread published Round 36, covering Praise given between September 26 and October 16, 2023. The round allocated 335.08 TEC tokens for rewards. As in previous rounds, the post noted that some Praise accounts had not been activated, so the amount ultimately distributed could be lower than the amount initially set aside.
The distribution followed the established rewards split: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board and submitted for distribution to the Reward Board DAO. The post also linked to the full period analysis and opened the round for a forty-eight-hour community review period before final execution.
By the end of the thread, Round 36 continued TEC’s standard Praise rewards process: quantify and review Praise, publish the allocation, allow community review, and then submit the final distribution through the Reward Board process.
2023-11-23 — Fiduciary Stewardship of the TEC Common Pool: A Comprehensive Approach
Forum thread: Fiduciary Stewardship of the TEC Common Pool: A Comprehensive Approach Category: Advice Process / Archive Archive theme: Fiduciary stewardship, Common Pool, accountability policies, financial reporting, budgeting practices, TECAN, Coordination Team
November 23, 2023
An advice process thread was opened to propose a more comprehensive fiduciary stewardship framework for the TEC Common Pool. The thread began from the concern that TEC’s financial framework did not yet have enough accountability mechanisms, reporting practices, or budgeting discipline to protect the remaining Common Pool resources. The continuing depletion of the Common Pool was framed as a threat to the Commons’ mission.
The proposal connected this concern to several strategic changes that had already taken place. TEC had moved toward predictable operating budgets, set aside specific funding for public goods, and shifted funding proposals away from Conviction Voting toward Tao Voting. The thread argued that these changes were not enough on their own and that TEC needed additional mechanisms to responsibly steward its remaining capital.
The proposed solution had three parts. First, TEC would conduct an analysis of the current state of its resources, including Common Pool and Reserve Pool funds, multisigs, unused funds, liquidity positions, and active governance models. This analysis would include a SWOT assessment focused specifically on fiduciary stewardship and would be shared publicly with the community.
Second, TEC would develop fiduciary accountability policies. These would define guidelines and principles for the responsibilities of TEC token holders in managing Common Pool resources. The recommendation would be published on the forum and, if necessary, submitted to a vote.
Third, TEC would develop commons-level budgeting and reporting practices. This would include a budget with clear spending limits for annual Commons initiatives, recurring financial reports, and practices for tracking financial movements across the Common Pool and wider TEC ecosystem. These practices would be aligned with the fiduciary accountability policies.
The thread specified that the work would be carried out collaboratively by the Coordination Team and the TEC Advisory Network, with ongoing community input and refinement. By the end of the thread, fiduciary stewardship had been framed as a necessary next stage in TEC’s maturity: not merely reducing spending, but creating shared policies, analysis, budgeting processes, and reporting structures for responsible long-term management of the Commons’ remaining resources.
2023-11-25 to 2023-12-13 — Token Census Before the TEC Migration to Optimism
Forum thread: Token Census before the TEC Migration to Optimism Category: TEC / Archive Archive theme: Optimism migration, token census, contract addresses, multisigs, liquidity pools, Deposit Manager, token supply consistency
November 25, 2023
A technical migration thread published a token census before TEC’s move to Optimism. The census identified 735 addresses holding TEC as of November 23, 2023, and then focused on the contract addresses that held more than a small threshold of TEC. The purpose was to understand which token balances could require special handling before or during the migration.
The analysis identified three main types of contracts holding meaningful TEC balances. The first category was Safe multisigs. The owners of these multisigs had been contacted so they could either move their TEC or redeploy their safes on Optimism in order to receive migrated TEC properly. The second category was HoneySwap liquidity pools, which represented TEC paired with other assets on Gnosis Chain. Because the number of LP token holders was limited, the plan was to reach out to those holders individually. The third category was the Gardens Deposit Manager, where deposited amounts would be automatically returned to the appropriate owners without requiring additional action.
The census also noted that a small number of contracts collectively held less than twenty cents worth of TEC. For simplicity, these were not treated as requiring operational attention, but the equivalent amounts would still be minted on Optimism so that total token supply remained consistent.
The post included a detailed list of current Deposit Manager holders who would automatically receive TEC back, and it described the census as the first deliverable of the technical migration work. It also linked to the source code used to generate the holder data, making the census reproducible and inspectable.
December 13, 2023
The thread was updated with a revised list of contracts holding more than 0.15 TEC as of December 12, 2023. The update reflected changes in balances and added a previously omitted Reward Board multisig that had been missed because of an import error when moving the CSV into a spreadsheet. The correction acknowledged the mistake and updated the migration-relevant contract list.
By the end of the thread, the token census had established an operational map of TEC holdings before migration. It helped identify which balances were straightforward individual holdings, which were in multisigs, which were in liquidity pools, and which were held by governance infrastructure. The thread captured the practical migration work needed to preserve token balances, maintain supply consistency, and reduce the risk of leaving tokens stranded in contracts during the transition from Gnosis to Optimism.
2023-11-29 to 2024-05-19 — Optimism TEC DAO Specification
Forum thread: Optimism TEC DAO Specification Category: TEC Strategy & Governance Archive theme: Optimism migration, Tao Voting, DAO architecture, Guardians DAO, Reputation Board, rTEC, Common Pool, Reserve Pool, ABC configuration
November 29, 2023
A technical specification thread was published to describe the DAO architecture TEC would use if it migrated from its Gardens DAO on Gnosis Chain to a Tao Voting DAO on Optimism. The specification was presented as a deliverable of the technical feasibility work and as a concrete architecture for the proposed migration.
The proposed architecture used two Tao Voting instances. The first would handle broad governance powers, including app installation, permission changes, parameter adjustments, and control over core DAO functionality. The second would focus on Common Pool management and fund requests. Both voting paths would include a tollgate to discourage spam, a Tao Voting process for governance, and a delay period during which Guardians could intervene before execution.
The specification introduced the TEC Guardians DAO as an independent membership DAO designed to protect against malicious proposals. Guardians would not have special voting rights or access to DAO funds. Their authority would be limited to pausing or vetoing execution during the delay phase when a proposal violated the Community Covenant or presented economic, social, or legal risk to TEC.
The thread also described a possible future dual-token governance model involving TEC and a non-transferable reputation token, rTEC. This reputation layer would not be activated immediately after migration. If activated later, TEC and rTEC could jointly determine governance power, initially with TEC holders holding 95 percent of power and rTEC holders holding 5 percent. A separate TEC Reputation Board subDAO would be needed to oversee minting and burning of the reputation token, but the specification emphasized that both rTEC and the Reputation Board would require future community approval before activation.
The technical details then specified the Token Engineering Commons DAO, including the transferable TEC token, the non-transferable rTEC token manager, the voting aggregator, tollgates, governance and budget voting instances, delay apps, Reserve and Common Pool agents, Finance app, and Augmented Bonding Curve settings. The ABC configuration used rETH as the reserve token, a 2 percent entry tribute, a 12 percent exit tribute, and a reserve ratio near 20 percent. The thread also listed the intended permissions for the DAO, the Guardians DAO, and the future Reputation Board.
An edit later clarified that, after a TEC Advisory Network discussion, the specification had been updated to use rETH as the reserve token and a 40 TEC tollgate fee. Another edit later reflected that the Guardians DAO would be created with an Agent, without changing the overall architecture.
May 19, 2024
A later response connected the Guardians role to legal analogies around protectors or guardians in trust-like structures. The response framed the Guardians as part of a human-in-the-loop governance philosophy and raised the question of how such roles map to legal concepts of advisory versus strong protective powers.
By the end of the thread, the Optimism TEC DAO Specification had translated the migration proposal into a concrete governance architecture. It documented how TEC would structure Tao Voting, Common Pool fund requests, Guardian veto protections, the Reserve and Common Pool, ABC parameters, and possible future reputation governance on Optimism. The thread became one of the central technical references for the migration from Gnosis Chain to OP Mainnet.
2023-12-04 to 2023-12-11 — The Vote to Migrate TEC to Optimism Is Now Live
Forum thread: The vote to migrate TEC to Optimism is now live! Category: Advice Process / Archive Archive theme: Optimism migration, Tao Voting, technical specification, migration funding, Gnosis to OP Mainnet, Guardians, WATER partnership
December 4, 2023
A short announcement thread was opened to notify the community that the vote to migrate TEC from Gnosis Chain to Optimism Mainnet was live. The vote was set to run through Friday and asked the community to approve the TEC migration plan based on the previously shared technical specification.
The vote also included approval to transfer 9,000 wxDAI to the technical team so the team could test and perform the migration work. The thread clarified that this vote would not itself execute the final migration. Instead, once the team was ready, a separate Tao vote would be needed to execute the actual migration.
The announcement connected the migration vote to several related governance discussions. These included the community advice process around migration, the technical feasibility study, discussions and votes related to the WATER partnership, the new role of TEC Guardians, Guardian self-nominations, and the updated community covenant. This framed the Optimism migration as more than a technical move; it was part of a broader governance and operational transition for TEC.
December 11, 2023
A follow-up confirmed that the vote had passed and had been enacted. A dress rehearsal would be conducted that week, and the final migration target date would be set for either December or January depending on the rehearsal results.
By the end of the thread, TEC had formally approved the next major step in its migration from Gnosis Chain to Optimism. The thread captured the moment when earlier technical analysis, advice process discussions, Guardian planning, partnership considerations, and covenant updates converged into an enacted migration approval and a plan for final rehearsal before execution.
2023-12-13 — Simulating the TEC Migration to Optimism
Forum thread: Simulating the TEC Migration to Optimism Category: Community Updates Archive theme: Optimism migration, EVMcrispr, dress rehearsal, token freeze, Guardians multisig, Common Pool, Reserve Pool
December 13, 2023
A community update shared the EVMcrispr script created to simulate the vote that would freeze the TEC token on Gnosis Chain and move the DAO’s funds toward Optimism. The script represented one of the practical technical steps needed to prepare for the migration after the migration plan had been approved.
The simulated vote would connect to the TEC Garden, use surgery operations on the Token Manager and Agent apps, disable TEC token transfers, change the token controller to the Guardians multisig, and withdraw wxDAI from both the Common Pool and Reserve Pool to the migration address. After execution, the TEC token was expected to be non-transferable, while the Guardians would retain the ability to make it transferable again in an emergency.
The funds would first move into the Guardians multisig, then be sent to Mainnet, and afterward to Optimism. The post linked to the full simulation and explained that the same script would be used during the dress rehearsal to verify that the process worked as expected, and then again in the final migration vote.
By the end of the thread, the Optimism migration had moved from planning and approval into executable technical rehearsal. The thread documented how TEC intended to freeze the old token, protect emergency recovery through the Guardians, transfer treasury funds, and test the migration sequence before performing the final onchain action.
2023-12-13 to 2023-12-18 — Tao Vote: Migration to Optimism
Forum thread: Tao Vote: Migration to Optimism Category: Tao Voting Archive theme: Optimism migration, Tao Vote, token freeze, Guardians multisig, rETH reserve, DAI bridge, ABC activation
December 13, 2023
A Tao Voting thread was opened for the final vote required to migrate TEC to Optimism. The vote was based on the previously shared migration simulation and would freeze the TEC token on Gnosis while sending DAO funds to a multisig controlled by the Guardians.
The vote would make the Gnosis TEC token non-transferable, while preserving the Guardians’ ability to make it transferable again in an emergency. A snapshot of Gnosis TEC token holders would be taken, and the equivalent TEC supply would be minted on Optimism. The post warned that token holders with TEC in contracts needed to be aware of this process, and noted that multisigs and LP token holders were being contacted so they could act before migration.
The vote would also transfer DAO funds to the Guardians multisig. From there, the Guardians would unwrap wxDAI, bridge funds to Mainnet, swap the reserve portion into ETH and then rETH, keep the rest as DAI, bridge both DAI and rETH to Optimism, verify the new Tao Voting DAO architecture, send funds to the DAO, and activate the Augmented Bonding Curve. The expected timeline was that migration would finish roughly one day after vote execution.
A follow-up clarified that the onchain vote description looked cryptic because the vote involved multiple technical surgeries, including making the token non-transferable and moving funds without knowing exact balances at execution time. The simulation was provided as the more readable explanation of what the vote would do.
December 18, 2023
A later update confirmed that the vote had passed, making the next day migration day. The migration team, which overlapped with the recently elected Guardians, would receive TEC DAO funds, bridge DAI to Mainnet, swap roughly 117,000 dollars into rETH using a time-weighted average price mechanism to reduce slippage, send the remaining DAI and rETH to Optimism, mint TEC tokens on Optimism, and then send funds to the Common Pool and Reserve while opening the bonding curve.
By the end of the thread, TEC had passed the final vote needed to execute the migration. The thread documented the exact onchain transition plan: freeze the old token, snapshot balances, move funds under Guardian control, convert the reserve into rETH, bridge assets to Optimism, recreate the DAO, mint the new token supply, fund the Common Pool and Reserve Pool, and activate the new Augmented Bonding Curve.
2023-12-14 to 2023-12-15 — Vote to Migrate to OP Mainnet Is Open: What TEC Token Holders Need to Know
Forum thread: VOTE to migrate to OP Mainnet is open: What $TEC token holders need to know! Category: Tao Voting / Archive Archive theme: Optimism migration, token holder guidance, rETH reserve, ABC swap, Guardians, Community Covenant, Gnosis token freeze
December 14, 2023
A Tao Voting thread announced that the final vote to migrate TEC to OP Mainnet was open and explained what token holders needed to know before execution. The post clarified that if the vote passed, executing it would begin the starting sequence of the migration. Without any voting delay, the migration could begin as early as December 19.
The thread explained the operational implications of the migration. Once the migration started, the TEC token on Gnosis would be frozen permanently. Recreating the TEC token economy on OP Mainnet could take up to twenty-four hours, and no TEC swaps would be possible during that window. The post also noted that previous migration approval had allowed the team to finish preparations and conduct dress rehearsals, and that the rehearsals had shown positive indicators. If those indicators changed, the migration could still be halted and the token economy restored on Gnosis.
The post then translated the migration into practical instructions for token holders. A simple externally owned wallet holding TEC would receive the migrated TEC at the same address on OP Mainnet. Token holders would need to add OP Mainnet to their wallet and later import the new TEC token address. TEC still held in smart contracts at the time of migration would become claimable TEC, allowing owners to claim it after migration.
The thread also summarized several design changes tied to the migration. rETH would become the reserve currency for TEC on OP Mainnet, following the reserve-currency advice process and later agreement in a joint TEC Advisory Network and Coordination Team discussion. TEC would be swappable for rETH through the new ABC swap interface, with secondary market information to follow. Because Celeste was not available on Optimism, the Aragon Guardians solution would replace the previous dispute-resolution mechanism. A new TEC Covenant would also take effect after the migration.
December 15, 2023
A follow-up recognized the complexity of the migration process and the amount of project management and proposal coordination needed to bring the community to this point.
By the end of the thread, the migration had reached the final token-holder-facing stage before execution. The thread served as a practical guide explaining what the migration meant, what token holders needed to do, what would happen to Gnosis TEC, how claimable TEC would work, how rETH would change the ABC reserve, and how the governance architecture would shift toward Guardians and the updated Community Covenant.
2023-12-15 — Financial Analysis of the TEC
Forum thread: Financial Analysis of the TEC Category: Community Updates Archive theme: Financial analysis, Common Pool, Reserve Pool, multisigs, liquidity providers, Tao Voting, fiduciary stewardship, SWOT analysis
December 15, 2023
A community update published a high-level financial analysis of TEC as part of the first phase of the fiduciary stewardship initiative. The analysis was prepared by the Coordination Team together with the TEC Advisory Network and used balances as of December 8, 2023. Its purpose was to give the community a clearer view of TEC’s Common Pool, Reserve Pool, multisigs, liquidity positions, and governance systems for managing funds.
The analysis began with the Common Pool and Reserve Pool. The Common Pool was described as the funding source for TEC projects and operations, funded through Augmented Bonding Curve entry and exit tributes. The Common Pool balance was listed at 308,478.40 wxDAI. The post also summarized cumulative tribute flows since January 2022, with more than 327,000 wxDAI collected through entry and exit tributes. It then noted that the Common Pool had funded roughly 456.7k wxDAI in grants and 349.5k wxDAI in operations.
The Reserve Pool was described as the backing liquidity for the TEC token inside the bonding curve. At the time, the reserve ratio was 19.82 percent, with 318,665.21 TEC bonded to the ABC and a reserve balance of 133,288.14 wxDAI. This section clarified the distinction between operational funds in the Common Pool and collateral backing in the Reserve Pool.
The post then reviewed TEC’s multisigs and liquidity positions. It documented the Coordination Team multisig, the TE Grants Program funds, LASERTAG assets, the legal contingency multisig, the Rewards Board, the WATER position, HoneySwap liquidity pools, and Gravity-related funds. Several observations were attached to these accounts, including the possibility of closing down LASERTAG, the need to continue holding legal contingency funds, the fact that the old Aragon Rewards DAO had become unusable, the already-approved plan to exit WATER contingent on migration, and the need to identify TEC held in smart contracts before migrating.
The governance section explained that Tao Voting had replaced Conviction Voting for stewarding larger Common Pool funding requests. Tao Voting was described as a time-boxed yes/no voting process with defined support, quorum, duration, delegated voting, quiet ending, and execution delay parameters.
The final section presented a SWOT analysis focused on fiduciary stewardship. Strengths included the reduced essential operating budget, the strategic use of the TE Grants Program, the successful operation of the ABC, the transition to Tao Voting for larger funding requests, and the plan to seek sponsorships for grants rounds. Weaknesses included dependence on external funding, the absence of a clear financial strategy, lack of continuous financial reporting, lack of reliable revenue streams, projected budget runout at current spending levels, and limited TEC token utility.
Opportunities included diversifying revenue streams, forming strategic partnerships, improving operational efficiency, benefiting from a bull market, using a liquid staking token as reserve currency, pursuing Optimism ecosystem funding, and exploring investment-style support for funded projects. Threats included internal mismanagement, market volatility, regulatory changes, and token price depreciation.
By the end of the thread, TEC had a consolidated financial snapshot to support future fiduciary policy and budgeting discussions. The post did not make a specific funding request. Instead, it functioned as a baseline analysis for responsible stewardship of TEC’s remaining resources during the migration and governance transition period.
2023-12-18 to 2023-12-19 — Optimism Migration Dress Rehearsal
Forum thread: Optimism Migration Dress Rehearsal Category: TEC / Archive Archive theme: Optimism migration, dress rehearsal, DAO deployment, rETH reserve, token minting, ABC activation, Guardians, EVMcrispr
December 18, 2023
A technical thread documented the dress rehearsal for migrating TEC to Optimism. The post linked to the test TEC DAO, the test TEC Reputation Board DAO, and the test bonding curve interface created during the rehearsal. It then walked through the steps used to create the DAOs, migrate the tokens and funds, configure permissions, and verify that the new architecture worked.
The rehearsal began by creating two DAOs: one for TEC and one for the Reputation Board. Because of a bug in the tooling, the DAO creation had to be separated into two scripts. Permissions were then reassigned so the DAOs could be configured from the TEC Guardians DAO.
The next step was token creation. The rehearsal created the three tokens involved in the new architecture: TEC, rTEC, and the Reputation Board token. These were created in a separate transaction because combining them with the full architecture setup caused gas issues. The post noted that test labels would need to be removed when the process was performed for real.
The thread then described the installation and configuration of the main DAO and Reputation sub-DAO. The new architecture included a voting aggregator combining contribution token power and reputation token power, agents for the Reserve and Common Pool, tollgates for governance and budget votes, Tao Voting instances, delay modules, finance, and the Augmented Bonding Curve. The ABC configuration used rETH as the reserve token, with the same entry and exit tribute structure used in the migration plan.
The rehearsal also outlined how the migration team would use the Guardians DAO to mint TEC on Optimism for every frozen TEC held by externally owned addresses on Gnosis, while distributing TEC held in contracts according to the strategies previously discussed by the community. After confirming that all tokens had been minted correctly, the Guardians would transfer funds to the Common Pool and Reserve, open the bonding curve, and remove their own permission manager roles where appropriate.
The final section described testing DAO functionality through a payment to the migration team. Budget and governance vote flows were simulated both in normal execution and in cancelled flows, verifying that proposals could be executed and that Guardians could cancel when needed. The conclusion was that the migration tests showed TEC was ready to migrate to Optimism the next day.
December 19, 2023
A follow-up question asked whether TEC held in a Gnosis multisig was safe. The answer confirmed that the relevant address had received TEC on Optimism. This provided a concrete example that the migration handling for at least one multisig-held balance had worked as expected.
By the end of the thread, the dress rehearsal had translated the migration plan into a tested sequence of scripts and verification steps. It documented DAO creation, permission assignment, token creation, Tao Voting setup, reputation architecture, rETH-backed ABC configuration, token minting, treasury transfer, bonding curve activation, Guardian cancellation powers, and post-migration confirmation for contract-held tokens.
2023-12-19 to 2024-07-19 — And We Are Live on OP Mainnet
Forum thread: And we are live… on OP Mainnet! Category: Community Updates Archive theme: Optimism migration, OP Mainnet launch, rETH reserve, ABCSwap, contract addresses, Lasertag, Reward Board, Common Pool consolidation
December 19, 2023
A community update announced that TEC’s migration from Gnosis Chain to OP Mainnet was complete. The post framed Optimism as a mission-aligned ecosystem because of its history around Ethereum scaling and public goods funding, and positioned TEC’s move to Optimism as a chance to join an ecosystem with shared commitments around sustaining public goods.
The thread then explained what the migration meant for token holders. People who held TEC in ordinary externally owned accounts would find their TEC at the same address on OP Mainnet. Token holders were instructed to add OP Mainnet to their wallets and import the new TEC token address. The post also clarified that TEC would still appear in Gnosis wallets, but those old tokens no longer had economic value after the migration.
The update confirmed that rETH was now TEC’s reserve currency on OP Mainnet. Unlike the Gnosis-era ABC, which used xDai as collateral, the new ABC used Rocket Pool ETH as collateral. This meant TEC would now follow the price of rETH, a staked ETH derivative. The post directed users to the ABCSwap page for TEC swaps and explained that rETH was the only bonding curve swap pair at that moment.
The announcement also published the new contract addresses for the TEC token, Common Pool, and Reserve Pool on Optimism. This made the thread a practical reference for users trying to locate the new token and treasury infrastructure after the migration.
The post also documented special cases handled during the migration. LASERTAG’s liquid assets were consolidated and sent to the Common Pool because the multisig had been inactive for more than a year. TEC held by LASERTAG was also sent to the Common Pool. The GIV-TEC LP was liquidated, and the TEC freed from that LP was sent to a LASERTAG multisig on Optimism so the GIV-TEC liquidity position could be recreated on OP Mainnet. The Reward Board’s wxDAI balance was moved and converted into rETH, with funds sent to the Reward Board multisig on Optimism.
The thread closed with recognition for the many contributors who worked on the migration, provided strategic input, or helped coordinate the transition.
July 19, 2024
The announcement was later pinned, keeping the OP Mainnet launch post visible as a key reference for the migrated TEC token, ABC, contract addresses, and post-migration setup.
By the end of the thread, TEC had completed one of its largest technical and governance transitions. The OP Mainnet launch thread marked the practical end of the Gnosis-era token economy and the beginning of the Optimism-era TEC: a new token address, a new rETH-backed bonding curve, new Common Pool and Reserve Pool addresses, consolidated legacy assets, and updated instructions for token holders.
2024-01-08 to 2024-01-22 — TEC Rewards Distribution: Round 37
Forum thread: TEC Rewards Dsitribution - Round 37 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, quantifiers, Reward Board, OP Mainnet execution, community review
January 8, 2024
This Rewards Distribution thread published Round 37, covering Praise given between October 30 and November 27, 2023. The round allocated 524.9315137 TEC tokens for rewards. As in previous rounds, the post noted that some Praise accounts had not been activated, so the amount ultimately distributed could be lower than the amount initially set aside.
The distribution followed the established rewards split: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board and submitted for distribution to the Reward Board DAO. The post linked to the full period analysis and opened the distribution for a forty-eight-hour community review period before final execution.
January 22, 2024
A follow-up confirmed that the rewards had gone out and linked to the Optimism address where the distribution was executed. This made Round 37 one of the first rewards distribution threads to point toward the post-migration OP Mainnet execution environment.
By the end of the thread, Round 37 continued TEC’s Praise-based rewards process while reflecting the migration into the Optimism-era infrastructure. The core workflow remained the same: quantify Praise, review the allocations, publish the results, allow community review, and execute the distribution through the Reward Board process.
2024-01-19 to 2024-01-22 — Token Engineering Content Hub
Forum thread: Token Engineering Content Hub - Exciting New Initiative! Category: Community Updates Archive theme: Token Engineering Content Hub, Beem, decentralized video, Livepeer, token-gated content, TEC utility, content commons
January 19, 2024
A community update introduced an experiment to create a Token Engineering Content Hub. The problem identified was that token engineering content had become abundant but scattered across many channels, teams, and formats, including tutorials, podcasts, recorded sessions, community calls, and workshops. The proposed initiative would aggregate that content into a more accessible knowledge hub.
The tool selected for the experiment was Beem, a decentralized video and streaming network built on Livepeer. Beem was described as allowing communities to create their own application pages that display content uploaded to IPFS and other decentralized storage networks in a user-friendly format similar to a streaming homepage. The platform could also support live-streaming for community calls, workshops, and presentations.
The thread framed the initiative as a way to create utility for TEC. The initial experiment would token-gate access to the full content library with a 50 TEC holding requirement. The idea was that curated token engineering content could become a knowledge Schelling point for token engineers, firms, and participants, while giving TEC holders a concrete use case beyond governance and funding participation.
The longer-term vision was to explore a shift from token-gated access toward a revenue-generating model. Future iterations could use NFT subscriptions or similar access systems, potentially creating revenue streams that benefit content creators and encourage more educational material for the field. The thread also imagined that organizations such as Block Science or TE Academy could run their own Beem applications while selectively sharing content into the broader Token Engineering Content Hub.
The proposal emphasized permission and collaboration. Existing content creators and organizations would be asked for permission to host videos, and their communities could receive vouchers to access the hub. This positioned the hub not only as a TEC utility experiment, but as a possible shared media layer for the broader token engineering ecosystem.
January 22, 2024
The replies supported the initiative and highlighted the potential value of token-gated access, content aggregation, and a shared hub for the TEC and token engineering ecosystem.
By the end of the thread, the Token Engineering Content Hub had been framed as an experiment in knowledge coordination and TEC utility. It aimed to aggregate scattered educational content, use decentralized media infrastructure, provide a concrete access use case for TEC, and explore future revenue models that could support content creators and public knowledge in token engineering.
2024-01-22 — TEC Rewards Distribution: Round 38
Forum thread: TEC Rewards Distribution - Round 38 Category: Rewards Distributions / Archive Archive theme: Rewards distribution, Praise, quantifiers, Reward Board, Safe execution, community review
January 22, 2024
This Rewards Distribution thread published Round 38, covering Praise given between December 12, 2023 and January 1, 2024. The round allocated 180.87 TEC tokens for rewards.
The distribution followed the established rewards split: 90 percent of tokens went to Praise rewards, 7 percent went to quantifiers, and 3 percent went to the Reward Board. The data had been reviewed by the quantifiers and Reward Board and submitted for distribution to the Reward Board DAO, now linked through the Safe infrastructure rather than the older Gnosis-era Reward Board DAO link. The post opened the distribution for a forty-eight-hour community review period before final execution and linked to the spreadsheet with the calculations.
By the end of the thread, Round 38 continued TEC’s recurring Praise reward process in the post-migration environment. The basic workflow remained consistent: quantify Praise, review the allocation, publish the results, allow community review, and execute the final distribution through the Reward Board process.
2024-02-14 to 2024-06-09 — The TEC Is Hiring
Forum thread: The TEC is Hiring! Category: Community Updates Archive theme: Hiring, Coordination Team capacity, Ecosystem Development Lead, Programs Lead, hiring committee, onboarding, trial period
February 14, 2024
A community update announced that TEC was opening a recruiting process to increase Coordination Team capacity for the year ahead. The thread framed hiring as part of TEC’s evolving needs and priorities after the Optimism migration and as a way to support new levels of growth and impact.
The initial announcement focused on two roles: an Ecosystem Development Lead and a Programs Lead. These roles were presented as important additions for helping TEC execute its strategy, develop ecosystem relationships, and operate its programs more effectively.
The thread also described the hiring process. The opportunities would be promoted through the forum, Discord, and Twitter, and applicants would apply through a job board with basic information and a CV upload. A hiring committee connected to TECAN would review applications weekly, shortlist candidates, and conduct interviews to assess experience, skills, alignment, cultural fit, and expectations around DAO work.
The final selection process would involve weekly candidate review, committee voting, and direct feedback to candidates. Successful candidates would receive an offer, onboarding resources, and a two-month trial period, with a review after six weeks before any longer work agreement was extended.
February 29 to March 7, 2024
A later update clarified that the Programs Lead role was also open and encouraged qualified applicants to review the job board. A prospective applicant asked whether someone newer to token engineering but experienced in blockchain, community building, and external relations could apply. The response encouraged them to apply, reinforcing that the hiring process was open to candidates with adjacent experience and alignment.
June 9, 2024
The thread later received a question about applying for a part-time Grants Operator position listed on the job board. The question was then withdrawn after the applicant realized the position had already been filled.
By the end of the thread, TEC had publicly documented a more formal hiring process for expanding its operational capacity. The thread captured a shift from volunteer-heavy DAO operations toward clearer roles, committee-based hiring, onboarding procedures, and trial periods designed to professionalize TEC’s program and ecosystem-development work.
2024-02-20 — Results of TE Grants Round 3
Forum thread: Results of TE Grants Round 3 Category: Grants Program Archive theme: TE Grants, Gitcoin Featured Round, quadratic funding, sponsor funding, TE Matching Boost, public goods funding
February 20, 2024
A results post summarized the third round of the Token Engineering Grants Program. The round had run during the Gitcoin round from November 15 to November 29 as a Gitcoin Featured Round. This round marked an important change in the grants program because, for the first time, all matching funding came from sponsors rather than TEC’s Common Pool. Ocean Protocol and Arbitrum supported the round.
The round used a 50,000 dollar matching pool, a 15 percent matching cap, and a 2x coefficient multiplier for the TE Matching Boost. This continued TEC’s experiment with combining quadratic funding with token engineering subject-matter-expert signals, while also testing whether the program could attract external sponsorship to reduce direct pressure on TEC’s treasury.
The round included twenty projects, 530 unique donors, and 1,720 total contributions. Donors contributed 5,108.13 dollars, with an average contribution of 9.64 dollars. The results table distributed 100,217.3289 TEC across the participating projects. The largest allocations went to Commons Stack, Bonding Curve Research Group, cadCAD, Metagov, PlaceCred, Mechanism Institute, EVMcrispr, Breadchain Cooperative, Index Wallets, and cadEVM, with additional support going to security, governance education, tooling, regenerative finance, and ecosystem projects.
The post noted that dates for the next round were still to be determined and invited grantees, interested projects, and future sponsors to reach out. It also apologized for delays and acknowledged that the team had learned a lot from running a sponsor-supported round.
By the end of the thread, TE Grants Round 3 had been documented as a significant evolution of TEC’s grants program. It showed that the grants mechanism could support a larger pool of projects, operate with a sponsored matching pool, continue testing the TE Matching Boost, and move closer to a more sustainable model for funding token engineering public goods without relying entirely on the Common Pool.
2024-03-04 to 2024-07-19 — TEC 2024 Priorities, Budget, and Six-Month Operating Proposal
Forum thread: TEC 2024 Priorities, Budget, and 6-Month Operating Proposal Category: TEC Strategy & Governance Archive theme: 2024 strategy, annual budget, operating proposal, grants program, RetroPGF, Optimism, public goods funding, economic sustainability
March 4, 2024
A strategy and funding proposal was opened to define TEC’s 2024 priorities, annual budget, and six-month operating budget. The post marked TEC’s first annual operating budget with both income and outlay projections. Its central objective was to reach break-even, with no net withdrawals from the Common Pool, while continuing to fund token engineering public goods and investing in stakeholder engagement, communications, and ecosystem development.
The strategy built on TEC’s strongest demonstrated function: regranting from public goods funders to token engineering projects. TEC had already moved from directly funding grants out of the Common Pool to using the Common Pool as matching funds in Gitcoin quadratic funding rounds. After migrating to OP Mainnet and receiving Optimism RetroPGF, the proposal argued that TEC had an opportunity to build a symbiotic relationship with Optimism while remaining chain-agnostic as a token engineering commons.
The proposal introduced two major changes to the TE Grants Program. First, TEC would experiment with its own RetroPGF process. QF rounds would continue to provide seed funding, while projects that met performance thresholds could later participate in TEC RetroPGF rounds with fewer projects and larger awards. This was described as the first phase of a token engineering public goods incubator.
Second, the proposal introduced the idea of RetroPGF impact bundling. Projects participating in TEC RetroPGF could delegate their impact to TEC’s next Optimism RetroPGF application. TEC would then bundle the impact of several token engineering projects into one OP RetroPGF application, reducing evaluation burden for Optimism badgeholders and making RetroPGF more accessible to earlier-stage projects. Projects could later graduate and apply to Optimism directly.
The organizational section described TEC’s operating structure for the year. The Coordination Team remained the operational core, divided into Programs Operations, Ecosystem Development and Communications, and Coordination. The TE Grants Program was treated as TEC’s first major program, with the possibility that it could become its own working unit over time. TECAN continued to provide strategic advice and subject-matter expertise, while the overall structure was meant to stay flexible enough to integrate new programs and business models.
The roadmap included strategy and budgeting, hiring, TE Grants Round 4, an OP-TEC liquidity pool, a first TE Grants RetroPGF round, another QF round, and planning for the 2025 strategy and budget.
The annual budget projected 475,331 dollars in income and 472,240 dollars in outlays, producing a small projected net income. Income sources included Optimism RetroPGF, other grants, sponsorships, tributes, and other sources. Outlays included QF grants, RetroPGF grants, OP-TEC liquidity, other programs, staffing, and miscellaneous costs. The six-month staffing proposal requested 160,589 dollars for March through August 2024, while program outlays would be requested later as their details became clearer.
Success for 2024 was defined as no net Common Pool outflows, funding at least 100,000 dollars in token engineering public goods, growing TEC’s RetroPGF relationship with Optimism, and investing in communications, engagement, and reputation systems that could support new income streams and token utility in 2025.
March 6 to March 21, 2024
The early response praised the clarity of the strategy and the transparency of the budget. The proposal then moved to a vote on March 12. On March 21, the proposal was reported as successfully approved.
July 19, 2024
The thread was later pinned, keeping the 2024 strategy and operating budget visible as a key reference for TEC’s post-migration priorities.
By the end of the thread, TEC had approved a new operating strategy for the Optimism era. The proposal moved TEC from survival and migration work toward economic sustainability, sponsored public goods funding, RetroPGF integration, ecosystem development, communications, and a budget framework designed to preserve the Common Pool while building toward new forms of revenue and TEC token utility.
2024-03-22 to 2024-04-08 — Funding of TEC-OP Liquidity Pool on Velodrome
Forum thread: Funding of TEC-OP Liquidity Pool on Velodrome Category: TEC Strategy & Governance Archive theme: OP Mainnet migration, Velodrome liquidity, TEC-OP liquidity pool, RetroPGF funds, TECAN multisig, token utility
March 22, 2024
A strategy and governance proposal was opened to fund a TEC-OP liquidity pool on Velodrome. The proposal positioned the liquidity pool as part of TEC’s post-migration strategy for increasing the usability and liquidity of the TEC token on OP Mainnet.
The immediate proposal was to move 20,000 dollars worth of assets from TEC’s recent Optimism RetroPGF award into a TEC-OP liquidity pool. The initial deposit would be split evenly between OP and TEC. The proposal also requested authority to add up to 100,000 dollars total over time, with additional deposits made gradually as TEC gained more clarity around cash flow, future funding, and budget constraints.
The proposal emphasized that the initial 20,000 dollar allocation had already been accounted for in the 2024 budget and was intended as a prudent first step rather than a full immediate deployment. It also clarified that liquidity pool funds could be withdrawn if needed for TEC operations or grant-making obligations.
The expected benefits were practical and strategic. The pool would make it easier to buy and sell TEC, reduce slippage, support the broader Optimism partnership narrative, create future arbitrage opportunities, and give partners a clear way to contribute to TEC liquidity. The pool would be managed by a TEC Advisory Network multisig, with progress tracked internally and updated through the forum.
March 25 to April 3, 2024
The early response was supportive and treated the proposal as an important step in making the post-migration TEC token more usable. The proposal was later reported as successfully approved through Snapshot.
April 8, 2024
A final update confirmed that the TEC-OP liquidity pool had been created on Velodrome. The thread therefore moved from a funding request into implementation, marking a concrete step in TEC’s OP Mainnet liquidity strategy.
By the end of the thread, TEC had approved and created its first TEC-OP liquidity pool on Velodrome. The proposal connected Optimism RetroPGF funds, TEC token liquidity, partner alignment, and post-migration treasury strategy into one operational step for making TEC more accessible and useful in the Optimism ecosystem.
2024-04-11 to 2024-05-24 — Ideas on Token Utility
Forum thread: Ideas on token utility Category: TEC Strategy & Governance Archive theme: TEC token utility, TE Stakeholder Study, grants program, matching boosts, partnerships, token-gated membership, TE public goods
April 11, 2024
A strategy discussion was opened to explore possible sources of utility for the TEC token after the Optimism migration and the publication of the Token Engineering Stakeholder Study. The thread began from the idea that the stakeholder study had identified concrete needs in the token engineering field, and that TEC could use those needs to narrow the grants program toward projects that directly addressed them.
The initial proposal suggested that TEC grants could become a mechanism for tying TEC token value to the production of token engineering public goods. Grant rounds could prioritize topics supported by stakeholder study data, and donations made in TEC could receive higher matching. This would give token engineers, firms, and ecosystem participants a reason to hold and use TEC if they wanted to support projects working on needs they cared about but did not have the capacity to solve themselves.
The thread also proposed that grant projects could have the option to receive TEC tokens and that stronger token engineering partnerships could help create more durable demand for TEC. If TEC became tied to the value produced by projects funded through the Commons, token engineering firms and institutions might eventually accept partial payment in TEC as a commitment to advancing the field as an open-source discipline. A longer-term idea was also raised around a token engineering union or membership structure connected to TEC token ownership.
April 11 to April 12, 2024
The discussion then connected token utility to grants program design. One response suggested that the Token Engineering Advisory Group could use the stakeholder study to define seasonal grant intents, such as education, standardization, or other field-development priorities. Token holders could then vote on which intent should guide a given grant round. Narrowing grant rounds around specific needs was presented as a way to bring more specialized projects forward instead of keeping the funding surface too broad.
The thread also examined whether grantees would actually want to receive TEC. Since current grant distributions were already made in TEC, the question was whether additional incentives would be enough to make holding TEC attractive. A concern was raised that, without stronger utility or changes to token economics, grantees might prefer to exit rather than hold the token, especially because the exit tribute reduced the attractiveness of converting TEC back out.
The discussion identified partnerships as the larger opportunity. If token engineering partners, institutions, and firms could adopt TEC as a preferred medium of economic exchange for products or services, TEC might gain a more continuous source of demand while also supporting the Common Pool. The thread recognized that the difficult part would be designing the right incentives for partners to accept and hold TEC.
A follow-up clarified that the grants program already included donor-side matching boosts based on token engineering alignment and expertise, such as holding TEC or holding TE certifications. The idea of grantee-side boosts was not yet established but was treated as promising, especially for projects that made a clear commitment to the Commons. The thread also noted that the existing TEC token boost needed better communication during grant outreach so applicants and donors understood it was available.
April 19 to May 24, 2024
The discussion later expanded into the broader gaps identified in the token engineering field. One response argued that legal, ethical, political science, and decision-modeling dimensions were underdeveloped compared with engineering approaches. This opened a possible collaboration path around legal engineering, peer review, and education for complex token engineering projects.
A later reply connected this to education and skill-building, noting overlap between legal reasoning and programming and suggesting that courses or collaborations at the intersection of law and technical practice could be valuable.
By the end of the thread, token utility had been framed less as a single mechanism and more as a design space. The discussion connected TEC token demand to focused grant intents, TEC-based matching boosts, partner adoption, grantee commitments, education, peer review, and membership-like structures. It showed TEC beginning to think about token utility as something that would need to emerge from real economic relationships between the Commons, funded projects, token engineering firms, and the broader field.
2024-05-16 to 2024-06-18 — TE Grant Round 4 TEC Distribution Proposal
Forum thread: TE Grant Round 4 $TEC Distribution Proposal Category: Grants Program Archive theme: TE Grants Round 4, TEC distribution, Common Pool, grant funding, ABC purchases, price calculation, fiduciary transparency
May 16, 2024
A grants program proposal was opened to handle the logistics of distributing TEC tokens for Token Engineering Grants Round 4. The proposal clarified that the underlying 50,000 dollar grant budget had already been approved in the TEC 2024 priorities and budget proposal, but that the community still needed a practical process for sourcing and distributing the TEC tokens.
The proposal explained that TEC was planning to distribute 50,000 dollars worth of TEC across thirty-two grant projects. The Common Pool already held about 97,000 TEC, which represented most of the tokens needed for the round. Using those existing Common Pool tokens would reduce operational complexity and avoid creating unnecessary price pressure by purchasing the full grant amount from the market or bonding curve.
The proposed actions were to withdraw 97,000 TEC from the Common Pool, announce that the grant distribution would be based on a specified TEC spot price, purchase any additional TEC needed from the Augmented Bonding Curve, distribute TEC to grantees, and use remaining grant program funds to begin accumulating TEC for future rounds. The proposal also included monitoring grantee sell pressure and potentially purchasing TEC from the secondary market after most grantees had sold.
May 18 to May 21, 2024
The discussion raised concerns about how the TEC price should be calculated. One response argued that the secondary market price was too volatile because liquidity depth was low, and suggested using the Augmented Bonding Curve price instead. The same response noted that, using the ABC price, the Common Pool’s existing TEC was close to enough for the grant distribution, meaning that additional purchases might not be necessary for this round.
Another concern was whether the request functioned as a de facto increase to the Coordination Team budget. The response clarified that the request was for the TE Grants Program and was separate from the previously approved Coordination Team staffing budget. The funds were part of the already approved annual TEC budget for QF grant rounds, not an expansion of operational staffing funds.
The proposal then moved to a vote.
June 18, 2024
A later update was posted to maintain financial transparency and fiduciary accountability around the grants program. The update explained that TEC was creating a purchasing process to accumulate TEC for future grant rounds without making large predictable purchases that could be front-run or that could significantly affect the ABC or secondary market.
The proposed process separated responsibilities across three wallets. The TE Grants Program multisig would receive grant funding, receive TEC, and distribute TEC to grantees. A Transaction Team multisig would manage the acquisition of rETH through a dollar-cost-averaging process and send rETH to a dedicated account. A separate ABC EOA would use that rETH to buy TEC from the Augmented Bonding Curve and send the TEC back to the grants multisig.
The update also established limits and reporting expectations. The Transaction Team multisig would have a maximum amount under management, the ABC EOA would have a smaller maximum amount under management, and the owner of the ABC EOA would be required to report activity during weekly Coordination Team meetings so other members could verify the actions taken.
By the end of the thread, the Round 4 distribution proposal had moved from a simple token withdrawal request into a more developed grants treasury process. It clarified how TEC would source tokens for grantees, how price calculation should be handled, how future TEC accumulation could avoid predictable market impact, and how wallet roles and reporting practices could support fiduciary accountability.
2024-05-19 to 2024-06-06 — Increasing the Minimum Quorum on Tao Voting
Forum thread: Increasing the minimum quorum on Tao Voting Category: TEC Strategy & Governance Archive theme: Tao Voting, quorum, token concentration, governance participation, Nakamoto coefficient, Guardians, post-migration governance
May 19, 2024
A strategy and governance discussion was opened after work on a new dashboard revealed that TEC token ownership had become more concentrated than it had been at the Hatch. The concern was not that the largest token holders were misaligned, but that one large holder appeared close to having enough tokens to pass proposals with very little additional participation.
The thread suggested increasing the minimum quorum parameter on Tao Voting to either 15 percent or 20 percent. The purpose of the change would be to require broader participation and discussion around governance decisions, especially now that TEC had migrated to a new governance architecture on Optimism.
May 24, 2024
A follow-up supported the idea and suggested that quorum could eventually be adjusted algorithmically. Instead of setting a fixed minimum quorum manually, the system could periodically adjust quorum requirements to maintain a target Nakamoto coefficient or similar decentralization threshold. This expanded the idea from a one-time parameter adjustment into a possible adaptive governance mechanism.
June 6, 2024
A later response agreed that token concentration and governance participation were important issues, but raised the practical concern that TEC had struggled for years to generate meaningful engagement around many DAO decisions. Increasing quorum could improve legitimacy, but it could also make it harder for the DAO to act quickly while participation remained low.
The response also noted that the Guardians mechanism already provided a safety layer against misaligned or harmful proposals. This meant that quorum did not need to carry the full burden of protecting the DAO from malicious action, although improving engagement and participation remained a priority.
By the end of the thread, the quorum discussion had framed a central post-migration governance tradeoff. TEC needed to respond to token concentration and encourage wider participation, but it also needed to preserve operational capacity in a community where governance engagement was often limited. The thread connected quorum settings, token distribution, adaptive governance design, and Guardian protections into one broader question about how TEC should maintain legitimacy and agility after migrating to Tao Voting.
2024-06-13 to 2024-08-14 — Results of TE Grants Round 4
Forum thread: Results of TE Grants Round 4 Category: Grants Program Archive theme: TE Grants Round 4, Gitcoin Community Round, quadratic funding, TE Matching Boost, grant results, process improvements
June 13, 2024
A Grants Program results post summarized the fourth round of the Token Engineering Grants Program. The round took place during Gitcoin Grants Round 20, from April 23 to May 7, as a Gitcoin Community Round. Funding came from TEC’s Common Pool and Gitcoin.
The round used a 50,000 dollar matching pool, a 15 percent matching cap, and a 2x coefficient multiplier for the TE Matching Boost. This continued TEC’s experiment with combining quadratic funding, donor participation, and token engineering alignment signals to allocate public goods funding.
The round included thirty-two projects, 554 unique donors, and 1,619 total contributions. Donors contributed 9,365 dollars, with an average contribution of 16.90 dollars. The results distributed TEC across the participating projects, with the largest allocations going to Commons Stack, the cadCAD Foundation, Trusted Seed, Bonding Curve Research Group, Super DCA, Crypto Commons Association, Kairos Research, Streaming Quadratic Funding, Network of Trust, and Gobying, followed by a broader set of projects working on governance, mechanism design, regenerative finance, attestations, tooling, and education.
The post linked to a full retrospective report on the Gitcoin forum and noted that the timing of the next round was still to be determined. It invited future grantees, sponsors, and community members to provide feedback on how the program could improve.
June 14 to August 14, 2024
The replies focused on appreciation for the round’s operational execution. The discussion noted that the round had happened during a period of constrained team capacity and that the round manager had stepped in to keep the program moving. The replies also highlighted process improvements that could make future rounds smoother.
A later response from one of the supported projects thanked the team for making the round happen.
By the end of the thread, TE Grants Round 4 had been documented as another major Gitcoin-based funding round for token engineering public goods. The post captured the round’s configuration, participation statistics, project allocations, operational lessons, and the continued evolution of the grants program as TEC tried to fund a wider set of projects while improving the internal processes required to run recurring rounds.
2024-10-09 — Results of Token Engineering the Superchain
Forum thread: Results of Token Engineering the Superchain Category: Grants Program Archive theme: Token Engineering the Superchain, Tunable Quadratic Funding, Optimism, Superchain, Gitcoin Grants 21, Retroactive Funding, Passport, cluster mapping
October 9, 2024
A Grants Program results thread summarized the Token Engineering the Superchain Grants Round for summer and fall 2024. The round was designed as a dual-phase initiative to advance token engineering within the Optimism and broader Superchain ecosystems. The first phase was a Tunable Quadratic Funding round run during Gitcoin Grants 21, and the second phase was planned as a later Retroactive Funding round to reward projects based on milestones and demonstrated impact.
The round had three core objectives. It aimed to advance the token engineering field, support projects that could create measurable impact within Optimism and the Superchain, and set the foundation for a later retroactive funding round using Gitcoin’s RetroPGF platform. This made the round both a funding event and a pipeline for later impact-based evaluation.
The round included eighteen projects, 349 unique donors, 914 contributions, and 5,792.59 dollars in total donations. The average contribution was 16.60 dollars, and the average grant size was 3,333 dollars. The round was narrower than the previous TE Grants Round 4, with fewer projects and donors, but the post framed this as expected because the round was more selective and focused on OP and Superchain alignment.
The mechanism design continued TEC’s experimentation with Tunable Quadratic Funding. The round incorporated token engineering expertise signals, such as TE Academy credentials and TEC holdings, and added Optimism-related signals, including OP holdings, OP delegate activity, and badgeholder status. The purpose was to amplify donors who had demonstrated knowledge or alignment with both token engineering and the Optimism ecosystem.
The results post also analyzed multiple anti-sybil and matching-adjustment approaches. It described Gitcoin’s Passport model, where donors received full, partial, or no matching based on human-score thresholds. It then compared baseline Quadratic Funding, Cluster Mapping, Connection Oriented Cluster Mapping, and the final TQF approach. The discussion recognized that stronger clustering and passport mechanisms could reduce suspicious or coordinated funding patterns, but could also penalize newer participants, small communities, or legitimate groups of donors with similar interests.
The final payouts distributed funding across projects working on Superchain tooling, governance, research, education, swaps, funding infrastructure, and token engineering services. The largest allocations went to Pairwise, Inverter Network, Superchain Innovation and Competition, Bonding Curve Research Group, Token Swaps as a Mechanism for Superchain Alignment, Treegens DAO, Valueverse Labs, TPRO Network, Flow State, and GovGraph.
The post compared the round to TE Grants Round 4. The Superchain round had fewer projects, fewer unique donors, lower total crowdfunding, and fewer total contributions, but a similar average contribution size. The report interpreted this as a consequence of the round’s more focused scope rather than as a failure of engagement.
The lessons learned focused on improving future rounds. The thread identified the need for clearer guidance on token engineering and Superchain alignment, more upfront templates and workshops, more review capacity for last-minute applications, earlier grantee marketing support, and better milestone and impact metric definitions. These lessons were especially important because the next phase would be a Retroactive Funding round where grantees would need to submit proof of milestones and impact.
By the end of the thread, Token Engineering the Superchain had been documented as a major evolution in TEC’s grants program. It combined QF with TQF, Optimism-aligned expertise signals, sybil-resistance tools, cluster analysis, and a planned retroactive funding phase. The round showed TEC moving from general token engineering grants toward a more strategic incubator model for projects that could advance token engineering while producing measurable Superchain impact.
2025-01-30 to 2025-03-24 — TEC Coordination Team Funding Proposal: January to June 2025
Forum thread: TEC Coordination Team Funding Proposal January - June 2025 Category: TEC Strategy & Governance Archive theme: 2025 strategy, Coordination Team funding, operational budget, financial sustainability, grants program, knowledge commons, token utility, governance development
January 30, 2025
A strategy and governance proposal was opened to fund the TEC Coordination Team for January through June 2025. The proposal also served as a broad strategic plan for the year, combining a retrospective on 2024, a financial analysis, a roadmap for the first half of 2025, and a funding request for continued operations.
The proposal began by reviewing the goals set in the 2024 operating proposal. TEC had aimed to reach operational sustainability, fund token engineering public goods, embed itself within the Optimism ecosystem, and grow the TEC economy. The thread reported that TEC had achieved its first breakeven year, with Common Pool resources roughly preserved when counting funds held in TECAN and grants-program multisigs as Commons-controlled assets. This was attributed to efficient resource management, external grant funding, recovered unused funds, and improved token value late in the year.
The proposal reported that TEC had funded 135,000 dollars across fifty projects through two QF rounds, exceeding its 2024 public goods funding goal. It also noted that TEC had committed 40,000 dollars to a first Retro Public Goods Funding round for early 2025 as part of the Token Engineering the Superchain initiative. The Optimism funding goal was only partially achieved, because changes in Optimism’s RetroPGF program reduced expected opportunities, but TEC still raised funding through RetroPGF and began positioning itself for future collaboration with Optimism.
The post also summarized progress on token utility, community engagement, and fundraising. TEC had made TEC holdings a signal in Tunable Quadratic Funding, distributed TEC to grantees, established the TEC-OP liquidity pool, and improved its communications reach through social campaigns and online events. However, the proposal acknowledged that new income streams had not developed as much as hoped and would need to become a major focus in 2025.
The 2025 strategy framed TEC as shifting from abstract theory toward real-world implementation. The three core focus areas were education and advocacy, ecosystem empowerment, and collaborative growth. These were translated into four major objectives: increasing awareness of Web3’s real-world impact, supporting projects that tackle real-world challenges, creating a long-term economic system for TEC, and expanding TEC governance and ecosystem development.
The roadmap included a Knowledge Sharing Program, an Education Program, a Grants Program, a Token Infrastructure Program, a Fundraising Program, a Governance Development Program, and an Ecosystem Development Program. Planned initiatives included cataloging one hundred resources in the TEC Library, launching a newsletter, hosting online events, creating a TE AI agent, developing a Knowledge Commons roadmap, publishing educational articles, reviving Research Hub presentations, exploring a virtual conference, producing a grants-program retrospective, developing a new grants framework, testing TQF integrations, exploring ABC and secondary-market infrastructure, researching TEC token utility, building a sponsorship program, improving governance participation, recruiting advisors, and launching an opportunities board.
The financial section summarized TEC’s 2024 inflows and outflows. TEC had secured roughly 310,725 dollars through grants, sponsorships, tributes, recovered funds, and other grants, while outflows totaled roughly 314,846 dollars across QF grants, the OP-TEC liquidity pool, and Coordination Team operations. The Common Pool closed 2024 at about 206,662 dollars, while other balances existed in the grants program, TECAN, Reserve Pool, liquidity pools, and related accounts.
The funding request asked for approximately 84,000 DAI for Coordination Team operations from January through June 2025. The budget included 72,000 DAI for staffing, 9,000 DAI for incentives and bounties, 600 DAI for tools, and 2,400 DAI for miscellaneous expenses. Instead of drawing from the Common Pool, the proposal requested access to funds held in the TECAN multisig and TEC GG multisig, using a Snapshot approval process because of issues with Aragon OS on Optimism. The vote would function as a signaling vote, after which multisig signers would execute the transfers and report back.
The team section described a shift from fixed roles toward a more collaborative “swarming” model for managing projects, improving communication, distributing responsibility, and supporting team well-being.
February 4 to February 5, 2025
The discussion that followed supported the proposal while suggesting possible future directions. One response proposed that TEC’s knowledge-sharing and education work could evolve into a broader research commons where real problems in tokenized systems are surfaced, investigated, and solved through incentives and bounties. The same response suggested that support for projects could include stronger reciprocity back to the TEC ecosystem, potentially through token relationships or bonding mechanisms, and that partnerships with legacy institutions moving into blockchain could become a source of mutual benefit.
A reply welcomed these directions and connected them to future grant rounds, outcomes-based funding, and research groups. The response noted that one challenge for TEC was identifying fundamental token engineering problems and offering incentives strong enough to compete with private-sector opportunities. It suggested that seeding focused research groups, similar to the Bonding Curve Research Group, could be a practical way to develop deeper expertise while preserving TEC’s role as an aggregator of token engineering knowledge.
February 4 to February 13, 2025
The proposal moved to a Snapshot vote, which was scheduled to close on February 9. A follow-up later confirmed that the proposal had been successfully approved. On February 13, transfers from both the TEC GG multisig and TECAN multisig were reported as successfully executed, completing the funding process for the first half of 2025 operations.
March 24, 2025
A later reply offered support for the research presentations milestone, noting that a funded project had accumulated research from recent TEC Gitcoin rounds and could share it through TEC’s planned programming.
By the end of the thread, TEC had approved and executed its first-half 2025 Coordination Team funding proposal. The thread captured a major strategic transition: TEC was building on a breakeven 2024, reducing reliance on the Common Pool, expanding its focus toward real-world Web3 impact, formalizing knowledge-sharing and education programs, rethinking grants and token utility, and funding a more collaborative operating model for the next phase of the Commons.
2025-05-13 — TEC Q1 2025 Progress Report
Forum thread: TEC Q1 2025 Progress Report Category: Community Updates Archive theme: Q1 progress report, 2025 operating milestones, knowledge sharing, grants program, token infrastructure, fundraising, governance development, financial transparency
May 13, 2025
A Q1 progress report was published to document TEC’s work from January through March 2025 against the milestones in the January to June 2025 funding proposal. The thread was structured as an accountability update rather than a new funding request. It reviewed progress across program areas, identified what had been completed or delayed, outlined Q2 plans, and summarized the financial position at the end of the quarter.
The knowledge-sharing program showed early foundational progress. TEC had begun aggregating resources for the TEC Library, with twenty-six resources cataloged toward a one-hundred-resource milestone. Social media work had moved into regular content sharing, the first edition of the Rollup Report newsletter had launched in March with an initial subscriber base, and one online event had been hosted. The report also noted that the Knowledge Commons roadmap and TEC AI agent were still early, with the library expected to serve as a foundation for future development.
The education program remained mostly in the planning stage. Publishing, Research Hub presentations, and the virtual conference concept had foundational planning completed, with the main work expected to happen in Q2. The report framed Q2 as the period when articles, research presentations, and potential conference partnerships would need to move from planning into delivery.
The grants program had mixed progress. Work on the broader grants framework and collaborative grant planning had not yet begun because the current retroactive funding round still needed to conclude. However, the Tunable Quadratic Funding work had exceeded its original goal by being integrated into the Gitcoin quadratic funding calculator. The next steps were to finalize documentation and support other round operators who might use the mechanism.
The token infrastructure program reported the launch of a new TEC Swap site for interacting with the Augmented Bonding Curve. Other token infrastructure questions, including secondary market liquidity and future TEC utility, had not yet been developed in detail. These were deferred to a final Token Infrastructure report planned for Q2.
The fundraising program showed stronger progress. TEC had submitted a Gitcoin Grants 23 application, initiated the OP RetroPGF 6 claims process, and reviewed OP mission requests, which were judged not viable at that time. The report also noted that the Token Engineering Superchain Retro Round had secured roughly twenty-one thousand dollars in Gitcoin matching funds, covering more than half of the grant round’s expected costs.
Governance and ecosystem development remained less advanced. One Snapshot vote had been completed successfully, but the governance framework, advisor engagement structure, and opportunities board still needed more development. The Q2 plan was to strengthen governance infrastructure, continue assessing advisory needs, and launch a lightweight opportunities board starting with article collaboration opportunities.
The financial section provided a snapshot of Q1 inflows, expenses, and treasury position. TEC had raised roughly 3,614 dollars from ABC tributes during the quarter. Reported expenditures totaled roughly 42,244 dollars, including the new TEC Swap site, a partial payment for TQF integration, staffing, and tooling. The end-of-Q1 total value across TEC accounts, pools, multisigs, grant funds, liquidity positions, and related holdings was reported at approximately 300,365 dollars.
The Q2 outlook identified expected inflows from OP RetroPGF 6 streaming funds, Gitcoin matching funds for the Token Engineering Superchain Retro Round, and pending GG23 funding. Expected outflows included forty thousand dollars in grantee payouts for the Token Engineering Superchain Retro Round and the final payment for the TQF integration project.
By the end of the thread, Q1 2025 was presented as a foundational phase. Several programs had moved from planning to execution, especially in knowledge sharing, fundraising, token infrastructure, and TQF development. At the same time, the report made clear that many larger goals still depended on Q2 execution, including publishing, research events, grant framework development, governance improvements, liquidity strategy, token utility planning, and broader financial sustainability.
2025-07-11 to 2025-07-22 — TEC Token Infrastructure and Utility Report
Forum thread: $TEC Token Infrastructure & Utility Report Category: TEC Strategy & Governance Archive theme: TEC token infrastructure, Augmented Bonding Curve, Reserve Pool, Common Pool, Velodrome liquidity, token utility, market architecture, token sunsetting debate
July 11, 2025
A strategy and governance report was published to evaluate the state of TEC’s token infrastructure roughly a year and a half after the migration from Gnosis Chain to Optimism Mainnet. The report framed the migration as complete and noted that a new ABC page and core TEC economic infrastructure had been deployed. The purpose was to begin a deeper discussion about the health of the TEC token economy, the system’s vulnerabilities, the pain points in its design, and the decisions token holders would need to make about the next chapter of the TEC economy.
The report began with a token supply and distribution snapshot. It listed a total supply of 1,214,204.81 TEC, 745 token holders, the Optimism token contract, and the Common Pool and Reserve Pool addresses. The report initially described token-holder growth in a way that was later corrected, after the discussion clarified that holders had peaked around 800 in May 2024 and had declined since then.
The report then evaluated the Augmented Bonding Curve. It described the ABC as the primary minting and redemption mechanism for TEC and the mechanism that routes tribute revenue into the Common Pool. The Reserve Pool was described as being held in rETH, making TEC partly tied to ETH exposure and Ethereum staking yield. This was framed as powerful but risky because TEC inherits volatility and security assumptions from ETH and rETH.
The July 2025 pool snapshot listed the Common Pool at roughly 207,215 dollars in DAI, rETH, and TEC, and the Reserve Pool at roughly 42,775 dollars in rETH. The report also noted that the ABC had generated roughly 25,235 dollars in tributes since migration, mostly from exits rather than entries. This showed that the ABC was functioning more as an exit ramp than a sustainable entry point, although the high exit tribute had also slowed the pace of exits during a period of contraction.
The next section focused on secondary market liquidity on Velodrome. The report identified two post-migration pools: TEC/OP and TEC/GIV. The TEC/OP pool handled most activity but still had high slippage, while the TEC/GIV pool was described as nearly unusable due to limited depth and instability. The report argued that TEC’s current liquidity was insufficient and that users were penalized whether they interacted through Velodrome or the bonding curve.
The report then framed a market architecture conflict between the ABC and the secondary market. The ABC generated tribute revenue for the Common Pool but had worse user experience and discoverability. Velodrome was easier to access and more visible, but did not generate revenue for the Commons and suffered from slippage. Running both systems without a clear arbitrage or coordination strategy was described as leaving value on the table and creating friction for users.
Three strategic options were proposed. Option A would close public access to the ABC and allow TEC-controlled wallets to use the ABC for internal arbitrage, while most public trading would move to the secondary market. Option B would remove secondary market liquidity and force all trading through the ABC. Option C would maintain the dual-market structure while gradually improving liquidity. The report favored migrating existing liquidity into a single TEC/ETH pool with at least 15,000 dollars in TVL to reduce slippage and improve routing and price discovery.
The final section explored pathways to token utility. Possible utility experiments included using TEC in a publishing initiative for tipping, article curation, or content access; using TEC for tickets or speaker compensation in virtual events; integrating TEC into the grants program for proposal voting, delegated stake, or milestone unlocking; and longer-term experiments involving reputation, peer review, credentialing, ReFi coordination games, funding challenges, and bounties. The report argued that utility would need to be intentionally designed rather than waited for.
July 13 to July 14, 2025
The discussion quickly became a deeper critique of the TEC token’s condition. One response challenged the original framing around holder growth and argued that the number of holders had declined since its May 2024 peak. The same critique argued that the token price appeared to be tracking the underlying treasury and reserve value rather than pricing in future upside, raising the question of whether the community should consider gracefully sunsetting the token and using remaining funds to support token engineering in a leaner way.
The critique also questioned whether the proposed utility paths were credible enough to generate meaningful demand. Publishing, grant distributions, and virtual events were described as unlikely to produce enough circular demand on their own. On market structure, the critique argued that a DAO-operated arbitrage strategy would need automation, likely through a PAMM-SAMM bot or similar mechanism, and that removing secondary liquidity would be confusing and difficult to enforce. Option C was viewed as the most plausible, but the question remained where additional liquidity would come from and whether providing exit liquidity was the best use of remaining treasury resources.
A response acknowledged the mistaken framing around holder growth and clarified that the holder count was a distribution snapshot rather than a reliable measure of active participation. It accepted that the market price was largely reflecting underlying asset value, but framed that as consistent with TEC’s design as a reserve-backed public goods token rather than a speculative asset. The response also acknowledged that token sunsetting was a legitimate option available to token holders, while arguing that TEC was still adding value through grants, infrastructure, and ecosystem work.
On utility, the response argued that the most developed and promising path was integration with the grants program, while publishing and events remained earlier-stage experiments. On market architecture, the response agreed that the BCRG-style arbitrage bot was relevant and that a DAO-operated arbitrage approach with lower tribute rates might better manage liquidity and tribute flow. It also recognized that Option B would reduce accessibility and that Option C would require governance support and a credible source of liquidity.
July 19 to July 22, 2025
The thread continued with a further argument that TEC had already had a full market cycle to try to bootstrap the token economy and that the community should hold a broader discussion about whether to maintain the ABC or shut down the Common Pool and focus on TEC’s core competency: advancing token engineering.
Another response supported Option C, arguing that maintaining the dual-market structure while gradually improving liquidity would preserve flexibility, reduce risk, and avoid the disruption of more drastic changes. The response suggested that a TEC/ETH pool could help, while also leaving open the possibility of mission-aligned diversified liquidity pairings with partners such as OP or GIV.
By the end of the thread, the TEC Token Infrastructure and Utility Report had become both a diagnostic and a strategic fork in the road. It documented the state of TEC’s supply, pools, tributes, liquidity, and utility options, while also surfacing serious questions about declining holder participation, token demand, the limits of the ABC and secondary market structure, and whether TEC should continue trying to build token utility or begin planning a respectful wind-down.
2025-07-12 to 2025-07-22 — TEC Grant Program Analysis and Framework Proposal
Forum thread: TEC Grant Program Analysis & Framework Proposal Category: Grants Program Archive theme: Grants program retrospective, funding framework, real-world impact, Tunable Quadratic Funding, TEC token utility, sustainable grant funding, grantee support
July 12, 2025
A Grants Program analysis and framework proposal was opened to evaluate TEC’s grantmaking history and propose a new direction for the second half of 2025. The thread began by placing TEC’s work in the broader Ethereum grants landscape, where programs such as Gitcoin, Octant, clr.fund, and others had helped energize the ecosystem but also revealed problems of fragmentation, short-termism, unstable funding sources, and a tendency to reward visibility more than sustained impact.
The proposal argued that TEC’s grants program had been more than a funding mechanism. It had functioned as a strategic catalyst for token engineering ecosystem development, a way to surface priorities, a signaling layer for the field, and an internal alignment mechanism for the Commons. By funding research, tools, simulations, governance primitives, educational resources, and open-source infrastructure, the program helped define what TEC believed mattered and created relationships around that work.
The long-term grant program vision was organized around three goals. First, TEC needed more predictable financial support infrastructure. Rather than relying on one-time donations, last-minute sponsorships, or Common Pool drawdowns, the proposal suggested building revenue-sharing relationships with validators, node operators, protocol treasuries, and other infrastructure beneficiaries who profit from Ethereum and Web3 ecosystems and may have reason to support foundational public goods.
Second, the proposal argued that TEC token utility should be embedded directly into grant program design. Possible mechanisms included staking TEC for curation power, using TEC donations for quadratic funding boosts, and allowing TEC holders to vote on matching allocations, thematic priorities, and distribution processes. The goal was to make TEC a coordination instrument for grantmaking rather than a passive governance token.
Third, the proposal called for more intimate post-grant support through a Token Engineering Network. Instead of treating grants as one-time transactions, TEC would support grantees through peer circles, mentorship, integration pathways, visibility support, and connections to existing research, tools, and infrastructure. The intended shift was from a grant vending machine toward a community accelerator for token engineering public goods.
The proposal then reviewed the grant program’s iteration history across four dimensions: funding sources, funding mechanisms, funding focus areas, and funding stage. It noted that TEC had attracted external capital in several recent rounds, experimented with Tunable Quadratic Funding, integrated TQF into the Gitcoin Grants Calculator, and used rounds as both funding exercises and mechanism research opportunities.
For the second half of 2025, the proposal recommended narrowing the grant program around Real-World Impact. These projects would use token engineering methods to address concrete social or environmental challenges, with clear societal benefit, measurable outcomes, stakeholder engagement, scalability, replicability, sustainability, evidence-based impact assessment, and ethical design.
The proposal also introduced a funding-stage focus on zero-to-one projects. TEC would prioritize early ideation, research, prototypes, and foundational infrastructure that might be too early for traditional funding. The proposed structure began with a TQF Discovery Round with a 10,000 dollar matching pool, followed by retroactive funding for projects that completed agreed milestones. Future retro rounds could either repeat the discovery-and-retro cycle or steward selected projects through progressively larger milestone-based funding.
The thread framed the second half of 2025 as an inflection point. By narrowing the funding focus, supporting earlier-stage projects, and creating a clearer impact definition, TEC could become a more differentiated and effective grantmaker rather than competing directly with larger public goods funding platforms.
July 19 to July 22, 2025
The discussion raised several strategic questions about the proposed direction. One response asked how TEC’s sustainable funding model would differ from or relate to Octant, especially if TEC hoped to attract funding from validators or infrastructure stakeholders. The same response questioned whether using TEC token utility would make the program more or less attractive to funders, and suggested that QF might not be the best mechanism for a capital-constrained program. Flow funding, Conviction Voting, or other mechanisms built on newer Allo infrastructure were raised as possible alternatives.
A reply clarified that Octant was seen as an important example because of its predictable funding base and its emerging yield-generating vaults. Rather than competing directly with Octant, one possible path would be to partner with or learn from that infrastructure. The discussion also contrasted Octant’s funding base with Gitcoin’s increasingly uncertain community matching model, suggesting that TEC needed to diversify beyond dependency on Gitcoin if it wanted durable funding capacity.
The conversation then outlined three possible funding directions: partner with Octant or similar infrastructure, find TEC’s own long-term infrastructure sponsor or validator-like funder, or try to fit into Gitcoin’s evolving allocation system. Regardless of funding source, the allocation mechanism would depend on what tooling was available, and the thread acknowledged that QF might be best understood as a discovery and signaling mechanism rather than the only possible structure for grant distribution.
The discussion also returned to TEC token utility. The goal was not to turn TEC into an investment vehicle, but to make it a tool that could meaningfully influence grant allocation and program governance. Another response strongly supported embedding TEC utility into grant programs and suggested partnerships with aligned organizations, retroactive funding models, and AI-supported modeling tools as possible ways to strengthen the regenerative loop around TEC.
By the end of the thread, the grants framework proposal had reframed TEC’s grants program as a long-term institutional strategy. It connected grant funding to financial sustainability, token utility, grantee support, impact measurement, mechanism innovation, and real-world applications. The thread captured TEC’s attempt to move from running broad QF rounds toward a more focused, relational, and strategically differentiated grant program for token engineering projects with measurable real-world impact.
2025-07-15 to 2025-08-01 — TEC H1 2025 Deliverables Update
Forum thread: TEC H1 2025 Deliverables Update Category: Community Updates Archive theme: H1 2025 deliverables, program accountability, grants infrastructure, publishing, token infrastructure, fundraising, governance, prioritization
July 15, 2025
A H1 2025 deliverables update was published to summarize the Coordination Team’s work across the first half of the year. The report reviewed progress across four strategic objectives and eleven programs, describing what was completed, what was delayed or deprioritized, and what lessons should guide planning for H2.
The report framed H1 as a period of meaningful progress but also recalibration. Several initiatives met or exceeded expectations, especially publishing, Research Hub development, grants infrastructure, TQF implementation, and token infrastructure repair. At the same time, the update acknowledged that the team had taken on too much, that capacity changed during the period, and that several original goals lacked clear success metrics or underestimated implementation friction.
The first objective focused on awareness and education. The TEC Library was launched and populated with more than sixty curated resources, though it fell short of the one-hundred-resource target. The content distribution work performed strongly: four newsletters were published, four online events were hosted, social media engagement grew substantially, and TEC expanded its recurring presence beyond X into YouTube, LinkedIn, and Instagram. The report also noted that subscriber growth remained slower than expected and that future online events would shift toward a more opportunistic, quality-focused cadence.
The knowledge-infrastructure work produced mixed results. A TEC Retro Round GPT was launched as an experiment for grants-program support, but no broader TEC Library-based AI agent was deployed because of unclear ownership, limited technical capacity, and uncertainty around near-term value. Knowledge Commons exploration also remained preliminary. A call was held with an aligned organization and an internal roadmap was drafted, but no formal collaboration emerged because timing, priorities, and product maturity did not align.
The education program produced four articles focused on TEC’s core themes of regenerative economics, token engineering, public goods, and decentralized networks. Two Research Hub events were held, with recordings and related materials distributed through the newsletter and social channels. However, the program fell short of the original four-event Research Hub target and did not host a virtual conference MVP. The report concluded that a virtual conference should become a sharper experiment for H2 rather than remaining a broad H1 ambition.
The grants program advanced through retrospective and framework development. A comprehensive analysis of past TEC grant rounds was published, and a new grants framework was drafted for release and iteration in H2. The report also documented that Tunable Quadratic Funding had been successfully integrated into the Gitcoin QF calculator, exceeding the initial goal of merely assessing feasibility. However, external adoption of TQF did not materialize during H1, and impact acceleration and collaborative grants remained exploratory rather than executed.
The token infrastructure program completed important foundational repairs. The new TEC Swap site was launched to restore interaction with the Augmented Bonding Curve, access and permissioning needs were audited, and initial liquidity analysis was completed. The report acknowledged that token utility experiments were not launched in H1 because limited funding and reduced team capacity forced attention toward rebuilding core infrastructure first. The outlook for H2 emphasized activating token utility, using the grants program as a possible testing ground, and improving market structure through deeper and less fragmented liquidity.
The fundraising program produced notable inflows but not a full external fundraising system. TEC secured an ongoing OP RetroPGF 6 stream of roughly sixteen thousand OP and received funding from the Gitcoin Grants 23 OSS round. The Token Engineering Superchain Retro Round also secured twenty-one thousand dollars in Gitcoin matching funds, covering more than half of the grant budget. However, no OP mission request was submitted, no formal sponsorship deck was completed, and outreach did not produce the desired sponsor pipeline.
Governance and ecosystem development were more limited. The governance interface was fixed and relaunched, restoring access for onchain DAO decision making. One Snapshot vote was completed, but participation goals were not met, a second Snapshot vote was not conducted, the broader governance framework was deprioritized, and the advisory network was not developed. The proposed Opportunity Board was also shelved because of bandwidth constraints and uncertain demand.
The report concluded that H1 had been a cycle of foundational work, experimentation, and learning. TEC had strengthened grants infrastructure, publishing capacity, token infrastructure, and content distribution, but the experience showed the need for narrower scoping and more disciplined prioritization. The H2 outlook emphasized fewer high-impact initiatives, clearer token utility experiments, and ecosystem engagement that more directly strengthens TEC’s value proposition.
August 1, 2025
A later reply pointed to an external AI-agent tool designed for knowledge bases and suggested that it might be useful for TEC’s library or knowledge-management ambitions. This connected back to the report’s decision not to continue building a TEC AI agent internally, while still leaving open the possibility that lower-overhead external infrastructure could support future knowledge work.
By the end of the thread, the H1 deliverables update had become a public accountability checkpoint. It documented delivery across publishing, grants, infrastructure, fundraising, and governance, while making clear that TEC needed to enter H2 with fewer priorities, stronger ownership, clearer success metrics, and a tighter connection between program activity and community value.
2025-07-20 to 2025-07-23 — TEC H2 2025 Strategic Proposal
Forum thread: TEC H2 2025 Strategic Proposal Category: TEC Strategy & Governance Archive theme: H2 2025 strategy, operating budget, real-world impact, grants program, storytelling, token infrastructure, community development, TEC token debate
July 20, 2025
A strategy and funding proposal was opened for TEC’s second half of 2025. The proposal framed this cycle around a central narrative shift: TEC should help move crypto away from speculation and mechanism hype and toward protocols, tools, and communities using blockchain for direct positive real-world impact.
The proposal looked back on H1 2025, noting progress on the TEC Publication, Research Hub, grants program work in the OP Superchain ecosystem, a new ABC page, the Aragon governance interface, and the integration of Tunable Quadratic Funding into the Gitcoin calculator.
The H2 strategy was organized around four focus areas: storytelling, education, and advocacy; grants program development; sustainability and infrastructure; and community development and visibility. These were presented as interlocking parts of one strategy rather than isolated workstreams.
Under storytelling, education, and advocacy, the proposal described continued publishing, the Rollup Report newsletter, TEC Talks, Research Hub events, a virtual conference pilot, and TEC Library development. The purpose was to make complex ideas in token engineering and real-world blockchain applications more accessible, while creating a repeatable content flow across events, recordings, articles, newsletters, and social media.
The grants section proposed a Real-World Impact grant round focused on early-stage projects applying token engineering to concrete social, ecological, or coordination problems. The round would begin with a 10,000 DAI quadratic funding round to surface promising ideas and could lead into a later retroactive funding process for projects that completed milestones. The strategy also included sponsor development so at least half of grant-round funds could come from external partners.
The sustainability and infrastructure section focused on external fundraising, token infrastructure maintenance, token utility experimentation, and governance infrastructure. The proposal aimed to raise at least 50,000 dollars through grants, consolidate TEC liquidity away from TEC/OP and TEC/GIV into a TEC/ETH Velodrome pair, test one measurable token utility use case in the grants program, and maintain the Aragon governance interface with tokenholder communication.
The community development section proposed website improvements, an onboarding kit, and a more sustainable cross-platform social media strategy. The goal was to make TEC easier to discover, easier to understand, and easier to join.
The financial request asked for approximately 58,200 DAI to fund Coordination Team operations from July through December 2025. The budget included staffing, incentives and bounties, tools, and miscellaneous costs. The proposed funding source combined remaining assets in TECAN, TEC GG, and LASERTAG multisigs, incoming OP RetroPGF 6 streaming funds, and a smaller Common Pool request. The proposal said a TAO vote would serve as approval for the Common Pool portion and as a signal to coordinate multisig and OP grant fund disbursements.
July 21 to July 22, 2025
The discussion quickly surfaced governance-process and strategic concerns. One response asked for a community call before execution, saying some parts of the plan were valuable but the budget seemed off. The reply from the proposal side argued that the advice process allowed asynchronous engagement and that open Coordination Team calls were available, so a dedicated call was not necessary at that stage.
The conversation then shifted toward the larger question of TEC’s future. A critique called for dissolving the TEC token and pursuing a graceful end-of-life for the token economy, with a counterproposal expected. The concern was that the H2 proposal did not yet have sufficient active community support, especially given recent low forum engagement and the volume of large Coordination Team posts released close together.
Another response supported parts of the strategic direction but suggested sharpening priorities. It argued that high-leverage digital marketing and short-form content could be more effective than resource-intensive panels or newsletters if the organization needed to stay lean. It also suggested that grants, fundraising, and user experience should remain core priorities because they were most directly tied to TEC’s survival and community growth.
July 23, 2025
The proposal authors responded by clarifying the role of the advice process and defending the structure of the proposal. They argued that the advice process was meant to surface feedback and improve the proposal before any vote, while actual community support would be reflected in the voting process. They also pushed back on the idea that using multisig-held funds bypassed tokenholder rights, explaining that those funds could not be moved unilaterally and that the proposal required token-holder ratification.
The discussion also clarified the intended relationship between storytelling and core survival needs. The response agreed that grants, fundraising, and user experience were essential, but argued that strategic storytelling, events, publications, and social media could support those priorities by building credibility, visibility, and narrative momentum. The content strategy was described as a flywheel where events generate recordings, clips, articles, newsletters, and social posts that help reinforce TEC’s reputation and fundraising capacity.
The final visible critique argued that the proposal still had serious issues under the TEC Community Covenant. The concerns were that the proposal bundled scoped multisig funds into the operating budget, did not include enough live participation or consultation, relied too heavily on activity-based deliverables instead of measurable impact and accountability, and expanded scope despite unresolved structural problems around token value, legitimacy, and traction.
By the end of the thread, the H2 2025 strategic proposal had become both an operating budget request and a debate about TEC’s strategic direction. It laid out an ambitious plan for real-world-impact storytelling, grants, token utility, governance, and community development, while the discussion raised fundamental questions about budget fit, multisig fund governance, community input, token sunsetting, and whether TEC should continue expanding its strategy or narrow toward a leaner path.
2025-07-23 to 2025-08-26 — Sunsetting the TEC: Proposal and Treasury Distribution Framework
Forum thread: Sunsetting the $TEC: Proposal & Treasury Distribution Framework Category: TEC Strategy & Governance Archive theme: TEC sunsetting, treasury distribution, tokenholder return, retroactive public goods funding, ABC closure, post-mortem, severance, community legacy
July 23, 2025
A sunsetting proposal was opened to initiate a structured shutdown of the Token Engineering Commons and distribute remaining treasury assets. The proposal argued that TEC had reached an end-of-life moment as an economic and governance system. It described a pattern of declining participation, low governance engagement, weak token utility, renewed treasury outflows, inactive signers, and a token trading at a discount to treasury value.
The proposal framed sunsetting as a responsible lifecycle decision rather than a failure. It compared TEC to an engineered system that had reached deprecation and argued that the Commons should be archived, documented, and closed with clarity instead of continuing as a low-velocity institution that slowly consumed the remaining treasury.
The central mechanism was a treasury distribution model based on two variables. The first was alpha, a parameter defining the split between tokenholders and retroactive public goods recipients. The second was a weight vector defining how the public-goods portion would be distributed across verified contributors or project-level multisigs. The proposed structure avoided new micro-grants or ongoing governance, and instead imagined a one-time execution process through a steward multisig.
The proposed execution process included inventorying dormant multisigs and public goods recipients, returning scoped funds to the Common Pool, freezing a tokenholder snapshot, upgrading or decommissioning the ABC so funds could be withdrawn into the Common Pool, voting on the alpha parameter, executing distribution through a trusted multisig, and archiving infrastructure, credentials, forum materials, GitHub repositories, and other operational records.
The proposal argued that TEC’s lasting contribution included funding and supporting cadCAD, Token Engineering Academy, conviction voting experiments, bonding curve research, and other token engineering work. Its final contribution, the proposal suggested, could be demonstrating how a DAO can shut down cleanly, distribute unused capacity, and preserve its legacy.
July 24, 2025
The first responses showed both support for closure and sharp disagreement over distribution. Some comments argued that TEC had struggled to fulfill its mission, that the token had not found product-market fit, and that the remaining funds should support the projects and people best positioned to carry token engineering forward. There was also support for severance or transition support for the small remaining team that had continued day-to-day operations.
A strong critique argued that the proposal looked less like a clean shutdown and more like a discretionary treasury allocation process. The concern was that retroactive public goods recipients were not clearly defined, the group deciding allocations was not yet accountable to the wider community, and the alpha model could be used to justify insider-directed distribution rather than a straightforward return to tokenholders. This critique argued that if the goal were a clean sunset, the default should be returning all remaining funds to tokenholders after covering clearly defined wind-down costs.
The proposal side responded that the alpha model was meant to give the community control over the split between tokenholders and public goods contributors, and that the range could include a full return to tokenholders. The response also emphasized that the proposed working group would not have autonomous authority because nominations, weights, and final parameters would be subject to public review and community voting. The disagreement therefore centered on whether the mechanism was a transparent framework for closure or an insufficiently specified process with too much discretion.
The conversation then broadened beyond mechanics. Some participants argued that ending the TEC token did not have to mean ending the TEC community. The token economy could be sunset while preserving forums, knowledge archives, relationships, and lightweight spaces for future token engineering discussion. Others suggested that some share of the remaining funds could support a minimal token engineering community, educational events, post-mortem analysis, or public goods aligned with TEC’s original mission.
A more detailed contribution argued that there were real reasons to consider ending the token: sell pressure, weak secondary market liquidity, price divergence from underlying assets, and the failure of TEC to develop a regenerative financial model. But it also cautioned that a full tokenholder liquidation might contradict the original intent of the Common Pool, which had been dedicated to token engineering public goods. This view suggested that a split between tokenholder return and public goods funding might better reflect the original ethos of the TEC experiment.
July 25 to July 26, 2025
The discussion became more intense around timing, legitimacy, and process. A major objection was that the proposal felt rushed and lacked concrete implementation details. Questions were raised about claims processing, dead or inaccessible wallets, hacked or drained wallets, outreach to tokenholders, unclaimed assets, whether distribution would be automated or manual, how long claims would remain open, and who had been consulted before the proposal was posted.
The critique also challenged the framing that TEC had failed because of token price or lack of product-market fit. It argued that TEC’s mission had never been solely about delivering returns to tokenholders and that its day-to-day value included maintaining a network, directing people to opportunities, facilitating first grants for developers, and supporting a broader community of practice. From this perspective, judging TEC only through token performance ignored the relational and public-goods functions that had continued even at lower velocity.
Other comments supported sunsetting but recommended a cleaner path. One view argued that tokenholders had every right to vote to sunset the DAO and redistribute assets, and that the simplest distribution would be a full return to tokenholders after funding a deliberate wind-down, severance for active contributors, and possibly an objective post-mortem. Another view supported a post-mortem and argued that the key lesson was that TEC launched as a token economy without a clear plan for income and token utility, leaving the Common Pool to be depleted rather than replenished.
The discussion also identified conflict-of-interest concerns around retroactive public goods distributions. If the people proposing or supporting the shutdown could also benefit from the remaining funds, then the process needed much clearer safeguards. Recommendations emerged to delay any rushed vote, let the Coordination Team’s existing H2 proposal proceed first, and, if a sunset became the preferred path, develop a detailed plan with a transparent budget for severance, wind-down execution, post-mortem analysis, and any remaining retroactive recognition.
The proposal author responded by restoring the broader alpha range, including the possibility of full tokenholder return, and by inviting more stakeholders into the discussion. The response acknowledged missing details and described the proposal as a public attempt to restart serious community engagement around TEC’s trajectory, not a final unilateral plan.
By July 26, several additional perspectives supported a structured shutdown while calling for collaborative refinement. The thread began to converge around a shared distinction: the TEC token economy might need to end, but the relationships, knowledge, archives, and community around token engineering could continue in other forms.
July 29 to August 4, 2025
The proposal author later reported that the Coordination Team and proposal supporters were working together to split the original sunsetting proposal into three separate sections: confirmation of TEC wind-down, a technical and operational implementation plan, and a treasury distribution plan that would include severance for active contributors and a post-mortem. This directly led into the later thread that proposed a first yes-or-no vote on whether to initiate the sunsetting process.
A later response opposed unwinding the community or token at that time. It argued that a new crypto market cycle could create renewed attention around the exact areas TEC had worked on for years: systems engineering, tokenomics, public goods, retroactive funding, and decentralized coordination. From this perspective, dissolving TEC would abandon hard-won positioning just as the ecosystem might again become receptive to TEC’s mission. The alternative proposed was not indefinite preservation, but a roadmap centered on renewed TEC token utility.
Another response was more supportive of sunsetting the economic layer while emphasizing preservation of TEC’s knowledge databases and archives. It suggested returning funds to tokenholders or giving tokenholders a final choice between tokenholder return and public goods distribution, possibly through a final grant round.
August 24 to August 26, 2025
Late reflections returned to the deeper legacy of TEC. One response argued that token engineering was, and perhaps still is, ahead of its time because ethics, safety, and rigor run against many extractive or low-friction design incentives in crypto. It emphasized that TEC funded education, research, tools, libraries, commons culture, and personal pathways into meaningful work, even if the token economy did not sustain itself.
Another reflection expressed gratitude for the experiences, opportunities, and professional development made possible through TEC. It also noted openness to participating in post-mortem or retrospective work on technical aspects of TEC’s system design, such as the Augmented Bonding Curve.
By the end of the thread, the original treasury distribution framework had transformed into a broader community reckoning over TEC’s end state. The discussion questioned whether the token should be sunset, how remaining funds should be allocated, whether tokenholders or public goods should be prioritized, how to avoid conflicts of interest, how to compensate active contributors, how to preserve TEC’s knowledge and relationships, and how to document the successes and failures of one of the earliest blockchain-based economic commons. The outcome of the thread was not a final distribution plan, but a decision to break the process into clearer stages so the community could first decide whether to begin winding down the TEC token at all.
2025-07-24 to 2025-12-16 — Request for Accounts Transparency
Forum thread: Request for Accounts Transparency Category: TEC Strategy & Governance Archive theme: treasury transparency, multisig inventory, account balances, OP RPGF funds, Giveth donations, DAO custody, sunsetting prerequisites
July 24, 2025
A request for accounts transparency was opened during the emerging sunsetting debate. The thread asked for the full list of TEC-associated multisigs and accounts with remaining funds, along with current balances and source links. The request argued that this information was essential for any future vote, whether the community chose sunsetting, restructuring, or continued operations.
The initial post noted that the H2 2025 Strategic Proposal and the initial sunsetting proposal both depended on knowing where TEC-controlled funds were held. It therefore asked for an up-to-date version of the multisig and signer inventory, while compiling a preliminary list of major accounts such as the Common Pool, Reserve, Coordination Team, TECAN, TE Grants Program, Lasertag, OP RPGF6 funds, TEC GG, Giveth donations, Transaction Team, and ABC EOA.
The thread framed account transparency as a practical prerequisite for both paths under discussion. If TEC continued, the community needed to know what funds existed and who controlled them. If TEC sunset, unused funds would need to be consolidated into the Common Pool before any claims, distribution, or wind-down process could be legitimate and complete.
July 25, 2025
The discussion quickly focused on two custody questions. First, OP RPGF6 funds appeared to be held in an EOA rather than a multisig. The request asked whether those funds could be moved into a multisig for better security and accountability. A reply explained that the OP RPGF funds were held in an EOA because of KYC restrictions, that the funding stream remained active through September, and that the funds belonged to TEC even though they could not be moved into a multisig at that moment.
Second, the thread identified that some Giveth donation routes pointed to an EOA while others pointed to a TEC multisig. The question was whether the EOA owner was known and whether those funds should be returned to DAO custody. A response clarified that the EOA was controlled by a trusted person associated with TECAN and that this structure had been agreed to for logistical reasons. The reply agreed that those funds should eventually be accessed, but explained that they had not been prioritized because the funds had been safely held and were not immediately needed.
The thread also clarified why the full signer spreadsheet would not be posted publicly. Because it linked people’s names to multisig responsibilities, it was treated as sensitive from a security perspective. However, the Coordination Team had access to the information and could privately confirm details as needed. The broader balance information was supplemented with public source links so community members could verify the accounts themselves.
December 16, 2025
After the TEC token had been shut down, the thread was revived with a concern that not all assets had been recovered before the kill switch was executed. The response asked which funds were being referenced and clarified that the Coordination Team multisig was intentionally excluded because it was being used to pay the approved shutdown budget, including severance and backpay, the retrospective analysis grant, sunsetting operations, and the claims contract.
By the end of the thread, the accounts transparency request had become an important companion to the sunsetting process. It helped surface the location of TEC-controlled assets, clarify custody constraints around EOAs and multisigs, identify funds that needed to be recovered or excluded, and establish that treasury inventory was necessary for both legitimate continuation planning and orderly shutdown execution.
2025-07-29 to 2025-08-14 — Proposal to Initiate the Sunsetting Process for the TEC Token
Forum thread: Proposal: Initiate the Sunsetting Process for the $TEC Token Category: TEC Strategy & Governance Archive theme: TEC token sunsetting, ABC decommissioning, treasury wind-down, tokenholder process, Snapshot vote, Covenant compliance, governance legitimacy
July 29, 2025
A proposal was opened asking TEC tokenholders whether the community should formally begin a structured sunsetting process for the TEC token. The thread clarified that this first vote would not determine fund distribution or operational execution. Instead, it would establish whether the community agreed in principle that the TEC token and related token infrastructure should be wound down.
The motivation was that TEC had moved from an active early-stage coordination experiment into a quieter and lower-velocity commons. The proposal argued that participation had slowed, governance activity had declined, and the token’s value proposition had become increasingly unclear despite attempts to restore engagement and utility. Rather than leaving the token economy in an indefinite holding pattern, the proposal framed sunsetting as a way to end this phase intentionally, transparently, and with dignity.
The proposed process was divided into three votes. The first vote would simply ask whether TEC should initiate the sunsetting process. If approved, a second proposal would define the technical and operational wind-down plan, including decommissioning the Augmented Bonding Curve, consolidating available funds into the Common Pool, compensating essential technical and operational work, and creating a secure tokenholder snapshot. A third proposal would define the final treasury distribution plan, including a post-mortem report, possible severance or thank-you payments for active contributors, and a final distribution framework for remaining funds.
The proposal emphasized that final execution and distribution would only begin after all three proposals passed. The proposed timeline imagined an initial forum and Snapshot vote within several days, followed by Proposal 2 and Proposal 3 about a week apart, with execution and distribution beginning after the final vote and aiming to complete within several weeks.
The thread framed the decision as a continuation of TEC’s values rather than a declaration of failure. TEC was described as an experiment in collective stewardship, infrastructure design, and regenerative funding, and the proposal asked the community to close this chapter with the same care and coordination values that shaped its beginning.
July 30, 2025
A follow-up shared the official Snapshot vote for the first proposal. This moved the thread from an initial forum discussion into the first formal signaling step of the proposed three-part sunsetting process.
August 12 to August 14, 2025
The thread was later revived with questions about whether the proposal and vote complied with the TEC Community Covenant, especially around the advice process, community participation, offchain voting, onchain voting, and decisions with financial or code implications.
A response argued that the Covenant was being followed and that the broader sunsetting discussion had already shown overwhelming support for beginning a structured wind-down. The response clarified that this thread functioned as a more granular amendment to an earlier sunsetting proposal by splitting the process into three separate votes: first, confirmation of the wind-down; second, a technical implementation plan; and third, a treasury distribution plan including contributor severance and a post-mortem.
The compliance challenge continued. A critique argued that using Snapshot or Tokenlog for a decision of this constitutional importance was not sufficient, because winding down the token could affect treasury rights, tokenholder interests, governance rights, and core smart-contract infrastructure. From that perspective, the vote was not merely a signal but the beginning of a binding wind-down process and therefore required more robust deliberation, impact analysis, and formal governance procedure.
The response pushed back by arguing that Snapshot had become the practical voting method after the Optimism migration because the previous Aragon infrastructure had not been deployed on Optimism. It also argued that this first proposal did not itself move funds, alter contracts, or execute distribution. The concrete financial and technical actions would come only in the second and third proposals, which would also need to be ratified by the Commons.
The final visible exchange left the dispute unresolved. The critique maintained that a token wind-down was constitutionally different from an ordinary budget decision because it could divest tokenholders of capital interests and governance rights. The thread therefore captured not only the beginning of the TEC token sunsetting process, but also a live disagreement over what level of process, consent, and governance authority was required to legitimately initiate the end of the token economy.
By the end of the thread, TEC had moved into a formal debate over sunsetting the TEC token. The proposal established a three-step path for confirming wind-down, designing technical and operational closure, and distributing remaining treasury funds. The discussion also exposed the central governance tension of this stage: whether beginning the sunsetting process through Snapshot was a legitimate tokenholder signal under TEC’s evolved post-migration governance reality, or whether the constitutional weight of token closure demanded a stricter Covenant-based process before any vote could be considered valid.
2025-08-21 to 2025-09-16 — Sunsetting Implementation for the TEC Token
Forum thread: Sunsetting Implementation for the $TEC Token Category: TEC Strategy & Governance Archive theme: TEC token wind-down implementation, asset consolidation, rETH claims contract, Guardians, hacked-wallet disputes, multisig recovery, governance rights, residual tokenholder claims
August 21, 2025
An implementation proposal was opened to operationalize the TEC token wind-down. Unlike the earlier proposal that asked whether the token should be sunset, this thread focused on the technical, operational, and procedural steps required to move from a decision to wind down into an executable closure process.
The proposal established a plan to consolidate all recoverable TEC-related assets into the Common Pool, convert recovered assets into rETH, and create a minimal claim mechanism for TEC tokenholders. It proposed upgrading legacy Aragon contracts so the Reserve and Common Pool could be frozen in a recoverable state and so funds could flow from the Reserve into the Common Pool and then into a claim contract.
The proposal required all TEC-related multisigs and EOAs to remit remaining funds to the Common Pool within fourteen days. If a unit did not act by the deadline, it would be marked dormant and documented publicly, with later recoveries added to the claim contract as top-ups. Any TEC held by participating multisigs would be burned through the ABC or otherwise removed from circulation to avoid circular accounting.
The proposal also addressed OP RetroPGF funds vesting through Superfluid. The default rule was that, as those funds vested, they would be routed to the Common Pool and converted into rETH unless governance directed otherwise before execution.
A fixed budget of 5,000 dollars was proposed for an implementation partner to build a lightweight claim contract and user interface. The claims process would snapshot TEC balances at the frozen block, calculate a TEC-to-rETH rate from total assets committed to claims, maintain a record of claimed addresses, and allow tokenholders to claim through a simple interface. The claim period would be indefinite by default, with any future end date or treatment of unclaimed funds requiring a later governance decision.
The proposal included a hacked-wallet dispute process. For four weeks after passage, the community could raise cases involving compromised wallets. Reported addresses would be temporarily blocked from claiming while a review panel evaluated evidence such as transaction history, incident descriptions, due-process proof, and prior ownership proof. Approved cases would blocklist the compromised address and allowlist a replacement address for the same amount. Denied cases, or cases with no decision, would allow the original address to claim after the hold expired.
The requested governance decisions included authorizing Guardians to upgrade and freeze legacy contracts, mandating the fourteen-day remittance window, requiring rETH conversion for inbound assets, funding the claim contract and UI, setting default OP RPGF routing, adopting the TEC burn policy for multisig-held TEC, approving the hacked-wallet process, and confirming indefinite claim-period logic by default.
August 23 to August 26, 2025
The first response treated the proposal as a meaningful technical contribution and suggested that it should be reviewed by people with deep expertise in TEC’s token infrastructure, governance, and system design. The level of detail was appreciated, but the implementation was seen as complex enough to warrant domain expert review before execution.
The discussion then turned to tokenholder rights and post-wind-down governance. Questions were raised about what would happen to TEC holders’ governance rights once assets were moved to the Common Pool and the bonding curve was frozen or deprecated. The thread also asked whether tokenholders would retain any formal voting or proposal rights after the wind-down, especially over future closure of claims or allocation of unclaimed funds, and how Guardians would remain accountable while holding central execution responsibilities.
The proposal side explained that a burn-based mechanism would likely require a temporary governance freeze because each claim would change the relative share of remaining holders over the Commons’ assets. Keeping governance active while claims were occurring could create attack or manipulation risks. At the same time, the TEC contracts would remain recoverable in case an unpause became necessary.
On claim closure and unclaimed funds, the response suggested that a month-long process after passage could be used to amend those parameters before execution, rather than trying to settle them inside this proposal. On Guardian accountability, the response argued that Guardians had already held significant post-Optimism permissions and had remained socially accountable, though it also suggested increasing the Guardian multisig threshold from three-of-seven to four or five as a possible additional safeguard.
A further clarification stated that, under this proposal, there would be nothing left for remaining TEC holders to govern after the claims contract went live. The Reserve and Common Pool would be converted into rETH and placed into a claim contract, with each TEC holder able to exchange their TEC for rETH at a fixed rate. Any future hatch, fundraise, or renewed effort would likely use a different token architecture and stakeholder set, separated from remaining TEC tokens.
This clarification prompted concern that the proposal would eliminate residual optionality for tokenholders who still wanted TEC to continue. The critique argued that converting all assets into rETH and placing them into an open-ended claim contract amounted to a forced end of TEC, rather than simply letting people exit if they wanted. Another response agreed that residual TEC tokenholder rights should be protected and asked that the proposal be modified to preserve some claim on future TEC assets or governance possibilities.
September 16, 2025
The thread was later revived with a reflection on the state of community engagement. The proposal author argued that the thread had been left open to see whether there was an active community that wanted to continue the TEC token, but that little evidence of broad active support had appeared. From this perspective, the absence of engagement around continuation suggested that the governance framework was no longer fit for purpose and that TEC risked entering a deadlock where neither continuation nor wind-down could pass.
A response challenged that framing. It argued that there was still an active alternative proposal on the forum, that absence of loud opposition should not be equated with absence of community engagement, and that asynchronous proposal refinement was a feature of TEC governance rather than a sign of failure. The response also cautioned against framing the Coordination Team or individual contributors as self-interested without evidence, and called for continued participation rather than prematurely declaring a deadlock.
By the end of the thread, the implementation proposal had clarified the technical path for a token wind-down while deepening the governance debate over what sunsetting should mean. It defined asset recovery, rETH conversion, claims infrastructure, hacked-wallet handling, Guardian responsibilities, and dormant multisig recovery. At the same time, the discussion surfaced unresolved questions about residual tokenholder rights, whether a claim contract should fully replace governance, how to preserve optionality for people who still wanted TEC to continue, and whether the Commons was truly inactive or still capable of negotiating a legitimate end-state.
2025-09-08 to 2025-09-16 — OTC Buyback Proposal
Forum thread: OTC Buyback Proposal Category: TEC Strategy & Governance Archive theme: OTC buyback, TEC continuation, tokenholder exit, alternative to sunsetting, claims contract, rETH conversion, Common Pool, governance compromise
September 8, 2025
An OTC buyback proposal was opened as an alternative to the full TEC token sunsetting implementation plan. The proposal was presented as a compromise between tokenholders who wanted to wind down the TEC token economy and tokenholders who wanted TEC to continue with its existing infrastructure and remaining resources.
The proposal argued that the worst outcome would be a split vote that created governance gridlock, leaving TEC without either a fair exit mechanism or a path for renewal. Instead of dissolving the token economy through an indefinite claims process, the counterproposal suggested creating a fixed-rate, time-limited OTC buyback program. Tokenholders who wanted to exit could sell their TEC back to the organization at a fair value, while those who remained would preserve the Commons and continue developing the mission.
The buyback price was proposed at approximately 0.20 dollars per TEC, calculated from the current value of the Common Pool, Reserve, and other TEC-controlled funds. Exiting tokenholders would not pay the standard bonding curve tribute tax or be forced into a race-to-the-bottom selloff in thin secondary markets. This was intended to create a clean and predictable exit for people who no longer wanted exposure to TEC.
The proposal also described how repurchased tokens would be handled. A portion would be reserved for secondary-market liquidity support, another portion would be reserved for token utility experiments and incentives, and the remainder would be burned to protect the floor price for remaining holders. Repurchased tokens would not be allowed to participate in governance decisions going forward, avoiding governance capture by treasury-held TEC.
Unlike the implementation proposal’s indefinite claim period, this proposal called for a fixed buyback window of roughly four to six weeks. After that window, the program would close and any remaining funds would return to the Common Pool for ongoing Commons initiatives. The claims contract approach would be similar to the sunsetting implementation proposal, but with a fixed exchange rate and fixed duration rather than a permanent redemption mechanism.
The budget requested 5,000 dollars for the claims contract and 10,500 dollars for organizing funds, proposal facilitation, and closure work. The proposal also approved consolidating remaining funds from multisigs and grant accounts into the Common Pool, converting assets to rETH, and moving rETH into the claims contract for the buyback process.
The proposal concluded by framing the buyback as a starting point for renewal. If it passed, the Coordination Team would continue facilitating new ideas, token utility work, token model review, and revenue-generating pathways with the remaining tokenholders.
September 13, 2025
A response supported the proposal’s overall attempt to offer both exit and continuation, but raised several concerns using Ostrom’s commons-governance principles. The strongest support was for the time-bound claims window, because it gave exiting holders a fair opportunity while allowing remaining participants to govern the Commons after the exit period closed.
The response objected to any interpretation of the buyback price as an indefinite floor. A fixed OTC rate could be useful during the exit window, but if treated as ongoing, it could distort market signals and create arbitrage opportunities. The response argued that after the exit window closed, remaining participants should accept the risks and volatility of continuing to govern a commons.
The strongest objection concerned the proposed use of repurchased tokens for liquidity boosts. The concern was that using Commons funds to support secondary-market liquidity could create speculative incentives and benefit those positioned to exit through improved market conditions, rather than supporting long-term mission-aligned utility. The response argued that repurchased tokens should instead be governed transparently by those who remain.
The response also emphasized that decisions about remaining funds should be made by the continuing governance body, not pre-allocated through the exit proposal. It requested more open forum debate before any vote, arguing that such a significant decision required broader communication and participatory review.
September 16, 2025
A follow-up announced that an active TAO Voting proposal was live and encouraged tokenholders to vote. By this point, the OTC buyback proposal had become the main alternative to the full token sunsetting implementation. It tried to preserve optionality: tokenholders who wanted to exit could receive a fair fixed-value buyout, while those who wanted TEC to continue could retain infrastructure, treasury, and governance capacity.
By the end of the thread, the buyback proposal had reframed the sunsetting debate from an all-or-nothing wind-down into a question of partial exit versus full closure. It introduced a practical mechanism for tokenholder liquidity, but also raised unresolved questions about liquidity support, the governance of repurchased tokens, post-window market dynamics, and who should control remaining Commons resources after exiting holders leave.
2025-10-17 to 2025-11-04 — TEC Shutdown Proposal
Forum thread: TEC Shutdown Proposal Category: TEC Strategy & Governance Archive theme: TEC shutdown, tokenholder distribution, contributor severance, archival process, post-mortem, claims contract, communications wind-down, final governance vote
October 17, 2025
A full TEC shutdown proposal was opened to bring the Commons itself, not only the TEC token, to an orderly close. The proposal built on the prior token sunsetting and implementation discussions, but reframed the process around the complete retirement of TEC’s technical, social, brand, knowledge, and financial assets.
The proposal began by describing TEC as an ambitious experiment to implement a blockchain-based commons for advancing token engineering. It argued that the Commons had reached a crossroads: without decisive action, TEC risked drifting into a drawn-out decline that would weaken its legacy and leave the community in limbo. The proposal was organized around three principles: honoring the legacy of the world’s first blockchain commons, exemplifying token engineering values through a responsible end-of-life process, and caring for the people who had continued stewarding the Commons.
The plan identified four major non-financial asset categories to sunset responsibly. First, the technical infrastructure would follow the previously developed implementation plan for dissolving the Augmented Bonding Curve, moving funds, and handling claims. Second, knowledge resources from GitBook, the forum, and other TEC platforms would be preserved for public reference under a Creative Commons license. Third, the TEC brand would be retired, with branding assets archived on GitHub under their existing license. Fourth, communication platforms would be used for tokenholder outreach during the notification period and then archived or shut down where feasible.
The knowledge-preservation section also proposed a final 10,000 dollar grant to the Bonding Curve Research Group for retrospective analysis of TEC’s major mechanisms, including the Augmented Bonding Curve, Conviction Voting, and the Praise system. This was described as the final grant to be made by TEC and as a way to document the experiment’s lessons for future commons and token engineering projects.
The proposal then described TEC’s remaining obligations. It stated that TEC had funded more than 433,000 dollars in direct grants to token engineering projects and that its Gitcoin collaboration had catalyzed an additional 250,000 dollars. With grantee obligations fulfilled, the remaining responsibilities were to current contributors and tokenholders.
For contributors, the proposal included backpay and severance for the remaining Coordination Team. It argued that a small skeleton crew had continued stewarding TEC under difficult conditions, often below market rates and without touching the Common Pool for a long period. It proposed discounted backpay for three months of unpaid work and severance based on 1.5 weeks per year of service. The total backpay and severance amount was 27,171 dollars.
For tokenholders, the proposal recommended that all remaining financial assets after the sunset budget be distributed pro rata. To reduce speculative behavior, distribution would be calculated using the lower of a holder’s TEC balance on July 23, 2025, when the sunsetting plan was first publicly announced, or their balance on the dissolution date when the proposal was enacted. The claims process would run for six months with heavy upfront notification and a final month of high-frequency outreach. Any unclaimed funds after the notification period would be donated to the Giveth Galaxy Cause.
The full sunset budget totaled 52,671 dollars. It included severance and backpay, the retrospective token engineering analysis grant, shutdown operations, and the claims contract. The proposal described shutdown operations as covering the practical work of archiving knowledge bases, handling communications, managing the claims process, and addressing unforeseen costs during closure.
October 17 to October 20, 2025
Early responses generally supported the proposal as a responsible and difficult but necessary wind-down. One response framed end-of-life planning as part of both engineering and biological lifecycles: when infrastructure no longer serves its constituents, a controlled wind-down allows resources and lessons to be redistributed into other ecosystems.
Another response offered a Global South perspective, arguing that TEC and TE Academy were not failures but courageous experiments whose ideas could still live in new applied settings. This reply did not ask for funding, but asked for access to TEC’s knowledge and occasional dialogue with experts so that token engineering ideas could be carried into practical projects elsewhere.
A grantee also expressed gratitude for TEC’s Gitcoin Grants rounds, saying that TEC support had helped their project become what it was. Another response committed to supporting the proposal and emphasized that TEC’s shutdown was unusually clean compared with many DAOs. Instead of slowly draining the treasury, the remaining stewards had fought for years to keep the DAO alive and preserve the Common Pool. This was framed as an integrity story that should be remembered in the retrospective.
October 21 to October 22, 2025
The discussion then moved into refinements around legacy and distribution. One response argued that the proposal should formally recognize early Hatch participants and long-term contributors, not only tokenholders captured by the snapshot. The concern was that the historical record should preserve who helped build the experiment and prevent any future attempt to “rehatch” or reuse TEC assets without honoring the original community. The response also suggested that unclaimed assets should return to active tokenholders rather than being donated to charity by default.
A reply acknowledged the desire to recognize early participants, noting that Hatch-related NFTs and POAPs existed and should be tracked down or included in the archival record. But it argued that giving Hatch participants a distribution boost over later token purchasers would create difficult fairness questions because no such arrangement had ever been promised. The reply also defended donating unclaimed funds to Giveth Galaxy, arguing that Giveth had supported TEC with infrastructure, domains, bots, websites, and the forum over many years and should not be treated as an unrelated charity.
Another response added that TEC’s POAPs, Hatch Bot NFTs, token contracts, and other important addresses should be preserved alongside the social media and knowledge-platform archives. This expanded the archival scope from documents and communications to include onchain memory and participation artifacts.
The proposal also received a closing statement from one of the earlier sunsetting proponents, who supported the final shutdown plan as a loving and intentional closure rather than a slow decay. The response still wished there had been more budget for a comprehensive post-mortem of the major mechanisms and social evolution of the Commons, but accepted the proposal as a viable path to close in the spirit of care, curiosity, and reflection.
October 27 to November 4, 2025
Later reflections emphasized the personal and professional impact of TEC. One response described how the TEC community had encouraged, guided, and empowered contributors whose later work in crypto and adjacent projects grew out of TEC relationships. This reinforced the idea that TEC’s legacy was not only in grants and mechanisms, but also in people, projects, and communities that spun out of the Commons.
On October 29, the governance vote was announced as live. The announcement also noted that work had been required to resolve infrastructure issues so the vote could happen. On November 4, the thread was updated to say that the TEC Shutdown Proposal had officially passed. The Coordination Team would provide further informational updates about fund distribution, work agreements, and the claims-process timeline as TEC moved toward the end of the year.
By the end of the thread, TEC had moved from debate over whether and how to sunset into an approved shutdown plan. The proposal established the final budget, contributor support, tokenholder distribution method, archival responsibilities, claims period, communication wind-down, and final retrospective grant. It marked the formal transition from TEC as an operating commons into TEC as an archived experiment whose remaining work would be closure, distribution, documentation, and legacy preservation.
2025-12-02 to 2025-12-11 — TEC Token Sunset
Forum thread: TEC Token Sunset Category: TEC Strategy & Governance Archive theme: final token sunset implementation, snapshot adjustments, bonding curve closure, claims contract, rETH and DAI distribution, treasury consolidation, claim window, TEC closure execution
December 2, 2025
A final implementation post was published to describe the operational details of the TEC token sunset. The thread established this post as the authoritative version of the sunset implementation, superseding older descriptions where technical constraints required changes.
The first major clarification concerned the snapshot rule. To prevent last-minute speculation, each address’s claimable amount would be based on the lower of its TEC balance on July 23, 2025, when the sunset plan was publicly announced, or its TEC balance at the dissolution date, when the final vote passed and the snapshot was taken. This meant that holders who sold after July 23 would need to reacquire TEC to preserve their claim, while holders who bought additional TEC after July 23 would have those excess tokens deducted from their claimable amount.
The post then identified addresses that would have balance deductions if the final snapshot matched the then-current comparison. Those deductions would not go to the buyers who accumulated after the announcement. Instead, the value of the deducted TEC would be redistributed pro rata to other eligible TEC holders.
The technical implementation replaced the bonding curve with a minimal withdrawal and claims contract. Claimants would send TEC from their address and receive a proportional share of the treasury. The payout would be calculated pro rata based on circulating TEC supply, excluding TEC held by DAO contracts, liquidity pools, or burned addresses. The distribution would use two assets: rETH and DAI.
The claim window was planned for roughly six months. After the window closed, a remaining-claims function would allow the leftover funds to be claimed by the Giveth address designated in the shutdown plan. Hacked-wallet and other edge cases were not handled directly in the contract; instead, they would be handled manually before or after the claims window based on the established reporting process.
The post also explained the pre-deployment treasury work. Reachable treasury assets would be sent to a consolidation address, TEC/OP and TEC/GIV liquidity would be removed, volatile assets would be converted into rETH, stable assets into DAI, and all TEC, rETH, and DAI would be moved to the Common Pool except for funds needed for final contributor payments.
The final governance vote would withdraw rETH from the ABC into the Common Pool, approve the claims contract to withdraw rETH and DAI from the Common Pool, burn TEC in the Common Pool, and define the dissolution timestamp for the final snapshot. After the vote, the team would prepare the balance snapshot, calculate final applicable balances under the lower-of-two-dates rule, and compute the final circulating supply for pro-rata claims.
The timeline expected the governance vote in the first week of December, claims to open in mid-December, edge-case reports to remain open through January 31, 2026, and claims to close on June 20, 2026.
December 4 to December 10, 2025
The governance vote was posted on December 4. On December 9, the thread was updated to say that the vote had passed and was in the delay app, meaning it would execute unless stopped by the Guardians.
On December 10, the vote was executed. This effectively burned roughly 24,000 TEC from the Common Pool, approved the movement of rETH and DAI from the Reserve and Common Pool into the claims contract, closed the bonding curve, and created the final TEC snapshot at the specified Optimism block. From that point forward, attempts to buy or sell TEC through the bonding curve would fail because the required authorization was no longer available.
The same update described the next calculation step: compare TEC balances at the July 23 announcement block and the December 10 dissolution block, use the lower balance for each address, and configure the claim contract with the adjusted claim amounts. A list of addresses with changed balances was published, along with the addresses that had acquired TEC after the announcement and would have those excess balances deducted. The total post-announcement deduction was reported as 5,846.0032 TEC, to be redistributed pro rata to eligible holders.
December 11, 2025
The thread was updated to announce that claims were live at the TEC conversion site. A test claim was reported, showing that holders could now exchange their TEC for DAI and rETH through the claims interface. The post noted the emotional weight of the moment, while also emphasizing that TEC was closing with integrity and that holders who stayed to the end were receiving more than the market price before the bonding curve closed.
By the end of the thread, the TEC token sunset had moved from planning to execution. The bonding curve was closed, the snapshot was taken, balances were adjusted to prevent post-announcement speculation, rETH and DAI were routed into the claims system, and the public claims interface was live. This thread marked the operational end of TEC as a token economy and the beginning of the final claims period for remaining TEC holders.