From 239b7a29572e04b14790b8f55bb6a0ea7fa1473f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Wed, 25 Jul 2018 14:13:07 +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 acb5f7f..b2e5808 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 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. +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 `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): ```