The vault

A swipe does not have to be only a payment. The same privacy_invoke that settles a restaurant bill can route the rest of the withdrawal into a lending vault, so idle balance starts working in the transaction that spent the rest of it.

The point is atomicity rather than yield. Two separate transactions - pay, then deposit - publish an intermediate state where the value is out of the pool and not yet anywhere else. One transaction has no such moment.

A dinner that opened a position

The pool withdrew 10.24 STRK. The helper paid 0.24 STRK to the merchant and deposited 10 STRK into the vault, emitting AuthorizationSettled and PositionOpened in the same receipt. Private STRK notes went from 18.26 to 8.02, and the vault's total_assets went from 0 to 10.

Spending the position back out

Shares are not a one-way door. A later swipe can be paid by redeeming them: the vault returns the assets, the merchant is paid, and total_assets falls back to zero.

The bug worth publishing

The first vault class did not expose an allowance entrypoint. Calling it reverted with entrypoint does not exist, which meant the STRK20 pool could not pull the share note, and the atomic dinner-plus-lend could not settle at all.

The fix was a new class exposing allowance, deployed at 0x076811f2…cda8b. The old vault at 0x00474c6b…68bb is retired and stays listed in the evidence page rather than being quietly deleted, because a contract that was live and then abandoned is exactly the kind of thing a reader deserves to find named.

A second live failure came from the same family: the hosted account's STRK allowance was 1 STRK against a 2 STRK pool fee, so a hosted swipe reverted until the fee approval was topped up. Both are allowance bugs, and neither was visible from reading the code.

What is read live, and what is not claimed

Tests behind it

• 10 Cairo tests across the card program and the vault, run with snforge.
• The allowance regression is checked directly: the call reverts on the retired class and returns on the current one.