MailNames is a decentralized domain name system (DNS) built by Peng Protocol. It introduces an "Economic Filter" architecture designed to favor long-term users and utility over namespace squatting. By combining a time-weighted check-in queue with an automated fee-oscillation contract, the protocol ensures that maintaining a large portfolio of unused names is prohibitively expensive while legitimate personal use remains accessible.
The system consists of four primary smart contracts:
- MailNames.sol: The heart of the protocol. It handles ERC721 name ownership, 1-year allowance periods, and Check-In queue.
- MailMarket.sol: A marketplace where users can bid on names. It handles 3-week settlement periods and bid-security penalties.
- MailLocker.sol: Manages 10-year lockups of $MAIL required for renewals.
- MailSpiker.sol: An autonomous, ownerless "Fee Governor" that oscillates global
checkInCostbetween 100 $MAIL and 0.000001 $MAIL.
Ownership of a .mail name is granted for free for an initial 365-day Allowance Period wherein the name cannot be auto-settled to the highest [NATIVE] bidder. Nonetheless, ownership of the name remains with the user forever if no [NATIVE] bidder arises. To extend this allowance, an owner must perform a Check-In.
-
The Mechanism: A Check-In is functionally free, but requires locking $MAIL in the
MailLockerfor 10 years, afterwhich the user can withdraw. -
The Cost: The amount of $MAIL required is dictated by the global
checkInCost(controlled by the owner address). - The Queue: Check-ins are not instant. Users enter a queue with a wait duration of 10 minutes to 2 weeks, scaling with the total number of addresses waiting.
-
Wait Duration Math:
$10 \text{ minutes} + (6 \text{ hours} \times \text{queueLength})$ , capped at 14 days. - Grace Period: After the allowance period, the name enters a 7-day grace period wherein it still cannot be auto-settled and the current owner can renew.
- Auto-Settlement: Outside the grace period, the user retains the name indefinitely, however, if [NATIVE] bids exist, the highest bigger can queue an auto-settlement, which will take 3-weeks to finalize, this gives the current owner an additional grace period to check in.
- Settlement Cancellation: If a user completes their check-in before a pending settlement completes, the settlement is deleted and the new allowance period begins for the current owner.
MailSpiker is a state-driven contract that automates the protocol's difficulty. It oscillates the checkInCost to create windows of opportunity for users and "tax events" for squatters.
- Spike Period (100 $MAIL): A 1-month killzone where check-ins are extremely expensive. This forces squatters to choose between a massive "tax" or risk having their names automatically bought out.
- Drop Period (0.000001 $MAIL): A 1-month window where check-ins are effectively free.
- The Year-End Drift: Every 6th spike cycle (roughly 1 year), the "Drop" period is extended to 2 months. This shifts the calendar schedule, ensuring that Spike months are not predictable year-to-year.
The following table shows how high-fee months (Spikes) rotate through the calendar:
| Year | Month 1 (Spike) | Month 2 (Drop) | Month 3 (Spike) | Month 4 (Drop) | Month 5 (Spike) | Month 6 (Drop) | Month 7 (Spike) | Month 8 (Drop) | Month 9 (Spike) | Month 10 (Drop) | Month 11 (Spike) | Month 12 (Drop) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Year 1 | JAN | feb | MAR | apr | MAY | jun | JUL | aug | SEP | oct | NOV | dec (Extra Drop) |
| Year 2 | jan | FEB | mar | APR | may | JUN | jul | AUG | sep | OCT | nov | DEC |
| Year 3 | jan (Extra Drop) | feb | MAR | apr | MAY | jun | JUL | aug | SEP | oct | NOV | dec |
When a name expires and the 7-day grace period ends, the top market bid can be pushed into a 3-week Settlement Queue. This creates a race between the Owner (Check-in) and the Bidder (Settlement).
- Price Locking: The price of a check-in is locked in at the moment of initiation.
- Price Validation: The price of a check-in for a bidder is only validated at the end of their 3-week wait. If they initiated during a fee drop period, but finalize during a fee spike, they must have 100 $MAIL in their wallet to complete the settlement.
- The Victory Condition: Because settlement takes 3 weeks, if the current owner completes their check-in before an undesirable bid settles, the pending settlement is automatically deleted and the bid is returned to the general bid pool. This requires the check-in being fully processed, not just queued.
The system uses a 1% penalty to ensure bidders have "skin in the game."
- Applies to: Bidders who manually cancel a bid after it has been accepted for settlement, OR bidders who fail to have enough $MAIL in their wallet at the moment of settlement.
- Does NOT Apply to: Bidders who cancel a bid before it is accepted.
Legitimate users with "trash" names (e.g., randomGuy600) can defend against grief-bidders by placing a bid on their own name from a second wallet.
- If a griefer outbids them, the owner can simply accept the bid and take the griefer's $MAIL, leaving them with a "trash" name.
- A bid placed during the spike period is likely to settle during the drop. If the user "loses" the name to their own second wallet, they would have successfully avoided a forced takeover of their name without checking in during a spike period.
- If a griefer places a bid during the drop period, the owner can just check-in.
The MailSpiker contract uses a "Not yet!" logic gate. If the required duration for a Spike or Drop has not elapsed, the function returns immediately. This avoids expensive SSTORE operations, saving ~90% of gas for users or bots who monitor the contract state.
Once initialized, the ownership of MailNames should be transferred to the MailSpiker contract. This "burns" administrative control, making the Spike/Drop cycle an immutable, autonomous law of the namespace.