Smart Contracts T-REX
Como a Axia emite e controla ativos tokenizados on-chain, os 4 modelos de contrato disponíveis, e o comportamento de cada smart contract. Foco em smart contracts e integração.
1. Os 4 modelos de tokenização
Toda oferta escolhe um modelo, definido por duas decisões: fungível vs NFT e regulado vs padrão.
| Modelo | Contrato | Fungível? | Regulado (KYC on-chain)? | Caso de uso |
|---|---|---|---|---|
| 1. NFT padrão | ERC-721 | Não (1 = 1 ativo) | Não | Colecionável, certificado simples |
| 2. Token padrão | ERC-20 (whitelabel) | Sim (divisível) | Não | Token utilitário, cota não-regulada |
| 3. NFT regulado | AxiaCompliantERC721 | Não | Sim | Certificado de investimento (1 NFT/investidor) |
| 4. Token regulado | ERC-3643 (suíte T-REX) | Sim | Sim | Cota negociável / security token |
- Padrão (1 e 2): transferência livre, sem identidade on-chain. Simples e barato.
- Regulado (3 e 4): cada transferência é verificada on-chain — só carteiras com identidade/KYC aprovada podem receber. É o que dá enforceabilidade regulatória (ERC-3643 é o padrão reconhecido para security tokens).
2. Camada de Identidade compartilhada (modelos 3 e 4)
Os dois modelos regulados compartilham a mesma infraestrutura de identidade por blockchain — construída uma vez por rede. É o que torna a tokenização regulada possível.
Papel de cada contrato:
- ONCHAINID (ERC-734/735): a identidade on-chain do investidor. Um contrato por pessoa, que guarda os claims (ex.: "KYC aprovado", "país=BR") assinados por um emissor confiável.
- IdentityRegistry (IR): responde "esta carteira está verificada?". Liga
carteira → ONCHAINID. - IdentityRegistryStorage (IRS): o armazenamento dos vínculos — compartilhado entre todos os tokens da chain, então o investidor faz KYC on-chain uma única vez e vale para todas as ofertas reguladas.
- TrustedIssuersRegistry (TIR): lista quem pode emitir claims válidos. Aqui = a Axia (que aprova o KYC off-chain e assina on-chain).
- ClaimTopicsRegistry (CTR): quais claims o token exige (ex.: KYC).
- ModularCompliance (MC): regras plugáveis de transferência (lock-up, jurisdição, limites).
3. Comportamento de cada smart contract
Modelo 1 — ERC-721 (NFT padrão)
- ERC-721 clássico.
transferlivre entre quaisquer carteiras. - Sem consulta de identidade. Sem freeze/recover.
- Comportamento: quem tem a chave, controla o NFT.
Modelo 2 — ERC-20 (token padrão / whitelabel)
- ERC-20 clássico, com
supplydefinido na emissão. transfer/negociação livres. Sem KYC, sem compliance on-chain.- Comportamento: token fungível comum.
Modelo 3 — AxiaCompliantERC721 (NFT regulado)
Contrato proprietário da Axia (auditável) que adiciona a camada ERC-3643 sobre um ERC-721. Toda movimentação passa por um único ponto de controle (_update):
Funções e comportamento:
| Função | Quem | Comportamento |
|---|---|---|
mint(to, tokenId, uri) | Agente Axia | Emite o NFT; reverte se to não verificado |
transfer (usuário) | Investidor | Só para carteira verificada; respeita freeze/pause/compliance |
setAddressFrozen(wallet, bool) | Agente | Congela/descongela uma carteira |
setTokenFrozen(tokenId, bool) | Agente | Congela um NFT específico |
forcedTransfer(from, to, tokenId) | Agente | Move por ordem judicial/correção; ignora freeze, mas exige destino verificado |
recover(old, new, onchainId, tokenId) | Agente | Recupera NFT de carteira perdida → nova carteira do mesmo ONCHAINID |
pause()/unpause() | Agente | Pausa transferências de usuário (mint/forced do agente seguem) |
burn(tokenId) | Agente | Queima |
Modelo 4 — ERC-3643 / suíte T-REX (token regulado)
Implementação de referência da Tokeny (open-source, auditada) do padrão ERC-3643. O Token é um ERC-20 cujas transferências consultam a mesma IR + Compliance:
| Função | Comportamento (vs modelo 3) |
|---|---|
mint(to, amount) | Fungível (quantidade, não tokenId); reverte se não verificado |
transfer | Igual: só entre verificados + compliance |
freezePartialTokens(wallet, amount) | Congela parte do saldo (granularidade que o NFT não tem) |
setAddressFrozen | Congela a carteira inteira |
forcedTransfer(from, to, amount) | Igual semântica |
recoveryAddress(lost, new, onchainId) | Recupera saldo completo para nova carteira do mesmo ONCHAINID |
pause/unpause, batch* | Pausa + operações em lote |
Mesma camada de identidade dos modelos 3 e 4 → um investidor verificado pode receber tanto NFT compliant quanto token fungível regulado, sem refazer KYC on-chain.
4. Fluxo de emissão (deploy do contrato)
A emissão é automática quando a oferta é ativada/encerrada, conforme o modelo configurado.
5. Fluxo de aporte → identidade → mint (modelos regulados)
A identidade on-chain é provisionada sob demanda (lazy) no momento do mint — o investidor não faz nada além do KYC normal.
Se o investidor não tiver KYC aprovado, o provisionamento falha e o mint reverte — por construção, ativo regulado nunca vai para carteira não verificada.
6. Fluxo de transferência (mercado secundário regulado)
P2P entre investidores e listagem em exchange funcionam desde que ambas as pontas tenham KYC — o que é exatamente o requisito de um security token.
7. Matriz de comportamento (resumo)
| Capacidade | Modelo 1 ERC-721 | Modelo 2 ERC-20 | Modelo 3 NFT regulado | Modelo 4 ERC-3643 |
|---|---|---|---|---|
| Transferência livre | ✅ | ✅ | ❌ (só KYC) | ❌ (só KYC) |
| Identidade on-chain (KYC) | — | — | ✅ | ✅ |
| Compliance on-chain | — | — | ✅ | ✅ |
| Congelar carteira | — | — | ✅ | ✅ |
| Congelar parcial (saldo) | — | — | n/a (NFT) | ✅ |
| Transferência forçada (agente) | — | — | ✅ | ✅ |
| Recuperar carteira perdida | — | — | ✅ | ✅ |
| Pausar token | — | — | ✅ | ✅ |
| Fungível / divisível | ❌ | ✅ | ❌ | ✅ |
| Reconhecido como security token | — | — | parcial¹ | ✅ |
¹ O NFT regulado usa o mesmo mecanismo de identidade/compliance do ERC-3643 aplicado a ERC-721; o selo formal "ERC-3643" é do modelo fungível.
8. Ações administrativas (modelos regulados)
Operadas pela Axia (papel Agente no contrato), sob permissão + autenticação reforçada:
- Recover só move ativos para uma carteira do mesmo ONCHAINID — não é possível desviar para um endereço arbitrário.
- Revoke identity remove o investidor da IdentityRegistry da chain → afeta todos os ativos regulados dele naquela rede.
9. Por que esse desenho
- Reuso, não reinvenção: o modelo 4 usa a suíte T-REX da Tokeny (auditada), padrão de fato para security tokens reconhecido por reguladores (ex.: VARA/ADGM). A Axia não reescreve o padrão — integra.
- Custódia transparente: o investidor faz só o KYC; a Axia (custodial) provisiona a identidade on-chain e paga o gas. A experiência é a mesma de um app comum.
- KYC on-chain único por chain: graças ao IRS compartilhado, o investidor é verificado uma vez e pode participar de qualquer oferta regulada daquela rede.
- Enforceável: uma transferência irregular não executa — não depende do backend estar correto/online. É garantia no nível do contrato.
Glossário
| Termo | Significado |
|---|---|
| ERC-3643 | Padrão de security token regulado (identidade + compliance on-chain) |
| T-REX | "Token for Regulated EXchanges" — implementação de referência do ERC-3643 (Tokeny) |
| ONCHAINID | Contrato de identidade on-chain do investidor (ERC-734/735) |
| Claim | Atestado assinado (ex.: KYC aprovado) guardado no ONCHAINID |
| Trusted Issuer | Quem pode emitir claims válidos (a Axia) |
| Agente | Papel administrativo no contrato (mint, freeze, recover…) |
| Compliance | Conjunto de regras on-chain que validam cada transferência |