Stacking Pool Registry

Smart Contracts
#1

As part of the Stacks grant, I have developed a pool registry smart contract (It comes with some unit tests):

The registry collects the following data:

  (name (tuple (namespace (buff 20)) (name (buff 48)))) ; a bns name
  (delegatee principal) ; the pool's address to be used by stackers
  (pox-address (tuple (hashbytes (buff 20)) (version (buff 1)))) ; the btc address used by the pool admin
  (url (string-ascii 250)) ; the pool's web site
  (contract (optional principal)) ; a contract managing the stacking, e.g. SP000000000000000000002Q6VF78.pox
  (extended-contract (optional principal)) ; a contract managing the stacking e.g. SPXVRSEH2BKSXAEJ00F1BY562P45D5ERPSKR4Q33.xverse-pool-v1
  (minimum-ustx (optional uint)) ; the required amount of STX to join the pool
  (locking-period (optional uint)) ; the number of stacking cycles
  (payout (string-ascii 5)) ; the currency of payout, e.g. BTC or STX
  (status uint))) ; the status: 0 (development), 1 (production), 2 (retired)

The registry entry is secured through a BNS name, that means only the owner of the name can register or update the data of the pool.

Two questions:

  1. Is the registered data sufficient? Missing any? Too much? Too many optionals?
  2. Is securing by BNS name good? Or currently too much of a burden due to missing support by the Stacks Wallet?
#2

There is a basic UI to register a pool at https://speed-spend.org/pools However, it is currently not functional because testnet is not progressing.

Screenshot from 2021-03-29 12-30-01

#3

Hi Friedger, Daniel from PlanBetter Pool here. What do you think about adding payout interval data?
For example some pools will payout EOM, some End of Cycle, etc.

Or maybe it’s too verbose?

Also, what about adding information on fees? Such as a % or none

1 Like
#4

Please keep it coming…

@hank In the userX demo you mentioned that using a BNS name for the pool registry is not a good option because of an extra request. The idea is to secure the pool meta data by the username. Only the owner of the name can update the data. If changing the delegatee address is an issue we could keep this write-once only.

#5

Can the locking-period be a list of uint? Since the same pool can have several different locking periods.

Maybe also the pool’s pox reward address, mapped by the starting cycle and duration?

The status can also indicate if the pool is currently open for registration in addition to being in development/production.

#6

For the multiple locking-periods and pox addresses, I thought to have one entry for each.

Not sure about the status for registration. Will pool operators update their entry? I’d doubt it.

#7

Will the pools in the registry be indexed by BNS name or contract name? Do you need multiple BNS names for a pool then?

#8

I have updated the contract as follows:

  • a pool is identified by the delegatee address
  • it is enough to use just one bns name as a pool operator and then create several entries for each pool
  • locking periods are a list of uints
  • pox addresses are a list
  • added a field for date of payment and fees

Contract is deployed on testnet: Contract Deploy - Stacks 2.0 explorer [testnet mode]
Source code with tests: RunRiot / Clarity Pool Registry · GitLab