Just finished implementing the MLPX Core Program in Anchor as part of @solanaturbine's week 3 task of the builders program.
Github: https://t.co/U8PKmfeQS4
This program uses cross program invocations into the MLPX Core program. @metaplex
Features 👇
1) Whitelist creators.
2) Let whitelisted creators create collections.
3) Mint CORE NFTs to those collections with plugins such as freeze/burn delegate and attached NFT metadata.
4) Freeze and un-freeze NFTs and update NFT metadata.
Wrote a Constant Product AMM program in Anchor for @solanaturbine's week 3 task of the async builders program.
Github: https://t.co/QikCKb8vkT
This time, had to write the tests along with the program.
As part of @solanaturbine's tasks for week 2 of the async builders program, I have built a vault, an escrow and an NFT staking program.
OS repos below:
Vault:
https://t.co/Rq0MA8Kf2V
Escrow:
https://t.co/uKDn6pwuKI
NFT Staking:
https://t.co/ssQgtavSog
The NFT staking contract involving the new Core Metaplex NFT standard which is going to be widely adopted was cool.
5) These 3 scenarios act as a definitive proof of concept for being able to produce a Threshold signature scheme for any arbitrary Solana transaction with any number of signers one of which is the aggregated public key.
6) This is the most industry standard and professional way of managing user private keys.
7) Unlike Shamir secrets, a central service never has a single private key capable of signing transactions.
8) The two isolated ED25519 private keys produce public and private messages, share the public messages, produce partial signatures over client sent transaction and communicate to share the partial signatures and produce a valid signature on behalf of the aggregated public key.
Tongue in cheek but @kirat_tw mentioned a fat @superteam bounty if this has not been implemented already.
I have implemented Threshold Signature Scheme signing for arbitrary Solana transactions modifying ZenGo-X's open source code to expose endpoints for clients over an Axum Rust backend instead of a CLI.
Instead of being able to produce a valid signature for just native SOL transfers, this implementation lets clients have any arbitrary transaction signed.
Open source code: https://t.co/sXJyoCOBjO
1) Able to generate a user facing aggregated ED25519 public key on behalf of which two (can be any number as per choice in production) isolated ED25519 private keys can produce a valid signature.
2) Able to produce valid signatures for the aggregated public key for native SOL transfer transactions.
3) Able to produce valid signatures for SPL token transfer transactions.
4) Able to produce valid signatures for transactions where additional Keypairs need to sign along with the aggregated public key such as creating a token mint by modifying signing logic.
Got this idea from the private key management videos from @kirat_tw's Cohort 3 and super devs lectures.
@kirat_tw@superteam@SuperteamIN@100xDevs.