Announcing the Aztec Sandbox Alpha Program

Supporting the earliest builders on Aztec’s privacy-first Layer 2

In September, Aztec Labs launched the Aztec Sandbox, a prototype local developer testnet for privacy-first applications on the Aztec network.

Shortly thereafter, we recruited a small group of dedicated blockchain and ZK developers to a friendly, closed-invite feedback partnership program.

We had three goals for this program:

Improve developer experience with added features
Stabilize the Sandbox with bug reports and technical feedback
Encourage experimentation and development of novel applications using the Sandbox’s Private Execution Environment (PXE) and public-private state management functionality

We’re now wrapping up the first round of closed-invite Sandbox feedback partnerships, with two more rounds to come, before we gear up for an open testnet launch.

We believe the Sandbox environment is alpha-ready: stable, well-documented, and well-featured enough for dedicated partners to use.

As a result, we are opening the alpha to developers in a hands-on program. Experience with Noir, Aztec, or Sandbox is strongly preferred but not necessary.

The Program

The Sandbox Alpha Program is meant to onboard the earliest, most hardcore, and most dedicated privacy-first developers. No prior experience with Noir, Aztec, or ZK is necessary, but alpha partners will need to have:

Exceptional technical skills
Ability to commit 15-20 hours a week for ~4-6 weeks
Regular check-ins with the Aztec Labs core team

In return, alpha partners will receive:

A modest stipend
Comarketing support
A dedicated core Aztec protocol engineer as a partner
Opportunity to be a highly valued member of the Aztec community and join early to voice your feedback in the development of our network
Help from the Aztec core team in building fully-fledged Aztec applications on Aztec’s eventual mainnet
And, of course, honor and glory

📝 If you’re interested in becoming an Alpha partner, apply here:

What’s so special about Aztec?

Aztec is a privacy-first layer 2 on Ethereum. What that means is Aztec enables:

Reading and writing smart contract data to private storage
Private execution of smart contract functions
Public-private state interactions in the same transaction

Aztec also comes with private L1<>L2 messaging functionality and native account abstraction.

Practically, smart contracts can store public information, legible to all, and also write information to private, encrypted datastores.

Users–and only users–are able to retrieve their own private data and compute over that data locally, on their own devices.

This not only establishes ironclad privacy, but enables broad new blockchain functionality. For starters, Aztec easily enables identity privacy, meaning every transaction in Aztec can start privately (from your account contract) which can then execute functions privately or publicly.

A dapp can have private and public methods in the same contract, with public-private contract calls.Aztec has identity privacy by default. Meaning even when applications are deployed to public memory, users can interact with those applications privately.

Feedback Partners Proofs of Concept

The design space for private applications goes far beyond “DeFi but private” or “NFTs but private” given that fully encrypted data ownership (“private state”) is now a reality.

Here are just some of the example projects built in the Sandbox during our closed-door feedback round:

Ikigai (web3 Patreon) - Resurgence Labs

As an example, take Resurgence Labs, who are building a project called Ikigai, a private web3 version of Patreon. The way Patreon works in web2 is individuals commit funds on a recurring basis to Patreon, unlocking rewards. Payments are verified using a web2 payment API (e.g. Stripe), allowing access to paywalled content.

👀 See the Ikigai project Github here.

How would you build a Patreon like service on Ethereum without forcing individuals to leak their subscriptions? For instance, on Ethereum everyone can see your address sending payments to your chosen creators.

Using the Aztec Sandbox, Resurgence Labs created a smart contract that allows individuals to purchase a private NFT–kept in one’s own encrypted datastore, which when proven to Ikigai, grants access to gated premium content.

The contract first mints an encrypted NFT with details of the subscription. At any time, the NFT owner can prove ownership and non-expiry of the NFT to Ikigai’s server.

“Unlike most web3 dapps, we can actually cite something other than decentralization as our USP over our web2 counterpart (say Patreon). With this feature, people can subscribe to something without having to let the world know about it (or be judged over it).”

Private Optimistic Oracle - DeFi Wonderland

Wonderland built a private ask-and-answer platform on which a requester can pose a private query for information. This query is encrypted specifically for a third party that can furnish answers for the requester, and all questions and responses are kept private to everyone but the involved parties.

👀 See DeFi Wonderland's Github projects here, here, and here.

The requester escrows funds privately to a contract, where the answerer can eventually redeem the funds, without any established relationship between the requester and the answerer.

Wonderland’s design opens up significant opportunities across messaging and oracle services:

Not only can individuals privately request information and data on-chain, but they can also exchange funds attached to answers furnished.

The notion that two parties can privately escrow funds in advance of a unilateral transaction is a powerful primitive we think could be used in everything from oracles to on-chain legal contracts and business agreements.

Zybil, a Sybil-Resistant Identity Protocol - Mach34

Mach34 created a mock of a Gitcoin Passport-style Sybil Resistance protocol that allows the creation of a sybil resistance score that encrypts “stamps” of data ingested from various web2 and web3 sources. By aggregating stamps, a public sybil score can be created for use in other applications, proving you meet a minimum sybil score without revealing the individual data sources used. Users can also post encrypted attestations to identity back to L1.

👀 See Mach34's project Github here.

In the future, such functionality can be extended to things like legal identities which could confer proof of age, residency, or other personal identifiable information without privacy leakage.

Aztec Labs has always believed provable attestations and identity would be a significant step ahead in securing blockchains, improving fair token distributions, and unlocking DeFi primitives like undercollateralized lending.

Imagine identity passports with completely private attestations, any combination of which a protocol can request in order for the user to access additional functionality.

Private On-Chain Poker - Zach Obront

Poker is a trivial game to design in a trusted game environment. A trusted dealer custodies face-down cards, shuffles them, and deals them to players. Players assume fairness in shuffling and distribution.

👀 See Zach's project Github here.

Zach Obront is an Aztec Labs grantee who developed a poker game with no centralized, trusted dealer. The players cryptographically generate the deck and use Aztec’s infrastructure to keep their cards private while performing betting and hand resolution logic.

Each player generates a secret key, derives a public key, and posts proof that they know the secret key corresponding with the public key.
Each player takes turns shuffling the order of the cards, and then encrypting the value. They submit a ZK proof that the shuffle was done legitimately.
After all players have shuffled, no group (except the whole table) could have colluded to know which encrypted value corresponds to which card, and all cards are encrypted with the aggregate public key.
To deal the cards, we count off which card belongs to which player, and everyone else decrypts it. Then the player can privately decrypt to view the card.

While playing fully on-chain poker is likely too transaction- and latency-intensive to be feasible, we believe such a design could be implemented using state channels (where the end state of the hand is settled on-chain) or an L3 built on top of Aztec.

“ZK proof of correct shuffle is as easy as a for loop. That would have been the bottleneck to the whole thing working in any other environment.”
– Zach Obront on choosing Aztec

Join the Feedback Program

We want to work with dedicated, privacy-first individuals and teams who are willing to commit to working with Aztec’s infrastructure on a collaborative and open basis.

We are at the frontier of blockchain privacy. So to paraphrase Ernest Shackleton, Antarctic explorer:

DEVS WANTED

For hazardous journey, small wages, bitter bugs, long months of debugging, constant updates, working code doubtful, honor and recognition in case of success

What we’re looking for

Prior experience with building apps/infra either for blockchains or the ZK domain
A commitment to collaborating on application concepts and feature improvements for Aztec
Solid foundational understanding of smart contracts, blockchain applications and Ethereum Layer 2’s

📝 To join our next round of Sandbox Alpha Partners, apply here.