Ethersocial 2019 Report Explained

Figures come from the public BSVG token audit and an ETHGlobal showcase entry.

The Ethersocial 2019 report is best read as a list of claims, each checked against a record that can be inspected. Contract claims need the contract and its audit, while dated activities need dated evidence.

Background on the project itself sits on the ethersocial coin page. This article covers only how to read a single year’s report and test it against public records.

Reading the report claim by claim

A year-in-review document usually mixes several kinds of statement: things that happened on a date, changes to a smart contract, and figures about network activity. Each kind has a different best check, and treating them alike is the most common way to misread a report.

The practical rule is to sort every item before checking it. A dated activity needs a dated record. A contract statement needs the contract address and its code or audit. A network figure needs an explorer query with a stated period.

Why the order of checks matters

Start with contract claims, because they are the most precise and the easiest to confirm. Move to network figures next, since they depend on the period and the contract involved. Leave narrative activities for last, because they rely most on dated external records.

Contract claims and what an audit changes

The BSVG token audit in the Ethereum Commonwealth auditing repository is a useful worked case of how a contract statement should be tested. The contract is an ERC20 token written in Solidity on Ethereum, and the audit summary lists its supply, decimals and standard. It is not presented here as part of the Ethersocial report; it shows the kind of record a report claim about a contract should be matched to.

Supply and decimals

The audit summary gives a total supply of 21,000,000 with 18 decimals. The consequence is practical: explorers and wallets often display raw integer values, so a report that quotes a supply in whole tokens only matches the chain after the raw value is scaled by the stated decimals. A figure that fails to match at first may simply be in different units.

Zero-value transfers

The audit flagged that transfer and transferFrom reject a value of 0, and it grouped this among the ERC20 compliance issues for which fixes were recommended. For anyone building on a token like this, the implication is that an integration which sends a zero-value transfer, for example as a test or a status ping, will be rejected by the contract.

A crowdsale with no limits

The audit also records that no deadline is implemented for the crowdsale, and that it has no hardcap or softcap. That has a direct reading consequence. A report statement about when a sale ended or how much it raised cannot be confirmed from contract rules, so it must be rebuilt from the recorded transactions.

Severity and audit length

Six issues were reported: 1 medium, 4 low and 1 minor observation. The auditing time was 1 day. Choices that follow from that:

• Read the severity split. A single medium finding with the rest low is a different message from a report that simply says a contract was audited.
• Treat the audit as a snapshot. A review of 1 day covers the contract version examined, so a later redeployment needs its own check.
• Look for the fixes. The audit recommends fixing the ERC20 compliance issues; a report claiming the contract is sound should point to a revised version.

Wallet addresses and the chain behind them

Every on-chain check depends on addresses. In the ETHGlobal showcase design, arbitrators are identified only by their wallet address, so they may operate on any EVM chain. The same logic applies when a report names a participant or treasury: the address is the verifiable identity, and a name in a document is only a label.

The chain matters as much as the address. The same showcase states that Polygon stores its example contracts, which shows that a project’s contracts do not necessarily sit on Ethereum. Before querying a block explorer, confirm which chain a report item refers to, or the lookup will return nothing and wrongly suggest the claim is false. The showcase also states that OpenZeppelin contracts are the basis for its ERC20 and ERC721 architecture, a reminder to ask whether a contract builds on a known library when judging a report’s description of it.

Meetups and foundation activities

Items about gatherings and organisational work are the hardest to check on-chain, because a meeting leaves no transaction. The sensible approach is to look for an independent dated record, such as a published agenda or an archived page, and to treat the report’s own wording as the claim rather than the proof.

Where an activity involved governance or funding, the reader is better served by the ethersocial network foundation page, which covers the organisation behind such items. Use it to understand who would have done the work, then look for records that confirm what was done and when.

Dating the year’s activities

A report is only as checkable as its dates. Build a simple timeline from the report’s items and give each one a date source: a transaction timestamp for contract events, an archived page for announcements, and a dated listing for meetups. Items with no date source stay as unconfirmed claims.

When to wait before relying on a date

If a date appears only in the report and nowhere else, hold it as provisional. A later archive snapshot or explorer record can confirm it. Do not fill the gap with an assumed date.

Network activity and mining claims

Statements about activity levels, block production or participation need a stated period and a named data source. A monthly claim should be tied to a dated explorer view, and the same period should be used when repeating the check later.

Mining-related statements add a second layer, because they depend on how the network is secured and how participants join. For the mechanics behind those claims, the guide on how to mine ethersocial explains the process so a report line can be read in context.

Frequently asked questions