DWELL: Pay your rent with a yield-bearing stablecoin

[rohan-patra]

Summary

Added new token standard implementation and Foundry project setup:

1. SERC20 Token Standard

   • Introduced SIERC20 interface
   • Implemented privacy-preserving ERC20 with shielded balances/transfers
   • Added USDY yield-bearing stablecoin using shares-based accounting

2. Project Infrastructure

   • Set up Foundry project with:
     • Foundry.toml config
     • .env.example with local RPC
     • Comprehensive .gitignore
   • Added test suite and deployment scripts
   • Included forge-std library as dependency

3. Documentation

   • Updated root README with token project details
   • Added dedicated tokens/README.md explaining:
     • Privacy/yield challenges
     • Architecture (SERC20/USDY)
     • License (AGPL-3.0)

[raviriley]

LGTM

[lyronctk]

LGTM

LOL

[ssolit]

Would propose the following two revisions:

1. revert in private view functions instead of returning 0
   This would help dApps know whether the value is really zero or if something went wrong. It would be unfortunate for a dApp to believe something is really zero when it's not and use it for business logic. The contract could return a custom error, perhaps named UnauthorizedView?

How dApps could interface:
a) Caller contracts can use .call() to error handle if they want
b) The SRC20 could also provide a safeBalanceOf function that returns (bool success, uint256 balance)

2. For ISRC20, instead of providing events, have emitEvent functions that must be overridden
   For the default SRC20, these should be no-ops because we assume users want complete privacy from indexers. However, these functions can be overridden with custom behavior, which leaves the door open to future improvements (i.e. encrypted events)
   Requires replacing all emits in the SRC20 with calls to emitApprovalEvent, etc

[rohan-patra]

Would propose the following two revisions:

1. revert in private view functions instead of returning 0
   This would help dApps know whether the value is really zero or if something went wrong. It would be unfortunate for a dApp to believe something is really zero when it's not and use it for business logic. The contract could return a custom error, perhaps named UnauthorizedView?

How dApps could interface: a) Caller contracts can use .call() to error handle if they want b) The SRC20 could also provide a safeBalanceOf function that returns (bool success, uint256 balance)

2. For ISRC20, instead of providing events, have emitEvent functions that must be overridden
   For the default SRC20, these should be no-ops because we assume users want complete privacy from indexers. However, these functions can be overridden with custom behavior, which leaves the door open to future improvements (i.e. encrypted events)
   Requires replacing all emits in the SRC20 with calls to emitApprovalEvent, etc

I modified the original function to return the error, and added a new function that returns 0 on unauthorized attempts and also returns a boolean to indicate that the call was unsuccessful

Also updated the tests to expect the appropriate reverts

[ssolit]

comments for USDY

[lyronctk]

LGTM