Update multi-signatures.md#589
Open
GordonLtron wants to merge 1 commit into
Open
Conversation
vivian1912
reviewed
May 20, 2026
| # Account Permission Management | ||
|
|
||
| The TRON network supports fine-grained control of account permissions. By configuring permissions (owner, witness, active), joint control of accounts, secure delegation, and functional permission separation can be achieved. The following document details the account permission model, contract structure, configuration methods, and common interface calls. | ||
| The TRON network supports Hierarchical Role-Based Access Control (RBAC) of account permissions. By configuring permissions (owner, witness, active), joint control of accounts, secure delegation, and functional permission separation can be achieved. The following document details the account permission model, contract structure, configuration methods, and common interface calls. |
Contributor
There was a problem hiding this comment.
It is recommended to stick with the original description; RBAC might not be entirely accurate for TRON.
vivian1912
reviewed
May 20, 2026
| - This contract is used to **update all account permission structures at once**. | ||
| - This contract is used to **update all account permission structures at once**, which is an "all-or-nothing" update. Even if modifying a single permission, the full permission set must be resubmitted to prevent accidental loss of access. | ||
| - Even if only one permission is modified, all other existing permissions must be fully specified in the contract. | ||
| - `AccountPermissionUpdateContract` |
vivian1912
reviewed
May 20, 2026
| ### 2. Operations Value Calculation Example | ||
|
|
||
| `operations` is a 32-byte hexadecimal string (little-endian) representing executable contract permissions. | ||
| `operations` field is a 32-byte bitmask where each bit represents a specific `ContractType` , defining the functional scope of an Active permission. |
Contributor
There was a problem hiding this comment.
Suggest keeping the little-endian information.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR enhances the documentation for Account Permission Management. The updates focus on clarifying the hierarchical structure of TRON accounts, the mechanics of threshold-based security, and the bitmask calculation for operational permissions.
Key Changes
1. Security Model Refinement
Threshold Mechanics: Provided a clearer explanation of how Weight vs. Threshold validation works during transaction broadcasting.
2. Technical Specification Updates
Bitmask Calculation: Refined the Java example for calculating operations values, ensuring developers understand the little-endian hexadecimal requirement.
Atomic Transaction Logic: Added a "Warning" block regarding AccountPermissionUpdateContract, noting that partial updates will overwrite omitted permissions.