add economics
This commit is contained in:
parent
ab5500dfda
commit
0e8e9ad705
1 changed files with 8 additions and 2 deletions
10
bsip-0040.md
10
bsip-0040.md
|
@ -52,7 +52,7 @@ A `custom_active_permission` looks like follows (in JSON-like/pseudo for clarifi
|
|||
custom_active_permission = list of custom_active_authority items
|
||||
custom_active_authority = {
|
||||
valid_from, // timestamp when this is active, defaults to now
|
||||
valid_to, // timestamp when this is invalid, defaults to 1 month
|
||||
valid_to, // timestamp when this is invalid, defaults to 1 year
|
||||
operationid, // operationid of the target operation,
|
||||
authority, // same as for the existing authortities (multisig with weighted accounts or keys),
|
||||
asserts // see below
|
||||
|
@ -144,6 +144,12 @@ That has the consquence now that a transfer transaction sending funds away from
|
|||
|
||||
Note: This is just an illustration of a possible serialization, not a specification of the serialized format.
|
||||
|
||||
### Economics
|
||||
|
||||
Adding a custom active authority means increased effort for the backend, and with a stateful one also the need for more storage.
|
||||
We propose that the transaction fee for the creation is tied to the duration of the custom active authority.
|
||||
Furthermore, normal accounts can only create custom active authoritites with a duration of maximum 1 year. LTM can do any duration and also unlimited, but the transaction fee is capped at duration of 2 years.
|
||||
|
||||
### Outline of handling incoming transactions
|
||||
|
||||
When a signed transaction arrives and before the backend evaluates if all necessary authorities are present through the signatures, do the following:
|
||||
|
@ -180,7 +186,7 @@ the transaction is executed.
|
|||
Notes: The implementation must not differentiate on which operation the custom active authority is applied, all operations are treated in same fashion
|
||||
|
||||
# Milestones
|
||||
We propose do split the implmentation into two milestones:
|
||||
We propose do split the implmentation into two milestones. Each milestone will be voted on as a separate BSIP:
|
||||
|
||||
1. Implementation of basic functionaliy to allow custom active permissions and authorities, including `any`, `none` and `lt, le, gt, ge` and `attribute_assert` `asserts`. If deemed necessary by developpers, reduce to only allow one key or one account for every `custom active authority`
|
||||
2. Evaluation of stateful asserts `limit` and `limit_monthly` in terms of performance. If positively evaluated, implement
|
||||
|
|
Loading…
Reference in a new issue