Skip to main content

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.

​
Engine

The non-custodial smart contract Barker deploys per partner per chain. Wraps an underlying ERC-4626 vault and splits accrued yield between Barker and the partner via on-chain fee bps.

​
Underlying vault

The yield source the engine deposits into — a curated ERC-4626 vault. Curated by Barker; the partner picks one per engine at deploy time.

​
AUM (assets under management)

Total assets currently held by the engine, denominated in the underlying asset (USDC). Equals engine.totalAssets() on chain.

​
Underlying APY

The yield rate emitted by the underlying vault — what the vault would pay a depositor with no fees. Sourced from on-chain reads + Barker’s protocol-specific transforms.

​
Net APY (for user)

What the end user actually earns after Barker’s and the partner’s fee bps are taken out: 
net_apy = underlying_apy × (1 − barker_fee_bps/10000 − partner_fee_bps/10000)
This is what you should display in your UI as “yield”.

​
Fee bps (basis points)

1 bp = 0.01%. Two configurable parameters set at engine deploy time:
FieldGoes to
barkerFeeBpsBarker treasury
partnerFeeBpsYour partnerFeeRecipient address
Both are fixed at deploy and configured per partner contract. Changing requires deploying a new engine.

​
accrueFee()

The contract method that materializes accumulated yield into engine shares for barkerFeeRecipient and partnerFeeRecipient. Anyone can call it; gas is paid by the caller. Barker runs an off-chain keeper that calls it on a sane cadence — partners typically don’t need to.

​
Sandbox vs production

A key-level distinction, not a host-level one. Same base URL api.barker.money, same chains — what differs is access scope and rate limit.
Key typePrefixAccessRate limit
Sandboxbk_test_*Read-only against a demo engine100 req/min
Productionbk_live_*Full access to your deployed engines1000 req/min
Sandbox keys are issued instantly after email verification. Production keys go through manual review (typically 1 business day).

​
API key prefix

The first 12 chars of an API key (e.g. bk_live_a3F2) — the only part of the key we keep in the clear. Used in audit logs, key listings, and last_used_at displays. The full key is bcrypt-hashed and unrecoverable once you lose it.

​
Outbound vs inbound webhook

  • Outbound: Barker → you. Notifies you of engine events (deployed, fee accrued, etc.)
  • Inbound: you → Barker. Notifies us of partner-side events (user KYC change, off-chain reconciliation)
Each direction has its own secret. See Webhooks.

​
Idempotency key

Any string you pick (UUID recommended) attached to an inbound webhook via X-Idempotency-Key. Resending the same key returns 200 duplicate without re-processing — safe to retry on network errors.

​
LiFi widget

Third-party cross-chain bridge UI that we embed inside the widget for users whose USDC is on a chain other than the one your engine is deployed on. Barker does not custody bridge flows; the widget hands off to LiFi and waits for the user to return.

​
Pending deploy

An engine product can be created in our DB before the contract is deployed on chain. During this window:
  • status is pending_deploy
  • engine_contract_address is NULL
  • The product is not listed in public /products responses
  • Your portal shows it as “Awaiting deploy”
Once Barker deploys the contract and the on-chain event is indexed, status flips to active and the address is populated.