Fund Verification: Service Terms

Effective date: 2026-03-23 · Last updated: 2026-09-09

1. Service description

Chain Daddy provides a fund verification service ("Fund Verification") for deal offers. Fund Verification checks the on-chain balance of a buyer's wallet at a specific block and creates a signed attestation of the result.

1.1. Fund Verification is required, not optional, for certain offers. A buyout, project acquisition or collab offer on an EVM chain cannot be created without a passing verification: the API refuses it with HTTP 402. This requirement was previously described here as optional; it is not.

1.2. Fund Verification is not required, and is not available, on Solana registrations. The Solana chain definitions carry no dollar-stable token address the check could read, so no Solana offer is asked for one.

2. Nature of verification

2.1. Fund Verification is a point-in-time balance check, not a guarantee, escrow, or hold on funds.

2.2. A passing verification confirms that, at a specific block number, the wallet held a balance meeting or exceeding the required threshold. It does not guarantee that funds will remain available at deal completion.

2.3. Verification results are informational. They do not constitute financial advice, credit checks, or underwriting.

2.4. A verification is valid for one hour. An offer submitted more than an hour after the balance was read is refused, and the buyer must verify again.

3. Attestation

3.1. When verification passes, Chain Daddy signs a cryptographic attestation containing the verification details. This attestation is:

• Stored off-chain in Chain Daddy's database and returned to the buyer
• Signed with a dedicated attestation key using the standard Ethereum personal-sign (EIP-191) envelope, so anyone holding the attestation payload and its signature can recover the signer address and compare it against Chain Daddy's fund-attestation signer

3.2. The attestation signer key is dedicated to fund verification and is separate from Chain Daddy's administrative keys.

3.3. The attestation commits to the buyer's wallet, the currency, the balance read, the required amount and percentage, the block number, the chain id, a hash binding it to the offer, and a timestamp. It does not commit to a block hash, so it does not bind the chain fork the balance was read on.

4. Limitations

4.1. Not an escrow or guarantee. Fund Verification does not lock, reserve, or custody any funds. The buyer retains full control of their wallet at all times.

4.2. Point-in-time only. Balances can change between verification and deal completion. Re-verification on an accepted deal provides updated information but is also point-in-time.

4.3. RPC dependency. Verification relies on third-party blockchain RPC providers. Temporary RPC outages may prevent verification. This is not a service failure.

4.4. Enforced by the API, not by a smart contract. The requirement in §1.1 is applied when the offer is created. No smart contract reads, stores, or enforces a fund verification, and no chain is consulted about one; a verification governs whether an offer may be made, not whether a deal may settle. This clause previously described Fund Verification as a "soft check" that "does not block deal progression"; that description was wrong in both halves.

4.5. Currency volatility. The required verification percentage adjusts based on 60-day currency volatility, from 20% up to 50%. This is a risk-adjusted threshold, not a guarantee against price movements.

4.6. Fail-open on unavailability. If Chain Daddy cannot read its own verification records — an unconfigured or unreachable store — offers are admitted without a proof rather than refused, so a storage fault does not take the deal system offline. The condition is logged.

5. Liability

5.1. Chain Daddy is not liable for deals where a verified buyer subsequently lacks sufficient funds. Fund Verification is a tool for informed decision-making, not a financial guarantee.

5.2. Chain Daddy is not liable for temporary unavailability of Fund Verification due to RPC provider outages, price API outages, or infrastructure maintenance.

5.3. Chain Daddy charges no facilitation fee for a deal, so no fee is available as a measure of liability for Fund Verification service errors. This clause previously capped liability at "the facilitation fees paid for the relevant deal", a figure that is always zero. Liability is governed by the general Terms of Service.

6. Data handling

6.1. Verification records (wallet address, balance, attestation hash) are stored in Chain Daddy's database and retained for the lifetime of the associated deal.

6.2. Wallet addresses are masked in system logs (first 6 + last 4 characters visible).

6.3. No attestation hash is published on any blockchain. Fund Verification is off-chain end to end: the attestation and its hash live only in Chain Daddy's database, and the deal settlement path — which calls the OpenCrown registry directly — never carries them. This clause previously stated that attestation hashes were publicly visible on the blockchain, contradicting §3.1 of this same document. Verification by a third party is done off-chain, by recovering the EIP-191 signer as described in §3.1; there is no contract function to call for it.

7. Availability

7.1. Fund Verification targets 99.5% availability as measured over rolling 30-day windows.

7.2. Scheduled maintenance windows will be communicated via the platform status page.

7.3. Offers of the types named in §1.1 cannot be submitted without a passing verification. On a buyout or a project acquisition, the registration's holder is shown, before accepting, what percentage of the offer the buyer proved they held — or that no proof was recorded, which is the ordinary case for an acquisition on a Solana registration. It is deliberately not presented as a guarantee, because a balance read is not one.