The road to cross chain governance

Hundred Finance is a Defi project with the ambition of building a novel cross chain lending protocol that will span over 100 blockchains

Protocol governance, is one of the building blocks to reach that vision. In the following article, we explain how Hundred Finance governance is being built and the challenges that still lie ahead

veToken governance model has become increasingly popular, since it was introduced by Curve Finance in the form of $veCRV. It is now considered a governance standard in the Defi space.

With the assurance of building on strong foundations, we decided to introduce $veHND by forking the Curve Dao contracts and adapting them to $HND

How does $veCRV work?

$veCRV is a non transferrable and decaying token, issued by locking $CRV for a time period ranging from 0 to 4 years.

After locking, the amount of $veCRV a user gets is linearly proportional to the lock period:

• 1 $veCRV for locking 1 $CRV for 4 years
• 0.5 $veCRV for locking 1 $CRV for 2 years
• and so on…

To achieve that, a well thought smart contract system enters into play, we can see all its components in the figure below

There are 3 main parts

1. Governance that issues $veCRV in the form of locked $CRV
2. Liquidity in the form of gauges that record user position of a given Lp token, and manage voting for gauge weights
3. Rewards that distributes $CRV to eligible users

Those component coordinate in the following way to achieve the protocol goals of maximising its usage:

1. Users receive rewards proportional to their share of liquidity provided to the gauges
2. Rewards distribution is decided by $veCRV voting, and most voted gauge will get the biggest share of $CRV. This is managed by the GaugeController contract
3. Users can boost their rewards (in a given gauge) by locking extra $CRV, the more liquidity a user provide the more $veCRV they need to maintain maximum boost

For further details check the official curve dao technical documentation

What is special about $veHND ?

All $HND tokens — 100M, are pre-minted. In contrast, $CRV is a scheduled issuance token with a pre-determined distribution curve.

With the great uncertainties that comes with multi-chain deployments, we wanted to have more control on the reward component, for better flexibility on deciding when and how much to distribute over time, with the long term goal of ultimately making this driven by $veHND holders voting

With that in mind, we introduced the following changes:

1. Split CRV contract logic into two

— A RewardPolicyMaker contract that determines the amount of $HND to distribute. With this we can simulate any curve by setting the amount of rewards per epoch

— A Treasury contract that holds the total $HND rewards, and can be called (only by the Minter) to distribute user rewards

2. Change the rewards checkpoint logic (in Gauge contract) to use RewardPolicyMaker instead of the fixed curve distribution schedule

It is very important for us to perform minimal changes to the original curve code, in order to limit the risk of introducing new bugs

The only significant logic change is on the GaugeController checkpointing logic, replacing pre-scheduled based checkpoint by a more abstract interface where an external contract RewardPolicyMaker will provide the rate() at which rewards are distributed for a given time period (a 1 week epoch)

From $veHND to $mveHND 🌉

The motivation behind $mveHND is to enable a user, with $veHND on a given blockchain, to use their boost and voting powers on another blockchain without the need to lock extra $HND

To achieve this we introduced a new contract MirroredVotingEscrow, which will be responsible of keeping track of locks for each (user, chain) tuple. It is implementing the same checkpointing mechanism as in VotingEscrow, to be able to simulate the decaying aspect of a $HND lock, generalising it to multiple locks per user.

We can see here a comparison of the storage structure used in both cases, to keep track of the locks:

# Voting Escrow lock storage
# user -> lock
locked: public(HashMap[address, LockedBalance])# Mirrored Voting Escrow mirrored lock storage
# user -> chain -> escrow_id -> lock
mirrored_locks: public(HashMap[address, HashMap[uint256, HashMap[uint256, LockedBalance]]])

you’ll notice that the contract supports multiple $veHND versions as it tracks a map of escrow ids in addition to the user and the chain. We will explain it’s use in next sections

And those are the action that can be invoked on it

# Only whitelisted addresses 
# can perform a mirror
def mirror_lock(
  _user: address, 
  _chain: uint256, 
  _escrow_id: uint256, 
  _value: uint256, 
  _unlock_time: uint256
)# Anyone can force an update 
# of total supply calculation
def checkpoint()# Admin actions
def set_mirror_whitelist(_addr: address, _is_whitelisted: bool)
def add_voting_escrow(_addr: address)

The mirror_lockaction only creates “virtual locks”, it can never lock actual $HND and merely acts as a mirror of real locks created by other VotingEscrow contracts

Since it is implementing the same read interface as the VotingEscrow, there is minimal impact on the architecture. We only had to adapt one validation check on the GaugeController

Thanks to the mirror whitelisting feature, we’ve been able to execute cross chain mirroring before having a bridging solution

We did that using a custom Merkle contract that records all users mirrors on all chains, and that can be triggered by users to safely perform the mirror

This modular design proved to be greatly useful when we started integrating new message bridging technologies, allowing us to take benefit of both Multichain and LayerZero message sending solutions

The mirror gates are whitelisted contracts, that take the responsibility of validating a user actually has a lock and call the mirror_lock with correct parameters. They also perform bridge related wiring logic to prepare for sending the mirror_lock call to the target chain

See their respective implementation here and here

But wait there is more 👀

After various feedbacks and requests, we introduced the following features helping unlock more utility for $mveHND

Hundred bonds

The idea is to be able to give $mveHND to a user instead of liquid $HND, limiting impact on the market, and increasing protocol usage

The original curve voting Escrow contract, does not allow a third party to create locks for other wallets. So we added a new call create_lock_for. This feature is protected by a whitelist

This adds more composability in using $mveHND by giving more options to partner projects

Gauge Tiers

Thanks to the new customisable rewards module, it is now possible to create multiple tiers of gauges and separately allocate rewards to each. One reason to have different tiers could be to group assets with different risk profiles into isolated systems

This is currently used for the Lendly product

Supporting multiple $veHND implementations

The MirroredVotingEscrow contract aggregates $veHND balances across multiple VotingEscrows, each in a different chain

A natural extension to that model, is to also make it aggregate multiple VotingEscrows but in the same chain 🤯

This enables us to deploy hundred bonds in the form of a new version of $veHND without any impact on existing user locks, as this is hidden by $mveHND

This will also enable new and exotic implementation of $veHND

For instance we believe it will be possible to mint $veHND using $HND-lp tokens, giving liquidity providers more governance rights as they deserve

Future Challenges

Operational complexity ⚙️

Current architecture requires setting rewards on a weekly basis (two transactions). Since this needs to be done on each chain, the process will eventually become overwhelmingly time consuming and error prone

We need to build tools or on-chain systems to streamline that process. This might require a great deal of innovation and ingenuity, which promises to be a exciting work subject 🤩

Cross chain lending 🦄

Now that we have reliable cross chain messaging tech, we started working on Hundred Finance’s next big innovation. Our goal is to enable a user with collateral on chain A, to borrow on chain B without moving their tokens. We believe that we can achieve that goal, and we think it will drive new and capital efficient avenues for our users

We are carefully finalising all the solution designs, with particular attention on exploit risks and the measures to mitigate them. Cross chain lending will be a powerful tool, and with greater powers come greater responsibilities

Hundred Finance DAO 🏛

Our ambition is to make the lending protocol fully controlled by $mveHND holders, which will be able to decide on every changes via on-chain voting

We are still a long way from achieving that goal. In fact, the future DAO module will have to support the following features:

1. Administer the Lending protocol day to day tasks and new features
2. Oversee $veHND infrastructure and decide of reward distributions
3. Be multi-chain, without feeling multi-chain. This will require a great deal of good UX design + seamless chain bridging technology

We hope this article made you curious and excited about what we are building for Hundred Finance 🙌. If you want to dig into more details, all $veHND code is completely open-source here, open to contributions or re-use for anyone

Made with ❤️ by Hundred Finance