Skip to main content

Multisig Transaction Guide

Multisig Process

The Multisig Process was ratified by JBX holders in JBP - 98 Ratify Multisig Process. Multisig members should be aware of the following stipulations:

  1. The Juicebox multisig and Juicebox multisig owner accounts must agree to execute the will of JBX token holders, as expressed through the Juicebox Governance Process.
  2. Existing multisig members must agree to these principles, and prospective multisig members must agree to these principles before being added to the multisig.
  3. These principles are intended as general guidelines that formalize existing processes while being flexible enough to adapt as Juicebox changes over time.


  • Check the transaction queue to see pending transactions. Double check the transaction data and relevant proposals before signing.
  • Keep an eye on #multisig in the JuiceboxDAO Discord server to coordinate with other multisig members
  • The latest payouts and reserved JBX recipients can be found in #bookkeeping. Queue the reconfiguration and notify others in #multisig.
  • Request gas reimbursements in #bookkeeping.

Juicebox v1.0 Multisig Actions

For more information about v1 transactions, look at the Juicebox Docs.

Treasury and Tickets

TerminalV1.configureConfigure funding cycle properties including funding target, funding distribution, reserved tokens, etc.
TerminalV1.printPreminedTicketsPrint tickets to any address. Only works before payments have been received (no longer possible for JuiceboxDAO).
TerminalV1.migrateMigrate funds and operations to a new contract.
TicketBooth.issueIssues an owner's ERC-20 Tickets that'll be used when unstaking tickets and deploys an owner's Ticket ERC-20 token contract.
TerminalV1_1.printTicketsPrint tickets to any address (Only available on V1.1 projects—Allow minting tokens must be enabled).

Project Details

Projects.setHandleSet the project's handle.
Projects.setUriSet the project's URI (IPFS CDN with project info).
Projects.transferHandleTransfer handle to another address.
Projects.claimHandleClaim and apply a transferred handle.
Projects.renewHandleRenew a handle to prevent claiming for a year after it is challenged.

Project Control

OperatorStore.setOperatorGive an address permission to take actions (full operation list) pertaining to a specified domain
Projects.transferTransfer the ERC-721 that confers ownership in a Juicebox project to a new address.


All Gnosis actions are available on their app, use them for better UX.

OwnerManager.addOwnerWithThresholdAdd a new owner to the Safe and update the threshold at the same time (check txn here)
OwnerManager.removeOwnerRemove an owner from the Safe and update the threshold at the same time (check txn here)
OwnerManager.changeThresholdUpdate the number of owner accounts needed to confirm a Gnosis Safe transaction.

Add Juicebox Safe

  1. Go to

  1. Click “Add existing Safe”, input address “0xAF28bcB48C40dBC86f52D459A6562F658fc94B1e”

  1. Label the owners if you’d like

  1. Finish the procedure, and next time you could find JuiceboxDAO on your Gnosis App.

How to write a “configure” transaction:

First, add the Juicebox app to Gnosis Safe:

  • navigate to Gnosis Apps
  • Add custom app ->
  • check "This app is not a Gnosis product and I agree to use this app at my own risk."
  • click “Add”

You can access the Juicebox website with multisig wallet connected. Navigate to the JuiceboxDAO project and find the “Reconfigure upcoming” button:

Click on it to reconfigure. You will be able to see the preview before submit transaction. If you submit the txn, call other members to sign it on Gnosis App.

How to read a “configure” transaction:

Here are the interface definitions:

Configures the properties of the current funding cycle if the project hasn't distributed tickets yet, or
sets the properties of the proposed funding cycle that will take effect once the current one expires
if it is approved by the current funding cycle's ballot.
Only a project's owner or a designated operator can configure its funding cycles.
@param _projectId The ID of the project being reconfigured.
@param _properties The funding cycle configuration.
@dev The amount that the project wants to receive in this funding stage. Sent as a wad.
@dev _properties.currency The currency of the `target`. Send 0 for ETH or 1 for USD.
@dev _properties.duration The duration of the funding stage for which the `target` amount is needed. Measured in days. Send 0 for a boundless cycle reconfigurable at any time.
@dev _properties.cycleLimit The number of cycles that this configuration should last for before going back to the last permanent. This has no effect for a project's first funding cycle.
@dev _properties.discountRate A number from 0-200 indicating how valuable a contribution to this funding stage is compared to the project's previous funding stage.
If it's 200, each funding stage will have equal weight.
If the number is 180, a contribution to the next funding stage will only give you 90% of tickets given to a contribution of the same amount during the current funding stage.
If the number is 0, an non-recurring funding stage will get made.
@dev _properties.ballot The new ballot that will be used to approve subsequent reconfigurations.
@param _metadata A struct specifying the TerminalV1 specific params _bondingCurveRate, and _reservedRate.
@dev _metadata.reservedRate A number from 0-200 indicating the percentage of each contribution's tickets that will be reserved for the project owner.
@dev _metadata.bondingCurveRate The rate from 0-200 at which a project's Tickets can be redeemed for surplus.
The bonding curve formula is
where x is _count, o is _currentOverflow, s is _totalSupply, and r is _bondingCurveRate.
@dev _metadata.reconfigurationBondingCurveRate The bonding curve rate to apply when there is an active ballot.
@return The ID of the funding cycle that was successfully configured.
function configure(
uint256 _projectId,
FundingCycleProperties calldata _properties,
FundingCycleMetadata calldata _metadata,
PayoutMod[] memory _payoutMods,
TicketMod[] memory _ticketMods

struct PayoutMod {
bool preferUnstaked;
uint16 percent;
uint48 lockedUntil;
address payable beneficiary;
IModAllocator allocator;
uint56 projectId;

struct TicketMod {
bool preferUnstaked;
uint16 percent;
uint48 lockedUntil;
address payable beneficiary;

Real transaction as example to explain

Check Gnosis safe tx detail here.

What does this tx mean?

  • _projectId: 1 we are configuring the JuiceboxDAO project
  • _properties:
// it's 117453.82 based on 18 decimals
// 0 for ETH, 1 for USD
// funding target: $117,453.82
// funding duration: 14 days
// cycle limit: 0
// discount rate: 10% (based on 1000)
// contract address
// ballot: 3-day delay
  • _metadata:
// reserve rate: 50% (based on 200)
// bonding curve: 95% (based on 200)
// reconfiguration bonding curve: 95%
  • _payoutMod:
// preferUnstaked: false
// percent: 13.4
// lockedUntil: 0
// beneficiary: 0x823b...ADAD (jango.eth)
// allocator: zero address
// only set this if you are paying other projects on Juicebox
// projectId: 0 (not project but address outside Juicebox ecosystem)
// other payout mod
// ...
  • _ticketMods:
// preferUnstaked: false
// percent: 1.92%
// lockedUtil: 0
// beneficiary: 0x823b...ADAD (jango.eth)
// other ticket mod
// ...