This glossary defines and explains Webb ecosystem specific concepts and terminology.


Anchors are augmented Tornado Cash Tornados that possess graph-like data structures and functionality; that is, they can be connected and have edges. Users interact with Anchors through a deposit/withdraw API. To deposit into a Webb Anchor, a user generates a hashed commitment and submits this to the Anchor's merkle tree for insertion. The commitment contains the chainID of the chain they wish to withdraw on as well as some secret data.


Every SignatureBridge contract has a corresponding AnchorHandler to add or update the neighborRoots of the anchors on that chain after relayers pass and execute a proposals containing connected anchors' root updates. The Handler updates a specific anchor based on a mapping of a resourceID to a LinkableAnchor contract address which is set by the SignatureBridge admin.


The nodes that act as a collective to manage consensus on a blockchain network. In a proof-of-stake blockchain—for example, a blockchain that use the Staking pallet from FRAME—authorities are determined through a token-weighted nomination and voting system.

The terms authorities and validators sometimes seem to refer the same thing. However, validators is a broader term that can include other aspects of chain maintenance such as parachain validation. In general, authorities are a (non-strict) subset of validators and many validators are authorities.


commitment is generated upon a users deposit into an anchor and later used in a ZK proof for withdrawal. The commitment is the PoseidonHash(DestinationChainID + nullifier + secret). DestinationChainID is a user input indicating the chain they will withdraw on.

merkle tree

Merkle trees’ primary purpose is to prove the consistency of data, and is essentially a tree of hashes. Merkle tree is a tree in which every leaf node is labelled with the hash of a data block and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes.


Every LinkableAnchor stores its neighborRoots, a mapping containing the merkle roots of the anchors it is connected to. Each anchor stores a history of 30 roots, so users can verify against a historical root while new deposits occur.


A message that is voted on which suggests a change in the merkle roots or system. Proposals can be unsigned and unsigned. Below are all the proposal types in the system.

RefreshProposal to refresh a contract’s governor
AnchorCreateProposal to create a new anchor
AnchorUpdateProposal to update merkle roots
SetVerifierProposalProposal to set a verifier address
TokenAddProposal to add token to a set
TokenRemoveProposal to remove token from a set
WrappingFeeUpdateProposal to update fee parameter
RescueTokenProposal to move tokens from a Treasury
MaxDepositLimitUpdateProposal to update a maximum deposit limit parameter
MinWithdrawalLimitUpdateProposal to update a minimum withdrawal limit parameter
FeeRecipientUpdateProposalProposal to update a fee recipient account
SetTreasuryHandlerProposalProposal to set a treasury handler address
ResourceIdUpdateProposal to add/update a resource ID
ProposalSetUpdateProposal to update the latest proposer set state


resourceID's provide a chain agnostic identifier to connect tokens with the handlers and anchors that interact with that token. A resourceID for a given token and denomination is defined as the hash of that token name concatenated with its denomination. The resourceID for a token used in public bridging that is not tied to a denomination will simply be the hash of its token name.

signature bridge

The SignatureBridge contract allows for both fixed denomination, private bridging and standard, public bridging of assets. The private bridging functionality uses an AnchorHandler to track the state of connected chains while the standard bridging uses an ERC20Handler. The Bridge's state is is maintained by a set of relayers through voting. These relayers vote to update the latest merkle roots of connected anchors in the case of private bridging, and to distribute bridged assets in the case of public bridging.


The unspent transaction output (UTXO) model for ledger-keeping, which is most notably used by the Bitcoin blockchain, is logically more similar to a cash-based system than Ethereum's account model. In a cash-based system, a finite set of discrete units (cash) represents value. In a UTXO  system, entities may only spend the discrete units of value of which they have ownership. This means that each transaction consists of some set of "inputs" (the collection of cash that is used to pay for the transaction) and some set of "outputs" (the change that is leftover).

Last edit: on

Run into problems?
Let us Know
© 2022 Webb Technologies All Rights Reserved