Protocol
Contracts
Every Prop House round interacts with two chains:
Starknet, which handles core round logic like proposing, voting, and winner determination.
An origin chain, where houses are deployed, assets are held, and execution (payouts) occur.
This approach utilizes the cheaper execution cost of Starknet to make proposing, voting, and winner calculations more affordable.
Currently, Ethereum is the only supported origin chain.
Ethereum Contracts
The PropHouse contract serves as the primary entry point for house and round creation, while also handling all round deposits.
Supported asset types include: ETH, ERC20s, ERC721s, ERC1155s.
The Manager contract controls which house and round implementation contracts can be deployed using the PropHouse contract. This contract will be owned by the Prop House team multisig. This contract has no control over existing rounds.
The Messenger acts as an L1<>L2 message pass-through contract between rounds and the Starknet Core contract. It uses the PropHouse contract to authenticate rounds and inserts the msg.sender in the first index of the payload that's passed to Starknet to ensure that the manager can't register a malicious round implementation that acts as another round.
Covered in the overview.
The CreatorPassRegistry is an ERC1155 token, which is used by the CommunityHouse to determine who is authorized to create rounds on the house. The CommunityHouse achieves this by issuing or revoking passes (mint, burn). The ID of the token is the calling house ID.
You can see the pass authorization in the CommunityHouse here.
Infinite Round
Infinite rounds are not yet live on mainnet 🕐
Mostly covered in the overview.
This contract handles continual asset deposits and payouts (claims) to winners, and enables the round manager, holder of the round NFT, to cancel or finalize the round.
In this round type, no awards are specified during round creation. Instead, proposers can request any assets that the round holds.
Winners are reported to this contract from Starknet in batches of one or more. The payload from Starknet includes the new winner count and the latest merkle root. If the new winner count is greater than the previous winner count, anyone can consume the new root and open up claiming for the latest batch of winners. For now, the incremental merkle tree is capped at 2^10 leaves.
Mostly covered in the overview.
This contract handles asset deposits and payouts (claims) to winners, enables the round manager, holder of the round NFT, to cancel the round, and allows anyone to finalize the round.
Unlike infinite rounds, this contract receives a list of all winners during finalization and allows 4 weeks for claiming before depositors can reclaim unclaimed assets.
In addition, this contract supports rounds that offer no assets. When no assets are offered, the utility of this contract is the isWinner function, which can be used by 3rd party contracts to enable new use-cases. For example, a contract that allows the winner of the timed round to receive a streamed payment.
Starknet Contracts
The EthereumRoundFactory is the entrypoint for all rounds created on Ethereum. It deploys an accompanying Starknet round and creates a mapping to the Ethereum round address that was passed via msg.sender from Messenger.
In addition, it can route messages from an Ethereum round contract to a Starknet round contract.
Infinite Round
InfiniteRound handles proposing, voting, and winner determination for the infinite rounds. If a FOR or AGAINST quorum is reached, the state change will occur inside the vote transaction. A rejection will move the proposal state to REJECTED, while an approval will change the state to APPROVED and append the winner's claim leaf to the merkle tree.
process_winners can be called to relay new winners to the origin chain. finalize_round, which is called from the origin chain contract, will process any remaining winners before finalizing the round.
TimedRound handles proposing, voting, and winner determination for the timed rounds. It accepts proposals during the proposal submission period, accepts votes during the voting period, and allows finalization, which determines winners, following the voting period.
Auth Strategies
Both infinite and timed rounds have authentication strategies. These strategies are pass-through contracts, which are the actual callers of all propose and vote functions on Starknet. They enable meta-transactions in two different ways.
The transaction auth strategy accepts a commit hash from Ethereum that contains the target round, selector, and calldata, and allows any Starknet account to consume the commit, relaying the function call.
The signature auth strategy allows any EOA to sign a message to propose or vote, which can be relayed by any Starknet account.
Auth strategies are chosen at the time of round creation.
Governance Power Strategies
These strategies can be consumed to determine proposing or voting power. There are currently four governance power strategies in use:
Allowlist: Enables a predefined list of accounts to have a specific governance power.
Ethereum Balance Of: Uses Herodotus v1 to determine governance power using ERC20/ERC721 balances on Ethereum.
Ethereum Balance Of ERC1155: Uses Herodotus v1 to determine governance power using ERC1155 balances on Ethereum.
Vanilla: For testing only. Gives all users a power of 1.
This contract maps timestamps to block numbers by reading from the Herodotus headers store. It is used in the Ethereum balance of governance power strategy
This contract stores immutable dependencies, like authentication or execution strategies, for rounds. It uses a combination of the origin chain ID and round type for the dependency key, which allows Starknet rounds to service many origin chains.
Rounds can only read dependencies from this contract if they have been permanently locked. This ensures that a malicious owner cannot add a backdoor to an existing strategy.
This contract registers governance strategies by inserting them in storage, keyed by their hash, and allowing anyone to query for them. Governance strategies will be reused many times, so we can save users on storage costs by only inserting a strategy into storage if it has never been seen before.
Last updated
