Lock & trust model
What is enforced on chain, who can do what, and what is still beta.
Feebric is built so that the people who receive creator fees do not have to trust the creator, and nobody has to trust Feebric. This page lists exactly what is enforced on chain, what is operated by us, and what is still beta.
The lock
A manager can lock a vault until a date. While now < lock_until:
- rules cannot be changed,
- the manager cannot be changed,
- the verifier key cannot be changed.
There is no exception for Feebric: the program has no admin path into a locked vault. The only lock operation is extending it (until ≥ lock_until). A vault needs at least one rule before it can be locked. The token page shows the lock date next to the coin name; "Unlocked · manager can edit" is shown otherwise, so holders know what they are looking at.
Roles
| role | can | cannot |
|---|---|---|
| Creator wallet | create the vault (seed of its address), pay rent | anything else after creation, unless it is also the manager |
| Manager | while unlocked: set rules, set manager, set verifier, lock | touch funds; change anything while locked; shorten a lock |
| Coin creator (on pump.fun) | point pump.fun's fee share at the vault | change where the vault routes fees |
| Verifier key | sign attestations that release social escrows to a recipient chosen by the account owner | redirect an escrow, sign for a different vault, rule or recipient than requested, or after 10 minutes |
| Anyone | settle, pay wallets and treasury, drip, buyback, expire escrows | move money anywhere the rules do not say |
| Feebric admin | rotate the treasury and admin keys of the program config | change any vault's fee or rules |
Permissionless by design
Every crank is an open instruction with the vault's own checks. Feebric runs the reference keeper so creators do not have to, but the money does not depend on it: if the keeper stopped, anyone could settle and pay the buckets, and the holders' shares would be paid to the same addresses.
Accounting invariants
sum_buckets = Σ rule.balance + treasury_pendingafter every settlement.- Drips pay pro-rata against the full circulating supply, so omitting holders can only under-pay, never over-pay anyone.
- A buyback's accounting is measured from the vault's actual balance change, and the program rejects a spend above the planned amount (
UnexpectedSpend). - Changing rules never takes a second fee: released buckets are redistributed as
carry.
The platform fee
10% of every inflow, taken at settlement, before the split. The value is a program constant copied into each vault at creation; a future program version cannot raise the fee of an existing vault. The fee's running total is shown on every token page.
The verifier
Social escrows need an oracle that confirms "this login is account user_id". Feebric runs one, but its power is narrow:
- It signs exactly one message shape,
FEEVAULT_SOCIAL_V1 ‖ vault ‖ rule ‖ platform ‖ user_id ‖ recipient ‖ expiry, and only when the logged-in account's numeric id equals the rule'suser_id. - The recipient is chosen by the account owner and bound into the signature; the expiry is ten minutes.
- The program verifies the signature through the Ed25519 instruction placed right before the claim, and checks every field against the rule.
- The verifier key is a per-vault parameter, not a program constant. A manager can replace it while the vault is unlocked, which is also the path to a different attestation source without a program upgrade.
Beta caveats
- The program is upgradeable. The planned upgrade authority is a Squads multisig with a 72-hour timelock; until then the deployer key holds it.
- The program has not been audited. Planned before mainnet: fuzzing of settlement and drip invariants, a static analysis pass, a verifiable build.
- Feebric runs on devnet. Nothing on mainnet yet.
- Known gaps are listed in FAQ & beta status.