> ## Documentation Index
> Fetch the complete documentation index at: https://docs.barker.money/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance & risk

> Custody model, KYC responsibilities, risk disclosures, and what you must show to your users before deposit.

<Note>
  This page describes Barker's compliance posture and provides **suggested user-facing language**. It is not legal advice. Consult your own counsel for jurisdictional requirements.
</Note>

## Custody model

Barker Yield Engine is **100% non-custodial**:

* User funds move directly from the user's wallet to a `BarkerEngine` smart contract via on-chain transactions the user signs themselves.
* Barker does not hold private keys, custody assets, or sign transactions on behalf of users.
* The `BarkerEngine` contract has **no admin withdrawal path**. The only ways assets leave are: (a) the share-holder calling `redeem` / `withdraw`, or (b) `EmergencyWithdraw` which redeems from the underlying vault back into the engine itself (does not transfer to any external party).
* Both Barker's and the partner's fee income are **share allocations** (yield-only, after the fact) — neither party can extract user principal.

## KYC / AML responsibility

The party who **onboards the end user owns KYC/AML**. In practice:

| Mode         | Onboarding party                                                        | KYC/AML owner |
| ------------ | ----------------------------------------------------------------------- | ------------- |
| Embed iframe | Partner — user lands in Barker iframe from inside the partner's product | **Partner**   |
| Headless API | Partner — user signs deposit in the partner's UI                        | **Partner**   |

Barker does not collect, retain, or screen end-user PII. If your jurisdiction requires KYC for the deposit flow, you must run it before the user signs `approve` / `deposit`.

For sanctions screening, treat the deposit as if you were the on-ramp: screen the wallet address against your sanctions list before allowing the transaction. Barker performs partner-level due diligence; partners perform user-level due diligence.

## What to disclose to your users

Before a user signs their first deposit, **show**:

1. **Non-custodial nature** — "Your funds remain on-chain in a smart contract; \[Partner] and Barker never take custody."
2. **Variable APY** — "APY is variable and reflects current rates. It is not a guaranteed return."
3. **Underlying vault risk** — "Yield is generated by an underlying ERC-4626 vault \[link to underlying]. Risks include smart contract bugs, oracle failures, depeg of stablecoin assets, and counterparty risk in the underlying protocol."
4. **No deposit insurance** — "Deposits are not covered by FDIC, SIPC, or equivalent deposit insurance."
5. **Withdrawal mechanics** — "Withdrawals execute on-chain and may be subject to underlying vault liquidity. In normal conditions, withdrawal is instant."
6. **Smart contract risk** — "BarkerEngine is open-source \[link to source]. Smart contract risk is inherent in DeFi; deposit only what you can afford to lose."

### Suggested copy block

```
By depositing, you acknowledge:

• Funds remain in your wallet's control via a smart contract — neither
  [Partner] nor Barker takes custody.
• APY is variable and not guaranteed. Past returns do not predict future
  returns.
• Yield comes from an underlying DeFi protocol [link]. You are exposed to
  that protocol's smart contract, oracle, and counterparty risk.
• Deposits are not covered by deposit insurance.
• You are responsible for tax reporting on yield earned.
• Withdrawals execute on-chain and depend on underlying vault liquidity.
```

Adapt to your jurisdiction's required language. We've seen partners place this as a checkbox before the deposit button, or as a one-time onboarding modal — both work.

## Audit & verifiability

* `BarkerEngine` and `BarkerEngineFactory` source code: [github.com/YBSbarker](https://github.com/YBSbarker), verified on each chain's block explorer.
* All AUM verifiable on-chain: any block explorer call to `engine.totalAssets()` returns the true total.

## Sanctions and prohibited jurisdictions

Barker's terms restrict the service from being offered to:

* Persons or entities on OFAC SDN, EU consolidated, or UK HMT sanctions lists
* Residents of comprehensively sanctioned jurisdictions (consult your counsel for the current list)
* Persons who would be prohibited from accessing DeFi protocols generally

Partners are responsible for enforcing these restrictions in their own product. If your user base spans jurisdictions, build a geo-block / sanctions screen into your onboarding.

## Tax

Yield earned through Barker is generally treated as **interest or investment income** in most jurisdictions, but tax treatment varies. Barker does not issue tax forms. Partners should:

* Surface a "view earnings" report (the `fee-stats` endpoint provides daily yield per user-position)
* Direct users to consult their own tax advisor

## Data we hold

For partner accounts (your team, not your end users):

* Partner organization name, contact email, fee recipient wallet address
* API key hashes (raw keys never stored)
* API request logs for rate limiting and abuse detection (typically 30 days)

For end users: **none directly**. We see anonymous wallet addresses from on-chain events, never PII.

## Contact

Compliance questions: [compliance@barker.money](mailto:compliance@barker.money). For partner-tier disclosures (e.g. financial statements, audit reports, due-diligence questionnaires), reach out via your account manager.

## What's next

* [Smart Contracts](/contracts-reference) — verify what you're integrating against
* [Webhooks](/webhooks) — `vault_pause` events let you halt deposits proactively