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 0x4A7A1400fD67cCE15C87905e6953c2A9d8336D0C 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 — The Validator Court Owns Permissioning

No single person or administrator can block or unblock an address. Ownership of the permissioning contract has been transferred to the BESC Validator Court, an on-chain smart contract at:

ValidatorCourt: 0x58e337F94DB45657480e88CCc6558D4ef673D061

(verified on both explorer and explorer2).

Because the Court contract is the owner of the permissioning contract, the blockAddress / unblockAddress functions can only be reached through the Court's internal verdict path — that is, only after a passing validator vote. There is no admin key, no oracle, and no human who can invoke them. Even the contract's deployer holds no power to block anyone.

The Validator Court

The Court reads the live validator set directly from the on-chain Validator Registry (0x1F5aE93493c8ace89b47e559Ad51Ec32BA736BED). Every currently-active Proof-of-Stake validator is a juror. No separate collateral is required to vote.

Voting Parameters (live on-chain)

Parameter	Value
Voting window	72 hours from case opening
Threshold to Uphold	2/3 supermajority of all active validators (currently 29 active → 20 Uphold votes)
Vote options	Uphold or Dismiss
Default outcome	Dismissed — if the 2/3 Uphold threshold is not reached, the address is not blocked
Verdict execution	Automatic, on-chain, immutable (inside the ValidatorCourt contract)
Who may vote	One vote per active validator; a validator that is itself the target may not vote on its own case

These parameters are read from the contract and can themselves only be changed by a validator governance vote (see Governance below).

How a Case Closes (fast-path + deadline)

The Court settles a case the moment the outcome is mathematically decided — no one waits out the clock unnecessarily:

• Upheld early — the case executes the instant Uphold votes reach the 2/3 threshold.
• Dismissed early — the case is dismissed as soon as it becomes impossible for Uphold to reach 2/3 (i.e. too many Dismiss votes).
• Deadline — if neither threshold is hit within 72 hours, anyone may call finalize(); the case is Upheld only if the 2/3 bar was met, otherwise Dismissed.

This design fails closed: blocking an address always requires an explicit 2/3 supermajority. Silence or a split vote results in no block.

Full Case Lifecycle

Step 1 — Report filed on-chain

A reporter calls fileReport(target, migrate, evidenceHash) (or fileReportBatch([...], …) for a cluster) directly on the ValidatorCourt contract. Filing is tiered:

• Active validators file for free.
• Anyone else posts a 2.5 BESC bond, held by the contract.

The report commits a keccak256 hash of the evidence on-chain; the full evidence (statement, transactions, and screenshots) is stored off-chain and anchored to that hash — see Evidence.

Step 2 — Validators review and vote

Each active validator reviews the evidence in the Validator Court UI and casts one vote — castVote(caseId, Uphold | Dismiss). The tally is visible in real time. Validators may anchor additional counter-evidence with addEvidence.

Step 3 — The accused may defend themselves

While voting is open, the target may call submitDefense(caseId, defenseHash) to put a defense on the record — a written statement and counter-evidence shown to the jury before the vote closes.

Step 4 — Verdict executes automatically

There is no admin step. When the 2/3 threshold is reached (or finalize() runs after the deadline), the ValidatorCourt contract itself executes the verdict:

• Upheld → Block: the Court calls blockAddress on the permissioning contract.
• Upheld → Migrate: the Court blocks the address and emits MigrationOrdered for the off-chain asset-migration process (see Asset Migration Policy).
• Dismissed: no penalty.

Step 5 — Bonds settle

• Upheld: the reporter's bond is refunded in full (a good-faith report).
• Dismissed (bonded report): the bond is split among the validators who voted — an anti-spam participation reward, claimable with claimCourtReward(). Validator-filed reports carry no bond.

Verdict Types

Verdict	Effect
Dismiss	No action. The address remains permitted.
Block	The address is dead-blocked on-chain via the permissioning contract.
Migrate	The address is blocked and flagged for asset migration to BNB Chain (see policy below).
Unblock (appeal)	A previously blocked address is un-blocked after a passing appeal vote.

Appeals — Unblocking Is Also Vote-Gated

Blocking is not permanent by decree. Anyone may file an appeal with fileUnblockReport(target, evidenceHash); validators vote exactly as they do on any case, and a passing 2/3 vote calls unblockAddress. No single party can unilaterally unblock, either — restoring access requires the same supermajority.

Evidence — On-Chain Hashes, Off-Chain Content

Every case anchors its evidence cryptographically:

• The case lifecycle, votes, verdicts, and evidence/defense hashes are stored on-chain — a tamper-proof audit trail.
• The full content — written statements, transaction references, and evidence images (screenshots) — is stored off-chain in the Validator Court service and anchored to the on-chain keccak256 hash. Any viewer can confirm the off-chain material matches what was committed on-chain (an "anchored" badge in the UI).

This keeps large evidence (including images) practical to store while preserving on-chain integrity.

What Triggers a Case

Trigger	Description
Community report	Any user may file with a 2.5 BESC bond and on-chain-anchored evidence
Validator report	Any active validator may open a case directly (no bond)
Court order / legal ruling	A legally binding decision is submitted as evidence for a validator vote
Sanctions / OFAC	An address on a recognized sanctions list is submitted as evidence

Court orders and sanctions are processed the same way as any report — the ruling is submitted as evidence and validators vote. The outcome is decided by the validator set, not by any individual.

Contract Functions (permissioning)

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

// Owner == the ValidatorCourt contract. These are reachable ONLY through the
// Court's internal verdict path after a 2/3 validator vote — never by a human key.
function blockAddress(address addr) external onlyOwner;
function blockAddresses(address[] calldata addrs) external onlyOwner; // batch (sybil clusters)
function unblockAddress(address addr) external onlyOwner;             // appeals
mapping(address => bool) public blocked;                              // check status

No human owner

The onlyOwner of the permissioning contract is the ValidatorCourt smart contract (0xb585…207a), not a person. It calls these functions automatically when a vote passes. There is no oracle key and no manual execution.

Validator Governance (beyond blocking)

The same jury also governs the Court's own parameters and future upgrades — again with no single admin:

• proposeGovernanceAction(...) — validators propose and vote on parameter/config changes (e.g. raise the reporter bond, change the voting window, adjust the supermajority ratio or the anti-harassment refile cooldown). On a passing vote the change executes automatically.
• proposePermissioningOwnershipTransfer(newOwner) — validators can vote to migrate ownership of the permissioning contract to an upgraded Court, so the system is never permanently frozen — yet still no individual key can move it.

A bounded, renounceable owner key exists only to tune parameters within safe limits and to pause the opening of new cases in an emergency. It cannot block, unblock, alter a verdict, or move funds.

Enforcement Points

The permissioning check applies at:

1. The public RPC nodes — 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(
  "0x4A7A1400fD67cCE15C87905e6953c2A9d8336D0C",
  ["function blocked(address) view returns (bool)"],
  provider
);

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

You can also read case history straight from the Court, e.g. getCasesForTarget(address), cases(id), getVoters(id), and isBlocked(address).

Defending Against a Case / Appealing a Block

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

• Be notified — cases and their evidence hashes are publicly visible on-chain the moment they are filed.
• Present a defense — the target can submit a defense on-chain (submitDefense) with a written statement and counter-evidence, shown to the jury before the vote closes.
• Appeal a block — anyone may file an unblock appeal (fileUnblockReport); a passing 2/3 validator vote restores access.
• Seek legal remedy — a court ruling in the address's favor can be submitted as evidence grounding an unblock vote.

Because every decision requires a 2/3 validator supermajority, no single party can block, uphold, dismiss, or unblock 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. The Court tracks the count of upheld verdicts per address on-chain, and a Migrate verdict emits an on-chain MigrationOrdered event that the migration process acts on.

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.