Quando começamos a desenvolver Smart Contracts, é comum imaginar que a Ethereum Virtual Machine — EVM — possui alguma espécie de relógio interno capaz de executar comandos como:

Execute esta transferência daqui a 30 dias.

Mas não é exatamente assim.

A EVM não possui um agendador semelhante ao cron do Linux, ao setTimeout() do JavaScript ou a um timer de um microcontrolador.

Um Smart Contract também não "acorda" sozinho quando chega determinada data.

O que existe são informações associadas aos blocos que podem ser utilizadas pelo contrato para decidir se uma determinada operação já pode ou ainda não pode ser executada.

É a partir dessa característica que surgem mecanismos como:

• timelocks;
• vesting;
• períodos de votação;
• escrows temporais;
• maturidade de ativos;
• depósitos bloqueados;
• pagamentos futuros;
• períodos de carência;
• snapshots de governança.

Neste artigo vamos estudar cinco propostas particularmente interessantes:

ERC-6372 — Contract Clock

ERC-7444 — Time Locks Maturity

ERC-7720 — Deferred Token Transfer

ERC-6229 — Tokenized Vaults with Lock-in Period

ERC-1132 — ERC-20 Token Locking

O interessante é perceber que elas não competem necessariamente entre si. Cada uma resolve uma camada diferente do problema da temporização de Smart Contracts.

1. Primeiro: de onde vem o "tempo" na EVM?

Solidity disponibiliza, entre outras informações:

block.timestamp
block.number

block.timestamp representa o timestamp do bloco atual em segundos desde a Unix Epoch, enquanto block.number representa a altura do bloco atual na blockchain.

Podemos escrever algo simples como:

uint256 public unlockTime;

constructor() {
  unlockTime = block.timestamp + 30 days;
}

E posteriormente:

function withdraw() external {
  require(
      block.timestamp >= unlockTime,
      "Ainda bloqueado"
  );

  // liberar os recursos
}

Observe um detalhe fundamental.

Quando:

block.timestamp == unlockTime

nada é automaticamente executado.

O contrato apenas passa a aceitar uma transação que anteriormente seria rejeitada.

Portanto:

TEMPO PASSA
   ↓
CONDIÇÃO SE TORNA VERDADEIRA
   ↓
ALGUÉM ENVIA TRANSAÇÃO
   ↓
EVM EXECUTA O CONTRATO
   ↓
CONTRATO CONFERE O TEMPO
   ↓
OPERAÇÃO É AUTORIZADA

Se quisermos execução automática, precisamos de algum mecanismo externo — bot, keeper, serviço de automação, agente ou outro participante — que envie a transação.

Essa distinção é essencial para compreender todos os ERCs apresentados a seguir.

2. block.timestamp versus block.number

Existem basicamente duas referências muito utilizadas.

Timestamp

block.timestamp

É intuitivo para situações como:

liberar em 30 dias
votação termina em 48 horas
vesting termina em 1 ano
pagamento disponível após determinada data

Por exemplo:

uint256 unlockAt = block.timestamp + 30 days;

Número do bloco

Outra estratégia é utilizar:

block.number

Nesse caso poderíamos ter algo conceitualmente semelhante a:

uint256 unlockBlock = block.number + 1000;

Mas existe uma diferença importante.

Bloco não é uma unidade de tempo.

Se uma aplicação disser:

1000 blocos = X horas

está fazendo uma aproximação dependente das características daquela blockchain.

Isso se torna ainda mais importante quando pensamos em:

• Ethereum;
• Polygon;
• Arbitrum;
• Optimism;
• Base;
• outras EVMs;
• diferentes Layer 2.

É justamente aqui que o primeiro padrão de nossa lista se torna extremamente interessante.

3. ERC-6372 — Contract Clock

O ERC-6372 tenta responder uma pergunta aparentemente simples:

Qual relógio este contrato utiliza?

Imagine um protocolo de governança.

O token registra snapshots de poder de voto utilizando blocos.

Outro contrato interpreta o parâmetro recebido como timestamp.

Temos um problema de interoperabilidade.

O ERC-6372 propõe uma interface extremamente pequena:

interface IERC6372 {
  function clock()
      external
      view
      returns (uint48);

  function CLOCK_MODE()
      external
      view
      returns (string memory);
}

O padrão encontra-se atualmente em estado Review.

clock()

Retorna o timepoint utilizado pelo contrato:

clock()

O valor deve ser monotônico, isto é, não diminuir conforme a blockchain avança. O ERC admite referências como timestamp, número de bloco ou eventualmente outros relógios monotônicos.

Por exemplo:

function clock()
  public
  view
  returns (uint48)
{
  return uint48(block.timestamp);
}

CLOCK_MODE()

Explica o que aquele número significa.

Para timestamp:

mode=timestamp

Para o número de bloco padrão:

mode=blocknumber&from=default

Então podemos ter:

function CLOCK_MODE()
  public
  pure
  returns (string memory)
{
  return "mode=timestamp";
}

Agora outro Smart Contract ou uma aplicação pode descobrir programaticamente:

clock() → 1789...
CLOCK_MODE() → "mode=timestamp"

e saber interpretar corretamente aquele valor.

4. Por que o ERC-6372 é mais importante do que parece?

O ERC-6372 não bloqueia tokens.

Não realiza vesting.

Não executa pagamentos.

Não implementa escrow.

Ele cria algo mais fundamental:

uma abstração padronizada de relógio para Smart Contracts.

Isso é particularmente importante para governança.

O ERC-5805, por exemplo, que trata de votação com delegação e histórico de poder de voto, utiliza justamente o ERC-6372 para permitir diferentes formas de acompanhamento temporal.

Podemos imaginar:

undefined

Ou seja:

ERC-6372 responde "qual é o relógio?"

Os próximos padrões começam a responder:

"o que fazemos com esse tempo?"

5. ERC-7444 — Time Locks Maturity

Agora temos outro problema.

Imagine um ativo bloqueado até 2030.

Outro protocolo encontra esse ativo e pergunta:

Quando ele ficará disponível?

Sem uma interface padronizada, cada projeto poderia implementar algo diferente:

unlockTime()

ou:

releaseDate()

ou:

vestingEnd()

ou ainda:

maturity()

O ERC-7444 tenta padronizar essa consulta.

Seu núcleo conceitual é:

function getMaturity(bytes32 id)
  external
  view
  returns (uint256 maturity);

O valor retornado representa o timestamp Unix em que determinado lock atinge sua maturidade. O padrão também requer suporte à detecção de interface ERC-165.

Em setembro de 2026, o ERC-7444 permanece com status Draft.

6. Entendendo maturidade

Vamos imaginar que João tenha:

10.000 TOKENS

bloqueados até:

01/01/2028

O contrato poderia atribuir um identificador ao lock:

lockId

e permitir:

getMaturity(lockId);

Obtendo:

timestamp → data de vencimento

A arquitetura torna-se:

Isso permite que wallets, protocolos DeFi, marketplaces e outros Smart Contracts descubram a maturidade sem conhecer detalhes internos da implementação.

7. ERC-7444 não executa o desbloqueio

Essa é uma distinção muito importante.

O ERC-7444 basicamente padroniza a descoberta da maturidade.

Ele não significa:

ERC-7444
  ↓
automaticamente libera tokens

Seu papel é mais próximo de:

ERC-7444
  ↓
"Este ativo vence nesta data."

A lógica que efetivamente impede ou permite a movimentação continua sendo responsabilidade do protocolo.

Isso permite inclusive representar direitos sobre ativos bloqueados através de NFTs ERC-721 ou ERC-1155. A própria motivação do ERC menciona a utilidade de conhecer a maturidade desses direitos para melhorar sua avaliação e interoperabilidade.

8. O tempo passa a fazer parte do valor econômico

Aqui aparece um conceito bastante interessante.

Compare:

100 USDC disponíveis hoje

com:

100 USDC disponíveis daqui a 3 anos

Embora ambos representem nominalmente 100 USDC, economicamente os dois direitos não precisam possuir o mesmo valor presente.

Temos:

ATIVO
+
VALOR
+
TEMPO ATÉ MATURIDADE
+
RISCO
↓
VALOR PRESENTE

O próprio ERC-7444 discute a importância do tempo até a maturidade na avaliação de ativos bloqueados.

É uma excelente demonstração de como a tokenização começa a aproximar conceitos tradicionais do mercado financeiro da infraestrutura programável da Web3.

9. ERC-7720 — Deferred Token Transfer

Agora avançamos um nível.

Não queremos apenas descobrir quando um ativo vence.

Queremos dizer:

Transfira estes tokens para determinado beneficiário, mas permita que eles sejam retirados somente depois de determinada data.

Esse é o objetivo do ERC-7720 — Deferred Token Transfer.

A proposta está atualmente em estado Draft.

Seu fluxo básico é:

ALICE
│
│ ERC-20
↓
CONTRATO ERC-7720
│
│ bloqueado
│ até unlockTime
↓
BENEFICIÁRIO
│
│ depois do vencimento
↓
WITHDRAW

O depósito possui informações como:

token
from
to
amount
unlockTime
referenceNo
withdrawn

e recebe um identificador:

txnId

10. A função central do ERC-7720

A interface proposta inclui:

function transferFrom(
  address _token,
  address _from,
  address _to,
  uint256 _amount,
  uint40 _unlockTime,
  bytes32 _reference
)
  external
  returns (uint256 txnId);

E posteriormente:

function withdraw(uint256 _txnId)
  external;

O contrato registra:

txnId = 157

token       = USDC
from        = Alice
to          = Bob
amount      = 10.000
unlockTime  = 01/01/2028
withdrawn   = false

Antes da data:

withdraw()
 ↓
REVERT

Depois:

withdraw()
 ↓
verifica unlockTime
 ↓
transfere tokens para Bob
 ↓
withdrawn = true

Na referência publicada pela proposta, a condição fundamental é equivalente a:

require(
  block.timestamp >= transaction.unlockTime,
  "Current time is before unlock time"
);

11. Por que uint40?

O ERC-7720 usa:

uint40 unlockTime;

em vez de:

uint256 unlockTime;

Um uint40 possui 40 bits:

2^40 - 1

valores possíveis.

Interpretado em segundos, isso fornece aproximadamente 34.842 anos de intervalo, muito mais do que o necessário para aplicações normais de vesting, escrow ou pagamento diferido.

Ao mesmo tempo, tipos menores podem facilitar storage packing quando combinados corretamente com outros campos.

O padrão escolheu uint40 justamente para possuir alcance temporal suficiente para aplicações práticas de longo prazo.

12. ERC-7720 é muito interessante para escrow temporal

Imagine uma tokenização imobiliária.

O comprador deposita:

100.000 USDC

mas o vendedor somente poderá receber depois de uma determinada condição temporal.

Ou um vesting:

FUNCIONÁRIO
    ↓
100.000 TOKENS
    ↓
LOCK
    ↓
01/01/2028
    ↓
WITHDRAW

Ou pagamentos comerciais:

EMPRESA
 ↓
PAGAMENTO AGENDADO
 ↓
ERC-7720
 ↓
MATURIDADE
 ↓
FORNECEDOR

Há, entretanto, uma distinção importante:

passagem do tempo não é a mesma coisa que confirmação de um evento externo.

Se o pagamento depender de:

mercadoria entregue

ou:

documento registrado

o relógio sozinho não resolve o problema.

Teríamos algo como:

TEMPO
+
ORÁCULO / VALIDAÇÃO
+
REGRA CONTRATUAL
↓
LIBERAÇÃO

13. ERC-6229 — Vaults com períodos de bloqueio

Agora o problema muda novamente.

Imagine um vault compatível com ERC-4626.

Usuários depositam ativos:

USDC
 ↓
VAULT
 ↓
SHARES

Normalmente temos operações como:

deposit
mint
withdraw
redeem

Mas determinadas estratégias financeiras precisam utilizar os recursos durante um período no qual não seria adequado permitir entradas e saídas livremente.

É daí que surge o:

ERC-6229 — Tokenized Vaults with Lock-in Period

A proposta permanece em status Draft e estende o ERC-4626.

14. O ERC-6229 trabalha como uma máquina de estados

Podemos entender seu funcionamento assim:

O contrato disponibiliza:

isLocked
vaultRound

Quando:

isLocked == true

as operações tradicionais de:

deposit()
mint()
withdraw()
redeem()

devem ser bloqueadas.

Mas isso não significa que o usuário não possa manifestar sua intenção.

15. Operações agendadas no ERC-6229

Durante o período bloqueado existem operações como:

scheduleDeposit()
scheduleRedeem()

Imagine:

VAULT LOCKED
   │
   ├── Alice quer depositar
   │       ↓
   │ scheduleDeposit()
   │
   └── Bob quer resgatar
           ↓
     scheduleRedeem()

Quando o vault volta ao estado:

UNLOCKED

essas operações podem ser liquidadas através de:

settleDeposits()
settleRedemptions()

Temos portanto:

PEDIDO
 ↓
AGENDAMENTO
 ↓
LOCK-IN PERIOD
 ↓
DESBLOQUEIO
 ↓
SETTLEMENT

16. Um detalhe sofisticado do ERC-6229

O ERC-6229 deliberadamente não define como o início e o fim do período de lock devem ser determinados. A especificação deixa essa decisão para a implementação.

Isso é extremamente interessante.

Ele não diz necessariamente:

lockUntil = block.timestamp + 30 days

Ele padroniza principalmente:

ESTADO DO VAULT
+
OPERAÇÕES DURANTE O LOCK
+
LIQUIDAÇÃO

Portanto, conceitualmente poderíamos combinar:

ERC-6372
Contract Clock
    │
    ↓
regra temporal
    │
    ↓
ERC-6229
Vault Lock State

Essa combinação não é uma exigência dos padrões, mas representa uma arquitetura bastante coerente.

17. O problema do preço das shares

Existe ainda uma questão financeira importante.

Imagine:

Round 10

Alice agenda um depósito.

Mas não ocorre settlement.

Passam vários rounds.

Depois Alice tenta liquidar aquela operação.

Qual preço das shares deve ser utilizado?

O preço atual?

Ou o preço do final do round no qual ela entrou?

Esse problema é explicitamente reconhecido no ERC-6229. A especificação sugere estratégias como impedir um novo lock enquanto houver operações pendentes, forçar sua liquidação ou memorizar o preço final das shares de cada round.

Isso demonstra algo importante:

temporização em DeFi não é apenas um problema de relógio.

Também envolve:

TEMPO
+
ESTADO
+
PREÇO
+
CONTABILIDADE
+
LIQUIDAÇÃO

18. ERC-1132 — uma abordagem mais antiga para tokens bloqueáveis

Chegamos finalmente a uma proposta bastante anterior às demais.

Criada em 2018, ela aparece atualmente no repositório oficial como:

ERC-1132 — Extending ERC20 with token locking capability

e seu estado é Stagnant.

A ideia é interessante porque aborda o problema de maneira diferente.

Em muitos sistemas de staking ou escrow fazemos:

WALLET
 ↓
transfer()
 ↓
ESCROW

Os tokens deixam a conta original e ficam depositados em outro contrato.

O ERC-1132 propôs incorporar ao próprio ERC-20 mecanismos capazes de determinar:

SALDO TOTAL
 │
 ├── BLOQUEADO
 │
 └── TRANSFERÍVEL

sem exigir a transferência para um contrato de escrow externo.

19. Bloqueando tokens por motivo

Uma ideia particularmente interessante do ERC-1132 é utilizar:

reason

para identificar por que determinados tokens estão bloqueados.

A função proposta é:

function lock(
  bytes32 _reason,
  uint256 _amount,
  uint256 _time
)
  public
  returns (bool);

Poderíamos imaginar:

100 tokens → GOVERNANCE
200 tokens → VESTING
50 tokens  → COLLATERAL

Cada lock possui:

reason
amount
time

Então:

CARTEIRA DE ALICE

Saldo total:        1.000
Bloqueado:            350
Transferível:          650

A proposta inclui consultas para descobrir tokens bloqueados, tokens desbloqueáveis e saldo total, além de mecanismos para estender um lock ou aumentar sua quantidade.

20. ERC-1132 versus ERC-7720

Aqui temos uma diferença arquitetural muito interessante.

ERC-1132

O token permanece associado ao proprietário:

ALICE
 │
 ├── saldo total
 │
 ├── saldo bloqueado
 │
 └── saldo transferível

A funcionalidade de locking faz parte da arquitetura do token.

ERC-7720

O ativo ERC-20 já pode existir sem conhecer o padrão:

ALICE
↓
ERC-20
↓
DEFERRED TRANSFER CONTRACT
↓
LOCK
↓
BOB

O ERC-7720 foi deliberadamente concebido como interface separada do ERC-20, permitindo trabalhar com tokens existentes sem modificá-los.

Portanto:

ERC-1132
LOCKING DENTRO DO ECOSSISTEMA DO TOKEN

ERC-7720
LOCKING ATRAVÉS DE UM CONTRATO EXTERNO

São filosofias arquiteturais diferentes.

21. E onde entra o ERC-7444?

Vamos agora conectar as peças.

Imagine um sistema de vesting.

Temos:

TOKEN
↓
LOCK
↓
MATURITY
↓
RELEASE

O ERC-7720 pode cuidar do:

LOCK + TRANSFERÊNCIA DIFERIDA

Enquanto conceitualmente uma interface de maturidade pode permitir que outros sistemas perguntem:

Quando vence?

Esse é o domínio do ERC-7444.

E um contrato que precise tornar explícito qual referência temporal utiliza encontra no ERC-6372 a abstração de relógio.

Assim podemos enxergar três problemas diferentes:

ERC-6372
"QUAL RELÓGIO ESTOU USANDO?"
    ↓
CLOCK

ERC-7444
"QUANDO ESTE LOCK VENCE?"
    ↓
MATURITY

ERC-7720
"COMO FAÇO A TRANSFERÊNCIA FUTURA?"
    ↓
DEFERRED TRANSFER

Essa separação de responsabilidades é uma das partes mais elegantes desses padrões.

22. E o ERC-6229?

O ERC-6229 trabalha em uma camada diferente:

ERC-4626 VAULT
    ↓
LOCK-IN PERIOD
    ↓
SCHEDULED OPERATIONS
    ↓
SETTLEMENT

Ele não representa simplesmente:

token bloqueado até determinada data

Ele representa um sistema financeiro que alterna entre períodos operacionais.

Portanto podemos resumir os cinco padrões assim:

PadrãoPrincipal perguntaERC-6372Qual relógio o contrato usa?ERC-7444Quando o lock vence?ERC-7720Como programar uma transferência para liberação futura?ERC-6229Como operar um vault que possui períodos de lock?ERC-1132Como bloquear parte do saldo de um ERC-20 sem enviá-lo a um escrow externo?23. Estado atual das propostas

É importante não confundir a existência de um ERC com adoção universal ou finalização da especificação.

Em 18 de setembro de 2026, as páginas oficiais apresentam:

PadrãoSituaçãoERC-6372ReviewERC-7444DraftERC-7720DraftERC-6229DraftERC-1132Stagnant

Portanto, vários dos mecanismos estudados neste artigo devem ser vistos também como propostas arquiteturais em evolução, e não como padrões finais amplamente consolidados.

Isso é especialmente importante antes de utilizá-los em contratos financeiros de produção.

24. Não confunda Time Lock com execução automática

Talvez esta seja a principal conclusão prática deste tutorial.

Quando escrevemos:

require(
  block.timestamp >= unlockTime
);

não estamos programando:

EXECUTAR ÀS 14:00

Estamos programando:

ANTES DAS 14:00
  ↓
NÃO PERMITIDO

DEPOIS DAS 14:00
  ↓
PERMITIDO

Há uma enorme diferença.

Uma blockchain é essencialmente reativa às transações.

Portanto:

TIMELOCK
 ≠
SCHEDULER

O time lock controla quando uma operação pode ocorrer.

Um scheduler ou serviço de automação controla quem provocará sua execução quando chegar a hora.

25. Temporização pode ser representada em três camadas

Depois de analisar esses ERCs, proponho uma maneira didática de organizar o problema.

Camada 1 — Clock

Que referência temporal utilizamos?

Exemplo:

ERC-6372

block.timestamp
block.number
outro clock monotônico

Camada 2 — Temporal State

Qual é o estado da operação em função do tempo?

Exemplos:

ERC-7444

locked → mature

ERC-6229

unlocked → locked → unlocked

ERC-1132

transferable → locked → unlockable

Camada 3 — Temporal Action

O que pode acontecer depois da condição temporal?

Exemplo:

ERC-7720

deposit
 ↓
wait
 ↓
withdraw

Essa separação é extremamente útil no projeto de Smart Contracts mais complexos.

26. Uma arquitetura combinando os conceitos

Imagine um protocolo de ativos tokenizados.

Poderíamos conceitualmente ter:

O sistema poderia perguntar:

Qual relógio usamos?
      ↓
ERC-6372

Quando o ativo vence?
      ↓
ERC-7444

Como mantemos o pagamento bloqueado?
      ↓
ERC-7720

Como administramos períodos operacionais
de um vault?
      ↓
ERC-6229

Não significa que esses padrões obrigatoriamente devam ser combinados dessa maneira.

Mas essa visão demonstra como interfaces independentes podem construir uma infraestrutura progressivamente mais interoperável.

27. Cuidados de segurança

Contratos temporais precisam ser tratados com bastante atenção.

1. Não use timestamp como fonte de aleatoriedade

Tempo e aleatoriedade são problemas diferentes.

block.timestamp deve servir como referência temporal, não como um gerador seguro de números aleatórios.

2. Evite igualdade exata

Não faça:

require(block.timestamp == unlockTime);

Prefira:

require(block.timestamp >= unlockTime);

Não existe garantia de que uma transação será incluída exatamente naquele segundo.

3. Pense nas diferenças entre redes

Um contrato projetado para Ethereum pode ser posteriormente implantado em uma Layer 2.

Assumir implicitamente que:

N blocos = N segundos

pode introduzir erros de projeto.

É exatamente o tipo de ambiguidade que a abstração do ERC-6372 procura reduzir.

4. Timelocks modificáveis precisam ser claramente tratados

O ERC-7444 alerta que protocolos podem permitir extensão da maturidade. Uma aplicação que precifica ou aceita um ativo bloqueado como garantia precisa saber se o vencimento é imutável ou pode ser alterado.

5. Settlement precisa preservar a contabilidade correta

Como demonstra o ERC-6229, operações agendadas e liquidadas em rounds diferentes podem produzir erros de preço das shares se a implementação não definir corretamente sua contabilização.

6. Código de referência não substitui auditoria

Especialmente em propostas ainda em Draft, implementações publicadas junto ao ERC devem ser estudadas como referência da especificação — não simplesmente copiadas para contratos que movimentarão ativos reais.

Checks-Effects-Interactions, proteção contra reentrância, autorização, pausabilidade quando apropriada, testes de invariantes e auditoria continuam sendo responsabilidades da implementação.

28. Uma forma simples de lembrar

Podemos finalmente reduzir tudo a cinco frases:

ERC-6372
Que horas são para este contrato?

ERC-7444
Quando este ativo amadurece?

ERC-7720
Quando este pagamento poderá ser recebido?

ERC-6229
Em qual período operacional está este vault?

ERC-1132
Quanto do meu saldo continua bloqueado?

E isso revela algo maior.

Smart Contracts não servem apenas para representar:

QUEM POSSUI O QUÊ

Eles também podem representar:

QUEM POSSUI O QUÊ
+
QUANDO PODE UTILIZAR
+
QUANDO PODE TRANSFERIR
+
QUANDO PODE RESGATAR
+
QUANDO UMA REGRA PASSA A VALER

É essa dimensão temporal que permite construir instrumentos mais sofisticados de:

• tokenização;
• vesting;
• governança;
• escrow;
• crédito;
• investimentos tokenizados;
• pagamentos diferidos;
• tokenized vaults;
• direitos com maturidade;
• ativos do mundo real — RWAs.

O tempo deixa de ser apenas uma informação externa.

Ele passa a integrar a máquina de estados do contrato.

E entender essa diferença é fundamental para avançarmos de Smart Contracts simples para sistemas financeiros e jurídicos realmente programáveis.

Referências

As principais fontes utilizadas neste tutorial foram as especificações oficiais do Ethereum Improvement Proposals para ERC-6372, ERC-7444, ERC-7720, ERC-6229 e ERC-1132, além da documentação do Solidity sobre block.timestamp e block.number.

#Ethereum #Solidity #SmartContracts #Blockchain #Web3 #EVM #DeFi #Tokenization #ERC20 #ERC4626 #RWA #EthereumDevelopment #Tokenização