Backwards Compatibility and Breaking Change Guide

[SimiHunjan]

This topic is on creating a backwards compatibility and breaking change guideline for projects in Hiero such that the community and maintainers of projects can reference and adhere to.

I have an initial proposal for what this should entail:

Overview

Hiero projects are committed to maintaining backwards compatibility to ensure a seamless experience for users and developers. This document outlines the approach to backwards compatibility, the process for introducing breaking changes when necessary, and the communication and deprecation timelines required to maintain transparency and stability within the Hiero ecosystem.

All Hiero projects under the Hiero GitHub organization would follow this guideline.

Ensuring Backwards Compatibility

• All changes must be evaluated for their impact on existing users and applications.
• Consider every public API as potentially accessible to any community member.
• Feature enhancements and bug fixes should be implemented in a way that does not break existing functionality.
  • Add new methods instead of modifying existing feature behavior like changing return types.
• APIs and data structures should follow versioning best practices to avoid disruption.
• Deprecation of features must be accompanied by clear documentation and migration paths.

Breaking Changes Process

If a breaking change is deemed necessary, the following process must be followed:

1. Proposal and Review
   • A detailed proposal outlining the breaking change must be submitted for review.
   • The proposal must include justification, potential impact, and alternatives considered.
   • Internal stakeholders and technical leads must review and provide feedback.
2. Hiero Technical Steering Committee (TSC) Approval
   • A formal meeting with the Hiero Technical Steering Committee (TSC) must be scheduled.
   • The TSC will review the proposed breaking change and assess its necessity and impact.
   • Approval from the TSC is required before proceeding with the implementation.
3. Deprecation and Communication Plan
   • A structured deprecation plan must be established, adhering to best practices.
   • The deprecation timeline should provide users with adequate time to migrate.
   • Clear documentation, including migration guides and upgrade instructions, must be published.
   • Communication should include:
     • Announcements in official Hiero community channels.
     • Announcements in official Hedera community channels.
     • Updates in release notes.
     • Notifications in relevant technical documentation.
4. Implementation and Monitoring
   • The breaking change should be implemented with feature flags, if possible, to allow gradual adoption.
   • Monitoring should be in place to assess adoption rates and identify potential issues, if applicable to the project.
   • Feedback from the community should be actively collected and addressed.

Deprecation Timeline Best Practices

• Initial Announcement: At least 3 months before enforcement, announce the deprecation and provide migration guidelines.
• Active Support: Continue supporting the deprecated feature for at least 6 months while encouraging migration.
• Final Removal: The feature is removed only after the communicated timeline has elapsed and sufficient migration support has been provided.

[tomachianura]

Dear Hedera Team,
Thank you for initiating a discussion on backward compatibility and breaking change guidelines for Hiero projects, as outlined in your initial proposal.

While we appreciate the intent to formalize these processes, we believe the current approach falls short of addressing fundamental concerns that impact Hedera’s credibility as a secure, stable, and enterprise-ready blockchain.

Below, we elaborate on the most pressing issues — frequent network upgrades, the immutability of native services, and the developer experience — while proposing actionable solutions to ensure Hedera remains a trusted platform for builders and enterprises.

---

1. Frequent Network Upgrades: A Threat to Security and Enterprise Adoption

Concern: Upgrading the Hedera mainnet every two weeks introduces significant risks and undermines professionalism, potentially deterring enterprise adoption.
Analysis: In traditional software development, rapid release cycles can drive innovation, but blockchain networks operate under a different paradigm. As a decentralized trust layer, Hedera must prioritize stability and predictability over frequent iteration. Biweekly upgrades increase the attack surface by introducing new code into a live environment without sufficient time for exhaustive testing or community validation.

This cadence risks:
Security Vulnerabilities: Insufficient time to identify and patch exploits before deployment.
Operational Instability: Unintended regressions or bugs disrupting live applications.
Perception of Immaturity: Enterprises, accustomed to long-term support (LTS) models in traditional infrastructure, may view this as unprofessional and unreliable.

Enterprise Perspective:
Enterprises select blockchain platforms based on their ability to provide a stable foundation for mission-critical applications. A biweekly upgrade schedule signals unpredictability, clashing with the multi-year planning horizons typical of enterprise IT. Competitors like Hyperledger Fabric or Ethereum offer more measured upgrade cycles, reinforcing their appeal to risk-averse organizations.

Recommendation:

• Transition to an annual upgrade cycle with a clear, published roadmap (e.g., 6-12 months in advance).
• Implement extended testnet validation (minimum 6-8 months) and incentivize community participation in stress-testing upgrades.
• Conduct mandatory third-party security audits for every release, with results publicly disclosed prior to mainnet deployment.
• Adopt phased rollouts using feature flags to mitigate disruption and allow real-time monitoring.

---

2. Immutability of Native Services: A Non-Negotiable Principle

Concern: Deprecating native service's features (either on consensus nodes or on sdk) related to Hedera Consensus Service (HCS), Hedera Token Service (HTS), and Hedera File Service (HFS) contradicts the immutability guarantees offered to smart contracts, eroding trust in the native layer.
Analysis: Hedera’s native services are marketed as a differentiator, enabling developers to build without relying on smart contracts. However, this value proposition hinges on the same immutability that smart contracts provide. Smart contracts on Hedera are guaranteed to remain unchanged once deployed, ensuring that application logic persists indefinitely. Native services must uphold this standard, as they form the bedrock of appnets—application-specific networks built atop Hedera.

Deprecation, even with a 6-month timeline, violates this principle by:
Undermining Trust: Developers expect native APIs to be as permanent as smart contract bytecode.
Breaking Parity: If smart contracts are immutable but native services are not, appnets using the latter are unfairly disadvantaged.
Forcing Redevelopment: Any deprecation requires appnet operators to rewrite and redeploy, negating the “build once, run forever” promise.

Technical Implications:
Consider an appnet leveraging HTS for tokenized assets. A deprecated API or altered behavior (e.g., modified return types) would invalidate the appnet’s hashing or compiled state, breaking its immutability and potentially its functionality. This is unacceptable for a blockchain promising enterprise-grade reliability.

Recommendation:
Commit to Permanent Stability: Declare HCS, HTS, and HFS as immutable at their current functionality level. Enhancements must be additive, not subtractive.
Adopt Versioning: Introduce new features via versioned APIs (e.g., HTS v2) while preserving v1 indefinitely, mirroring smart contract deployment patterns.
Align with Blockchain Principles: Treat native services as part of the protocol’s immutable core, ensuring parity with smart contracts in permanence and reliability.

---

3. Developer Experience: Ensuring “Build Once, Run Forever”

Concern: Frequent upgrades and potential deprecations force developers to continuously update appnets, draining resources and introducing bugs/regressions.
Analysis: Developers building on Hedera’s native services expect a frictionless experience where their appnets—once developed, compiled, and hashed—remain functional without ongoing maintenance.

Biweekly upgrades and a 6-month deprecation timeline shatter this expectation by:
Mandating Continuous Updates: Developers must re-engineer, re-test, and re-deploy appnets to accommodate breaking changes, incurring significant time and cost.
Introducing Risk: Each update cycle risks new bugs or regressions, as evidenced by past Hedera releases (e.g., consensus disruptions or API inconsistencies).
Eroding Immutability: Appnets lose their “set-and-forget” quality, undermining Hedera’s promise of a tamper-proof ledger.

Real-World Impact:
Imagine a supply chain appnet using HCS for timestamped records. A breaking change to HCS forces the developer to refactor their codebase, recompile the appnet, and coordinate updates across all stakeholders. This not only consumes resources but also risks data integrity if migrations fail—hardly the hallmark of a professional blockchain.

Recommendation:
Guarantee Backward Compatibility: Ensure all public APIs remain unchanged indefinitely, using versioning for new functionality (e.g., HCS/v1 persists while HCS/v2 adds features).
Extend Deprecation Timelines: For critical security fixes necessitating breaking changes, enforce a minimum 18-24 month notice period, with robust migration tools and support. Non-critical deprecations should be prohibited.
Enhance Quality Assurance: Invest in automated regression testing across all native services to prevent bugs from reaching mainnet, supplemented by community bounties for identifying issues. (lately HackerOne has been suspended, no more bounties for bug hunters, very poor decision)
Provide LTS Releases: Offer Long-Term Support versions of the network software (e.g., 3-year support cycles) to give developers a stable target for appnet deployment.

---

4. Additional Pillars for a Robust Ecosystem

To strengthen our argument and align Hedera with enterprise and developer expectations, we propose the following enhancements:
Immutable Appnet Guarantees: Explicitly assure appnet builders that the native services their applications depend on will not change in ways that break compatibility. This could be formalized in a “Hedera Stability Covenant.”
Transparent Governance: Establish a Developer Advisory Council within the Hiero TSC, empowering the community to veto or refine proposed breaking changes.
Proactive Monitoring: Deploy real-time analytics to track upgrade impacts on appnets, with public dashboards to build trust and accountability.
Competitive Benchmarking: Align Hedera’s practices with industry leaders (e.g., Ethereum’s 12-18 month hard fork cycles) to reinforce its enterprise-grade positioning.

---

5. Conclusion

Hedera’s vision as a secure, scalable, and decentralized public ledger is compelling, but its current approach to network upgrades and backward compatibility risks alienating the very builders and enterprises it seeks to attract.

A blockchain cannot afford biweekly upgrade and risks attached to it, nor can it contemplate deprecating native services that appnets rely on, especially when smart contracts enjoy immutable guarantees. Developers must be empowered to build once and trust that their work endures—free from the burdens of constant updates, resource drain, and regression risks.

We urge Hedera to adopt a stability-first mindset: reduce upgrade frequency, enshrine native service immutability, and prioritize backward compatibility as a core tenet.

Your initial proposal is a step forward, but it requires significant revision to meet the standards of a professional blockchain ecosystem.
We stand ready to collaborate with the Hedera team and community to refine this strategy, ensuring that Hedera fulfills its potential as the trust layer for the decentralized economy.

---

Sincerely,
Tomachi Anura @ HbarSuite - CTO & Founder

[AshiElSharky]

The issues raised by Tomachi Anura are of serious concern. I am an investor in Hedera because I believe in the enterprise application/utility of this technology. Even if we are open source we need to keep up the high standard that is necessary to win the market. We have a whole eco-system that started to build because of the commitment to high quality and thought leadership by the founders Leemon and Mance. This topic needs full leadership attention. Please!

[takamae1]

It's really disappointing that this keeps happening to this hard working team. These guys have been nothing but transparent with their community always being honest and keeping us updated, I cannot understand why they are deemed 'toxic' at all.
What Tomachi is saying makes complete sense, an enterprise grade network cannot keep changing every few weeks, it's not fair to the builders who need to spend what free time they have fixing the project and dealing with support tickets and cranky investors.
Please, all the team is asking is for some stability, communication and professionalism. We all want what is best for the network and everyone involved with it.

[PossibleTs]

Hello everyone, I'm seeing we're not getting to much interections here. I would like to state the MOST important reccommendations. This is essencial so we could keep bulding in peace.

We're not using SmartContracts for those who don't know. We've been building Dr. Leemon Baird's vioson of dAppnets!

### Recommendation - "Build once, run forever"
Commit to Permanent Stability: Declare HCS, HTS, and HFS as immutable at their current functionality level. Enhancements must be additive, not subtractive.
Adopt Versioning: Introduce new features via versioned APIs (e.g., HTS v2) while preserving v1 indefinitely, mirroring smart contract deployment patterns.
Align with Blockchain Principles: Treat native services as part of the protocol’s immutable core, ensuring parity with smart contracts in permanence and reliability.

@popowycz

[tomachianura]

Comparative Analysis: Risks of Rapid Update Cycles in Blockchain Development - Hedera's Approach vs. Industry Best Practices

Blockchain Update Cadence: A Critical Security Factor

Established blockchains have demonstrated that deliberate, carefully-paced development is essential for network security and stability. Examining update practices across major platforms reveals significant differences in approach:

Update Frequency Comparison

Blockchain	Major Update Frequency	Testing Approach	Deployment Method
Bitcoin	2-3 years	Extensive testnets, multiple implementation reviews	Soft forks requiring miner support
Ethereum	Annually	Multiple testnets, months of public testing	Coordinated validator upgrades after extensive simulation
XRP Ledger	1-2 times yearly	Dedicated testnet, gradual validator adoption	Two-week voting period ensuring consensus
Hedera	Bi-weekly	Limited preview testing	Council-mandated releases regardless of ecosystem readiness

Critical Security Insight: Bitcoin's Taproot update underwent three years of design, testing, and implementation before deployment. Ethereum's Merge required 18+ months of testing across multiple testnets. These deliberate timelines aren't bureaucratic inefficiency—they're essential security measures that Hedera's bi-weekly push schedule fundamentally undermines.

The Inherent Dangers of Accelerated Update Cycles

Bi-weekly Updates: A Fundamental Security Risk

Hedera's accelerated bi-weekly mainnet update schedule introduces profound vulnerabilities:

1. Insufficient Security Validation: Complex cryptographic systems require extensive review periods. Bitcoin Core's deliberate pace isn't accidental—it's necessary for identifying subtle vulnerabilities that can compromise billions in assets. Hedera's compressed timeline makes thorough cryptographic review mathematically impossible.

2. Operational Fragility: Frequent updates significantly increase the risk of node desynchronization and network instability. While XRP Ledger's two-week voting period ensures consensus before implementation, Hedera forces updates regardless of network readiness, creating potential chain split vectors.

3. Inadequate Testing Windows: Bitcoin, Ethereum, and XRP Ledger updates undergo months of public testing before implementation. This extensive testing process has repeatedly identified critical vulnerabilities before deployment. Hedera's rapid cycle structurally prevents this essential security layer.

4. Integration Challenges for Ecosystem Partners: Exchanges, wallets, and applications built on Hedera face significant operational challenges with bi-weekly updates. Most established platforms require weeks to properly test and integrate blockchain updates, making Hedera's pace unsustainable for enterprise applications.

5. Documentation and Education Gaps: Rapid updates create perpetual knowledge gaps as documentation and developer education cannot keep pace with platform changes. This increases the likelihood of implementation errors and security vulnerabilities in applications built on Hedera.

Repository Update Practices: Speed vs. Security

Blockchain	Code Freeze Period	Security Audit Time	Post-Release Monitoring
Bitcoin	Months before release	Multiple independent reviews	Extended monitoring across diverse node implementations
Ethereum	Weeks of stabilization	Multiple client team validations	Phased rollout with automatic fallback mechanisms
XRP Ledger	Two-week amendment voting	Multiple validator confirmation	Gradual adoption with explicit consensus
Hedera	Minimal freeze periods	Limited external review	Rapid deployment with limited fallback options

Quantifiable Metrics: Stability vs. Vulnerability

Historical Resilience Comparison

Blockchain	Years in Operation	Major Version Changes	Regression Incidents
Bitcoin	15+	Carefully-spaced updates with extensive testing	Extremely rare with multiple safeguards
Ethereum	9+	Annual major updates with months of preparation	Managed through extended test phases
XRP Ledger	10+	Conservative amendment process	Validator amendment process prevents regressions
Hedera	5+	26+ updates per year	Higher statistical likelihood with compressed testing

Enterprise Adoption Implications

Update Management Requirements

Enterprise systems typically operate on quarterly or annual update cycles due to:

1. Risk Management Policies: Financial and corporate systems require extensive testing periods to maintain operational stability.

2. Compliance Requirements: Regulated industries require documentation and certification processes that cannot be completed within a two-week window.

3. Change Management Procedures: Enterprise IT requires defined change windows, advance notification, and contingency planning incompatible with rapid update cycles.

Hedera's bi-weekly update approach creates significant friction for enterprise adoption, as organizations must either:

• Skip updates (creating security vulnerabilities)
• Rush integration (increasing operational risk)
• Dedicate disproportionate resources to Hedera integration compared to other systems

Case Studies: Update Failures in Distributed Systems

Ethereum Constantinople Delay (2019)

A critical vulnerability was discovered just 24 hours before scheduled deployment, leading to a last-minute postponement. This incident demonstrates the value of extended review periods that Hedera's update cycle doesn't accommodate.

Solana Outages (2021-2022)

Frequent network updates contributed to multiple outages as validators struggled to maintain synchronization. Despite a slower update cycle than Hedera, Solana's experience highlights the risks of prioritizing rapid development over stability.

Technical Debt Accumulation

Rapid update cycles inevitably lead to accumulated technical debt as:

1. Thorough code refactoring cannot be completed within compressed timeframes
2. Documentation lags behind implementation
3. Testing coverage becomes increasingly incomplete
4. Compatibility layers multiply to support ecosystem partners

Bitcoin, Ethereum and XRP Ledger all periodically allocate extended development cycles specifically to address technical debt—a practice incompatible with Hedera's continuous bi-weekly schedule.

Conclusion: Balancing Innovation and Security

The established blockchain development models have demonstrated remarkable resilience through deliberate, measured evolution. These systems prioritize security and stability over development speed—a necessary trade-off when securing billions in assets.

Hedera's bi-weekly update approach fundamentally misunderstands this essential balance. By adopting software industry-style development cycles for cryptographic infrastructure, it introduces structural vulnerabilities that contradict blockchain's security requirements.

While appearing innovative on the surface, Hedera's accelerated update cadence sacrifices the critical security layers that have made established blockchains resilient. True innovation in blockchain requires not just technical capability but security wisdom—recognizing that proper cryptographic systems must prioritize thorough validation over rapid deployment cycles.

For blockchain technology to achieve its transformative potential, particularly in enterprise applications, it must embrace appropriate update methodologies that balance innovation with the rigorous security demands of distributed financial systems. Hedera's current approach represents a concerning deviation from these essential principles, potentially compromising both security and long-term adoption potential.

[tomachianura]

it's been more than a week now, with ZERO interaction from Hiero and Hedera.
Ed Marquez provided an answer to us in issues/2930, telling us he created a Discord channel specifically to keep discussing the topics in this thread.

for those interested, the channel is inside Hedera's discord #features-request-desk

the main problem is that not only we got ZERO answers on this thread, but also on the discord one.
Ed wrote one single message in 2 days, yet without answering all the questions and the concerns expressed.

Once again, we at HbarSuite and we as Hedera community are totally lost in the unclear and undefined procedures you ask us to follow, bringing us nowhere else, always moving in circles.

I'm writing here on GitHub to keep everyone posted, including those ones which are NOT memeber of the Hedera discord, to let everyone know this convo is NOT dead, yet is NOT being properly addressed either.

We will never give up, until the moment Hiero and/or Hedera clarify their position and their intetions toward this public ledger.
We are their investors, it's our money in there, and we all deserve to know why they're taking down this approach and why they keep moving us from discord to github, from github to discord, without any concrete action nor resolution.

[AshiElSharky]

Dear Richard, thank you for finally replying. I am a community member of HbarSuite. I hope you can understand the pressure and frustration that we experience. The team has enterprise customers and we went down for a full week because of this mistake.

What is really confusing about all this is that it is not clear to us who has the hat on and how does this process look like. Ed has invited us to a Discord channel where as far as I know you are not included. And here you are trying to address our issue.

We are confused and we do not know with whom we are supposed to talk and who can drive home our points and how a binding decision can be reached.

Here is the Discord link:
https://discord.com/channels/373889138199494658/1354571561385853235

[rbair23]

Hi @AshiElSharky,

Hedera's donation of code to the Linux Foundation late last year changes the way things work, so confusion is very understandable. The executive summary is: we took decentralization seriously and there are groups of people who contribute to all phases of the decision making. This isn't a centralized system with one decision maker. To contribute to code, Hiero is the place. To discuss the Hedera hosted networks, Hedera is the place.

The Long Answer

The source code (consensus node, mirror node, SDKs, relay node, mirror node explorer, HIPs, etc) are all owned by the Linux Foundation, and the development of these projects is governed by open source principles, and conversations and collaborations on that code are based on the Linux Foundation's Code of Conduct.

The Technical Steering Committee is a vendor neutral committee responsible for approving HIPs and govern the open source development. The charter defines the different members of this committee, their roles, etc. It was designed to give community members a say in the design and development of the network code.

Hedera hosts and governs a deployment of this code. Mainnet, testnet, etc are Hedera networks, not governed by Hiero. Hedera decides on the release cadence to testnet and mainnet, the set of networks they support, and so forth. Hedera sets the fees. They decide how to configure the Hiero code.

Hedera is not responsible for the SDKs. These are on the periphery of the network. Hiero is happy to host many SDK implementations. And this is a really important point. These are normal open source projects -- they are vendor neutral and all licensed Apache-2.0 -- extremely permissive. Fork, modify, contribute, repurpose -- everything is allowed.

Hiero is like the CNCF -- it is a house for many collaborating sub-projects.

Tomachi has brought up a number of issues:

1. Breaking change process -- This is definitely a Hiero issue. Technically each project can have its own compatibility policies, but I think the Hiero TSC should review and adopt a general policy that all the projects can also adopt.
2. Frequent network upgrades -- This is a Hedera issue. It actually doesn't belong here in a Hiero thread, and that discord thread might be a better place. I know Ed is working on a blog post so Hedera can detail what the strategy is.
3. Immutability of native services (write once run forever) -- This is primarily a Hiero issue (because it has to do with code ownership).

For Hiero issues, I am a member of the Hiero TSC but I'm not the entire TSC, so I cannot speak for the project. I am very sympathetic to the argument Tomachi makes. Even when we had to fix a flaw in the security model for smart contracts in 2023, we didn't break older contracts, we grandfathered them in. We take compatibility on the mainnet extremely seriously. I would expect the Hiero TSC to maintain that same posture. But neither Ed nor I can speak authoritatively for the TSC.

This is why I like to emphasize that our meetings are open and there are elections and electors and ways to participate. We really did create an organization that gives the community a real and significant voice. And this is not all that common -- most open source projects are governed solely by the maintainers, but for Hiero, we set it up to be predominantly governed by maintainers (because open source is a meritocracy) but we also reserved seats on the TSC to be elected by contributors (not just maintainers!) and by end users (not even contributors!).

I hope that helps clear it up!

[AshiElSharky]

Dear Richard,
thank you for the clarification. We are currently trying to set up a call with Ed I would really appreciate it if you could join us in this call. I think it would be of great benefit. I have tagged you in the discord channel.

[PossibleTs]

Thanks for the inputs, but I'm still confuse.
Please confirm my understanding:

1. As you previouslly mentioned, the update frequency is a Hedera decision, but not what will be updated. Right?
2. If Hiero decided to break some compatibility, even then, the code will be updated. Right?
3. To guratee fundational principles, we need to engage with the TSC every meetings and Hiero repositories to try to avoid any break to happen. Right?
4. SDKs are completely Open Source Projects, only supervised by the Hiero community.
5. In this context, Hedera is only responsible to gurantee the Nodes Uptime, but not how the Network will behave. Right?

And believe me, I'm not trying to criticize the model or judge the Board decision, but I do need to understand the process and risks to decide what to do. Stay or move. My company can't rely and sign SLA contracts without know all the risk and how we can mitigate them.

[gregscullard]

Hi @PossibleTs, please find some answers to your questions below.

1. As you previouslly mentioned, the update frequency is a Hedera decision, but not what will be updated. Right?

It is indeed a Hedera decision, Hedera chooses if and when to deploy a release. It is also able to choose which features within a given release are to be deployed or not, feature flags exist such that not all features in a given releases are necessarily deployed on mainnet. We often use this to enable a feature on testnet which still requires testing, while not enabling it on mainnet until sufficient testing has happened.
Given Hiero's and its TSC independence, it is entirely possible that a feature that's desirable to Hiero and its community is something that would not be acceptable to Hedera, in that case Hedera can choose not to enable the feature.

2. If Hiero decided to break some compatibility, even then, the code will be updated. Right?

Per (1), Hedera can choose not to deploy a breaking change that has been introduced.

3. To guratee fundational principles, we need to engage with the TSC every meetings and Hiero repositories to try to avoid any break to happen. Right?

The community is indeed encouraged to participate in the open source development of Hiero, not only contributing code, but also participating in meetings.

4. SDKs are completely Open Source Projects, only supervised by the Hiero community.

Correct

5. In this context, Hedera is only responsible to gurantee the Nodes Uptime, but not how the Network will behave. Right?

Not strictly true, see (1) and (2).

[tomachianura]

Dear Richard,
Thank you for your thoughtful response and sharing your experience with Java platform development.

Enterprise software and blockchain platforms operate under fundamentally different paradigms. While enterprise software benefits from rapid iteration to fix bugs and add features, blockchain networks serve as immutable trust layers where stability and predictability are paramount. The financial consequences of blockchain changes are immediate and irreversible, unlike traditional software where patches can resolve issues.

The assertion that long release cycles don't achieve stability directly contradicts established blockchain industry practice. Bitcoin, Ethereum, and XRP Ledger all employ extended testing periods (6-24 months) precisely because this approach has proven essential for security and stability. Their deliberate pace isn't inefficient—it's a critical security measure for platforms securing billions in assets. So most probably what your personal experience is, doesn't truly match what a blockchain should be.

Not to mention that bi-weekly updates will surely mine the integrity and the security of the entire network.
And not to mention either that the simply fact you contemplate deprecation / removal / deletion of native features/methods implies that appnets can never be build-once-run-forever and must always keep re-engineering and re-deploying every time you guys decide to deprecate something or to change the behaviour of the native features. This is not only deeply wrong, but once again this is a suicidal move to put in place, the best way to kill every appnet and to make every native-building to run far away from Hedera.

Regarding responsibility for mistakes, accountability must extend beyond acknowledgment to concrete action. When breaking changes occur, developers incur real costs in time, resources, and potentially lost revenue. The fact that you believe apologies are enough when potentially causing millions of dollar of damages makes all of us wonder about the integrity of Hedera and the real intents behind this attitude.

The most successful blockchains maintain strict immutability guarantees. Once deployed, smart contracts remain functional indefinitely, and native APIs preserve backward compatibility permanently. This "build once, run forever" principle is fundamental to blockchain's value proposition, and MUST be appliable both for contracts and for appnets. As long as you don't put this paradigm in place, there will be a very clear and undeniable act of favouritism towards smart-contracts on Hedera, and a deliberate and intentional approach to suppress all appnets and native builders by taking off them the only thing we all required: IMMUTABILITY.

I appreciate the invitation to TSC meetings and will do my best to participate, accordingly to my agenda. However, transparency extends beyond access to meetings—it requires formally documented policies on immutability, deprecation, and breaking changes that enterprises can confidently build upon.

Respectfully,
Tomachi