Advanced Tutorials

Implementing Custom Authorization Rules

To define custom authorization rules, you must first understand the granularity of your use case and the limitations of your module. We encourage you to study the provided example and extract insights tailored to your requirements. Below, we showcase how this module is utilized for our specific purposes.

Recurring/Scheduled Message Execution Tutorial

1. We prepare an example of how to use x/icauthcall module in interchain-auth. The module is called x/schedule.

2. The x/schedule module is an automation tool that uses BeginBlock and EndBlock to manage and execute scheduled queues. While it functions as a cron-like executor on its own, its integration with x/icauthcall transforms it into a robust solution for recurring transfers and swaps, enabling advanced scheduling features for the chain.

3. x/schedule have three action to support three features:

   • Actions
     • Create schedule
     • Execute schedule
     • Cancel schedule
   • Features
     • Recurring swap
     • Recurring transfer
     • Scheduled transfer

4. For our tutorial purposes, we only focus where custom authorization are created. We will go in-depth in Create Schedule and Recurring Transfer.

5. Recurring Transfer are chosen because it contains the full example of how the authorization works.

6. Let’s say that we want to have these authorization in recurring transfer.

   • Whitelist address: array of string
   • Transfer limit: how much transfer can be done in one message execution
   • Total limit: the sum of transfer amount in that schedule lifetime
   • Daily limit: the sum of transfer amount in that day (UTC)

   We can categorize which is immutable data and mutable data:

   • Whitelist address and transfer limit are immutable. It will not change.
   • Total limit and daily limit are mutable because it needs calculation.

7. After we declare the authorization constraint, take a look at your cosmos SDK message. In our case, we want to execute this

   [
       {
           "@type": "/cosmos.bank.v1beta1.MsgSend",
           "from_address": "cosmos1zypqa76je7pxsdwkfah6mu9a583sju6xq....",
           "to_address": "cosmos1mgp7qnvumhlcq6e4z2q05r29dchcyug0z....",
           "amount": [
               {
                   "denom": "ualpha",
                   "amount": "50000000"
               }
           ]
       },
   ]

   If you remember the core concept explanation, the parameter that can be validated will be from_address, to_address, and amount because the message are /cosmos.bank.v1beta1.MsgSend

8. Now let’s combine them both to form something like this. Remember, adjust the validation value according to user input.

   [
   {
       "enable": true,
       "immutable": {
           "from_address": [
               {
                   "type": "string",
                   "operator": "equal",
                   "value": "cosmos1zypqa76je7pxsdwkfah6mu9a583sju6xq...."
               }
           ],
           "to_address": [
               {
                   "type": "array.string",
                   "operator": "equal",
                   "value": "cosmos1mgp7qnvumhlcq6e4z2q05r29dchcyug0z....,cosmos1zypqa76je7pxsdwkfah6mu9a583sju6xq...."
               }
           ],
           "amount": [
               {
                   "type": "array.coin",
                   "operator": "lte",
                   "value": "50000000ualpha"
               }
           ]
       },
       "mutable": {
           "amount": [
               {
                   "type": "array.coin",
                   "operator": "sum",
                   "value": "100000000ualpha"
               },
               {
                   "type": "array.coin",
                   "operator": "daily.sum",
                   "value": "100000000ualpha"
               }
           ]
       }
   }
   ]

9. The code implementation would look like this: recurring_transfer.go

Debugging and Validating Complex Transactions