What Lantern hides — and what it doesn't

Lantern hides the giver, not the money. That distinction is the whole design, so it is worth being precise about.

Hidden

Who gave. Your wallet address never appears on a campaign. The privacy pool moves the funds, so observers see the pool paying the Lantern contract — not you instructing it.
The link between a deposit and a donation. Shielding funds and giving are separate events with no on-chain connection.
Who claimed. Refunds and payouts are authorised by proving knowledge of a secret, not by an address.

Donation amounts. Each donation's size is public. This is deliberate: it is what lets anyone verify the total is real. The amount is simply not attached to a name.
The running total, goal, and backer count. Read straight from the contract by anyone.
Deposits and withdrawals at the edges. Moving money into or out of the pool is a public ERC-20 transfer, as is its timing.

Timing correlation. Shielding funds and immediately donating can let an observer connect the two by timing. Separating them — by hours, ideally — weakens that link considerably. The give flow warns you when it detects this.
Distinctive amounts. An unusual figure is easier to single out than a round one. There is no technical fix; it is a matter of blending in.
Claiming reveals a secret in calldata. Starknet does not expose a general public pending transaction pool, so this is hard to exploit — but it is not zero risk, and a future version should bind claims to a specific caller.
Regulatory disclosure exists by design. STRK20 screens every deposit, and each user's viewing key is encrypted to an auditor key at registration. Private from the public is not the same as private from lawful oversight.

It measures, it doesn't trust. Each donation is derived from the contract's own measured balance change, not from a number the caller supplies. Since the public total is the entire basis for trusting a campaign, an inflatable tally would be fatal.
Only the pool can drive it. The privacy_invoke entrypoint rejects every caller except the STRK20 pool.
Claims are single-use and campaign-scoped. A refund cannot be taken twice, and a code from one campaign is useless on another.
Refunds and payouts are mutually exclusive. Refunds require the goal to have been missed; payout requires it met. Both require the deadline to have passed.

Unaudited. Lantern was built for a hackathon. It runs on mainnet and the logic is tested, but it has had no professional security review. Do not entrust it with significant funds.
No campaign moderation. Anyone can create a campaign. Deposit screening covers where the money came from, not what a campaign claims to be for.

Lantern contract: 0x06fed63d5a8a4af0d3edf59c01776883e29ee6730158a645a2c7204a0d93022c
STRK20 pool: 0x040337b1af3c663e86e333bab5a4b28da8d4652a15a69beee2b677776ffe812a

Source is public and MIT licensed: github.com/PhiBao/lantern · SECURITY.md