WHITE PAPER — Sollar Token (SLLC)

1. Resumo Executivo

O Sollar Token (SLLC) é um ativo digital do tipo RWA (Real-World Asset) emitido pela Sollar Machine Energy. Implementado no padrão ERC-3525 (semi-fungível), o token representa participação fracionada em infraestrutura de geração fotovoltaica e data centers modulares de inteligência artificial alimentados por energia solar.

O contrato inteligente SLLC.sol opera na rede Polygon (Chain ID 137) com pagamentos em USDT Polygon. Seus parâmetros centrais são:

O projeto integra quatro dimensões: narrativa institucional, arquitetura técnica do token, parâmetros operacionais do deployment e estrutura executiva. Quando há diferença entre a camada comercial pública e a camada on-chain, ambas são explicitamente distinguidas.

2. Visão do Projeto e Posicionamento

2.1. Tese Central

A SollarMachine propõe aproximar capital, infraestrutura de geração distribuída e tecnologia blockchain em uma estrutura RWA. A tese transforma investimento tradicional em energia renovável em uma experiência digitalmente nativa com fracionamento, rastreabilidade e governança parametrizável.

2.2. Proposta de Valor

• Energia off-grid 100% renovável — usinas fotovoltaicas com armazenamento BESS (Battery Energy Storage System).
• Arquitetura modular — módulos de 0,5 MW escaláveis até 100 MW.
• Data centers de IA — alta densidade (15–35 kW por rack), customizáveis por unidade.
• Regime fiscal otimizado — operação no Paraguai sob regime de maquila (0% importação, 1% exportação).
• Tokenização fracionada — acesso a investidores de qualquer porte via token ERC-3525.

2.3. Infraestrutura Existente

A comunicação pública informa 3 usinas solares prontas no Brasil (capacidade instalada de 6,3 MWp), baterias de 12 MWh para estabilidade off-grid e pipeline de 400 MW planejado. A produção de data centers modulares no Paraguai está prevista para 2026.

3. Estrutura Institucional

A comunicação pública associa diretamente o SLLC à Sollar Machine Energy, com sede na Av. João Cabral de Mello Neto, 850 — Bloco 3, Sala 228, Ed. CEO, Barra da Tijuca, Rio de Janeiro, Brazil, 22775-055.

A estrutura societária opera sob as entidades Sollar Machine SA e RUC, responsáveis pela governança contratual e operacional do ecossistema.

Para fins de governança documental, a Sollar Machine é a camada institucional e o SLLC é a camada operacional de tokenização. A formalização completa dessa relação requer documentação societária, regulatória e contratual específica.

4. Arquitetura Técnica do Token

4.1. Padrão ERC-3525

O SLLC.sol implementa o padrão ERC-3525 modelo semi-fungível que combina propriedades fungíveis e não-fungíveis por meio de slots. Cada slot define uma janela de investimento com datas de abertura/fechamento e limite máximo de captação.

4.2. Dependências e Compilação

4.3. Constantes do Contrato

uint256 private constant TOTAL_SUPPLY      = 3_250_000_000e18;
uint256 public  exchangeFeeBps             = 150;       // 1,50%
uint96  public  royaltyFeeBps              = 160;       // 1,60%
uint256 private constant BPS_DENOMINATOR   = 10_000;
uint256 private constant PRICE_SCALE       = 1e18;
uint256 private constant MIN_USDT_PURCHASE = 1_000_000; // 1 USDT (6 decimais)
uint256 private constant MAX_BATCH_SIZE    = 200;

4.4. Emissão (Mint)

Dois mecanismos de emissão:

1. purchaseTokens — investidor transfere USDT e recebe SLLC proporcionalmente. Exige aprovação prévia de USDT, correspondência de preço esperado, taxa máxima aceita e deadline.
2. adminMint — o owner pode cunhar tokens para endereços específicos (respeitando whitelist, limites de slot e supply cap).

Em ambos os casos, totalMinted + amount jamais excede TOTAL_SUPPLY.

4.5. Queima (Burn)

O contrato não expõe função pública de burn. Tokens emitidos permanecem no ecossistema.

4.6. Slots de Investimento

Cada slot possui ciclo de vida com quatro estados:

Created → Open → Closed → Finalized

Auto-close: se block.timestamp > closingDate, o slot é automaticamente fechado via _syncSlotState.

4.7. Fluxo de Compra

purchaseTokens(slotId, tokenAmount, expectedPrice, maxFeeBps, deadline)

1. Validações: amount > 0, deadline futuro, preço == tokenPrice, fee ≤ maxFeeBps.
2. Verificação de slot: estado Open, dentro da janela temporal.
3. Verificação de limites: slot e supply global.
4. Compra mínima: ≥ 1 USDT em valor base.
5. Cálculo de custo com Math.ceilDiv (arredondamento conservador).
6. CEI pattern: atualiza estado antes de chamadas externas.
7. Transferência de USDT com detecção de fee-on-transfer.
8. Mint do SLLC para o comprador.

4.8. Mecânica da Exchange Fee (Modelo Dedutivo)

A exchange fee de 1,50% é extraída do valor total pago (modelo dedutivo). O investidor paga exatamente o totalCost — a taxa não é adicionada por cima:

totalCost      = ceilDiv(tokenAmount × tokenPrice / PRICE_SCALE)
exchangeFee    = ceilDiv(totalCost × exchangeFeeBps / BPS_DENOMINATOR)
treasuryAmount = totalCost − exchangeFee

• treasuryAmount → enviado à treasury wallet (98,50%).
• exchangeFee → enviado à exchange wallet (1,50%).

Exemplo: compra de 1.000 SLLC a 1 USDT/token: o investidor paga 1.000 USDT → treasury recebe 985 USDT, exchange wallet recebe 15 USDT.

Limites: a taxa pode ser ajustada pelo owner entre 1 bps e 1.000 bps (máximo 10%).

4.9. Whitelist (KYC/AML)

O contrato implementa whitelist habilitada por padrão:

• addToWhitelist / removeFromWhitelist — operações individuais.
• batchAddToWhitelist / batchRemoveFromWhitelist — lotes de até 200 endereços.
• setWhitelistEnabled — toggle global.

Quando habilitada, apenas endereços autorizados podem executar purchaseTokens.

4.10. Funções de Cotação

A função quoteFromUsdtAmount utiliza divisão direta com ajuste de arredondamento para calcular o máximo de tokens dentro de um orçamento (modelo dedutivo v3).

5. Parâmetros Operacionais (Snapshot Polygon)

Snapshot administrativo do deployment ativo. Deve ser interpretado como fotografia operacional, não como substituto de auditoria on-chain independente.

6. Segurança do Contrato

6.1. Proteções Estruturais

6.2. Checklist de Auditoria Recomendado

1. Validar que nenhum cenário permite totalMinted > TOTAL_SUPPLY.
2. Testar _beforeValueTransfer bloqueia transferências quando pausado.
3. Verificar que whitelist não pode ser burlada em purchaseTokens e adminMint.
4. Confirmar cálculo correto de ceilDiv em todos os cenários de arredondamento.
5. Testar fluxo completo de lockUsdtAddress — irreversibilidade.
6. Simular ataques de reentrância nas funções com chamadas externas.
7. Validar auto-close de slots via _syncSlotState.
8. Testar emergencyWithdraw e withdrawEther para recuperação de fundos.

6.3. Funções de Emergência

• emergencyWithdraw(to, amount) — retira USDT acidentalmente enviado ao contrato.
• withdrawEther(to) — recupera ETH/MATIC enviado ao contrato.
• pause() / unpause() — suspende/reativa todas as transferências e compras.

7. Governança e Controle Administrativo

7.1. Modelo Atual

Governança centralizada via owner único com Ownable2Step. Não há DAO, votação por token nem governança descentralizada automática.

7.2. Poderes do Owner

7.3. Roadmap de Descentralização

O plano prevê transição da posse de carteira única para modelo multisignatário (Safe/Multisig) como próximo passo de maturação da governança.

8. Considerações Legais e Compliance

8.1. Classificação Regulatória

Como token RWA vinculado a projetos de infraestrutura com expectativa de retorno econômico, o SLLC pode ser enquadrado como security token em diversas jurisdições.

8.2. KYC/AML

O contrato implementa whitelist nativa para controle de identidade, atendendo requisitos de Know Your Customer (KYC) e Anti-Lavagem de Dinheiro (AML) conforme padrões FATF.

8.3. Jurisdições Aplicáveis

O projeto opera entre Brasil (sede corporativa, usinas solares) e Paraguai (data centers, regime de maquila). Ambas as legislações podem se aplicar conforme a natureza da operação.

8.4. Tributação se aplicável

Investidores devem observar tributação de ganhos de capital em criptomoedas e eventuais obrigações sobre royalties ou dividendos associados à infraestrutura.

9. Fatores de Risco

10. Equipe, Liderança e Capacidades de Execução

A estrutura de liderança combina capacidade executiva, profundidade técnica, coordenação comercial, suporte jurídico e desenvolvimento tecnológico orientado à implementação.

11. Roadmap

12. Conclusão

O projeto Sollar Token (SLLC) reúne elementos de tese relevantes: conexão com energia renovável, narrativa de ativo real, infraestrutura blockchain avançada (ERC-3525), guard rails operacionais robustos e equipe com competências distribuídas entre execução, engenharia, sistemas, jurídico e desenvolvimento.

O contrato demonstra maturidade técnica: proteção contra reentrância, detecção de fee-on-transfer, arredondamento conservador, limites rígidos de supply e taxas, governança em duas etapas e pausabilidade de emergência. A base técnica é concreta e a camada operacional está configurada e ativa na Polygon.

Apêndice A — Referência Técnica do Contrato

Eventos Principais

event SlotCreated(uint256 indexed slotId, uint256 indexed openingDate, uint256 indexed closingDate, uint256 maxAmount);
event SlotOpened(uint256 indexed slotId);
event SlotClosed(uint256 indexed slotId);
event SlotFinalized(uint256 indexed slotId);
event TokensPurchased(address indexed buyer, uint256 indexed slotId, uint256 indexed tokenAmount, uint256 usdtPaid, uint256 treasuryAmount, uint256 exchangeFee);
event AdminMint(address indexed to, uint256 indexed slotId, uint256 indexed amount);
event InvestorWhitelisted(address indexed investor, address indexed addedBy);
event EmergencyWithdraw(address indexed to, uint256 amount);

Custom Errors

InvalidAddress, InvalidAmount, InvalidSlot, InvalidTokenId, InvalidDates,
SlotNotOpen, SlotNotCreated, SlotNotClosed, SlotNotReady, SlotWindowViolation,
ExceedsSlotLimit, ExceedsTotalSupply, TransferFailed, FeeOnTransferDetected,
UsdtAddressLocked, DeadlineExpired, UnexpectedPrice, ZeroTransferAmount,
BelowMinimumPurchase, UnexpectedFee, NoStateChange,
NotWhitelisted, AlreadyWhitelisted, NotInWhitelist

Interfaces Suportadas

• ERC-3525 (Semi-Fungible Token)
• ERC-20 (Fungible, functions, Events via ERC-3525)
• ERC-721 (Non-Fungible Token, via ERC-3525)
• ERC-165 (Interface Detection)
• ERC-2981 (Royalty Standard)

Apêndice B — Nota Metodológica

Este white paper foi redigido com base nas seguintes fontes:

1. Código-fonte do contrato SLLC.sol (Solidity 0.8.34).
2. Informações públicas em sollar.energy e sollarmachine.com.
3. Snapshot administrativo do deployment na Polygon apresentado pela equipe.
4. Perfis profissionais fornecidos para composição da seção institucional.

Quando a informação decorre de material fornecido pelo próprio projeto e não de verificação pública independente, o texto a trata como dado informado ou snapshot operacional.

Apêndice C — Cobertura de Imprensa

• Data Center Dynamics — Sollar Machine bets on Paraguay for solar data center
• PV Magazine Brasil — Paraguai sediará data center autônomo movido a energia solar
• New Energy Events — Sollar Machine to build US$9M solar-powered data center in Paraguay