> For the complete documentation index, see [llms.txt](https://veloriz-network-ltd.gitbook.io/veloriz-network-ltd-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://veloriz-network-ltd.gitbook.io/veloriz-network-ltd-docs/veloriz-protected-launch-infrastructure/founders-identity-and-background-verification-standard-fibvs.md).

# Founders Identity & Background Verification Standard (FIBVS)

Establishing Accountability Before Public Capital Is Accepted

Within the Veloriz Ecosystem, We believe trust begins with knowing who is behind the project. One of the persistent weaknesses of the digital-asset market is the ability for project founders to raise capital while providing limited information about their identity, background, experience, or accountability. When participants cannot confidently determine who they are supporting, the information gap between project founders and the public becomes significant.

The Veloriz Launch Protection Architecture addresses this problem at its first layer of protecting investors: Founder Identity & Background Verification.

Before a project is permitted to conduct a public sale through the Veloriz Ecosystem, its designated founders and key responsible individuals must undergo a structured identity-verification and background-due-diligence process in accordance with applicable requirements.

Veloriz's position is straightforward:

> If a project is asking the public to trust its vision with capital, the people responsible for that vision should be willing to establish who they are.

***

**1.1 Verified Founders**

As part of the Veloriz launch process, founders may be required to provide information necessary to establish and verify their identity, including:

Legal identity, Government-issued identification, Verified photograph, Professional background, Relevant experience, Previous business or project involvement, Jurisdictional information where required, and other information reasonably necessary for due diligence

Verification may be performed through appropriate independent verification providers and procedures designed to establish the authenticity of the information supplied.

The purpose is to create a verifiable relationship between the person(s) and the project they represent.

***

**1.2 Background Due Diligence**

Within the standards of Veloriz Ecosystem, project founder(s) must note that identity verification alone is not sufficient.

Where legally permissible and appropriate, Veloriz may conduct background checks and due diligence on founders and key project personnel to identify material information relevant to their eligibility to be able to conduct Public Sale in the Veloriz Public Sale System.

This may include examination of publicly available records, professional history, previous project involvement, disclosed business activities, sanctions-related screening, fraud-related indicators, and other legally permissible risk factors.

The objective is not to declare that a founder is "good" or "bad."

The objective is to identify material risks that prospective participants should reasonably know before a public sale takes place.

***

**1.3 Public Founder Disclosure**

A verified identity should not remain hidden behind an anonymous project profile.

As a condition of conducting a public sale in Veloriz Public Sale System, founders must provide explicit consent to the publication of their approved identity and profile information on the project's official Veloriz sale page, subject to applicable privacy and legal requirements.

A public founder profile may include:

Founder Name, Verified Photograph, Project Role, Professional Background, Relevant Experience, and Verification Status

This will help us to creates a direct connection between the project and the individuals publicly responsible for building it.

The community or individuals who might want to participate in the token sale activity are therefore not presented with only a logo, website and token contract.

Within the environment of Veloriz Sale System, it is the sole right of participants to see who is behind the project.

***

**1.4 Consent Creates Accountability**

Founder disclosure is not presented as an incidental feature. It is a deliberate condition of accessing the Veloriz Public Sale System.

By consenting to the applicable Veloriz terms, founders acknowledge that their verified identity and approved professional profile may be publicly displayed as part of the project's sale information.

This establishes an important principle:

> Public fundraising should come with public accountability.

Veloriz does not require founders to surrender unnecessary private information. Sensitive verification data should remain protected and should not be published simply because it was collected for due diligence.

The public sees what is necessary to establish accountability; sensitive verification information remains subject to appropriate privacy, security and legal controls.

***

**1.5 Verification Is Not an Investment Guarantee**

Veloriz makes an important distinction between verification and endorsement.

A founder being verified does not mean; Veloriz guarantees the project, Veloriz guarantees the founder's future conduct, the project is guaranteed to succeed, the token will increase in value, participants cannot lose money.

Instead, verification establishes that the individual has undergone the applicable identity and screening process and that the information presented through the Veloriz system corresponds to the verified person.

This distinction is fundamental to maintaining the integrity of the system. Verification establishes accountability. It does not manufacture trust.

Trust is strengthened through continued transparency, responsible conduct and fulfillment of commitments.

***

**1.6 Material Findings and Eligibility**

Where due diligence identifies material issues relevant to a project's eligibility, Veloriz may request additional information, impose additional conditions, delay the sale, or decline the project's participation.

Veloriz may also require additional disclosures where circumstances change materially after initial verification. The purpose is to prevent the verification process from becoming a one-time checkbox. Accountability must remain relevant throughout the launch lifecycle.

***

**1.7 The Veloriz Founder Standard**

The Founder Identity & Background Verification layer establishes the first principle of the Veloriz Launch Protection Architecture: **Know Who You Are Supporting.**

Before participants are asked to evaluate a project's technology, tokenomics or market opportunity, they should be able to establish the identity of the individuals publicly responsible for the project.

Veloriz therefore moves the standard from:

"Trust this anonymous project."

to:

"Here is who is responsible. Here is what has been verified. Here is what has been disclosed."

That difference matters.

Because transparency does not eliminate investment risk—but anonymity can make accountability almost impossible.

Veloriz Launch Protection Architecture

Verify the Founders. Establish Accountability. Disclose Responsibly. Then Open the Public Sale.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://veloriz-network-ltd.gitbook.io/veloriz-network-ltd-docs/veloriz-protected-launch-infrastructure/founders-identity-and-background-verification-standard-fibvs.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
