Giving software the authority to pay

Graduate · enrolled learners

This lesson opens with Furucombo, February 2021.

What happened

Furucombo was a tool that let users combine several decentralized-finance actions into one transaction, and to use it, users granted its smart contract an approval, permission to move specified tokens from their wallets on their behalf. That approval is the authority to pay: it lets the software spend the user's funds without the user signing each movement. In February 2021 an attacker exploited a flaw in how Furucombo's contract trusted another contract, tricking it into treating a malicious contract as legitimate, and then used Furucombo's existing approvals to transfer about 14 million dollars of tokens out of the wallets of users who had approved it. The users had not been hacked individually; they had given software the authority to move their funds, and when that software was made to misbehave, the authority they had granted was exercised against them. Furucombo did precisely what an approved contract can do, move approved funds, only at the direction of an attacker who had broken its logic. The lesson is not that the tool was uniquely flawed but that granting software spending authority hands that authority to whoever controls or subverts the software.

The decision point

Authorizing software to move your funds is not delegating a task; it is delegating spending power, and that power is exercisable by whoever controls the software or breaks it. An approval, an allowance, an API key, an agent's signing capability, each is the authority to pay, and it does not distinguish between the software using it as intended and an attacker or a bug using it otherwise. Furucombo is the demonstration: users granted a tool permission to move their tokens, and a flaw let that permission be used to drain them, because the authority, once granted, was simply available to be exercised. As payments move to autonomous agents, this is the central risk: an agent given the authority to pay can pay to the full extent of that authority, whether it is acting correctly, acting on corrupted logic, or compromised, and the payments are fast and final as the last lesson showed. So the decision when giving software the authority to pay is to scope and bound that authority to the minimum the task requires, a limited allowance rather than unlimited, a capped key rather than an open one, a narrow permission rather than a broad one, because the authority you grant is exactly the authority that gets abused, and an agent can only misspend what it was empowered to spend.

Recorded loss

$14,000,000

Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.

It is free. We do not sell the list and there is nothing to buy at the end of it.