> 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-es/marketplace/estates-marketplace-integrations.md).

# Integraciones de Estates Marketplace

Cosas importantes a tener en cuenta si quieres integrar el Estate de Decentraland en tu marketplace

## Integrando el Estate de Decentraland en tu Marketplace

El Estate de Decentraland es un NFT compatible con ERC721 y se ejecuta en Ethereum Mainnet. Por lo tanto, muchos Marketplaces de terceros pueden comerciar con él. Para hacerlo, este Marketplace debe seguir ciertas reglas para mantener las transacciones seguras para los usuarios.

Como quizá sepas, cada [Estate](https://docs.decentraland.org/decentraland/faq/#what-is-an-estate) es un grupo de [LANDs](https://docs.decentraland.org/decentraland/faq/#what-is-land) y tiene un *bytes* hash asociado al grupo que se llama *`fingerprint`*. Cada vez que el Estate cambia al añadir o quitar un LAND, su *`fingerprint`* también cambia.

Para los Marketplaces, especialmente aquellos sin un sistema de escrow, se recomienda al 100% llevar un registro del fingerprint del Estate *`fingerprint`* cuando alguien lo pone a la venta o hace una oferta. De esa manera, cuando la orden/oferta se ejecuta correctamente, el propietario actual no puede cambiar el Estate intentando adelantarse a la ejecución de la orden.

No se recomienda listar Estates vacíos. El smart contract del Estate tiene un método `getEstateSize` que devuelve el número de LANDs en el Estate. Si el resultado es `0`, recomendamos no listar ese Estate. Si aun así quieres listarlo, verás una imagen como esta:

![](https://1216664193-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)

## Ejemplo

### No usar el fingerprint del Estate

* Bob tiene el Estate1 con los LANDs (1,1) y (1,2). Fingerprint de Estate1: hash1
* Bob añade el LAND (1,3) a Estate1. Estate1 tiene los LANDs: (1,1), (1,2) y (1,3). Fingerprint de Estate1: hash2 (Fingerprint cambiado)
* Bob elimina el LAND (1,1) de Estate1. Estate1 tiene los LANDs: (1,2) y (1,3). Fingerprint de Estate1: hash3 (Fingerprint cambiado)
* Bob pone a la venta el Estate1. La lista se crea onchain en la mainnet de Ethereum con la dirección del smart contract del Estate, el id del Estate, el precio y la fecha de expiración.
* Alice envía una transacción para comprar el Estate especificando el id del Estate y el precio que espera pagar.
* Bob detecta que alguien está intentando comprar su Estate1 y envía una transacción con tarifas de gas más altas que las de Alice para eliminar los LANDs (1,2) y (1,3) de Estate1.
* La transacción de Bob se mina primero. Estate1 tiene 0 LANDs. Fingerprint de Estate1: hash4 (Fingerprint cambiado)
* La transacción de Alice se mina después. Alice compró el Estate1 con 0 LANDs en él. Eso significa que Bob hizo front-running a Alice (y la estafó).

### Usando el fingerprint del Estate

* Bob tiene el Estate1 con los LANDs (1,1) y (1,2). Fingerprint de Estate1: hash1
* Bob añade el LAND (1,3) a Estate1. Estate1 tiene los LANDs: (1,1), (1,2) y (1,3). Fingerprint de Estate1: hash2 (Fingerprint cambiado)
* Bob elimina el LAND (1,1) de Estate1. Estate1 tiene los LANDs: (1,2) y (1,3). Fingerprint de Estate1: hash3 (Fingerprint cambiado)
* Bob pone a la venta el Estate1. La lista se crea onchain en la mainnet de Ethereum con la dirección del smart contract del Estate, el id del Estate, el precio y la fecha de expiración.
* Alice envía una transacción para comprar el Estate especificando el id del Estate, el precio que espera pagar y **el fingerprint que vio (hash3)**.
* Bob detecta que alguien está intentando comprar su Estate1 y envía una transacción con tarifas de gas más altas que las de Alice para eliminar los LANDs (1,2) y (1,3) de Estate1.
* La transacción de Bob se mina primero. Estate1 tiene 0 LANDs. Fingerprint de Estate1: hash4 (Fingerprint cambiado)
* La transacción de Alice se revierte porque el smart contract comprobó que el fingerprint del parámetro que envió Alice no coincidía con el fingerprint actual de Estate1 (hash3 != hash4). Esta comprobación evitó que Alice comprara un Estate no deseado.

## Interfaz de fingerprint del Smart Contract del Estate

El smart contract del Estate es compatible con una [interfaz de fingerprint](https://github.com/decentraland/land/blob/master/contracts/estate/EstateStorage.sol#L19). Cuando un Estate se pone a la venta o recibe una oferta, registra su fingerprint llamando a *`getFingerprintV2(uint256 estateId)`* y guarda el valor que devuelve. Para comprobar si esa orden/oferta sigue siendo válida en el momento de la ejecución, llama a *`verifyFingerprint(uint256 estateId, bytes fingerprint)`* con el valor almacenado.

Guarda siempre el valor devuelto por *`getFingerprintV2`*. La versión anterior *`getFingerprint`* del método se conserva solo por compatibilidad con versiones anteriores y se está retirando progresivamente: a partir del 26 de noviembre de 2026, *`verifyFingerprint`* dejará de aceptar valores producidos por él. Las nuevas integraciones deben usar *`getFingerprintV2`*.

Puedes consultar un ejemplo funcional en producción [aquí](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-es/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.