The TRON Account Model: Permissions, Multi-Sig, and What Investigators Should Know

TRON’s multi-signature system is not a smart contract bolted on top of the protocol. It is the protocol. Every TRON account has a built-in permission structure with configurable keys, weights, and thresholds — regardless of whether the owner ever touches those settings. The key that sends a transaction may not be the key with full control of the account. A wallet’s original funder may have been locked out through a permission rotation. Understanding the permission model is not an edge case — it is a prerequisite for accurate attribution on TRON.

What’s different about TRON accounts

TRON accounts look superficially similar to Ethereum accounts. Both are identified by a 20-byte address derived from a public key. Both can hold native tokens and interact with smart contracts. Both have a transaction history visible on a block explorer.

The differences start with how an account comes into existence. On Ethereum, sending any amount of ETH to an address makes it “exist” in the ledger — nothing else is required, and the cost comes from the gas the sender already pays. On TRON, a new address is not recognized by the network until it has been explicitly activated. The activation event carries a specific cost (currently 1 TRX, deducted from the activating account), and it creates an on-chain record of the moment and the party responsible.

The standard activation path is an EOA-initiated transaction: an existing account transfers TRX or a TRC-10 token to the new address, and if the target is not yet active, the network simultaneously activates it. There is also a distinct transaction type, AccountCreateContract, which creates an account explicitly without a simultaneous transfer. (Smart contracts can incidentally activate accounts by transferring TRX or TRC-10 to an inactive address, but that path consumes 25,000 Energy instead of the 1 TRX activation fee, and it is not an AccountCreateContract transaction — it is a side effect of the transfer.) In the common case, the activation event is attributable to a real external account: someone made a decision to activate that specific address.

The more consequential difference is the permission model. Ethereum wallets have one private key. Multi-signature on Ethereum requires deploying a smart contract — a custom program that holds funds and requires multiple approvers. On TRON, multi-signature is a first-class feature of every account, implemented at the protocol level.

Owner permission vs Active permission

When a TRON account is created, the network initializes two permission groups on the account automatically.

Owner permission is the master permission. It can execute any transaction type on the account — transfers, staking, contract calls, voting, and critically, changes to the account’s own permission structure. If you hold Owner permission, you hold complete control. Whoever holds Owner permission can add or remove keys, change thresholds, and grant or revoke Active permissions. It is the root of the account’s authority tree.

By default, the Owner permission has one key — the account’s own address — with weight 1 and threshold 1. That is the minimum single-signer configuration, and it is what most freshly activated wallets look like.

Active permissions are scoped, delegated permissions. Each Active permission is defined by:

• An operations field: a 32-byte bitmask (represented in block explorers as hex) where each bit corresponds to a TRON contract type. Setting a bit to 1 means this Active permission can execute that contract type. Typical configurations include everything except AccountPermissionUpdateContract — preventing an Active-permission holder from changing the account’s own permissions.
• A list of keys, each with an assigned weight.
• A threshold the total signing weight must reach for the permission to authorize a transaction.

An account can hold up to eight Active permissions, each with its own operation set. This allows multi-tier delegation: one Active permission for day-to-day transfers, another for staking operations, another for specific contract interactions — each with its own signers and quorum requirements.

The separation between Owner and Active is the most investigatively important aspect of this model. Knowing that a particular address is a signer on an Active permission tells you that address can execute the Active permission’s allowed operations — but it tells you nothing about who holds Owner permission, and therefore nothing about who can ultimately reconfigure or seize the account. Ownership investigation must always start with Owner permission.

Threshold signatures

Each permission group — Owner and each Active — uses the same signature mechanics: a list of keys, each key with a weight, and a threshold.

A transaction signed under that permission is valid when the combined weight of all provided signatures meets or exceeds the threshold. The network does not care how many keys sign, only whether the weight sum is sufficient.

Three common configurations illustrate the range:

2-of-3 multi-sig: Three keys, each with weight 1, threshold set to 2. Any two of the three keys can authorize a transaction. One alone cannot.

Single-signer default: One key, weight 1, threshold 1. Every account starts here. The single key’s signature meets the threshold, and the account behaves like a standard externally-owned account.

High-threshold lockout: Threshold set higher than the sum of all key weights. No combination of current keys can authorize — useful as a deliberate freeze, and detectable via the API.

Keys in a permission group are TRON addresses, not raw public keys. Each address represents a key-holder who can sign on behalf of the account. There is no requirement that the key-holder address itself be active or funded — only that its private key can produce a valid signature. Up to 5 keys per permission group are supported.

Permission updates on-chain

The transaction type that modifies an account’s permission structure is AccountPermissionUpdateContract. It carries a protocol-level fee of 100 TRX (a governance parameter that can be changed by SR vote, but has not been). If the resulting transaction requires multiple signatures because the current Owner permission already requires a quorum, an additional 1 TRX multi-signature fee applies.

AccountPermissionUpdateContract is an all-or-nothing operation: the transaction must specify the complete desired state of all permissions simultaneously. You cannot update only the Owner permission and leave Active permissions unchanged — if Active permissions exist and are not included in the update transaction, they are removed. This means a permission update transaction in a wallet’s history contains the full picture of the account’s new permission configuration.

What an AccountPermissionUpdateContract transaction looks like on Tronscan:

• Transaction type listed as AccountPermissionUpdate.
• The transaction detail shows the new Owner permission (keys and threshold) and any Active permissions being set.
• The from address is the address that broadcast and paid for the transaction — not necessarily the address whose permissions are being updated (another account with Owner permission could have signed it).
• The 100 TRX fee is deducted from the account paying transaction costs (usually the account being updated, but not required to be).

TRONORIGIN may apply a PERMISSION_UPDATER tag to an address in its analysis when it detects AccountPermissionUpdateContract transactions affecting a wallet. This tag signals that permission rotation has occurred — a meaningful event in the history of control over that account.

Why this matters for attribution

The permission model creates a gap between the addresses that appear in a wallet’s transaction history and the addresses that actually control it.

Consider a wallet that was activated in 2022 by an exchange hot wallet and has since received transfers from two personal addresses. In a naive analysis, those three addresses are the candidates for ownership. But if the wallet’s Owner permission was updated in 2023 — adding two new keys and setting a 2-of-2 threshold — then the original activation source and the personal funding addresses are irrelevant to current control. Control today belongs to whoever holds those two new keys.

Permission rotation is one of the clearest signals of a deliberate transfer of control. Unlike a simple outbound transfer, which could represent a payment, a rotation of the Owner permission keys is an administrative act. Someone with existing Owner access decided to change who can control the account. This can represent a legitimate ownership transfer (an account sold or handed off), a security measure (old keys deprecated after a device compromise), or a hostile takeover (an attacker who obtained temporary Owner access replacing all keys before being locked out).

The timing relationship matters. A permission rotation that precedes a large outbound transfer is a different signal than one that follows a dormant period. A rotation that adds a key associated with a known exchange or custodian may indicate a formal custody arrangement. A rotation that removes all original keys and replaces them with unfamiliar addresses is the highest-priority signal that control has changed hands.

TRONORIGIN’s three-phase scoring weights this accordingly. Phase 3 (current control, weighted at 50% of the confidence score) examines the most recent observable state of who is operating a wallet — and permission state is a direct input into that analysis. A wallet where Phase 1 (activation) and Phase 3 (current control) point to the same set of addresses has a clear story. A wallet where they diverge, especially with a permission rotation visible in between, has a more complicated one. See /how-it-works/ for the full scoring methodology, and /learn/tron-history/ for the background on why TRON’s structure creates these attribution challenges in the first place.

Reading permission state on-chain

There are two primary ways to inspect a TRON account’s current permission state.

Via Tronscan: Navigate to the account page. In the account detail view, look for the “Permissions” section or tab (the exact layout varies with Tronscan UI versions; as of 2026 it appears under the account detail section). Tronscan shows the Owner permission’s keys and threshold, and lists each Active permission with its id, name, threshold, keys, and operations scope. This is the fastest way to check whether an account is using the default single-signer configuration or has been configured for multi-sig.

Via the wallet/getaccount API: POST /wallet/getaccount returns the full account object. The owner_permission field contains the threshold and a keys array (each key has an address in hex and a weight). The active_permission field is an array of Active permission objects, each including a threshold, keys, and an operations hex bitmask. A fresh account with default settings has one key (the account’s own address), weight 1, threshold 1 in both Owner and the single Active permission. If witness_permission is present, the account is a registered SR candidate.

What to look for when reviewing permission state:

• Number of keys per permission. More than one key in Owner means coordinated signing is required for full control. Multiple keys in Active means routine operations are shared.
• Unfamiliar addresses in key lists. Owner keys absent from the transaction history signal control through a channel not visible in the transaction graph.
• Threshold relative to total achievable weight. If the threshold equals the sum of all key weights, all signers must agree. If lower, a quorum suffices and some key-holders can be locked out.
• Recency of the last AccountPermissionUpdateContract. Current state from wallet/getaccount shows who holds control now; the transaction history shows when control changed.

Common patterns

Exchange custody wallets. Large exchange custody wallets typically use a split model: the hot wallet (from which user withdrawals originate) runs single-key Owner permission because it needs to process transactions rapidly and at high volume. The cold storage or settlement wallet typically uses a multi-sig Owner permission with a high threshold — often 3-of-5 or similar — requiring coordinated signatures from hardware security modules that are geographically distributed. Finding an exchange-annotated hot wallet address in an Active permission key list is unusual and worth investigating.

DAO and protocol multisigs. Governance-controlled treasuries set Owner permission to high-quorum multi-key configurations (4-of-7, 5-of-9). These accounts often have no Active permissions — all operations require Owner-level approval. Key addresses frequently correspond to known governance participants.

Personal hardware wallet rotation. An account originally controlled by a software wallet key rotates Owner permission to a hardware wallet key, then optionally adds the old software key back as a lower-weight Active permission for convenience. The rotation is visible on-chain; the new Owner key is the hardware wallet address.

The “compromise” pattern. An account has stable permission state for months or years. Then an AccountPermissionUpdateContract appears — adding unfamiliar keys or replacing existing ones — followed shortly by large outbound transfers. The new keys have no prior history on the account. This is the on-chain signature of a hostile takeover: an attacker obtained temporary signing capability, rotated permissions, and extracted value. The timestamp of the AccountPermissionUpdateContract is the earliest moment of attacker control.

Sources

Primary and authoritative sources used for the facts in this article:

• TRON Developer Hub. “Account Permission Management” — Permission type IDs (Owner = 0, Witness = 1, Active starting from 2), AccountPermissionUpdateContract transaction type, 100 TRX update fee, up to 8 Active permissions per account, up to 5 keys per permission, all-or-nothing update semantics, operations field bitmask interpretation, additional 1 TRX multi-sig transaction fee.
• TRON Protocol documentation (java-tron). “Account Permission Management — Multi-Signatures” — Threshold and weight mechanics, default permission structure (threshold 1, single key at weight 1), signing authorization rules (sum of weights ≥ threshold).
• TRON Developer Hub. “AccountPermissionUpdate API reference” — Request and response fields for the wallet/updateaccountpermission endpoint and AccountPermissionUpdateContract parameter structure.
• TRON Developer Hub. “GetAccount API reference” — wallet/getaccount endpoint, permission fields in the response (owner_permission, active_permission, witness_permission), key and weight field names.
• TRON Developer Hub. “Accounts” — Account activation mechanics, 1 TRX activation fee, AccountCreateContract transaction type, smart-contract-triggered activation and its 25,000 Energy cost.
• TRON Developer Hub. “Supported Transaction Types in Detail” — AccountCreateContract (type 0) and AccountPermissionUpdateContract (type 46) system contract type IDs.
• GitHub: tronprotocol/tips. “TIP-16: Account Permission Management” — The foundational TIP specifying the multi-signature permission model, operations 32-byte bitmask encoding (little-endian byte order, big-endian bit order within each byte), and the original design rationale.
• GitHub: tronprotocol/tips. “TIP-105: Multi-signature Permission Operation” — Refinements to the operations permission model.
• TRON Developer Hub. “Multi-Signature Example Process Flow” — Step-by-step walkthrough of permission setup and multi-sig transaction construction, illustrating the full signing lifecycle.
• TRONSCAN Support Center. “How to set up a TRON multisig account” — UI walkthrough for the Tronscan permission tab and multisig configuration interface.
• TRON Protocol documentation (java-tron). “Account Model” — Account types, activation requirements, default state of newly created accounts.