TRON Operations Bitmap: Decode an Active Permission

A TRON operations bitmap records which system contract type IDs are enabled for one Active permission. Decode the 32 bytes in their original order, then inspect each byte from its least significant bit. Keep the selected permission’s keys and threshold alongside the decoded types: a set bit alone does not prove that a person can authorize a transaction.

This tutorial is for readers who have an account response containing a long operations value and need a reproducible interpretation. It includes a real dated Mainnet response, an offline decoder, 22 local tests and a byte-position worksheet. The Tronscan News homepage collects our independent English guides. Nothing below signs a transaction or changes account permissions.

1. Select the Active entry before decoding

Open the public account record on the intended network, preserve its full address and identify the specific Active permission ID. Do not choose an entry because its display name sounds restrictive. A name is a label; the decoder needs the exact entry and original bytes. The account-permission interpretation guide explains the surrounding Owner, Active and threshold model.

The official permission documentation defines the operations bitmap as 32 bytes, with contract type number n represented by bit n % 8 of byte n // 8. This article applies that rule to retained data and tests the boundary cases locally.

Our example selects Active ID 2 from a solidified GetAccount response. The selected record contains one key with weight 1 and threshold 1. Those are observed configuration fields, not evidence that we control the key or know the account operator. We used a public address solely to make the reading method reproducible.

1. Save the unmodified account response.
2. Record the network, source endpoint and request time.
3. Find the exact ID in active_permission.
4. Copy its complete operations string without adding a prefix.
5. Decode that entry alone and retain unknown type numbers.
6. Review keys, threshold and the intended transaction separately.

2. Reproduce the October 29 observation

At 04:07:57–04:07:58 UTC on October 29, 2026, we made a read-only Mainnet request to https://api.trongrid.io/walletsolidity/getaccount. The JSON request used visible:false and address 41ccc1fa093d84927b8f1b16384fbf626c45f652a1. HTTP status was 200, and the response included the account address and an Active permission list.

The selected permission was ID 2, named active. Its operations bitmap was 7fff1fc0033ec30f000000000000000000000000000000000000000000000000. Our decoder found 37 set bits. Every enabled ID had a name in the retained protocol enum file. This is one account observation; it does not establish a default configuration for all Mainnet accounts.

The response does not attach a block number to this account object. We therefore preserve the collection time and endpoint rather than inventing an exact historical block anchor. Repeating the request later can return a different configuration. A later result must be saved as a new observation, not silently substituted into this example.

3. Read the operations bitmap byte by byte

Do not reverse the visible hexadecimal string. Split it into pairs of characters, retaining the leftmost pair as byte index 0. Each pair represents eight potential IDs. The first byte in our observation is 7f, so bits 0 through 6 are set and bit 7 is unset. The next byte is ff, so IDs 8 through 15 are set.

For a manual check of ID 31, integer division gives byte index 3, and the remainder gives bit 7. The observed byte at index 3 is c0. Its mask includes 0x80, so bit 7 is set. For ID 46, use byte index 5 and bit 6. That byte is 3e; its 0x40 bit is unset.

The byte and bit coordinates are zero based. Confusing the fourth visible byte with index 4 shifts the check into the wrong group. Likewise, reading the leftmost displayed binary digit as bit 0 reverses the interpretation inside each byte. The boundary tests below specifically exercise IDs 7 and 8 so these mistakes do not remain hidden behind a plausible-looking output count.

We retained the official Tron.proto enum source on October 29. It names ID 31 TriggerSmartContract and ID 46 AccountPermissionUpdateContract. The developing source branch is a naming reference, not proof of the version running at a public provider. Preserve the file used for your own interpretation.

4. Run the read-only decoder locally

Save the account response as account.json. Save the program below as decode_operations.py. Its second argument selects the Active ID. Its third argument is a JSON object mapping decimal type numbers, stored as strings, to names. The program reads local files; it has no HTTP request, signing, broadcast or permission-update routine.

For a minimal mapping sufficient to label the six worksheet IDs, save this as contract-types.json: {"1":"TransferContract","7":null,"8":"WitnessUpdateContract","31":"TriggerSmartContract","46":"AccountPermissionUpdateContract","59":"CancelAllUnfreezeV2Contract"}. Unmapped enabled IDs remain in the result. Our full real-data test used the complete enum extracted from the retained source, so it reported no unmapped IDs. A minimal file intentionally produces more unknown labels.

Run python decode_operations.py account.json 2 contract-types.json. Review both enabled and unmapped_ids. A missing label does not turn a set bit into an unset bit. This separation lets the program report the exact bitmap even when the naming reference is incomplete or older than the response.

import json
import re
import sys


def decode_operations(value):
    if not isinstance(value, str) or not re.fullmatch(r'[0-9a-fA-F]{64}', value):
        raise ValueError('operations must contain exactly 64 hexadecimal characters')
    data = bytes.fromhex(value)
    return [number for number in range(256)
            if data[number // 8] & (1 << (number % 8))]


def inspect_permission(account, permission_id, names):
    if not isinstance(account, dict) or 'Error' in account:
        raise ValueError('usable account object required')
    if type(permission_id) is not int or not 2 <= permission_id <= 9:
        raise ValueError('select an Active permission ID from 2 through 9')
    entries = account.get('active_permission')
    if not isinstance(entries, list):
        raise ValueError('active_permission list is missing')
    matches = [entry for entry in entries if isinstance(entry, dict)
               and type(entry.get('id')) is int and entry['id'] == permission_id]
    if len(matches) != 1:
        raise ValueError('selected Active permission must appear exactly once')
    selected = matches[0]
    enabled = decode_operations(selected.get('operations'))
    rows = [{'id': number, 'byte_index': number // 8,
             'bit_index': number % 8, 'name': names.get(str(number))}
            for number in enabled]
    return {'account': account.get('address'), 'permission_id': permission_id,
            'permission_name': selected.get('permission_name'),
            'operations': selected['operations'].lower(), 'enabled_count': len(enabled),
            'enabled': rows, 'unmapped_ids': [row['id'] for row in rows if row['name'] is None],
            'threshold': selected.get('threshold'), 'keys': selected.get('keys'),
            'scope': 'Bitmap decoding only; not signature, key availability or transaction validation'}


if __name__ == '__main__':
    if len(sys.argv) != 4:
        raise SystemExit('Usage: decode_operations.py account.json active-id contract-types.json')
    with open(sys.argv[1], encoding='utf-8') as source:
        account = json.load(source)
    with open(sys.argv[3], encoding='utf-8') as source:
        names = json.load(source)
    print(json.dumps(inspect_permission(account, int(sys.argv[2]), names), indent=2))

The decoder requires exactly 64 hexadecimal characters. It rejects missing, short, oversized and prefixed strings rather than padding them. Uppercase hexadecimal characters are accepted and normalized in the output. This strict input rule makes an accidental truncation visible instead of silently changing which operations appear enabled.

The permission selector also rejects a missing list, no matching ID and duplicate matching IDs. It does not guess that the first entry is ID 2, and it does not use an Owner object as an Active entry. These checks validate the supplied record’s shape; they do not establish that the account response came from a trustworthy provider.

5. Reproduce the local tests

We executed 22 offline test cases against the displayed functions. They include the retained real account, synthetic boundary masks and malformed inputs. The synthetic masks were local data only. None was installed on an account or used in a transaction. This is decoder testing, not a Mainnet permission-update trial.

To independently test the orientation, call decode_operations("8001" + "00" * 30) after importing the saved module. The result should be [7, 8]. Reversing the entire byte sequence would place those bits near the other end of the 256-position range. That mistake can still yield two set bits, which is why the exact IDs matter more than the count alone.

For the real example, the first eight bytes are 7f ff 1f c0 03 3e c3 0f; all remaining bytes are zero. You can compare those bytes with the original operations bitmap before reviewing any names. This gives a separate manual checkpoint between copying the source value and trusting a long decoded list.

6. Keep type scope separate from transaction meaning

A type-31 bit describes the contract-call category. It does not identify a particular token, recipient or function argument. A type-level decoder cannot conclude that a key is restricted to one named asset or that a future call is harmless. The contract-input reading guide covers the separate task of inspecting a call’s destination and encoded arguments.

A token spender allowance is also a different layer from this account permission. If you need that separate owner-spender value, use the read-only allowance-query tutorial. Removing or inspecting an allowance does not change the bytes decoded here. Do not combine the two records into one generic approval count.

An unset type-46 bit in our selected entry says nothing about whether another Active entry or the Owner permission could authorize an account change. Likewise, an enabled operation type does not demonstrate a valid signature or sufficient signing weight for a specific transaction. Keep the selected ID and its key list attached to every conclusion.

If the question concerns an earlier failed transaction, a current account snapshot is not automatically the configuration that applied at that earlier time. Preserve the original attempt and any relevant update records. This program has no historical-state query and cannot reconstruct past permissions from a present-day bitmap.

7. Preserve a precise review note

Record the account address, intended network, source URL, request times, selected ID, name, threshold, key list, original operations bitmap and mapping-file date. Include the exact enabled ID list and any unknown IDs. A note that says only “37 operations allowed” loses the distinction between very different sets with the same count.

Keep three outcomes separate: the input decoded successfully, the selected type bit was set or unset, and the intended transaction was valid or invalid. This decoder handles the first two within a supplied record. It does not perform the third. A successful process exit therefore cannot be used as a recommendation to sign, pay or update an account.

If an explorer’s labels disagree with your local output, retain both observations with their times. Check the exact account, Active ID, original bytes and naming-reference version before attributing a fault. A difference caused by selecting another permission is different from a byte-order bug. Preserve the unresolved discrepancy if the available evidence cannot distinguish them.

If the response omits the selected entry or its operations field, mark the interpretation incomplete. Do not replace it with an all-zero mask or the example’s mask. Missing information and a complete zero value follow different code paths deliberately. A later authorized read can supply new evidence without rewriting what the earlier response actually contained.

The success criterion is reproducibility: another reader with the same response and mapping file obtains the same IDs, byte positions and unknown labels. The resulting note should explain what was decoded and what remains untested. It should not rely on an account name, a balance screenshot or an assumption about who owns a key.

8. Audit the complete output rather than a summary count

The complete enabled-ID list for our retained response was 0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 30, 31, 32, 33, 41, 42, 43, 44, 45, 48, 49, 54, 55, 56, 57, 58, 59. Compare that sequence with your local output before attaching operation names. If the sequence differs, investigate the input and decoding first. Editing the naming file cannot repair a bit-position error.

To prepare a broader naming file, locate Transaction.Contract.ContractType in the retained official source. Copy each numeric value and its exact enum label into the JSON object. Keep the source file beside the mapping and record its date. Do not assume the enum is a continuous sequence: the observed list contains gaps, and the source also has gaps. Creating labels by counting lines would assign incorrect names.

A mapping file is an interpretation aid, not a list of operations that a particular provider currently accepts. The decoder deliberately does not filter away an enabled ID just because a reference omits it. Conversely, finding a name in a source file does not show that the bit was set in this account. Review the original bitmap and the name lookup as two independent pieces of evidence.

For a second review, ask another reader to check ID 31 manually without looking at the decoder’s answer, then compare their byte and bit coordinates. Repeat for unset ID 46 and the 7/8 synthetic boundary. Agreement on both positive and negative cases is more useful than agreement on a total alone. Record any disagreement and the original input instead of adjusting the result until it resembles an explorer label.

When sharing a small excerpt, include the selected Active ID and collection date with the mask. An isolated hexadecimal value can be decoded accurately while still describing the wrong entry. The reproducible result is the combination of source identity, exact bytes, method and limited conclusion.

Frequently asked questions

Is the operations bitmap a list of token approvals?

No. It describes system contract type scope for one Active permission. A token allowance is a separate owner-spender record.

Should I reverse the hexadecimal bytes before decoding?

No. Keep their displayed order and use the least significant bit of each byte for that byte’s lowest type ID. The local 7/8 boundary test checks this interpretation.

Does an enabled type mean a transaction will succeed?

No. Keys, threshold, signatures, state and execution requirements remain separate. This code only reads the supplied bitmap.

What does an unknown enabled ID mean?

The bit is set but the supplied naming file has no label for it. Keep the ID and verify the appropriate protocol reference rather than guessing a meaning.

Can this program modify my account permissions?

No. It reads local JSON files and prints a report. It contains no signing, network request or account-update function.

Checked October 29, 2026 by the Tronscan News editorial team. AI assisted preparation; the original decoder and 22 local tests were executed against retained public data. Independent publication, not official TRONSCAN support. For corrections, use this page’s comments with the affected step and public source; exclude private keys and recovery phrases.