Proposed smart contract interaction for an unified NEAR KYC standard


The main goal of this project is to establish a standard for reusable KYC (for end-users & DAOs) within the greater NEAR ecosystem. The rationale for this is providing KYC as a main building block for DAOs & Dapps within NEAR to operate compliant.

The requirements for our proposal includes:

a) Opt-in (only users / DAOS that wish to be KYCd)
b) Fit with existing DAO building blocks e.g (Sputnik / Astro)
c) Allow multiple KYC providers to support worldwide coverage (when one provider is serving a certain jurisdiction better than others)
d) At a later point allow KYB providers
e) Avoid

Two different approaches:

We propose two different solutions which will both rely on third party KYC SaaS providers and both require a proxy contract (whitelist payout) where DAO funds will be distributed on approval and will be held until KYC status is - true. A general downside of the proposed solutions are that council members will have to be mindful of the payment destination, which is always this proxy contract to avoid (unKYCed) payouts


  • Option 1 assumes that proposal CAN be created at any time and is riskier
  • Option 2 assumes that use will not be able to created proposal until KYC status is true

Option 1: Refundable model

Option 2: Non-refundable model

Complementary KYC approaches in development on NEAR

  • KYCDAO, has received a grant to allow a user to receive a NFT once they have become whitelisted

  • Synaps, uses a DiD approach by using the decentralised cloud provider Aleph

Towards a standard - your opinion matters!

We are eager to get your feedback on which of the two approaches (or others) you prefer and why. We will summon a call with Sputnik, Astro team, Synaps & KYCDAO to move forward, let us know if you wish to be included!

Gus, Denys ‘Stardust’ & the rest of the NEAR DEV LABS Team


A KYC contract interface with approval/callback steps is an excellent candidate for contract standardization. Please include me in these meetings, this is very exciting.


What is riskier about option 1?

There is a possibilitiy of claim() not being called in both options so it seems like allowing for a refund mitigates the risk of funds being stuck in the payouts contract.

With option 2, can claim() be called by the DAO? If so something like multicall could be used to call it in series after payout().

1 Like