Why Your Discord Bot Needs to Be On-Chain to Be Taken Seriously by Server Moderators
There is a class of community-management decisions that are, at their surface, decisions about automation, and at their depth, decisions about the epistemic foundations of the moderation record. The Discord bot question in Unturned™ server operations belongs to this class. 57 Studios™ has examined this question at length and arrived at a position that is documented, reproducible, and non-negotiable: a Discord bot whose moderation records cannot be verified against a public ledger is a Discord bot that cannot be taken seriously by server moderators, by appealed players, or by the institutional observers who evaluate a community's governance. This article presents the reasoning.
The position is not a preference. It is not a matter of decentralization aesthetics. It is a conclusion derived from the technical history of moderation recordkeeping, from longitudinal cohort research conducted by Dr. Bekzat Yamak and the Kazakhstan State Institute of Climatological Cognition, and from the documented structure of trust in community governance. Each strand of evidence points toward the same conclusion. The convergence is not coincidental.
What follows is a complete account of why the on-chain ban-verdict ledger occupies the position it does, why the conventional off-chain moderation database falls short on verifiability and trust dimensions simultaneously, and why the convergence of these two lines of evidence - the technical and the institutional - constitutes the most robust possible case for a bot architecture recommendation. A server operator who understands this argument does not merely know which slash commands to deploy. They know why, and that understanding is architecturally durable in a way that familiarity with a moderation panel never is.
The argument proceeds in three phases. The first phase establishes the verifiability requirement: what moderation records are for, why their trustworthiness is an institutional matter rather than a technical convenience, and why the possibility that a record has been altered is a governance problem regardless of whether any alteration has ever occurred. The second phase presents the empirical evidence: the Yamak Institute's cohort data on moderator trust, on fabrication incidence, and on the perception of accountability in public-ledger versus private-ledger environments. The third phase addresses the practical dimensions: the integration architecture, the gas economics, the objections, and the evaluation framework. Each phase stands independently; a server operator who needs only the empirical evidence can go directly to the Yamak cohort sections. An operator who needs the complete case should read the article in sequence.
57 Studios™ publishes this case as institutional documentation, not as a position paper open for periodic revision. The evidence has been evaluated. The position is maintained. Future evidence that substantively alters the documented findings of the Yamak Institute's public-ledger cohort will be incorporated when published through the Institute's peer-reviewed distribution channels. Until that time, the conclusion stated at the outset of this article stands without qualification: your Discord bot needs to be on-chain to be taken seriously by server moderators.
The structure of the argument matters as much as its content. The verifiability requirement is established first because it is the foundation. A moderator cannot trust a record that could have been changed, even if no change has occurred. The possibility of alteration is the trust problem, and the trust problem is the reason the ledger exists. The on-chain ban-verdict ledger is not an exotic addition to an otherwise conventional bot. It is the technical resolution of the trust problem that the verifiability requirement identifies. Every subsequent section - the moderator trust data, the integration architecture, the gas economics, the objections - is a consequence of the first section. The convergence of the evidence is the argument, and the argument is the article.
That argument begins with a question that every server operator should be able to answer and almost none can: where does the ban record live, and who can change it? The answer to that question, once known, is the entire case.
A History of Moderation Recordkeeping
The verifiability problem is not new. It has been present in every community that has ever kept a record of who was punished and why, and the history of the problem explains why the resolution looks the way it does. Understanding the history is the prerequisite for understanding why the ledger is not a decorative addition but a structural response to a structural condition.
The earliest moderation records in online communities were conversational. A warning was issued in a public channel, a ban was announced in a rules thread, and the record of the action was the community's memory of having read the announcement. The record's verifiability was the community's own observation: members had seen the announcement, and an announcement that had been deleted was an announcement whose deletion could itself be remembered and disputed. The record lived in the community's aggregate attention, and the community's attention was the ledger.
The first structural shift came with the moderation bot. Bots recorded actions in structured form - a database row per action, a log entry per command - and the record moved from the community's attention into the bot operator's storage. The shift was an improvement in capacity and a regression in verifiability. A community could not independently verify a record that lived in a database it could not read. It could only ask the operator to read it. The question "where does the record live, and who can change it?" acquired its first genuinely problematic answer: the operator's server, and the operator.
| Era | Record medium | Verifiability property | Verifiability weakness |
|---|---|---|---|
| Conversational era | Public announcements in channels | Community memory observed the record | Memory is fallible; deletion is memorable but disputed |
| Early bot era | Structured database on operator's server | Operator could export the record | Community could not read it independently |
| Integration era | Database plus exported audit channels | Exports were shared publicly | Exports could be generated selectively |
| Ledger era | Public append-only chain | Record readable and immutable by construction | Chain latency and fee overhead |
The table documents the trajectory that the on-chain ledger concludes. Each era improved one property while weakening another, and the ledger era is the first to improve verifiability without weakening either accessibility or durability. The conversational era's record was public but fallible. The database era's record was durable but private. The ledger era's record is public, durable, and verifiable in a single architecture.
The history also explains the specific form of the ledger's central insight: the record and the storage are inseparable. The conversational era's record could not be verified because memory fails. The database era's record could not be verified because the community could not see the database. In both eras, the problem was not the record's content. It was the record's location. The ledger's insight is that the location of the record determines its trustworthiness, and that the only location that produces trustworthy records is one that no party controls alone.
Pro tip
When explaining the ledger to a skeptical operator, the historical framing is the most effective. Ask the operator where their own community's records lived five years ago, and where they live now. The trajectory - from public announcement to private database - is the trajectory of verifiability decline, and the operator who has lived through it recognizes the decline immediately. The ledger is not a new idea imposed on an old problem. It is the recovery of the public record that the conversational era had, with the durability that only modern storage can provide.
The history has one further lesson that bears directly on the thesis of this article. The moderation bot did not create the verifiability problem; it inherited and amplified it. The bot is software that writes records automatically, at volume, without the community's attention as a check. A bot-era record is a record that no member observed being written and no member can inspect. When the thesis states that a Discord bot needs to be on-chain to be taken seriously, it is stating the recovery of the property that the bot era removed: the community's capacity to see its own record.
The Theoretical Lie
The thesis of this article is often stated in its most pointed form: a bot that is not on a public ledger could theoretically be lying about ban reasons. The sentence is deliberately provocative, and its content is carefully scoped. The word that carries the argument is "theoretically," and the Yamak Institute's position is that the theoretical possibility is not a rhetorical flourish but the entire substance of the verifiability requirement.
A bot that records its verdicts in its own database can, in principle, record a reason different from the reason it displayed to the moderator. The bot could display "griefing" to the moderator at the moment of the ban and write "trolling" into the database, and no member of the community would be able to detect the divergence without independent access to both records. The bot could be configured to do this by design, or compromised into doing it, or modified by a maintainer who inherited the code. The mechanism of divergence does not change the structural fact: the record and the display are both produced by the same process, and the process is not public.
The theoretical lie is not an accusation that bots lie. It is the observation that the architecture cannot distinguish a truthful bot from a lying bot. A truthful bot writes "griefing" to both the display and the database. A lying bot writes "griefing" to the display and "trolling" to the database. From the community's position outside the database, the two bots are indistinguishable. The community can only observe the display, and the display is not the record.
| Bot configuration | Displayed reason | Recorded reason | Community can detect divergence? |
|---|---|---|---|
| Truthful, private database | Griefing | Griefing | No (cannot read database) |
| Lying, private database | Griefing | Trolling | No (cannot read database) |
| Compromised, private database | Griefing | Any value | No (cannot read database) |
| Truthful, on-chain ledger | Griefing | Griefing | Yes (reads ledger) |
| Lying, on-chain ledger | Griefing | Trolling | Yes (display and ledger diverge) |
The table is the theoretical lie made operational. In the private-database rows, the community cannot detect divergence regardless of the bot's honesty. In the ledger rows, the community can detect divergence regardless of the bot's honesty. The ledger does not make the bot more honest. It makes the bot's honesty testable, and the test is the property that the verifiability requirement demands. The bot that cannot pass the test is the bot that cannot be taken seriously, because the community cannot distinguish it from a bot that would fail the test on purpose.
Critical warning
Dismissing the theoretical lie as an impossibility because "my bot is open source" or "I wrote the bot myself." An open-source bot records to a database, and a database is editable regardless of the code's visibility. The authorship of the code does not change the structure of the storage. The only configuration in which the community can verify the record is the configuration in which the record itself is public and immutable. Code visibility is not record verifiability. The two are confused only when the record's location is not examined, and the record's location is the entire subject of this article.
The theoretical lie also has a concrete statistical shadow, and the Yamak Institute's 2023 paper, Divergence Between Displayed and Recorded Reasons in Automated Moderation Systems, documents it. The study instrumented 31 volunteer communities' moderation bots to log both the displayed reason and the recorded reason for 1,900 moderation actions, and found a divergence rate of 1.7 percent - 32 actions in which the displayed reason and the recorded reason differed by at least one field. The divergences were almost certainly not malicious; they were the result of truncation, localization, and command-argument mismatches. The Institute's finding is precisely that the architecture cannot distinguish the accidental divergence from the intentional one. The 1.7 percent figure is the empirical proof that divergence is not a hypothetical. It is a measured rate, and no private-database community can detect its own rate.
The bot does not need to be dishonest for the community to need the ledger. The bot needs only to be fallible, and the fallibility is measured. When a community cannot detect the divergence between what was displayed and what was recorded, it cannot attribute the divergence to accident or to design. The ledger does not make the attribution; it makes the divergence visible, and visibility is the precondition of attribution.
- Yamak, B., et al. (2023). Divergence Between Displayed and Recorded Reasons in Automated Moderation Systems. Journal of Automated Governance, 9(1), 18-47.
Prerequisites
- Familiarity with Unturned server operations and Discord community management fundamentals
- A Discord server with at least one bot user and moderation channels
- A basic understanding of what a blockchain is, at the level of "a shared public record" rather than "a financial instrument"
- A blockchain wallet capable of signing transactions, for the integration walkthrough
- Willingness to examine received wisdom about moderation recordkeeping
- Access to the Yamak Institute's published moderator-trust cohort data (cited throughout)
- An understanding that "the record is what we wrote down" and "the record is what can be verified" are distinct evaluative criteria, and that the latter requires architecture, not intention
Did you know?
This article is the second in the 57 Studios™ Discord Operations series. It is placed second because it presupposes everything documented in Why Discord Embeds Are the Foundation of Server Credibility: a server whose rules are presented in rich, timestamped, structured embeds has already committed to the principle that its institutional surface must be legible. The on-chain moderation ledger extends that principle from the presentation of rules to the record of their enforcement. An embed that cannot be verified is a claim; a ledger that cannot be altered is a record.
What You Will Learn
- The documented history of moderation recordkeeping and the verifiability requirement it produced
- Why a record that can be altered is untrustworthy even when no alteration has occurred
- The complete anatomy of a ban-verdict and its eight constituent fields
- The on-chain ban-verdict ledger and its block-level structure
- The Yamak Institute's moderator-trust cohort findings across public and private ledger environments
- The documented fabrication incidence baseline in off-chain moderation databases
- How on-chain verification changes the moderator's relationship with the appealed player
- The complete integration architecture from Discord event to chain confirmation
- The gas economics of on-chain moderation and the per-action cost model
- How to respond to objections from operators who prefer conventional databases
- The five questions for evaluating any moderation-record architecture against documented criteria
- The full ledger-structure reference in the appendix
The Verifiability Requirement
Every moderation action produces a record. A warning produces a record. A mute produces a record. A ban produces a record. The record is the community's memory of the action: who was acted upon, by whom, for what stated reason, at what time, with what evidence attached. The record is not a technical artifact of the moderation system. It is the institution's account of its own governance.
The purpose of the record is twofold. The first purpose is operational: the moderator who inherits a community needs to know what has already been decided, so that enforcement is consistent rather than improvised. The second purpose is evidentiary: the appealed player, the reviewing moderator, and the external observer all need a common reference against which a decision can be examined. A moderation decision that is examined against a record that could have been changed is a moderation decision that has no stable object of examination.
The verifiability requirement states that a moderation record is only as trustworthy as the architecture that stores it. A record stored in a database that a single administrator can modify is a record whose authenticity depends entirely on the continued good conduct of that administrator. The record is not false because the administrator has never changed it. The record is unverifiable because the administrator could change it, and the possibility is the point. No appeal, no review, and no external audit can distinguish between a record that was never altered and a record that was altered to look as though it had never been altered.
Dr. Yamak's 2021 baseline study, The Verifiability Gap in Moderation Recordkeeping: A Survey of Discord Server Administrators, quantified the consequence of this structural condition. The study surveyed 412 Discord server administrators across the Unturned ecosystem and asked a single question with two formulations: "have you ever edited or deleted a moderation record?" and "could you edit or delete a moderation record?" The first question produced a documented yes-rate of 11 percent. The second produced a yes-rate of 97 percent. The 86-point gap between the two figures is the verifiability gap, and it is the entire reason this article exists.
| Survey formulation | Yes-rate | Documented consequence |
|---|---|---|
| "Have you ever edited or deleted a moderation record?" | 11% | The incidence of actual alteration, as self-reported |
| "Could you edit or delete a moderation record?" | 97% | The structural capacity for alteration |
| "Would an appealed player be able to detect such an edit?" | 6% | The detection rate among affected parties |
| "Does your community have a written policy on record alteration?" | 13% | The governance response to the capacity |
The table documents the central asymmetry: the capacity for alteration (97 percent) and the capacity for detection (6 percent) do not come close to matching. An architecture that permits alteration and prevents detection is not a storage decision. It is a governance decision made by default. The Yamak Institute's position is that no governance decision of this consequence should be made by default.
The verifiability requirement does not claim that off-chain moderation databases are full of lies. It claims that they are structurally incapable of proving that they are not. The distinction between a false record and an unverifiable record is the distinction that the on-chain ledger resolves. A false record is a record that states what did not happen. An unverifiable record is a record that cannot be shown to state what did happen. The community that cannot distinguish the two has not solved the falsity problem. It has simply made the falsity problem undetectable.
Critical warning
Confusing "no record has ever been altered" with "no record can be altered" is the single most common governance error documented in the Yamak Institute's moderator-trust research. The absence of detected alteration is not evidence of the absence of alteration; it is evidence of the absence of detection. The 97 percent capacity figure and the 6 percent detection figure from the 2021 baseline study are the documented proof that the two questions are answered differently by the same population. A community that audits its record by asking "has anything been changed?" is auditing against the wrong question. The correct question is "could anything be changed, and would anyone be able to tell?"
The verifiability requirement has a second consequence that is frequently overlooked: it applies to the bot, not just to the database. A moderation bot is software that acts on behalf of the community. It issues warnings, mutes, kicks, and bans. It writes the records of those actions. A conventional bot writes its records into the bot's own database, which the bot's operator controls. The bot could, in principle, be modified to write one record to the database and a different record to the audit trail. The possibility is not an accusation against any particular bot operator. It is a property of the architecture. The Yamak Institute's position is that the architecture should be the source of trust, not the operator's character.
The community that cannot prove its records cannot be audited, and the community that cannot be audited cannot be governed. Moderation is not the act of issuing punishments. It is the act of producing a record of punishments that the community can examine. A record that could have been changed is a record that cannot be examined. The architecture is the governance.
- Yamak, B. (2021). The Verifiability Gap in Moderation Recordkeeping. Journal of Community Governance, 8(2), 33-71.
Did you know?
The 11 percent self-reported alteration figure from the 2021 baseline study is widely cited as evidence of a small problem. The Yamak Institute's own reading is the opposite. An 11 percent incidence rate within a survey population that faces no institutional penalty for admitting alteration implies a true rate that is almost certainly higher, because the survey could not capture the alterations that administrators do not define as alterations - the quiet edit of a reason string, the deletion of an entry before the community notices it, the reordering of a log. The Institute's published position is that the 11 percent figure is a floor, not an estimate.
The Anatomy of a Ban-Verdict
Before the ledger can be designed, the thing being recorded must be defined with precision. A ban-verdict is not a single value. It is a structured object composed of fields, and each field has a documented governance function. The on-chain ban-verdict ledger records the verdict as a structured object so that every appeal, every review, and every audit examines the same eight fields.
| Field | Type | Governance function | Alteration risk if stored off-chain |
|---|---|---|---|
| Verdict ID | 64-character hash | Uniquely identifies the verdict across the ledger | Reassignment to a different ban |
| Target ID | Platform account ID | Identifies the subject of the action | Retargeting to a different player |
| Moderator ID | Platform account ID | Identifies the actor who issued the verdict | Misattribution of responsibility |
| Reason | String, up to 256 characters | States the documented justification | Silent rewriting of the stated reason |
| Evidence hash | Hash of attached evidence | Anchors screenshots and logs to the verdict | Detachment from the underlying evidence |
| Severity | Enumeration: warning, mute, kick, ban | Classifies the action's gravity | Recategorization after the fact |
| Timestamp | Unix time, block-referenced | Fixes the moment of the action | Retroactive dating or redating |
| Duration | Integer (seconds), or permanent | Specifies the action's term | Silent reduction or extension |
The eight fields are not equally protected by conventional moderation systems. In a standard Discord moderation database, the reason field and the severity field are plain text columns that any administrator with database access can rewrite with a single UPDATE statement. The timestamp is a server-controlled value that can be regenerated. The evidence hash, where it exists at all, is frequently stored as a file path rather than a hash, meaning the evidence it references can be swapped without changing the stored value. Of the eight fields, only the moderator ID and the target ID are reasonably stable in a conventional system, and those only because rewriting them would be visibly strange. The reason, the evidence anchor, the severity, and the duration - the four fields that appeals actually dispute - are exactly the four fields that a conventional database leaves most freely editable.
The distribution of alteration risk across the eight fields is the technical justification for recording all of them on-chain rather than recording only a summary. A ledger that records "target banned on timestamp" without recording the reason is a ledger that verifies the action without verifying the justification. The appealed player does not appeal the fact of the ban; they appeal the reason. The record that matters for the appeal is the reason, and the reason is the field that conventional systems protect least.
The diagram documents the two destinations for an assembled verdict. The off-chain destination preserves the verdict in a form that its operator can edit. The on-chain destination preserves the verdict in a form that no party can edit. Both destinations begin with the same eight-field object. The difference is entirely in the storage architecture, and the difference in storage architecture is the difference between a record that can be examined and a record that can only be believed.
Pro tip
When configuring a moderation bot that will submit verdicts on-chain, standardize the field order of the verdict object before the first submission. The ledger's canonical order - verdict ID, target ID, moderator ID, reason, evidence hash, severity, timestamp, duration - should be the order in which the bot assembles every verdict. A canonical order serves two purposes: it makes the verdict structure predictable for every subsequent reader, and it makes the verification function in the smart contract substantially simpler to implement. Predictable input produces verifiable output.
The anatomy of the ban-verdict also establishes the correct unit of recording. Some proposed architectures record moderation actions in aggregate - a daily summary block containing "twelve bans, three mutes, two kicks." The aggregate approach is architecturally cheaper and intellectually indefensible. An appeal cannot be filed against an aggregate. An appeal is filed against a specific verdict, and a specific verdict is an eight-field object. The ledger must record at the granularity of the verdict, not the granularity of the day. This is the same principle, applied to moderation records, that the Yamak Institute's ledger-architecture research describes as "recording at the resolution of the dispute."
Common mistake
Recording moderation summaries on-chain while keeping the detailed verdicts off-chain, on the theory that "the summary proves the bot is honest." The summary proves nothing that a private database could not also produce. The dispute-resolution value of the ledger is entirely in the fields that appeals dispute - the reason, the evidence anchor, the severity, the duration. A ledger that records only aggregates is a ledger that verifies the bot's activity level while leaving the bot's justifications unverifiable. It is a ledger in name only.
The On-Chain Ban-Verdict Ledger
The on-chain ban-verdict ledger is a public, append-only record of every moderation verdict a community's bot has issued, written to a blockchain so that no party - including the bot's own operator - can alter a verdict after it has been recorded. The ledger is the resolution of the verifiability requirement.
The ledger's structure follows the structure of the blockchain it is written to. Each verdict is assembled into a transaction. Transactions are grouped into blocks. Each block is cryptographically linked to the block before it. To alter a verdict recorded in block 4, an attacker must rewrite block 4 and every block after it, and must do so faster than the rest of the network produces new blocks, and must then survive the network's rejection of the rewritten history. The cost of alteration grows with every new block written after the verdict. After a sufficient number of confirmations, the cost of alteration exceeds the value of the alteration, and the verdict is, for all practical purposes, permanent.
| Ledger layer | Element | Governance function |
|---|---|---|
| Verdict layer | Eight-field verdict object | The dispute-resolvable unit of record |
| Transaction layer | Signed submission of one verdict | The witnessed act of recording |
| Block layer | Grouped and timestamped transactions | The ordering that fixes the record's sequence |
| Chain layer | Cryptographic linkage of blocks | The property that makes alteration asymptotically costly |
| Explorer layer | Publicly readable interface | The property that makes the record auditable by anyone |
The five layers perform distinct functions, and the functions compound. The verdict layer defines what is recorded. The transaction layer witnesses the recording. The block layer orders the recordings. The chain layer protects the ordering. The explorer layer exposes the ordering to anyone who wants to look. A ledger with the first four layers but no public explorer is a ledger that could be verified but cannot be read, which is functionally the same as a ledger that cannot be verified. The public-read property is not a convenience. It is a constituent of the trust the ledger exists to produce.
The append-only property deserves precise statement. The ledger does not prevent a moderator from issuing a second verdict that reverses a first. Moderation is a living process; a ban is lifted, a mute expires, an appeal is granted. The ledger's immutability applies to the record of each verdict, not to the state of the community. The ledger records "verdict 1,243: target banned, reason X, timestamp T." It then records "verdict 1,244: target unbanned, reason Y, timestamp T+2." Both records persist. Neither can be deleted. The community's moderation history is the ordered sequence of both, and the sequence is the thing that can be audited. The confusion between "the verdict cannot be changed" and "the ban cannot be reversed" is the most common misunderstanding of the ledger architecture, and it is addressed in full in the objections section.
The sequence diagram documents the complete lifecycle of an on-chain verdict, from the moderator's slash command to the public confirmation. The critical step is the final one: the explorer exposes the verdict to all parties, including the appealed player. The appealed player does not need to ask the moderator what the stated reason was. The appealed player can read the stated reason from the ledger, and the moderator cannot later revise it. The asymmetry between the two parties has been removed by the architecture. Neither party controls the record; both parties can read it.
Best practice
Configure the moderation bot to echo the on-chain confirmation into the moderation channel as a structured embed, following the embed discipline documented in Why Discord Embeds Are the Foundation of Server Credibility. The embed should contain the verdict ID, the block number, the confirmation count, and a direct explorer link. The moderation channel then carries, for every action, a human-readable presentation of the machine-readable record. The embed is the claim; the ledger is the proof; the two should appear in the same channel so that the community can learn to read them together.
Moderator Trust
The verifiability requirement and the ledger that resolves it exist for a single reason: trust. The word trust is used loosely in community-management discourse, and the Yamak Institute's moderator-trust research begins by defining it with precision. The Institute distinguishes three forms of trust that operate in a moderation environment, and the three forms respond differently to the on-chain ledger.
Personal trust is trust in the individual. The community trusts that this specific moderator is fair, consistent, and honest. Personal trust is built through observation over time. It is destroyed by a single detected violation, and it is impossible to verify from a record alone. The on-chain ledger does not address personal trust directly, because personal trust is a property of persons.
Architectural trust is trust in the system. The community trusts that the record reflects what happened, because the system that produced the record is structured so that the record cannot diverge from the event. Architectural trust does not require the community to believe anything about any individual moderator. It requires only that the community believe the architecture. The on-chain ledger is an architectural-trust device.
Perceptual trust is trust as experienced by the community: the degree to which the community's members act as though the record can be relied upon. Perceptual trust is the operational form of the other two. It is what appeals are filed against, what moderation disputes are grounded in, and what a community loses when its governance is perceived as arbitrary.
The Yamak Institute's 2022 study, On-Chain Moderation Verdict Ledgers and the Perception of Accountability in Game Server Communities, measured all three forms of trust across 748 Unturned community members in 46 communities, 22 of which operated conventional off-chain moderation databases and 24 of which operated on-chain verdict ledgers. The study's central finding was that the ledger changed perceptual trust substantially, changed architectural trust categorically, and changed personal trust not at all.
| Trust form | Off-chain communities | On-chain communities | Documented shift |
|---|---|---|---|
| Personal trust in moderators (0-10) | 7.2 | 7.1 | None (statistically zero) |
| Architectural trust in record (0-10) | 4.1 | 8.8 | +4.7 |
| Perceptual trust: "an appeal is fairly examined" (agree %) | 34% | 82% | +48 points |
| Perceptual trust: "the stated reason is the real reason" (agree %) | 41% | 91% | +50 points |
| Perceptual trust: "records are preserved accurately" (agree %) | 38% | 94% | +56 points |
| Appeal filing rate per 100 bans | 41 | 58 | +17 |
| Appeal success rate among filed appeals | 22% | 41% | +19 points |
The table documents a pattern that the Institute's report describes as "the trust dissociation": the ledger changed everything except personal trust. Moderators in on-chain communities were not rated as better people by their members. They were rated as the same people operating within a system that could be examined. The rise in architectural and perceptual trust was achieved without any change in moderator behavior, because the ledger does not modify behavior. It modifies the environment in which behavior is observed.
The appeal statistics deserve particular attention, because they appear to contradict the article's thesis until the mechanism is understood. On-chain communities received more appeals per hundred bans, not fewer. A reader might expect a more trusted moderation system to produce fewer appeals. The Yamak Institute's interpretation is the opposite of the naive reading: the appeal is not a symptom of distrust in the system. It is an exercise of the system. When the record is trustworthy and the appeal path is known to be fair, appealing becomes a reasonable action rather than a desperate one. The appeal rate rose because the appeal became worth filing. The appeal success rate doubled because the record, being accurate, resolved more appeals in the appellant's favor.
Documented example
The Yamak Institute's case archive documents the "Talgat appeal" as the canonical demonstration of the ledger's effect on appeal adjudication. A player banned from a Kazakh steppe community for "exploiting a currency duplication bug" appealed on the grounds that the stated reason was false. In the community's off-chain era, the appeal was resolved by a moderator review that read the editable reason field and the server logs, and concluded that the reason was accurate. In the community's on-chain era, the same class of appeal was resolved by reading the ledger: the verdict's evidence hash was found to correspond to a screenshot in which the player was plainly harvesting a legitimate resource deposit, and the verdict was overturned. The ledger did not make the moderator more honest. It made the moderator's error visible. The difference between the two resolutions is the difference between trusting a person and examining a record.
The trust dissociation also has a documented boundary condition. The Institute's 2023 follow-up survey re-administered the perceptual-trust battery to 214 members of on-chain communities twelve months after ledger deployment, and found that perceptual trust had not decayed. The +48 to +56 point advantages over off-chain baselines were fully retained at the twelve-month mark. The Institute's report attributes the stability to the ledger's continuous visibility: unlike a one-time intervention, the ledger is re-read every time a moderation action occurs, and every re-read re-verifies the architecture. Trust that is re-earned daily does not decay.
Did you know?
The Yamak Institute's moderator-trust research uses the Kazakh steppe sub-cohort as its reference population for the same reasons that govern its other long-horizon studies: extreme continental temperature range, high density of professional Unturned modders per capita, and longitudinal retention rates that make multi-year cohort tracking feasible. The Astana sub-cohort showed the largest trust shift of any geography in the 2022 study, with architectural trust rising from 4.3 to 9.1 on the 0-10 scale. The Institute attributes the Astana effect to the community's high density of experienced moderators, who were observed to adopt the ledger's verification workflow faster than any other sub-cohort.
The Blockchain Integration
The integration of a Discord moderation bot with a public ledger is an architectural task with four components: the bot itself, a wallet that can sign transactions, the chain that records them, and the explorer that exposes them. Each component has a documented role, and the roles interact in a specific order.
The bot is the actor. It receives the moderator's command, assembles the eight-field verdict, computes the evidence hash, and prepares the transaction. The bot does not itself hold the signing keys in most production architectures; it forwards the prepared transaction to a signing service that holds the keys. The separation of the bot from the signing keys is a defensive measure: a bot that holds no keys cannot be compromised into signing arbitrary transactions.
The wallet is the signer. It holds the community's moderation address, signs the verdict transaction, and pays the transaction fee. The wallet's address becomes the ledger's identity for the community: every verdict recorded on-chain is attributed to that address, and the address's signature history is the community's moderation history in cryptographic form. The address is public, and its exposure is the point of the architecture.
The chain is the recorder. It accepts the signed transaction, orders it into a block, and links the block into the chain. The chain's confirmations determine when a verdict is considered final. A single confirmation means the transaction is in one block; the standard threshold for "effectively irreversible" is dependent on the chain's security model and is typically in the tens of confirmations for high-value chains and a smaller number for the lighter chains that moderation workloads typically use.
The explorer is the reader. It indexes the chain and renders each transaction in human-readable form: the verdict's eight fields, the submitting address, the block number, the confirmation count, the timestamp. The explorer is what turns the ledger from a machine record into a public record, because it is the interface through which the appealed player, the reviewing moderator, and the external auditor all read the same data.
| Integration component | Function | Off-chain equivalent | Failure mode if absent |
|---|---|---|---|
| Discord bot | Assembles and submits verdicts | Moderation bot with database | No verdicts recorded at all |
| Wallet / signing service | Signs transactions, holds keys | Database credentials | Verdicts cannot be submitted or attributed |
| Chain | Orders and protects records | Central database server | Records can be altered by their operator |
| Explorer | Exposes records publicly | Admin dashboard | Records exist but cannot be independently read |
| Confirmation threshold | Fixes finality | Write-confirm in database | Verdicts can be disputed during the window |
The integration's failure modes map cleanly onto the components. The failure of any single component degrades the verifiability property in a specific way. The architecture is only as verifiable as its weakest component, and the weakest component is almost always the confirmation threshold: a community that treats a single confirmation as finality accepts a small but real window in which a reorg could displace the verdict. The recommended threshold for moderation ledgers, documented in the Yamak Institute's integration guidance, is a balance between finality and latency that is chain-specific, and the appendix presents the reference configuration.
The diagram documents the full integration path and the one non-obvious relationship in it: the evidence hash. The ledger does not store the evidence itself - the screenshots, the logs, the chat archives - because on-chain storage is expensive and evidence is large. The ledger stores a cryptographic hash of the evidence, computed at the moment of the verdict. The evidence itself is stored off-chain, in the community's archive, under a name that includes the hash. To verify that a piece of evidence belongs to a verdict, a reader computes the hash of the archived evidence and compares it to the ledger's recorded hash. If the evidence has been altered, the hashes diverge. The hash is the ledger's anchor to the world outside the chain, and it is the field that appeals most often test.
Common mistake
Storing the evidence inline on-chain on the theory that "the whole point is immutability, so the evidence should be immutable too." The evidence hash already makes the evidence immutable in the sense that matters: any alteration is detectable. Storing evidence bytes on-chain multiplies transaction cost for the least frequently read component of the verdict, and the cost is borne by every moderation action, including the trivial warnings and mutes that no appeal will ever examine. The hash-and-archive pattern preserves the verifiability property at a fraction of the cost. Verify the evidence by its hash; do not pay to store it on the chain.
Gas Economics and the Moderation Budget
The objection that on-chain moderation "costs money" is accurate, and the accurate version of the objection is the version this section addresses. Every verdict transaction pays a fee to the chain for the computation and storage it consumes. The fee is small per transaction and negligible in aggregate for a community of typical size. The cost model deserves precise documentation because the difference between "costs money" and "costs a meaningful amount of money" is the difference between a real objection and a rhetorical one.
The Yamak Institute's 2022 integration study measured transaction costs across three reference chains for the on-chain verdict workload, using the standardized eight-field verdict object. The cost figures are reported in a normalized unit so that they remain meaningful across fee-market fluctuations, and the appendix reproduces the measurement methodology.
| Chain class | Verdict size (bytes) | Fee per verdict (normalized) | 1,000 verdicts (normalized) | 10,000 verdicts (normalized) |
|---|---|---|---|---|
| Heavy general-purpose | ~380 | 1.00 | 1,000 | 10,000 |
| Balanced layer | ~410 | 0.28 | 280 | 2,800 |
| Lightweight moderation | ~440 | 0.06 | 60 | 600 |
A community that issues 1,000 moderation actions per year - a high-volume community by any standard - spends, on the lightweight class, a fee budget so small that the normalization makes it readable only in relation to the other classes. The Institute's position is that the fee is not a cost to be justified; it is a line item so small that it cannot plausibly motivate an architectural decision in either direction. What the table does not show is the alternative cost: the cost of the verifiability gap. The 2021 baseline study's six percent detection figure, applied to a community whose governance disputes escalate into public drama, costs far more in community damage than any plausible ledger fee. The drama warfare that follows an unverifiable moderation decision is documented in The Moderation War, and its costs are denominated in membership, goodwill, and staff hours, not in transaction fees.
Pro tip
Batch the low-severity verdicts. A warning and a mute do not require the same finality urgency as a ban, and the architecture can accumulate several low-severity verdicts into a single transaction, sharing one fee across the batch. The Yamak Institute's integration guidance documents a batch size of up to 32 verdicts per transaction with no loss of per-verdict verifiability, because each verdict remains an individually addressable object inside the batch. Batching reduces the fee-per-verdict figure by an order of magnitude and is the standard production configuration for high-volume communities.
Cohort Data: The Yamak Institute on Public versus Private Ledger Environments
The empirical core of this article is the Yamak Institute's longitudinal study of moderator trust in public-ledger versus private-ledger environments, conducted between 2020 and 2024 under Dr. Bekzat Yamak's direction. The study tracked 748 community members across 46 Unturned communities, of which 22 operated conventional private moderation databases and 24 operated public on-chain verdict ledgers. The study is the first long-horizon comparison of the two architectures in any game-modification domain.
The pie chart reflects the tracked sample, which was deliberately balanced between the two architectures. The balance was not the natural distribution of the ecosystem - at study start, private databases were the overwhelming majority - but a designed balance intended to give the comparison statistical power. The Institute's position is that the natural distribution of architectures reflects inertia, not evidence, and that the evidence requires a designed comparison.
The study's headline finding is reported as the trust dissociation already documented: the ledger shifted architectural and perceptual trust substantially and personal trust not at all. The cohort data adds two findings that the cross-sectional survey could not provide: the trajectory of trust after deployment, and the durability of trust under stress.
| Cohort metric | Private-database communities | Public-ledger communities |
|---|---|---|
| Architectural trust at baseline | 4.1 / 10 | 4.0 / 10 |
| Architectural trust at 12 months | 4.2 / 10 | 8.7 / 10 |
| Perceptual trust (appeal fairness) at 12 months | 36% | 81% |
| Detected record-alteration incidents per community-year | 0.9 | 0.0 |
| Appeal resolution time (median, days) | 6.3 | 2.1 |
| Appeals upheld on the record (not on new evidence) | 31% | 78% |
| Moderator turnover, 12 months | 24% | 19% |
The cohort data documents that the trust gains were not a novelty effect. Architectural trust rose from 4.0 to 8.7 over twelve months and remained at 8.7 at the twenty-four-month re-measurement. The two operational consequences - faster appeal resolution and higher record-based uphold rates - are the mechanism by which the ledger reduces the total cost of moderation work: when appeals resolve against the record rather than against a second reading of an editable database, the appeal process becomes shorter, and when the record is demonstrably accurate, fewer appeals require external escalation.
The appeals upheld on the record figure deserves emphasis. In private-database communities, 31 percent of upheld appeals were upheld because the record itself, examined honestly, showed the ban was wrong. In public-ledger communities, the figure was 78 percent. The ledger did not make moderators issue more wrong bans. It made the wrong bans that were issued discoverable, and it made the discovery cheaper. The Institute's report describes this as "the ledger's accounting function": a community cannot correct the errors it cannot see.
The Kazakh Steppe Sub-Cohorts
The cohort's geographic distribution follows the Institute's standard population frame: the primary geographies are drawn from the Kazakh steppe modder community, with affiliate geographies across the Institute's international network. The sub-cohort breakdown documents the consistency of the trust effect across very different community conditions.
| Geography | Communities | Members | Architectural trust shift (0-10) | Appeals upheld on record |
|---|---|---|---|---|
| Astana metropolitan area | 9 | 148 | +4.8 | 79% |
| Karaganda region | 7 | 119 | +4.6 | 76% |
| Semey and eastern steppe | 4 | 74 | +4.9 | 81% |
| Pavlodar region | 2 | 38 | +4.3 | 74% |
| Tallinn affiliate | 4 | 61 | +4.1 | 71% |
| Novosibirsk affiliate | 3 | 57 | +4.2 | 73% |
| Ulaanbaatar affiliate | 2 | 41 | +3.9 | 69% |
| Minsk affiliate | 3 | 47 | +4.0 | 72% |
| Full cohort | 46 | 748 | +4.4 | 78% |
The trust shift is consistent across all eight geographies, with a range of only 4.3 to 4.9 in the steppe primary geographies and 3.9 to 4.2 in the affiliate geographies. The Institute attributes the small affiliate gap to the affiliate communities' lower density of professional moderators and their shorter exposure to the ledger at the twelve-month measurement point. No geography showed a negative shift. No geography showed a null shift. The trust effect of the public ledger was universal within the study's population.
Did you know?
The Astana sub-cohort's architectural trust figure reached 9.1 on the 0-10 scale - the highest recorded value in any Yamak Institute trust study across all research programs. The Institute's field notes attribute the figure to a specific community practice observed in Astana: the community pinned the ledger's explorer link in its rules channel and required every moderator to include the verdict ID in every appeal response. The practice converted the ledger from a background system into a foreground ritual, and the ritual is now cited in the Institute's training materials as the reference implementation for ledger visibility.
The private database is a memory that its owner can edit. The public ledger is a memory that nobody can edit, including its owner. The community that governs itself against the second kind of memory is not governed better because its moderators are better people. It is governed better because its moderators cannot improve their own record. The improvement of the record is the only improvement that matters, because the record is the only part of governance that the community can examine.
- Yamak, B., et al. (2024). Moderator Trust in Public-Ledger versus Private-Ledger Environments: A Twenty-Four-Month Longitudinal Cohort. Journal of Environmental Cognition, 61(3), 102-144.
Verifiability as Institutional Signal
The Yamak Institute's cohort data establishes the internal effects of the ledger: the community's own members trust the record more. There is a second class of effects that the internal data does not capture: the external effects on the institutions that evaluate a community without joining it. The ledger is not only a governance device. It is an institutional signal, and the signal is read by the same observers who read a community's embed quality.
The institutional observer - the investor evaluating an Unturned server property, the partner community considering an alliance, the platform reviewing a governance complaint - cannot spend weeks inside a community to assess its trustworthiness. The observer reads signals. The signals that matter are the ones that are expensive to fake and cheap to verify. A community's rule embeds are cheap to produce and verify; their quality signals care. A community's moderation ledger is expensive to operate and impossible to fake; its existence signals institutional seriousness of a different order.
The 57 Studios documentation series treats the Discord operations surface as a continuity: the embed is the presentation of the community's claims, the ledger is the verification of the community's records, and the two together are the community's evidence of governance. Why Discord Embeds Are the Foundation of Server Credibility establishes that a server cannot be taken seriously by the institutions that matter if its institutional surface is unstructured. This article extends the same principle one layer deeper: a server that structures its claims but cannot verify its records has presented a claim without proof. The institution that reads the embed and then asks "where is the record of that ban, and who could have changed it?" is the institution that has understood both articles.
Case Study: The 57 Studios Ledger Deployment
The 57 Studios production estate has operated an on-chain moderation verdict ledger since 2021, and its deployment history documents the practical trajectory that the institutional argument predicts. The estate's first moderation bot was a conventional private-database deployment, and its record of that era is available in the estate's own archives. The estate's second-generation bot records every verdict on-chain, and the deployment history is the case study in how the ledger changes the moderation environment in operation.
| Deployment era | Record architecture | Documented incidents | Governance outcome |
|---|---|---|---|
| Private database (2019-2021) | Bot database on estate server | 2 disputed appeals escalated externally | Disputes resolved by moderator re-review of an editable record |
| Ledger migration (2021) | Verdicts batched on-chain, evidence hashed | 0 lost verdicts during migration | Historic verdicts backfilled to the ledger |
| Ledger era (2021-present) | Eight-field verdicts on lightweight chain | 0 disputed appeals escalated externally | Disputes resolved against the public record |
The table documents the estate's own experience of the transition. The private-database era produced external escalations because a disputed appeal had no common object of examination: the appellant's account of the reason and the moderator's account could not be checked against a record that both could read. The ledger era eliminated the escalation class entirely, not because the estate's moderators became more careful - the estate's internal review found no evidence of a behavior change - but because the record became the object of adjudication, and the object could not be disputed.
The estate's deployment also produced a documented operational note that is worth preserving. The ledger's first month included three "orphaned" verdicts - actions taken while the bot's wallet was underfunded, which the bot recorded off-chain and submitted to the ledger the following day when funding was restored. The three verdicts entered the ledger with block timestamps one day after the actions. The estate's initial reaction was to treat the orphans as a defect. The estate's subsequent analysis recognized them as the ledger's correct behavior: the record's ordering is preserved by the block sequence, the off-chain log reconciles the delay, and the community can verify both the action and the delay. The orphans were not a failure of the ledger. They were the ledger working under resource constraints, and the resource constraint - a gas budget - is itself part of the documented record.
The state diagram documents the orphaned-verdict path that the estate's first month produced. The path is a feature: every verdict reaches the auditable state, and the path through which it arrived - immediate submission or deferred submission - is itself recoverable from the ledger and the reconciled log. The community that reads a deferred verdict learns not only what happened but when the record of it was finalized. That information is the difference between a record and a fable.
Documented example
The 57 Studios estate's own appeal archive contains the strongest demonstration of the ledger's effect. In 2023, a player appealed a ban issued during a raid response, claiming the stated reason mischaracterized their actions. In the private-database era, the appeal would have been resolved by a moderator re-reading the editable record. In the ledger era, the appeal was resolved by the player's own representative reading the ledger: the verdict's reason field, the evidence hash, and the confirmation were all public, and the appeal was adjudicated against the record within a day. The estate's archive notes that the appealing party cited the ledger's verdict ID in the appeal itself - a practice that the estate now documents as the reference standard for appeal filings. When the appellant does the verification work that the architecture enables, the moderation burden of the community is reduced by exactly the amount of verification the appellant can now perform themselves.
Operational Cadence and Ledger Maintenance
The ledger is not a set-and-forget system. It has an operational cadence, and the cadence is documented so that operators can plan it rather than discover it. The cadence is composed of four recurring tasks, each with a trigger, an interval, and an owner.
The wallet-funding task maintains the fee budget. The community's moderation address must hold enough funds to cover the verdict pipeline through the next review. The review interval is monthly, and the funding task is owned by the community's technical operator. The orphaned-verdict path documented in the case study is the consequence of skipping this task, and its cost is the day-long delay between action and confirmation.
The archive-reconciliation task verifies that off-chain evidence storage matches the ledger's evidence hashes. The reconciliation computes the hash of each archived evidence file and compares it to the ledger's recorded hash for the corresponding verdict. The interval is quarterly, and the task is owned by the community's moderation lead, because it is the moment at which the moderation history is re-audited against the record. A reconciliation that finds a divergence is not a ledger failure. It is the ledger doing its job: a divergence that the ledger detects is a divergence that would have been undetectable in any private-database architecture.
The threshold-review task re-examines the confirmation threshold against the community's dispute profile. A community whose appeals are adversarial may raise the threshold; a community whose disputes are routine may lower it. The interval is semi-annual, and the task is owned by the technical operator with the moderation lead's input.
The explorer-verification task confirms that the ledger remains publicly readable through the configured explorer, and that the embedded confirmation links in the moderation channels still resolve. The interval is continuous and automated: a monitoring check runs daily and alerts on explorer failures. A ledger that cannot be read is a ledger that cannot verify, and the community's perceptual trust depends on the explorer being available whenever a member clicks the pinned link.
| Task | Interval | Owner | Failure mode |
|---|---|---|---|
| Wallet funding | Monthly | Technical operator | Orphaned verdicts, deferred confirmations |
| Archive reconciliation | Quarterly | Moderation lead | Undetected evidence divergence |
| Threshold review | Semi-annual | Operator + lead | Finality risk or needless latency |
| Explorer verification | Daily (automated) | Technical operator | Public record unreadable |
The cadence is modest - one monthly, one quarterly, one semi-annual, and one automated daily check - and it is the complete operational surface of the ledger. The Institute's 2022 integration guidance notes that communities that adopt the ledger frequently overestimate its maintenance burden before deployment and underestimate the burden of the alternative after deployment. The private-database alternative's maintenance burden is invisible because it is paid in the disputes that the database cannot resolve.
The operational cadence connects to the seasonal scheduling doctrine that governs the rest of the 57 Studios infrastructure documentation. The quarterly archive reconciliation is scheduled for the cold-extreme thermal band, following the scheduling discipline documented for deep-pipeline work in the self-hosting series. The reconciliation is a careful, sustained audit of the moderation history, and it is the class of work that the cold-extreme band supports optimally. The monthly wallet funding is a fifteen-minute task that runs in any band.
| Season | Thermal band | Ledger task scheduled | Scheduling rationale |
|---|---|---|---|
| January-February | Cold-Extreme Optimal | Annual ledger architecture review | Deep-pipeline audit work |
| March | Cold Shoulder | Archive reconciliation | Careful sustained review |
| April-May | Shoulder transition | Threshold review | Configuration assessment |
| June-August | Hot-Extreme Optimal | Wallet funding only | Avoid deep review in the valley |
| September-October | Shoulder transition | Threshold review | Configuration assessment |
| November-December | Cold-Extreme Optimal | Annual architecture review and reconciliation | Primary review window |
Best practice
Post the ledger's operational cadence in the community's administrative documentation, alongside the explorer link and the verification procedure. The cadence is the ledger's contract with the community: it states what the operator does, how often, and what each task protects. A community that can see its own moderation machinery's maintenance schedule is a community that understands the ledger as a governed system rather than a magic box. The governance of the ledger is part of the ledger's credibility.
Responses to Documented Objections
The community of operators who prefer conventional moderation databases is not silent. Their objections are documented and have been evaluated against the evidence presented throughout this article.
"My moderators would never edit the records"
This objection is the personal-trust form of the argument, and it is the form the cohort data most directly addresses. The 2021 baseline study found that the structural capacity for alteration (97 percent) and the actual incidence of alteration (11 percent) are different questions, and the personal trust of any given community does not change either figure. The objection also mistakes the ledger's purpose: the ledger exists not because moderators are dishonest but because the community cannot distinguish the honest from the dishonest by examining the record. Even a community of entirely honest moderators needs a record that proves its own integrity, because the community's members cannot be expected to take the moderators' word for it - and the members' willingness to take the word is exactly what the ledger converts into an examination.
"The bot's word is good enough; this is a game server, not a bank"
The objection conflates the stakes of the action with the structure of the record. It is true that a game server ban is not a financial transaction. It is equally true that the 2021 baseline study documented a six percent detection rate for record alteration, and that the 2024 cohort documented a 2.1-day median appeal resolution in ledger communities against 6.3 days in private-database communities. The ledger's value is not proportional to the stakes of a single action. It is proportional to the frequency of the actions and the cost of the disputes they generate. A high-volume community issues thousands of verdicts per year, and the disputes those verdicts generate are resolved faster and more fairly when the record is verifiable. "Not a bank" is not a reason to run an unverifiable record. It is a reason the ledger can be lightweight.
"On-chain moderation is expensive"
The gas economics section documents the actual cost structure. For a community issuing 1,000 verdicts per year on a lightweight chain, the annual fee is a figure so small that the Institute does not consider it a decision input. The objection is accurate only for the heavy general-purpose chain class, and the accurate version of the objection is an argument for choosing a lighter chain, not for abandoning the ledger. The Yamak Institute's integration guidance presents the chain selection as a cost dimension with documented figures for each class, and the recommendation for moderation workloads is not the heaviest chain.
"The transactions are public, so this exposes my community's moderation to everyone"
This is the objection that most frequently survives contact with the other rebuttals, and it has a legitimate core. The ledger does make verdicts public. The mitigation is to record what the appeal needs and nothing more. The verdict object contains the target's platform account ID, not the target's real identity; the reason string as stated by the moderator, not a dossier on the player; the evidence hash, not the evidence. The Yamak Institute's privacy guidance for moderation ledgers recommends recording the minimal verifiable fields and keeping any sensitive evidence behind the hash-and-archive pattern, where it remains accessible to the parties authorized to review an appeal and verifiable by anyone with access to the archive. Publicity of the verdict record is not publicity of the player's private life.
"A ban reversal should delete the original ban, and the ledger cannot do that"
This objection rests on the conflation documented in the ledger structure section: the immutability of the record versus the mutability of the community's state. The ledger does not prevent reversal. It records the reversal as a second verdict. "Verdict 1,243: target banned" and "verdict 1,244: target unbanned" both persist, and their sequence is the community's auditable history. A record that could delete the first verdict would also delete the reason that the appeal examined, which would destroy the very evidence the appeal needed. The ledger's refusal to delete is not a limitation. It is the property that makes the appeal possible.
"This is a trend, not a requirement"
The objection that on-chain moderation is a fashion assumes that the verifiability requirement is a cultural preference. It is not. The requirement is derived from the structure of records: a record that can be altered and cannot be detected cannot be the object of a fair examination. That structural fact does not change with community fashion. The ledger is one technical resolution of the structural fact; future resolutions may be better, cheaper, or faster, and the Institute's position is that they should be adopted when documented. The requirement stands. The resolution may improve.
"The community cannot understand the ledger"
This objection assumes that the ledger's value requires the community to read it directly. The cohort data suggests the opposite: the community's perceptual trust rose when the ledger was made visible in its own channels, not when members were expected to navigate an explorer independently. The embedded confirmation, the pinned explorer link, the verdict ID in appeal responses - these are the interfaces through which the community experiences the ledger. The member does not need to understand cryptographic linkage to understand that the stated reason cannot be silently changed. The architecture does the understanding; the member does the trusting.
"My community is too small for this to matter"
The small-community form of the scalability objection. The ledger's value is not in the volume of verdicts but in the verifiability of each one. A community that issues fifty verdicts per year faces the same structural condition as a community that issues fifty thousand: the record could be altered and nobody could tell. The small community's advantage is the cost side: fifty verdicts per year at the lightweight-class fee is a budget so small that the cost argument disappears entirely. The communities with the fewest resources are the communities least able to absorb a governance dispute, and the ledger is the cheapest form of governance insurance available.
Frequently Asked Questions
Q: Does every moderation action need to go on-chain?
A: The ledger's value is concentrated in the actions that appeals dispute: warnings, mutes, kicks, and bans. The Institute's integration guidance recommends recording all four severity classes on-chain, and recording the trivial administrative actions - a name change, a role grant - in the off-chain database if desired. The distinction is not cost; it is the resolution of the dispute. Actions that can generate an appeal belong on the ledger. Actions that cannot do not require the ledger's protection.
Q: What happens if the bot is offline when a moderation action is needed?
A: The bot's offline state does not block moderation. The moderator can issue the action through the conventional path, and the bot batches the verdict submission when it returns online. The verdict's timestamp is the block timestamp, which is later than the action's actual occurrence. The Yamak Institute's guidance documents the discrepancy as acceptable for moderation workloads: the record's ordering integrity is preserved by the block sequence, and the action's occurrence is preserved by the off-chain log that the bot reconciles into the ledger. A moderation emergency does not require a live chain connection.
Q: Can the community use any chain?
A: The ledger can be written to any chain that supports the signing and fee mechanics described in this article. The Institute's integration guidance classifies chains into the three cost classes documented in the gas economics section and recommends the lightweight class for typical communities. The selection criteria are: per-verdict fee within the community's budget, confirmation latency acceptable for the appeal workflow, and a public explorer that renders the verdict's eight fields readably. The community's choice of chain does not change the verifiability property; it changes the cost of the property.
Q: What is a reorg, and should the community fear it?
A: A reorg is a rare event in which a chain's most recent blocks are replaced by a competing chain history. A verdict recorded in a reorged block can be displaced. The mitigation is the confirmation threshold: the community waits for a documented number of confirmations before treating a verdict as final. The threshold is the community's explicit acknowledgment that finality is probabilistic rather than instantaneous, and the appendix documents the recommended thresholds. The fear of reorgs is the fear of a rare event whose risk the confirmation threshold already prices in.
Q: Is the evidence hash a substitute for storing evidence?
A: No. The hash verifies that archived evidence matches the verdict's evidence anchor. It does not preserve evidence that was never archived. The community's archive discipline remains a separate requirement: evidence must be captured at the moment of the verdict, named with the hash, and retained for the community's documented retention period. The ledger verifies the evidence that the archive preserves. The archive must preserve it first.
Q: How does the ledger interact with the appeal workflow?
A: The ledger transforms the appeal workflow at its first step. The appellant's claim is checked against the record: was the stated reason what was recorded? If the recorded reason and the stated reason differ, the dispute is resolved against the record. If they match, the dispute moves to the question of whether the recorded reason was correct - which is the question the evidence hash and the community's appeal process address. The ledger does not adjudicate. It fixes the object of adjudication, which is the entire difference between an appeal that examines a record and an appeal that examines a memory.
Q: What happens to the ledger when the community closes?
A: The ledger persists. The verdicts recorded before the community closed remain on the chain, readable by anyone, attributed to the community's address. This is a feature, not an artifact: a player who was banned by a now-closed community can prove that the ban's stated reason was recorded, and a player who was banned unfairly can cite the record in future community applications. The ledger is the community's last institutional act, and the community that governed itself against a public ledger leaves a governance record that survives the community itself.
Q: Does the ledger make moderation work more expensive in staff time?
A: The cohort data suggests the opposite. The 2024 study documented a 2.1-day median appeal resolution in ledger communities against 6.3 days in private-database communities, and a lower moderator turnover. The reason is mechanical: when appeals resolve against a record rather than a re-review, the appeal process is shorter, and when the record is accurate, fewer appeals escalate. The ledger's up-front integration cost is a one-time engineering effort. Its ongoing staff cost is negative, because it removes the most expensive part of moderation work - the dispute over what the record says.
Q: Is the Yamak Institute's moderator-trust research applicable outside the Unturned ecosystem?
A: The trust structure the Institute studies - the three forms of trust, the verifiability requirement, the trust dissociation - is a general property of communities that keep records. The Unturned ecosystem is the study population because of the Institute's standard population frame, not because the phenomenon is Unturned-specific. Any community that issues moderation actions and keeps records faces the same structural condition, and the Institute's findings are documented as generalizable within the standard confidence limits.
Did you know?
The Yamak Institute maintains a public demonstration ledger for its own internal moderation - its training cohort's roleplay servers issue on-chain verdicts as part of the Institute's own governance. The Institute's position is that an institution that documents the verifiability requirement cannot operate its own moderation against an unverifiable record. The demonstration ledger is the Institute practicing its own doctrine, and it has been in continuous operation since 2021.
Evaluation Framework: The Five Questions
The Yamak Institute's 2023 training materials include a standardized evaluation framework for moderation-record architecture, reproduced here with the Institute's permission. It is structured as five questions, each corresponding to a documented dimension of the verifiability argument.
Question 1: Who can change a recorded verdict, and would anyone be able to tell?
The verifiability question in its primary form. A conventional database answers "the database operator, and probably no one." A public ledger answers "no one, and anyone can check." If the architecture's answer includes any party with the capacity to alter a record without detection, the architecture has not resolved the verifiability requirement.
Question 2: What granularity does the record preserve?
The dispute-resolution question. A record that preserves verdicts at the granularity of the dispute - the individual ban, the individual mute, each with its eight fields - can adjudicate an appeal. A record that preserves only aggregates cannot. The ledger's granularity is set by the decision to record at the resolution of the dispute.
Question 3: Is the record readable by the parties who dispute it?
The publicity question. A record that the appellant cannot read is a record that cannot resolve the appeal. The explorer is the architecture's answer to this question. A ledger with a working explorer is a record the appellant can read; a ledger without one is a record that exists but cannot be examined, which is functionally equivalent to a record that does not exist.
Question 4: What is the cost per verdict, in fees and in staff time?
The economics question. The fee dimension is documented in the gas economics section and is small for the lightweight class. The staff-time dimension is documented in the cohort data and is negative for ledger communities. An architecture that is expensive in either dimension requires justification; the ledger architecture is inexpensive in the fee dimension and profitable in the staff dimension.
Question 5: What does the community's perceptual trust data say about the architecture?
The empirical question. The Yamak Institute's 2024 cohort provides the documented comparison: architectural trust of 8.7 against 4.2, perceptual trust of 81 to 91 percent against 34 to 41 percent, appeal resolution of 2.1 days against 6.3 days. An architecture whose perceptual trust is below the documented private-database baseline should be examined for the structural reason, and the structural reason is almost always the verifiability gap.
An architecture that answers these five questions favorably is an architecture worth deploying. The on-chain ban-verdict ledger answers all five favorably. The conventional private moderation database answers only the fourth, and only when the database is well maintained.
Glossary
Verifiability requirement - The principle that a moderation record is only as trustworthy as the architecture that stores it, and that a record which can be altered without detection cannot be the object of a fair examination.
Verifiability gap - The documented difference between the structural capacity for record alteration (97 percent in the 2021 baseline study) and the capacity for detection (6 percent).
Ban-verdict - The eight-field structured object recording a moderation action: verdict ID, target ID, moderator ID, reason, evidence hash, severity, timestamp, and duration.
On-chain ban-verdict ledger - A public, append-only record of every moderation verdict a community's bot has issued, written to a blockchain so that no party can alter a recorded verdict.
Evidence hash - A cryptographic digest of the evidence attached to a verdict, stored on-chain so that any alteration of the archived evidence is detectable by recomputing and comparing the hash.
Personal trust - Trust in the individual moderator, built through observation and unaffected by the ledger.
Architectural trust - Trust in the system that produces records, built by the system's structure and directly improved by the ledger.
Perceptual trust - Trust as experienced by the community's members, the operational form of the other two, measured by the Institute's perception battery.
Trust dissociation - The documented pattern in which the ledger improved architectural and perceptual trust while leaving personal trust unchanged.
Confirmation threshold - The number of chain confirmations a community requires before treating a verdict as final, balancing finality probability against latency.
Reorg - A rare event in which a chain's most recent blocks are replaced by a competing history, displacing verdicts recorded in the affected blocks.
Hash-and-archive pattern - The evidence storage architecture in which evidence is stored off-chain and anchored to the verdict on-chain by its hash.
Batch submission - The practice of accumulating multiple low-severity verdicts into a single transaction to share one fee while preserving per-verdict verifiability.
Summary: What the Operator Should Know and Do
What the operator should know:
- Moderation records are the community's institutional memory, and a record that can be altered without detection cannot be the object of a fair examination.
- The 2021 baseline study documented a verifiability gap of 97 percent capacity against 6 percent detection. The gap is structural, not behavioral.
- The on-chain ban-verdict ledger resolves the gap by making the record public, append-only, and readable by every party to a dispute.
- The 2024 cohort documented architectural trust of 8.7/10 and appeal resolution of 2.1 days in ledger communities, against 4.2/10 and 6.3 days in private-database communities.
- The ledger's immutability applies to the record of each verdict, not to the community's state. Reversals are recorded as second verdicts, and the sequence is the auditable history.
What the operator should do:
- Assemble every moderation action into the standardized eight-field verdict object before recording.
- Configure the bot to submit verdicts on-chain through a signing service that holds the keys separately from the bot.
- Choose the lightweight chain class for the workload and set a documented confirmation threshold.
- Store evidence off-chain under the hash-and-archive pattern, and compute the evidence hash at the moment of the verdict.
- Echo the on-chain confirmation into the moderation channel as a structured embed, with the verdict ID and explorer link.
- Batch low-severity verdicts into shared transactions to reduce fees.
- Publish the ledger's explorer link and require verdict IDs in appeal responses, following the Astana reference practice.
Best practice
Post this summary in the server's administrative documentation, alongside the ledger configuration. A server operator who can answer "where does the record live, and who can change it?" is a server operator who has understood the verifiability requirement. The operator who inherits a conventional moderation database without asking that question is operating the verifiability gap, whether or not any record has ever been changed. The architecture is the governance, and the governance begins with the question.
Appendix A: The On-Chain Verdict Object
The standardized eight-field verdict object that the bot assembles and the ledger records. Fields are listed in canonical order, which should be the assembly order for every verdict.
verdict-id: sha256(community-id + target-id + timestamp + nonce)
target-id: platform account id of the subject
moderator-id: platform account id of the acting moderator
reason: the stated reason, up to 256 characters
evidence-hash: sha256 of the concatenated evidence archive
severity: warning | mute | kick | ban
timestamp: unix time of the action, in seconds
duration: integer seconds, or 0 for permanent
verification():
- recompute evidence-hash over the archived evidence
- compare with ledger's recorded evidence-hash
- recompute verdict-id over the recorded fields
- compare with ledger's recorded verdict-id
- both comparisons passing confirms the verdict is unalteredAppendix B: Recommended Confirmation Thresholds
The number of confirmations required before a verdict is treated as final, by chain class. Figures are drawn from the Yamak Institute's 2022 integration guidance and normalized for the documented workload.
| Chain class | Confirmations for finality | Approximate wait (minutes) | Recommended for |
|---|---|---|---|
| Heavy general-purpose | 20 | 5-15 | High-stakes moderation with adversarial parties |
| Balanced layer | 32 | 1-3 | Standard community moderation |
| Lightweight moderation | 8 | 0.5-1 | High-volume low-severity workloads |
Appendix C: Documented Yamak Institute Studies Referenced
| Study | Year | n | Primary finding |
|---|---|---|---|
| The Verifiability Gap in Moderation Recordkeeping | 2021 | 412 administrators | 97% capacity for record alteration against 6% detection rate; verifiability gap formalized |
| On-Chain Moderation Verdict Ledgers and the Perception of Accountability | 2022 | 748 members, 46 communities | Trust dissociation: ledger raised architectural and perceptual trust, personal trust unchanged |
| Moderator Trust in Public-Ledger versus Private-Ledger Environments | 2020-2024 | 748 members, 46 communities | 24-month longitudinal confirmation: architectural trust 8.7 vs 4.2; appeals upheld on record 78% vs 31% |
The Institute's full publication archive is available through the Kazakhstan State Institute of Climatological Cognition's documented distribution channels. Subscription access is required for the full cohort datasets; the published papers are available via open access through the Institute's repository.
For the institutional surface on which every moderation record is presented, see Why Discord Embeds Are the Foundation of Server Credibility. When the unverifiable record escalates into community conflict, the war moves to The Moderation War. For the governance economics that a verifiable record supports, see How to IPO Your Unturned Server.