Quando falamos em Smart Cities, é comum pensar imediatamente em semáforos inteligentes, veículos conectados, câmeras, sensores ambientais, iluminação pública automatizada e aplicativos de mobilidade.

Por trás de praticamente todos esses sistemas existe, porém, um recurso ainda mais importante: dados.

Uma cidade inteligente pode produzir continuamente informações sobre:

• fluxo de veículos;
• transporte público;
• qualidade do ar;
• temperatura e umidade;
• consumo energético;
• iluminação pública;
• disponibilidade de vagas;
• ocupação de prédios;
• ruído urbano;
• utilização de serviços públicos;
• fluxo de pedestres;
• eventos meteorológicos;
• infraestrutura;
• mapas e georreferenciamento;
• dispositivos IoT distribuídos pela cidade.

Individualmente, cada sensor gera apenas pequenas quantidades de informação. Quando milhões dessas observações são organizadas ao longo do tempo, entretanto, passam a constituir datasets extremamente valiosos.

Esses conjuntos podem alimentar sistemas de Inteligência Artificial, pesquisas acadêmicas, modelos de mobilidade, planejamentos urbanos, Digital Twins, sistemas de previsão, serviços comerciais e aplicações desenvolvidas por empresas privadas.

Surge então uma questão fundamental:

quem pode utilizar esses dados, durante quanto tempo, para qual finalidade e sob quais condições?

É justamente nesse ponto que Blockchain, Smart Contracts e NFTs começam a assumir um papel bastante diferente daquele normalmente associado à negociação de obras digitais ou colecionáveis.

O verdadeiro ativo pode não ser o NFT — pode ser o direito de acessar um dataset

Um NFT, ou Non-Fungible Token, é essencialmente um registro digital individualizado controlado por um Smart Contract.

Um erro comum é imaginar que o NFT necessariamente precisa armazenar dentro da Blockchain aquilo que representa.

Não precisa.

Um NFT pode representar:

• uma obra de arte;
• um ingresso;
• uma licença de software;
• uma identidade;
• uma credencial;
• um certificado;
• um imóvel;
• uma autorização;
• ou simplesmente o direito de utilizar determinado recurso digital.

Isso abre uma possibilidade particularmente interessante para ambientes urbanos.

Em vez de colocar gigabytes ou terabytes de dados de sensores dentro da Blockchain, podemos colocar na Blockchain apenas uma representação digital dos direitos relacionados àquele dataset.

Temos então duas coisas separadas:

DADO
↓
armazenado fora da Blockchain

TOKEN
↓
representa direitos sobre o dado

Esse princípio é essencial para compreender a tokenização de datasets.

Imagine, por exemplo, um dataset contendo:

Dataset: Mobilidade Urbana de Fortaleza
Período: janeiro a dezembro de 2026
Origem: sensores municipais
Granularidade: 5 minutos
Registros: 2,7 bilhões
Tamanho: 850 GB

Não faria sentido armazenar 850 GB dentro da Ethereum.

Mas poderíamos emitir um token representando:

"Esta carteira possui autorização para utilizar o Dataset Mobilidade Urbana 2026 conforme determinadas condições."

A Blockchain passa, portanto, a controlar o direito de acesso, e não necessariamente o dado.

Da propriedade para o direito de uso

Essa distinção é importante porque possuir um recurso e poder utilizá-lo são coisas diferentes.

Podemos fazer uma analogia com um apartamento.

O proprietário continua sendo dono do imóvel, mas pode conceder temporariamente a outra pessoa o direito de utilizá-lo.

O mesmo pode acontecer com dados.

Uma prefeitura, universidade, empresa de transporte ou operadora de infraestrutura pode continuar sendo responsável pelo dataset enquanto concede a terceiros um direito limitado de utilização.

É justamente para resolver situações semelhantes que surgiu o ERC-4907.

ERC-4907: o NFT com proprietário e usuário

O ERC-4907 é uma extensão do ERC-721 projetada para permitir que um NFT possua dois papéis diferentes:

OWNER
proprietário do NFT

USER
usuário temporário do NFT

Além disso, o padrão acrescenta uma informação extremamente importante:

expires

que determina quando o direito do usuário deixa de ser válido.

O padrão foi criado originalmente pensando em NFTs que poderiam ser alugados. A especificação acrescenta ao ERC-721 um papel user, separado do owner, e um timestamp expires. Após o vencimento, o endereço deixa automaticamente de ser considerado usuário válido, sem que seja necessária uma segunda transação para retirar manualmente a permissão.

Conceitualmente:

                  NFT ERC-4907
                       │
           ┌───────────┴───────────┐
           │                       │
         OWNER                   USER
           │                       │
     possui o NFT            pode utilizá-lo
                                   │
                                   ▼
                             até "expires"

Isso parece uma mudança pequena em relação ao ERC-721, mas cria um mecanismo muito poderoso de licenciamento temporário on-chain.

Um dataset como NFT alugável

Agora podemos transportar esse conceito para Smart Cities.

Imagine que uma prefeitura mantenha um dataset de mobilidade atualizado continuamente.

O dataset permanece protegido em uma infraestrutura apropriada:

Object Storage
Data Lake
IPFS privado
Banco de dados
Data Space
API segura

Um NFT ERC-4907 representa o direito de acesso a esse dataset.

A prefeitura ou entidade responsável permanece como:

owner

Enquanto uma universidade que contratou acesso por seis meses torna-se:

user

com:

expires = 31/12/2026 23:59:59

A estrutura poderia ser:

Prefeitura
  │
  │ owner
  ▼
NFT ERC-4907
  │
  │ user durante 180 dias
  ▼
Universidade
  │
  ▼
API Gateway
  │
  ▼
Dataset

O Smart Contract não precisa entregar o dataset diretamente.

Ele apenas responde a uma pergunta:

Esta carteira possui, neste momento, autorização válida para utilizar este recurso?

Como isso poderia funcionar tecnicamente

O ERC-4907 define funções como:

userOf(tokenId)

e:

userExpires(tokenId)

O sistema de acesso pode consultar essas informações.

Imagine uma universidade requisitando:

GET /datasets/mobilidade-fortaleza-2026

O servidor solicita que a carteira prove que controla determinado endereço.

Depois consulta o Smart Contract:

userOf(357)

Recebendo:

0xUniversidade...

E posteriormente:

userExpires(357)

Retornando:

31/12/2026 23:59:59

Se:

wallet == userOf(tokenId)

e:

block.timestamp < expires

o acesso pode ser concedido.

Em termos simplificados:

Usuário
 │
 │ solicita acesso
 ▼
API Gateway
 │
 │ verifica assinatura da wallet
 ▼
Smart Contract ERC-4907
 │
 ├── userOf(tokenId)
 └── userExpires(tokenId)
 │
 ▼
Autorizado?
 │
 ┌─┴─┐
 │   │
sim não
 │   │
 ▼   ▼
dados bloqueio

A Blockchain funciona, portanto, como uma camada verificável de autorização e governança.

O NFT não deve conter o dataset

Esse é um dos conceitos mais importantes de toda essa arquitetura.

Para a maioria dos datasets reais, principalmente aqueles relacionados a Smart Cities, colocar os dados integralmente em uma Blockchain pública seria inadequado por questões de:

• custo;
• desempenho;
• privacidade;
• escalabilidade;
• proteção de dados;
• atualização;
• direito de exclusão;
• confidencialidade.

A arquitetura apropriada tende a ser híbrida:

                BLOCKCHAIN
                    │
    ┌───────────────┼─────────────────┐
    │               │                 │
 identidade       licença           auditoria
    │               │                 │
    └───────────────┬─────────────────┘
                    │
               Smart Contract
                    │
                    ▼
                API Gateway
                    │
                    ▼
            armazenamento externo
                    │
                    ▼
                  DATASET

Na Blockchain poderiam ser registrados apenas elementos como:

datasetId
hash
URI
owner
licença
período de acesso
política de uso
identidade do emissor

O hash permite ainda detectar alterações.

Se:

H(dataset_original) =
0xABCD...

e posteriormente:

H(dataset_recebido) =
0xABCD...

temos evidência criptográfica de que o conteúdo corresponde à versão registrada.

Se um único bit for alterado, o hash muda.

Soulbound Tokens: quando a autorização não deve ser negociável

O ERC-4907 resolve muito bem uma pergunta:

Quem pode utilizar este recurso temporariamente?

Mas existe outro problema.

Algumas autorizações não deveriam poder ser vendidas ou transferidas para outra carteira.

Imagine que uma universidade recebeu acesso a dados sensíveis porque:

• assinou um acordo;
• passou por processo de homologação;
• declarou uma finalidade de pesquisa;
• possui determinado certificado;
• passou por análise de segurança.

Não faria sentido permitir que essa instituição simplesmente vendesse sua autorização para outra entidade.

É aqui que entram os Soulbound Tokens, ou SBTs.

O que é um Soulbound Token?

A expressão Soulbound ganhou projeção na Web3 a partir do trabalho de Glen Weyl, Puja Ohlhaver e Vitalik Buterin sobre uma sociedade descentralizada, no qual tokens não transferíveis poderiam representar relacionamentos, credenciais, compromissos e reputações vinculadas a determinada "Soul".

De maneira simples:

Um Soulbound Token é um token vinculado a uma identidade ou conta que não pode ser livremente transferido como um NFT convencional.

Enquanto um ERC-721 tradicional normalmente permite:

Alice
│
│ transfer
▼
Bob

um Soulbound Token pode ser:

Alice
│
├── possui
│
└── não pode transferir

Um padrão Ethereum que implementa uma interface mínima para esse comportamento é o ERC-5192. Ele estende o ERC-721 permitindo identificar se determinado token está locked; enquanto estiver bloqueado, as operações de transferência precisam falhar.

Soulbound como credencial de acesso a dados

Agora podemos combinar os conceitos.

Imagine que a Secretaria Municipal de Mobilidade possua vários níveis de datasets.

Dataset A

Dados agregados de trânsito.

Pode ser aberto para empresas.

Dataset B

Dados de alta resolução provenientes de sensores.

Disponível apenas para universidades credenciadas.

Dataset C

Informações potencialmente sensíveis.

Somente pesquisadores aprovados podem acessá-lo.

Um Soulbound Token poderia representar:

Credencial:
Pesquisador autorizado para dados urbanos

Emissor:
Secretaria Municipal

Titular:
0xCarlos...

Categoria:
Researcher-Level-2

Como o token não é transferível, outra carteira não deveria simplesmente comprá-lo.

Temos então algo semelhante a um crachá digital verificável.

ERC-4907 e Soulbound não precisam competir

Uma arquitetura mais interessante surge quando utilizamos os dois conceitos de maneira complementar.

O Soulbound Token responde:

Quem é você ou qual qualificação você possui?

O ERC-4907 responde:

Qual recurso você pode utilizar e até quando?

Podemos então ter:

             IDENTIDADE / QUALIFICAÇÃO

                     SBT
                      │
                      │
                Universidade
                credenciada
                      │
                      ▼

             LICENÇA TEMPORÁRIA

                  ERC-4907
                      │
                      │ acesso por 90 dias
                      ▼

                   Dataset

Para obter acesso, uma aplicação poderia exigir:

Possui SBT válido?
     +
É user do ERC-4907?
     +
Licença ainda não expirou?

Somente quando as três condições forem satisfeitas:

ACCESS = TRUE

Um exemplo completo em uma Smart City

Imagine uma empresa desenvolvendo um sistema de Inteligência Artificial para otimizar linhas de ônibus.

Ela precisa de:

• posição histórica dos ônibus;
• horários;
• velocidade média;
• ocupação;
• fluxo por estação;
• interrupções;
• dados meteorológicos.

A prefeitura possui um dataset chamado:

UrbanMobilityDataset-2026

Etapa 1 — Tokenização

O dataset recebe uma identidade digital:

Dataset ID:
URBAN-MOBILITY-FOR-2026

Hash:
0x9a14...

Owner:
Prefeitura

Storage:
data.city.example/datasets/...

O token não precisa carregar todos os dados.

Ele representa direitos sobre o dataset.

Etapa 2 — Credenciamento

A empresa passa por uma análise jurídica e técnica.

Depois da aprovação recebe um Soulbound Token:

CITY-DATA-RESEARCHER

Esse token representa:

esta organização foi autorizada a participar do ecossistema municipal de dados.

Etapa 3 — Contratação

A empresa solicita três meses de acesso.

Um Smart Contract atribui:

user:
0xEmpresa...

expires:
90 dias

ao NFT ERC-4907 que representa a licença do dataset.

Etapa 4 — Autenticação

Ao solicitar informações pela API:

Empresa
 │
 ▼
Assina desafio com wallet
 │
 ▼
Servidor verifica assinatura
 │
 ▼
Verifica Soulbound Token
 │
 ▼
Verifica ERC-4907
 │
 ▼
Verifica expires
 │
 ▼
gera credencial temporária
 │
 ▼
Dataset

Blockchain como Control Plane, não como Data Plane

Do ponto de vista de arquitetura distribuída, podemos fazer uma distinção bastante útil.

A Blockchain seria o:

Control Plane

responsável por:

• identidade;
• propriedade;
• autorização;
• licenciamento;
• auditoria;
• pagamentos;
• validade temporal.

Enquanto a infraestrutura tradicional seria o:

Data Plane

responsável por:

• armazenar;
• transmitir;
• consultar;
• processar;
• filtrar;
• entregar os dados.

Isso produz uma arquitetura muito mais realista:

┌────────────────────────────────────┐
│          BLOCKCHAIN / WEB3         │
│                                    │
│ SBT       ERC-4907      Payments   │
│  │           │              │      │
│ identidade  licença      cobrança  │
└───────────────┬────────────────────┘
              │
              ▼
┌────────────────────────────────────┐
│          ACCESS GATEWAY            │
│                                    │
│ Wallet Auth                        │
│ Policy Engine                      │
│ Rate Limiting                      │
│ Logging                            │
└───────────────┬────────────────────┘
              │
              ▼
┌────────────────────────────────────┐
│              DATA                  │
│                                    │
│ Data Lake │ API │ IPFS │ Database │
└────────────────────────────────────┘

Isso também evita atribuir à Blockchain funções para as quais ela não foi projetada.

Tokenizar um dataset não significa necessariamente vender o dataset

Essa diferenciação é fundamental.

Quando ouvimos a palavra tokenização, muitas vezes pensamos imediatamente em transformar algo em ativo financeiro.

Mas tokenização significa algo mais amplo:

representar digitalmente um recurso, direito, atributo ou relação através de tokens programáveis.

Um dataset poderia possuir vários tipos de tokenização simultaneamente.

Por exemplo:

Dataset
 │
 ├── NFT → identidade/proveniência
 │
 ├── ERC-4907 → licença temporária
 │
 ├── SBT → credencial de acesso
 │
 └── ERC-20 → créditos de consumo

Cada mecanismo resolve um problema diferente.

Surgem então os Data Assets

Ao receber uma identidade verificável e políticas programáveis, o dataset deixa de ser apenas:

arquivo.csv

e começa a assumir as características de um ativo digital de dados — Data Asset.

Ele pode possuir:

IDENTIDADE
+
PROVENIÊNCIA
+
INTEGRIDADE
+
PROPRIETÁRIO
+
LICENÇA
+
PREÇO
+
POLÍTICAS
+
HISTÓRICO

Isso é particularmente relevante porque pesquisas recentes sobre data spaces baseados em Blockchain apontam exatamente problemas como soberania sobre os dados, identidade, assetização, cumprimento de contratos, governança e interoperabilidade como desafios centrais desse tipo de ecossistema.

Um marketplace de datasets urbanos

A próxima evolução natural seria a criação de um Data Marketplace.

Imagine um catálogo:

SMART CITY DATA MARKETPLACE

─────────────────────────────

Mobilidade Urbana 2026
R$ 800 / mês

Qualidade do Ar
R$ 300 / mês

Consumo Energético
R$ 1.200 / mês

Fluxo de Pedestres
R$ 500 / mês

Meteorologia Urbana
R$ 250 / mês

Uma empresa poderia:

encontrar dataset
     ↓
consultar metadados
     ↓
verificar licença
     ↓
efetuar pagamento
     ↓
receber direito temporário ERC-4907
     ↓
autenticar wallet
     ↓
acessar API

Tudo isso poderia ser automatizado por Smart Contracts.

E se o dataset for atualizado constantemente?

Esse é outro detalhe importante.

Dados de Smart Cities raramente são estáticos.

Sensores podem gerar novos dados a cada:

1 segundo
10 segundos
1 minuto
5 minutos

Portanto, não necessariamente estamos tokenizando um arquivo.

Podemos estar tokenizando um serviço de dados.

Por exemplo:

NFT #7215

Dataset:
CityTraffic

Access:
Streaming API

Resolution:
30 seconds

Region:
Fortaleza

Rate Limit:
10.000 requests/day

Expires:
2026-12-31

Nesse caso, o token representa uma espécie de assinatura Web3 programável.

Controle de replicação: o problema que a Blockchain não resolve sozinha

Existe, entretanto, uma limitação importante.

Se alguém recebe um arquivo:

dataset.csv

e o salva em seu computador, nenhum Smart Contract consegue magicamente apagar esse arquivo quando o NFT expirar.

Portanto:

expiração do token
≠
destruição das cópias já realizadas

Esse é um ponto crítico em qualquer arquitetura séria de tokenização de dados.

A Blockchain controla direitos e autorizações, mas não controla diretamente todos os computadores externos.

É necessário utilizar mecanismos adicionais.

Em vez de entregar o dataset, entregar acesso ao dataset

Uma das melhores estratégias é evitar entregar integralmente dados sensíveis.

Em vez de:

Download dataset.zip

usar:

API
Query Engine
Secure Data Space
Data Clean Room
Streaming

Assim, o usuário consulta:

SELECT AVG(speed)
FROM traffic
WHERE region = 'Centro'
AND date BETWEEN ...

e recebe somente o resultado autorizado.

Isso reduz significativamente a capacidade de replicação indiscriminada.

Criptografia também pode participar da arquitetura

Datasets podem permanecer criptografados.

Uma possível arquitetura seria:

Dataset
 │
 ▼
AES-256 encryption
 │
 ▼
Encrypted Dataset
 │
 ▼
Storage

O usuário autorizado obtém uma chave temporária ou mecanismo equivalente.

O Smart Contract pode ajudar a decidir quem está autorizado, enquanto um sistema externo realiza o gerenciamento seguro das chaves.

Tecnologias mais avançadas ainda podem incluir:

• proxy re-encryption;
• attribute-based encryption;
• confidential computing;
• Trusted Execution Environments;
• Multi-Party Computation;
• Zero-Knowledge Proofs.

A combinação dessas técnicas com Blockchain cria controles muito mais poderosos do que simplesmente colocar um NFT na frente de um arquivo.

Blockchain fornece rastreabilidade, não invisibilidade

Outro ponto importante é a auditoria.

O acesso a dados pode gerar registros como:

Wallet:
0x81...

Dataset:
Traffic-2026

Permission:
Research

Granted:
08/09/2026

Expires:
08/12/2026

A Blockchain pode ajudar a tornar determinados eventos verificáveis e resistentes a alterações posteriores.

Entretanto, dependendo da legislação e do nível de sensibilidade do sistema, detalhes pessoais ou confidenciais não devem necessariamente ser publicados em uma Blockchain pública.

Pode-se registrar apenas:

hash(event)

mantendo o conteúdo completo em sistemas adequadamente protegidos.

Privacidade e Smart Cities

Esse cuidado torna-se ainda mais importante quando os dados urbanos podem estar relacionados a pessoas.

Informações aparentemente inocentes podem permitir inferências.

Por exemplo:

localização
+
horário
+
trajeto
+
recorrência

podem ajudar a identificar padrões de comportamento.

Por isso uma arquitetura adequada precisa considerar:

• anonimização;
• pseudonimização;
• minimização de dados;
• consentimento quando aplicável;
• finalidade de processamento;
• controle de acesso;
• políticas de retenção;
• LGPD;
• auditoria.

Pesquisas sobre compartilhamento de dados em Smart Cities já exploram justamente a utilização de Blockchain e Smart Contracts para autorização descentralizada, rastreabilidade e mecanismos destinados a aumentar a responsabilização em caso de vazamentos.

Blockchain deve, portanto, ser vista como uma parte da arquitetura de segurança, não como substituta da segurança.

NFTs podem representar direitos, e não arquivos

Chegamos então ao principal conceito.

Quando pensamos em tokenização de datasets, o token não precisa representar:

"Aqui está o conjunto de dados."

Pode representar:

"Aqui estão os direitos que esta carteira possui sobre este conjunto de dados."

Essa mudança de perspectiva é poderosa.

Podemos definir:

Dataset
    ↓
Digital Asset
    ↓
NFT
    ↓
Smart Contract
    ↓
Access Rights

E esses direitos podem ser programáveis.

Uma possível arquitetura de tokenização de datasets

Uma Smart City poderia implementar algo próximo a:

               SMART CITY
                   │
            Data Producers
                   │
     ┌─────────────┼─────────────┐
     │             │             │
   IoT         Transport      Energy
     │             │             │
     └─────────────┬─────────────┘
                   │
                   ▼
                DATA LAKE
                   │
                   ▼
             Dataset Registry
                   │
                   ▼
              BLOCKCHAIN
                   │
     ┌─────────────┼─────────────┐
     │             │             │
    NFT        ERC-4907         SBT
identidade       licença      identidade
do dataset      temporária    autorizada
     │             │             │
     └─────────────┼─────────────┘
                   │
                   ▼
              Policy Engine
                   │
                   ▼
              API Gateway
                   │
                   ▼
               Consumer
                   │
        ┌──────────┼───────────┐
        │          │           │
       IA      Universidade   Empresa

Essa arquitetura conecta três mundos:

Web 2.0
infraestrutura de dados

Web 3.0
direitos programáveis

IoT
produção dos dados

De Smart Cities para uma economia de dados

Quando datasets passam a possuir:

• identidade;
• origem verificável;
• políticas;
• licenças;
• controle de acesso;
• mecanismos de pagamento;
• histórico de utilização;

torna-se possível construir uma verdadeira economia de dados.

Uma universidade pode publicar um dataset.

Uma empresa pode licenciá-lo.

Um município pode permitir seu uso gratuitamente para pesquisa e cobrar pelo uso comercial.

Um consórcio pode financiar sua coleta.

Uma empresa de Inteligência Artificial pode adquirir acesso temporário para treinamento ou avaliação de modelos.

Tudo isso pode ocorrer sem que a propriedade do dataset precise necessariamente ser transferida.

ERC-4907 transforma acesso em algo temporal

O ERC-4907 é especialmente interessante porque introduz uma característica que normalmente exige grande esforço nos sistemas tradicionais:

tempo como parte nativa da autorização.

Temos:

WHO
quem pode acessar

WHAT
qual dataset

UNTIL WHEN
até quando

Podemos ainda complementar isso fora do padrão com:

PURPOSE
para qual finalidade

HOW MUCH
qual volume

HOW OFTEN
qual frequência

WHERE
em qual ambiente

UNDER WHICH LICENSE
sob qual licença

Passamos então de uma simples permissão:

ALLOW / DENY

para uma política programável de utilização de dados.

Soulbound adiciona identidade e responsabilidade

O Soulbound Token acrescenta outra dimensão:

WHO ARE YOU?

Uma carteira sozinha é apenas:

0x8f62...

Um token não transferível pode indicar que aquela carteira pertence, por exemplo, a uma entidade que recebeu determinada credencial:

Research Institution
Environmental Agency
University
Certified AI Provider
Urban Planning Contractor

A partir disso, Smart Contracts e aplicações podem criar regras como:

SE
possui ResearcherSBT
E
possui licença ERC-4907 válida

ENTÃO
permitir Dataset-Level-2

É uma forma de Attribute-Based Access Control, na qual atributos verificáveis da carteira participam das decisões de autorização.

Tokenização não significa necessariamente especulação

Essa talvez seja uma das maiores mudanças conceituais necessárias para compreender a Web 3.0.

Token não significa necessariamente moeda.

NFT não significa necessariamente imagem colecionável.

Blockchain não significa necessariamente especulação financeira.

Tokens podem representar:

IDENTIDADE

AUTORIZAÇÃO

LICENÇA

CERTIFICADO

CONTRATO

REPUTAÇÃO

PROPRIEDADE

DIREITO DE USO

E datasets podem se beneficiar diretamente dessas propriedades.

Conclusão

Smart Cities produzem quantidades gigantescas de dados, mas o verdadeiro desafio não está apenas em coletá-los.

Precisamos responder:

quem pode utilizá-los?

por quanto tempo?

para qual finalidade?

sob quais condições?

como saber se o dataset foi alterado?

como provar que determinada organização recebeu autorização?

como revogar ou fazer uma licença expirar automaticamente?

A tokenização de datasets oferece uma forma interessante de transformar essas regras em ativos e direitos digitalmente verificáveis.

Nesse cenário, um Soulbound Token pode representar a qualificação ou autorização permanente de uma organização, enquanto um ERC-4907 representa o direito temporário de utilizar determinado dataset.

Podemos resumir a arquitetura assim:

SBT
"Quem é você?"

    +

ERC-4907
"O que você pode usar e até quando?"

    +

Smart Contract
"Quais são as regras?"

    +

API / Data Space
"Como os dados serão entregues?"

    =

DATASET TOKENIZADO

O dataset continua existindo em uma infraestrutura apropriada para armazenamento e processamento de grandes volumes de informações.

A Blockchain passa a atuar onde possui maior valor:

identidade, integridade, propriedade, licenciamento, autorização, auditoria e coordenação entre entidades que não necessariamente confiam umas nas outras.

É justamente aí que a tokenização de datasets começa a se tornar especialmente relevante para a próxima geração de Smart Cities.

Em vez de enxergar os dados apenas como arquivos armazenados em servidores, podemos começar a tratá-los como recursos digitais com identidade, proveniência, direitos e políticas programáveis.

E talvez esse seja um dos usos menos discutidos — e mais promissores — dos NFTs na Web 3.0.

Referências

Ethereum Improvement Proposals — ERC-4907: Rental NFT, an Extension of EIP-721. O padrão adiciona ao ERC-721 os papéis distintos de proprietário e usuário, além de um prazo de expiração para o direito de uso.

Ethereum Improvement Proposals — ERC-5192: Minimal Soulbound NFTs. Define uma interface mínima para NFTs não transferíveis baseados no ERC-721.

Weyl, E. Glen; Ohlhaver, Puja; Buterin, Vitalik. Decentralized Society: Finding Web3's Soul. Trabalho que desenvolveu o conceito de Soulbound Tokens como representações não transferíveis de credenciais, compromissos e relações sociais.

Blockchain for data spaces: A survey of architectures, capabilities, and challenges. Discussão sobre Blockchain aplicada a Data Spaces, incluindo identidade, soberania, assetização, governança, segurança e interoperabilidade.

PrivySharing: A blockchain-based framework for privacy-preserving and secure data sharing in smart cities. Pesquisa sobre Blockchain, controle de acesso e compartilhamento seguro de dados em ambientes urbanos.

Efficient and traceable data sharing for the Internet of Things in smart cities. Pesquisa sobre autorização descentralizada, rastreabilidade e responsabilização no compartilhamento de dados IoT em Smart Cities.