On-Chain Push MFA for Web3 With Reduced Oracle Dependence

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current 2FA mechanisms cannot be adopted by Web3 services due to the need for secret information to be publicly accessible in the blockchain, and existing solutions either rely on off-chain data or lack flexibility and efficiency in managing multi-factor authentication.

Innovation Solution

An on-chain push-mode multi-factor authentication system where the multi-factor authentication status is stored directly in the blockchain, allowing for decentralized and efficient management of user authentication through a multi-factor provider smart contract, eliminating off-chain interactions and reducing costs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If 2FA mechanisms are implemented in Web3, then user authentication security is improved, but the system complexity increases due to the need for off-chain data storage and oracle interactions

Engineering Contradiction:
Improveauthentication securityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts the MFA status storage from off-chain databases and moves it directly to the blockchain smart contract. The smart contract includes a mapping structure that stores user MFA status directly on-chain, eliminating the need for off-chain data storage and reducing system complexity while maintaining security

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces a bridge between Web2 MFA systems and Web3 blockchain through a standardized interface. The smart contract provides functions like `checkMFAStatus`, `updateMFAStatus`, and `pairUser` that mediate between traditional MFA providers and blockchain services, enabling integration without increasing complexity

Inventive Principle:
Principle #24Intermediary (Mediator)

2Loss of information

If multi-factor authentication status is stored off-chain, then data accessibility is improved, but dependency on off-chain oracles and external systems increases

Engineering Contradiction:
Improvedata accessibilityVSAvoiddependency on off-chain systems
Core Design Contradiction:
Loss of informationVSReliability

Solution Approach 1:

The patent merges the MFA status storage function with the blockchain smart contract itself. The smart contract includes an internal mapping data structure that stores MFA status directly on-chain, combining what were previously separate off-chain storage and on-chain verification functions into a single self-contained system

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The smart contract performs self-service by storing and retrieving MFA status directly on-chain without requiring external oracle systems. The contract can read MFA status for authentication decisions and update status through user-initiated transactions, making the system self-sufficient and eliminating dependency on off-chain systems

Inventive Principle:
Principle #25Self-service

3Adaptability or versatility

If traditional 2FA services are used in Web3, then authentication flexibility is improved, but cost increases due to oracle fees and off-chain infrastructure

Engineering Contradiction:
Improveauthentication flexibilityVSAvoidoperating cost
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The patent uses lightweight on-chain data structures (mappings) to store MFA status instead of expensive off-chain oracle subscriptions and infrastructure. The smart contract stores status in efficient on-chain storage, eliminating the need for costly oracle services while maintaining flexible authentication capabilities

Inventive Principle:
Principle #27Cheap short-living objects (Disposable)

Solution Approach 2:

The patent extracts the MFA status from expensive off-chain oracle systems and stores it directly in the blockchain's cost-effective on-chain storage. This extraction eliminates ongoing oracle fees and infrastructure costs while maintaining the flexibility needed for Web3 authentication

Inventive Principle:
Principle #2Taking out (Extraction)

4Extent of automation

If public key is used for user identification in blockchain, then decentralization is improved, but user privacy and data protection are worsened

Engineering Contradiction:
ImprovedecentralizationVSAvoiduser privacy risk
Core Design Contradiction:
Extent of automationVSObject-affected harmful factors

Solution Approach 1:

The patent introduces the public key as an intermediary that links users to their MFA status on-chain without storing sensitive personal information. The smart contract stores only the public key and MFA status boolean values, using the public key as a mediator that enables identification while protecting private data through the separation of identification and data storage functions

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP4418152B1On-chain push-mode multi-factor authentication method and system for blockchain services
Publication Date: 2025.07.30 TELEFONICA INNOVACION DIGITAL SL
  • EP4418152B1 patent drawingFigure 1
  • EP4418152B1 patent drawingFigure 2
  • EP4418152B1 patent drawingFigure 3

AI summary

A method and a system for multi-factor authentication for blockchain services are proposed. The method comprises holding, by a server, an account of an end-user, the account being identifiable via an accountlD;associating the accountID with a clientAddr by executing a pairing process; establishing, by the end-user, using a software application, an approval status for a multi-factor service in the server; in response to said established approval status, calling, by the server, a changestatus function of a multi-factor provider smart contract operating in at least one blockchain, the changestatus function including the established multi-factor approval status, the clientAddr, and a certificate termed ownerAddr; modifying, by the provider, the established approval status in the blockchain; delivering, by the provider, a notification to the end-user via the server when the established approval status is modified in the blockchain; and retrieving, by a smart contract developer the established approval status from the provider.