Tron account permissions: multisig, active keys, and locking down an account

Most people treat a Tron account as one address with one private key: hold the key, you hold the funds; lose the key, lose everything. That's the default, but it's not the limit. Every Tron account has a built-in permission system — the same machinery exchanges and projects use for multisig treasuries — and it lets you do things a single key can't: require multiple signers, separate a cold "owner" key from a restricted day-to-day key, and hand a hot wallet exactly one capability and nothing else.

It's also the feature most directly relevant to not losing your money. If you read how address poisoning works, that's the attacker's side; permissions are the defender's. Here's the whole model.

Three kinds of permission

Every account has up to three categories of permission, each identified by a fixed id:

Owner (id 0) — the root authority. It can do everything, including rewriting every other permission on the account. By default it's just your one key. This is the permission you protect above all else.
Active (id 2 and up) — day-to-day operating permissions. An account can have up to 8 of them, and each one can be scoped to only certain operations. This is where multisig and restricted hot keys live.
Witness (id 1) — exists only on Super Representative accounts. It's the key used to sign blocks, kept separate so an SR's block-producing key isn't its treasury key.

What a permission is actually made of

A permission isn't a single key — it's a small policy. Each one carries:

A list of keys, up to 5, each an address paired with a weight.
A threshold — the total weight that must sign before an operation is authorized. A transaction is valid when the weights of the keys that signed it sum to at least the threshold.
An operations bitmap (active permissions only) — 32 bytes, one bit per Tron contract type. A set bit means "this permission may invoke that operation." An active permission with only the TransferContract bit set can move TRX and nothing else: it can't vote, stake, deploy a contract, or touch permissions.

Those three knobs — keys, weights, threshold — are the entire vocabulary. Everything below is just a way of setting them.

Multisig, by example

The classic case is M-of-N. Put three keys on an active permission, each with weight 1, and set the threshold to 2:

active permission "treasury"
  keys:       keyA (weight 1), keyB (weight 1), keyC (weight 1)
  threshold:  2

  keyA + keyB        → weight 2 ≥ 2  ✓ authorized
  keyC alone         → weight 1 < 2  ✗ rejected

That's a 2-of-3 wallet: any two of the three signers can move funds, no one alone can. Weights make it more expressive than plain M-of-N. Give a founder key weight 2 and two ops keys weight 1 each, with threshold 2:

  founder (weight 2)             → 2 ≥ 2  ✓ can act alone
  ops1 (weight 1) alone          → 1 < 2  ✗
  ops1 + ops2 (1 + 1)            → 2 ≥ 2  ✓ two of them together

Now the founder is autonomous, while either ops person needs a co-signer. The same building blocks express "2-of-3," "any director plus the CFO," or "3 of these 5, but the security team's key counts double" — all by choosing weights and a threshold.

The pattern that matters: a cold owner, a limited active key

Here's the configuration worth understanding even if you never run a multisig. The owner permission can rewrite any active permission — including swapping out its keys. So:

Keep the owner key cold and untouched. Operate from an active key that's restricted to only the operations you actually use day to day.

If that active key gets phished, or the device it lives on is compromised, you haven't lost the account. You bring the cold owner key out once, rotate the active permission to a fresh key, and the attacker's key is revoked. Your funds never moved. Compare that to a single-key account, where a leaked key is total, immediate, and irreversible loss — there is no second line.

You can go further with the operations bitmap. Running an auto-voting setup? Give the bot an active key that can only call VoteWitnessContract — if it's compromised, the attacker can change your votes and not one TRX can leave the account. Least privilege, enforced by the protocol rather than by trust.

Witness permission: the SR special case

Super Representatives produce a block every time the 3-second rotation lands on them, and each block has to be signed. That signing key is the witness permission. Splitting it out means the key sitting on a hot, always-online block-producing node is not the key that controls the SR's staked TRX and rewards. If the node is breached, the attacker can sign blocks (and get the SR slashed in reputation) but can't drain the account. For anyone running validator infrastructure, this separation isn't optional hygiene — it's the difference between an incident and a catastrophe. You can see the active SR set on the validators page.

What it costs

Permissions aren't free to change, by design — a flat fee keeps the operation deliberate and spam-resistant:

Updating permissions (AccountPermissionUpdateContract) costs 100 TRX by default. It's a governance-set chain parameter (getUpdateAccountPermissionFee), so the exact number can move via SR proposal, but 100 TRX has been the standing value for years.
Each extra signature on a multisig transaction adds a small multi-sign fee — about 1 TRX by default — on top of the normal bandwidth cost. Budget for it if you're signing high volumes.

The footgun: you can brick your own account

The same power that locks attackers out can lock you out, permanently. The owner permission enforces whatever rule you give it, including a rule you can no longer satisfy:

Set an owner threshold of 2 but only control one of the listed keys → permanently locked.
Point the owner permission at an address whose key you later lose → no recovery.
Fat-finger the operations bitmap and remove your only path to move funds → stuck.

There is no support line, no override, no reset. Tron will faithfully enforce the configuration you signed. The rules are simple and non-negotiable: test on a throwaway account first, keep the owner permission as simple as you can justify, and never set a threshold higher than the number of keys you can reliably sign with. Verify you can still produce a valid signature before you move real value onto the account.

Reading it on the explorer

A permission change is itself an on-chain event. On the explorer it shows up in an account's history as an AccountPermissionUpdateContract — classified under the Account transaction type. That's the one event to look for when you audit an account, your own or anyone else's:

A permission update is the only thing that can change who controls an account's funds without moving them. If you're vetting a treasury or a counterparty, that's the event that tells you control changed hands.

Browse any account's activity from the live transfer feed or its address page, and a permission change is right there in the log next to the ordinary transfers — quiet, but the most consequential line in the history.

The bottom line

A single key is the floor of Tron's account model, not the ceiling. The permission system turns "one key, all or nothing" into something you can shape: multiple signers for a shared treasury, a cold owner key that can revoke a compromised hot key, an operation-scoped key that can vote but never spend. None of it requires a smart contract — it's native to every account, waiting in the protocol. The cost of using it is a 100 TRX fee and the discipline to test before you trust. The cost of not using it is that a single leaked key is still the end of the story.