SMART CONTRACTS, DEFI & WEB3 SECURITY - Chapter 10, Exercise 2 Solution
==========================================================
Why SimpleStake Isn't "Fully Non-Custodial"

PROBLEM
-------
Using this chapter's own custody discussion, explain why a user's
tokens sitting inside SimpleStake are not the same thing as "fully
non-custodial," even though no company or exchange is involved anywhere
in the design.

SOLUTION
--------
Chapter 9 defined custody around one specific question: who actually
holds the private key controlling an asset. Applying that same question
to SimpleStake reveals something easy to overlook - once a user calls
deposit(), their tokens move to the contract's own address, and the
user no longer holds the private key controlling those specific tokens
anymore. The contract's own code does.

WHY THIS DIFFERS FROM CHAPTER 9'S OWN FTX EXAMPLE
The obvious, important difference from FTX is that no company, and no
human decision-maker, controls what happens to those tokens while
they're deposited - only the contract's own public, auditable code
does. There is no equivalent of Alameda Research receiving a secret
exemption, because there is no human institution positioned to grant
one in the first place. This is a real and meaningful difference from
custodial-exchange risk.

WHY IT IS STILL A GENUINE FORM OF CUSTODY
But the underlying structural fact remains true regardless: for as long
as tokens sit inside the contract, the depositing user is trusting
something other than their own held private key to eventually let them
withdraw correctly. That trust is placed in the contract's own code
behaving exactly as written, rather than in a company's own internal
controls - but it is still trust in something external to the user,
which is precisely what "non-custodial" is meant to rule out entirely.
This is exactly why this chapter's own vulnerability finding mattered so
much: if the contract's own code had a real, uncaught flaw (as the
original draft did), that flaw would have been just as damaging to
depositors as a custodial exchange's own internal failure, even with no
company or exchange involved anywhere in the picture.

WHY THIS DISTINCTION MATTERS
Recognizing this distinction is what lets "custody" be understood
correctly as a spectrum rather than a strict binary. A centralized
exchange represents custody by an opaque company; a smart contract like
SimpleStake represents custody by transparent, auditable code - a real
and valuable difference, but not the complete absence of custody risk
that "non-custodial" might otherwise seem to promise.

ANSWER: SimpleStake is not fully non-custodial because, once a user
calls deposit(), they no longer hold the private key controlling their
own tokens - the contract's own code does, for as long as the tokens
remain deposited. This differs meaningfully from Chapter 9's FTX
example, since no company or human decision-maker controls those funds,
only public, auditable code - but it is still a genuine form of
custody, since the user must trust something other than their own held
key, exactly what "non-custodial" is meant to rule out. This is why the
chapter's own reentrancy finding mattered: a real flaw in that code
would have been just as damaging as a custodial exchange's own internal
failure.

----
WHY THIS WORKS AS AN ANSWER

It applies Chapter 9's own specific custody question (who holds the
private key) directly to SimpleStake's own deposit mechanism, and
distinguishes the real difference from centralized custody (code vs. a
company) without overstating that difference into a false claim of zero
custody risk.