.png)
I always thought that tokenization is one of the most interesting concepts in blockchain. Basically, tokenizing means issuing a token that are linked to a real-world asset. The link can probably be implemented in multiple ways but if I understand the legal context properly, the primary way is a regulatory framework. I will definitely be doing more research into this, but first I wanted to create something of substance that I could use as a point of departure. I went with my first idea which is short-time rentals.
The Kottage project (forgive me the name, but I don't have a large marketing budget) is focused on tokenizing short time rentals and brokering the transactions between landlords and tenants with additional room for anyone in-between.
Let's assume that Alice has several properties that she would like to rent. From her perspective, she can predict availability of the property in advance. She's interested primarily in profits that we can calculate as number of days the property is rented times the average rent. Relationships between these two factors can be complex. Bob on the other hand is interested in renting a property for his vacation in Europe. He is looking for attractive properties with a set of criteria that, among other things, include the availability in a specific period, location.
Connecting landlords and tenants based on location is easy. But how to we deal with e.g. availability and price?
My approach in handling the property availability for rentals is to decide on the most granular unit of availability. The most convenient way to handle the date & time on-chain that I found so far is to use UNIX timestamps and the @quant-finance/solidity-datetime library. In theory UNIX timestamps offer granularity of seconds and web3 part of the project supports this as a smallest unit. However, I assume in practice the practical slot would be an hour. This way the landlord and the tenant can precisely agree on the check-in and check-out times. In the initial version of this project for simplicity I'm relying on 24h hotel night so the check-in and the check-out times can occur only at the same hour of day.
We deploy a single ERC721 token contract for each property that Alice owns and authorize her as a minter for the tokens. Each token has assigned check-in and check-out date and time represented by UNIX timestamps that are held in the contract storage:
rentalPeriods mapping is responsible for tracking rentalPeriod structs for each token (hotel night) minted.
Now given this granularity it should be quite easy for Alice and Bob to agree on the rental period. Let's suppose that Alice provides availability of her apartment each day of August of 2023. Bob can decide that he'd like to rent the apartment only for the first week of August. If he will purchase relevant tokens, he gains the right to use the property in the period between the check-in time on the 1.08.2023 and the check-out time on the 7.08.2023. This right can be implemented e.g. with a smart lock that will respond to a hardware wallet containing the Bob's private key and unlock the door.
But what if Bob due to some unfortunate scheduling mishap is not able to make it for his European trip. Let's assume he would like to sell the rental right. How would he go about it?
Fortunately for Bob there are well functioning ERC721 token markets like OpenSea, Rarible, Blur, etc.. Thanks to the ERC721 standardization, he is able to list and sell his tokens on compatible markets. It might be however difficult to deal with each token individually - to list them, configure the sale or auction parameters, for the customers to buy them in batches, etc.. It might be easier to merge several hotel night tokens into one token or two tokens and list them as such. For this purpose I introduced the split and merge methods.
The KottageToken allows to merge a list of tokens into a single token. Bob can use this functionality to merge his tokens into one token representing the first week of August and list it on OpenSea as such or e.g. transfer it to his friend who will be in the neighborhood and would happily make use of it. One large token can be also split into several smaller ones over a period of time.
But there are obviously some conditions that need to be fulfilled before merging or splitting. The first one is that Bob has to own are have an owner's approval of all of the tokens that he wants to merge. The second is that the tokens that he'd like to merge need to form a sequence. It wouldn't be correct to merge only six of the seven days into a token representing the whole week. If we are e.g. missing Wednesday that could lead to a situation where Alice sold Wednesday to another person and the two would find themselves in the property on the same day. If you wondered why I brought the check-in and check-out timestamps on-chain, that's the answer - they need to be verified to confirm that a sequence of tokens can be merged together into a new one.
Similar conditions apply to splitting.
Secondary market brings very interesting functionalities for tenants and landlords alike.
Let's start with the tenant's perspective. Existence of a secondary market of availability slots means that any "unusable" time slot can be put back on the market by its owner and create a potential attractive purchase. From perspective of the current owner of the time slot it's much more reasonable to put it back on the market at a reduced price that simply not use it at all. Availability of time-slots on the secondary market might bring down the prices on the primary market because they constitute a product alternative.
From the landlord's perspective, the existence of the secondary market means that their time-slots are much more liquid. People will be much more likely to purchase time-slots if they know that they can easily sell it if they will be unable to use it. It also means that there exists potential of time-slot "investments" meaning that people with surplus capital might be interesting in purchasing large quantities of time-slots in advance with the hopes of selling some of them at higher price e.g. closer to the holiday's season and make up for any unused time-slots in the portfolio. For the landlord it means that she can easily unlock the value of her property through time-slots.
In order for the landlords to be able to mint the tokens, we need to deploy a contract that will be creating token contracts for each property. This type of contract is called a factory. Let's create a simple factory that for requested parameters (name & symbol) will deploy the KottageToken and will transfer its ownership to the landlord's wallet.
The factory is Ownable and owned by the Kottage project owner, but the createKottageToken function is not gated. Anyone can use the factory to create the KottageToken contract for its property. The onlyOwner modifier will be used in the factory to setup and implement in each deployment a fee structure that will generate revenue for its author by deducting a small percentage from each KottageToken transfer. Thanks to this, every time the token is changing hands on primary or secondary market, the author will receive royalty that she can e.g. use for further project development.
All right, let's run some tests!
We'll first test the KottageTokenFactory's fucntion for creating the new KottageToken contract:
First, we deploy the factory itself. Then, we create a TestToken with sample parameters. We double check that all properties match between the factory and a token.
Now let's move to the token itself:
First, let's mint the first token for the period of one week: 2023-07-24-2023-07-30 (please note the UNIX timestamps):
Now, let's try and split this large token into two smaller ones: 2023-07-24-2023-07-28 and 2023-07-28-2023-07-30. We'll use the following UNIX timestamps:
Splitting:
Once we split the first token, we should have two smaller ones. Then let's try and merge it back into one single token:
Now we should be back at 1 token in our balance.
Let's run the tests!
Excellent, all functional tests have passed.
To summarize, we tested the following steps:
1. we deployed the on-chain factory for the KottageToken contracts
2. we used the factory to deploy a KottageToken contract for our property
3. we minted a KottageToken for our property representing the whole week of 2023-07-24-2023-07-30
4. we split the whole week into two separate periods, 2023-07-24-2023-07-28 and 2023-07-28-2023-07-30
5. finally, we merged them back into whole
Kottage is a fun side-project, at least for now. The current version can be found here.
Currently I designed and deployed the KottageToken test contract but there is much more to do before is forms an MVP:
I've delved into the intriguing concept of tokenizing short-term rentals in my project, Kottage. In this project, I leverage the power of blockchain technology, using ERC721 tokens to signify specific time slots for property availability. These can be traded and even merged, offering an unprecedented degree of flexibility and liquidity in the rental market. I'm also exploring the exciting possibilities of a secondary market. I've still got plenty on my to-do list for Kottage, including ramping up security, developing a user-friendly interface, incorporating a fee structure, and minimizing operational costs. This adventure of mine highlights how blockchain technology could revolutionize traditional real estate transactions.
If you found this entry interesting, feel free to message me!