Yes, but what does that have to do with the structure of a bounty?

Bounty programs are very noisy. I don't even have a bug bounty program, and have several messages from confused people in my inbox asking about one. The "bugs" they propose are not bugs in my programs---for example, one reports that data can be uploaded to a collaboration system, downloaded, and then executed in a user-provided interpreter---and that this interpreter may surprise the user with its behavior.

Any better ideas of how to structure a bounty to get bugs and not confused users?

Saying something is theoretically possible with automated vulnerability scanners (which have incredibly high type 1 error due to out of date headers due to lazy programmers and misconfigured webservers) and showing that it's actually possible are completely different things. A whitehat proving he can get user access or MITMing data they created as a proof of concept is completely benign. I've yet to hear this as the source of a leak of customer data.