convex-dev / bounties Goto Github PK

Convex is the perfect platform for virtual assets, tokens and unique tradable items in gaming!

To test out this capability, we would like to integrate with popular game engines, starting with Unity, which is one of the most popular engines for Indie games.

Objectives:

• Create an OSS library for Unity that integrates with Convex
• Must have a way of connecting to a least on Convex Peer (e.g. https://convex.world)
• Must support transactions (submitting an arbitrary signed transaction)
• Must support queries (sending an arbitrary query to a Peer)
• Must have some way of managing private Ed25519 keys in the client for transaction signing
• Must have a working demo application / minigame that demonstrates key functionality
• must have adequate documentation, so that a typical Unity developer can get it running

The project is to enable several parties to make a combined crowdfunding payment to a project creator, across NBDC and commercial bank accounts.

Objective:

• A project creator sets their project's funding goal and deadline on a crowdfunding platform.
• Multiple parties (Party A, Party B, …, Party Z) pledge certain amounts of money from their nation-state-backed digital currency (NBDC) account or commercial bank accounts to the project on the crowdfunding platform. This triggers the transfer of value from their NBDC or commercial bank accounts to an escrow account maintained by the crowdfunding platform at a commercial bank
• The consent of the respective party must be secured before payment is initiated from their account.
• If the project succeeds in reaching its funding goal within the deadline, the collected funds are transferred from escrow account to the commercial bank account of the project creator.

The goal of this bounty is to compromise the Actor security model. Convex depends on a security model such that the only code that should be executed in the Actor's context is code deployed or permitted to be executed by the Actor itself.

Requirements:

• Must show the ability to execute arbitrary CVM code in the Actor's security context (i.e. using the *address* of the Actor, such as transfering coins away from the Actor's Account)
• May be demonstrated with any Actor deployed on the test network (you may deploy your own)
• Must not exploit a flaw in the Actor's code (e.g. creating an Actor which calls eval on untrusted user input) - this would be considered a flaw in the Actor implementation rather than the CVM security model.

All CVM Values (and constituent Cells) have an Encoding, which is a unique representation of the Cell value in a byte sequence.

This bounty is for finding an Encoding bug and fixing it.

Requirements:

• A test case must be created that proved a failure in a fundamental Encoding rule, for example:
  • Two different Encodings that produce the same Cell value (as tested with ACell.equals)
  • Two different Cell values that produce the same Encoding
  • An Encoding which appears to produce a valid Cell (can be decoded successfully with Format.readXXX and passes ACell.validateXXX) but in fact the Cell has some flaw (i.e. a violated invariant that may break assumptions elsewhere in the code base)
• The root cause of the issue must be identified
• A PR must be contributed and accepted that adds the test case, and fixes the defect
• If appropriate, a PR must be contributed and accepted that updates the Encoding CAD (https://github.com/Convex-Dev/design/tree/main/cad/003_encoding)

The project is to enable users to transfer NBDC from their account to another party's NBDC account.

Objective:

• Transfer £20 from Party A’s nation-state-backed digital currency (NBDC) account at payment interface provider (PIP) 1 to Party B’s NBDC account at PIP 2.
• Ensure the creation of the relevant prerequisite resources: environment, currency, PIP, party, and accounts.

Currently Convex uses Parboiled (https://github.com/sirthias/parboiled) as a Reader. While parboiled does its job well as a fast PEG Parser, it has a few problems:

• It isn't being actively maintained
• It uses a lot of bytecode magic to build parsers with ASM, which causes JVM compatibility and build issues

Objective of this bounty it to replace Parboiled with a dedicated Convex reader. Requirements:

• Must be able to express Reader rules in a customisable way, similar to Parboiled
• Must produce full CVM values (Cells) as parse results
• Must be pure Java
• Must pass all current Reader tests in Convex main repo
• Must support meaningful parse error messages

64-bit longs are great for most normal usage. But some more advanced scenarios will require larger integer values (e.g. working with Crypto primitives, high precision fixed point integer maths etc.)

The goal for this Bounty is to provide a new 256-bit integer type for the CVM, that is well integrated with CVM numerical capabilities.

Requirements:

• Must support 256-bit signed integer maths consistent with the current 64-bit longs
• Must implement a new first class CVM data type (should extend ACell)
• Must have extensive testing (generative + important examples / edges cases)
• Must by supported by the key CVM functions (addition, multiplication, comparators, abs, inc, etc.)

Under normal circumstances, the CVM should never throw an exception when executing CVM code.

• Must be caused by invoking valid CVM code in a valid Context (e.g. via Context.execute(op))
• Must result in a Java exception that is not otherwise caught by the CVM (e.g. NullPointerException)
• May be triggered by executing multiple transactions, providing such transactions are possible for an account to execute in a single block
• Exceptions caused by JVM limits (OutOfMemoryError, StackOverflowError etc.) do not count unless they can be reliably replicated even with arbitrarily large JVM allowances.
• Must implement a fix that prevents the issue along with JUnit regression tests

This bounty may be claimed multiple times, providing that the exception has a different cause

Convex maybe should support a native BigDecimal type

• Must build upon the BigInteger type
• Must support all integer numeric operations
• Must maintain a decimal point position (up to long capacity)
• Must have a strategy for ensuring values are canonical (e.g. always storing BigInteger with no trailing zeros)
• Must be an ACell for effective CVM usage

Convex should support a native BigInteger numeric type

• Should support key arithmetic operations (+ - * / mod quot abs signum etc.)
• Should be implemented as an ACell for CVM usage
• Should have a canonical encoding that is unique for each BigInteger value
• Should have juice costs that reflect computational complexity of operations
• Should be relatively efficient, e.g. using longs for implementation rather than individual bytes

One of the interesting capabilities in Convex is the ability for Account to be transferred between owners (like any other digital assets), since the public key associated with the Account.

The bounty is for a secure smart contract that buys and sells Accounts automatically, enabling these to be recycled.

Requirements

• Must allow users to "buy" an Account from the market (or create one if not available)
• Must allow users to "sell" an Account back to the market
• Market price must increase when less Accounts are available, decrease when more are available (probably with a "bonding curve")
• Accounts sold to the market must be cleared in a reliable and well-specified way to make them usable for a new owner. Use of undef, set-controller and set-key probably required.
• Must have consideration for all possible security and cryptoeconomic risks
• Must have comprehensive tests and documentation
• Must be submitted and accepted as a PR on the Convex main repo (https://github.com/Convex-Dev/convex)

We currently believe that CPoS is relatively resistant to front-running attacks, and that a front running attack without special resources is not feasible on the Convex network. We would like to test and verify this belief, hence the objective of this bounty is to demonstrate and hopefully fix a front running attack.

Requirements:

• Must show front running, i.e. an attacker successfully executes a transaction before an existing in-flight transaction observed on the network.
• Must be a plausible attack where attacker does not have access to special resources:
• does not have large network stake (<10%0
• does not have ability to intercept / censor arbitrary messages on the network
• does not have other unusual resources (e.g. ultra-fast global messaging)
• Client is assumed to submit transaction to a good/trusted peer. Attacker must observe the message broadcast on the network before submitting its intended front-running transaction
• Must have demonstration code that is repeatable (at least with high probability of attack success)

Bounty breakdown:

• 500 Gold for repeatable attack demonstration code
• 1000 Gold for PR to fix specific attack
• Up to 2000 Gold extra for more general solution to front running / network security

The project is to enable users to transfer NBDC from their account to another party’s commercial bank account.

Objective:

• Transfer £30 from Party A’s nation-state-backed digital currency (NBDC) account at payment interface provider (PIP) 1 to Party B’s commercial bank account.

The project is to build a working Bridge that can connect a Convex network (e.g. the Testnet) to an Ethereum Network.

Objective:

• Must be possible to run on a secure server which also operates as a Convex Peer
• Must allow ERC20 / ERC777 and similar tokens to be transferred to and from Convex as a wrapped fungible token
• Wrapped assets on Convex must conform to the standard convex.asset interface
• Must be demonstrated linking the Convex mainnet (once launched) to the Ethereum mainnet

The Bridge itself need not be decentralised, but must support fully decentralised networks on both the Convex and Ethereum side

The project is to encourage participants to be creative and demonstrate a novel concept.

Objective A:

• Enable the cash-on-delivery capability for nation-state-backed digital currency (NBDC), with users paying for online purchases using NBDC, but merchants only receiving funds on physical delivery of goods and services.

Objective B:

• Configure rules to sweep funds between their nation-state-backed digital currency (NBDC) and commercial bank accounts.

Objective C:

• Configure rules to define how payments initiated should use the funds available across their nation-state-backed digital currency (NBDC) and commercial bank accounts.

Objective D:

Completion of any one or more of the following:

• Cross border nation-state-backed digital currency (NBDC) payment.
• Implement a hard cap limit for NBDC user balances across payment interface providers (PIPs).
• Pay merchant for in-person purchases using a PIP-issued payment card that is linked to a NBDC account.
• Split bill payment amongst friends (multiple debits, single credit).
• Variable recurring payments from NBDC (e.g. utility bill payments).
• Aggregate balance information across NBDC and commercial bank accounts and select payment account based on available balances.
• Or anything else.

The project is to enable users to deposit physical cash into their NBDC account.

Objective:

• Deposit £100 in physical cash into a nation-state-backed digital currency (NBDC) account owned by Party A at a payment interface provider (PIP).
• Ensure the creation of the relevant prerequisite resources: environment, currency, PIP, party, and finally an account.

The project is to enable users to pay for goods and services using NBDC.

Objective:

• Party A visits a merchant website and pays £40 for products/services purchased on the site using their nation-state-backed digital currency (NBDC) account held at payment interface provider (PIP) 1.
• The consent of Party A must be secured before payment.
• The funds are transferred to the merchant’s commercial bank account.

The objective of this bounty is to steal at least one copper coin from any Account on the Convex test network without knowledge of the account's private key.

Requirements:

• Must exploit a technical or security flaw in the CVM or Convex network
• Must be reproducible (ideally with a code example)
• Must NOT depend on compromising or otherwise obtaining access to the private key of the account (e.g. social engineering)