[ANN] Validora (VLD) – On-chain certification & verifiability-focused token(BSC)

[Validora_Project]

Hello Bitcointalk community,

I’d like to introduce Validora (VLD), a live blockchain project focused on on-chain certification and verifiability.

Validora is already active on Binance Smart Chain mainnet and aims to provide tools for certifying and verifying digital actions, files, and events directly on-chain.
The project prioritizes transparency and technical substance over short-term speculation.

Current status:
- Network: Binance Smart Chain (mainnet)
- Token: Validora (VLD), live
- Staking: active
- On-chain certification & verification: active
- AI component (“The Guardian”): beta, available via Telegram for project-related queries

Project principles:
- Verifiability over hype
- Public, on-chain data
- Gradual and documented development

Important notes:
- No guaranteed returns
- No private support via DMs
- No aggressive marketing or paid promotions

This announcement is meant for documentation and technical discussion.

Official channels:
- Website: https://www.validora-project.com/
- X (Twitter): https://x.com/Validora_token
- Telegram (announcements): https://t.me/validora_token

Feedback and technical questions are welcome.

[flapduck]

I'm seeing different mentions of the hashing method (and that's the one thing you really can't be fuzzy about, because once people start certifying, changing the algorithm later breaks verification for everyone).

My suggestion is to pick one canonical digest scheme, and document it. Also, for anyone certifying sensitive docs, do consider offering an optional salt/pepper workflow (hash(salt || file) or similar) so people don't accidentally leak "this is the exact PDF from template X" to anyone who can precompute common hashes.

[Validora_Project]

Thanks for raising this — we fully agree that the digest scheme must be fixed and unambiguous from day one.

In Validora, the canonical and immutable digest scheme is:

keccak256(file_bytes)

Hashing is performed off-chain on the full file bytes, and the resulting bytes32 digest is the only value accepted by the on-chain certifier. The contract does not recompute or transform the hash.

This choice is structural: the NFT tokenId itself is derived directly from the digest, so changing the hashing algorithm later would break verification and is explicitly not planned.

We will document this clearly as part of the protocol specification and metadata.

Regarding the optional salt/pepper workflow: this is a valid privacy consideration.

An optional client-side salt can be used to prevent hash correlation on common or sensitive documents (e.g. standard templates), so that third parties cannot recognize a file by precomputing its hash.

Whether to use a salt is therefore a user choice based on privacy needs, not a security requirement.

While salting is not required, we may provide explicit client-side support for this workflow in the future (e.g. UI guidance, optional receipt export, and verification helpers).

Validora is intentionally hash-agnostic at the smart contract level. Any salting is performed off-chain by the user before submitting the digest, without requiring changes to the on-chain protocol.