Home What It Does Why This Matters Human Onboarding For Builders Capabilities Contracts Status GitHub

Phase 8: Human Onboarding

How Human Onboarding Works

Wallet provided → Role selected → Permission recorded → No funds move → Receipt sealed → Future actions require separate approval.

The Simple Version

Anyone can provide a wallet address to Quantum Pi Forge. That wallet is recorded with a role label and nothing more. No money moves. No keys change hands. No custody transfers. The entire process produces a sealed receipt that anyone can verify.

Financial Exposure: ZERO — Onboarding a wallet does not authorize any fund movement. It is a metadata receipt, not a financial transaction.

The Process

Human onboarding follows a fixed five-step sequence. Each step produces a sealed JSON receipt stored in the repository.

1

Wallet Provided

A human shares a public wallet address. This can be any chain: Bitcoin, Ethereum, OINIO, or others. Only the public address is recorded.

Input: bc1q...abc123

2

Role Selected

The wallet is assigned a role describing its purpose. Roles are metadata only. They do not grant authority.

Role: personal_support_wallet

3

Receipt Sealed

A JSON receipt is created recording the wallet, role, timestamp, git commit hash, and policy reference. The receipt is committed to the repository.

4

Policy Applied

The Wallet Onboarding Policy v1 is applied, clearly stating what this receipt does not authorize.

5

Milestone Sealed

A governance receipt seals the onboarding milestone. No further action occurs unless a new, separate receipt explicitly unblocks it.

Wallet Roles

Each onboarded wallet receives a role. Roles describe intent, not authority. The system treats all roles as read-only by default.

Supporter

A person who supports the project. No authority. No claims.

Builder

Someone contributing work. No deployment authority. No fund authority.

Observer

Watching governance or activity. No voting power. No claims.

Donor

Provided past support. No ongoing obligation. No control.

Foundation Candidate

Under consideration for a foundation role. No authority until explicit verification and legal steps.

Trust Candidate

Under consideration for a trust-related role. No authority until explicit verification.

What Onboarding Does NOT Authorize

A wallet onboarding receipt explicitly does not authorize any of the following:

No BTC Sends

No Bitcoin movement of any kind.

No OINIO Sends

No OINIO token transfers.

No Liquidity

No liquidity pool creation or funding.

No Treasury Routing

No treasury distribution or rebalancing.

No Staking

No staking or delegation authority.

No Minting

No token minting authority.

No Bridge Activity

No cross-chain bridge operations.

No Foundation Claim

No public foundation authority assertion.

No Identity Claim

No wallet-for-Kris or public identity claim.

Security Guarantees

No Private Keys — QPF never requests, stores, or accesses private keys, seed phrases, recovery words, or passwords.
No Custody — Onboarding does not transfer custody. The wallet provider retains full control of their wallet at all times.
No Automatic Movement — A receipt does not trigger fund movement, signing, or any on-chain action.
Roles Are Metadata First — A role label describes intent, not authority. Changing or confirming a role requires a new explicit permission receipt.
Every Unlock Requires a New Receipt — Anything beyond read-only onboarding requires a separate receipt with explicit scope, human approval, and the required verification steps.

Optional Future Unlocks

The following actions are not currently available. Each would require a separate receipt and explicit approval before it can proceed.

Signed Bitcoin Message Verification

A wallet provider could optionally sign a message proving they control the wallet. This would produce a separate verification receipt without authorizing fund movement.

Public/Private Permission Update

A wallet's role or visibility could be updated. This requires a signed permission from the wallet provider and a new receipt.

EVM Wallet Pairing Record

An EVM-compatible wallet (e.g., OINIO, Ethereum) could be paired with a Bitcoin wallet. This would be a metadata relationship record, not a bridge or transfer.

Safe-Controlled Support Vault Design

A multi-signature vault could be designed to accept support contributions. The design would be verified and receipted before any deployment or funding.

Current Onboarded Wallet

First External Human Onboarding: COMPLETE