Decentralizing a Certificate of Deposit (2024)

This article explores the motivations and methodology in developing a smart contract-driven Certificate of Deposit that offers its users a return-on-investment by penalizing early withdrawals and redistributing the penalties to parties who leave their funds alone until the maturation date of the CD. The similarities and differences between HODL/PoWH games is discussed.

The Ethereum blockchain is capable of executing smart contracts: decentralized code that enforces a set of pre-programmed rules and actions regarding incoming funds or information.

Decentralized banking represents a significant opportunity for blockchain development, and I was curious how one would go about recreating the equivalent of a Certificate of Deposit, a fairly boring but standard banking industry offering, using Ethereum.

Certificates of Deposit (CDs) are best described as a “timed deposit” with rewards for on-time withdrawal — the interest rate — and penalties for early withdrawal, such as a loss of a portion of the original deposit taken as fees.

Upon maturity, the date agreed upon for which withdrawal becomes available, the original principal amount as well as the accrued interest are released to the depositor.

Example: a one year term with a $500 minimum might yield 2.75% from a given bank. Thus, at the end of one year the original depositor should receive $513.75 if they invested the bare minimum.

This, at first, seems like a straight-forward sort of application perfect for a blockchain.

The smart contract being described is a standalone application, and thus doesn’t have access to the digital equivalent of a bank that is investing its money, making loans, or making market trades.

Several options present themselves:

1. Penalize early withdrawals and pass fees back to other depositors.
2. Allow the smart contract owner to access a portion or the full principal funds for external investing.
3. Allow the smart contract owner to access a portion or the full amount of the fees assessed from early withdrawals for external investment.
4. Allow the smart contract to invest partial or full principal funds in other smart contracts.
5. Allow the smart contract to invest partial of the full amounts of early withdrawal fees in other smart contracts.

The first option can be fully automated and is provably fair.

The second option is the most dangerous, as the depositor has no guarantee they’ll be able to eventually withdraw even their original principal amount at the maturity date.

The third option represents risk to the interest gain for the depositor, but preserves their original principal.

Readers experienced with various Ethereum “games” will recognize the similarity described herein to HODL games like “Proof of Weak Hands” and its myriad copies and imitators. The idea in these games is to distribute a withdrawal penalty (sometimes 10%!) from early exiters to those who stay in the game. In most cases these “game” smart-contracts contain the equivalent of “clauses” that always give a certain amount of the fees to the contract owners/early-investors themselves — which explains the numerous iterations constantly spawning themselves, all competing for attention.

At the time of writing the PoW3D game held a balance of 22,510 ETH, which was worth about $3,071,714.

The fourth and fifth options are rather undeveloped. There are no great, truly decentralized “banks” in the Ethereum ecosystem. One might imagine such a digital edifice as a collection of community developed and approved banking smart contracts over which no person has control.

In the here and now it is indeed possible, at least to some degree, to have smart contracts automatically invest their funds in other smart contracts. An example of this could be in an Ethereum crypto-exchange in which funds are deposited and a variety of tokens are bought, then cashed-out at a later date. Or, much more dangerously and unwisely, “invested” in a HODL style game.

It should be noted that any variety of the above methods might be used, but this article is dedicated to the idea of pure decentralization.

Further, the key difference between a legitimate CD offering on the blockchain and the HODL-style games is that the CD must allows its users to withdraw at the maturity date without penalty.

It should also be especially noted that by simply replicating the early withdrawal penalty of real-world Certificates of Deposit that no actual external investment scheme is needed to reward depositors.

Other depositors would receive a portion of the fees accrued before their maturity dates, and thus the “interest” rate then would simply be variable.

In fact, these early CDs would most likely not promise a guaranteed yield rate at all, and fee-sharing-only types would replicate the style of HODL games but in an unbiased manner.

Note: It is entirely possible that this style of decentralized CD could end up offering no reward at all to its depositors, costing them the gas spent to deposit and withdrawal, and do nothing more than act as a time-locked savings account.

The factors involved in calculating this sort of return-on-investment include:

• Number of depositors
• Minimum amounts of deposits
• Gas costs for transactions
• Predicted Rate of Early Withdrawal
• Early Withdrawal Fee Scheme (Fixed, Pro-rated, etc)
• Distribution Scheme (Fixed, Proportional, etc)

In the abstract sense there are three possibilities for the number of depositors that might be utilizing a CD smart contract: zero, one, or many.

In the case of zero there is no issue, as no gas has been expended executing functions.

In the case of one there is no issue except for early withdrawal: where does the penalty fee go? Future users?

In the case of many there are issues only regarding the total number of supportable accounts. Due to block-gas execution limits there is a realistic ceiling on how many accounts might be allowed to utilize a given instance of the CD smart contract at a time.

Early Withdrawal Gas Consumption

For instance, let’s say that an early withdrawal fee of 1% of the account balance is due, and the depositor initiates a withdrawal request.

There are two components to calculating the gas usage for this call:

• Constant Cost: the minimum gas usage for calculating the depositor’s remaining funds and sending it to them in a given transaction
• Variable Cost: the gas used to disperse the fee amidst remaining accounts that haven’t met their maturity date yet.

In algorithmic complexity the first operation, handling the depositor’s withdrawal, is O(1) or constant time.

The fee dispersal, though, is O(n), or linear time, based on the number n other depositors whose maturity dates have not yet been met who get a share of the fees.

Example:

• 1 ETH deposit
• 1% Early Withdrawal Penalty
• 100 other depositors with immature accounts

The fixed or constant cost might be 50,000 gas between verifying the account’s balance, performing the math to determine the penalty, deducting the penalty, and creating the transaction that will return their funds.

Based on the 1% early withdrawal penalty being split evenly each depositor would receive 0.0001 ETH.

Looping through the list of accounts and performing this math might cost 5,000 gas each; a total of 500,000 gas.

A grand total of 550,000 gas has now been expended in our hypothetical case.

The reader can see how, at the current block gas limit of around eight million, that the contract could only viably support (8000000-50000)/5000 total depositors, which would be about 1,590.

Thus careful performance auditing of the contract’s finalized functions would need to be performed on the test networks before a deployment to the production Ethereum network would be possible with a pre-determined cap on total depositors.

Note: the gas costs described above are completely hypothetical.

The next question to ask is: under what circ*mstances is the contract profitable to the average user?

In our case an average user is one who allowed their account to reach its maturity date without withdrawing early.

In a fee-only type the depositors are the ones paying the gas fees to execute the deposit() and withdraw() function. Additionally, it isn’t contemplated that this style of CD smart contract would allow partial withdrawals.

Thus, for a given, average user, depositing money into the CD assumes that some certain percentage of accounts will withdraw early, passing on the fees to the rest of the accounts.

The gas spent in the initial deposit() and eventual withdraw() cases need to be covered by the long-term investment gain in order for there not to be a loss to the matured account holder.

Exploring a Worst Case

Using the Ethereum Gas Station’s calculator we could imagine in the worst possible case that the initial deposit might take 50,000 gas and the withdrawal up to the maximum block gas limit (8,000,000) for a total of: 0.02415 ETH (at average safe-spend Gwei).

Since that is quite literally 2.415% of the 1ETH minimum and given the 1% fee described in the example above, and assuming something like 1,590 total immature deposit accounts, it means that creative math must be employed to figure out the minimum number of early withdrawals needed to be break-even for a mature account, and account for the fact that even though early withdrawals have occurred new accounts have replaced them up to the cap on total depositors.

In other words, we have to assume, worst case, that new depositors can join the contract after old ones leave.

Again, in the worst case, if a single depositor joins and exits early with a minimum deposit of 1ETH, each of the 1,589 other depositors would receive 0.000629ETH. Thus it would take ~38 repeats of this action (a minimum balance holder with unaccrued funds being replaced again and again by the same) for enough funds to accumulate in each mature account for the remaining accounts to withdraw at a break-even, given gas consumption costs.

Thus this contract example assumes, worst case, that 2.4% of its depositors withdraw early in order for the rest to be rewarded. Everything beyond that is gravy to the depositors.

The long-term maturity of a Certificate Deposit lends itself well to the idea of the smart contract being able to invest its funds, in whole or part, in a decentralized exchange like IDEX for trading ERC-20 tokens.

Multiple schemes for allocating funds for investment might be employed: whether the principal is touched or not is up to the style of the CD. It is possible that an ecosystem of decentralized CD offerings would develop where some invest only collected fees while others risk their principals.

The methodology for this should be apparent: the CD would have a token-pair or basket of token-pairs that it can invest in and new incoming funds would be allocated to it. One would imagine during withdrawals the converse would occur where funds would be sold and transferred back to the CD smart contract.

The caveats here are that these investment actions do not occur on the same block, and thus some measure of self-executing callback or oracle functionality is required, requiring more smart contracts with possible external (non-blockchain) interactions and an internal account in the CD smart contract to handle gas fees.

The risks associated with this should be apparent: trades could fail, the markets may decline in value, or even, given the public nature of all blockchain actions, markets could be manipulated by the knowledge of maturity dates in CD smart contracts and their association with automated trade execution.

The design and development of a decentralized Certificate of Deposit (CD) smart contract is an academic exercise.

However, the implementation and publishing of any such contract may run afoul of any given country’s financial securities laws. If there is a “smart contract owner” who is collecting a portion of fees then this is guaranteed, as it would be an unregistered security.

On the other hand, this would also incentivize blockchain developers to work on making these new types of securities registered and approved by their governments, and thus make it possible to have the owning-authority make a return-on-investment for advertising and supporting the CD.

This would also create a financial arms race, especially in the field of automating investment, that would boost the Ethereum ecosystem forwards in the usage of decentralized exchanges and banking functionality.

In the development of this sort of CD smart contract I would begin with the following, simple design:

• No contract owner
• No automated investment
• All fees shared proportionally by remaining deposit amounts
• Minimum deposit amount (TBD)
• Simple, timestamp based term, such as one year
• No promise of profit or yield
• Hard cap on total depositors

The parameters for minimum deposit, cap on depositors, and early withdrawal fee would all be determined after the gas requirements were discovered after development is complete.

Viability of different implementations would be tested on the various Ethereum test networks.

It’s contemplated that a self-owning version of the most basic, simplest type would then be deployed on the production network.

This article is a simple proposal with some rough sketches on how to legitimize the use of “time-lock” smart contracts in a provably fair way, while avoiding the unseemly aspects of the current generation of gambling “games.”

Certificates of Deposits on the blockchain represent a forward-movement in the development of decentralized financial products, and it is entirely possible to create such smart contracts as self-owning mechanisms that fairly distribute early withdrawal fees.

Additional research, especially in discovering the rate at which real-world Certificates of Deposit penalties occur in the banks’ favor, is needed.

However, the author believes that enough information is already available to begin development on such contracts and is now working on one such implementation.