We do not lend our own capital
KEZS connects investors and funders with entrepreneurs and projects. We organize capital needs, assessment information, documentation and traceability. Project funds belong to the identified transaction participants under their agreements and the responsible provider’s arrangements.
KEZS earns its service fees or contracted commissions. An investor’s contribution does not become platform revenue merely because it is part of a transaction. Investor, entrepreneur, intermediary and financial provider have distinct roles that must be clear before any commitment.
We do not assess credit risk or assign scores
KEZS does not perform credit-risk analysis, assign scores or classify projects as approved or safe investments. Organizing information and documents is not an investment recommendation and does not certify a business’s repayment capacity.
Every investor performs their own assessment and due diligence: checking information, asking questions, consulting any needed professionals and independently deciding whether to invest. The contribution decision and responsibility for assumed economic risks belong exclusively to the investor, including losses, partial or total loss of capital and any returns obtained.
Entrepreneurs remain responsible for the information they provide and obligations they undertake. Any assessment performed by a financial institution or another provider is identified as that party’s assessment within its scope. Independent investor decisions do not remove KEZS’s or other participants’ legal duties for their services and own conduct.
We are not a bank
An account or cash-flow interface does not make KEZS a bank. Accounts, payments, collections, transfers and other financial services depend on responsible providers and contracted scope. The institution actually supplying the service must be identifiable to the customer.
The model separates the owner of funds, the linked project and the institution executing the transaction. Expected receipts, committed balances, available cash and investment positions are different measures with their own conditions.
We are not a foreign-exchange broker
KEZS does not claim authorization to provide foreign-exchange brokerage. Conversion, custody and virtual-asset services need arrangements and providers appropriate to the activity actually performed. Naming a balance or token does not create a regulatory exemption.
Where funding or payment involves different currencies, documents must identify the incoming and outgoing assets, quote, expiry, costs, ownership and confirmation. Converting cryptoassets into reais and executing a payment are different events; both need records and accountable providers.
KEZ$ is not a promise of returns
In the KEZS architecture, the KEZ$ unit connects a digital position to transaction rights and events. Its purpose is to organize the use and monitoring of project resources. It must not be confused with equity, the loan agreement itself or a guarantee that an investment will be repaid.
Payments and purchases in reais require an identified order, sufficient eligible balance, settlement by the responsible provider and reconciliation. Reducing a digital position must correspond to the actual cash movement, with verifiable amount, currency, costs and receipt. The model permits withdrawal in reais against a corresponding KEZ$ debit or burn. A request reserves the balance; final reduction requires provider-confirmed payment. A confirmed failure without settlement releases the reservation. An unknown outcome remains pending reconciliation.
We do not present KEZ$ as foreign-exchange speculation or a way to remove credit risk. Reserves, issuance, custody, conversion and holder rights are separate from a project’s return. Capital invested in a company cannot simultaneously be presumed liquid reserves for redeeming another obligation.
The trail must correspond to real events
The evidence chain starts with the confirmed source of funding. It then identifies project allocation, the recipient’s position and each use of funds. Asset conversions, payments, transfers and returns need their own references and links to prior origins.
Financial confirmation must come from the responsible institution or adapter, with checks of authenticity, ownership, amount and settlement state. A user action or a browser “paid” field does not establish receipt of money. Repeated references must be detected so that one notification does not create two economic records.
Records need to distinguish confirmed events, reversals and corrections. Overwriting or deleting an earlier movement obscures what happened; corrections should preserve the original relationship and identify their reason and authority. Traceability also needs reconciliation against the financial source, not just linked hashes.
We distinguish local hashes from blockchain records
Application history, cryptographic proof and blockchain publication are different evidence. A hash supports integrity checks against a reference; a Merkle proof supports batch inclusion; a confirmed network transaction anchors a commitment in that network record. None alone establishes solvency or the truth of a bank receipt.
An anchor should only be described as confirmed with a verifiable network, contract, transaction identifier and confirmation. History must distinguish system observations from actual network publication. A cryptographic root calculated on a server is not a blockchain transaction.
We do not publish personal documents on-chain
Transparency should let authorized people understand source, destination and terms. It does not require exposing documents, personal IDs, banking details or a business’s entire financial activity. The proof architecture uses opaque references and cryptographic commitments; detailed data access depends on identity and authorization.
Private data and public information require different treatment. Publishing a project does not authorize disclosure of receipts, contacts or full contracts. Proof recipients should understand its scope and receive what is needed for verification without automatically gaining access to other projects or participants.
We do not guarantee approval or returns
Investors need due diligence, understanding of the instrument and assessment of possible loss. Entrepreneurs need consistent information and understanding of their obligations. Smart contracts can execute valid rules over confirmed events; they do not make customers pay, create demand or remove default.
Businesses of every size and newly registered companies can organize projects. That is not automatic approval. Term, rate, collateral if any and conditions depend on assessment and responsible participants. A risk acknowledgment does not remove service providers’ legal duties.
We are not a public notarial or registration office
KEZS organizes documentation and traceability. This does not replace notarial acts, security registration, signatures or other formalities required for specific rights. Debt acknowledgments are entered into by the competent parties; organizing documents does not itself make the platform a creditor or guarantor.
A token or digital reference does not automatically transfer asset ownership. The connection among document, right, ownership and applicable registration needs checking. Technology aims to make the trail more verifiable while preserving the responsibilities and instruments supporting the transaction.