Account Permissioning

BESC Hyperchain implements on-chain account permissioning at the protocol level via Hyperledger Besu's native permissioning framework. This is not an application-layer filter — it is enforced by every node in the network before a transaction is ever broadcast to validators.

How It Works

The permissioning contract at 0x7fE182b8Dd4Af1cE7DeD446dB7174fbE6656695c implements:

function transactionAllowed(
    address sender,
    address target,
    uint256 value,
    uint256 gasPrice,
    uint256 gasLimit,
    bytes calldata payload
) external view returns (bool);

Besu calls this function for every transaction before accepting it into the transaction pool. If transactionAllowed returns false, the transaction is rejected immediately at the node level — it simply never propagates to the network.

Who Controls Blocking — Validator Governance

No single person or administrator can unilaterally block or unblock an address. All permissioning decisions are made through the BESC Validator Court — an on-chain jury system where active Proof-of-Stake validators vote on every case.

This means the same decentralized validator set that secures the network also governs who may participate in it. There is no admin key, no centralized operator, and no back-room decision-making.

The Validator Court

Active BESC Hyperchain validators serve as the on-chain jury for all blocking cases. Honest voting earns MONEY rewards proportional to validator stake. No separate collateral is required.

Voting Parameters

Parameter	Value
Voting window	48 hours from case opening
Minimum votes to close (quorum)	3
Early close (supermajority fast-path)	Yes — see below
Vote options	Uphold or Dismiss
Tie result	Dismissed — ties always favour the defendant
Verdict execution	Automatic, on-chain, immutable
Quorum miss (< 3 votes at deadline)	Expired — no verdict, reporter bond refunded

Supermajority Fast-Path

The court uses a fast-path to close obvious cases early, saving gas for validators who would otherwise vote after the outcome is already clear.

A case closes immediately when both of the following are true at the moment the 6th vote is cast:

• Condition 1: At least 6 total votes have been cast (double the minimum quorum)
• Condition 2: The leading side has at least 3 more votes than the losing side

Vote tally	Total	Lead margin	Fast-path?	Result
5 Uphold / 1 Dismiss	6 ✓	4 > 3 ✓	Yes — closes now	Upheld
6 Uphold / 0 Dismiss	6 ✓	6 > 3 ✓	Yes — closes now	Upheld
4 Uphold / 2 Dismiss	6 ✓	2 < 3 ✗	No — runs to 48h	Awaiting more votes
3 Uphold / 3 Dismiss	6 ✓	0 < 3 ✗	No — runs to 48h	Tie → Dismissed at deadline
2 Uphold / 1 Dismiss	3	—	No — total < 6	Runs full 48h

Close races stay open

If the vote is contested (e.g. 4-2 or 3-3), the fast-path never triggers and the case runs the full 48 hours — giving every validator time to review evidence and weigh in. Only a clear, decisive supermajority closes early.

Full Case Lifecycle

Step 1 — Report submitted by community member

The reporter pays a 0.5 MONEY bond and submits the suspect wallet address, a primary evidence transaction hash, up to 4 additional evidence transactions, and a written statement. All data is encoded directly into the on-chain transaction — no off-chain storage.

Step 2 — Oracle opens a court session

The oracle bot detects the new report and calls openSession() on the ValidatorVoting contract. Validators are notified via Telegram instantly. The 48-hour clock starts.

Step 3 — Validators review evidence and vote

Each active BESC Hyperchain PoS validator gets exactly one vote per case — Uphold or Dismiss. They review all on-chain evidence transactions and the reporter's statement directly in the Validator Court UI. The vote tally is visible in real time.

Step 4 — Case closes: fast-path or deadline

If a supermajority is reached (see above), the case closes the moment the decisive vote lands. Otherwise it closes automatically at 48 hours. If fewer than 3 validators voted, the case expires with no verdict and all bonds are returned.

Step 5 — Verdict executed on-chain automatically

No admin action is needed. The smart contract calls processReport() automatically at close, which either penalizes the suspect and pays the reporter bounty (Upheld) or closes cleanly with no penalty (Dismissed).

What Triggers a Case

Trigger	Description
Community report	Any user may file a report with a 0.5 MONEY bond and on-chain evidence
Court order / legal ruling	A legally binding judicial decision is submitted to the validator set for a vote
Sanctions / OFAC	Address appears on a recognized regulatory sanctions list
Validator proposal	Active validators may initiate a case directly for imminent network threats

Court orders and legal rulings are processed the same way as community reports — the ruling is submitted as evidence and validators vote. Validators are obligated to honor a valid judicial decision; the outcome is still decided by the validator set, not by any individual.

Contract Functions

The permissioning contract uses a blocklist model: all addresses are permitted by default, and addresses are blocked only after a successful Validator Court verdict.

// Block a single address (executed automatically after a passed vote)
function blockAddress(address addr) external onlyOwner;

// Block multiple addresses in one transaction
function blockAddresses(address[] calldata addrs) external onlyOwner;

// Unblock an address (executed automatically after a passed unblock vote)
function unblockAddress(address addr) external onlyOwner;

// Check if an address is blocked
mapping(address => bool) public blocked;

Governance-Controlled Execution

The onlyOwner modifier refers to the governance execution key used by the oracle contract — not an individual. This key is invoked automatically by processReport() after a validator vote passes. No human manually calls these functions.

Enforcement Points

The permissioning check applies at:

1. The public RPC nodes — blocked addresses are rejected at the node level — a transaction from a blocked address is dropped the moment it arrives and never forwarded
2. The validator nodes — the permissioning contract is checked at the block inclusion stage

This dual-enforcement means there is no path for a blocked address to get a transaction onto the chain.

Checking If an Address Is Blocked

const permContract = new ethers.Contract(
  "0x7fE182b8Dd4Af1cE7DeD446dB7174fbE6656695c",
  ["function blocked(address) view returns (bool)"],
  provider
);

const isBlocked = await permContract.blocked("0xSomeAddress");
console.log(isBlocked ? "BLOCKED" : "Permitted");

Defending Against a Case / Appealing a Block

Any address that is the subject of a Validator Court case has the right to:

• Be notified — cases and their evidence are publicly visible on-chain the moment they are filed
• Present a defense — contact security@bescfinancial.com to submit counter-evidence that validators will review before voting
• Seek legal remedy — if a court rules in the address's favor, that ruling is submitted to the validator set as grounds for a new unblocking vote, which validators are obligated to process
• Appeal a verdict — a formal appeal may be filed with supporting documentation; a new validator vote is held on the appeal

Because every decision requires a validator supermajority vote, no single party can block, uphold, or dismiss a case unilaterally. Every outcome is recorded immutably on-chain.

Asset Migration Policy

BESC Hyperchain is a new and growing network. Unlike established chains such as BNB Chain or Ethereum, our on-chain liquidity and infrastructure are still scaling. As a result, sustained or repeated activity that places significant strain on the network — as determined through the Validator Court process — has the potential to cause meaningful harm to the chain's liquidity pools and operational stability in a way it would not on a more mature network.

To protect the integrity of the chain while ensuring affected holders retain full access to their assets, BESC Hyperchain reserves the right to migrate a holder's assets to BNB Chain in cases where the Validator Court has issued repeated Upheld verdicts against an address for infrastructure-harmful activity.

What Migration Means for You

Migration is not a seizure. All holdings are transferred in full to BNB Chain, where:

• You retain complete ownership of every token
• You are free to sell, transfer, or hold your assets without restriction
• BNB Chain's significantly deeper liquidity pools allow you to exit positions with less price impact than would be possible on BESC Hyperchain at this stage of our growth
• BESC Hyperchain has no further claim on or involvement with your assets after migration

In short: you get your assets on a larger, more liquid chain and can proceed however you choose.

Why BNB Chain

The majority of BESC's external liquidity resides on BNB Chain. Migrating assets there gives the holder access to the deepest available market for BESC-related assets, making it the most practical destination for anyone looking to exit a large position.

When This Applies

This measure is reserved exclusively for cases where:

1. A Validator Court case has been opened against the address
2. Validators have returned an Upheld verdict citing sustained infrastructure harm
3. The pattern of activity has been flagged across multiple Validator Court cases

Activity	Eligible for migration?
Selling tokens — any volume	❌ No
Removing liquidity	❌ No
Normal trading	❌ No
Sustained, validator-reported infrastructure harm	✅ After repeated Upheld verdicts

Standard market activity — including large sells, liquidity removal, or price-impacting trades — is never grounds for migration. This policy exists solely to protect the chain's infrastructure during its growth phase, not to interfere with ordinary market participation.

INFO

All assets are migrated in full. Nothing is withheld, reduced, or penalized. The holder receives the equivalent of their complete BESC Hyperchain holdings on BNB Chain.

What Triggers It

This only applies in one specific scenario: a Validator Court case that reaches an Upheld verdict and explicitly identifies the activity as harmful to the chain's infrastructure. That's it.

Scenario	Eligible for migration?
Selling tokens — any amount	❌ Never
Removing liquidity	❌ Never
Normal trading activity	❌ Never
Coordinated exploit targeting chain infrastructure	✅ After Validator Court Upheld verdict
Deliberate bridge abuse draining external custody	✅ After Validator Court Upheld verdict

Everyday market activity — no matter the size or price impact — is never a trigger. This is narrowly reserved for confirmed, coordinated infrastructure attacks voted on by the full validator set.

Your assets go with you — always

BESC Hyperchain does not seize, freeze, or destroy holdings. The migration policy exists to give you a better-suited home for your activity, not to take anything from you.