Running a database with no liquidity does not allow you to actually transfer funds.
When A sends money to B both have an expectation that B is able to access such money through normal monetary systems like: seeing their bank balance go up, withdraw it as cash, or transfer it again to C which will have a similar recursive set of expectations.
Unless your database is the de facto central banck for the currency A and B use you will have to convice B's monetary system to believe B now has more money. The simples and almost only way to do that is to pay the appropriate price in a currency they like.
Which requires liquidity.
As an example if you wanted to install a bitcoin ATM with withdrawl* in a train station (or anywhere else) you would need liquidity in whatever currency the user want to withdraw.
* I suppose you could withdrawn bitcoin by giving out fresh wallets with the sum or by simply transfering it.
Why should a database need to transfer funds? Bitcoin doesn’t transfer funds, it’s just a shared ledger of what funds have been transferred. Lots of banks use Oracle to record fund transfers, but Oracle doesn’t transfer any funds.
> Lots of banks use Oracle to record fund transfers, but Oracle doesn’t transfer any funds.
because it is the banks that do the transfer, so they need to have liquidity
> Bitcoin doesn’t transfer funds, it’s just a shared ledger of what funds have been transferred.
the bitcoin blockchain act as a single bank in terms of transfering between bitcoin wallets, there is no need for central liquidity because it is all "internal".
A perfect example is arbitrage between bitcoin exchanges, to my undestanding many exchanges do internal transactions off-chain and only interact with the public blockchains for deposits/withdrawals. If a user wanted to exchange bitcoin for ether and then withdraw the sum the exchange would need to have liquidity in ether for the withdrawal.
