Skip to content

Commit

Permalink
rename priviledge to funtionality
Browse files Browse the repository at this point in the history
  • Loading branch information
trinitys7 committed Jan 8, 2025
1 parent 64fedb7 commit 833a1f0
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions x/asset/spec/01_concepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,15 +6,15 @@ order: 1

## The Realio Asset Token Model

The Realio Asset module is centered around a token model where certain whitelisted accounts can issue their own token. A token issued by this module will be managed by a set of privileged accounts. These privileged accounts are assigned role by the issuer of the asset.
The Realio Asset module is centered around a token model where certain whitelisted accounts can issue their own token. A token issued by this module will be managed by a set of `manager` and `distributor` accounts. These accounts are assigned role by the issuer of the asset.

### System of privileged accounts
### System of functionality accounts

Privileged accounts of a token are accounts that can execute certain actions for that token. There're are several types of privileges, each has its own logic to define the actions which accounts of said type can execute. We wanna decouple the logic of these privileges from the `Asset module` logic, meaning that privileges will be defined in separate packages/modules, thus, developers can customize their type of privilege without modifying the `Asset Module`. Doing this allows our privileges system to be extensible while keeping the core logic of `Asset Module` untouched and simple, avoiding complicated migration when we expand our privileges system.
Functionality accounts of a token are accounts that can execute certain actions for that token. There're are several types of functionalities, each has its own logic to define the actions which accounts of said type can execute. We wanna decouple the logic of these functionalities from the `Asset module` logic, meaning that functionalities will be defined in separate packages/modules, thus, developers can customize their type of functionality without modifying the `Asset Module`. Doing this allows our functionalities system to be extensible while keeping the core logic of `Asset Module` untouched and simple, avoiding complicated migration when we expand our functionalities system.

In order for a privilege to integrate into the `Asset Module`. It has to implement the `Privilege` interface and has its implementation registered via the method `AddPrivilege`. Once that is done, we can make said privilege available onchain by executing `SoftwareUpgradeProposal` like a regular chain upgrade process.
In order for a functionality to integrate into the `Asset Module`. It has to implement the `Functionality` interface and has its implementation registered via the method `AddFunctionality`. Once that is done, we can make said functionality available onchain by executing `SoftwareUpgradeProposal` like a regular chain upgrade process.

It's important to note that the token manager can choose what privileges it wants to disable for its token Which is specified by the token manager when creating the token. After creating the token, all the enabled privileges will be assigned to the token manager in default but the token manager can assign privileges to different accounts later on.
It's important to note that the token manager can choose what functionalities it wants to disable for its token Which is specified by the token manager when creating the token. After creating the token, all the enabled functionalities will be assigned to the token manager in default but the token manager can assign functionalities to different accounts later on.

### EVM enable

Expand Down

0 comments on commit 833a1f0

Please sign in to comment.