27122025

EDEBIT

(Part of an IBM Partner Programme)

EDEBIT TLD Agentic AI Programme

Domain-Based Payments for Web2 and Web3

1. Overview

EDEBIT is a non-custodial payment abstraction layer that allows human-readable domain names to be used as payment identifiers, while actual settlement continues to occur on existing blockchain and traditional payment rails.

EDEBIT does not replace blockchains, wallets, or payment networks. Instead, it provides a resolution and routing layer that maps a domain name to one or more underlying payment endpoints, depending on context, currency, and user preference.

The system is designed to:

  • reduce user error,

  • improve payment UX,

  • preserve user custody,

  • and remain compatible with existing infrastructure.


2. Core Design Principles

2.1 Non-Custodial by Default

EDEBIT does not hold user funds and does not require custody of private keys.
Users retain full control of their wallets, accounts, and assets.

2.2 Human-Readable Addressing

Domain names act as payment aliases, not wallets themselves.
The domain resolves to one or more destination endpoints (on-chain or off-chain).

2.3 Rail-Agnostic Payments

EDEBIT does not mandate a single blockchain, token, or payment network.
It supports
multi-rail routing, including:

  • blockchain networks,

  • stablecoin rails,

  • fiat on-ramps and off-ramps.

2.4 Progressive Decentralization

The architecture supports decentralization where practical, while allowing centralized components where required for performance, compliance, or interoperability.


3. High-Level Architecture

At a high level, EDEBIT consists of five layers:

  1. User Interface Layer (Web2/Web3 Front Ends)

  2. Domain Resolution Layer

  3. Routing & Logic Layer

  4. Settlement Layer

  5. Optional Intelligence Layer (Automation & Optimization)

Each layer is modular and can evolve independently.


4. Domain Resolution Layer

4.1 Domain Ownership

Domains within the EDEBIT ecosystem (e.g., merchant.edebit) represent identity and intent, not custody.

Domain ownership is cryptographically verifiable via:

  • blockchain-based domain registries (e.g., Handshake-style ownership),

  • or registrar-backed records linked to verifiable wallets.

4.2 Resolver Records

Each domain can publish resolver records, similar in concept to DNS or ENS records, but payment-focused.

Examples of resolver records:

  • PAY_USDC_POLYGON → 0x...

  • PAY_USDT_BSC → 0x...

  • PAY_FIAT_EUR → IBAN / PSP reference

  • META_MERCHANT → JSON metadata

  • WEB2_FALLBACK → https://merchant.site/pay

Resolver data can be:

  • on-chain (for transparency),

  • off-chain (for performance),

  • or hybrid (hash-anchored for integrity).


5. Routing & Payment Logic

5.1 Context-Aware Routing

When a payer enters a domain (e.g., shop.edebit), the system evaluates:

  • selected currency or asset,

  • payer wallet capabilities,

  • merchant preferences,

  • regulatory constraints,

  • network fees and latency.

The routing layer then selects the best available settlement path.

5.2 No Mandatory Token Dependency

EDEBIT does not require the use of a proprietary token for basic payment routing.

Optional tokens may be used for:

  • fee optimization,

  • staking access to premium features,

  • governance,

  • or incentive alignment.


6. Settlement Layer

Settlement occurs directly on existing rails, such as:

  • blockchain transfers (stablecoins, native tokens),

  • payment service providers,

  • on-ramp/off-ramp partners.

EDEBIT does not intermediate or re-custody funds during settlement.

6.1 Example Flow (On-Chain)

  1. User enters merchant.edebit

  2. Resolver returns supported payment endpoints

  3. Wallet executes a standard on-chain transfer

  4. Settlement finalizes on the target network

6.2 Example Flow (Hybrid)

  1. User enters merchant.edebit

  2. Resolver routes to fiat on-ramp

  3. PSP handles compliance and settlement

  4. Merchant receives funds via existing rails


7. Intelligence & Automation Layer (Optional)

An optional logic layer can be added to optimize outcomes without controlling funds.

Possible functions:

  • dynamic rail selection (fees, speed),

  • stablecoin preference matching,

  • compliance routing by jurisdiction,

  • automated invoicing or reconciliation,

  • analytics and reporting.

This layer can be:

  • rules-based,

  • API-driven,

  • or AI-assisted,
    without changing custody or settlement guarantees.


8. Security Model

8.1 Threat Model

EDEBIT assumes:

  • users control private keys,

  • blockchains provide settlement security,

  • resolution data must be tamper-resistant.

8.2 Protections

  • Cryptographic domain ownership

  • Signed resolver records

  • Optional hash anchoring on-chain

  • No centralized honeypots of funds

Because funds are never pooled, systemic risk is reduced.


9. Compliance & Integration Considerations

EDEBIT is designed to integrate with:

  • KYC/AML-compliant payment providers,

  • regulated on-ramps and off-ramps,

  • jurisdiction-specific compliance tooling.

Compliance is handled at the rail level, not forced into the domain layer.


10. Developer Integration

10.1 APIs

Developers can integrate via:

  • resolver lookup APIs,

  • payment routing APIs,

  • metadata and analytics endpoints.

10.2 Wallet Compatibility

Wallets can integrate EDEBIT by:

  • resolving domains to standard addresses,

  • executing standard transactions,

  • without protocol-level changes.


11. Why Domains as Payment Identifiers?

Domains provide:

  • human readability,

  • global uniqueness,

  • portability across platforms,

  • brand alignment,

  • and long-term persistence.

EDEBIT uses domains as an abstraction layer, not as a replacement for existing payment infrastructure.


12. Summary

EDEBIT is best understood as:

A domain-based payment resolution and routing layer that sits above existing payment rails, preserving custody while improving usability.

It does not attempt to replace:

  • wallets,

  • blockchains,

  • banks,

  • or payment processors.

Instead, it connects them through a consistent, human-readable interface that can evolve alongside both Web2 and Web3 ecosystems.





View the EDEBT Token Price and details HERE

EDEBIT Pay to Domain

Human-Readable Payments for Crypto & Stablecoins

Domains become payment infrastructure.

The Problem

Crypto payments are still broken for everyday use.

  • Long addresses → irreversible mistakes
  • Wrong network → lost funds
  • Stablecoins ≠ currencies for users
  • Wallet UX assumes technical expertise
  • Result: low conversion, high support cost, slow adoption.

    The Insight

    Payments need:

  • Names, not addresses
  • Currencies, not tokens
  • Resolvers, not custody
  • Domains are the missing abstraction layer.

    The Solution

    Pay to Domain

  • Users send to Domain
  • Resolvers translate domains into the Recipient Address

    No custody. No new token. No key risk.

    How It Works

  • User enters a domain
  • Wallet calls resolver API
  • Resolver returns verified route
  • Wallet builds a normal transaction
  • User signs and sends
  • better address resolution.
  • Currency Domains (.EDEBIT)

    e.g. USD.EDEBIT use Agentic AI to

  • Route payments to the best stablecoin
  • Select lowest fees / fastest settlement
  • Adapts to recipient capabilities
  • Wallets don’t need FX logic.

    Why This Is Hard to Copy

  • Domain-centric payment identity
  • Currency routing encoded as policy, not tokens
  • Non-custodial, resolver-based trust model
  • Wallet + browser + Web2 compatibility
  • Agentic AI optimising routing over time
  • Each layer is simple alone — defensible together