2

i'm here to ask if my project is doable or not.

I'm actually reading "Mastering Ethereum" by Andreas M. Antonopoulos, so i have some basic solidity knowledge.

I have a project:

I have a building, with floors and rooms for each floor.

My idea is to "tokenize" each element of the building in order to send it (idea similar to renting), For example:

i have 4 rooms in a single floor assigned to 2 different persons (each owns 2 rooms) and after some time someone comes and asks for the entire floor.

So the 4 tokens (room) should merge into a single token (floor) of the building (another token).

Another example:

i have an entire floor and i want to give 3 rooms (out of 5) to someone, so i have to split the floor token into the 5 rooms token.

So i have 3 kinds of token: building, floors and rooms.

I'm struggling to find some kind of solution to this problem, my idea was to manipulate the building as a single token with a struct and to create an "Authorized" contract in order to not changing the original owner of the token.

It's kinda hard to figure out how to do it with 3 different tokens (non fungible, i was thinking of erc721).

Thanks to anyone who will answer me :)

2

Take a look at ERC-1155, https://github.com/ethereum/EIPs/issues/1155.

This was designed by the Gnosis Team to address the problem of using ERC20 and ERC721 tokens in a case where when unique tokens would emerge. You can do that, and decompose/recompose according to rules to configure you will have the problem of gas cost for deploying a new contract each time.

I suspect the really challenging aspect of this isn't tokening the assets as much as defining what they represent and the method of conversion. I don't have a generic answer for that which is why it looks like the challenge, from my perspective.

Hope it helps.

  • the big problem i'm facing as you mentioned is "the method of conversion" wich is kinda hard to understand. But i'm thanking you for your answer, i'll take a look at the erc1155 to see if it's a better path to solve my problem. – D4D3 May 28 at 7:37
0

In my opinion this depends on what you want to achieve. The big question is whether you want your token(s) to follow some standard (such as ERC20 or ERC721) or not.

If you don't need your tokens to follow any standard I'd suggest just creating one (token) contract which handles all of these types - at least for a start. So one contract which knows who owns a building and who owns what inside it. You can create a flexible data structure to handle splits and mergers. Basically you can write it to behave in any way you want. This way it won't be a traditional token contract and it might be questionable whether there's 1 token or 3 different tokens, or whether it's a token contract at all. But if that's ok for you then this is probably the easiest approach.

If, however, you want your token(s) to follow some standard, things get trickier. ERC721 is probably your best option. (Or, there are probably a lot better standard suggestions around but they're not as widely accepted as ERC721.) The first problem you'll face is that you can't split/merge such tokens. So you need to first divide everything into the smallest possible unit (a square meter for example?) and distribute those. Also ERC721 doesn't inherently contain options for owning another ERC721, but nothing stops you from including such code in the contract.

  • Thanks a lot for your answer, you gave me an idea. i will think about a single contract to manage everything but it will be a "simplier" solution. (hey, it's a solution :) ) – D4D3 May 28 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.