SNXweave Weekly Recap

November 23, 2022

The following post contains a recap of news, projects, and important updates from the Spartan Council and Core Contributors, as well as the Grants Council and Ambassador Council from last week.

Spartan Council and SIP updates

Present at the November 17, 2022 Spartan Council Weekly Project Sync:
Spartan Council: Adam, Afif, Burt, dsacks, Ethernaut, ksett, nana, TerraBellus
Core Contributors: Cavalier, Darius, David, db, Jordan, noah, Regina, Steve, Sunny

V2X is quickly being wrapped up, as SIP-288 was released, adding 1inch exchange contracts to the Direct Integration Manager. Afif explained that they’re starting with a 30 basis point Uniswap pool oracle because the fees and slippage from the Curve side are still pretty large, so this configuration makes more sense now.

As for V3, Noah said the team is just ripping through the code and making sure it’s ready for audit. They are also very focused on the migration plan and ensuring that all of the edge cases there are covered. The plan is to have all of V3 in audit in the first half of December.

And speaking of audit, all of the SIPs for Perps V2 (279, 280, 281, 285) are currently being reviewed by the auditors. The test net deployment is in progress, and just about everything is code-complete. Afif said basically all the features have been built in, and they’re still pretty optimistic about December.

There were also a few SIP presentations last week, all for V3, so let’s briefly review them:

SIP-306 proposes the migration plan, where collateral will be migrated to V3 and account tokens will be minted to existing stakers’ addresses. Noah said high-level: they’re aiming to launch the V3 system as a separate thing and use V3 to back V2. The major benefit to doing it this way is having a more progressive migration — where all of the integrations that are currently deployed and issued by the V2 system can continue to operate uninterrupted. This will drastically reduce the complexity of the migration process and also reduce the risk.

In anticipation of the migration, Noah said they would like to implement SIP-255 to burn the fees on the V2 system, which would automatically distribute those rewards pro rata across the backers of that debt (regardless of whether they’re on L1, L2, V2, or V3). They’d also like to roll out SIP-237 (Debt Migration) to allow stakers to move from L1 V2 to L2 V2 prior to migrating over to V3. We’ve included the V3 migration graphic that Noah shared during his presentation in our blog post, so go check that out to better visualize the whole process!

Next, SIP-307 was presented for the V3 Router Proxy Architecture, which is the base architecture for all V3-related systems. This new architecture minimizes complexity during releases, provides a novel way of overcoming the EVM’s smart contract size limits, and makes system upgrades very explicit to the community. Ale explained that the main change since the last presentation is that “satellites” have now been replaced by associated “systems.” The previous presentation said we would have something called satellites for those cases where each satellite would have its own module that connects it to the system. This solution simplifies all that — so now we’d just call it the associated systems module.

Lastly, SIP-310 proposes a “feature flag” mechanism to only allow certain addresses access to parts of the protocol. This allows specific functions to be restricted with a feature flag, and only SCCP-specified addresses are able to call them. Initially, feature flags will just be for the creation of pools and registration of markets in order to reduce risk to the protocol.

Grants Council

Present at the November 17, 2022 Grants Council meeting:
Grants Team: ALEXANDER, CT, cyberduck, JVK, Max

In Grants Council updates, the NFT project is still coming along well, with the whole Grants team working on different aspects of it. JVK said the developer for the smart contract is almost done, so the team will be working to get the website in a condition where the smart contract can be integrated. The whitelist is also in its final stages, and the lore is being written in greater detail. We might be hearing some alpha about this project soon so keep your ear to the ground!

Ambassador Council

Present at the November 15, 2022 Ambassador Council meeting:
Ambassadors: GUNNBOATs, Kevin, mastermojo, Matt, MiLLiE

In Ambassador updates, the team hosted another Spartan Space last week, this time with Aztec, which is a privacy by default rollup solution on Ethereum that is based on zero-knowledge technology. We got to meet Josh who joined the protocol in May and is leading the developer relations team at Aztec.

Josh wanted to emphasize that Aztec is truly zero-knowledge: it’s privacy-preserving, which is not common amongst other zero-knowledge rollups on Ethereum. He explained how users generate proofs on their computers that hide their transaction details and get sent to the network. They are then they’re rolled up by the Aztec sequencer into another zero-knowledge proof (zkProof), which is then published to a smart contract on Ethereum that verifies it. At its most basic, a zkProof is a technique where one party can prove to another party that something is true without revealing any other information about the statement other than the fact that it’s true.

Basically, what this means for users is, when you’re transacting on the Aztec network itself you get complete privacy. There is no public information leaked about who the sender of a transaction is, who the recipient is, or how much you’re actually sending.

The Ambassadors then asked Josh to talk about Aztec connect, which launched this past summer. He said they call it the VPN for Ethereum because it allows you to interact with any smart contract on Ethereum directly from an Aztec account. And you get anonymity with that transaction: all you see is someone from Aztec is interacting with an Ethereum L1 contract.

He also discussed the idea of aliases and how they work in the Aztec network. Basically, there’s a public/private key pair that designates an Aztec account, which you can use for anything you want to do on Aztec (such as decrypting your account balance, decrypting your transaction history, sending transactions). However, this isn’t ideal because the decryption key and the spending key are the same. So it would be hard to log into applications because you’d be sharing this sensitive key that could spend your notes as well as decrypt your notes.

Instead, you can register an account when you sign up for Aztec, which breaks this link between a decryption key and the spending key. When you register an account, you can add a new spending key, and then you can share your decryption key with applications that you log into. Those applications can now decrypt your transaction history, show your balance, and get your basic account info, but they wouldn’t be authorized to actually spend your funds (they would need the spending key to sign transactions for you).

And the alias comes in when you register your account and add a new spending key, where you will have the option for an alias (which is just a 20-character alphanumeric string that’s made to be more human readable).

As of now, Aztec has several integrations including: zk.money, Aave, Euler, Lido, and Element Finance. They also have a bunch of upcoming integrations with projects like Compound, Liquity, mStable, Index Coop, Reflexer, and Ribbon. During the call, Josh also gave a quick run-down on how a project would go about integrating with Aztec. So make sure you catch the recording to learn about that, as well as hear the other cool features that Aztec has to offer!

Podcast now also on YOUTUBE

SNXweave Anchor Podcast: https://anchor.fm/snxweave

Follow us on Twitter! @snx_weave

SIP/SCCP status tracker:

SIP-288: 1inch Direct integration, Status: approved

SIP-306: V3 Migration, Status: draft

SIP-307: Router Proxy Architecture (V3), Status: draft

SIP-310: Feature Flags (V3), Status: draft