> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-pt/marketplace/estates-marketplace-integrations.md).

# Integrações de Marketplace para Estates

Coisas importantes a ter em mente se você quiser integrar o Estate do Decentraland ao seu marketplace

## Integrando o Estate do Decentraland no seu Marketplace

O Estate do Decentraland é um NFT compatível com ERC721 e funciona na Ethereum Mainnet. Portanto, muitos marketplaces de terceiros podem negociá-lo. Para fazer isso, esse marketplace deve seguir certas regras para manter as transações seguras para os usuários.

Como você talvez saiba, cada [Estate](https://docs.decentraland.org/decentraland/faq/#what-is-an-estate) é um grupo de [LANDs](https://docs.decentraland.org/decentraland/faq/#what-is-land) e ele tem um *bytes* hash associado ao grupo que ele chama de *`fingerprint`*. Sempre que o Estate muda ao adicionar ou remover um LAND, sua *`fingerprint`* também muda.

Para marketplaces, especialmente os que não têm um sistema de escrow, é 100% recomendado ter um registro da *`fingerprint`* do Estate quando alguém o lista para venda ou faz uma oferta. Dessa forma, quando a ordem/oferta é executada com sucesso, o proprietário atual não pode alterar o estate tentando front-run a execução da ordem.

Não é recomendado listar Estates vazios. O smart contract do Estate tem um método `getEstateSize` que retorna o número de LANDs no Estate. Se o resultado for `0`, recomendamos não listar esse Estate. Se você quiser listá-lo mesmo assim, verá uma imagem como esta:

![](https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-cc72f276a0f7c5a7aa5eb2dab3a3d1213e96fb0e%2Fdissolved_estate.png?alt=media\&token=e063628d-c3f8-40b2-b51e-0b344158847f)

## Exemplo

### Não usar a fingerprint do Estate

* Bob tem o Estate1 com os LANDs (1,1) e (1,2). Fingerprint do Estate1: hash1
* Bob adiciona o LAND (1,3) ao Estate1. O Estate1 tem os LANDs: (1,1), (1,2) e (1,3). Fingerprint do Estate1: hash2 (Fingerprint alterada)
* Bob remove o LAND (1,1) do Estate1. O Estate1 tem os LANDs: (1,2) e (1,3). Fingerprint do Estate1: hash3 (Fingerprint alterada)
* Bob coloca o Estate1 à venda. A listagem é criada onchain na Ethereum mainnet com o endereço do smart contract do Estate, o id do Estate, o preço e a data de expiração.
* Alice envia uma transação para comprar o Estate especificando o id do estate e o preço esperado a pagar.
* Bob detecta que alguém está tentando comprar seu Estate1 e envia uma transação com taxas de gas maiores do que as de Alice para remover os LANDs (1,2) e (1,3) do Estate1.
* A transação de Bob é minerada primeiro. O Estate1 fica com 0 LANDs. Fingerprint do Estate1: hash4 (Fingerprint alterada)
* A transação de Alice é minerada depois. Alice comprou o Estate1 com 0 LANDs nele. Isso significa que Alice foi front-runned (e roubada/enganada) por Bob.

### Usando a fingerprint do Estate

* Bob tem o Estate1 com os LANDs (1,1) e (1,2). Fingerprint do Estate1: hash1
* Bob adiciona o LAND (1,3) ao Estate1. O Estate1 tem os LANDs: (1,1), (1,2) e (1,3). Fingerprint do Estate1: hash2 (Fingerprint alterada)
* Bob remove o LAND (1,1) do Estate1. O Estate1 tem os LANDs: (1,2) e (1,3). Fingerprint do Estate1: hash3 (Fingerprint alterada)
* Bob coloca o Estate1 à venda. A listagem é criada onchain na Ethereum mainnet com o endereço do smart contract do Estate, o id do Estate, o preço e a data de expiração.
* Alice envia uma transação para comprar o Estate especificando o id do estate, o preço esperado a pagar e **a fingerprint que ela viu (hash3)**.
* Bob detecta que alguém está tentando comprar seu Estate1 e envia uma transação com taxas de gas maiores do que as de Alice para remover os LANDs (1,2) e (1,3) do Estate1.
* A transação de Bob é minerada primeiro. O Estate1 fica com 0 LANDs. Fingerprint do Estate1: hash4 (Fingerprint alterada)
* A transação de Alice é revertida porque o smart contract verificou que a fingerprint no parâmetro que Alice enviou não correspondia à fingerprint atual do Estate1 (hash3 != hash4). Essa verificação impediu Alice de comprar um Estate indesejado.

## Interface de Fingerprint do Smart Contract do Estate

O smart contract do Estate é compatível com uma [interface de fingerprint](https://github.com/decentraland/land/blob/master/contracts/estate/EstateStorage.sol#L19). Quando um Estate é listado para venda ou recebe uma oferta, registre sua fingerprint chamando *`getFingerprintV2(uint256 estateId)`* e armazene o valor que ele retornar. Para verificar se essa ordem/oferta ainda é válida no momento da execução, chame *`verifyFingerprint(uint256 estateId, bytes fingerprint)`* com o valor armazenado.

Sempre armazene o valor retornado por *`getFingerprintV2`*. O antigo *`getFingerprint`* método é mantido apenas por compatibilidade com versões anteriores e está sendo descontinuado: a partir de 26 de novembro de 2026, *`verifyFingerprint`* deixa de aceitar valores produzidos por ele. Novas integrações devem usar *`getFingerprintV2`*.

Você pode conferir um exemplo funcional em produção [aqui](https://github.com/decentraland/marketplace-contracts/blob/master/contracts/marketplace/MarketplaceV2.sol#L382).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/content-creator-pt/marketplace/estates-marketplace-integrations.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
