SIP - Time-locked Savings Accounts

[bytemaster]

The purpose of this improvement is to enable liquid funds to be protected by the account recovery process. The requirement for protection is that there is enough time to notice the hack, coordinate with account recovery, recover account, and cancel any unauthorized transfers.

With this change it will be much easier to maintain the stance that liquid / unsecured funds are not recoverable in the event of a hack. Users will have the tools to secure their funds with confidence.

New Operations

transfer_to_savings from_account to_account amount memo
transfer_from_savings from_account to_account amount memo request_id
cancel_transfer_from_savings from_account request_id

New Virtual Operations

savings_withdraw_complete from to amount memo

New Database Objects

savings_withdraw_request {
     string               from
     string               to
     string               memo
     uint16_t            request_id
     asset                amount
     time_point_sec complete
}    

Savings balances for STEEM and SBD can be tracked on existing account object.

New API Calls

get_pending_savings_withdraws from
get_pending_savings_withdraws_by_receiver to

Behavior

Funds can be transferred into savings instantly, but require 72 hours (3 days) to withdraw from savings. This will guarantee there is at least 1 business day during which you can contact your recovery agent.

To prevent abuse of the memory space, each user account will be limited to 100 simultaneous pending withdraws from either STEEM or SBD savings (100 total, not 200).

Withdraw requests are assigned a unique ID by the withdraw request creator and the ID can be used to cancel the request later. The ID must be between 0 and 100 and there must not be any other active requests with the same ID. The operation should use uint16 to allow future upgrade to up to 65K pending requests per account.

Encourage Security, Discourage Recklessness

Interest on Steem Dollars should only accrue to balances held in savings.

Interest will be automatically paid every thirty days from the time the savings balance goes from 0 to positive until the balance is 0.

Shorter Review Periods

Accounts that wish to have shorter periods (24 hr or less) can maintain a rotating queue of withdraws and cancel them if they do not need it.

[abitmore]

Interest on Steem Dollars should only accrue to balances held in savings.

Good idea. Best if interest be paid at constant intervals (e.g. 30 days), but not like current implementation -- only pay interest when moving funds.

[abitmore]

Will SD in savings be forced converted to STEEM when conditions described in #230 met?

[bytemaster]

@abitmore yes all SBD will be treated equally with respect to #230

[arhag]

Will the SD part of the blogging reward immediately be deposited into the time-locked savings? I think it should.

Also, VEST withdraw options allow a user to automatically send the withdrawn STEEM to their own account or to another account in either liquid or vested form. I think those options should be augmented to allow the user to also have the option to withdraw the STEEM directly into the time-locked savings of their own account or to withdraw the STEEM directly to the time-locked savings of another account.

[theoreticalbts]

To match how market orders work, the ID should be 32 bits and suggested client behavior should be to set it to the current time.

If only an 8-bit or even 16-bit range is allowed, then high-volume accounts might need to recycle ID's, which violates the user expectation that ID's should be unique (within a single account).

[iamsmooth]

but require 72 hours (3 days) to withdraw from savings. This will guarantee there is at least 1 business day during which you can contact your recovery agent.

Not accurate in the case of holidays (and in some societies there are holidays of at least a week when it is almost impossible to do any kind of business). Likewise users may be on vacation or otherwise out of contact with the Steem account for some reasonable periods quite a bit longer than 72 hours.

I'd like to see some sort of user-settable rate limit on withdraw (with a reasonable default) as there is with vesting so even if recovery agent can't be contacted in some specific short time limit or is not responsive, the financial loss is still limited (even if not zero).

Only paying interest on SBD in savings will decrease liquidity and may have other unintended market consequences.

[bytemaster]

Notes: make sure this counts as a market/transfer operation

[bytemaster]

@iamsmooth - Presumably password recovery and hack recovery services will be 24-7. The question is the cost / benefit of extending the time.

[iamsmooth]

@bytemaster that is perhaps a very reasonable assumption, but you were the one who mentioned weekends.

Might I suggest considering something closer to the ATM withdraw-limit model? That is, you can withdraw up to $X per day, but larger withdraws require a delay.

This, I think, allows extending the delay with less inconvenience to the user, and makes timely recovery less of an all-or-nothing proposition. Losing a several days worth of daily-limit withdraws might sting but not be a disaster the way failing to respond to a hard (e.g. 72 hour) limit in time might be. There are numerous cases one can think about where the user might reasonably fail to handle the situation within 72 hours even if the recovery service is available, for example vacation, notification failure, etc.

[TheDarkLightX]

I like this but 30 days is arbitrarily long. Why not every 24 hours or even every hour? I don't understand the delay. But the time lock is a great feature and resembles the security provided by Coinbase Vault.

[bytemaster]

@TheDarkLightX this compounding calculations add a passive burden to every block.

[mvandeberg]

Tested and merged

[theoreticalbts]

Still need to make ID's uint32_t.

[abitmore]

Using sbd_XXX but not savings_sbd_XXX in adjust_savings_balance(...): line 3488, line 3490, line 3496

[abitmore]

Interest on Steem Dollars should only accrue to balances held in savings.

With current implementation, interest will be paid to liquid SD as well.

Interest will be automatically paid every thirty days from the time the savings balance goes from 0 to positive until the balance is 0.

With current implementation, interest will be paid only when balance changes but not every 30 days.

[mvandeberg]

With current implementation, interest will be paid to liquid SD as well.

That is intended. Sorry for documentation being out of date.

With current implementation, interest will be paid only when balance changes but not every 30 days.

That is also intended. It is exactly how interest on SD works currently.

[abitmore]

With current implementation, interest will be paid only when balance changes but not every 30 days.

That is also intended. It is exactly how interest on SD works currently.

Current behavior has been expected to be improved for a long time. People who forgot to move funds will lose the compound interest. If interest rate decreased some day(which is highly potential), people who finally remember to move funds after that date will lose more.

By the way, the pay-every-30-days design is not too hard to implement nor too much resource consuming, it's just like how powering down works currently.

[xeroc]

I think the reason for not paying automatically is because compound interest is expensive for the steem blockchain as a business. If you participate in the network and even earn a single SD cent, the compound interest will be paid out almost seemlessly.

[abitmore]

@xeroc Use It Or Lose It.
Advanced users may setup cron jobs to move funds every 30 days. Perhaps it's profitable to establish a service to help other people get the compound interest periodically? Only need to cost 0.001 SBD per month per user to achieve that (perhaps only doable for liquid SBD but not savings), any user with a monthly interest more than 0.2 SBD or average balance more than 20 SBD would benefit from subscribing that service.

[mvandeberg]

Time Locked savings is implemented and live on the blockchain. Closing this issue.