(Credit to guiltygyoza of Topology who is the original creator and brains behind the Solve 2 Mint framework)

NFT emission today is primarily done using a predetermined fix supply (10,000, 8,888, etc.) and the owner of that NFT is simply who wins the bid or mints fastest. The rarity of the NFT is predetermined by the project team or seeded with some sort of on-chain randomness. The scarcity of the NFT received is either based on price paid or pure luck.

Solve 2 Mint is a framework for NFT emission where each NFT maps to a unique solution to an equation or puzzle. A user submits a solution through a contract call or a contract itself that meets the required specification of the Solve 2 Mint contract. When a valid solution is submitted, the user then owns that solution in the form of an NFT that uniquely maps to that solution.

The scarcity of a Solve 2 Mint system is not always straightforward. However, it is guaranteed to be finite when working in a fixed point number system. Certain puzzles may have many solutions, while others may have very few.

Structurally, solutions can be categorized into different families. A family of solutions can be loosely defined by the concept that once a solution is found for a given family, the rest of the solutions for that family can be easily found by perturbing (slightly modifying) the first solution. Therefore, it is ideal to differentiate the first found solution in a family from the rest of the family’s solutions.

The applications for building a Solve 2 Mint system within the context of different communities has the ability to be quite powerful. We are interested to hear what ideas the community has for applying Solve 2 Mint to different communities. Matchbox is pursuing building a Solve 2 Mint system for programming challenges to onboard and provide grants to developers building games on the Starknet ecosystem.

Solve 2 Mint systems can be roughly categorized into 3 different classes. Class C (Weak), Class B (Moderate), and Class A (Strong). There are implementations that can be taken from a Class A system and implemented in Class B to create an “in-between” or “Class B.5”. These definitions are loose and have been created to help understand the different types of options available within a Solve 2 Mint framework.

1. Class C (Weak)

   A Class C Solve 2 Mint system is one or more mathematical solutions that can be solved analytically. To mint an NFT, a user would read over the smart contract to understand the equations, and then solve the equations using off-chain software or custom programming logic. They would then submit their solution to the contract via a call.

2. Class B (Moderate)

   A Class B Solve 2 Mint system is an equation or puzzle that does not have a (or at least an obvious) direct analytical (closed form) solution, but can be solved using numerical methods. This makes solving the puzzle harder, but a competent competitor could run numerical simulations that exhaust the entire space.

3. Class A (Strong)

   A Class A Solve 2 Mint system accepts a smart contract as an input which contains logic that solves randomized versions of the challenge defined by the Solve 2 Mint system. A participant submits a smart contract that attempts to solve randomized trials by the Solve 2 Mint contract. An NFT is minted to the submitter if and only if the submitted smart contract passes all the randomized trials.

The concept of solution families is meant to recognize unique “ideas” or methods that lead to a solution for a specific puzzle. For example, imagine a physics puzzle where there is 1 player controlled object and 5 stationary objects. A solution is defined by a series of collisions leading to a score defined by some criteria. A family of solutions can be defined by the first object the player object collides with. So a player to find the first solution that’s first collision is with object X, they would be credited by being the first participant to find a solution for that solution family.

To summarize, a solution family is an informal definition where the goal is to credit the solution finder for recognizing “an idea” about how to achieve a certain score or solution.

Class C Theoretical Examples:

• A naïve physics equation such as simple projectile motion where the goal is to input an initial velocity and launch angle to hit a target d distance away.

Class B Theoretical Examples:

• A physics system that is defined by a certain set of equations or rules (friction, gravity, collisions, etc.) that has clearly defined goal or scoring system such as collision with a certain point or other object. A submitter must submit input variables that start the system and when the system has come to rest the score is above the scoring requirement threshold of the Solve 2 Mint contract. A prototype of an implementation like this is found on the 0xstrat v1 page of the Topology github here.

• A maze where the player is positioned at a certain coordinate of the maze to start and must navigate out within N number of moves. A participant must submit a valid sequence of moves that exits the maze.

• A Rubik’s cube of size N x N with a known starting position (i.e. the squares always start in the same spot or they are changed after a solution is submitted). A participant must submit a valid sequence of moves that solves the Rubik’s cube.

Class A Theoretical Examples:

• A contract that generates polynomial equations of degree 1 ≤ n ≤ N where n is random but N is known. Each equation has at least one solution. The submitted contract would be challenged with M random polynomial equations to solve and submit a response. The submitted contract would need to solve and submit a valid solution for each trial. If the contract returns a valid solution for all trials, the NFT is minted to the contract submitter.

• A physics system that is defined by a certain set of equations or rules that has a clearly defined scoring system. The system is seeded by a form of randomness where the objects in the system may be in random locations or the goal for the scoring may be different (collide with the green circle, collide with both the green and red circle, etc.). The submitter would submit a smart contract that must pass a series of randomized trials by the Solve 2 Mint system. A prototype of this implementation can be found on the 0xstrat v2 page of the Topology github here.

• A contract that randomly seeds a Rubik’s cube of 3 x 3 ≤ n x n ≤ N x N squares on each side. There are 6 sides (and consequently 6 colors) on a Rubik’s cube so 6 * n^2 total squares. The positions of the squares are random. The submitted contract must solve each randomly seeded Rubik’s cube with a sequence of valid moves less than a difficulty level D which is the maximum number of moves (likely scaled for the size of the cube).

• An open information abstract strategy game (like Chess or Onitama) where the submitted smart contract plays against the Solve 2 Mint contract in a series of games. A target win rate must be accomplished over the sample to mint the NFT. If the NFT is defined as the moves of a game in order (1. e4 e5, 2. ... , etc.), the combinatorics of the game make the solution space very large. A family of solutions could be defined by the classical chess openings (Sicilian, Italian Game, Ruy Lopez, etc.).

• Class C (Weak) systems are easily solved with off the shelf solutions or known analytical equations and are vulnerable to sniping and model a first come, first serve environment.

• In certain cases, the system may need a way to monitor the resources used or the efficiency of a submitted solution. Choosing or designing this measurement may not always be trivial.

• Class B (Moderate) systems may be prone to a case where the first participant to find a numerical solution finds ALL the numerical solutions to the puzzle and mints the entire solution space. A counter to this is absorbing parts of the Class A definition into Class B by imposing a randomized trial with a time restraint. A participant would register their address and kick off the trial process. In return, they receive a randomized trial from the solve2mint contract that must be solved within a certain time frame. This can be extended to include multiple trials over multiple time periods.

• Class A (Strong) systems are not trivially mapped to a unique solution. Many contracts that efficiently solve a system will share logic. For example, just using the hash of a given solver contract as a form of uniqueness does not stop an adversary from trivially changing the contract’s hash by altering a variable name and submitting it as their own work. A possible counter to this is only accepting solutions that improve upon the efficiency (see above) of the last previously accepted solution.

• The integrity of the mint will still fall partially upon the puzzle developer, except possibly in the case where they develop a puzzle with requirements and do not know if there even exists a solution. Presumably in many cases the puzzle developer will know of at least one solution and should keep this secret to ensure a fair gameplay experience if the environment is designed to be competitive. There is not much a puzzle developer can do to prevent a participant who has previously solved the puzzle from sharing a related but different solution with a friend. This is where differentiating between families of solutions and/or efficiencies of solutions is important.

Matchbox is working on an initial proof of concept for a Solve 2 Mint system that serves to onboard already proficient (but not necessarily proficient in Cairo!) developers into the Starknet ecosystem. The first iteration of the Matchbox DAO Solve 2 Mint Challenge will likely be a Class B challenge of a physics puzzle similar to the prototype on Topology’s github. Developers will have to study and understand the Cairo contracts, design off-chain computation in the programming language of their choice to compute solutions, and then submit a unique solution to the challenge contract. A few winners will be chosen by a criteria (likely top score or fastest to solve above a certain scoring threshold), and presented with grants to pursue their development goals on Starknet.

Matchbox plans to run many more future iterations of the Solve 2 Mint challenge with different prizes and varying levels of difficulty. We hope that the Solve 2 Mint concept will take on legs of its own within the community and members will design all sorts of interesting and unique challenges to be used in future competitions.

Solve 2 Mint provides the perfect opportunity for gamified learning and rewards. Developers that successfully complete the Solve 2 Mint system will have showcased great potential for building in Cairo on Starknet.

Solve 2 Mint is a framework for NFT emission that focuses on intellectual competition as a form of minting rather than traditional NFT emission frameworks like auctions or first come first serve sales.

Matchbox is launching a Solve 2 Mint Challenge in the context of its community for onboarding developers interested in learning about Cairo and developing games on the Starknet ecosystem.

Be on the lookout for future announcements about the competition including prizes and timeline!

Sound interesting? Come join us and help build the future of gaming on blockchain.

Follow Matchbox DAO on Twitter here.

Join the Matchbox DAO Discord here.

Read the Matchbox DAO Notion (Work in Progress) here to learn more about what Matchbox is and is working on.

Topoloygy Github with a prototype implementation

guiltygyoza blog post: Conceptualizing on-chain trial protocols for knowledge

Written by Derked on 3/2/2022

(Credit to guiltygyoza of Topology who is the original creator and brains behind the Solve 2 Mint framework)

NFT emission today is primarily done using a predetermined fix supply (10,000, 8,888, etc.) and the owner of that NFT is simply who wins the bid or mints fastest. The rarity of the NFT is predetermined by the project team or seeded with some sort of on-chain randomness. The scarcity of the NFT received is either based on price paid or pure luck.

Solve 2 Mint is a framework for NFT emission where each NFT maps to a unique solution to an equation or puzzle. A user submits a solution through a contract call or a contract itself that meets the required specification of the Solve 2 Mint contract. When a valid solution is submitted, the user then owns that solution in the form of an NFT that uniquely maps to that solution.

The scarcity of a Solve 2 Mint system is not always straightforward. However, it is guaranteed to be finite when working in a fixed point number system. Certain puzzles may have many solutions, while others may have very few.

Structurally, solutions can be categorized into different families. A family of solutions can be loosely defined by the concept that once a solution is found for a given family, the rest of the solutions for that family can be easily found by perturbing (slightly modifying) the first solution. Therefore, it is ideal to differentiate the first found solution in a family from the rest of the family’s solutions.

The applications for building a Solve 2 Mint system within the context of different communities has the ability to be quite powerful. We are interested to hear what ideas the community has for applying Solve 2 Mint to different communities. Matchbox is pursuing building a Solve 2 Mint system for programming challenges to onboard and provide grants to developers building games on the Starknet ecosystem.

Solve 2 Mint systems can be roughly categorized into 3 different classes. Class C (Weak), Class B (Moderate), and Class A (Strong). There are implementations that can be taken from a Class A system and implemented in Class B to create an “in-between” or “Class B.5”. These definitions are loose and have been created to help understand the different types of options available within a Solve 2 Mint framework.

1. Class C (Weak)

   A Class C Solve 2 Mint system is one or more mathematical solutions that can be solved analytically. To mint an NFT, a user would read over the smart contract to understand the equations, and then solve the equations using off-chain software or custom programming logic. They would then submit their solution to the contract via a call.

2. Class B (Moderate)

   A Class B Solve 2 Mint system is an equation or puzzle that does not have a (or at least an obvious) direct analytical (closed form) solution, but can be solved using numerical methods. This makes solving the puzzle harder, but a competent competitor could run numerical simulations that exhaust the entire space.

3. Class A (Strong)

   A Class A Solve 2 Mint system accepts a smart contract as an input which contains logic that solves randomized versions of the challenge defined by the Solve 2 Mint system. A participant submits a smart contract that attempts to solve randomized trials by the Solve 2 Mint contract. An NFT is minted to the submitter if and only if the submitted smart contract passes all the randomized trials.

The concept of solution families is meant to recognize unique “ideas” or methods that lead to a solution for a specific puzzle. For example, imagine a physics puzzle where there is 1 player controlled object and 5 stationary objects. A solution is defined by a series of collisions leading to a score defined by some criteria. A family of solutions can be defined by the first object the player object collides with. So a player to find the first solution that’s first collision is with object X, they would be credited by being the first participant to find a solution for that solution family.

To summarize, a solution family is an informal definition where the goal is to credit the solution finder for recognizing “an idea” about how to achieve a certain score or solution.

Class C Theoretical Examples:

• A naïve physics equation such as simple projectile motion where the goal is to input an initial velocity and launch angle to hit a target d distance away.

Class B Theoretical Examples:

• A physics system that is defined by a certain set of equations or rules (friction, gravity, collisions, etc.) that has clearly defined goal or scoring system such as collision with a certain point or other object. A submitter must submit input variables that start the system and when the system has come to rest the score is above the scoring requirement threshold of the Solve 2 Mint contract. A prototype of an implementation like this is found on the 0xstrat v1 page of the Topology github here.

• A maze where the player is positioned at a certain coordinate of the maze to start and must navigate out within N number of moves. A participant must submit a valid sequence of moves that exits the maze.

• A Rubik’s cube of size N x N with a known starting position (i.e. the squares always start in the same spot or they are changed after a solution is submitted). A participant must submit a valid sequence of moves that solves the Rubik’s cube.

Class A Theoretical Examples:

• A contract that generates polynomial equations of degree 1 ≤ n ≤ N where n is random but N is known. Each equation has at least one solution. The submitted contract would be challenged with M random polynomial equations to solve and submit a response. The submitted contract would need to solve and submit a valid solution for each trial. If the contract returns a valid solution for all trials, the NFT is minted to the contract submitter.

• A physics system that is defined by a certain set of equations or rules that has a clearly defined scoring system. The system is seeded by a form of randomness where the objects in the system may be in random locations or the goal for the scoring may be different (collide with the green circle, collide with both the green and red circle, etc.). The submitter would submit a smart contract that must pass a series of randomized trials by the Solve 2 Mint system. A prototype of this implementation can be found on the 0xstrat v2 page of the Topology github here.

• A contract that randomly seeds a Rubik’s cube of 3 x 3 ≤ n x n ≤ N x N squares on each side. There are 6 sides (and consequently 6 colors) on a Rubik’s cube so 6 * n^2 total squares. The positions of the squares are random. The submitted contract must solve each randomly seeded Rubik’s cube with a sequence of valid moves less than a difficulty level D which is the maximum number of moves (likely scaled for the size of the cube).

• An open information abstract strategy game (like Chess or Onitama) where the submitted smart contract plays against the Solve 2 Mint contract in a series of games. A target win rate must be accomplished over the sample to mint the NFT. If the NFT is defined as the moves of a game in order (1. e4 e5, 2. ... , etc.), the combinatorics of the game make the solution space very large. A family of solutions could be defined by the classical chess openings (Sicilian, Italian Game, Ruy Lopez, etc.).

• Class C (Weak) systems are easily solved with off the shelf solutions or known analytical equations and are vulnerable to sniping and model a first come, first serve environment.

• In certain cases, the system may need a way to monitor the resources used or the efficiency of a submitted solution. Choosing or designing this measurement may not always be trivial.

• Class B (Moderate) systems may be prone to a case where the first participant to find a numerical solution finds ALL the numerical solutions to the puzzle and mints the entire solution space. A counter to this is absorbing parts of the Class A definition into Class B by imposing a randomized trial with a time restraint. A participant would register their address and kick off the trial process. In return, they receive a randomized trial from the solve2mint contract that must be solved within a certain time frame. This can be extended to include multiple trials over multiple time periods.

• Class A (Strong) systems are not trivially mapped to a unique solution. Many contracts that efficiently solve a system will share logic. For example, just using the hash of a given solver contract as a form of uniqueness does not stop an adversary from trivially changing the contract’s hash by altering a variable name and submitting it as their own work. A possible counter to this is only accepting solutions that improve upon the efficiency (see above) of the last previously accepted solution.

• The integrity of the mint will still fall partially upon the puzzle developer, except possibly in the case where they develop a puzzle with requirements and do not know if there even exists a solution. Presumably in many cases the puzzle developer will know of at least one solution and should keep this secret to ensure a fair gameplay experience if the environment is designed to be competitive. There is not much a puzzle developer can do to prevent a participant who has previously solved the puzzle from sharing a related but different solution with a friend. This is where differentiating between families of solutions and/or efficiencies of solutions is important.

Matchbox is working on an initial proof of concept for a Solve 2 Mint system that serves to onboard already proficient (but not necessarily proficient in Cairo!) developers into the Starknet ecosystem. The first iteration of the Matchbox DAO Solve 2 Mint Challenge will likely be a Class B challenge of a physics puzzle similar to the prototype on Topology’s github. Developers will have to study and understand the Cairo contracts, design off-chain computation in the programming language of their choice to compute solutions, and then submit a unique solution to the challenge contract. A few winners will be chosen by a criteria (likely top score or fastest to solve above a certain scoring threshold), and presented with grants to pursue their development goals on Starknet.

Matchbox plans to run many more future iterations of the Solve 2 Mint challenge with different prizes and varying levels of difficulty. We hope that the Solve 2 Mint concept will take on legs of its own within the community and members will design all sorts of interesting and unique challenges to be used in future competitions.

Solve 2 Mint provides the perfect opportunity for gamified learning and rewards. Developers that successfully complete the Solve 2 Mint system will have showcased great potential for building in Cairo on Starknet.

Solve 2 Mint is a framework for NFT emission that focuses on intellectual competition as a form of minting rather than traditional NFT emission frameworks like auctions or first come first serve sales.

Matchbox is launching a Solve 2 Mint Challenge in the context of its community for onboarding developers interested in learning about Cairo and developing games on the Starknet ecosystem.

Be on the lookout for future announcements about the competition including prizes and timeline!

Sound interesting? Come join us and help build the future of gaming on blockchain.

Follow Matchbox DAO on Twitter here.

Join the Matchbox DAO Discord here.

Read the Matchbox DAO Notion (Work in Progress) here to learn more about what Matchbox is and is working on.

Topoloygy Github with a prototype implementation

guiltygyoza blog post: Conceptualizing on-chain trial protocols for knowledge

Written by Derked on 3/2/2022