Protocol

Byhnex On-Chain Rules

This summary is based on the current product codebase: Solana escrow accounts, USDC funding, wallet signatures, deterministic PDAs, and the current escrow state machine already implemented in the product.

1. Contract lifecycle

The current escrow flow is built around draft creation, funding, and release. Users should treat only the states exposed in the live application as active features, even if the wider codebase contains forward-looking structures for later phases.

2. Funding model

Funding is designed around USDC amounts stored as integer micro-units. The Solana program and backend both indicate a platform fee model and an escrow vault flow where the employer funds the contract and the net amount is locked until release.

3. Escrow finality

In the current escrow model, users should not assume a funded contract can be reversed outside the product flow actually exposed at signing time. The application should communicate clearly what happens after funding and release.

4. Fees

The current backend specification documents a 5% platform fee at funding. In practical terms, Byhnex takes 5% on each funded contract. Final percentages, treasury addresses, and fee destinations should always be checked against the deployed configuration and interface shown at transaction time.

5. DAO dispute roadmap

The dispute layer should be presented as a roadmap item, not as an already active production module. Based on your current product direction, DAO-based dispute handling is planned for a later phase and not before December 31, 2026.

6. Public on-chain program

The current Solana program identifier found in the project codebase is 4YNNcAsh3kfDXX5SeCPbQxHccjtkTkmw3Qwb62Crsy3d. This identifier should be treated as public reference information and can be surfaced to users for protocol verification.

7. Signature and verification

The product stack indicates that users sign transactions from the frontend wallet, while the backend stores and verifies expected transaction data, pointers, and signatures. Users remain responsible for reviewing destination accounts, amounts, and network before signing.

8. Source of truth

When there is any mismatch between marketing copy and protocol behavior, the deployed smart contracts, wallet prompts, and backend validation rules govern actual execution. Users should rely on the transaction details they sign and the state returned by the application.