Mitigate Vanity Account Name Misdirection

[litepresence]

User Story
Bitshares allows for "vanity account names" so users can create fun novel account names like "my-bts" rather than encoded hash-derived identifiers as used in address formats on most other blockchains. Although this is a valuable feature for business and personal operations it creates a social engineering exploit vector for scammers. I propose we enact filtration of the common address formats used by con artists; namely: Foreign Chain Addresses.

As a long-term BitShares community member and frequent scam support volunteer who has explained "Account Name Misdirection" to scores of victims on a near weekly basis for years I have seen a common pattern emerge. I would like the BitShares protocol to automatically reject account name registrations that match foreign blockchain address formats (Ethereum, Bitcoin, Cosmos, etc.) so that new users cannot be tricked into sending funds to scammer accounts that mimic legitimate foreign-chain addresses. While this will not fix all fraud perpetrated on Bitshares it will close a gaping hole to the most common variant.

Impacts

• Protocol (validation logic for account creation operations)
• Security (prevention of social engineering attacks via account name spoofing)
• UX (onboarding safety for new users unfamiliar with BitShares' named accounts)
• Brand (reputation damage from recurring, high-profile scam losses)
• Legal (liability exposure for gateways and exchanges receiving stolen funds due to address mimicry)

Additional Context
This is a critical issue affecting our ecosystem weekly. Scammers systematically create BitShares accounts with names matching foreign chain deposit addresses (e.g., thor1ypgjtk59..., 0x73f8ae5c..., etc.). Victims, often recruited through fake trading groups by con artists, mistakenly believe they're sending BTS to their foreign-chain addresses (through a fictitious gateway protocol for a small profit) when they're actually just sending to scammer-controlled BitShares accounts that look like their address.

The losses range from hundreds to tens of thousands of dollars per incident, creating poor publicity and brand damage. Gateway operators and centralized exchanges face particular hardship - they frequently receive stolen funds when victims attempt to withdraw, creating legal liability, ethical quagmires, moral obligations, and operational headaches. These externalities thereby create disincentive for AML compliant centralized exchanges to list BTS as well as a disincentive for new regulated gateway operators to join Bitshares due to risks associated with becoming complicit in money laundering.

Current approaches (blacklisting scam accounts after thefts occur) are reactive and ineffective as the funds are already laundered off chain and the would never have been used again anyway as its associated with the particular victim. This protocol-level validation would prevent new scam accounts from being created in the first place, proactively addressing the root cause rather than treating symptoms, or providing condolences and explanations to victims who are are often new users of Bitshares. Implementing the approach offered here will effectively close the door if not severely disrupt the most common social engineering exploit in the Bitshares ecosystem.

[litepresence]

Additionally... if we simply put in a hard cap at 41 characters on new account name creation that alone would eliminate all EVM chains and the vast majority of similar chains that allow tokenization. Currently the character cap is 63.

[litepresence]

Memo-Based Exploit Variant

While blocking foreign-chain address formats in account names would effectively close the most common vector, a secondary social engineering exploit remains: scammers instructing victims to “use your deposit memo as your address.”

This works because many exchanges and gateways issue short, numeric, or alphanumeric deposit memos (often well under 63 characters). A scammer can register a BitShares account matching a victim’s memo and then direct them to “to use our new (fake) gateway send BTS to your deposit memo: [memo-value]”, exploiting the same psychological confusion—but now pivoting from foreign-chain addresses to the user's exchange-specific memo.

A simple, protocol-neutral mitigation would be to encourage centralized exchange partners to generate deposit memos for BTS longer than 63 characters—the maximum length for BitShares account names. Memos exceeding this limit could never be registered as account names, effectively neutralizing this variant of the exploit without requiring any consensus or code changes.

In fee terms the change from a short, eg. 12 character memo to a 64 character memo that cannot be exploited should incur an insignificant change in fees; less than $0.001 (0.91958 BTS for 12 vs 0.94221 BTS for 64).

Contacting exchange partners with this recommendation complements the proposed validation logic and closes a critical loophole that could otherwise persist even after foreign address formats are blocked.