The Mundo Digital Real Estate Marketplace aims to drive digital inclusion through the digitization of real estate records, enabling international transactions in the real estate sector. The digitization process is semi-automated, enabling users of the Mundo Digital application to acquire their digital version of the real estate record.
To run the smart contract, you must have the following:
- A Web3 wallet 💼
- Gas tokens to pay network fees ⛽
In addition to the requirements outlined in the "Requirements" section of this README, the real estate records digitization process also requires the collection of the following information and documents:
Categoria | Documento | Descrição |
---|---|---|
Informações pessoais: | Nome completo | Nome completo do proprietário |
Data de nascimento | Data de nascimento do proprietário | |
CPF | Cadastro de Pessoa Física do proprietário | |
RG | Registro Geral do proprietário | |
Nacionalidade | Nacionalidade do proprietário | |
Estado civil | Estado civil do proprietário | |
Comprovante de residência: | Conta de água | Comprovante de residência - água |
Conta de luz | Comprovante de residência - luz | |
Conta de gás | Comprovante de residência - gás | |
IPTU: | Comprovante de pagamento do IPTU | Comprovante de pagamento do Imposto sobre a Propriedade Territorial Urbana |
Ônus reais: | Comprovante de ônus reais | Documento que comprova ônus reais |
Planta topográfica do lote: | Documento que representa a forma e as dimensões do lote | Planta topográfica do lote |
Planta arquitetônica do imóvel: | Documento que representa a distribuição interna do imóvel | Planta arquitetônica do imóvel |
Planta de zoneamento: | Documento que representa a divisão de uma área urbana em zonas | Planta de zoneamento |
Escritura: | Escritura | Documento público que registra a transferência de propriedade de um imóvel |
Fotos do imóvel: | Fotos do imóvel | Fotos do imóvel para ilustrar e facilitar a identificação do imóvel |
The project features a Solidity contract that serves as a decentralized marketplace for non-fungible tokens (NFTs), offering a number of robust features:
-
Decentralized Creation of NFTs:
- Users can easily create their own NFTs in a decentralized way, providing autonomy in generating exclusive content.
-
Buying and selling NFTs:
- Facilitates peer-to-peer trading of NFTs, allowing users to exchange digital assets in a secure and transparent manner.
-
Decentralized Auctions:
- Offers the functionality to create auctions for NFTs, enabling users to accept bids in a decentralized and transparent environment.
Mundo Digital -
Proprietários
Mundo Digital -
Localização
Mundo Digital -
Prefeitura e Cartório
Mundo Digital -
Profissionais
Mundo Digital -
Imóvel
Mundo Digital -
Plano Arquitetônico
Mundo Digital -
Plano Topográfico
Mundo Digital -
Plano de Zoneamneto
Presentation with description of the ERC721 and ERC1155 smart contract with its functions for nft marketplace.
The abi contract is in DigitalWorld.abi
. It is the abi of the implementation contract.
Interaction with DWorld is done at the proxy address at 0x00000000000000000000000000000000000
. To see
https://etherscan.io/token/0x0000000000000000000 for live on-chain details and the section on bytecode verification below.
Digital World (DWorld) is an ERC721 and ERC 1155 token that is minted and burned centrally by ASPPIBRA-DAO, representing the trusted party backing the token in US dollars.
DWorld's public interface is ERC721 and ERC1155 interface specified by EIP-20.
name()
symbol()
decimals()
totalSupply()
balanceOf(address who)
allowance(address owner, address spender)
transfer(address to, uint256 value)
approve(address spender, uint256 value)
transferFrom(address from, address to, uint256 value)
event Transfer(address indexed from, address indexed to, uint256 value)
event Approval(address indexed owner, address indexed spender, uint256 value)
Typical interaction with the contract will use transfer
to move the token as payment.
Additionally, a pattern involving approve
and transferFrom
can be used to allow another
address to move tokens from your address to a third party without the need for the middleperson
to custody the tokens, such as in the 0x protocol.
There is a well known gotcha involving the ERC20 approve
method. The problem occurs when the owner decides
to change the allowance of a spender that already has an allowance. If the spender sends a transferFrom
transaction at a similar time that the owner sends the new approve
transaction
and the transferFrom
by the spender goes through first, then the spender gets to use the
original allowance, and also get approved for the intended new allowance.
The recommended mitigation in cases where the owner does not trust the spender is to first set the allowance to zero before setting it to a new amount, checking that the allowance was not spent before sending the new approval transaction. Note, however, that any allowance change is subject to front-running, which is as simple as watching the mempool for certain transactions and then offering a higher gas price to get another transaction mined onto the blockchain more quickly.
- Description: Any user can create a new token.
- How to Use: Call the
mint
function by providing a metadata URI and paying a fee if necessary. - Function:
mint(string memory uri) public payable
- Description: Allows users to see all token IDs that a given address has.
- How to Use: Use the
tokenIdsOfOwner
function passing the owner's address. - Function:
tokenIdsOfOwner(address _owner) public view returns (uint256[] memory)
- Description: Allows you to obtain the URI of the metadata of a specific token.
- How to Use: Call the
tokenURI
function with the ID of the desired token. - Function:
tokenURI(uint256 tokenId) public view returns (string memory)
- Description: Allows you to check who created a specific token.
- How to Use: Use the
creatorOf
function passing the token ID. - Function:
creatorOf(uint tokenId) public view returns (address)
- Description: Users can transfer tokens between addresses.
- How to Use: Use the
transferFrom
orsafeTransferFrom
functions (with or without additional data). - Functions:
transferFrom(address from, address to, uint256 tokenId) public
safeTransferFrom(address from, address to, uint256 tokenId) public
safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public
- Description: Users can authorize other addresses to transfer their specific tokens or all of their tokens.
- How to Use: Call the
approve
orsetApprovalForAll
functions. - Functions:
approve(address to, uint256 tokenId) public
setApprovalForAll(address operator, bool approved) public
- Description: Allows you to check who is approved to transfer a specific token or all tokens from an owner.
- How to Use: Use the
getApproved
orisApprovedForAll
functions. - Functions:
getApproved(uint256 tokenId) public view returns (address)
isApprovedForAll(address owner, address operator) public view returns (bool)
- Description: The token owner can update the token metadata.
- How to Use: Call the
setTokenURI
function providing the token ID and the new URI. - Function:
setTokenURI(uint256 tokenId, string memory uri) public
- Description: Used to interact with ecosystem governance or proposals.
- How to Use: Depends on the specific implementation of governance in the contract, usually involving voting functions.
- Function: Dependent on the specific governance contract, which is not detailed here.
These functions enable a wide range of interactions with NFT tokens, from creation to transfer and participation in ecosystem governance. Make sure you understand the permissions and restrictions associated with each role before using them.
For some specific cases, the total supply of NFTs is guaranteed by securities held in reserve at ASPPIBRA-DAO. A single address, called supplyController
, has the authority to mint and burn tokens. This process is based on the real movement of money in and out of the reserve, according to requests for the purchase and redemption of NFTs.
supplyController()
: Returns the current address of the supply controller.
SupplyIncreased(address indexed to, uint256 value)
: Emits an event when the supply of NFTs is increased.SupplyDecreased(address indexed from, uint256 value)
: Emits an event when the supply of NFTs is reduced.SupplyControllerSet(address indexed oldSupplyController, address indexed newSupplyController)
: Emits an event when the supply controller is changed.
- Supply Increase: When new funds are added to the reserve,
supplyController
mints new NFTs, increasing the total in circulation. - Supply Reduction: When NFTs are redeemed for funds,
supplyController
burns these tokens, reducing the total supply.
In the event of a critical security threat, ASPPIBRA-DAO has the ability to pause all NFT token transfers and approvals. This functionality is managed by an owner
role, as implemented by the OpenZeppelin standards Ownable and Pausable .
- Emergency Situation: If a critical vulnerability is discovered, the pause function can be activated to prevent malicious movements until the situation is resolved.
To comply with regulatory requirements, we have introduced an asset protection function that allows you to freeze or seize the assets of a criminal party when required by law, such as by court order or other legal process.
assetProtectionRole
: This role can freeze and unfreeze NFTs from any address on the blockchain and clear the balance of a frozen address, allowing authorities to confiscate the assets.isFrozen(address who)
: Checks if an address is frozen.
- Asset Freezing: If an address is identified as belonging to a criminal entity,
assetProtectionRole
can freeze NFTs from that address, preventing any transfer.
To facilitate contract updating on the immutable blockchain, we follow a delegation pattern with two contracts: a proxy contract that represents the token and an implementation contract that contains the token logic.
Delegation uses delegatecall
, executing the implementation contract code in the context of the proxy store. This allows you to change the implementation contract without changing the proxy contract data or address.
- Proxy Used: AdminUpgradeabilityProxy from ZeppelinOS.
The implementation contract only handles the logic of the non-administrative methods. To update the implementation contract, we call upgradeTo()
or upgradeToAndCall()
on the proxy. The second method is used for updates that require new initialization or data migration, all in a single transaction.
- Implementation Update: To add new features or fix bugs, we deploy a new implementation contract and use
upgradeToAndCall()
to migrate the necessary data.
By following these practices, we ensure that the contract remains secure, updatable, and compliant with legal regulations.
The proxy contract and implementation contracts are verified on etherscan at the following links:
Because the implementation address in the proxy is a private variable,
verifying that this is the proxy being used requires reading contract
storage directly. This can be done using a mainnet node, such as infura,
by pasting the network address in truffle-config.js
and running
truffle exec ./getImplementationAddress.js --network mainnet
As a first step run the initial setup
make setup
Next to run the smart contract tests, in another terminal, start ganache-cli
make ganache
Then in the original terminal where setup was executed, run
make test-contracts
You can also run make test-contracts-coverage
to see a coverage report.
If you encounter any problems or bugs, feel free to open an issue in our repository. Be sure to provide details about the issue you encountered, including steps to reproduce, error messages, and relevant information to facilitate the fix.
Do you have ideas to improve the smart contract or user experience on Mundo Digital Marketplace? Open an issue to discuss your proposals. We're open to suggestions for new features, performance improvements, and general optimizations.
If you want to directly contribute code, follow these steps:
- Fork the Repository: Fork our repository to your own account.
- Branch Creation: Create a branch to work on your contribution.
- Development: Implement your improvements or corrections.
- Testing: Be sure to test your changes.
- Pull Request (PR): Open a PR describing your changes and explaining the benefits.
- Review: Wait for our maintainers to review your PR.
Contributions to documentation are also valued. If you identify areas that need more clarity or want to add useful information, please feel free to submit proposed changes to the documentation.
Thanks in advance for your support and contributions to making the Digital World smart contract even better. Together, we can create a more robust and efficient platform.
This project is protected by the terms of the Proprietary Software license model. See the file Licença for details.