Closed jcx120 closed 1 year ago
@paulbellamy It doesn't look like this contract needs to implement auth. I'll go over the contract methods to convince you.
Balance - This doesn't modify state, so adding auth does nothing here.
Deposit - This uses token::xfer_from
, which already requires authorization through token::approve
from the sender. After user A has approved this contract, anyone can call deposit on A.
Withdraw - The contract is already aware of the owner ID. It also knows the accounts that deposited a balance, along with the amounts. Let's say there's one deposit (AccountA, 5 xlm). If someone calls withdraw(AccountA, 5), then AccountA will get it's deposit back. It doesn't matter who actual calls withdraw here. It doesn't look like there's any point to keeping a deposit in an expired contract, so AccountA shouldn't care when the deposit gets sent back. The same logic applies for the owner and a successful crowdfund.
I'm planning on cleaning up the contract and adding tests, but wanted to make sure we're on the same page regarding auth.
Assuming you only allow withdrawals back to the initial depositor address (or the owner), then yeah, no auth needed. (as opposed to supporting withdraw-to-address). That seems like a great simplification 👍 and should make the contract simpler to understand as well.
Complete the crowdfunding contract.
SRC Code: https://github.com/stellar/soroban-example-dapp/blob/main/contracts/crowdfund/src/lib.rs
Workflow: https://github.com/stellar/soroban-example-dapp#user-workflows
To Do: