[RFP] Wallet Selector Maintenance & Positions

Wallet Selector Maintenance & Positions

Request For Proposals


The OnboardDAO is seeking three individuals to hold paid positions with the OnboardDAO to lead and maintain the Wallet Selector Product.

Github Repo → https://github.com/near/wallet-selector

NPM Package → https://www.npmjs.com/package/@near-wallet-selector/core

Approved Proposal → Proposal For Ownership

Proposals can be submitted as individuals applying for one position or as a team applying for all 3 positions. If the council determines that the best proposals are from individuals, they will ask those submitters to form a team for the purpose of these requirements.


Cycle Administrator

The CA will oversee the regular cadence of triaging defects, pruning the repo, and helping the engineers and council prioritize changes or fixes. They should help organize reviews and default to async communication using ticket comments or documents. The CA is a facilitator and organizer and should defer all authority to the OD council.

The Cycle Administrator will keep a spreadsheet to track hours worked and at what rewards are earned. The weekly average price of NEAR tokens should be included in this spreadsheet for each week of rewards. The sheet should be available to all participants to edit and viewable by the community.

Principal Engineer

The Principal Engineer should endeavor to become the subject matter expert on the Wallet Selector.

The Principal Engineer is responsible for the review of pull requests ensuring they adhere to best practices, standards, and quality. They will triage incoming defects for validity, priority, and severity. They will keep the repository pruned and call regular reviews of the repository by participating members. All merges should require a minimum of one review by either the Principal or Sr. Engineer.

Sr. Engineer

The Sr. Engineer will act as a backup resource to the Principal Engineer. They will strive to gain expertise on the Wallet Selector. They can help with the pull request workload, repo pruning, and triage of defects. All merges should require a minimum of one review by either the Principal or Sr. Engineer.

Budget & Compensation


A preliminary budget has been approved. Listed below is the average hours expected and max hours allowed with listed hourly rates.

Resource Hourly Avg. Hrs Avg. Cost Max Hrs Max Cost
Cycle Administrator $35.00 2 $70.00 4 $140.00
Principal Engineer $50.00 3 $150.00 6 $300.00
Sr. Engineer $40.00 3 $120.00 6 $240.00


  1. Rewards will be calculated and dispersed weekly.
  2. A spreadsheet will be created that is viewable to the public and editable by participants.
  3. Hours worked will be tracked on the spreadsheet.
  4. Columns will be available to track approvals by the council. A minimum of two approvals will be required to validate rewards per participant per week.
  5. The weekly average price of the NEAR token should be tracked on the spreadsheet for easy reference.
  6. Amounts paid will be in NEAR tokens = to the dollar amount (US) earned that week.
  7. The OnboardDAO should pay all rewards by Wednesday of the following week they are earned.


A preliminary repo management and working process was drafted as part of the proposal.


Selected = work on these in the current cycle.

Backlog = keep in the queue to work on in a future cycle.

In Progress = always choose this status when something is being worked on. This can be the initial work or rework based on reviews.

In Review = when an item is ready to be reviewed. This issue should have a corresponding pull request(pr) ready to review.

Blocked = there remains outstanding coding issues, decisions, or upstream problems blocking the completion of the ticket.

Complete or Closed = pr merged and deployed

Task = issue type. For tracking tasks within a project.

Defect = issue type. For issues or problems within the product or project.

Feature Request = issue type. For requesting an enhancement for the product.

Project = issue type. As a “top level” issue to house task lists tracking the completion of a project.

Repository Configuration

  1. The Repository should be linked to a Github Project with a Kanban board so the public can quickly assess progress. The columns should consist of Selected, In Progress, In Review, and Blocked.
  2. One tab of the project will be the Backlog. Tickets in this status are waiting for a new cycle selection.
  3. One tab of the project will be Completed. This will house all closed and completed tickets for easy reference.
  4. One tab will contain Decisions, a special type of Issue that documents for discussion any major decisions under consideration for the project. Github discussions can be used like a forum for the community to discuss. Once a Decision is complete, one or more Issues (Tasks) can be created for required changes / fixes.
  5. Any new Defects submitted should be given a status of Triage. A tab will be created to show these defects in Triage. Once defects have been triaged, they can be either moved to Selected or Backlog.



  1. When disagreements arise about changes or information is lacking to make a pertinent decision, a special type of issue should be created to document the decision to be made.
  2. This Decision should then house all major ideas, challenges, and potential solutions.
  3. Discussion of a Decision can be housed in the discussion forum for the repo / project.
  4. Once a Decision has been made, the issue can be closed.
  5. These Decisions should remain in the repo in closed status for future reference.

Issues, Features, & Defects

  1. New defects should be immediately reviewed by one of the engineers for validity and severity. Comments should be made on the ticket for reference.
  2. A weekly cadence will be established where participants will review the current submitted defects in Triage status. The triage process should determine priority for newly submitted defects. Once the reviewers determine priority, they can then be changed to Selected (work on right away) or Backlog (work on in the future).
  3. New feature requests can be reviewed in the same process as defects. Engineers should first review in Triage for validity and complexity. Comments should be made on the ticket for reference.
  4. A regular cadence will be established for engineer resources to review all outstanding PRs. In some cases this might require more frequent reviews for times of increased submissions. The minimum suggested cadence is once a week.
  5. In the event of major changes, the Principal Engineer should call for a review of the change in questions. A minimum quorum of council members must include comments as to their approval or opposition to the change. If approved, the Principal Engineer can schedule and plan a merge.
    1. Major breaking changes should first be communicated to the community so changes can be made to accommodate the major breaking change.
    2. Major changes should be limited to 2 in one cycle. Care should be taken to avoid change fatigue in the ecosystem. Care should be taken to avoid breaking other dependent apps or wallets.

Releases & Cycles

  1. A regular cadence of cycles should be determined to coordinate changes, fixes, and releases. The repo should be configured to utilize these cycle durations for easy reference by the community.
  2. All releases should follow a defined process whereby environments are used to “stage” changes for testing. The release should first be made to TESTNET and stay there for a specified amount of time. Once everyone is happy with the functionality and quality, the release is pushed to MAINNET.
    1. This time could be a couple days for a less impactful change to a full week for a major breaking change.
  3. Care should be taken that all releases have a rollback plan to quickly reverse a release in the event it has any unintended impact on the ecosystem.


  • The maintainers agree to the base repo management and process outlined above.
  • The maintainers agree that the project will remain open-source.
  • The maintainers agree that major changes and new features will be coordinated with the Wallet Builders community on Telegram.
  • The maintainers agree to list themselves as maintainers on the repo readme.
  • The maintainers will behave and perform their duties with professionalism and empathy.
  • The maintainers will create a focused Telegram channel for Wallet Selector based communications and announcements.
  • The maintainers will inform the committee and community of major incidents, outages, or controversies.
  • The maintainers will provide a weekly update in the Telegram channel of current tasks, issues, projects, initiatives, and overall progress.

How To Submit

Please make responses in this forum, as a response to this post. Please use the following template to ensure consistency → OnboardDAO Wallet Selector Template - Google Docs

Submissions will be open for 2 weeks starting from April 1st, 2024 and ending April 15th, 2024.

1 Like

Hello I am very interested in your position


  • Is this a team or individual?
    I am individual developer
  • What position are you applying for?
    Principal Engineer

Professional Experience

I am blockchain and frontend developer.
I am familiar with smart contract(including EVM, solona, Polkadot, Near), solidity, web3, rust and so on.

Thank you

1 Like

Hi, I am Ahnaf, I am writing to apply for the Principal Engineer position. I am highly interested in the NEAR Protocol’s potential to revolutionize blockchain scalability and user experience


  • Is this a team or individual?
  • What position are you applying for?
    Principal Engineer

Professional Experience

  • Possess strong blockchain development experience in NEAR Protocol since 2020. As a core dev at Paras, I played a key role in enhancing their codebase by implementing industry best practices and code standards
  • Developed and contributed to various Web3 applications built on NEAR, including Paras, Akoma, Arkana, Geovox, and others
  • Highly proficient in TypeScript for both front-end and back-end development
  • Strong communication, problem-solving abilities and collaboration skills
  • Proficient in NEAR development tools like near cli, near-api-js, near smart contract for development and deployment
Github: https://github.com/ahnafalfariza
Portfolio: https://ahnafalfariza.com/projects

Thank you and have a great day

1 Like

Individual application.

Position applying for:
Cycle Administrator.

Professional Experience:
Examples of relevant experience with NEAR blockchain:
I have extensive experience with NEAR blockchain, including managing cycles, triaging defects, and facilitating communication among council members. I was part of Near Certified Researcher Cohort Course and as part of that I am a Near Certified Researcher and I am currently a Co-Facilitator of Near Certified Researcher Cohort2. Additionally, I have a strong background in tracking hours worked and managing rewards systems.

Body :

Dear Hiring Committee,

I am writing to express my interest in the Cycle Administrator position within your organization. With a comprehensive understanding of NEAR blockchain and a proven track record in overseeing cycles, managing defects, and facilitating communication, I am confident in my ability to excel in this role.

The main approach and solution of the proposal:
As Cycle Administrator, my primary focus will be on maintaining the regular cadence of triaging defects, managing the repository, and assisting engineers and council members in prioritizing changes or fixes. I will emphasize asynchronous communication using ticket comments or documents to ensure efficiency and transparency throughout the process. Additionally, I will maintain a spreadsheet to track hours worked and rewards earned, incorporating the weekly average price of NEAR tokens for each week of rewards. This spreadsheet will be accessible to all participants and viewable by the community to promote transparency.

Why should the committee choose this project?
My experience and expertise uniquely qualify me for the Cycle Administrator position. I am dedicated to fostering a collaborative and efficient environment, prioritizing the needs of both engineers and council members, and ensuring transparent communication and tracking of rewards. By choosing me for this role, the committee can trust that cycles will be managed effectively and fairly, contributing to the overall success of the organization.

Will this solution be open source? What licensing will be used?
Yes, this solution will be open source, promoting accessibility and collaboration within the NEAR ecosystem. I will utilize a permissive licensing model to encourage community involvement and contribution.

Thank you for considering my application. I am eager to bring my skills and experience to your organization and contribute to the success of your team.

Nedlar Mlapa.


  • Application Type: Individual
  • Position: Cycle Administrator (CA)

Background and bios: I am Kwame Mensah a result-oriented individual with good organizational skills, currently pursuing a Master of Business in Accounting and Finance at the University of Professional Studies. I have experience as an Accountant/ Administrator and Mathematics Instructor, with certifications in Project Management and Data Analytics.

Professional Experience

Examples of relevant experience with NEAR blockchain: As a student researcher with the Near Research Collective, I have engaged in various projects and research initiatives that involve the NEAR blockchain, providing me with a deep understanding of its functionalities and potential applications.


Portfolio of relevant work: Portfolio of relevant work. My portfolio includes managing a Trello board for daily task organization, a Google Sheet for data tracking, and a research I am undertaking which are crucial skills for the Cycle Administrator role.

The main approach and solution of the proposal: As a Cycle Administrator, I will oversee the regular cadence of triaging defects, pruning the repository, and assisting the engineers and council in prioritizing changes or fixes. My approach will involve organizing reviews and facilitating asynchronous communication through ticket comments or documents.

Why should the committee choose this project?
My background in accounting, finance, data analysis and project management, combined with my organizational skills, positions me as a suitable candidate to efficiently manage the responsibilities of a Cycle Administrator. I am committed to maintaining transparency and accessibility of the spreadsheet tracking hours worked and rewards earned, aligning with the values of the NEAR community.

Will this solution be open source?
The spreadsheet for tracking hours and rewards will be openly accessible and editable by all participants, ensuring community visibility.

1 Like


  • Application type: Individual
  • Position: Sr. Engineer

Professional Experience

My name is Kujtim Prenku, and I was a core member of the Wallet Selector project with SQA.

I am a very hard-working, conscientious individual with more than 6 years of experience in the industry who is always eager to learn more.

  • Proficient in JS/TS and its popular frameworks
  • Experience working on open-source projects
  • Involved in the NEAR ecosystem since 2021
  • Great problem-solving and communication skills
  • Proficient in tools like near-api-js, near-cli and lately NEAR BOS

Thank you!

1 Like

Hi i’m the admin for the onboard dao.
Please dm me at Telegram: Contact @Yuensid since I didn’t find a contact detail in your forum post so we can do an interview.

1 Like

Hi i’m the admin for the onboard dao.

Please dm me at Telegram: Contact @Yuensid since I didn’t find a contact detail in your forum post so we can do an interview.

1 Like

Hi i’m the admin for the onboard dao team.
Please dm me at Telegram: Contact @Yuensid since I didn’t find a contact detail in your forum post so we can do an interview.

1 Like