# X-Post - TEE service governance and provisioning framework

**URL:** https://collective.flashbots.net/t/x-post-tee-service-governance-and-provisioning-framework/5016
**Category:** BuilderNet
**Created:** [June 18, 2025, 2:23pm UTC](https://collective.flashbots.net/t/x-post-tee-service-governance-and-provisioning-framework/5016 "2025-06-18T14:23:33Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![metachris](https://collective.flashbots.net/user_avatar/collective.flashbots.net/metachris/32/6_2.png) [@metachris](https://collective.flashbots.net/u/metachris)
#### Post date: [June 18, 2025, 2:23pm UTC](https://collective.flashbots.net/t/x-post-tee-service-governance-and-provisioning-framework/5016/1 "2025-06-18T14:23:33Z")

</div>

I wanted to highlight this important design document, which @mateusz just posted in the TEE category:

> [@TEE service governance and provisioning framework](https://collective.flashbots.net/t/tee-service-governance-and-provisioning-framework/4995):
>
> Creating a decentralized service comes with some non-trivial choices and tradeoffs. This post intends to show a perspective on the topic of provisioning decentralized services. Application Governance: who decides what about the application? Who, and how, controls the release cycle for the application? Who controls configurations, allowed operators? Configuration Availability: how, and where from, are instances of an application receiving their configuration and secrets? How does availability o…

It proposes an architecture, with reference implementation, for translating governance decisions into discrete TEE application updates; in particular regarding provisioning of resources and distribution of secrets.

We are considering adopting this approach for BuilderNet. It provides a number of interesting benefits:

1. Reduce dependency on Flashbots and centralized infrastructure
2. Increase transparency: complete on-chain audit trail of all changes and system states.
3. Possibly replace BuilderHub: secrets and configuration is distributed using decentralized DA storage. Governance can delegate authority to create/update secrets, and other system decisions like builder node allowlists, etc.
4. Simplified trust model using a TEE-based TLS root certificate authority: users can verify it’s TEE proof to trust the root CA, and the trust chain can extend to all certificates signed by it (instead of needing to TEE-verify each instance certificate individually).

Please take a look at the post and chime in with your thoughts!

* * *

References:

- [TEE service governance and provisioning framework](https://collective.flashbots.net/t/tee-service-governance-and-provisioning-framework/4995)
- [GitHub - Ruteri/tee-service-provisioning-backend](https://github.com/Ruteri/tee-service-provisioning-backend)
- [tee-service-provisioning-backend module - github.com/ruteri/tee-service-provisioning-backend - Go Packages](https://pkg.go.dev/github.com/ruteri/tee-service-provisioning-backend@v0.0.2-0.20250520110437-88acfcac462f#section-readme)