Custody, signing, security and compliance

The initial profile is partner_managed: the Partner controls the cryptographic authority within its own environment. From the end user's perspective it is a Partner-custodial wallet, because the user does not receive a private key or seed and the Partner keeps the technical ability to sign within authorized policies.

The initial option uses a high-entropy master key per environment/deployment behind the Partner Signer Gateway. In the reference sandbox it is kept in a protected local secret file that only the gateway reads. In a real Partner deployment, the same boundary obtains the master key from the vault/secret store controlled by that Partner. The signer derives different keys via keyReference, chain, wallet, role and version. The B2B API works with references, public addresses, digests and signatures; it does not read the master key.

Funds are held in the users' ChainAccounts. They are not concentrated in, or routed through, a central ChatterPay hot wallet. Separate Partner-operated wallets can exist for gas, paymaster, treasury, liquidity or fees.

An EVM private key can be generated directly as a valid random 256-bit value using a cryptographically secure generator. Another common option in user wallets is to start from entropy and represent it as a BIP-39 mnemonic; the mnemonic, together with an optional passphrase, is transformed into a seed and then into an HD tree from which keys are derived via deterministic paths.

The seed phrase is root material from which many keys can be derived, one per account. That is why losing or compromising the seed can affect the entire derived set.

A BIP-39 passphrase is not a password a server can reset. Every passphrase produces a different, valid seed. If the user forgets the exact passphrase, the original wallet can become inaccessible unless a correct backup or an independently designed recovery mechanism exists.

That trade-off is central to self-custody: it reduces a third party's unilateral authority, but shifts backup and recovery responsibility to the user.

It reduces the initial baseline's operational complexity: there is a single root secret per deployment/environment that can be backed up, rotated and audited within the signing boundary, while the signer derives separate keys by wallet and role. In the sandbox that key lives in a protected secret file; in a real deployment it moves to the Partner's vault without changing the SigningProvider contract. The cost is a larger blast radius: compromising that master key can compromise every key derived from it.

That is why the design requires isolating the signer, applying least privilege, versioning derivation, separating roles, auditing every signature, and maintaining backup, restore and rotation procedures.

The main alternatives are: independent per-wallet keys in a vault; KMS/HSM with non-exportable keys; hardware-protected derivation where the provider supports it; and MPC/threshold signing, where no single party holds the complete private key. These alternatives reduce blast radius or exposure of cryptographic material at the cost of higher cost, latency and operational complexity.

The architecture defines a Partner signing service, called the Partner Signer Gateway.

This service receives a request that includes wallet, network, asset, amount, destination, nonce, expiration and payload hash. Before signing it must check workload identity, permissions, policies, limits and idempotency.

It returns the signature and an audit reference. The key stays inside the system controlled by the Partner.

The Partner controls:

• the cloud project;
• the network;
• IAM;
• deployment;
• key storage;
• backups;
• rotation;
• auditing;
• authorized people and services.

ChatterPay delivers the interface and the integration controls, but does not hold unilateral authority to sign or move funds.

No. The initial baseline uses a software signer isolated behind SigningProvider with a per-environment master key. The sandbox runs it with a protected local file; a real deployment connects it to the Partner's vault and applies IAM, network, audit, backup and limits.

Non-exportable HSM/KMS, independent per-wallet keys and MPC are hardening alternatives. They can be incorporated behind the same signing boundary without changing the financial API or the Operation lifecycle.

It depends on which authority was lost.

• A derived key or an operational validator can be rotated if a valid higher authority still exists.
• If the Partner's master key is lost but an intact backup exists, exactly the same material and derivation version are restored.
• If the master key is lost without a backup, derived wallets can be left without an authority able to sign; the ability to migrate funds depends on another still-valid on-chain authority existing.
• If a key is compromised, pause, rotation, revocation/redelegation and migration are applied according to that authority's scope.
• In self-custody, a lost seed/passphrase cannot be reconstructed from the address or from prior signatures.

EIP-7702 adds a special consideration: the EOA's native private key controls the code delegation, so it must be treated as a critical authority even when day-to-day operations use separate validators.

By default, the Partner is the source of truth for:

• verified identity;
• KYC;
• screening;
• risk assessment;
• transaction monitoring;
• approval, rejection or manual review;
• regulatory reporting;
• the relationship with the end user.

ChatterPay B2B receives minimal claims and evidence references to apply the technical controls for each operation. It does not need to store the full KYC file.

The final legal assignment must be reviewed for each deployment based on the activities actually performed.

The tenant is derived from the authenticated credential. It is not accepted from a free-form request field.

Every table, query, event, lock and metric includes tenant context. PostgreSQL uses a mandatory tenant_id and Row-Level Security as an additional barrier.

Isolation tests must cover read, modification and processing attempts across tenants.