DEV Community: Jazz_Baba

A Time-Lock Smart contract That generates funds for devs.

Jazz_Baba — Fri, 02 Jun 2023 18:44:08 +0000

A time lock smart contract is a tool that locks tokens or crypto currencies into a smart contract for a particular time frame. This is a very useful feature in prevention of impulsive token sales or transfer on a whim.
The smart contract implemented allows external users to lock their Ethers in the smart contract and pay a small fee which goes directly to the developer of the smart contract. This could be a passive income generator for a smart contract developer.
Many technical concepts are implemented in this smart contract, some are:

Using modifiers
Preventing re-entrancy attacks
Working with Dates in smart contracts.
Using Structs and Mappings

The smart contract has the following features which can be used as a guide in understanding smart contracts and developing ideas which builds on this. The features are:

A taxing system
A time lock feature
Funds transfer feature
Authorization

Also included is simple string concatenation in smart contracts and using emojis.

Transferring Ethers to the Smart contract

The initial step to activating the smart contract lock feature is to credit the smart contract. The smart contract has a pay function that is "payable". The first check in the pay function is to ensure the amount inputed is that same as the value the user pays into the smart contract. A require statement is used to achieve this. The second check is to ensure that the credit amount is at least the fixed tax associated with the funds lock functionality. This particular smart contract implements a fixed tax system which would be explained further in the article.

The smart contract allows seamless withdrawal of funds that are transferred to the smart contract when the lock feature has not been triggered. No lock fee or tax is imposed only transaction gas is deducted by the EVM.

Triggering the Funds Lock feature

The main course in this project is the Time Lock feature. This feature implements a struct that holds essential details of the user: the start time for the funds lock, the Lock interval, user balance. As soon as a user locks their funds in the contract, the variable "hasLockedFunds" is set to true this is stored to be used to ensure the user has locked funds and has permission to trigger the withdraw functionality.

The image above shows the use of a struct to encapsulate all the user details in the smart contract.
The power of structs in smart contracts is unleashed when used with mappings and other structs. This is the simplest use case of a struct and a mapping.

Above is the implementation of the funds lock functionality. the code above uses a time of 15 seconds which is for testing while implementing the smart contract. The smart contract lock period is fixed at 365 days, this could be easily changed to accept a "number of days" variable value.

To test the time Lock functionality you could set the lock time to "15" seconds, this would help the developer validate the time count down functionality.

Time lapse feature

To help users of the smart contract know how far along their funds lock is there's a "howManyDays" feature. This feature helps the user get the number of days left before their funds are available for withdrawal. The functionality depends on a countdown timer which sets the "funds release time", which is when the funds would become available. The countdown timer ensures the "block.timestamp" hasn't yet equalled or exceeded the set "funds release time". The functionality uses "int256" and does a type casting to convert the difference "fundsLockTime" and the "presentTime". The difference between these two variables would eventually spill into a negative vale and the "uint256" type would error on variable subtraction.
Below is the code snippet for this:

The Tax System(payday for devs)

Smart contracts and tokens often implements a tax system that ensures the service rendered by the smart contract is billed to the end users of the contract. There are various taxing models that could be used, on this safe lock project a fixed tax system is implemented , which bills any Ether lock into the smart contract. A base fee of 0.00055ETH(which is about $10 as at writing this smart contract).
This fee can only be withdrawn by the smart contract developer. The code includes a snip-bit of how to use emojis in a smart contract for you perusal.

If you've followed the article all through, big up's. You can find the code on github. You can reach me on linkedIn and twitter. Looking forward to your comments and questions.
The smart contract would work seamlessly on the Remix IDE. Further set ups would be required for a local IDE.

See you soon, be on the look out for my next article on creating your own ERC20 token.

How To write a Smart Contract Wallet with Ownership change

Jazz_Baba — Mon, 22 May 2023 17:00:57 +0000

A smart contract Wallet can be defined as a device or application that lets users customise the way they would prefer to manage their digital assets.

One very important skill of a smart contract developer is understanding a understanding transactions in the EVM, having a sound knowledge of gas use and optimisation, harnessing the power of low level calls, understanding the security risks and sticking to safe smart contract writing patterns. All this principles are covered in this simple solidity project.

Overview

The projects implementation is broken into 4 sections:

Implementing a smart contract owner and restricting certain functionalities to the owner only.
Allowing the smart contract to receive funds from EOA and other contracts.
The funds transfer functionality
The change of owner voting system implementation.

Implementing a smart contract owner

The nature of a smart contract that makes it not modifiable after deployment necessitates very important functionalities to be "Authorised" before access is granted. The lowest level of access grant in a smart contract is the implementation of a smart contract owner.

The owner of a smart contract is the address that deploys the smart contract to the blockchain. The solidity contract allows for the implementation of constructor. The constructor enables a black of code to be implemented first in the creation of the smart contract and only once. A variable owner of type address is created, this is a state variable and of type address. The owner is assigned the value msg.sender using the global variables available in a smart contract.

The Funds Receive functionality

A smart contract has an address , hence can receive funds and make transactions. There are a few ways a smart contract can be made to receive funds. One is by creating a "depositFund" function that is labelled payable, the other is by using a payable fall back function. One other option which was utilised in this smart contract is to use a receive functionality. The receive function differs from a fallback in that it cannot receive data, and is the first default function called when a low level payment to the smart contract is triggered.

The receive function does not access storage or make a function call, hence the 2300 gas stipend would be sufficient for the transaction. None the less, it is a better practice to use low level function call where the transaction sender attaches more gas to the send function in a contract to cater for additional cost on fund transfer to a contract.

The funds transfer functionality

the transfer functionality is a function that utilizes many require statement to ensure proper checks are made before funds are transfers.
Three require checks are made: the first ensures that the amount to be transferred is less or at most equal to the funds in the smart contract.

The second require statement checks the mapping created that allows specific addresses to be recipients of the smart contract funds. The mapping "isAllowedToSend" is used to grant permission to withdraw funds by the smart contract owner.

The third require statement ensures that the amount to be transferred to an account is less than or equals the amount the owner has previously set.

To prevent the re-entrancy attack where, as a result of excess gas provided for transactions with external contracts they can still access the source contract and try to change state variables. Following the best practice the transfer functionality interacts last with external contracts.
Firstly we deduct the amount to be transferred from the smart contract before the actual transfer transaction is made.

Transfers can be done using at leat three methods:

_address.transfer()
_address.send()
_to.call{value: _amount, gas: 100000}(payload);

The third methods is referred to as a low level call. This method is usually used when ever you have no knowledge of what address the recipients of your funds transfer. When the transfer is done to other EOA(Externally owned Addresses) then any of the methods above is safe, if the transfer is to a smart contract, then the transaction would fail if the receive or fallback functionality interacts with the contract. The reason for this failure is that basic transfer functionalities only make the stipend gas available for transactions, only low level calls can be used to include a stipulated gas cost with the transaction.

The response of a low level call, must be assigned to check if the transaction was successful.

The change of owner voting system implementation.

The smart contract implements a simple voting system that allows for change of ownership. This could easily be a useful feature when the governance of a smart contract need to be changed, or owner demise.
The voting system ensures the owner of a smart contract selects at least three guardians who have the ability to elect the next address as the smart contract owner.
As soon as an address has 3 guardians selection, then the address becomes the new smart contract owner and perform functions restricted to the smart contract owner.

There is the link to the smart contract code on Github. Feel free to reach out to me on LinkedIn.

Further articles to this would be published, deploying a smart contract to a local blockchian, deploying to a test net such as Sepolia, deploying to a layer 2 solution (ZK SNARK).