Skip to main content

PureFi

PureFi — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

PureFi — a DeFi project on Ethereum, token (symbol: UFI).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a set of compliance tools for DeFi (for example, wallet checks, a KYC module, risk score) that are positioned as embeddable into protocols.
  • Who it’s for: DeFi projects and users who care about AML/KYC checks and risk control.
  • Why onchain/token: onchain is used as the environment for integrating the modules and accounting for operations; the token is claimed as the means of paying for services/access and part of the economic mechanisms.

How it works (very briefly)

  1. The user does: a protocol or service connects a module (for example, wallet checking / on‑chain KYC / verifier hook).
  2. The system does: checks the wallet/transaction/user against the risk rules and returns the check result.
  3. The user gets: access/refusal/a risk assessment and the ability to apply this as a filter in the product.
  4. Where the blockchain is: the integrations and part of the logic are positioned as onchain modules for DeFi.
  5. Token role (if any): payments for the use of services and the described ecosystem mechanics.

Quick links: AI thesis fit

Project passport

Field Value
Project name PureFi
Also known as (aliases) UFI
Logo (logo) ../assets/364_purefi-protocol_logo.svg
Token symbol (ticker) UFI
Category DeFi | Infra
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0xcDa4e840411C00a614aD9205CAEC807c7458a0E3
Token model (token_type) utility (payments + staking + governance)
Max supply —
Issuance —
Tokenomics (tokenomics, brief) payment for services in UFI; buyback/conversion and burn elements are described
Governance —
Admins/keys —
Audit yes
Bug bounty —
Team (team) Slava Demchuk (CEO), Mykhailo Tiutin (CTO), Vasily Vidmanov (COO), Andy Aleksandrov (BDO), Rasikh Morani (Technical Advisor)
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) AML/KYC compliance for DeFi
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary ai_score 0 / onchain_score 2 / token_score 1 / evidence_score 2
Last verified 2026-02-11

General project overview

PureFi describes itself as a compliance toolkit for DeFi: a set of modules and checks that help projects meet AML/KYC requirements and reduce risks (for example, wallet checks, on‑chain KYC, risk scoring). In the reviewed Tier‑1 sources, no confirmation was found that the product contains a separate AI component (in the sense of machine learning as a functional part of the product).

Features/modules

  • Wallet Checking / AML Risk Score (claimed): checking wallets/transactions and issuing a risk assessment.
  • On‑Chain KYC (claimed): an “on‑chain” identity verification module with an emphasis on privacy.
  • VerifierHook (claimed): embedding compliance checks into a DeFi protocol (as a “hook” before an interaction).
  • Token Analytics (claimed): analytics of tokens/liquidity/behavior (the methodologies require separate verification).

Typical scenarios

  • Scenario 1: a DeFi protocol integrates a checking module → blocks/allows interactions per the risk rules.
  • Scenario 2: a user goes through the KYC procedure → receives confirmation/access to the product.
  • Scenario 3: a team analyzes risk flows/triggers and adjusts the policy (if provided for by the product).

Getting started (wallet/network)

  • What you need: access to the PureFi products (website/wiki) and integration into a dApp (for B2B scenarios); for operations with the token — a compatible EVM wallet.
  • Network/chain: Ethereum (ERC‑20 token); per the website, support for several networks is claimed for the modules.
  • Fees: fees of the respective networks on onchain interactions; details of pricing/fees require separate verification.

Architecture/tech (non‑AI)

  • Components: a set of modules/SDK/integrations (per the description), the ERC‑20 token, web documentation/wiki.
  • Participant roles: integrators (DeFi projects), users, service operators.
  • Where logic runs: part of the logic is claimed as onchain modules; details of the modules’ contracts/addresses require separate verification.
  • Dependencies: the supported blockchains and access to them; external sources of risk data/rules (not established per Tier‑1).

Token/economics (expanded, no forecasts)

  • Token utility (Tier‑1, claimed): payment for the use of AML/KYC services; in the future — incentives for governance.
  • Protocol necessity drivers: the services are described as paid in $UFI (including with conversion of fees into UFI in the backend).
  • Who pays fees: users/integrators on onchain operations (depending on the integration and the network).
  • Where fees go: network fees — to the validators of the respective networks; buyback/conversion mechanics are described on the website (verification of the implementation separately).
  • Issuance/burn: the parameters and specific rules require separate verification.
  • Incentive mechanisms: not confirmed by Tier‑1 as mandatory protocol mechanics; Tier‑1 has mentions of yield farming and “future governance incentives”.
  • Distribution/vesting: an allocation chart is published on the website (Company Reserve 23%, Adoption Incentives 14%, Public Sale 11%, Team 11%, Marketing 10%, Farming with HAI 7%, Advisors 6%, Hacken Round 2%, Liquidity Pool 0.5%).
  • Treasury: not established per Tier‑1.

Governance

  • Who makes decisions: not established per Tier‑1.
  • How product parameters change: depends on the modules/integrations; the specific process is not established.
  • Where decisions are discussed/made: not established per Tier‑1.
  • Keys/multisig: not established per Tier‑1.

Security and incidents

  • Audits: a Hacken audit link is listed in links_* (Tier‑1 for this card: as an external audit page).
  • Bug bounty: not found per Tier‑1.
  • Incidents: no public postmortems were found per Tier‑1.
  • Threat model (what to double‑check): the correctness and sources of the risk scores; the correspondence of the on‑chain KYC claims to the actual implementation; the scope of the audit (what exactly was audited).

Project status and timeline

  • Current status: active (based on the presence of the website/wiki and current materials).
  • Key releases/milestones: not established per Tier‑1.
  • Roadmap: published as an article/post (see links_*).

Ecosystem/integrations

  • Integrations: B2B/B2C products for DeFi integrations are claimed; an “adopted by” list is present on the website.
  • Partners: the website mentions “Developed in partnership with Hacken Foundation” (requires separate verification of the partnership format).
  • Where it’s actually used: specific integration cases require separate verification against Tier‑1 artifacts.

AI component of the project

  • What is real AI here? no Tier‑1 confirmation of an AI component (in the sense of ML/AI as part of the product) was identified.
  • What is truly onchain? the ERC‑20 token is confirmed; the website also claims on‑chain modules (for example, on‑chain KYC and verifier hooks).
  • Why is a token needed? claimed as a utility token for paying for services/access; additional incentives/gov mechanics are described as future ones.
  • Red flags (what to double‑check): which modules are actually onchain and where the contract addresses are; what exactly the audit covers; which exact data/methods are used in the risk score and token analytics.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity medium 2
Token necessity low 1
Evidence Tier‑1 partially present 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): no Tier‑1 statements/roadmap about an AI component were identified.
  • Evidence: Tier‑1 — https://purefi.io ; https://wp.purefi.io/
  • Why sufficient / why not (one line): the focus of the Tier‑1 materials is compliance/AML/KYC; AI intent as a separate line is not confirmed.
  • Conflict note: —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): a description of a specific AI component (model/ML algorithms) was not found in Tier‑1.
  • Evidence: Tier‑1 — https://purefi.io ; https://wp.purefi.io/
  • Why sufficient / why not (one line): without a Tier‑1 description of “what the AI does” we set 0.
  • Conflict note: —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a demo/guide confirming an AI component was not found per Tier‑1.
  • Evidence: Tier‑1 — https://purefi.io ; https://wp.purefi.io/
  • Why sufficient / why not (one line): an AI demo does not apply to the claimed compliance modules without an explicit AI component.
  • Conflict note: —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://purefi.io ; https://wp.purefi.io/
  • Why sufficient / why not (one line): AI quality metrics were not found in Tier‑1.
  • Conflict note: —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): the architecture of an AI component is not described in Tier‑1.
  • Evidence: Tier‑1 — https://purefi.io ; https://wp.purefi.io/
  • Why sufficient / why not (one line): without a tech description of the AI part we set 0.
  • Conflict note: —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: ERC‑20 0xcDa4e840411C00a614aD9205CAEC807c7458a0E3
  • Evidence: Tier‑1 — https://etherscan.io/token/0xcDa4e840411C00a614aD9205CAEC807c7458a0E3
  • Why sufficient / why not (one line): onchain fact: the token contract in the network explorer.
  • Conflict note: —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: on‑chain modules are claimed (for example, on‑chain KYC) and integration hooks for DeFi.
  • Evidence: Tier‑1 — https://purefi.io ; https://wp.purefi.io/
  • Why sufficient / why not (one line): the Tier‑1 materials directly position part of the functionality as on‑chain.
  • Conflict note: —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: no Tier‑1 justification was found that the product breaks down without the blockchain (rather than just the method of integration/accounting changing).
  • Evidence: Tier‑1 — https://purefi.io ; https://wp.purefi.io/
  • Why sufficient / why not (one line): there is no explicit “impossible without the blockchain” test.
  • Conflict note: —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, $UFI.
  • Evidence: Tier‑1 — https://purefi.io
  • Why sufficient / why not (one line): the website describes $UFI as the ecosystem’s utility token.
  • Conflict note: —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): the PureFi services (AML/KYC compliance) are described as paid in $UFI.
  • Evidence: Tier‑1 — https://purefi.io
  • Why sufficient / why not (one line): the website has a “Services Paid In $UFI” block.
  • Conflict note: —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): mandatory collateral/penalty mechanics for the protocol are not confirmed by Tier‑1 sources.
  • Evidence: Tier‑1 — https://purefi.io
  • Why sufficient / why not (one line): the mentions of yield farming/incentives do not disclose protocol collateral/penalties.
  • Conflict note: —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance via the token is described as a future incentive; a working model is not established.
  • Evidence: Tier‑1 — https://purefi.io
  • Why sufficient / why not (one line): “future governance incentives” is not enough for 1.
  • Conflict note: —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the token is not established per Tier‑1.
  • Evidence: Tier‑1 — https://purefi.io
  • Why sufficient / why not (one line): a protocol specification is required for a strict conclusion.
  • Conflict note: —

Evidence (table)

Tier Source What it proves
Tier‑1 — No Tier‑1 source for claim “the product has an AI component (ML/AI as a functional part of the product)” was found.
Tier‑1 https://purefi.io Description of the product (Wallet Checking, On‑Chain KYC, AML Risk Score, VerifierHook) and the utility of $UFI; tokenomics and roadmap (on the page)
Tier‑1 https://wp.purefi.io/ Tier‑1 wiki/documentation on the products and on participation/integrations
Tier‑1 https://verifier-sdk.purefi.io/ Tier‑1 SDK documentation (@purefi/verifier-sdk) for integrating the Verifier/AML logic
Tier‑1 https://etherscan.io/token/0xcDa4e840411C00a614aD9205CAEC807c7458a0E3 onchain fact: the UFI token contract
Tier‑1 https://hacken.io/audits/purefi/ public audit page (as a claimed audit artifact)
Tier‑2 https://www.coingecko.com/en/coins/purefi reference token card (aggregator; not proof of technology)
Tier‑2 https://coinmarketcap.com/currencies/purefi-protocol/ reference token card (aggregator; not proof of technology)

No comments to display

Back to top