balloonbox-inc / near-oracle-contracts Goto Github PK

Description

Integrate with the native NEAR wallet to allow for user authorization before proceeding to core calculation

Description

• pass in token metadata (including the timestamp of when the token got minted)
• assign a token to a user
• mint an NFT

Description

Write full suite of unit tests to simulate the action of minting NFTs on NEAR. Simulate the transfer of NFTs and ensure that the host smart contract is paid a royalty too.

Description

Deploy the NFT-minter smart contract to NEAR testnet. Test it's functionality.

• create LookupMap obj to store credit score
• create struct to return info about state of the contract
• create struct containing updatable user count and credit score count

Description

Ever wondered how the wallet knows which NFTs you own? It's all thanks to log events. Let's implement some functions that emit an event whenever an NFT is transferred, minted, or burnt.

Tasks

• implement a function to burn NFT once the loan has been serviced (idea for future grants)
• emit an event whenever the nft_mint function is invoked
• emit an event whenever the internal_transfer is invoked
• emit an event whenever the nft_resolve_transfer is invoked

• write a fn for logic checks executed prior to storing a new score to blockchain.

Logic

Write a new score on blockchain iff:

• the size of the smart contract is < max cap of bytes
  AND if ONE of the following conditions apply:
• the person is a new user
• the person is a returning user AND their latest store is > 30 days old AND that user stored < 10 total scores thus far

Tasks

• store block height and time as a timestamp
• implement logic to compare timestamps
• add hard constraint: do not store more than one score a month for the same user

Description

Implement logic to transfer an NFT from owner A to owner B

Description

Perform unit testing of the codebase for the Rust smart contract. Test for these core functionalities:

• does the contract actually store scores to blockchain?
• does it increment the count of users and scores over time? Does it do so correctly?
• is the score description correctly stored on chain as a 256 bits long data slice?
• are read-ony queries such as state queries and score queries actually gasless?
• are the data types returned by function calls (both read-only calls and state-handling calls) as expected?

• optimize smart contract to get it ready on mainnet (optional - may not be needed)
• perform necessary integration changes to migrate to mainnet (checkout Discord dev channel)
• compile using ./build.sh
• deploy to mainnet
• use view calls to interact with contract and return (a) contract state and (b) a user's all historical score (c) the user's most recent score

Description

Review the Rust code implementing the basic functionalities for the NEAR smart contract: i.e.,

• store scores to blockchain for multiple users
• query the score history for a specified user
• query the state of the contract

Tasks

• complete the first round of development of the smart contract
• execute unit tests to verify main functionalities
• deploy this initial contract to the NEAR testnet and interact with it

Description

You must implement a security layer to protect the smart contract from being called from outside of the dApp frontend. Solution: implement a whitelisting mechanism.

Logic

• write a #[private] function to add a user to a whitelist of account addresses
• invoke this add_to_whitelist() method from inside of the function body of store_score() and nft_mint()
• empty the whitelist at the end of the execution of the functions storing scores or minting NFTs.

Implemented on both smart contracts.

Description

Grant approval permission to another contract to transfer NFTs

Tasks

• grant approval to a specific account
• revoke approval from a specific account
• revoke approval permissions from all accounts

Description

Ensure you are able to use patch fixes to correctly upgrade a smart contract by modifying both its state and it code.

• compile using ./build.sh
• deploy in testnet
• use view calls to interact with contract and return (a) contract state and (b) a user's all historical score

Description

Encrypt the score descriptive message as a vec < u8 > using the sha256 hash function from the sha2 cryptographic kit. Luckily, the Rust crate named near_sdk provides already the function sha256()

Tasks

• feed as function input a String
• convert the input String into a byte string of &[u8] using .as_bytes()
• encrypt the byte string, i.e., hash the random string of bytes &[u8] into a vec < u8 >

Establish logic for limiting behaviour of the store_score method in the smart contract

Logic

• a user can store at most 1 score every 30 seconds
• a user can store at most 5 scores in total

• create fn to store a credit score in LookupMap following this logic:
• if user already exists --> append new score to existing ones
• if user is new --> create new key-value pair in LookupMap

Description

Every smart contract must be initialized to the blockchain by calling a one-time-only initialization function (which is defined inside the contract itself).

Tasks

• initialize contract state as an attribute of the primary struct (singleton) of the smart contract
• write initialization function for score dict
• initialize contract on testnet, check init function is working properly

Tasks

• minimize number of structs used. Recycle the same struct when possible
• ensure output data structure is both logical and memory efficient

Description

Iterate through all NFTs in a contract

Tasks

• display all NFTs owned by a user under the collectible tab in their NEAR wallet
• implement a view function to query the contract state, which returns all the NFTs stored in the contract

Logic checks

Validate the logic of the smart contract to be correct. Furthermore, establish logic for limiting behaviour of the store_score method in the smart contract. Specifically,

• store_score should be a private method that can only be called from inside the contract. A random developer should not be able to bypass the dApp and call the store_score method externally to store and entirely fake score on chain
• Enforce payable methods! Payable methods should only execute if the user has enough balance in their NEAR account
• a user can store at most 1 score every 30 seconds - upon deployment this will become 30 days or more
• a user can store at most 3 scores in total - upon deployment we'll increase this treshhold to 100 scores of more
• convert the score message into a byte slice using the .as_byte() method. The ultimate solution is to encrypt the score message, to then be able to decrypt it using a decryption key. Formerly you had hashed the message via a SHA256 hashing function, but hashing functions are one directional and are (almost) impossible to be reversed --at least they are not reversible in polynomial time--.

Tasks

Implement the following logic in the nft_mint() function:

• a user can mint at most X total scores
• the contract can mint and store at most Y scores
• a user can mint at most 1 score / month
• you can't mint the same score (same media url) twice -at least not for the same recipient

• store in a struct:
• tot # users that interacted with the contract (len of LookupMap object)
• tot # credit scores saved on blockchain
• smart contract size (bytes)
• write a function that implements a view call and returns the state of the contract passing no parameters

Develop

• create a fn to query the credit score, passing the user address and returning ALL credit scores for that user
• if no score exists for that user, then return error message

Implement

• compile, deploy, and interact with the contract to return the score

Description

Assign automatized royalty payout

• Whenever an NFT is minted, ensure a royalty is paid to the NEAR account id hosting the smart contract. [idea for future implementation]
• A similar royalty should also be in place whenever an NFT transfer of ownership happens.

Description

Every state handling function should require a gas fee to be called and executed. Impose a token fee by adding the #[payable] macro on all state-handling implementations of the main Contract struct and print how much costly was the method execution by printing its gas cost.

Tasks

• print how much gas each operation is costing. Print it iff the operation was successful
• use #[payable] macros where needed

Description

Whenever information is stored on the smart contract, memory is used up and someone needs to pay a gas fee for that memory usage. Ensure that the smart contract charges the cost of storage to the user (not the smart contract account!). --> This was eventually made possible through a whitelist.

Description

Quality Assurance Testing of the NEARoracle dApp in view of the first release of the dApp for Milestone #1

Description

Redesign and improve the contract implementing feedback received from the team after a contract design quality assurance check.

Tasks

• remove the max_size requirement for the contract, i.e., don't set an upper bound limit to the memory used by the contract
• implement a new User struct replacing the old Score struct
• remove query_last_score() function and use only the query_all_scores() function instead
• write a gasless does_user_exist() function to check whether we have a score record for a given user wallet address
• fix bug overwriting scores instead of appending them (prefixes for persistent collections must be unique)
• increment score and user counts iff the score got actually stored to blockchain

• create a fn to query the credit latest score, passing the user address and returning only the latter credit scores for that user
• if no score exists for that user, then return error message

Description

Ensure that all the minting and transferring functions are payable methods. Namely,

• implement the #[payable] macro;
• require a deposit of 0.1 NEAR to sign transactions;
• refund a user whenever storage memory is released.

In all above cases, ensure that the account you are charging is the one interacting with the NearOracle dApp and NOT the account where the smart contract got deployed.

Description

implement some functions to query the NFT ownership of wallet addresses: who owns what? / who are tokens owned by?

Tasks

• ownership check 1: return the count of total NFT supply stored in the smart contract (nft_total_supply)
• ownership check 2: return the list of tokens stored in the smart contract (nft_tokens)
• ownership check 3: pass in a wallet address and return the count of NFTs owned. (nft_supply_for_owner)
• ownership check 4: pass in a wallet address and return list of owned tokens (nft_tokens_for_owner)
• ownership check 5: pass in an NFT and returns the wallet address that owns it - if any (whose_token)

Tasks

• write README.md summarizing the core logic and functionalities of the smart contract
• include a smart contract deployment guide for CLI as a section of the README.md file
• write instructions to explain and execute tests for Rust smart contract

Description

Write comprehensive Git docs documenting both gas-less and gas-fee methods featured in the smart contract. Write thorough docs for developers who might fork the project as well.

Description

Currently the 2 smart contract for the NEARoracle dApp are stored in 2 distinct GitHub Repos. Merge such repos, standardize files in the root directory and store the codebase of each contract in subdirectory.

Description

Ensure both smart contracts meets the NEAR nomicon.io standards.

Tasks

contract-nft: Ensure you've included the standard functions in your rust files:

• lib.rs
• metadata.rs
• mint.rs
• enumerate.rs
• internal.rs
• nft_core.rs
• approval.rs
• royalty.rs

contract-storescore: Include the standard functions in the file:

• lib.rs