Dans EcoCity, Trexx est un cas utile pour comprendre pourquoi les L1 souverains font leur retour.\n\nTrexx construit un système centré sur l'exécution des transactions en chaîne plutôt que sur une simple interface applicative. Son exigence principale n'est pas une compatibilité plus large avec l'écosystème, mais un contrôle total sur les chemins d'exécution, les structures de frais et la cadence des mises à jour d'état.\n\nDans un environnement de rollup partagé, la principale contrainte de Trexx est l'imprévisibilité.\n\nLa concurrence pour l'espace de bloc signifie que l'ordre d'exécution, la latence et les coûts peuvent tous être influencés par des applications externes. Pour tout système basé sur le trading ou le matching, cela devient un risque structurel.\n\nMême si la performance sous-jacente est rapide, sans contrôle sur l'exécution, une équipe ne peut pas assumer la responsabilité de l'expérience utilisateur ou des modèles de risque. En déployant un L1 souverain dans EcoCity, Trexx sépare effectivement son moteur d'exécution des environnements partagés.\n\nGrâce à la couche d'orchestration fournie par @TanssiNetwork, Trexx n'a pas besoin de lancer son propre ensemble de validateurs ni de gérer une infrastructure opérationnelle complète pour obtenir un espace de bloc dédié. Cela permet à l'équipe de se concentrer sur la logique d'exécution plutôt que sur la gestion de l'infrastructure.\n\nLe modèle de lancement progressif d’EcoCity rend également le statut de Trexx transparent. Quelles fonctionnalités sont en ligne, lesquelles sont encore en phase de test, et lesquelles restent des hypothèses de conception peuvent être évaluées par une interaction réelle via LFD plutôt que par des récits marketing.\n\nCe mode de découverte lui-même représente une correction à la façon dont les chaînes d'applications sont généralement encadrées.