Spume Technical Paper

INITIAL DRAFT VERSION ~ 04/17/2022

Silas D. Marvin, B.A.
[email protected]
Beauregard G. Moody, B.A., J.D. (IP)
[email protected]

Preface

Spume is a community governed, holder-owned NFT marketplace.  Spume facilitates the non-fungible tokenization of physical and digital assets and removes brokers, banks, and other centralized authorities from unjustifiably taxing the transactions and property of individuals.

The Spume project is ambitious by nature. We are pioneering a new industry and introducing something transformational which requires careful planning. This technical paper is an ever-evolving document specifying the design, implementation, and evolution of some of the more nuanced aspects of the Spume Marketplace. We greatly appreciate any feedback, both positive and negative.

It may seem abnormal for a marketplace to focus primarily on the tokenization and trading of real estate, digital licensing, and artwork. In reality, however, all three elements follow a few common underlying themes. These are industries where the ownership of individuals is being taken advantage of, they all can benefit from tokenization on the blockchain, and they all involve property owned by individuals.  

These three themes are the core of the Spume project. Bitcoin and its contemporaries were designed to decentralize, anonymize and disintermediate central actors. The current status of any type of ownership transfer system that encompasses all of our benchmark themes either lacks or removes these initial efforts, which is the entire goal of blockchain.

 

Spume is not simply a marketplace; it is the exchange to transfer digital and physical assets on the blockchain in ways that utilize the original advantages that the blockchain intended to implement. It is holder-owned, and community governed. It is decentralized and impervious to centralized control.

Digital Licensing

This section is heavily under review and subject to change.

At this time, there are no standardized methods for bringing digital property onto the blockchain. There are several ERCs, namely ERC721 and ERC1155, that specify smart contracts representing non-fungible tokens (ERC1155 also allows fungible). The tokenization of digital property is not standardized. Currently, a token ID on the blockchain is linked to a URL, usually pointing to IPFS, and this URL stores the data associated with the token ID. Open Sea has created something of their standard for how metadata should be stored. Popular IPFS storage systems like NFT.storage have followed suit, making a pseudo standard for storing images. However, there is no standard for music, software, or other intellectual property like patents. The primary issue we face is the contracts and pseudo metadata standards we use to show the ownership of images do not extend well to real-life applications.

This section will propose a standard for metadata and an extension to the ERC721 smart contract that shows the license and rights other addresses have to use the particular digital property.

Standardized Metadata

To incorporate the digital property into applications, there must be a standardized way to store the digital property’s metadata. The current standard for digital artwork does not extend to other digital objects. Our proposal is simple, each digital object’s metadata should have at minimum the following fields:

{

    image: “URL to image, provides backward compatibility with what is done today,”

    property: “URL to digital property,”

    rightsRelease: “text document signed by the tokenizer”

}

The image field is the link to an image that can be displayed for the item. This is a standard field when creating NFT artwork for marketplaces like Open Sea. If the digital property is the image, the property field can be omitted or set to the same value.

The property field links the digital property the NFT represents ownership of. Again, when the digital property is an image, the property field can be omitted or be set to the same value.

The Rights Release field is a contract in text signed by the user tokenizing the digital asset. In doing so, the user is consenting to relinquish complete ownership and control to whoever’s wallet holds the token.

Other fields can be added as needed, but this standard should allow a uniform adoption and use of tokenized digital property.

ERC721 Extension

Our extension to the ERC721 class allows for a verifiable, on-chain method to show wallets have licenses to use digital property. As we move to a system where our identity is associated with a public key (wallet address), a way to associate rights with public keys is akin to associating rights with individuals. This licensing method can be used by various applications to verify individuals have the necessary licenses to use digital property.

Use Cases

There are a number of different use cases we see for an on-chain licensing method. Specifically, we see two situations where the licensing can be used: off-chain uses and on-chain application use.

Off-chain use would include situations where individuals buy the license to use digital property on-chain and then utilize that license off-chain. This is similar to how websites like ShutterStock and Istock operate. Where the user purchases a license through a website and then uses that property out of the enforceable jurisdiction of that website. In an off-chain situation, there is no difference between buying the license on-chain or buying the license off-chain.

On-chain use is where the value of licensing through the blockchain shines. In this situation, a user will buy the license on-chain and utilize that license on-chain. For instance, a user could buy the right to use music in their song, and an on-chain studio application could load in their licenses and allow the user to include their licensed songs. This is only one example; the actual on-chain use cases for on-chain verifiable licenses are limitless.

Extension

The extension to the ERC721 class is very simple by incorporating the licensable class.

abstract contract ERC721Licensable is ERC721 {

    event License(uint256 indexed tokenId, address indexed licensee, string uri);

    mapping(uint256 => mapping(address => string)) private _licenses;

    function _addLicense(uint256 tokenId, address licensee, string memory uri) internal{

        _licenses[tokenId][licensee] = uri;

        emit License(tokenId, licensee, uri);

    }

    function getLicense(uint256 tokenId, address licensee) public view returns (string memory){

        require(licensee != address(0), "ERC721Licensable: address zero is not a valid licensee");

        return _licenses[tokenId][licensee];

    }

}

The licensable class includes a mapping between tokenIds, addresses, and the link to the license the user holds. It also emits the License event every time a license is granted. The function “_addLicense” is private, and there is no direct way to interact with it. It is recommended that the extending class creates a function called “addLicense” that puts restrictions on the callers and then calls the “_addLicense” function.

We are discussing adding another feature to the contract above that will allow other approved Ethereum accounts to add and remove licenses. This is the same idea behind the approve function already in the standard ERC721 contract. This feature would be useful when dealing with royalties. If, for instance, royalties are not being paid as outlined in the license agreement, a monitoring contract could automatically revoke the license.

Standardized Licenses

The license URI should resolve to a json data structure containing at least these two fields:

{

    licenseId: “The id of the license type, more on this below”,

    signedLicense: “license text document signed by the licensee”

}

The licenseId is a quick way to identify the type of license the individual has. We will publish a database with a series of standardized licenses and will expand it and eventually decentralize its control. For on-chain applications that require users to have certain licenses, this greatly simplifies the way these applications can verify that users have the required license to operate. For instance, a photoshop application requiring users to have a certain license can quickly identify a standardized license by its integer id. If the license the user has is not standard, they can simply set the licenseId to -1, and the signedLicense can be examined for the details.

The signed License is the actual license agreement, only in text and signed by the licensee.

The Spume DAO

The Spume DAO is a decentralized group of individuals in charge of governing and expanding the Spume Marketplace. It is composed of two parties: Token holders and Members. Token holders are anyone who holds SPUME tokens. Members are individuals that work for the DAO; they are programmers, designers, marketers, or anyone the Token holders feel worth having as Members. The goal of the Spume DAO is to equip Members with funds and incentives to develop the Marketplace while giving Token holders voting control over the development they do.

An effective government exists within a system of checks and balances. The individual Token holders must have power over the Members, or the Members may digress into self-seeking development. The goal of the Spume DAO is to create a true democratic republic where the individual SPUME token holders have and retain power over the DAO and Marketplace.

To be clear, we are proposing a completely new form of decentralized governance, utilizing a hybrid of permissionless and permissoned proposals that, unlike anything before it, use the blockchain to give token holders absolute power.

The DAO Treasury

The DAO owns 20,000,000 SPUME tokens, 20% of the total supply of SPUME. This means the DAO is entitled to 20% of all dividends that the Spume Marketplace produces (see Revenue Sharing section). The DAO’s tokens will be locked in a smart contract perpetually staked and generating dividends. This is atypical for DAOs. Namely, to secure funding, most DAOs will sell or use their tokens, both situations leading to a net loss for the DAO and an unsustainable model. In our system, our DAO will never sell or transfer its SPUME tokens, being funded instead by the dividends the Spume marketplace produces. The dividends the DAO receives from its SPUME tokens will be sent to a smart contract controlled by the DAO. The DAO treasury Members will control the funds in that smart contract for Holders and Members.

As stated before, the Spume DAO will consist of two parties: Token holders and Members. Token holders are anyone who holds SPUME tokens. Members are individuals that work for the DAO; they can be programmers, designers, marketers, or anyone the Token holders feel worth having as Members.

Token Holders

Token holders are anyone who holds SPUME tokens. For a Token holder to be eligible to vote, they must stake their SPUME tokens through spume.io. As mentioned in the revenue section, staking SPUME tokens also enables them to share in the revenue of the Spume Marketplace.

Members

Members are individuals that work for the DAO. To become a Member, Token holders must hold an election on-chain for a specific Member role. Member’s public keys (i.e., wallet addresses) are stored in mapping in the DAO smart contract. When a Member is elected, his public key is automatically added with his associated role. Likewise, his public key is automatically removed when a Member is removed. The mapping between public keys and roles represents Membership. Anyone who claims to be a member must prove that their public key is associated with a non-zero role in the Member’s mapping.

Specific Member Roles

Members handle the day-to-day operations of the DAO, including the funds in the DAO treasury. Not all members have rights to handle funds; instead, within the DAO, there are specific roles that allow certain Members to work together to spend the funds. Initially, there will be a treasury role assigned to three different members of the DAO. Funds are only removed when each treasury Member submits an individual transaction specifying the amount and address to send funds to. It is the role of the treasury Members to pay other Members according to what the Token holders agree on. As mentioned later, the Token holders have the ability to freeze the funds or add and remove treasury Members as they see fit. This means that Token holders can elect Members who will follow through with their desires. When treasury Members do not follow Token holders' wishes, the Token holders can simply remove them and elect new treasurers.

There will be no other specific member roles at the inception of the DAO. However, all contracts will be written with extreme flexibility allowing for the creation of unique actions requiring new roles.

Voting

The majority of DAOs that include on-chain voting simply weigh an individual's vote by the number of tokens they hold. This leads to situations where one individual’s vote is worth the weight of 10,000 or 100,000 smaller holders. The aforementioned situation is not a true democratic republic but one where the largest holders have extreme power over the DAO. The goal is to treat the Token holder’s votes equally, regardless of the number of tokens a Token holder has. A naive approach may simply disregard the total tokens the person voting has and only confirm they own at least 1 SPUME token. This method is highly vulnerable to attacks where large token holders divide their tokens among many wallets (whale attacks). If we simply require Token holders to hold at least 50 SPUME tokens before they can vote, we drastically reduce the power of whale attacks.

Example:

Let’s assume there are 100 SPUME token holders with 50 SPUME tokens. Let’s also assume there is 1 large whale holder with 2,500 SPUME tokens. In this situation, if we allowed anyone with 1+ SPUME tokens to vote, in a situation where the whale is voting entirely against the other SPUME token holders, the whale can divide his tokens among 2,500 wallets (25 times the voting power of the other Token holders). Meaning that he can pass any motion and proposal he wants. In our approach, where we require voting Token holders to have at least 50 SPUME tokens, even if the whale were to divide his tokens amongst wallets, he would only be able to cast 50 votes, meaning the smaller holders still retain power.

The exact number of SPUME tokens required to vote will be variable and controlled by the DAO Members. In an ideal world, it should be centered around the median tokens held by SPUME holders. However, there lies the possibility of malevolent parties trying to manipulate the median count by spreading their tokens between wallets, then the actual amount required will sit above the median.

To vote, Token holders cannot simply hold SPUME tokens; they must be staking them through spume.io. This will allow them to share in the rewards of the Spume Marketplace. Still, it also allows the intelligent voting contract to accurately track total holders capable of voting, which will be used when voting on motions. More on this in the next section.

More info on whale attacks and other potential attack points in the Vulnerabilities of the DAO section.

Permissionless and Permissioned Proposals

The Members and Token holders coexist in a strange balance. Because the Token holders are those invested and holding SPUME tokens, we believe they should have the power to choose the direction the Spume Marketplace and DAO take. In contrast, the Members work for the DAO and are in charge of implementing all changes proposed by Token holders. In such a system, it is possible that there may arise disagreements between the Token holders and the Members. In these situations, The Token holders must have some way to strongly motivate the Members to follow the Token holders and not their own inclinations.

When the Token holders vote on a proposal, that proposal would be automatically applied through the blockchain without requiring human intervention. Unfortunately, because we are allowing Token holders to have complete control over the entire marketplace, it is impossible to hard code every possible proposal they may enact. Instead, we need to devise a system where Members are highly motivated to apply any proposal Token holders vote on quickly. The system we are proposing is a permissionless and permissioned hybrid where permissionless means proposals Token holders agree on are automatically applied on the chain, and permissioned means Members of the DAO are required to apply the agreed-upon proposals.

Common Permissionless Proposals Include:

Permissioned Proposals Include:

The Spume DAO contract will include three common permissionless proposals Token holders can vote upon: vote to add a new DAO Member and hold an election for this new Member, remove a DAO Member, and freeze or unfreeze the funds of the DAO. Between these three permissionless proposals, the Token holders will have complete control over the Members, and in turn, over the Spume Marketplace.

A few additional permissionless proposals that the average Token holder will not typically propose a motion for. These include:

Motions for these proposals can be proposed by any Token holder but typically will only be proposed by Token holders who are also Members. Specifically, the Members on the dev teams will use these when/if they ever need to update the governance contract, staking contract, or the min and max range for tokens required for voting. These motions and proposals go through the same process as every other motion and proposal outlined below. These proposals are necessary so the DAO cannot arbitrarily change the governance, staking contract, or restrict voting without the consent of the Token holders.

While permissionless proposals exist to give the Token holders control over the DAO, permissioned proposals exist to give the Token holders control over everything else. For instance, Token holders can use permissioned proposals to propose a new site design or an extension to the Marketplace. Permissioned proposals can include propositions to do absolutely anything and are an essential part of giving the Token holders absolute control. There is an example of a permissionless proposal process in the section below.

Motions

Token holders should not be dependent on the Members to organize and vote on proposals. For instance, a Member of the DAO should not have to initiate a proposal to remove themself or another Member. Instead the individual Token holders should be able to initiate any proposal at any time. With this ideology, one major problem arises: how are times and dates for votes proposed and agreed upon? The solution we have devised is to use motions. Before a vote on any proposal takes place, a pre-vote we will call motions must occur. Any Token holders can initiate a motion, the universally required fields are the proposal to vote on, and the time the voting will start. Motions last for 72 hours, and in those 72 hours. Token holders can vote on whether to move forward with the motion or close the motion. In order for the motion to move forward it must receive +5% of all Token holders votes. To be specific, Token holders can either vote for or against the motion; if they vote for it, it adds one to the vote count. If they vote against, it subtracts one from the vote count. If there are 10,000 Token holders capable of voting, for a motion to move forward, it must end the 72-hour period with +500 votes.

Example:

Let us say that several Token holders have been discussing on Discord the need for another Member to work on Spume’s marketing. In this situation, one of the Token holders can create the motion to hold a vote to add a new DAO member and hold an election. After making the motion, the other Token holders can agree with the move, and if the 72-hour period ends with a +5% vote count, on the date specified in the move, a vote to add a new DAO member and hold an election will occur.

There will be a section on Spume’s site showing all current motions and votes in practice. Token holders will be free to vote on any of them any way they see fit.

Vote to add a new DAO member and hold an election

The vote to add a new DAO member and hold an election is imperative to creating a marketplace owned by the Token holders. This vote will be used when Token holders decide they need a new member for the DAO. It should be noted that when the motion is created to elect a new DAO Member, in addition to the motion holding the date the election will take place, the motion will also include the role the Member will have if elected.

Example Timeline:

  1. Create Motion
  1. A motion to vote to add a new DAO Member and hold an election is created
  1. Motion Passes and Individuals Add their Name to the Election
  1. When the motion passes, individuals can add themselves as candidates for the election all the way until the voting period ends
  1. Vote Whether to Add a New DAO Member
  1. On the date the motion specifies, a vote to decide whether to actually hold an election for a new DAO member begins. This is a standard yes, no, majority vote.
  1. Vote on Who to Add
  1. After the vote to add a new DAO member passes, the actual election immediately begins and runs for 24 hours
  2. The candidate that ends this 24 hour period with the most votes wins and is added to the DAO with the role specified in the motion

Remove a DAO Member

The vote to remove a DAO Member gives Token holders direct control over the DAO Members. For instance, the Token holders find that a specific DAO Member(s) is/are no longer needed, or is/are not performing as expected, they can vote to remove them. In addition to the date the vote will take place, the motion must also include the member(s) they are removing.

Example Timeline:

  1. Create Motion
  1. A motion to vote to remove a DAO Member(s) is created
  1. Motion Passes
  1. After the motion passes, the vote to remove the Member(s) will commence on the date specified in the motion
  1. Vote to Remove Members
  1. This is a standard yes, no, majority vote. If it passes the Member(s) specified are removed, if it fails, they stay

Freeze or Unfreeze the Funds of the DAO

It is essential that Token holders can control and punish the DAO. If for instance, the Members are failing to execute a permissioned proposal the Token holders voted on, the Token holders can permissonlessly freeze the funds of the DAO, effectively cutting out payment for DOA members. This has the same effect as removing all Members with the treasurer role, but may prove more useful when the conflict is not directly with the treasures.

Example Timeline:

  1. Create Motion
  1. A motion to freeze or unfreeze the funds of the DAO is created
  1. Motion Passes
  1. After the motion passes, the vote to freeze of unfreeze the DAO’s funds will commence on the date specified in the motion
  1. Vote to Freeze or Unfreeze DAO Funds
  1. This is a standard yes, no, majority vote. If this vote passes the DAO’s funds will be frozen or unfrozen according to the motion

Permissioned Proposals

There are no limits to what Token holders can use permissionles proposals for. We predict, most often they will be used to propose new site designs or extensions to the Marketplace, but in practice, they can be used to extend and alter everything pertaining to the DAO.

Example Permissioned Proposal:

  1. Create Motion
  1. A motion to renovate the homage page of the Spume Marketplace to include this month's most viewed NFTs is created
  1. Motion Passes
  1. After the motion passes, the vote for the proposal will commence on the date specified in the motion
  1. Vote to Pass the Proposal
  1. This is a standard yes, no, majority vote. If this vote passes the DAO will implement the proposal to include this months most viewed NFTs on the homepage

Vulnerabilities of the DAO

The goal of the DAO is to create a true democratic republic where Token holders have complete control over the Spume Marketplace, and each Token holder’s vote carries the same weight. The methods we have outlined above are the best way to create this government, but there are still vulnerabilities. Specifically, there are two angles of attack: Member attacks, and Token holders attacks. Token holders attacks are attacks done by Token holders to manipulate the voting process and gain control of the DAO. Member attacks are attacks done by the Members to lock the Token holders out of controlling the DAO.

Token Holder Attacks

Token holders only have the ability to create and vote on motions and proposals. There is no way for them to maliciously change variables or settings in any of the smart contracts involved in the governance and voting process, but there is room for them to try and game the voting system. As specified above, large Token holders are capable of what we call “whale attacks”, and despite our best efforts, by requiring voting Token holders to stake a minimum number of tokens, we can only reduce the impact of whale attacks, not completely nullify them. In the endeavor to explore the vulnerabilities of the DAO system, what percentage of the total SPUME token supply would a whale attacker need to pass his own motions and proposals?

This is not a standalone question. It becomes dependent on the number of voting Token holders and minimum SPUME tokens required to vote. Where the greater the number of voting Token holders and minimum SPUME tokens required to vote, the more secure the DAO is. For this situation, we will assume a fixed 50 SPUME tokens required to vote. The higher this number, the higher the security of the DAO (to an extent), but also the more exclusivity involved in the voting process.

If the minimum number of SPUME tokens required to vote is 50 tokens, then the tokens required by a whale attack is 50x the total number of Token holders.

Votable Token Holders Count

Tokens Required for Whale Attack

Percent of Token Supply

10,000

500,000

0.5%

100,000

5,000,000

5.0%

1,000,000

50,000,000

50%

Even with only 10,000 votable Token holders, it would require 500,000 SPUME tokens, 0.5% of the total supply, to perform a Whale Attack. Once again raising the number of SPUME tokens required to vote directly affects the power of whale attacks. For instance, if the DAO Members see a whale attack happening, they can automatically update the SPUME tokens required for voting. More on the DAO’s ability to update the required SPUME tokens for voting and the checks and balances imposed on this in the next section.

Member Attacks

In an ideal world, the Members will always follow any permissioned proposals the Token holders vote on. However, there may be times where malevolent Members come into power and may try to remove the Token holders influence, meaning Token holders will lack any power to freeze the funds of the DAO, or remove Members. To understand the power Members may have to do this, it is essential to know the power Members have over the governing smart contracts. The simple answer is not much.

Everything members of the DAO can change or do to the DAO smart contract and staking contract without a motion and vote from Token holders:

  1. If not frozen, the treasurers of the DAO can remove funds from the DAO contract
  2. Certain members of the DAO can raise the minimum amount of SPUME tokens required for a Token holders to have a vote

While it at first seems extremely dangerous that treasures can remove and spend funds from the DAO contract, it is not relatively safe. There are two reasons why this is true: one, there will never be an immense amount of funds in the DAO smart contract, and two: the funds will always refill as the DAO smart contract gets replenished by staking its 20,000,000 SPUME tokens. The headache caused by allowing treasury Members control over the funds without checks by the Token holders is far less than the downside of allowing them control. As the DAO evolves, if the Token holders want to create a bank of DAO funds, then a new contract could be created holding the DAO reserves that requires a motion and vote from the Token holders to move.

Certain members can raise the minimum amount of SPUME tokens required for a token holder to have a vote, but they can only do so within a limited range. This range will initially be 50 to 500, meaning Members could not raise the minimum amount to vote so high, that only 10 whales could vote, nor can they lower it to the point a whale attack could occur. As mentioned previously, it is imperative we give the Members some free range to raise the minimum SPUME tokens required for voting so they can combat whale attacks. Token holders have a permissionless proposal that allows them to update this range as they see fit.

The DAO governance contract and staking contract will both be upgradeable, meaning they will have individual modules that will shift between different contracts, but as mentioned previously, DAO Members cannot upgrade these contracts without a vote from the Token holders.

In reality, Members are very limited in the power they have to cut off Token holders from executing any permissionless proposals, meaning Token holders really do have the power to automatically add, remove, or freeze the funds of the DAO whenever they want, even against the wishes of the Members.

Limitations of the DAO

Unfortunately, there are some limitations to the DAO. While the roles of the Members of the DAO are controlled on-chain, completely under the desires of the Token holders, there are some off-chain components the DAO requires that pose security risks.

Spume is a Marketplace that requires servers, databases, and a number of other services that require off-chain logins like emails. Let’s assume the Token holders submit a proposal the Members refuse to implement. The rift between Token holders and Members becomes so large that the Token holders vote to remove the offending Members, and elect new ones. While the new Members are official Members of the DAO, for them to effectively work and update the Marketplace, they need access to the aforementioned off-chain logins. It is possible that the old Members may refuse login access to the new Members, causing something of a stalemate. Of course this only causes a minor setback for the new Members, as they could fork Spume and with the funding of the DAO set up new databases and servers with little work, but nevertheless, it does represent a limitation.

Revenue Sharing

All revenue generated from Spume’s Marketplace’s transaction fees will be given directly back to SPUME token holders proportional to the amount of SPUME the individuals have. We chose this revenue sharing model for two specific reasons. One, sharing fees with Token holders (individuals who hold SPUME tokens) will incentive participation in the governance of the Spume DAO. Two, because the DAO owns 20% of the total tokens, they are obligated to 20% of all revenue the Spume marketplace generates, providing continual funding for the DAO.

Marketplace transaction fees are flexible and can be voted on by Token holders of the DAO. To provide an example for revenue sharing lets assume Spume just launched, only trades NFT artwork, charges a flat 2.5% fee, and is 1/10th the size of Open Sea. In this scenario Spume will trade roughly $7.6 million in NFT volume per day, redistributing $190,000 per day to SPUME token holders. To be eligible to share in redistributed rewards, a holder's SPUME tokens must be staked. Assuming 35% of SPUME tokens are staked, each SPUME token will reward its holder with $0.0054 per day.

As mentioned earlier, the DAO’s SPUME tokens will be locked in a smart contract perpetually staked and sharing in the revenue. If the DAO wants to update the staking contract, the Token holders will have to create a motion and approve it with a vote.

Physical Property Tokenization

Spume was crafted to be a disruptor in not only the blockchain industry, but to use blockchain technology to be a disruptor in off-chain markets and industries. There are a few key amenities that every human on the planet requires for basic existence. The Spume team strategically decided to select real estate for its first physical property integration for a multitude of reasons but mainly because there are many areas that could and should be improved upon in order to make real estate transactions faster, safer and more affordable for the end consumer. Spume understands the disruption that our new and improved transactional process will have on intermediary industries within real estate such as: real estate agents, escrow services, and title companies.

However, innovation typically comes at a cost for multiple parties who are not adding enough value or can be easily replaced by technology, as the world has seen in the past.This section of our technical paper will focus on the tokenization of physical, real-world assets.

Our first foundational asset that we will be integrating into Spume’s tradable assets is real estate. Specifically, residential homes and vacant land (commercial properties will be integrated in future months). In this section, we will dissect the issues that exist in the current off chain process and how Spume’s platform intends to alleviate the referenced issues. The current process that we have developed, our future direction, and additional, upcoming applications will be addressed in this section.

Spume’s overarching goal is to use non-fungible tokens on the blockchain to identify true, unalterable ownership for both digital and physical assets, as well as facilitate the buying and selling of said properties. Our mission behind this facilitation and tokenization of real world property, such as real estate, is to remove intermediaries and middlemen. In result, making the process more efficient and cost effective. By decreasing costs for the end consumers, this will make housing more affordable and accessible to the everyday individual.

Our smart contract process is being crafted around the current, existing legal system instead of waiting for legislation to catch up with blockchain technology. Our tokenization protocols for physical land assets will make the liquidity of real estate be measured in minutes or hours, instead of weeks or months; it will turn four or five necessary middlemen into one.

Advantages of On-Chain Physical Property Transactional Processes

Some of the most apparent problems with the current real estate transactional system lie in the fact that there are simply too many unnecessary middlemen and intermediaries involved. However, being a future-based and progression focused project, rather than examine the problems of the current system, our technical paper will focus on the advantages that the Spume marketplace and platform will bring to the market and specifically everyday homebuyers and sellers.

The first advantage of using Spume’s real estate model versus the traditional transactional model is that realtor fees will be nonexistent. Reasonable justification for real estate agents to claim four to six percent of an individual's largest asset has yet to be discovered by the Spume Team. This percentage of the home sale that is typically taken by real estate agents, will now be returned back to the seller by using Spume’s on-chain real estate process. Since users will be able to list their real estate themselves in an efficient and fair manner, and have access to equal and fair marketing through Spume’s real estate NFT marketplace, this will remove basically any defensible value that a real estate agent adds to a transaction.

With a real estate transaction, you have a massive amount of paperwork to sign and most likely you won’t understand 90% of what you sign. There is the initial contract with the realtor, and at closing an individual needs to physically show up at a title company or an attorney's office to sign a large binder of papers. A real estate transaction would be little to no paperwork. Additionally, real estate agents tend to argue that their value rests in their ability to complete the local and state documentation that is required when real estate ownership is transferred between parties. To address this value claim and provide a substitution, Spume’s real estate model will utilize what is referred to as Quit Claim Deeds (QCDs), as well as Limited Liability Companies (LLCs); this instrument of ownership transferring can be found in all fifty of the United States of America where Spume will initiate its real estate operation. QCDs and LLCs will be used to minimize paperwork required for the real estate transactions and also to speed up the transfer of ownership with local municipalities. Essentially, QCDs LLCs are the most time efficient and cost effective instrument to assist Spume’s on-chain process in complying with local and state laws within the United States of America (more information on the application of QCDs and LLCs will be provided in subsequent sections).

Additionally, a major advantage for user to utilize Spume’s real estate platform, is that there would be no title company fees. Title companies or appointed attorneys can lead to closing costs that usually assign an inflated list of associated costs, from filing fees to paper copies, and are rarely bound by what they can charge the seller. By using LLCs and QCDs, the off-chain ownership of the real estate would never be transferred or need to be recorded; our process simply changes the ownership of the entity that controls and owns the property through the LLC’s bylaws that Spume’s real estate and legal team are handcrafting to abide by all state and national laws of the United States of America. Essentially, the LLC will have a clause in its Articles of Organization stating that whomever owns “X” non-fungible token on the Ethereum blockchain owns and has full rights to and control of the off-chain legal entity (refer to [VI4] for a visual example of this documentation).

Tokenizing physical property brings the possibility for decentralized finance and real estate to mix. For instance, instead of traditional bank mortgages, there could be a DAO formed for the decentralized funding of mortgages. Another example would be on-chain loans backed by real estate. The possibilities created by combining decentralized finance and real estate are endless, and will greatly benefit individuals. Specifically, funds no longer have to be borrowed from banks, paid back to banks, and then loaned back to individuals. Instead, funds can be borrowed from individuals, and paid directly back to individuals, without the taxing intermediary of a bank.

[VI4] Visual, Unrefined Example of the Standard LLC’s Bi Laws/Articles of Organization that Spume will Utilize:

Phase One of the Spume Real Estate Process

When a property owner wishes to list their property for sale as a non-fungible token, on Spume’s marketplace, the owner(s) will submit their property details via the submission form on our NFT real estate dashboard in their marketplace account. Information required will be far simpler than the typical required information. Required information will include but is not limited to 1) address of the property 2) name of the entity or individual who owns the property 3) whether or not the property has a lien attached to it 4) a recent, legally accepted inspection report 5) a recent, legally accepted title report. Once this information is gathered, Spume’s legal team will examine the property’s eligibility to be listed on the Spume marketplace.*

*Note: Initially, one reason for denial onto the Spume marketplace, will be contingent upon whether the real estate has a lien or if the registered owners holds the title of property free and clear. This qualification is necessary in order to align with Spume’s promises of speed, cost effectiveness, and minimal paperwork. In the future, integration of community funded mortgages and crowdfunding (referenced but not expanded upon two paragraphs above) to replace or eliminate traditional offchain liens will be the next step (more detail on this topic in the following version of the technical paper).

It is of utmost importance to recognize the necessity for Spume’s necessary intervention in the application and verification process of onboarding physical real estate applications. Regardless of how the system is constructed, there currently is not an accurate, national, and/or unwaveringly up to date database to construct an automated smart contract system from when it comes to real-world inspections and title reports. This level of centralization and mediation is still ridiculously low on the relativity scale when compared to the current process. As our proof of concept is solidified and local municipalities advance with new information databases and tracking systems, the goal is to remove Spume’s mediation proportionately.

To continue with Spume’s phase one process, once the onboarding process is complete and ownership is verified, there will be an instructional step by step process sent to the applicant detailing how to use a quit claim deed to transfer ownership of their real property into an standard disregarded entity limited liability company in the state of Wyoming. For our proof of concept in the United States, Wyoming was chosen to be the standard for all LLCs because its crypto friendly regulations, ease of incorporation, and privacy laws are significantly better than any other state. Spume will provide a list of legal councils that have already been vetted and are aware of the specific quit claim deed and LLC process that Spume’s platform will require.

Once the property is legally claimed by the LLC, which will take, in most cases, a matter of days, the Spume assigned non-fungible token that now controls the LLC’s shares and subsequently the property will be issued to the seller. This transfer of the non-fungible token that is referenced as the owner in the freshly created LLC, will signify the official on-chain onboarding of a physical asset. From this point forward, the seller will be able to list and sell their home on Spume’s real estate marketplace.

Photographs, inspection reports, title reports, and LLC information will be directly tied to the non-fungible token, starting at its inception either through metadata, or verifiable credentials. This information will always be transparent, even further down the transaction line, which will remove the possibility of future sellers being able to hide faults or past problems. Having this information easily accessible will save buyers hours in due diligence by eliminating calls to the title company and trips to the courthouse to pull records, amongst other burdening tasks.

Now that this real property is owned and controlled by whichever individual or entity can prove ownership of the non-fungible token, it can be easily bought and sold without real estate agents, signing paperworks, escrow services holding funds, or title companies registering a new owner. The state of Wyoming will recognize this ownership and give individuals the ability to pay bills as the owner of the LLC, even in other states where the LLCs own property. This is truly the catalyst that removes middlemen, saves time for the end consumer, and ultimately saves both the buyer and seller a significant amount of equity in their largest asset.

The Technical Details of On-Chain Tokenization

The process of tokenizing real estate is actually quite simple. Just like any other NFT, the LLC information, title, and other relevant details of the property will all be stored in the NFT’s metadata, and publicly available on IPFS. Our implementation will only require one extension to the standard ERC721 smart contract, a safeguard against transferring the real estate to the wrong address. Specifically, there will be a number of different individuals (at least 3) the DAO appoints, and together these members can submit a transaction that has the power to transfer the ownership of any token in the contract to a specific address. In a situation where an individual has accidentally sent the house to the wrong address, the individual could appeal to the DAO, and the token could be recovered. The feature allowing the DAO to recover mis-sent NFTs is still being discussed. Whether, and how, it will be implemented is undecided.

With the system of on-chain transacting, there arises need to know off-chain information. The on-chain information, pictures of the real estate or whatnot, may be outdated or maliciously deceiving. There must be a way to submit a transaction on-chain requesting for verified information about an off-chain asset. The solution we have is simple.

We will create a smart contract, allowing individuals to submit a transaction that contains a request for off-chain information and payment for aggregating that off-chain information. When the transaction requesting for off-chain information is submitted, the payment is stored in the contract, and an event is emitted. The emitted event is read by our off-chain system, and a number of individuals we have approved will have a job-board like interface to fulfill requests. Any approved individual will be able to accept and fulfill applicable jobs. When the approved individual has acquired the requested information, they submit a transaction to the smart contract that claims the payment and includes the uri of the uploaded information on IPFS. Stored at the uri is the verifiable credential, containing the requested information issued by the individual who fulfilled the job.

Initially this system will be used primarily for inspection reports on houses, but can be extended into many different fields. A simple example: an individual is interested in purchasing a house on Spume’s Marketplace (the buyer). The buyer views the listing and sees an outdated inspection report. The buyer messages the seller asking the seller to provide a newer inspection report. The seller submits a transaction requesting for an inspection and payment for the inspection through Spume’s site. Parties we have verified to be a licensed inspector accepts the job, inspects the house, issues a verifiable credential outlining the inspection for the real estate NFT, and gets paid. It is a simple yet extremely flexible model.

We will be using Spruce’s system which is backed by the Ethereum foundation, to handle decentralized identifiers and verifiable credentials.

https://www.spruceid.com/

Verifiable credentials have been highly researched and are quickly becoming standard use. More information on them can be found at the following link. https://www.w3.org/TR/vc-data-model/

Conclusion and Future Revisions

Overall, this technical paper for the Spume project is still in its infancy. Our team will actively be configuring new and improved attributes to our project’s processes and systems. The Spume Team will adjust this document accordingly as our research progresses in these previously discussed fields; additionally, adjustments will be made to assure Spume’s system is complying with international, federal, and state regulations when it comes to our physical property applications. Although our digital licensing and art marketplaces can be used globally with relative ease, our physical property tokenization process will be constantly adjusting as we expand inside and outside of the United States in order to specifically conform to unfamiliar jurisdiction’s ownership laws and regulations.