Integrações do Marketplace de estates
Coisas importantes a ter em mente se você quiser integrar o Estate da Decentraland no seu marketplace
Integrar o Estate da Decentraland no seu Marketplace
O Estate da Decentraland é um NFT compatível com ERC721 e opera na Ethereum Mainnet. Portanto, muitos marketplaces de terceiros podem negociá-los. Para isso, este marketplace deve seguir certas regras para manter as negociações seguras para os utilizadores.
Como talvez saiba, cada Estate é um grupo de LANDs e tem um bytes hash associado ao grupo que ele chama de fingerprint. Sempre que o Estate muda ao adicionar ou remover um LAND, o seu fingerprint também muda.
Para marketplaces, especialmente os que não têm um sistema de escrow, é 100% recomendado ter um registo do Estate fingerprint quando alguém o coloca à 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 fazer front-run da execução da ordem.
Não é recomendado listar Estates vazios. O Smart Contract do Estate tem um método getEstateSize que devolve o número de LANDs no Estate. Se o resultado for 0, recomendamos não listar esse Estate. Se, ainda assim, quiser listá-los, verá uma imagem como esta:
Exemplo
Não usar o fingerprint do Estate
O Bob tem o Estate1 com o LAND (1,1) e (1,2). fingerprint do Estate1: hash1
O 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 alterado)
O Bob remove o LAND (1,1) do Estate1. O Estate1 tem os LANDs: (1,2) e (1,3). fingerprint do Estate1: hash3 (fingerprint alterado)
O 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.
A Alice envia uma transação para comprar o Estate, especificando o id do estate e o preço esperado a pagar.
O Bob deteta que alguém está a tentar comprar o seu Estate1 e envia uma transação com taxas de gas mais altas do que as da Alice para remover os LANDs (1,2) e (1,3) do Estate1.
As transações do Bob são mineradas primeiro. O Estate1 fica com 0 LANDs. fingerprint do Estate1: hash4 (fingerprint alterado)
A transação da Alice é minerada depois. A Alice comprou o Estate1 com 0 LANDs nele. Isso significa que a Alice foi alvo de front-run (e roubada/enganada) pelo Bob.
Usando o fingerprint do Estate
O Bob tem o Estate1 com o LAND (1,1) e (1,2). fingerprint do Estate1: hash1
O 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 alterado)
O Bob remove o LAND (1,1) do Estate1. O Estate1 tem os LANDs: (1,2) e (1,3). fingerprint do Estate1: hash3 (fingerprint alterado)
O 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.
A Alice envia uma transação para comprar o Estate, especificando o id do estate, o preço esperado a pagar e o fingerprint que ela viu (hash3).
O Bob deteta que alguém está a tentar comprar o seu Estate1 e envia uma transação com taxas de gas mais altas do que as da Alice para remover os LANDs (1,2) e (1,3) do Estate1.
As transações do Bob são mineradas primeiro. O Estate1 fica com 0 LANDs. fingerprint do Estate1: hash4 (fingerprint alterado)
A transação da Alice é revertida porque o Smart Contract verificou que o fingerprint no parâmetro enviado pela Alice não correspondia ao fingerprint atual do Estate1 (hash3 != hash4). Esta verificação impediu a 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. Quando um Estate é listado para venda ou recebe uma oferta, registe o seu fingerprint chamando getFingerprintV2(uint256 estateId) e armazene o valor que ele devolve. Para verificar se essa ordem/oferta ainda é válida no momento da execução, chame verifyFingerprint(uint256 estateId, bytes fingerprint) com o valor armazenado.
Armazene sempre o valor devolvido por getFingerprintV2. O método mais antigo getFingerprint é mantido apenas por compatibilidade retroativa e está a ser descontinuado: a partir de 26 de novembro de 2026, verifyFingerprint deixa de aceitar valores produzidos por ele. As novas integrações devem usar getFingerprintV2.
Pode verificar um exemplo funcional em produção aqui.
Atualizado