From a82530729e951e7b664fb6b0b355967dbacfbd8d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Wed, 25 Jul 2018 14:12:42 +0200 Subject: [PATCH] Update bsip-0040.md --- bsip-0040.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0040.md b/bsip-0040.md index 8855536..acb5f7f 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -37,7 +37,7 @@ The above list of named keys is nothing that is known to the backend as the back # Rational The description here is more on a superficial level and no recommendation how it can best be implemented. -Custom active permission is a list of custom active authorities. A `custom active authorities` contains an `operation_id`, an `authority` (just like with active permission) and a list of `assert`s than can be used to restricted arguments. When a transaction is signed with such an authority the backend checks if the contained operation has a corresponding custom active authority entry and if so acts as if the active authority of the corresponding account is given. It also checks if the arguments are in the allowed range. +Custom active permission is a list of custom active authorities. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and a list of `assert`s than can be used to restricted arguments. When a transaction is signed with such an authority the backend checks if the contained operation has a corresponding custom active authority entry and if so acts as if the active authority of the corresponding account is given. It also checks if the arguments are in the allowed range. A Custom Active Permission looks like follows (in JSON for clarification, backend serializes and stores in a different way): ```