Tags Guide
Tag Information Documentation:
The protocol uses tags to assess fees and facilitate rule checks for addresses. Tags are applied to addresses via an addTag function in the app manager by application administators. Tags are stored as bytes32 in a mapping inside the tags data contract. A maximum of 10 tags may be applied to each address. Their purpose is to be for application of rulesets to specific groups of individuals that may be too narrow to be encompassed in an access level.
The tag data contract is deployed with and owned by the application manager contract. In the event of an upgrade the data contract can be migrated through a two step migration process. App administrators are the only ones who can migrate the data contracts to a new app manager contract. To understand the structure of tags at a far more indepth level please check here. If you would like an overview of all the tags available, there is a list located here.
Quick start
Lets begin a quick example of using tags. First, it is assumed that you have already deployed the protocol locally, have an application manager set up as well as a rule admin in place and have deployed a token with an appropriate token handler contract address handy. If not, please set those variables up now.
For our example we’re going to do a simple minimum/maximum token balance to be held by an account over a specified number of hours. If you’d like to dive deeper at any point, we recommend you read more here. Lets begin by saying that for all users with the tag “A” we want to be able to demand that they have a minimum balance of 20 and a maximum balance of 100 for a time frame of 3 hours. We would pass in the parameters to the function:
such that _appManagerAddr is $APPLICATION_APP_MANAGER, _accountTypes is [0x4100000000000000000000000000000000000000000000000000000000000000] which contains the hex input for ‘A’ with zeros appended, _min is [20], _max is [100], _periods is [3] for the number of hours required and _startTime is the current unix timestamp for when the checks should start, which due to the way the contracts are constructed, we can use the number 0 to get. The final call to this would look something like:
Once this is cleared, we need to get the index of the rule that was just created. If you’re using cast or a client side sdk for interaction, you’ll want to pull this from the logs on the signature AD1467_ProtocolRuleCreated(bytes32 indexed ruleType, uint32 indexed ruleId, bytes32[] extraTags) and search for the ruleId. Here’s an example of how that would look using cast:
From the output, search for the third argument in the topics to get the ruleId in a bytes format. If you’re using a smart contract to deploy the code, simply take the returned uint32 from the call to the function as this is the ruleId. Once you have the ruleId, it’s time to add it to the application. Call the function on your token handler setAccountMinMaxTokenBalanceId(uint8[],uint32) where the uint8 array is an array of enum selections from the action types and the uint32 is the ruleId. For our purposes we’re going to add all of the action types into our transaction send.
Finally, we activate the rule using activateAccountMinMaxTokenBalance(uint8[],bool) and can begin tagging accounts:
And can now call addTag(address _account,bytes32 _tag) with the App admin on the application manager to tag an account.