Não emprestamos dinheiro com capital próprio
A KEZS interliga investidores e financiadores de um lado e empreendedores e projetos do outro. Organizamos a necessidade de capital, as informações para análise, a formalização e a rastreabilidade. Os recursos destinados ao projeto pertencem aos participantes identificados na operação, conforme seus contratos e o prestador responsável.
A remuneração da KEZS corresponde aos seus serviços ou comissões contratadas. O valor aportado por um investidor não se torna receita da plataforma apenas por fazer parte de uma operação. Investidor, empreendedor, intermediador e prestador financeiro têm papéis distintos, que precisam ficar claros antes de qualquer compromisso.
Não avaliamos risco de crédito e não atribuímos scores
A KEZS não realiza análise de risco de crédito, não atribui score e não classifica projetos como investimentos aprovados ou seguros. A organização de informações e documentos não equivale a uma recomendação de investimento nem certifica a capacidade de pagamento da empresa.
Cada investidor realiza sua própria avaliação e due diligence: confere as informações, faz perguntas, consulta os profissionais que considerar necessários e decide de forma independente se deseja investir. É exclusivamente do investidor a decisão de aporte e a responsabilidade pelos riscos econômicos assumidos, inclusive prejuízos, perda parcial ou total do capital e os retornos eventualmente obtidos.
O empreendedor responde pelas informações que fornece e pelas obrigações que assume. Quando uma instituição financeira ou outro prestador fizer análise própria, ela será identificada como análise daquele responsável, conforme seu escopo. A independência da decisão do investidor não afasta os deveres legais da KEZS e dos demais participantes pelos serviços prestados e por seus próprios atos.
Não somos um banco
Uma interface de conta ou de fluxo de caixa não torna a KEZS uma instituição bancária. Contas, pagamentos, cobranças, transferências e outros serviços financeiros dependem dos prestadores responsáveis e do escopo contratado. A identificação da instituição que efetivamente presta o serviço deve estar visível para o cliente.
O modelo utiliza a separação entre o titular do recurso, o projeto ao qual ele está vinculado e a instituição que executa a operação. Não se deve confundir saldo previsto, saldo comprometido, dinheiro disponível e posição de investimento. Cada um tem significado e condições próprios.
Não somos uma corretora de câmbio
A KEZS não declara autorização para prestar serviços de corretagem de câmbio. Operações que envolvam conversão, custódia ou serviços de ativos virtuais precisam de estrutura e prestadores compatíveis com a atividade efetivamente realizada. A denominação de um saldo ou token não cria uma dispensa regulatória.
Quando um aporte ou pagamento envolver moedas diferentes, a documentação deve identificar ativo de entrada, ativo de saída, cotação, validade, custos, titularidade e confirmação. Trocar criptomoedas por reais e executar um pagamento são eventos diferentes: ambos precisam de registros e responsáveis.
KEZ$ não é uma promessa de retorno
Na arquitetura KEZS, a unidade KEZ$ relaciona a posição digital aos direitos e aos eventos da operação. Seu propósito é organizar a utilização e o acompanhamento dos recursos destinados aos projetos. Ela não deve ser confundida com participação societária, com o próprio contrato de empréstimo ou com garantia de que o investimento será pago.
Pagamentos e compras em reais exigem uma ordem identificada, saldo compatível, liquidação pelo prestador responsável e conciliação. A baixa de uma posição digital e a saída efetiva de dinheiro precisam corresponder, com valor, moeda, custos e comprovante verificáveis. O modelo permite saque em reais com débito ou queima do saldo KEZ$ correspondente. A solicitação reserva o saldo; a baixa definitiva depende da confirmação do pagamento pelo prestador. Falha confirmada sem liquidação libera a reserva. Resultado desconhecido mantém a solicitação pendente para conciliação.
Não apresentamos KEZ$ como mecanismo de especulação cambial nem como forma de eliminar risco de crédito. Reservas, emissão, custódia, conversão e direitos do titular são assuntos distintos da rentabilidade de um projeto. Recursos investidos em uma empresa não podem ser presumidos, ao mesmo tempo, reserva líquida disponível para resgatar outra obrigação.
O rastro precisa corresponder aos eventos reais
A cadeia de evidências começa pela origem confirmada do aporte. Em seguida, identifica a alocação ao projeto, a posição atribuída ao destinatário e cada uso dos recursos. Se houver conversão de ativo, pagamento, transferência ou devolução, esse evento precisa de referência própria e vínculo com a origem anterior.
Uma confirmação financeira deve vir da instituição ou do adaptador responsável, com verificação de autenticidade, titularidade, valor e estado da liquidação. Uma ação do usuário ou um campo “pago” no navegador não comprova que o dinheiro chegou. Referências repetidas devem ser detectadas para que a mesma notificação não gere dois registros econômicos.
O registro precisa distinguir evento confirmado, estorno e correção. Alterar ou apagar uma movimentação anterior impede entender o que aconteceu; uma correção deve preservar a relação com o evento original e informar seu motivo e sua autoridade. Rastreabilidade também exige conciliar o registro com a fonte financeira, não apenas encadear hashes.
Não confundimos hash local com blockchain
Histórico de aplicação, prova criptográfica e publicação em blockchain são evidências diferentes. Um hash permite conferir integridade diante de uma referência; uma prova de Merkle permite verificar inclusão em um lote; uma transação confirmada em rede ancora um compromisso naquele registro. Nenhuma dessas provas, sozinha, demonstra solvência ou veracidade de um comprovante bancário.
Uma ancoragem só deve ser apresentada como confirmada quando houver rede, contrato, identificação da transação e confirmação verificáveis. O histórico deve separar o que foi observado pelo sistema do que foi efetivamente publicado em rede. Uma raiz criptográfica calculada no servidor não será descrita como transação em blockchain.
Não publicamos documentos pessoais na blockchain
Transparência deve permitir que pessoas autorizadas compreendam origem, destino e condições. Isso não exige expor documentos, CPF, dados bancários ou toda a atividade financeira de um negócio. A arquitetura de provas utiliza referências opacas e compromissos criptográficos; o acesso aos dados detalhados depende de identidade e autorização.
Dados privados e informação pública precisam de tratamento distinto. Um projeto divulgado não autoriza publicar comprovantes, contatos ou contratos completos. Quem recebe uma prova deve conhecer seu alcance e as informações necessárias para verificá-la, sem ganhar automaticamente acesso aos demais projetos ou participantes.
Não garantimos aprovação ou rentabilidade
Investidores precisam fazer sua diligência, compreender o instrumento e avaliar a possibilidade de perda. Empreendedores precisam fornecer informações consistentes e entender as obrigações assumidas. Contratos inteligentes podem executar regras válidas sobre eventos confirmados; não fazem um cliente pagar, não criam demanda e não eliminam inadimplência.
Empresas de todos os portes e com CNPJ recente podem organizar um projeto. Isso não significa aprovação automática. Prazo, taxa, garantias quando houver e condições dependem da análise e dos participantes responsáveis. Uma confirmação de ciência de riscos não afasta deveres legais de quem presta o serviço.
Não somos um cartório público
A KEZS organiza formalização e rastreabilidade documental. Isso não substitui os atos de cartório, registros de garantias, assinaturas ou outras formalidades exigidas para cada direito. A confissão de dívida é celebrada entre as partes competentes; a plataforma não se torna credora ou garantidora apenas por organizar a documentação.
Um token ou referência digital não transfere automaticamente a propriedade de um bem. A ligação entre documento, direito, titularidade e registro aplicável precisa ser verificada. O objetivo da tecnologia é tornar o caminho mais verificável, preservando as responsabilidades e os instrumentos que dão fundamento à operação.