> For the complete documentation index, see [llms.txt](https://docs.bextree.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bextree.com/security/security-principles.md).

# Security Principles

The rules the system is designed around — the "why" behind the architecture pages.

## 1. Hold as little as possible, for as short as possible

Assets sit in protocol contracts or the vault; payments sit in escrow with total exit paths. Bextree's own infrastructure holds neither. The marketplace database can influence *what gets listed*, but never *where money goes*.

## 2. Verify on-chain, don't trust reports

A settlement completes when chain state proves the buyer received the asset — never when the seller, the buyer, or Bextree's own database claims it happened.

## 3. Price every risk, or eliminate it

Where seller-failure risk can be eliminated (LP positions), it's eliminated by pre-custody. Where it can't (Streamflow), it's priced with a bond calibrated so that failure costs the seller more than performing.

## 4. No standing permissions

No accounts, no sessions with ambient authority, no signature that works twice. Every wallet-attributed action is authorized by a fresh one-time nonce signature.

## 5. Fail toward the refund

Every failure path in settlement terminates at the same place: the buyer's money comes back in full, automatically. When something breaks, the default outcome is that nobody's funds are stranded.

## 6. Keep the audited surface small

The on-chain programs contain settlement logic only — no marketplace features, no admin conveniences. Small programs are auditable programs.

## 7. Say what we can't prove yet

No audit has happened yet, and program IDs aren't published yet — and these docs say so plainly. Trust claims should be verifiable or absent.