layerx-labs/dappkit-testflight

DappkitExample

This project was generated with Angular CLI version 13.3.1.

Development server

Run ng serve for a dev server. Navigate to http://localhost:4200/. The application will automatically reload if you change any of the source files.

Code scaffolding

Run ng generate component component-name to generate a new component. You can also use ng generate directive|pipe|service|class|guard|interface|enum|module.

Build

Run ng build to build the project. The build artifacts will be stored in the dist/ directory.

Running unit tests

Run ng test to execute the unit tests via Karma.

Running end-to-end tests

Run ng e2e to execute the end-to-end tests via a platform of your choice. To use this command, you need to first add a package that implements end-to-end testing capabilities.

Further help

To get more help on the Angular CLI use ng help or go check out the Angular CLI Overview and Command Reference page.

dappkit-testflight's Issues

Testflight Redesign

Testflight is our in-house Smart Contract GUI, it works by reading the JSON ABI for a contract and presents the user with a graphical interface with inputs and buttons to ease the usage of a smart contract.

You can access and check the demo over at https://testflight.taikai.network:8082/

The current website uses Google Material rules and is composed of two side panels, one for listing contracts and connection information (on the left) and another, on the right, for “global page actions” - these are actions that will be the same on all pages of this type (deploy, load, list contract addresses) - and a middle page container.

The objective for this bounty is for A DESIGNER to DESIGN a new UI based on what already exists.

Needed:

• Place for Connection
  • Select / Search Networks to connect
  • connect button
  • list current connected wallet
    • error if connected ≠ current network
• List for Contracts
  • “load custom” button
  • list custom entries
• List of previously deployed addresses for current listed contract
• “deploy this contract”
  • arguments for deployment are a combination of
    • label
    • input
• Load custom address

Rules:

• Only the “Home” page should be visible if no wallet is connected
  • upon entering on other pages a warning should show up

Deliverables

• Figma link / Project
• screenshots

the screenshots should go inside the folder “Design” (create it) under “”, pex Design/your-nickname/Design_template_1.jpg

Testflight UI

test-flight is our in-house Smart Contract GUI, it works by reading the JSON ABI for a contract

and presents the user with a graphical interface with inputs and buttons to ease the usage of a

smart contract.

You can access and check the demo over at https://testflight.taikai.network:8082/

The current website uses Google Material rules and is composed of two side panels, one for listing contracts and connection information (on the left) and another, on the right, for “global page actions” - these are actions that will be the same on all pages of this type (deploy, load, list contract addresses) - and a middle page container.

The objective for this bounty is for A DESIGNER to DESIGN a new UI based on what already exists.

Needed:

• Place for Connection
  • Select / Search Networks to connect
  • connect button
  • list current connected wallet
    • error if connected ≠ current network
• List for Contracts
  • “load custom” button
  • list custom entries
• List of previously deployed addresses for current listed contract
• “deploy this contract”
  • arguments for deployment are a combination of
    • label
    • input
• Load custom address

Rules:

• Only the “Home” page should be visible if no wallet is connected
  • upon entering on other pages a warning should show up

Deliverables

• Figma link / Project
• screenshots

the screenshots should go inside the folder “Design” (create it) under “”, pex Design/your-nickname/Design_template_1.jpg

BEPRO V2’s First Bounty

Solution description: A text document with the following information "BEPRO V2 will conquer the world”. The bounty rewards should be equally distributed to the first 2 users that make a PR.

The test:

1. Two users make a PR
2. The users provide the solution requested above
3. The Bounty is set as ready
4. An undesired rewards distribution (for example, 20%-80% instead of 50%-50%) will be made by a curator
5. That reward distribution should be disputed
6. Another bounty distribution should be made (this time, 50%-50%) and shouldn’t be disputed
7. After the disputing period, the bounty should be finalized, with the bounty rewards and the fees accordingly distributed, while NFTs should be minted and allocated to the users that made the PRs