# Use Cases -- Sandbox

Feedback Partners are committed partners that will participate in a structured program for testing the Sandbox to (1) provide targeted feedback on protocol design, and (2) validate specific use cases.

We are targeting 1 (up to 2) Feedback Partners per use case, for the following use cases:

## Account Abstraction
**User story**: As a wallet provider on Aztec, I want to utilize native account abstraction to build a better UX for end users.

**Scope of Potential Sandbox project**: Implement an account contract ([TypeScript glue code here](https://github.com/AztecProtocol/aztec-packages/blob/master/docs/docs/dev_docs/wallets/writing_an_account_contract.md)); implement the UI for the corresponding account, as a means to showcase the UX; and provide feedback on the following topics: (1) optimal interface for an Aztec-native account abstraction standard; (2) fee management; (3) EIP1271-like signature validation [see here](https://discourse.aztec.network/t/account-guardians-eip1271-and-recursive-proofs/675/16); and (4) use cases if we choose to abstract encryption keys ([see here](https://github.com/AztecProtocol/aztec-packages/blob/master/docs/docs/concepts/foundation/accounts/main.md#encryption-and-nullifying-keys))

**Additional notes**: Here are two documents ([1](https://medium.com/starknet-edu/account-abstraction-on-starknet-part-i-2ff84c6a3c30) and [2](https://medium.com/starknet-edu/account-abstraction-on-starknet-part-ii-24d52874e0bd)) touching on how to implement an Account contract on StarkNet.

## Governance / voting
**User story**: As a NounsDAO holder, I don't want to trust Aragon for calculating/tallying the results of voting; I want to use a private governance solution on Aztec instead

**Scope of potential Sandbox project**: Pick a specific governance system and implement it end-to-end, including a rudimentary UI, incorporating the flexibility for governance systems to utilize different components of programmable private voting (e.g., vote privacy, tally privacy, etc.). Upon completion, provide feedback on what an optimal governance framework would look like.

## Blind auctions/other auction mechanisms
**User story**: As a marketplace dev, I want to facilitate a blind auction for optimal price discovery

**Scope of potential Sandbox project**: Design a novel auction mechanism using private state and/or private functions. Provide feedback on (1) the benefits and/or limitations of the network for unique blockchain-centric mechanism designs and (2) further areas of exploration for the design for novel applications of auctions on the network.

**Additional notes**: [other auction mechanisms blog post by a16z](https://github.com/a16z/auction-zoo)

## Compliance tooling / KYC
**User story**: As a user of an Aztec application, I want to prove compliance onchain without revealing my full identity

**Scope of potential Sandbox project**: Design an end-to-end compliance tool for proving 'cleanliness'/provenance of funds on the network without exposing identifying information of the user.

## Sybil Resistance Using Web2 Services

**User story**: As the developer of an Aztec application, I want to incorporate a sybil resistance mechanism using web2 services to prevent spammers/farmers/etc.

**Scope of potential Sandbox project**: Create a proof-of-concept of an Aztec-native sybil-resistance mechanism, potentially using web2 services as data sources. In other words, it may look like an Aztec-native version of something like [Gitcoin Passport](https://docs.passport.gitcoin.co/overview/introducing-gitcoin-passport).

## Donations / financial freedom
**User story**: As someone living without financial freedom, I want to self custody funds or make political donations without the fear of punishment

**Scope of potential Sandbox project**: Design a novel onchain fundraising / contributions-to-public-goods project (e.g., 'the Aztec version of Gitcoin'). Direct donations are almost trivial given a private token, but stuff like quadratic funding could be handled in interesting ways in a private environment, where the number of different contributions matters and not just the total funds. An end-to-end implementation of this.

## Betting markets
**User story**: As a frequent user of prediction markets, I want the weights of a market to stay hidden so that the number of people on either side are hidden, therefore making a more fair market

**Scope of potential Sandbox project**: Experiment with potential betting market applications on the network, such as card games, prediction markets, or other novel onchain betting market application.

**Additional notes**: [Geometry zkPoker article](https://geometry.xyz/notebook/mental-poker-in-the-age-of-snarks-part-1); https://zkholdem.xyz/wp-content/themes/zkholdem-theme/zkshuffle.pdf

## AztecConnect Functionality
**User story**: As an L1 Ethereum user, I want to do some things on L1 completely privately.

**Scope of potential Sandbox project**: Experiment with implementing a library and interface for managing claim notes associated with AztecConnect-like functionality. Provide feedback on an optimal interface for AztecConnect functionality.

**Additional notes**: [AztecConnect Uniswap functionality example](https://github.com/AztecProtocol/aztec-packages/pull/1796/files#diff-04d680358cda99f07c80d5b5150484baaa7696a5acb0a831eae5064451d82a73)

## Consumer Finance
**User story**: As an employee of a crypto startup, I want to privately interact with basic consumer finance primitives onchain (e.g., getting a loan based on my salary or onchain reputation, keeping money in a non-custodial interest-earning 'savings accounts', depositing into yield-earning 'Certificate of Deposits', etc.)

**Scope of potential Sandbox project**: Experiment with building a proof-of-concept for a massmarket consumer finance application on Aztec. Provide feedback on major network limitations for achieving consumer finance use cases. Provide feedback on potential contract standards for basic onchain financial primitives (e.g., yield-bearing token).

## Private Patreon
**User story**: As a creator with a supporting community, I want to give my community a way to 'subscribe' to my creative works onchain and privately. I might want to have different membership tiers, with NFTs as proof that you're a member of the tier, and I don't want supporters to have to doxx themselves. As a private supporter, I want to be able to support any cause, artist or project financially, without having to reveal to the world whom I support or be judged for it.

**Scope of potential Sandbox project**: Build an end-to-end proof-of-concept of a Patreon-like service for Web3, with a primitive UI for a mass market 'private Patreon' subscription application. Subscriptions could be once a month payments or private token streams--let's explore the feasbility and difficulties of each. *Optional:* use private NFTs to manage subscription tiers.

## Private Attestations
**User story**: As an attestation/credential issuer, I can issue an attestation that an Aztec account associated with a person or an organization has completed a task or is a member of a group. I might want to issue attestations that a person is a citizen of a country (something like a digital ID), a member of a student group or class (and that they have graduated), or makes a X amount of money and has X amount of debt (eg. credit issuers).

As an attestation/credential receiver, I can selectively reveal information about attestations that I have received. (eg. I make over $X / year, I am a citizen of a X country, I participated in X class). Using an example of getting a loan, the verifier of my attestation (eg. a bank) can check the issuer (eg. a credit bureau) and self assess their trustworthyness.

This could look something like [POAPs](https://poap.xyz/), but private--and allows recipients of the attestation (POAP) to selectively reveal information about the attestations that are associated with them.

**Scope of potential Sandbox project**: Build a proof of concept application that allows an attestation issuer to associate information with an Aztec account. The issuer should be able to update the attestation (eg. revoke it). Attestation recipients should be able to get their attestation data and generate proofs against it. Verifiers of attestation data should be able to verify that the proofs are correct and that it is valid, given the latest state of the Aztec network.

Details of the attestation can live off chain (eg. on decentralized storage).