The NEAR chrome-extension Wallet

Narwallets allows NEAR users to manage their assets, connect to DEFI, to stake and earn rewards.

Join the Discord Server for updates


Providing NEAR users with

Account and assets management

You can manage all your NEAR accounts from a single wallet. NEP-141 Token support, Liquid-Staking suppor, classic staking support and Lockup-account support.

Liquid Staking

Narwallets is integrated with Metapool. You can stake and liquid-unstake with Meta Pool directly from the wallet!. Leverage your assets with stNEAR, you can earn additional rewards on the nascent DEFI ecosystem.

Non Custodial Security

We do not send any of your information to external servers, all your keys and passwords are encrypted and stored locally

Metapool Integration

We make it easy to stake and unstake NEAR tokens

Narwallets is integrated with Metapool, you can stake and liquid unstake directly from the wallet.


  • Open the wallet and select your account, click on "Stake"
  • On confirmation, you receive stNEAR as a new asset in your wallet
  • As part of Metapool every staker and liquidity provider gets $META
  • You are free to use your stNEAR and $META from the Wallet

Our Team


Common Questions

  • What is Narwallets?

    Narwallets is a chrome-extension wallet for the NEAR blockhain. It allows you to manage all your NEAR accounts, your NEP-141 Tokens, your Liquid Stake, your classical stake and even Lockup accounts.

  • Yes. We store your information only on local chrome storage and all the data is encrypted. The walllet is non-cutodial, we do not store your keys, password or any information in our servers

  • Liquid staking is an alternative to traditional staking: it allows users to stake any amount of NEAR and to effectively unstake their NEAR without the requirement of waiting 52 to 65 hours before NEAR token holders get their compounded rewards.

  • The stNEAR NEP-141 token is the toke you obtain when liquid-staking directly from the wallet. The integrateed Metapool functionality tokenizes your stake, allowing you to use your staked near as a NEP-141 token, called stNEAR. stNEARs represent staked NEAR. The price of stNEAR is incremented every 12 hours when staking rewards are collected.

  • You can stake NEAR and/or unstake NEAR immediately. There is no waiting time with our liquid unstaking swap solution. You pay a swap fee that ranges between 0.3% and 3% depending on actual liquidity and the amount you want to liquid unstake. You can also chose to unstake by the old method, waiting 2-3 days but with no fee.

  • Yes, staking rewards are compounded automatically into the stNEAR price.

    1. Has a security program in place that covers or is dedicated to the wallet
    2. Publishes information about its security program in an easily findable place.
    3. Conducts regular audits of wallet code, at regular intervals of less than a year or based on meaningful code changes.
    4. Conducts regular penetration tests, both “authenticated” and “non-authenticated” upon significant code changes.
    5. Conducts penetration tests on related infrastructure, such as databases, virtual machines, web servers, etc.
    6. Remediates any critical, high, or medium findings from audits (3, 4, an 5 above) in a rapid fashion, as suggested by auditors. Auditors should validate the remediation in their reports.
    7. Makes such reports (audits, penetration tests) publicly available, on at least a summary level.
    8. When making reports (7) available, wallet projects should ensure the equivalent reports appear on the security vendor’s site or simply links to the security vendor’s report. This ensures the authenticity of the audit reports.
    9. Conducts operational readiness reviews and testing or an equivalent process before deployment to production to ensure that code changes have not resulted in unanticipated behavior, compatibility issues, or inclusion of vulnerabilities.
    10. Maintains a testnet wallet, available to developers and security researchers.
    11. Maintains a bug bounty program.
    12. Implements minimal privilege and access policies with regard to supporting infrastructure.
    13. Implements MFA and strong passwords for access to critical related systems, such as domain registration, hosting platforms, cloud platforms, etc.
    14. Conducts known vulnerability and vulnerable dependency checks; and remediates critical, medium, and high findings before deploying to testnet or production.
    15. It is listed on the official extension marketplace
    16. Logs are collected from supporting infrastructure, web servers, etc.
    17. Ensures that logs do not contain sensitive information, are encrypted at rest in storage, and have restricted access with least privilege.
    18. Enables “audit logs” on related platforms (AWS, GCP, monitoring platforms, etc).
    19. Logs shall be maintained for 90 days for forensic purposes.
    20. Security feature shall be enabled in hosting environments, i.e. AWS GuardDuty.
    21. Inputs shall be sanitized.
    22. Code SAST scanning for vulnerabilities and vulnerable dependencies shall be conducted prior to production.
    23. Vulnerability scanning shall be conducted regularly on websites, infrastructure-related VMs, etc. Findings shall be quickly remediated.
    24. Patch management shall be conducted frequently on supporting infrastructure.
    25. VM and bare-metal infrastructure shall be protected by endpoint detection and response software.
    26. An incident monitoring, alerting, and response program shall be in place.
    27. Additional protective technologies, such as web application firewalls, should be put in place and appropriately configured to prevent attacks on the wallet.
    28. White and black lists should be maintained for ip addresses and domains interacting with the wallet to the extent possible.
    29. Reduction in attack surface shall be conducted by removing access to paths and unused ports; properly configuring domains, CSP, etc.
    30. Access to infrastructure should be limited to VPNs or commensurate technology, IP restricted, etc. in order to prevent malicious access. For example, port 22 for the web server would not be accessible from the internet.
    31. OWASP top 10 vulnerabilities shall be regularly tested and remediated.
    32. Tools such as Nessus and Qualys, or similar should be used to scan for vulnerabilities.
    33. Tools such as Burp Suite, or similar should be used to instrument and and analyze the interaction of the wallet with the browser for security issues.
    34. Playbooks for public disclosure and communication to stakeholders and users should be prepared in advance and practiced via tabletop exercises in order to ensure rapid response and disclosure to protect such stakeholders and their assets.
    35. An incident response retainer should be considered.
    36. Wallet projects should clearly inform users of risks, risky behavior, best practices in the use of the wallet, and the most secure methods for using the wallet.
    37. Wallet projects should have a clear path to reporting and receiving help on issues that is easily found by users.
    38. Sensitive information should not be stored in the client-side wallet in a way that could be scraped from storage by malicious software, such as keys, recovery phrases, etc.
    39. Encryption of sensitive data should likewise not rely on hard-coded keys or weak ciphers.
    40. A user’s ability to recover their wallet under various circumstances should be clearly spelled out to the user when setting up the wallet.
    41. Communication between infrastructure elements should be secured to the maximum extent possible. Please link to your the statement on your website or GitHub repo showing a statement of compliance. Please put link below (even if it is a placeholder).