Package faucet hands a small amount of GNOT to someone who has none, on the record, in two calls that are meant to travel in one transaction.
The chain's own faucet is gated and the people who most need a first coin are exactly the people who cannot ask for one: an empty account cannot pay the gas to call anything. So somebody else files the request on their behalf, an approver releases it, and both halves are on chain with a reason attached.
Why two calls and not one bank send
Request is permissionless and Approve is not. Splitting them puts the ask, its reason and who made it on chain even when the answer is no, and makes every payout name the request it settles. A plain send would leave a transfer with no why, and no way to refuse one in public.
They are meant to be sent together. A tm2 transaction carries a LIST of messages, runs them in order and stops at the first failure, and a failed transaction writes none of their state: only the fee and the sequence survive (tm2/pkg/sdk/baseapp.go, runMsgs and WriteCheckpoint). So a request and its approval in one transaction either both happen or neither does.
The id the second message cannot know yet
Approve names a request by id, and message 2 of a transaction cannot read what message 1 returned. A caller therefore reads NextID first and writes that number into the approval, which is a race: another Request landing in between shifts the id under it, and the approval would pay a stranger.
That is why Approve also takes the recipient and the amount it believes it is approving, and refuses when the stored request disagrees. The race then costs a failed transaction instead of the wrong person's rent.
What bounds the damage
The faucet spends only what has been sent to its own address, never the approver's balance, so the float is the ceiling and topping it up is a deliberate act. MaxPerRequest caps any single payout under that, and Withdraw takes the float back.
