Trade-Rate Limiting for New Buyers

[HenrikJannsen]

Trade-Rate Limiting for New Buyers

Overview

This proposal introduces a rate-limiting mechanism for new or low-reputation buyers to mitigate fraud involving stolen bank accounts. The system allows sellers to anonymously signal that a buyer has recently completed a trade, enabling other sellers to enforce time-based limits on how many trades the buyer may execute.

The mechanism is privacy-preserving, leverages P2P messages validated by an oracle, and prevents abuse by requiring seller signatures and enforcing oracle-level penalties for misuse.

Only buyers below a certain trust threshold are affected by that system. E.g. after account age is > 30 days, this restriction is lifted; buyers with reputation > 20 000 don't require that.

---

Goals

1. Reduce the viability of stolen bank account fraud by preventing high-frequency trade attempts.
2. Allow flexible rate-limits based on buyer safety indicators (deposit size, reputation, account age).
3. Preserve privacy using hashed identifiers.
4. Prevent malicious sellers from spamming fake events.
5. Avoid centralization by using an oracle only as a validation/publishing authority.

---

Core Mechanism

1. Blinded Account Hash

For each trade, the seller receives the buyer’s payment account hash + a secret.
This composite hash functions as an anonymous buyer-identifier for time-limited rate-control.

2. Seller Initialize-Trade Announcement

At initializing a trade, the seller submits the following to the oracle:

• blindedAccountHash
• date
• sellersPubKey
• sellerSignature
• sellerReputationScore

The seller does not include any personal payment details.

3. Oracle Validation Process

To prevent abuse, the oracle:

• verifies date is inside a +/- 2 hour tolerance range
• verifies the seller signature
• validates that hash of sellersPubKey matched an existing seller profile ID in the network
• verifies sellers provided reputation score is inside a tolerance range of the reputation seen in the network
• rate-limits sellers to prevent mass submissions
• stores the entry for a limited window (e.g., 30 days)

Oracle maps and blurs seller reputation to a sellerTrustScore to a value between 0-1. This is to avoid linkage to seller identity as well as to add weight to how much the data can be trusted.

After validation, the oracle publishes the announcement to the P2P network (authorized data).

This contains:

• blindedAccountHash
• date
• sellerTrustScore

This data has a short TTL (e.g. 2-5 days).

4. P2P Data Available to Sellers

When a seller receives a new incoming trade request, they can query:

• whether the buyer blinded account hash has appeared in the defined time frame (e.g. 24 hours)
• how many such appearances exist
• how trust worthy the data is

---

5. Rule Set for Buyer Trade Limits

Each buyer receives a dynamic trade limit based on their safety characteristics:

Baseline for New Buyers

• Maximum: 1 trade / 24h
• Maximum amount: 250 USD

Buyers Boosts Options

Buyer Parameter	Effect on Limit
Higher security deposit (e.g., 100%)	Increase to 2 trades / 24h
Buyer has reputation	Increase limit further based on reputation score
Account age	Gradual limit relaxation

This adds flexibility for honest buyers who are willing to show they have skin in the game.

---

Fraud Mitigation Rationale

1. Stolen Bank Account Scammers Typically Need Speed

They must:

• drain the victim account quickly
• perform multiple trades in a short time-frame
• extract maximum liquidity before account owner notices

Rate-limiting blocks high-speed exploitation, forcing fraudsters into a slow, inefficient process where their risk of detection skyrockets.

2. Incentives Are Misaligned for Fraudsters

Since new buyers start with very low limits, a scammer cannot:

• perform multiple parallel trades
• cycle through many sellers
• quickly turn stolen bank balances into BTC

3. Deposits Make Abuse Expensive

To lift limits, the scammer must post larger deposits, which can be slashed if trade ends up in arbitration.

This sharply raises the cost of attacking.

4. Oracle Prevents Fake Seller Announcements

Without validation, malicious sellers could block legitimate buyers.
With the oracle verifying:

• seller identity
• seller signatures
• reasonable submission behavior

Abuse becomes detectable and punishable. Sellers without reputation (nothing to lose) will have less weight in the system and the oracle nodes can apply more strict rate limits for those.

5. Privacy-Friendly

Even though trade frequency is tracked, the system reveals no bank details and no identity—only hashed values and time windows. Only sellers trading with the buyer would see that there have been other trades in the given time frame. But data have short TTL and will vanish from the network.

---

Data Lifecycle

1. Submission to oracle by seller
2. Oracle validates and signs
3. Oracle publishes P2P announcement
4. Sellers check P2P data for recent entries
5. Entries automatically expire after N hours (e.g., 2 days)

This avoids long-term storage and minimizes data footprint.

---

Pros & Cons

Advantages

• Strong mitigation of stolen bank account fraud.
• Low burden for honest buyers.
• Increased safety for sellers.
• Buyer incentive alignment via deposits and reputation.
• Prevents DoS attacks by malicious sellers.
• Fully functional even with low-trust environment.

Limitations

• Requires oracle role (but limited to validation).
• Leaks trade-frequency to short term future sellers - though that is required for the protection.
• Does not stop a scammer who performs just one scam trade—but limits the potentially stolen amount per time interval.

---

Conclusion

This proposal introduces a practical, privacy-preserving mechanism to limit the damage from stolen bank accounts by:

• restricting trade frequency,
• anchoring announcements via an oracle,
• enforcing seller signatures,
• incentivizing buyers to build a trustworthy profile.

It is incremental, compatible with Bisq’s decentralized architecture, and fits naturally into the account age, security deposit and reputation models.

Note: This is an AI generated summary

[HenrikJannsen]

Open Issue: Using Account Age for Trade Rate Limits

There is an unresolved issue with using account age as a factor in trade rate limits.

---

1. Current Account Hash Design

The account hash is derived from three components:

1. Account payload fingerprint (e.g., hash of the IBAN)
2. Public key (a newly generated key pair per account)
3. Salt (a random secret generated per account)

The public key and salt are newly created for every account. This means that even if a user reuses the same payment data, each account will produce:

• A different account hash
• A separate account age timestamp

---

2. Impact on Trade Limits

Trade Amount Limits

If a user creates multiple accounts with identical payment data, the accounts will have roughly the same creation time and therefore similar age. As a result, trade amount limits remain consistent across those accounts. This does not introduce a significant problem.

Trade Rate Limits (Problem)

The issue arises when account age is used to increase trade rate limits.

A user could:

• Create multiple accounts using the same payment data
• Receive independent rate limits for each account
• Effectively reset and multiply their allowed trade frequency

This undermines the intended protection mechanism.

---

3. Possible Solutions

Option 1: Use the Account Fingerprint Directly

Instead of using the combined hash, rate limits could be tied directly to the account fingerprint.

Advantage

• Prevents multiple accounts with identical payment data from bypassing rate limits.

Disadvantage

• Reduces privacy.
• Anyone who knows the payment data (e.g., IBAN) could derive the fingerprint and attempt to correlate it with P2P network activity.

In practice:

• Only trade counterparties learn payment data.
• They already exchange verification data, including the account age hash.

The additional privacy risk mainly concerns entities that already possess payment data (e.g., a bank) and actively scan the P2P network for correlations. While this may not be highly realistic, minimizing linkability remains preferable.

---

Option 2: Let the Oracle Detect Duplicate Fingerprints

The oracle node could:

• Persist account fingerprints
• Detect multiple timestamp requests for the same underlying payment data
• Reject duplicates

Additionally, the UI could prevent creating multiple accounts with the same fingerprint. If duplicate account creation is rejected at the UI level, the oracle can safely reject repeated timestamp requests.

Impact

• Slight reduction in privacy toward the oracle
• Lower overall privacy risk compared to public fingerprint usage
• Restrict account creation

---

Option 3: Oracle-Derived Secondary Fingerprint (Recommended Variant)

Introduce an oracle-side secret, shared among oracle nodes.

The oracle would:

• Derive a secondary salted fingerprint from the account fingerprint and the oracle secret
• Use this derived value internally for rate limit enforcement

Advantages

• The raw fingerprint is never exposed on the network
• Prevents rate-limit bypass via duplicate accounts
• Avoids strict protocol-level restrictions on multiple account creation
• Maintains better privacy compared to Option 1

Tradeoff

• Requires coordination between oracle nodes to share the secret

This approach avoids blocking legitimate cases, such as:

• Device changes
• Hard drive crashes
• Account recreation

---

Option 4: Remove Account Age from Rate Limits

Another alternative is to stop using account age as a factor for increasing trade rate limits altogether.

This eliminates the bypass vector but also removes the intended benefit of rewarding long-standing accounts with higher trade frequency.

---

Summary

The core problem is that account age is currently tied to an account hash that can be regenerated arbitrarily. This allows users to bypass rate limits by creating multiple accounts with identical payment data.

The most balanced solution appears to be introducing an oracle-derived secondary fingerprint based on a shared secret. This preserves privacy better than exposing the raw fingerprint while preventing rate-limit abuse.

[HenrikJannsen]

After more thought about the above I tried another approach. Still open issues but here the preliminary state:

TradeRateAttestation Model Proposal

Overview

If a Bitcoin buyer has not yet reached the unlimited trade rate, they must provide proof that they have not exceeded their trade limit. This proof is obtained from oracle nodes via a TradeRateAttestationRequest.

The seller is responsible for validating the request and sending the request to the oracle nodes.

---

Protocol Flow

1. Buyer → Seller: TradeRateAttestationRequest

When initiating a trade, the buyer sends a TradeRateAttestationRequest within the trade protocol.

TradeRateAttestationRequest

• buyerPubKey (profile public key)
• buyerSignature (signature over TradeRateAttestationPayload)
• tradeRateAttestationPayload

TradeRateAttestationPayload

• accountHash
• accountAge
• importedBisq1SignedAccountAgeWitness
• fingerprintHash
• tradeIdHash
• date
• profileId
• reputationScore

---

2. Seller-Side Validation

The seller performs initial validation before contacting the oracle:

• Verify accountHash matches.
• Verify fingerprintHash matches.
• Verify the imported Bisq 1 signed account age witness exists in the P2P network.
• Verify tradeId matches the current trade ID.
• Verify profileId matches the public key.
• Verify reputationScore is within a tolerance window.
• Verify date is within ±2 hours.
• Verify buyer signature.

If any check fails, the trade is rejected.

---

3. Seller → Oracle: Verification Request

The seller send the TradeRateAttestationRequest to all available oracle nodes via a HTTP request.

The seller performs this step (not the buyer) to prevent:

• Suppression of negative oracle responses.
• False claims about oracle unavailability.

The seller has no incentive to manipulate this step.

---

4. Oracle Validation

Each oracle independently verifies:

• accountAge is within tolerance based on P2P lookup of accountHash.
• Imported Bisq 1 signed account age witness exists in P2P network data.
• date is within ±2 hours.
• profileId matches buyerPubKey.
• reputationScore is within tolerance based on P2P lookup.
• accountHash is valid for the provided fingerprintHash, salt, and public key.

Because oracles may have slightly different views of network data, tolerance windows are applied to avoid unnecessary rejections.
Resulting date from multiple oracles need to be deterministic.

---

5. Rate Limit Check

If validation succeeds, the oracle evaluates the trade rate limit based on:

• Account age
• Imported Bisq 1 signed account age witness
• Reputation score

The oracle:fingerprintHash

• Uses fingerprintHash as the storage key.
• Checks entries from the past 24 hours (actually we use 22 hour for tolerance from clock screw).
• Verifies the new request does not exceed the allowed limit.

Example:

• If the limit is 2 trades per 24 hours,
• The oracle ensures no more than 1 existing entry is present.

If valid, the oracle stores the TradeRateAttestationRequest locally for the defined retention period (e.g., 24 hours).

---

6. Oracle → Seller

The oracle responds with:

• isTradeRateLimitExceeded

---

7. Oracle Availability Handling

The seller queries all available oracle nodes.

• If no oracle node responds unsuccessfully, normal validation proceeds.
• If none respond:
  • The seller retries once.
  • If still unsuccessful, the rate limit check is skipped to preserve trade availability.

---

Impact on Trade Protocol

Oracle requests may be delayed due to Tor routing.

To avoid delaying the trade protocol:

• The seller initiates the oracle request immediately at take-offer time.
• Blockchain confirmation time typically provides sufficient waiting time.
• A timeout and single retry round are used.
• Trade protocol is blocked with further progress until request is either successful or timeouts at retry are triggered.
• If still unsuccessful, the rate limit check is skipped.

---

Risk Analysis

Privacy Implications

The oracle learns:

• Linkage of buyers profile and account hash and fingerprintHash
• Trade frequency

Data is stored only as long as required (e.g., 24 hours).
This requires trust that the oracle enforces its data retention policy.

---

Security Risks

Malicious Oracle

A malicious oracle could:

• Approve trades that exceed the limit.
• Reject valid requests.

Invalid rejections are easily detectable by users reporting the problem and may result in bond loss.
False approvals are mitigated if multiple oracles exist and at least one behaves honestly. Mismatching oracles will also be reported and investigated. Only if all oracles collude the attack would be successful.

---

DDoS Attacks

A scammer may attempt to DDoS oracle nodes to bypass rate limit checks.

However:

• Trade amount limits remain in place.
• Bank-side fraud detection remains relevant.
• The rate limit is only one layer of protection.

An alternative mitigation would be to pause trades until oracle availability is restored, though this creates a trade availability risk.

---

Availability Risks

• If only one oracle is online, redundancy is reduced.
• If all oracles are offline:
  • The trade is delayed.
  • Eventually the rate limit check is skipped.

This preserves liveness at the cost of temporarily weakened protection.

---

Inconsistency Risks

Clock Drift

Oracles rely on time-based checks:

• Date tolerance: ±2 hours
• 24-hour window checks

To mitigate clock drift:

• Tolerance windows are applied.
• Instead of strict 24-hour comparison, a 22-hour effective window may be used.

As long as oracle clocks do not drift more than ±2 hours, inconsistencies should not occur.

---

Oracle State Divergence

If one oracle was offline and missed entries:

• It may respond positively due to incomplete data.
• If another oracle responds negatively, the trade fails.

This ensures safety at the cost of possible conservative rejection.

---

Attack Scenarios

1. Multiple Accounts Using Same Payment Data

A buyer may attempt to bypass limits by creating multiple profiles and multiple accounts using the same payment account data.

Mitigation:

• The oracle uses fingerprintHash as the rate-limit key.
• Reusing the same payment account data does not bypass the limit.

Legitimate use of multiple profiles is supported (e.g. if user switches to a new computer with a new installation, or after data loss due a hard disc crash), but the rate limit still applies globally per fingerprintHash.

---

2. DDoS to Bypass Rate Limit

An attacker may attempt to disable oracle nodes.

Impact:

• Rate limit checks may be skipped.
• Other protection layers remain active.

This primarily affects availability rather than core trade security.

---

3. Malicious Peer Blocking a Buyer

A malicious user may attempt to block a legitimate buyer by:

• Submitting requests using the victim’s fingerprintHash.
• Using a new account and/or a new user profile

A malicious user who knows another user’s fingerprint could attempt to consume rate-limit slots using that fingerprint.

Using the fingerprintHash as the rate-limit key enables:

• Protection to bypass rate limit via multiple accounts.
• But it allows potential griefing by filling rate-limit slots.

This problem remains unresolved in the current design.

---

Conclusion

The Attestation model introduces an oracle-based rate limiting mechanism that:

• Prevents multi-account bypass using shared payment data.
• Maintains deterministic validation across multiple oracle nodes.
• Preserves trade availability under partial oracle failure.

However, the fingerprintHash-based rate limiting approach introduces a potential griefing vector that is not yet fully mitigated and requires further design refinement.

[HenrikJannsen]

Addendum: Resolution Strategy for "Malicious Peer Blocking a Buyer" and Fingerprint Reset

Summary of the Core Issue

Using fingerprintHash as the global rate-limit key is necessary to prevent bypass via multiple profiles/accounts that use the same payment account data.
However, this also creates a griefing vector:

• An attacker who knows the victim’s payment account data can derive the same fingerprintHash
• The attacker can attempt to create a timestamp / claim for that fingerprint
• If the attacker is accepted first (or can trigger resets), the legitimate user may be blocked

This means:

• Delay / cooldown / PoW / bond alone are not sufficient
• They increase cost/friction but do not prove ownership
• Therefore they do not prevent a determined attacker from racing or repeatedly blocking the legitimate user

---

Security Invariant

A fingerprintHash ownership change (or re-registration for an existing fingerprint) must never be possible via an unauthenticated reset alone.

In other words:

• No unauthenticated reset may transfer control of a fingerprint entry
• Any ownership change must require a stronger proof path

This is required to prevent repeated reset/race griefing attacks.

---

Practical Model

Normal Case (No Reset Needed)

For the multiple-account / same-install use case, the UI can reuse the same local salt/key material so the same payment account data results in the same hash / identity continuity.

This avoids duplicate-claim issues in the common case.

---

Exceptional Case (HD Crash / Migration Without Backup)

If the user lost local data and cannot continue using the existing fingerprint entry, recovery requires a moderator-based reset flow.

Why a moderator-based solution is required

Because fingerprintHash alone is not a sufficient ownership proof:

• an attacker may know the fingerprint
• delay/cost mechanisms do not distinguish attacker from legitimate owner

Therefore, a human-verified ownership process is required for the no-backup recovery case.

---

Moderator-Based Reset Flow (Proposed)

Roles

• Moderator: verifies user-provided proof of payment account ownership (user provides the required evidence/data to the moderator).
• Security Manager (bonded role): authorizes the reset after moderator approval.
• Oracle nodes: apply the reset only upon receiving a valid signed reset authorization message.

Evidence / Verification (Out-of-Band)

The user provides proof of ownership of the payment account (e.g. guided screen-sharing / video proof under defined moderation rules).

The moderator verifies the evidence and approves recovery.

Oracle Authorization

After approval, the Security Manager sends a special signed reset authorization message to oracle nodes.

Oracle nodes must only apply a reset / ownership update if:

• the authorization message is valid
• the signer role is authorized
• required moderator/security approval conditions are met
• the authorization contains all required replacement data for the fingerprint entry

---

Oracle Reset Semantics

To avoid introducing a bypass or new attack vector, a reset should be modeled as an ownership update, not deletion.

Recommended behavior

• Do not hard-delete the fingerprint entry
• Update ownership/control metadata for the fingerprint entry
• The reset authorization message contains the replacement data that would normally be stored from a timestamp request
• The oracle replaces the stored ownership-related fields, while preserving:
  • fingerprintHash
  • original account age date
• Apply the reset deterministically across all oracle nodes

---

Why a Secret- or Password-Based Recovery Approach Is Not Applied

As an alternative to the moderator + Security Manager recovery path, a secret- or password-based recovery mechanism was considered.
However, these options were rejected because they do not provide a better overall tradeoff for the targeted recovery scenario.

Reasons

• If the user has a backup of a recovery secret, they likely also have a backup of the account data

  • In that case, the user can usually restore the account directly and continue using the existing fingerprint entry
  • A reset flow is typically not needed

• A password-based recovery mechanism introduces a permanent lockout risk

  • If the user forgets the password, they may be unable to recover access to the fingerprint entry
  • This creates a poor UX for the exact exceptional case the reset flow is intended to solve (HD crash / migration without backup)

• Secrets/passwords do not eliminate the need for a fallback recovery path

  • A no-backup / forgotten-password case would still require a human-mediated recovery mechanism
  • Introducing both systems increases complexity while only partially improving recovery coverage

Result

For the no-backup recovery case, a moderator-mediated recovery flow with Security Manager authorization is preferred as the primary exception path.

Resulting Design Direction

This proposal should treat the no-backup recovery case as a moderator-mediated recovery path:

• fingerprintHash remains the global rate-limit key
• re-registration / ownership change for an existing fingerprint requires strong authorization
• unauthenticated reset is not allowed to take over a fingerprint
• moderator + bonded security manager provide the exception path for legitimate users after data loss / migration without backup

This closes the repeated reset/race lockout attack while preserving a usable recovery path.

[HenrikJannsen]

Technical specification

1) Account timestamp authorization (user → oracle)

AuthorizeAccountTimestampRequestPayload

• date
• hash (account hash)
• fingerprintHash
• saltedFingerprint
• pubKey (account pub key)

AuthorizeAccountTimestampRequest

• authorizeAccountTimestampRequestPayload
• signature (signature over authorizeAccountTimestampRequestPayload)

Oracle state

Oracle maintains:

• accountTimestampRequestByFingerprintMap (fingerprintHash -> AuthorizeAccountTimestampRequestPayload)
• map with hash as key and accountTimestampDate as value

Oracle adds the AuthorizeAccountTimestampRequestPayload only if there is no existing entry for the same fingerprintHash.

Oracle publishes AccountTimestamp containing:

• hash
• date

---

2) Trade protocol (buyer → seller)

At trade protocol start, the buyer creates TradeRateAttestationData and sends it to the seller.

TradeRateAttestationData

• signature (signature over TradeRateAttestationPayload using accountPrivKey)
• tradeRateAttestationPayload

TradeRateAttestationPayload

• id
• accountPubKey
• fingerprintHash
• saltedFingerprint
• accountHash
• accountCreationDate
• tradeIdHash
• tradeDate
• importedBisq1SignedAccountAgeWitness
• reputationScore
• profileId
• paymentRail

---

3) Seller validation

Seller verifies:

• signature
• accountCreationDate matches the date from the AccountTimestamp existing in the network
• fingerprintHash matches the hash of the fingerprint derived from account data
• saltedFingerprint is correct
• accountHash matches hash of saltedFingerprint and pubKey
• tradeIdHash matches hash of trade ID
• tradeDate is within tolerance range
• importedBisq1SignedAccountAgeWitness exists in the network
• reputationScore exists in the network for the peer profileId and is within tolerance range
• paymentRail matches trade paymentRail

Seller creates the trade rate limit using:

• paymentRail
• accountCreationDate
• importedBisq1SignedAccountAgeWitness
• reputationScore

If the buyer has already reached the unlimited trade rate tier, no oracle request is required and the protocol continues without trade-rate attestation.

---

4) Seller → oracle nodes

Seller sends TradeRateAttestationRequest to oracle nodes. The trade protocol is paused until responses are received or timeout occurs.

• On timeout/failure, seller retries once.
• If the retry also fails, seller gives up.
• If all oracle nodes fail, the rate limit check is bypassed.

TradeRateAttestationRequest

• signature (buyer signature from TradeRateAttestationData)
• tradeRateAttestationPayload

---

5) Oracle validation

Oracle verifies:

• signature
• accountCreationDate matches the date from the AccountTimestamp existing in the network
• accountHash matches hash of saltedFingerprint and pubKey
• lookup AuthorizeAccountTimestampRequestPayload in accountTimestampRequestByFingerprintMap using fingerprintHash, and verify pubKey and saltedFingerprint match
• tradeDate is within tolerance range
• importedBisq1SignedAccountAgeWitness exists in the network
• reputationScore exists in the network for profileId and is within tolerance range
• no entry exists in tradeRateAttestationByFingerprintHashMap with the same tradeRateAttestationPayloadHash (replay protection)

Oracle creates the trade rate limit using:

• paymentRail
• accountCreationDate
• importedBisq1SignedAccountAgeWitness
• reputationScore

---

6) Oracle rate-limit state and decision

Oracle maintains tradeRateAttestationByFingerprintHashMap with:

• key: fingerprintHash
• value: HashSet<TradeRateAttestation>

The map is pruned hourly by removing entries older than 24 hours.

TradeRateAttestation

• tradeDate
• accountHash
• tradeRateAttestationPayloadHash

Replay handling:

• Add entry only if tradeRateAttestationPayloadHash is not already present.

Decision:

• Oracle checks entries for the same fingerprintHash
• Oracle counts entries younger than 22 hours
• If the count is less than the computed trade rate limit:
  • add TradeRateAttestation
  • return success
• Otherwise:
  • return reject (LIMIT_EXCEEDED)

TradeRateAttestationResponse

• requestId
• rateLimit
• result (ALLOW, LIMIT_EXCEEDED, INVALID_REQUEST, TEMP_ERROR)
• oraclePubKey
• signature (oracle signature over all fields above)

---

7) Seller handling of oracle responses

Seller verifies:

• requestId
• oracle signature using the publicly known oracle pubkey

Seller waits until:

• all responses are received, or
• timeout + retry are exhausted

Decision:

• If any oracle returns a reject result, the trade fails
• Otherwise, the protocol continues

---

Fingerprint ownership update request

In the rare case that the user has lost access to their account data and sets up a new account with a new salt and key pair, but with the same payment account data, the user can request a fingerprint ownership update via a moderator.

The user creates an AuthorizeAccountTimestampRequest and sends it to the moderator.
The moderator checks whether the user is the legitimate owner of the account data. If confirmed, the moderator sends a FingerprintOwnershipUpdateRequest to the oracle nodes.

FingerprintOwnershipUpdateRequest

• AuthorizeAccountTimestampRequest
• pubKey of moderator
• signature of all above

Oracle validation and update

Oracle verifies:

• moderator is a bonded role
• moderator pubKey and signature are valid
• new data differs from the existing entry

Oracle then:

• moves the existing AuthorizeAccountTimestampRequestPayload to a backup map
• replaces the entry in accountTimestampRequestByFingerprintMap with the new value
• preserves the original date from the old entry (to keep account age)
• publishes a new AccountTimestamp with the new hash

Rate-limit implications

No explicit action is required for tradeRateAttestationByFingerprintHashMap.

• Entries are pruned automatically
• The 24-hour prune time prevents abuse of the update request to reset trade rate
• In practice, the moderator process also introduces additional delay

Repeated ownership updates

Oracle can detect prior updates via the backup map and may reject repeated update requests.

This is an exceptional case and legitimate users are not expected to require it more than once.
A more tolerant policy can be applied later if needed.