Spend and Save - A Necessary Integration For All Hive Frontends

A few days ago while performing an off-chain transaction, precisely via my banking service, I discovered my month-over-month reports that indicated income value, spending which was sub-sectioned into bank-to-bank outgoing transfers and internet services – which has to do with my data subscription values over the month.

What I found interesting wasn't the fact that these analytics were well presented, but more of my attention was caught by my expenses.

Looking further and trying to trace and narrow down all transactions, I was frankly shocked at how that much value runs in and escapes my account on a monthly basis and I'm not even a "bank guy".

This made me realize that I was living too extravagantly in comparison to income flows and more worrisome the economic state of the world – not that it can really be reduced at this point, the needed action is to spread my wings and see what more value I can draw to myself.

That said, there was a section of the report that caught my attention!

The Spend and Save

Apparently, some months back I may have activated a spend and save command on my banking app and each time I made a transaction regardless of what it was, a portion of my balance was moved to savings at my specified percentage.

It really caught my full attention because regardless of having kept the bar at 1%, it turns out just that amount is significant when added up through all spending practices. So I decided, fine, let's make it 15%, and see how well I'll survive as it cuts my expenses low at a huge range.

Applying it to Blockchain - Hive!

I have grown this attachment to blockchains that I expect that every business model deployed on legacy infrastructures should be restructured and given a home on the blockchain.

HBD being our primary focus, I'd say I suck at saving in general so no surprise I cannot commit even when dealing with digital assets, and so the tools to compel people and promote more spending practices needs to be encouraged on Hive - preferably deployed on all frontends!

How I expect it to look,

although it's subject to improvements to meet the larger user needs.

The mechanism would need to support multi-purpose transactions similarly to Vechain multi-task transaction model- which in my own Hive-based theory would allows different "active" as in key signature commands to be sent and executed in one transaction!

Meaning that for it to be seamless, I believe it would require a system that allows a single transaction to carry multiple commands like -

Transfer 100 hive from @malopie to @deepcrypto8 and Save 10 hive to @malopie while at it.

Both are signed and executed as a "single transaction" instead of having two different transactions that would mean the need to sign twice, of course, if the system can be seamlessly designed to function with the later delivery method, it's still a win-win. Maybe this functionality already exists - would appreciate a shout-out if it does in the comments.

The benefits - More people would hold Hive Debt - HBD

Since this will obviously not be limited to HIVE coins, HBD embraced would be a huge beneficiary considering that as it stands, spending and saving HBD seems ideal cause it regenerates at a 20% APR following the witness consensus.

I would also expect that regardless of what is spent e.g HIVE, the system should allow the saving of HBD alongside this transaction, and to ensure that all things don't lead to system exploitation, the transaction should fail if the balance on both sides doesn't meet the command!

Meaning, if there's 100 HIVE but zero HBD to execute the command to:

Transfer 100 Hive from @malopie to @deepcrypto8 and Save 20 HBD to @malopie

The transaction would return an error code promoting that balance is low and a different transaction model should be picked.

This means, there would be a "regular transaction type", a "recurring transaction type", a "spend and save transaction type" and a "recurring spend and save transaction type".

The Arbitraging Risk

It could be called a "risk" or a "market merit" as we all should know that arbitrage only becomes a risk when price differences are too large and allows exploitation.

This would be observed with "Spend and Save" transaction types on Hive when users are trying to save HBD while spending HIVE!

So let's say the blockchain has to rely on the witness price feed and relay values based on % - which in this case is 20%, collecting the "output" for each HIVE amount entered in the denomination of HBD in percentage would open rooms for arbitrage.

To understand what I mean, let's say HIVE is trading at $1 a unit while spending 100 HIVE which is hundred dollars, and saving 20 HBD(20% of the spent amount in HBD) which should always be $1 a unit, the blockchain needs to be able to consistently tell what the actual price value of both assets are, and while it can't always be 100% accurate, the benefits/risk is an open room for arbitrage!

It is a likely scenario because "Saving Values" would most likely be presented in percentage rather than asking users to manually input the values!

The idea of saving in the first place is so that they can't influence the value that goes in and out of circulation!

Recurring spend and save!

In respect to my title, Hive frontends would only need to display these tools via their platform as the actual work needs to be done on the Hive Blockchain unless, of course, we're looking at projects building similar structures for their layer 2 assets.

This is where the importance of smart contracts on hive is perceived as this would allow users more flexibly use these base layer features.

Anyways, having learned that recurring transfers could be a potential solution to debit card flaws, spending and saving become even more powerful to integrate.

Imagine a situation where Hive users spend thousands to millions of hive shopping, while also paying for services - looking at services that charge on a monthly - autonomously without the user involvement.

Giving users the ability to remove a percentage of their money from circulation each time their balance is charged via recurring transfers to pay for services perhaps is ideal.

With this, users are given more easy routes to saving up more as they spend and as their savings are locked up, more people are protecting the value of HIVE just as they HOLD the networks' debt - HBD.

With the fact that HBD pays an APR and possibly Hive could in the future via saving, the integration would be vastly adopted.

^{These are my morning shower thoughts, I'm only an idea hamster, I think, write, and build what I can. See my ventured project and don't forget to share your opinions - let's discuss, thank you.}