# Super User Account

**URL:** <https://forum.flow.com/t/super-user-account/4088>\
**Category:** 🏄🏻‍♀️ Cadence\
**Tags:** cadence, account-model\
**Created:** [January 20, 2023, 4:39pm UTC](https://forum.flow.com/t/super-user-account/4088 "2023-01-20T16:39:57Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [February 7, 2023, 6:50pm UTC](https://forum.flow.com/t/super-user-account/4088/15 "2023-02-07T18:50:41Z")

</div>

While thinking through how entitlements for accounts could look like it occurred to me that we do not even need the distinction between `AuthAccount` and `PublicAccount` anymore.

Here is an example of how a refactoring a part of the account type could look like:

```auto
struct interface ContractAdmin {

    auth(ContractAdmin) let contractAdmin: auth &Account.Contracts
}

// ... other entitlement interfaces granting access to keys, capabilities, etc.

struct Account: ContractAdmin {

    let address: Address

    // ... other fields, functions, and types

    let contracts: &Account.Contracts

    auth(ContractAdmin) let contractAdmin: auth &Account.Contracts

    struct Contracts {

        fun get(name: String): DeployedContract?

        auth fun update__experimental(name: String, code: [UInt8]): DeployedContract

        // ... other fields and functions
    }
}

```

- We would only have one type `Account`
- Previous uses of `PublicAccount` would become `&Account`. Note that the reference is non-`auth`, meaning that informational fields like `address`, but also fields like `contracts` could be accessed and would allow “read-only operations”.
- Previous uses of `AuthAccount` would become `auth &Account`, effectively granting access to all `auth` fields
- A signer type `auth(ContractAdmin) &Account` would only allow access to managing contracts, but not to e.g. managing keys
- One small downside is that we would need to expose two fields for each nested reference, one non-`auth` and one `auth`, e.g. `contracts` and `contractAdmin`
- (Note that naming is just strawman syntax, suggestions welcome)

@sainati Did I apply [https://github.com/onflow/flips/pull/54](https://github.com/onflow/flips/pull/54) here correctly?

---

_[View the full topic](https://forum.flow.com/t/super-user-account/4088)._