Implement Regulatory Compliance Features: Blacklist and Authorized Accounts

[egonspace]

Problem Statement

To effectively respond to regulatory requirements, StableNet will introduce two key features: a blacklist mechanism and special preferential treatment for authorized institutional accounts. This issue outlines the scope and implementation details for these features.

Proposed Solutions & Features

1. Blacklist Functionality

The StableNet protocol will define the following behaviors for blacklisted accounts:

• Transaction Rejection: If the from address of a transaction is blacklisted, the transaction will be reverted.
• EVM Call Restriction: If the target of an EVM call is a blacklisted address, it will trigger a revert.
• Fee Delegation Prevention: If the fee payer in a fee delegation is a blacklisted address, the transaction will be reverted.
• NativeCoinAdapter Signature Denial: If the signer of a permit signature or transferWithAuthorization signature within the NativeCoinAdapter is blacklisted, the operation will be denied.

Furthermore, independent of the consensus protocol, go-stablenet will be implemented to reject transactions containing blacklisted addresses in either the from or to fields directly from the mempool, thus preventing their propagation.

This issue is a more concrete version of #11

2. Authorized Account Concept

A concept for accounts that have completed KYC (Know Your Customer) or similar authentication processes for institutional entities will be introduced.

• Transaction Prioritization: These authorized accounts will be eligible for prioritized transaction processing. They will be able to submit higher priority gas fees, thereby incentivizing validators to preferentially include their transactions in blocks.
• Standard Account Behavior: Regular accounts, even if they submit higher priority fees, will only have gas deducted up to a pre-agreed gasTip.
• Purpose: This feature ensures that even during periods of network congestion, transactions from authenticated institutions can receive preferential treatment within the StableNet ecosystem.

3. Account Extra Field

The standard go-ethereum Account structure is defined with only four fields: Nonce, Balance, StateRoot, and CodeHash.
go-stablenet will extend this Account structure by implementing an Extra field. This Extra field will provide a foundational mechanism to attach various flags or indicators to an account.

• Lookup Mechanism: This means the blacklist status or authorized status of an account can be queried directly via its Extra field.
• Performance Optimization: This design eliminates the need for separate storage slots to store blacklist or authorization flags, allowing for real-time determination based solely on the Account information during transaction processing, thereby mitigating potential performance issues.

4. GovCouncil Authority

The ability to write to an account's Extra field must be extremely restricted.

We define the GovCouncil as the exclusive entity possessing this authority.

• Control over Flags: The GovCouncil will have the power to set or unset the blacklist flag and authorized flag for specific accounts.