Enterprise, Compliance e RWA — Trilha de Privacidade (OpenZeppelin e Nethermind)
Guardian PrivateReceivable
Quem pode ficar com este recebível?
O Guardian PrivateReceivable tokeniza um recebível empresarial fictício como um token RWA permissionado na Stellar Testnet. Contratos de identidade e conformidade decidem quem pode receber, manter ou transferir o ativo — operadores de conformidade verificam carteiras, congelam contas, pausam o ativo e liquidam o recebível quando necessário.
O que é a TOTVS?
A TOTVS é a maior empresa de software corporativo do Brasil. Seu ERP principal, o Protheus, é onde boa parte das empresas brasileiras registra e administra suas contas a receber: as notas e duplicatas que esta prova de conceito representa on-chain. Na pesquisa anual de TI da FGV-Eaesp, a TOTVS detém cerca de 34% do mercado brasileiro de ERP (empatada com a SAP) e cerca de 50% entre implantações menores (até aproximadamente 180 usuários), então um recebível modelado nos dados do Protheus reflete como esses ativos são de fato registrados no Brasil.
Fonte: Pesquisa Anual de Uso de TI da FGV-Eaesp (participação no mercado brasileiro de ERP).
O problema
Empresas possuem recebíveis que podem ser financiados, cedidos ou representados digitalmente. Ambientes corporativos e regulados exigem controle sobre quem pode receber, manter ou transferir os direitos econômicos associados — um token público padrão permite transferências irrestritas e pode expor informações que deveriam permanecer privadas.
Prova de conceito de hackathon — não é uma plataforma de valores mobiliários regulada, um produto de investimento real, um provedor de KYC/AML, nem um sistema aprovado para uso em Mainnet.
Como a conformidade é aplicada
Toda emissão e transferência do token passa pela mesma cadeia de verificação antes de ser confirmada on-chain.
- Rejeitada enquanto o token estiver pausado.
- Rejeitada se qualquer uma das carteiras estiver congelada — carteiras congeladas não podem enviar nem receber.
- Verificada no contrato identity-verifier — a operação falha se a carteira não estiver Verified.
- Verificada no contrato compliance-policy (can_transfer / can_create) para remetente e destinatário.
- Rejeitada quando o status do recebível é Settled.
Fluxo de demonstração
Quatro minutos, do início ao fim, pela interface web.
- Operador de conformidade verifica o Investidor A; o Investidor B permanece não verificado.
- Emissor faz o mint para o Investidor A — transação confirmada na Testnet.
- Mint/transferência para o Investidor B é rejeitada: destinatário não verificado.
- Investidor B é verificado; a transferência A → B é concluída com sucesso.
- Congela o Investidor B — transferência rejeitada: carteira congelada — depois descongela.
- Pausa o token — transferência rejeitada: token pausado — depois despausa.
- Liquida o recebível — novos mints/transferências são rejeitados: recebível liquidado.
Em produção na Stellar Testnet
Contratos já implantados para a demonstração.
IDs dos contratos
CCJ52CC6HZJEEL67XLRKSHY4YMFPHV57HWONI2CXLLWIRXNI722ZKASXCCPUMFWSLIW5XPO7OOIDXXQBYBAGA7FEAN6C657MFNIPRYZ2FCDAKWFVCATSFC2TS3ZTWEIHRNH6R3UHVYHQTA4RHFSZ36E2464N5N7MAPWFUWD5Estados de identidade e do recebível
VerifiedCarteira aprovada na verificação de conformidade e pode receber/transferir o token.UnverifiedCarteira ainda não verificada — mint e transferência são rejeitados.RevokedCarteira foi verificada e depois revogada — mint e transferência são rejeitados.ActiveRecebível está aberto — mint e transferência são permitidos quando em conformidade.SettledCiclo de vida do recebível está encerrado — mint e transferência são rejeitados permanentemente.