Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exploration on contracts for NotoDepositWithdraw #485

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

awrichar
Copy link
Contributor

@awrichar awrichar commented Dec 19, 2024

This is a proposal for what a smart contract would look like to support a withdraw/deposit pattern on Noto. Specifically, the pattern implemented here allows withdrawing some Noto value as an ERC20 and later re-depositing it as Noto.

  • Each withdrawal is a separate ERC20 token
  • Each withdrawal is also tracked as a UTXO state, owned by the withdrawer
  • ERC20 tokens may be moved around as normal without affecting UTXO states
  • ERC20 token owners may deposit ERC20 tokens back to Noto, which will spend+confirm UTXO states
  • While ERC20 tokens are in the clear, parties may use randomly chosen keys for pseudonymity

Pros:

  • Allows an infinite range of programmability by temporarily converting Noto to ERC20

Cons:

  • Some loss of confidentiality
  • Some nuance in representing ownership of withdrawn tokens until they are deposited again

This is not yet a formal proposal for inclusion in Paladin, but more of a discussion-via-code to determine if this is a useful pattern to pursue, or if it breaks too many features around privacy.

Also, because Noto already knows how to talk to Pente, it's possible that a private ERC20 could be used instead of one on the shared ledger - although I haven't mentally worked through the details of this. It would require a different set of methods on the Noto contract.

Signed-off-by: Andrew Richardson <[email protected]>
@awrichar
Copy link
Contributor Author

awrichar commented Dec 23, 2024

After having some discussion on where this landed, I've decided it's not actually deposit/withdraw. It's similar, but that pattern is a bit more about controlling supply and providing an alternative for mint/burn operations.

This has actually ended up being a form of locking and unlocking, using ERC20 for programmable delegation of locked amounts. It feels like it actually needs to end up as an extension of #483 (possibly the "hooks" on that feature should support this pattern as a way that you could handle custom locks).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant