Bitcoin addresses are secure, but they are not exactly easy to remember.
A typical Bitcoin address can look like a long string of letters and numbers that is difficult to type, read, or verify manually. This creates a problem for everyday payments: How can someone pay you without having to copy a long Bitcoin address every time?
BIP 353 is designed to make that experience more user friendly.
Instead of asking someone to remember or share a long Bitcoin address, BIP 353 introduces a standardized way to associate a human readable name with Bitcoin payment instructions using the existing Domain Name System (DNS).
A payment name can look similar to:
The idea is simple: a Bitcoin wallet can look up the name, verify the information using DNSSEC, and discover the payment instructions associated with it.
BIP 353 is officially listed as Complete in the Bitcoin BIPs repository.
What Is BIP 353?
BIP 353 stands for Bitcoin Improvement Proposal 353, and its specification is titled DNS Payment Instructions.
It defines a standard method for storing Bitcoin payment instructions inside DNS TXT records.
In simple terms:
Human readable name → DNS lookup → verified payment information
The payment information can ultimately point to Bitcoin payment methods such as an on chain Bitcoin address or other payment instructions supported by the URI format.
The important part is that the user doesn’t have to manually deal with the underlying technical information.
Instead of sending someone:
bc1q...very-long-bitcoin-address...
you could potentially give them:
A compatible wallet can then resolve that name and determine where the payment should go.
BIP 353 was created by Matt Corallo and Bastien Teinturier and is an application-layer specification.
Why Does Bitcoin Need Human Readable Payment Names?
Bitcoin addresses work extremely well from a technical perspective.
However, they are not designed to function like names.
Imagine telling a customer:
“Send the payment to this 42 character string.”
The customer could copy and paste it, but manually typing or checking the address is inconvenient.
It also creates opportunities for mistakes.
A human readable payment name can make the experience much simpler.
For example:
Traditional approach:
Bitcoin address → Copy → Paste → Check → Pay
BIP 353 approach:
Human readable name → Wallet lookup → Verify → Pay
The underlying Bitcoin address or payment instruction still matters. BIP 353 simply provides a convenient way for a wallet to discover it.
This is an important distinction.
BIP 353 does not replace Bitcoin addresses.
Instead, it provides a human friendly layer that can point a wallet toward payment instructions.
What Does a BIP 353 Name Look Like?
BIP 353 recommends displaying a verified payment name with the Bitcoin symbol ₿.
For example:
The name contains two main components:
- alice — the user portion
- example.com — the domain portion
The @ separates the two.
This format deliberately resembles an email address because most people already understand the basic idea of:
username@domain
However, a BIP 353 payment name is not an email address.
The Bitcoin symbol helps distinguish the two.
For example:
could be an email address.
While:
is intended to represent a Bitcoin payment identifier.
The ₿ is used for display and is not actually part of the DNS name that the wallet resolves.
BIP 353 vs a Bitcoin Address
The easiest way to understand BIP 353 is to compare it with a normal Bitcoin address.
A Bitcoin address directly identifies a destination for receiving Bitcoin.
For example:
bc1q…
A BIP 353 name acts more like a human readable pointer.
Think of it this way:
Bitcoin address = destination information
BIP 353 name = human readable way to discover payment information
When someone enters a BIP 353 name, the wallet performs a lookup.
The result can contain a Bitcoin payment URI containing the relevant payment instructions.
This means the user doesn’t necessarily need to see or manually type the underlying address.
What Is DNS?
To understand BIP 353, you need to understand one basic internet technology: DNS.
DNS stands for Domain Name System.
It is one of the systems that makes the internet easier to use.
Instead of remembering an IP address such as:
142.250.x.x
you can use a domain name such as:
example.com
DNS helps translate human-readable names into information computers can use.
BIP 353 uses the same general naming infrastructure, but instead of using DNS simply to locate a website, it uses DNS to publish Bitcoin payment instructions.
This is why the proposal is called:
DNS Payment Instructions
What Is a DNS TXT Record?
DNS supports different types of records.
One of them is called a TXT record.
A TXT record allows a domain owner to publish text data through DNS.
BIP 353 uses TXT records to store a Bitcoin payment URI.
In simplified form, the process looks like this:
↓
DNS lookup
↓
DNS TXT record
↓
bitcoin:… payment URI
↓
Wallet interprets payment information
The actual DNS record follows a standardized naming structure based on the user and domain.
For example, a payment name for alice@example.com is associated with a DNS location similar to:
alice.user._bitcoin-payment.example.com
You don’t normally need to type this yourself. The wallet performs the lookup automatically.
Why Does BIP 353 Use DNS?
There are already many systems that attempt to create human-readable cryptocurrency payment names.
BIP 353 chooses DNS because DNS is already a global, hierarchical naming system used across the internet.
A domain owner can control a domain such as:
example.com
and create payment names under that domain.
This gives the system a familiar structure.
For example:
The domain becomes part of the identity of the payment name.
BIP 353 also uses DNSSEC to add cryptographic verification to the lookup process.
What Is DNSSEC?
DNSSEC stands for Domain Name System Security Extensions.
Normal DNS was not originally designed to provide strong cryptographic authentication for every response.
DNSSEC adds digital signatures to DNS data.
This allows a wallet to verify that the DNS information it received is authentic and has not simply been replaced by an attacker somewhere along the path.
For BIP 353, this is particularly important.
Imagine you enter:
and the wallet asks DNS where Alice wants to receive Bitcoin.
If an attacker could simply replace the response, they could potentially try to redirect the payment somewhere else.
BIP 353 therefore requires payment instructions to be DNSSEC-signed.
The wallet is expected to validate the DNSSEC chain back toward the DNS root rather than simply trusting a remote resolver to perform the verification.
BIP 353 Is More Than Just a Short Bitcoin Address
It might be tempting to think:
“BIP 353 just turns a Bitcoin address into an email-style name.”
That’s not quite accurate.
The system is designed around payment instructions, not merely static addresses.
This distinction becomes important because modern Bitcoin payment systems can support more than one way of receiving a payment.
For example, payment information can potentially include:
- On-chain Bitcoin addresses
- Lightning-related payment information
- BOLT 12 offers
- Silent Payment information
- Other payment URI parameters
This means a human-readable name can act as an entry point to different payment methods rather than being permanently tied to one static Bitcoin address.
Implementations and tooling already demonstrate BIP 353 records containing multiple payment methods.
Why This Matters for Bitcoin Payments
Bitcoin has become much more technically sophisticated since the original payment URI standards were introduced.
Users now have to deal with:
- Multiple Bitcoin address formats
- Lightning
- BOLT 12
- Silent Payments
- Hardware wallets
- QR codes
- Payment URIs
- Different wallet implementations
BIP 353 attempts to make the first step easier:
Give the user a human-readable payment name.
The wallet can then handle the technical details underneath.
This could make Bitcoin payments easier for:
- Online businesses
- Content creators
- Donations
- Freelancers
- Individuals
- Merchants
- Customer support systems
Instead of publishing a long address everywhere, a recipient could publish a memorable payment name.
BIP 353 and Bitcoin Payment URIs
BIP 353 is closely connected to the topic we covered in our previous article about Bitcoin Payment URIs.
A payment URI provides structured payment information.
For example, a URI can contain:
- A Bitcoin address
- Payment amount
- Label
- Message
- Other payment methods
BIP 353 provides a way to discover that payment information through a human-readable name.
The relationship can therefore be simplified as:
BIP 353 name
↓
DNS TXT record
↓
Bitcoin payment URI
↓
Wallet
↓
Payment
So BIP 353 doesn’t eliminate payment URIs.
Instead, it gives wallets another way to discover them.
This is one reason BIP 353 fits naturally into the broader Bitcoin payment ecosystem.
Is BIP 353 the Same as a Lightning Address?
No.
They can look similar because both can use an @-style human-readable identifier.
However, they work differently.
A traditional Lightning Address generally uses an email-like identifier that is resolved through an HTTPS service.
BIP 353 instead uses DNS and DNSSEC to publish payment instructions.
The BIP was specifically designed as a broader payment-instruction mechanism and also discusses compatibility with existing Lightning Address systems.
This distinction becomes especially important when comparing privacy, verification, supported payment methods, and infrastructure.
We’ll examine those differences in more detail later.
What Happens When You Enter a BIP 353 Name?
At a high level, the process looks like this:
Step 1: Enter the Name
You enter something like:
into a compatible Bitcoin wallet.
Step 2: The Wallet Performs a DNS Lookup
The wallet determines the appropriate DNS record associated with the user and domain.
Step 3: DNSSEC Is Verified
The wallet verifies that the DNS information is properly authenticated.
Step 4: Payment Information Is Retrieved
The TXT record contains the relevant Bitcoin payment URI.
Step 5: The Wallet Interprets It
The wallet extracts the available payment information.
Step 6: You Review the Payment
The wallet should still show the recipient and transaction details before you approve the payment.
Step 7: You Sign the Transaction
Your wallet signs the transaction according to its normal security process.
The BIP 353 lookup does not authorize the payment by itself.
You still have to approve the transaction.
Does BIP 353 Store Bitcoin on DNS?
No.
This is one of the most important things to understand.
BIP 353 does not store Bitcoin on DNS.
It doesn’t move Bitcoin onto DNS.
It doesn’t create a second Bitcoin blockchain.
Instead, DNS is used to publish payment instructions.
The Bitcoin itself remains governed by the Bitcoin network and its transaction rules.
You can think of DNS as providing a directory.
The directory tells the wallet:
“Here is the verified payment information associated with this human-readable name.”
The actual Bitcoin transaction still happens on the appropriate Bitcoin payment network.
How Does BIP 353 Actually Work?
A BIP 353 payment name contains a user name and a domain.
For example:
The wallet removes the display-only Bitcoin symbol and separates the name into:
- User:
alice - Domain:
example.com
It then constructs the corresponding DNS name.
Conceptually, this becomes something similar to:
alice.user._bitcoin-payment.example.com
The wallet queries DNS for the appropriate TXT record.
If a valid BIP 353 record exists, the wallet can retrieve the Bitcoin payment instructions published for that name.
The specification defines this DNS naming structure so different wallets can resolve payment names consistently.
What Is Stored in the DNS TXT Record?
The DNS TXT record contains payment information.
A simplified example could look like:
bitcoin:bc1qexample...?
This is important because BIP 353 builds on the Bitcoin payment URI system rather than inventing an entirely separate payment format.
The record can contain a bitcoin: URI with information that tells the wallet how the recipient can be paid.
Depending on the record, this can include an on-chain Bitcoin address and additional payment methods.
So the architecture becomes:
BIP 353 name
↓
DNS TXT record
↓
Bitcoin payment URI
↓
Payment method
↓
Wallet payment
This is one of the reasons BIP 353 fits naturally with the Bitcoin Payment URI system discussed in our previous article.
Why Does DNSSEC Matter?
Finding a DNS record is not enough.
A wallet needs confidence that the payment information is authentic.
This is where DNSSEC becomes important.
DNSSEC adds cryptographic signatures to DNS information.
A compatible BIP 353 wallet should verify the DNSSEC chain rather than blindly trusting a DNS resolver.
In other words, the wallet should not simply ask a server:
“What payment address belongs to Alice?”
and automatically trust whatever answer comes back.
Instead, it should verify the cryptographic evidence supporting the DNS response.
The BIP 353 specification requires clients to fully validate DNSSEC signatures leading back to the DNS root.
This is particularly important because a payment redirection attack could otherwise be extremely dangerous.
What Happens If DNSSEC Validation Fails?
A secure implementation should not simply ignore the problem.
If the DNS information cannot be authenticated, the wallet should treat the payment information as untrusted.
This is an important security principle.
Imagine that you enter:
but the DNS response cannot be verified.
A wallet should not respond:
“DNSSEC failed, but let’s use the address anyway.”
That would defeat the purpose of DNSSEC.
Instead, the failure should be communicated to the user or the payment should be rejected.
Current BIP 353 implementations demonstrate this approach by rejecting records when the required DNSSEC authentication cannot be established.
Does the DNS Resolver Have to Be Trusted?
This is an interesting part of BIP 353.
A normal internet user may rely on a DNS resolver provided by their:
- Internet service provider
- Router
- Operating system
- Public DNS provider
But BIP 353’s security model is designed so the wallet does not have to blindly trust that resolver to perform DNSSEC validation.
Instead, the client can retrieve DNS information and independently verify the DNSSEC signatures.
That means the resolver can act more like a messenger.
It provides the DNS response.
The wallet verifies whether the response is authentic.
This distinction is important.
DNS resolver = provides the data
DNSSEC validation = verifies the data
Current implementations specifically demonstrate local DNSSEC chain validation instead of trusting a remote resolver to validate it.
What About DNS-over-HTTPS?
BIP 353 can also be used with different ways of transporting DNS queries.
One example is DNS-over-HTTPS (DoH).
DoH sends DNS queries through HTTPS instead of traditional DNS transport.
This can provide additional privacy from parties that might otherwise observe ordinary DNS queries.
However, DoH does not replace DNSSEC.
These are different things.
DoH protects the transport of the DNS query.
DNSSEC authenticates the DNS data.
A wallet can therefore use DoH while still performing DNSSEC validation locally.
Some current BIP 353 implementations support DoH while continuing to validate DNSSEC independently.
What About Privacy?
This creates an important question.
If I pay:
does the domain owner know that I looked up the name?
Potentially, the DNS lookup itself can reveal information.
For example, someone observing DNS traffic could potentially learn that a wallet queried a particular payment name.
This is different from the security question of whether the payment address was authentic.
Therefore, BIP 353 has two separate considerations:
Authentication
Is this payment information legitimate?
DNSSEC helps answer this question.
Privacy
Who can observe the lookup?
DNSSEC does not hide the lookup.
This is why alternative DNS transports such as DoH or privacy networks such as Tor can be relevant.
For example, current BIP 353 tooling demonstrates direct DNS, DoH, and Tor-routed DoH options.
What Is DNS TTL?
Another important part of BIP 353 is TTL.
TTL stands for Time to Live.
It tells systems how long DNS information can be cached.
For example, a record might have a TTL of:
3,600 seconds
That means the information can generally be cached for around one hour.
Why does this matter for Bitcoin payments?
Because the payment information associated with a human-readable name can potentially change.
A recipient might update their payment information later.
If a wallet cached the old information indefinitely, it could continue using outdated payment instructions.
BIP 353 therefore specifies behavior around DNS TTLs.
Current implementations also explicitly enforce the TTL when caching resolved payment information.
Can a BIP 353 Name Point to Different Payment Methods?
Yes.
This is one of the more interesting aspects of the system.
A BIP 353 record isn’t necessarily limited to one static on-chain Bitcoin address.
The payment URI can contain different payment information.
For example, modern implementations can resolve records containing:
- On-chain Bitcoin addresses
- Lightning BOLT 11 invoices
- BOLT 12 offers
- Silent Payment addresses
- Other supported payment information
This allows one human-readable name to become an entry point to multiple payment methods.
However, support depends on the wallet and implementation.
The BIP itself defines the payment-instruction framework, while individual wallets may support different subsets of the available formats.
BIP 353 and BOLT 12
BOLT 12 is a Lightning payment protocol that introduces reusable payment offers.
This is different from a traditional Lightning invoice.
A normal Lightning invoice is generally created for a particular payment.
A BOLT 12 offer is designed to be reusable.
That makes BOLT 12 particularly interesting for human-readable payment names.
For example:
could resolve to payment information containing a BOLT 12 offer.
The user doesn’t need to manually copy a long Lightning object.
The wallet can resolve the BIP 353 name and discover the relevant payment information.
Current BIP 353 tooling supports decoding BOLT 12 offers retrieved through BIP 353 records.
BIP 353 and Silent Payments
BIP 353 can also work with Silent Payments.
Silent Payments are designed to allow recipients to publish a reusable payment identifier without requiring a new static Bitcoin address to be publicly reused for every payment.
This can improve receiving privacy because different payments can result in different on-chain outputs.
BIP 353 can provide a human-readable layer for discovering a Silent Payment address.
The relationship can therefore look like:
↓
DNSSEC-verified payment record
↓
Silent Payment address
↓
Wallet generates recipient-specific output
The underlying Silent Payment system still operates according to its own protocol.
BIP 353 simply provides a human-readable discovery mechanism.
Current BIP 353 implementations support parsing BIP 352 Silent Payment addresses.
BIP 353 Can Support Multiple Payment Methods at Once
One particularly useful feature is that a DNS payment record can contain multiple recognized payment methods.
For example, a record could provide:
- A BOLT 12 offer
- A Silent Payment address
- An on-chain Bitcoin address
A compatible wallet can then choose an appropriate payment method.
This is sometimes called a unified payment request approach: one human-readable identifier can provide several ways to pay.
For example:
could potentially represent:
Lightning + Silent Payments + on-chain Bitcoin
The advantage is obvious.
The recipient doesn’t need to publish three different complicated payment identifiers everywhere.
They can publish one human-readable name.
However, the sender’s wallet still needs to support the relevant payment methods.
What If Multiple Bitcoin TXT Records Exist?
This is an important security and configuration detail.
A wallet should not simply choose one payment record randomly if multiple BIP 353 records are found where only one is expected.
That could create ambiguity.
Imagine a domain accidentally publishes:
Record A → Alice’s address
and:
Record B → Completely different address
Which one should the wallet trust?
A deterministic payment system needs an unambiguous answer.
Current BIP 353 tooling treats multiple conflicting bitcoin: TXT records as an ambiguous configuration rather than silently choosing one.
This is a good example of why payment software needs strict validation rules.
What Happens After the Wallet Finds the Payment Information?
Finding the payment information does not automatically send Bitcoin.
The process still requires normal wallet authorization.
A simplified flow is:
1. Enter BIP 353 name
↓
2. Resolve DNS
↓
3. Validate DNSSEC
↓
4. Retrieve payment instructions
↓
5. Interpret payment method
↓
6. Display payment details
↓
7. User reviews the transaction
↓
8. User approves and signs
↓
9. Transaction is sent
This distinction is critical.
BIP 353 is a discovery mechanism.
It does not give the domain owner permission to spend your Bitcoin.
Your wallet still controls your private keys and the transaction-signing process.
Why Wallet Verification Still Matters
DNSSEC can verify that the payment information is associated with the domain’s authenticated DNS data.
But that doesn’t mean you should blindly approve every payment.
Your wallet should still show important information such as:
- Recipient
- Amount
- Payment method
- Fees
- Network
- Transaction details
You should review the information before signing.
This is especially important because a legitimate DNS record can still point to an address controlled by the wrong person if the domain itself has been compromised or intentionally configured incorrectly.
Cryptographic authentication tells you:
“This information is genuinely associated with this DNS domain.”
It does not automatically tell you:
“This is definitely the person you intended to pay.”
That difference is extremely important.
Can the Recipient Change Their Payment Information?
Yes.
One advantage of using DNS-based payment instructions is that the payment information can be updated.
For example, Alice might initially publish:
Bitcoin address A
Later, she could update the DNS payment record to use:
Bitcoin address B
A user who resolves the name after the change can receive the updated payment information.
This can be useful for operational security and address management.
It also means users should avoid treating a BIP 353 name as if it were itself a permanent Bitcoin address.
The name can remain the same while the underlying payment instructions change.
BIP 353 vs a Static Bitcoin Address
Consider a business that receives hundreds of Bitcoin payments.
If it publishes one static address everywhere, every customer sees the same destination.
With a BIP 353 name, the business can provide a human-readable payment identity while maintaining control over the payment information behind it.
The customer sees:
The wallet handles the underlying technical details.
This creates a separation between:
Human-facing identity
and
Machine-facing payment information
That separation is one of BIP 353’s main usability benefits.
What Are the Main Technical Components?
By now, the system can be broken into several layers.
1. Human-Readable Name
Example:
2. DNS
The name is mapped to a specific DNS location.
3. DNS TXT Record
The TXT record publishes the payment instructions.
4. DNSSEC
The wallet verifies the authenticity of the DNS information.
5. Bitcoin Payment URI
The retrieved information follows the Bitcoin payment URI framework.
6. Payment Method
The information can identify an on-chain address or supported payment methods such as Lightning or Silent Payments.
7. Wallet
The wallet presents the payment information and asks the user to authorize the transaction.
Together, these layers create a bridge between a simple human-readable name and Bitcoin’s underlying payment infrastructure.
What Are the Benefits of This Architecture?
BIP 353 offers several potential advantages.
Easier to Share
A human-readable name can be easier to publish than a long Bitcoin address.
Easier to Remember
People already understand username-and-domain formats.
DNS Infrastructure Is Already Global
BIP 353 builds on an existing internet naming system rather than creating an entirely new naming network.
Cryptographic Verification
DNSSEC provides a mechanism for authenticating payment records.
Multiple Payment Methods
A compatible record can provide more than one way to pay.
Payment Information Can Change
The human-readable name can remain stable even when underlying payment information changes.
Works With Modern Bitcoin Payment Technology
BIP 353 can act as a discovery layer for newer payment formats such as BOLT 12 and Silent Payments.
Current implementation work shows that this multi-method approach is technically practical.
But BIP 353 Isn’t Perfect
Human-readable payment names introduce their own risks.
You still have to consider:
- Domain ownership
- DNS configuration
- DNSSEC
- Phishing
- Lookalike names
- Privacy of DNS queries
- Wallet compatibility
- Domain expiration
- Human error
- Trust in the identity represented by a domain
A secure DNS lookup doesn’t automatically solve every problem associated with human identity.
For example, someone could register a domain that looks almost identical to a legitimate business.
That creates a phishing risk.
We’ll explore these issues in much more detail in Part 3.
What Are the Advantages of BIP 353?
BIP 353 offers several potential benefits for Bitcoin users and businesses.
1. Human-Readable Payment Names
The biggest advantage is simplicity.
A long Bitcoin address can be difficult to remember or communicate.
A name such as:
is easier to recognize and share.
This could make Bitcoin payments feel more familiar to people who are new to cryptocurrency.
2. Easier Payment Sharing
Businesses and individuals often need to publish payment information in multiple places.
They might put a Bitcoin address on:
- A website
- An invoice
- A social media profile
- A donation page
- A business card
- An email
- A physical sign
A human-readable payment name could provide a consistent identifier across these locations.
Instead of repeatedly publishing a long address, the recipient can share one payment name.
3. Payment Information Can Be Updated
A traditional Bitcoin address is a specific destination.
BIP 353 separates the human-readable name from the underlying payment information.
This means the payment information associated with the name can be changed without necessarily changing the name itself.
For example:
could continue to be the public-facing identifier while the underlying payment instructions are updated.
This can be useful for businesses and organizations that want to manage receiving infrastructure without constantly changing their published payment identity.
4. Support for Multiple Payment Methods
Another interesting feature is that BIP 353 can act as a discovery layer for different Bitcoin payment methods.
Depending on the record and wallet implementation, payment information can include:
- On-chain Bitcoin
- Lightning
- BOLT 12
- Silent Payments
This creates the possibility of one human-readable name serving as an entry point to several payment technologies.
The exact experience depends on the wallet and the payment methods it supports.
5. DNSSEC Adds Authentication
BIP 353 uses DNSSEC to authenticate payment information.
This is important because a payment system should not simply trust an unverified DNS response.
DNSSEC provides cryptographic proof that the relevant DNS information belongs to the authenticated DNS hierarchy.
However, DNSSEC authentication should not be confused with verifying the real-world identity of the person or organization behind a domain.
It answers a narrower question:
“Is this information authentic for this domain?”
It does not automatically answer:
“Is this definitely the person I intended to pay?”
What Are the Disadvantages of BIP 353?
BIP 353 also has limitations.
1. It Depends on DNS
BIP 353 uses the existing Domain Name System.
That means users and organizations must deal with:
- Domain registration
- DNS configuration
- DNSSEC configuration
- Domain expiration
- DNS provider problems
This is different from a system that operates entirely within the Bitcoin network.
If a domain stops working, the associated payment name may stop resolving.
2. DNSSEC Must Be Configured Correctly
DNSSEC is a major part of the security model.
If a domain does not have valid DNSSEC information, a compatible BIP 353 client should not simply treat the payment information as trustworthy.
That creates an operational responsibility for domain owners.
A business that wants to use BIP 353 needs to maintain its DNS configuration correctly.
3. Privacy Can Be Complicated
BIP 353 makes payment names easier to use, but DNS queries can reveal information.
Suppose someone searches for:
The fact that a lookup occurred could potentially reveal an interest in that payment destination to parties capable of observing the DNS request.
DNSSEC does not make DNS queries anonymous.
This is why privacy-preserving DNS transport can be useful.
However, privacy depends on the complete network setup, not simply on whether DNSSEC is enabled.
4. Human-Readable Names Can Still Be Phished
Making something easier to read does not automatically make it safer.
An attacker could create a domain that looks similar to a legitimate domain.
For example, someone might register a lookalike domain and publish a convincing payment name.
A user could then believe they are paying the correct organization.
This is similar to phishing attacks involving websites and email addresses.
Always verify the payment name carefully.
5. Domain Ownership Matters
A BIP 353 name is associated with a domain.
That means the domain owner controls the DNS information associated with that domain.
If ownership of the domain changes, the payment information could potentially change as well.
Likewise, if a domain expires and someone else registers it, the payment identity associated with that domain could become problematic.
For this reason, businesses using BIP 353 should treat domain security as part of their Bitcoin payment security.
BIP 353 Security Risks
Let’s look at the most important security issues in more detail.
Phishing
The biggest risk for ordinary users may be phishing.
A malicious actor could create a payment name that looks almost identical to a legitimate one.
For example:
could be imitated by a visually similar domain.
Don’t rely only on how a name looks.
Check the domain carefully.
Compromised Domain
If an attacker gains control of a domain’s DNS infrastructure, they could potentially modify payment instructions.
DNSSEC is designed to prevent forged DNS responses, but it cannot protect against an authorized change made by someone who legitimately controls the DNS signing keys.
This is why domain security and DNSSEC key management matter.
Incorrect DNS Configuration
Human error is another possibility.
A domain administrator could accidentally publish the wrong Bitcoin payment information.
DNSSEC can confirm that the information is authentic for the domain, but it cannot determine whether the administrator entered the correct Bitcoin address.
This is why wallets should still display the payment details before the user signs.
Fake Wallet Support
Another risk involves software claiming to support BIP 353.
Users should install wallets from trusted sources and keep them updated.
A malicious application could display one payment destination while actually signing another transaction.
The fundamental wallet security principles still apply.
How Should You Safely Use a BIP 353 Payment Name?
If you encounter a BIP 353 name, follow basic Bitcoin security practices.
1. Verify the Domain
Check every part of the domain carefully.
Don’t assume a similar-looking name belongs to the same organization.
2. Use a Trusted Wallet
Use a wallet that you trust and understand.
Keep the software updated.
3. Check the Payment Details
Before approving a transaction, verify:
- Recipient
- Amount
- Payment method
- Network
- Fees
4. Be Careful With Unexpected Payment Requests
If someone suddenly sends you a payment name and asks you to transfer money, verify the request through another trusted communication channel.
5. Never Share Your Private Keys
BIP 353 does not require you to give anyone your private key or recovery phrase.
Anyone asking for those credentials is a major warning sign.
BIP 353 vs Bitcoin Payment URI
These technologies work together rather than competing directly.
A Bitcoin Payment URI provides structured payment instructions.
A BIP 353 name provides a human-readable way to discover those instructions through DNS.
Think of it like this:
BIP 353
= human-readable discovery
Bitcoin Payment URI
= structured payment information
The two can therefore form a chain:
Human-readable name → DNS → Payment URI → Wallet
This makes BIP 353 a natural extension of the payment workflow covered in our previous article on Bitcoin Payment URIs.
BIP 353 vs Bitcoin Address
A Bitcoin address is a specific destination format used by the Bitcoin payment system.
A BIP 353 name is a human-readable identifier that can resolve to payment instructions.
For example:
Bitcoin address:
bc1q...
BIP 353 name:
The first is the underlying payment destination.
The second is a human-friendly way to discover payment information.
Therefore, BIP 353 does not make Bitcoin addresses obsolete.
Instead, it can hide some of their complexity from the user interface.
BIP 353 vs Lightning Address
BIP 353 and Lightning Address can look similar because both may use an email-style format.
For example:
However, their underlying systems are different.
A traditional Lightning Address uses a web-based mechanism to obtain a Lightning invoice.
BIP 353 uses DNS payment instructions and DNSSEC.
BIP 353 can also be used to discover different payment methods rather than being limited to a single Lightning mechanism.
The distinction is important because the two systems involve different infrastructure, trust assumptions, privacy characteristics, and wallet support.
BIP 353 vs Silent Payments
Silent Payments and BIP 353 solve different problems.
Silent Payments focus on receiving Bitcoin privately without publicly reusing a static address for every payment.
BIP 353 focuses on making payment information easier to discover through a human-readable name.
They can therefore work together.
For example:
could resolve through BIP 353 to payment information containing a Silent Payment address.
In this situation:
BIP 353 = discovery layer
Silent Payments = payment privacy mechanism
This combination illustrates how different Bitcoin technologies can solve different parts of the payment experience.
BIP 353 vs Traditional QR Codes
QR codes are already widely used for Bitcoin payments.
A QR code can encode a Bitcoin payment URI.
The advantage is that a smartphone can scan it instead of requiring the user to type the information.
BIP 353 approaches the problem differently.
Instead of scanning a QR code, a user could enter or select a human-readable payment name.
However, the technologies can also work together.
A QR code could potentially encode a BIP 353-related payment identifier or another payment URI.
The important point is that QR codes and BIP 353 are not necessarily competitors.
They can be different interfaces for discovering payment information.
Who Could Use BIP 353?
BIP 353 could be useful for many types of Bitcoin users.
Online Businesses
A company could publish a memorable payment name instead of displaying a long address everywhere.
Charities
Donation pages could use a human-readable payment identity.
Content Creators
Creators could publish a Bitcoin payment name across websites and social profiles.
Freelancers
A freelancer could provide one payment identity to clients.
Physical Businesses
A business could print a payment name on invoices, receipts, or signage.
Individuals
Ordinary users could use a memorable identifier for receiving Bitcoin.
The actual usefulness will depend on wallet adoption and ecosystem support.
What Happens If a Domain Expires?
This is an important practical issue.
Imagine a person uses:
for several years.
If the owner allows example.com to expire, someone else could potentially acquire the domain.
The payment identity could then become unsafe or unavailable.
This is not unique to BIP 353. It is a consequence of tying payment discovery to domain ownership.
For this reason, organizations relying on BIP 353 should protect their domains carefully.
Important measures can include:
- Keeping domain registration active
- Using strong account security
- Enabling multi-factor authentication
- Protecting DNS provider accounts
- Maintaining DNSSEC correctly
- Monitoring important DNS changes
Is BIP 353 Decentralized?
The answer is more complicated than simply saying yes or no.
Bitcoin itself is decentralized in a very different sense from DNS.
BIP 353 uses the existing DNS hierarchy.
Domains are registered through a system involving registries, registrars, and DNS operators.
Therefore, BIP 353 introduces infrastructure outside the Bitcoin blockchain.
However, DNSSEC allows the wallet to cryptographically verify the authenticity of DNS data instead of blindly trusting an ordinary DNS response.
So it is better to think of BIP 353 as:
A Bitcoin payment discovery system that uses existing internet infrastructure.
It does not attempt to turn DNS itself into a decentralized blockchain.
Does BIP 353 Require a New Bitcoin Blockchain?
No.
BIP 353 does not create a new blockchain.
It doesn’t modify Bitcoin’s consensus rules.
Instead, it operates at the application/payment layer.
That means a wallet can use BIP 353 to discover payment information while Bitcoin continues operating normally underneath.
This makes BIP 353 fundamentally different from a Bitcoin consensus upgrade.
Does BIP 353 Change Bitcoin Transactions?
Not directly.
The Bitcoin transaction still follows Bitcoin’s normal rules.
BIP 353 mainly changes how payment information is discovered.
The user experience becomes:
Human-readable name
↓
Payment information lookup
↓
Wallet review
↓
Bitcoin transaction
The transaction itself remains subject to Bitcoin’s normal validation and consensus rules.
Is BIP 353 Ready for Everyday Use?
BIP 353 is an important proposal for improving Bitcoin payment usability, and its specification is listed as complete.
However, that does not mean every Bitcoin wallet or merchant system supports it.
Bitcoin standards can take time to move from specification to widespread implementation.
Before relying on BIP 353 for important payments, check whether your wallet and the recipient’s infrastructure actually support it.
Implementation work exists, including tools that demonstrate DNSSEC validation and multiple payment methods, but ecosystem adoption remains an important practical consideration.
Frequently Asked Questions
What is BIP 353?
BIP 353 is a Bitcoin Improvement Proposal that defines a way to publish Bitcoin payment instructions through DNS TXT records using human-readable payment names.
What does a BIP 353 address look like?
A BIP 353 payment name can use an email-style format such as:
The Bitcoin symbol is a display convention and is not part of the DNS lookup name.
Does BIP 353 replace Bitcoin addresses?
No. It provides a human-readable way to discover payment instructions. The underlying Bitcoin address or other payment method can still be used by the wallet.
Does BIP 353 use DNS?
Yes. BIP 353 uses DNS TXT records to publish payment instructions.
Why does BIP 353 use DNSSEC?
DNSSEC provides cryptographic authentication for DNS data. This allows a wallet to verify that the payment information belongs to the authenticated DNS hierarchy.
Can BIP 353 work with Lightning?
Yes, depending on the payment information published and wallet support. BIP 353 can be used to discover Lightning-related payment information, including BOLT 12.
Can BIP 353 work with Silent Payments?
Yes. BIP 353 can provide a human-readable discovery layer for Silent Payment information.
Is BIP 353 the same as Lightning Address?
No. They use different underlying mechanisms. BIP 353 uses DNS and DNSSEC, while Lightning Address generally uses web-based infrastructure for obtaining Lightning invoices.
Is BIP 353 private?
Not automatically. DNS queries can potentially reveal information about which payment names are being looked up. Privacy depends partly on how DNS queries are transported and handled.
Can someone steal my Bitcoin through BIP 353?
BIP 353 itself does not give anyone control over your Bitcoin. You still need to authorize and sign transactions through your wallet.
However, phishing, compromised domains, incorrect payment information, or malicious wallet software can still cause losses.
Can a BIP 353 payment name change?
The human-readable name can remain the same while the payment information published by the domain changes.
What happens if DNSSEC fails?
A secure implementation should not simply treat an unauthenticated payment record as trusted. The wallet should handle the failure according to its security rules rather than blindly using the result.
Does BIP 353 store Bitcoin on DNS?
No. DNS contains payment instructions, not Bitcoin itself.
Does BIP 353 create a new cryptocurrency?
No. BIP 353 is a payment discovery standard. It does not create a new cryptocurrency or blockchain.
Do all Bitcoin wallets support BIP 353?
No. Support depends on the wallet and its implementation.
Is BIP 353 better than a Bitcoin address?
Not necessarily.
They serve different purposes.
A Bitcoin address is a payment destination, while BIP 353 provides a human-readable way to discover payment information.
Final Thoughts
What is BIP 353?
BIP 353 is a proposal for making Bitcoin payment information easier for humans to discover and share.
Instead of publishing a long Bitcoin address everywhere, a user can potentially publish a human readable payment name such as:
Behind the scenes, a compatible wallet can perform a DNS lookup, verify the information using DNSSEC, retrieve the payment instructions, and present the payment to the user.
The concept becomes even more interesting because the payment information can support different technologies, including on-chain Bitcoin, Lightning, BOLT 12, and Silent Payments, depending on the implementation.
However, BIP 353 isn’t a magic solution.
It introduces dependencies on domains, DNS, DNSSEC, wallet support, and careful security practices.
There are also privacy and phishing considerations that users should understand.
The biggest takeaway is this:
BIP 353 doesn’t replace Bitcoin’s payment system. It makes that system easier to discover.
It creates a human-friendly layer between people and the technical payment information underneath.
As Bitcoin payment technology continues to evolve, standards like BIP 353 could help bridge the gap between powerful infrastructure and everyday usability.
