MIMD-014: Permission Program & Privacy Improvements via TEE

[jonasXchen]

MIMD-014: Permission Program & Privacy Improvements via TEE

Summary

This MIMD proposes a set of breaking changes and design considerations to improve the MagicBlock Permission Program and privacy guarantees when used with Trusted Execution Environments (TEE). The proposals are based on direct user feedback and aim to strengthen security, improve privacy semantics, clarify naming, and ensure sufficient flexibility for legal and regulatory compliance, while acknowledging trade-offs in developer experience, tooling, and observability.

---

Motivation

Users adopting MagicBlock for privacy-sensitive use cases (private state, private payments, hidden execution) have raised concerns around:

• Authentication material exposure
• Transaction-level data leakage
• Ambiguous account naming that does not reflect permission semantics
• Lack of clarity around compliance and selective disclosure requirements

As MagicBlock positions the Permission Program as a privacy-enabling primitive when combined with TEE execution, these issues must be addressed at the protocol and API level — even if this requires breaking changes.

---

Proposed Changes

1. Authentication Token Handling

Type: 🟡 Backward-Compatible Change

Current state:

• authToken is passed via URL query parameters.

Issues:

• URLs may be logged by proxies, load balancers, browsers, and server logs
• Increased risk of credential leakage

Proposed change:

• Expand authToken to HTTP headers
• Suggested format:

  Authorization: Bearer <auth_token>
  

Impact:

• Backwards compatibility enabling explorers to utilize url based token
• Require client and SDK updates for header implementation
• Aligns with security best practices

---

2. Transaction Visibility & Privacy Guarantees

Type: 🔴 Breaking Change

Current state:

• Transactions are publicly discoverable via signature
• Observers can access pre-balances, post-balances, and execution metadata

Issue:

• Sensitive execution and balance information leaks publicly
• Conflicts with privacy expectations for TEE-based execution

Proposed change (directional):

• Transaction are visible exclusively to the signer
• No transaction balances are accessible
• Non-signer can only see whether transaction is successful or not

Suggestion to remove (https://solana.com/docs/rpc/http/gettransaction):

• result.meta.postBalances
• result.meta.preBalances
• result.meta.postTokenBalances
• result.meta.preTokenBalances

Trade-offs:

• Transactions not renderable by standard explorers
• Reduced public observability
• Requires new tooling for private transaction inspection

Design note:

• Disclosure levels should be configurable to support compliance and auditing requirements

---

3. Account Naming Semantics

Type: 🔴 Breaking Change

Current naming:

• delegated_account

Issue:

• Does not clearly express permissioned or privacy-aware semantics

Proposed rename:

• permissioned_account

Impact:

• Changes across programs, SDKs, documentation, and integrations

---

4. Permission Visibility & Closure Semantics

Type: 🔴 Breaking Change

Current state:

• Permission accounts are represented by a PDA with the following structure:

  pub struct Permission {
      pub discriminator: u8,
      pub bump: u8,
      pub account: Pubkey,
      pub group: Pubkey,
  }

• All permissions are treated uniformly in terms of visibility and lifecycle.

Issues:

• No explicit distinction between public and private permissions
• Limitation on closing permission acocunt on Ephemeral Rollup

Proposed Change: Optional group as Visibility Signal

• group == Pubkey::default() → Public permission
• group != Pubkey::default() → Private permission
  • If group has members → visible only to members
  • If group has no members → visible to no one

Impact:

• Changes across programs, SDKs, documentation, and integrations

[Dodecahedr0x]

Quick feedbacks:

1. AFAIK, changing token auth from query to header param is a breaking change in web3.js but should be fine with kit. Also, I don't know how it will be usable with the explorer because you will no longer be able to provide the custom URL with the token to see private data
2. I would prefer Option<Pubkey> where None means public, and Some(Pubkey::default()) means accessible to no one. This makes it clear that if there is a value, it is private, and would remove the need to create redundant empty groups to make an account fully private