scufFed

From the Archive: Heroglyphs

4320 words | 21 minutes

Note: The following blogpost is part of a series of old writeups I did on various DePIN and DeFi projects across the latter half of 2024.

It’s likely that some of the content is out-of-date or no longer reflective of the current state of the project discussed. I’ll leave notes here and there for some updates, but I’m keeping those minimal. Regardless, I’ve decided to post these here anyways for posterity. The writing style may be a little inconsistent and unstructured, but hopefully the reads are still entertaining.

A Look into “Heroglyphs”

[Update 15/01/2026: These notes are definitely out of date, but it seems like the project hasn’t gained much traction since 2024 either.]

The Whitepaper

Can this Decentralize Nodes?

The incentive system does line up with what they say: it is closer to how PoW rewards on, say, BTC are being distributed. And in theory, if the rewards are sufficient/effective, then it would promote spinning up independent nodes to reap those benefits. However, in practice, we do see that in live PoW systems (lowest hanging fruit, BTC) that centralization of power still occurs. Assuming that validators from “centralized entities” can be singled out based on their withdrawal address, perhaps the system can be made to reward solo validators only, making it effective.

As to whether this would decentralize nodes, at a simple level, it depends on how effective of an incentive these Heroglyph Tokens can be.

Let’s use the contrapositive: how does this decentivize liquid staking?

If you were to stake your ETH via liquid staking, you can receive block rewards without 1) having to deal with the technical details of setting up a validator and 2) you can behave as a validator without requiring 32 ETH.

However, Heroglyph Tokens are only rewarded to individual validators, namely the address tied to the validator which proposes the block which contains the correct Graffiti that denotes the mining of a Heroglyph Token. Unless the validator splits the rewarded Heroglyph Tokens (or liquidates them, then shares the reward) across all individuals that share their ETH to stake, the user which contributes their ETH would lose out on this additional reward.

On paper, we can mitigate this. Entities like LIDO which take your capital and outsource node operators to spin up validators run thousands of individual validators themselves (that happen to be considered “centralized” as they are under a singular aforementioned entity). Each individual validator that the node operators run can participate in Heroglyph Token mining by including the appropriate Graffiti if they are recognised as a “Complete Validator”, sidestepping the measures taken to avoid centralization.

As such, we need to figure out just how a “Complete Validator” is identified and whether there is any system in place that can differentiate validators owned by centralized entities and solo validators.

Quoting the Whitepaper: “To prevent a small number of partial validators who delegate validation operations from becoming the beneficiaries of this system and further centralization, validators whose deposit/withdraw address is a contract address could be automatically excluded from mining.”

This makes sense as to uphold the trustless system of staking, the withdrawal credentials of the validators should be of type 0x01 and point to a smart contract that will ensure that rewards will eventually make its way back to those who contribute to staking (ref for LIDO’s case) If your major staking pools all operate on this principle (granted, even in the case of LIDO, they still have type 0x00 withdrawal credentials that point to a standard multisig wallet) and their validators predominantly behave this way, that aforementioned differentiation can be done and the project’s principles remain in place.

All in all, the outlook isn’t particularly grim. In order for there to be a consolidation/centralization of power and continue to reap the rewards from it, entities which employ centralized validators would have to undermine what makes their systems trustless, which should dissuade contributing to their staking pool and create greater incentives to behave as a solo validator to reap the rewards of Heroglyphs as an independent entity.

What is $BADGE?

Lifting from the Whitepaper: “Heroglyphs mining ensures that all Complete Validators receive rewards for their participation, regardless of whether they are selected as block proposers.”

Given that you can only manipulate the Graffiti to mine Heroglyph Tokens iff you are a block proposer, how do you receive rewards otherwise?

It appears that Heroglyphs also offers another token, one divorced from the free for all “Tickers”, called $BADGES, which can be claimed when you perform attestations as a validator (as long as you have a valid withdrawal_credential), after which these $BADGES can then be used to redeem Heroglyph Tokens/Tickers.

This system also relies on the filtering process (of differentiating solo validators from centralized validators) being effective.

This seems to be Work in Progress.

Who is a Complete Validator?

This means that as long as you’re running your own node, specifying the correct graffiti when validating blocks and holding a Genesis NFT, you should be able to receive tokens associated with the NFT (details a few sections down). So, AWS and cloud nodes are not out of the question.

Tickers

Tickers correspond to the Heroglyphs Tokens that we’ve been talking about.

Every ticker contains the following fields:

Concerning hijacking of tickers, there are three states:

Right now, the primary concern is with the hijacking system. If a token were to be hijacked and their contract is changed, what happens to the old token contract? It should still remain tradable as an OFT20 token, but no new tokens would be minted unless another ticker (or the same old ticker) were to be hijacked or created, with the “new” ticker pointing to this contract.

IDs (Updated as of 2024/05/13)

Quoting the FAQ, IDs behave as an ENS in the Heroglyphs ecosystem. When you “mine” a token, you need some way to identify who would receive the reward that isn’t just the contract address.

IDs have the following properties:

If you aren’t a validator, you can still mint an ID and then delegate it to someone who is a validator and presumably receive a cut of their rewards + the base profits of selling the ID to them.

Heroglyph IDs are non-transferable (cannot transfer ownership), but the receiver address can be changed.

There is now dynamic pricing at play for the ID: it will take 0.1 ETH to mint your first 25 IDs in a day, then the price increases every 10 new IDs by 50% of the initial cost, then every 24h this price decays until it goes back down to 0.1 ETH.

Assuming that your Herogylph ID minting cost is tied to an owner account address, what is stopping someone from making multiple wallets and minting IDs on those? Are the NFTs now the limiting factor? i.e. If you want to use multiple wallets to mint multiple IDs and dodge the minting cost, will you require every wallet to have an NFT associated with the tokens you wish to mine? Or is it just the receiver address? These details are still unclear.

The validator index UUID is “soulbound”, so if you close your validator and open a new one, the associated identity tied to that UUID will be forever vanished/rendered unusable.

The Graffiti Format

So now we come down to the Graffiti format itself. As previously stated, it is a 32 byte chunk of data that can be appended to the block header by a block proposer (byte, not just char, which means you’re free to use non-ASCII characters).

A sample Graffiti following the format looks like this:

#x,X,0,_,lasagna@[]-a

So for this example, the validator mined x, X, 0, _ and lasagna, where the mined tokens will be deposited to the account associated with @[]

Thus, we find that shorter IDs are preferable (you can include more tickers) and the length of the ticker can be interpreted as either longer being better (increased scarcity as there is lowered incentive to mine it) or short being better (increased mining volume as it can be tacked on more easily in a mining graffiti).

The NFTs

This is the part that’s a little bit vague and confusing.

Is Minting Live?

Right now, at least in the Discord FAQ, it says that Claims are not live yet. Inspecting some TXs, we see this is not actually the case:

Here is an address that owns a bunch of the Genesis NFTs (in particular, the lueygi, KABOSU, PORIGON, SCRIBES and GARFELDO keys).

They were the block proposer for block number 19843098 , which contained the graffiti #x,X,0,_,lasagna@[]-a . We can check the the ID @[] does correspond to the owner 0x0ce2765B3adcF1bc7D5A12Eb05e50eCCF2D896c2 on the Heroglyphs site.

We can see that there are TXs in which this ID has been rewarded the associated tokens ($LASAGNA in this example), which means minting does appear to be live.

Smart Contracts

Currently, any information concerning the Heroglyphs ecosystem can only primarily be accessed via their site, https://heroglyphs.com. Of interest is how the tickers and identities are handled: what’s going on under the hood?

HeroglyphRelay.sol

Obviously, there has to be something in place that is looking out for the Graffitis themselves so that the minting can occur.

We see calls to 0x384f025f8B1993584857A305C3b2fE181087ae78, a contract called HeroglyphRelay.

We won’t dig into the code that much because the code itself is fairly simple and as the name implies, exists simply to relay information.

executeRelay

This function serves as the key bridge between off-chain and on-chain, and is only called if a produced block contains the relevant graffiti. There are two events that will be emitted on call, BlockExecuted and TickerExecuted, with the latter only being emitted after performing callTicker, which calls the contract associated with the ticker.

So who is calling executeRelay? Well, inspecting a tx gives us our answer: the Gelato network. As an automation protocol, it executes the contract as and when is needed. This also means it’s a point of failure for Heroglyphs right now.

Ticker.sol

This contract is responsible for the logic behind the tickers, including the ownership and hijacking stuff. As it states, “Tickers are contract identities [without real ownership]”

Some points of interest:

ValidatorIdentity.sol (Seemingly deprecated as of 2024/05/13)

This contract is responsible for the IDs and the delegation system. The logic seems sound and there’s nothing really more to comment on; the metadata and information that you see on the page is very much what you get.

Update 2024/05/13: Right now, when you call for the IDs on the Heroglyphs website, it appears to be making a GraphQL request to an Alchemy Subgraphs (Satsuma) API endpoint, requesting for the HeroglyphIDs directly instead of querying a smart contract.

HeroglyphAttestation.sol

This contract is interesting as it concerns the rewards for attestation rather than the inscription of a graffiti. Here we can also find the associated $BADGES token, which is an OFT token (clarifying, it is an extended ERC-20 token, whose spec is described here )

Functions which will perform the rewarding e.g. SendBatchToExecute are called with the block’s validator indexes (not to be confused with the validator ID that concerns the Heroglyph spec, we’re talking about regular ETH block validator IDs) specified in the function call .

HeroLinearToken20.sol

Our Genesis Tokens (which are tokens which should be following the intended spec as they have been created by the owners) all point to the HeroLinearToken20.sol contract, which appears to be a modified version of the aforementioned LayerZero OFT spec.

In here, our functions concerning minting and redemption are specified. I’m not really here to do a full smart contract audit and just giving it a cursory look, the contract logic appears sound. After all, it’s just a token spec.

Conclusion

Solid idea that has potential, although there are a few kinks concerning the ticker hijacking, how to differentiate solo validators from centralized validators (which currently is only being done by inspecting the validators’ withdrawal_credential) and the general eventual centralization of PoW reward oriented systems. Nonetheless, it definitely has promise and it’d be interesting to see how the Heroglyph Tokens utilities are extended in the future.

In conclusion, Heroglyphs is an interesting project which tries to create an incentive to spin up solo validators by rewarding those solo validators with tokens, be it by “mining” tokens via Graffiti or by receiving $BADGES tokens as an attestation reward, which can subsequently be used to redeem Heroglyph Tokens.

The logic behind the NFTs, the potential for cross-chain activity and further utility that these tokens can have are all things that are yet to be built up, but the building blocks are there. Any of the logic concerning the IDs, the tickers, the Graffiti monitoring has been implemented with a set of smart contracts that are already live and running.

Will this decentralize nodes? On paper, it is conceptually sound as it ports over the concept of PoW rewards over to a now PoS network while taking measures to “protect” and further reward solo validators. It definitely does not lower the barrier to entry to being a solo validator and the ability to differentiate outsourced centralized validators from solo validators hinges on one field (the withdrawal_credential), although improvements could be made to this in the future. But as it stands, the idea, although idealistic, is logically sound, clearly feasible, with the main hurdle being adoption.

We know that PoW networks have a tendency to centralize over time, so the longevity of this project and whether it can continue to effectively reward solo validation may be put into question, but that’s very much a “later problem”.

As for the comparison between this system and ordinals/inscriptions, a positive point is that although this is “off-chain”, the Tickers, Identifiers and actual Token contracts themselves still exist as Smart Contracts. This is in opposition to ordinals for BTC as BTC itself doesn’t have the primitives for smart contracts, and ordinals rely on external off-chain calculations in its entirety to attribute value. Whereas here, as pointed out in document 3, currently the only system that isn’t purely managed by smart contracts is the Graffiti monitoring system, which currently relies on Gelato. This means beyond the systems made up by the Heroglyphs dev team, since the rewarded/minted tokens follow the modified OFT20 standard, they appear to still be able to be traded as tokens on entirely on their own.

Other comments include the feature concerning ticker hijacking: it does make sense to have a system in place that helps to properly delegate the tickers given they are limited in quantity (you at most have 27 bytes to denote a ticker) and some tickers can be deemed more valuable than others (be it those of shorter or longer length, depending on what the widespread opinion is), but as of now there’s no real clarity as to what would happen to the associated token contract once it is decoupled from an expired ticker.

Overall, Heroglyphs sounds like a solid idea, one that doesn’t have a gross excess of unnecessary complexity, but definitely a project that requires more robust systems to achieve its purported goals. Although currently rough around the edges, the building blocks are all in place.

Phase 2 Updates

Sharing an ID Across Multiple Validators

According to the docs, you can now create a Parent-Child relationship between validators. This means that you can reuse an ID across multiple validators, as long as the validator is registered as a “child” of an ID.

Parents.png

Previously, if you wanted to use multiple validators you would have to mint a unique ID for each of them, and the graffiti that the validator mints has to match the ID

e.g. Validator with ID of @abc can only receive tokens if they append graffitis with @abc, if they were to put any other ID like @xyz in their graffiti, the graffiti is voided and the address associated with @xyz does not receive any tokens, nor does the address associated with @abc

This Parent-Child system does not mean that IDs can be reminted for multiple validators! Every validator still requires its own unique ID.

However, with the IdentityRouter.sol contract, it seems like you can “hook” an arbitrary number of children to a parent identity: here is an example tx of someone hooking their child @ra to a parent ID @C.

This means that the validator associated with @ra can now mint graffitis with @C and the owner of both validators can receive the rewards for it (deposited to the wallet associated with @C). I can now mint a very long ID for a validator, then simply hook it to a far shorter ID and retain my ability to mint multiple tokens per graffiti.

The intrinsic value of this is to be able to reuse short validator IDs across multiple validators, and this feels like a rework of the “delegation” system initially present in V1.

What Happens to Dead Tickers?

As previously discussed, a ticker owner has to continually pay taxes to keep the ticker “afloat”. It seems like if the taxes were to go unpaid and the ticker becomes hijackable, the ticker is considered “surrendered” and you simply stop being able to receive any of the associate tokens.

Doubling Up Tickers

However, given that the Heroglyphs tokens are associated with a contract, you can actually mint multiple tickers that points to the same contract, and even if one of those tickers goes underwater, you can continue receiving the tokens via the other tickers.

e.g. #ABC and #XYZ both point to some token $TOKEN. The owner of #ABC stops paying its tax and the ticker goes underwater, so graffitis minted with the ticker #ABC no longer receive any $TOKEN. However, you can simply switch to minting graffitis with the token #XYZ instead, and continue to receive $TOKEN.

This sort of behaviour can be disabled via the contract itself (the Heroglyphs team recognizes this as a possible Repeat Attack, e.g. having a graffiti minted with two tickers that point to the same contract and this somehow having an adverse effect). As you can only have one graffiti per block, you can check if the contract has been called on the latest block already, so a second execution via the same block will be reverted.

function onValidatorTriggered(uint32,uint256 _blockNumber,address,uint128) external override onlyAutomate
{
	if (_blockNumber <= latestMintedBlock) revert GhostBlock();
	latestMintedBlock = _blockNumber;
}

Requesting for Immunity

It seems like you can request for Ticker Immunity from the Heroglyphs team if “your product offers significant advantages to the ecosystem”. Otherwise, if your ticker goes underwater and you can’t buy it back, you would have to get all your validators to migrate to a new ticker.

This does open a security concern however: what if a ticker goes underwater and the hijacker makes it point to a malicious contract? What sort of malicious contracts can you even make it point to and have the user interact with?

Advanced Graffiti Minting

Given that the tokens exist on different chains, you can perform cross-chain minting.

For example, the $LEUYGI token exists on Base while the $69 token exists on Arbitrum (by default, if you do not specify a chain to mine on, it will use Arbitrum).

You can then craft a graffiti like this: #leuygi:h,69@ID, where the :h is an “override symbol” to specify that leuygi will be minted on the chain associated with h, which in this case is Base. We don’t have to write :a after 69 to mine it on Arbitrum thanks to the default system.

However, if you were to mint on a separate chain, you will need to pay a “layer-zero fee” on the target chain. … What the hell is a layer-zero fee?

Clarifying $BADGES, Genesis NFTs and Genesis Tokens

NFT Keys and OFT20

We now have more insight into what the NFTs and tokens are for. As previously speculated, it seems like in order to mine the genesis tokens (the tickers that are currently immune on the protocol), you will have to mint an associated genesis NFT (which is your “key”).

It seems like these genesis tokens are also primarily OFT20 tokens (Omnichain Fungible Tokens, like $OMNI, I think.) So you should be able to bridge the tokens across chains e.g. from Base to Arbitrum. Seems like your aforementioned layer-zero fees are the cost for bridging.

Bridging.png

Sidenote: OFT20 in Brief (ref)

So what is the OFT spec exactly?

Essentially, to facilitate interchain activity, when you transfer N tokens from chain A to chain B, it burns N tokens on chain A and mints N tokens on chain B (this is done via cross-chain messages). Simple, right?

Benefits:

With liquidity pools spread across multiple chains… arbitrage opportunities for Heroglyph tokens inbound? (Just like what happened to $OMNI fresh off its launch)

Medals and $BADGES

Furthermore, you will receive medals when you successfully attest blocks (the current rate on the heroglyphs site has 1 Medal = 0.000297 $BADGES). So around 3367 successful attestations will allow you to claim 1 $BADGES, which can then be used to redeem a genesis token (you still need the associated genesis NFT to do this redemption).

It seems like if you miss an attestation to a proposed block, you also get penalised and your claimable medal count is deducted.

Here is the contract for $BADGES, which also corroborates the point on the $BADGES being “soulbounded” (since your medals are tied to your validator’s attestations). Do note that you still need to register an ID for the validators to be able to make any medal claims.

The Parent-Child relationship from earlier does not seem to apply here, so if I have multiple validators I cannot funnel my medals to one address.