BernuviaBernuvia
Contents

Security and governance

Who rules the contracts that hold the money, what takes two signatures, what waits 48 hours and what the administration cannot do.

Who governs the contracts

Bernuvia's two contracts on Polygon, the escrow for purchases and the membership billing, are administered by a 2 of 3 multisig wallet: 0x87b6E96a3f64e01a9523ea5C5FCef9008800bfAc. Nothing leaves it on a single signature.

  • The same multisig resolves disputes, can pause the contracts and receives the fee.
  • The only separate role is the operator that charges the seller membership, and it can only charge within the cap the seller signed and always to the treasury.
  • The holders of every role are public: you read them on the explorer, at those same addresses.

The contract addresses, with links to their verified code on Polygonscan, are on Security and transparency.

What takes two signatures

Anything that can change the rules or move treasury money goes through the multisig. With two signatures out of three:

  • Resolving a dispute, that is, setting the split between buyer and seller.
  • Extending a dispute by 30 days, once only.
  • Pausing and unpausing the contracts.
  • Proposing and applying a treasury or fee change.
  • Granting or revoking any role.

The waiting periods

Two changes cannot be applied in the same block in which they are proposed:

  • The treasury (where the fee goes) and the fee percentage are proposed and then wait 48 hours before they can be applied.
  • The proposal is visible to anyone while it waits, expires after 7 days if nobody applies it, and can be cancelled.
  • The admin handover is a two step process with a 3 day delay, so a typo cannot leave the contract in the wrong hands.
  • The admin cannot renounce the role: the contract cannot be left without governance.

The fee on your purchase does not change halfway: it travels signed in the quote, order by order. Today it is 3.8%.

What the administration cannot do

These are not commitments of ours: they are limits written into the contract, and you check them by reading the verified code.

  • Send the money of a purchase somewhere else. It can only go to the seller, minus the fee, or back to the buyer.
  • Sweep the money. There is no rescue function over the principal, and any excess can only go to the treasury.
  • Block your payouts. Each party withdraws what is theirs whenever they want, and one blocked address does not block the rest.
  • Open or withdraw a dispute for you. The dispute belongs to the buyer alone.
  • Take a fee out of your share in a dispute. The fee never comes out of the buyer's refund, and it is zero if the refund is full.

Off chain it does not sign for you either: paying and withdrawing take your signature, and a withdrawal also takes a code sent to your email. The detail is in Account and wallet.

The audit, and its scope

The escrow contract went through an internal adversarial audit before going to mainnet, and a second internal review in September 2026, with the contracts already in production. That second one produced version 2, which is the one holding the money today.

  • July 2026: three adversarial reviews with different lenses (funds and reentrancy; access control and signatures; state machine), static analysis and a Hardhat test suite.
  • September 2026: twelve independent lenses across four rounds on the deployed contracts, with conservation invariants checked over 1,600 random operations and 662 test cases.
  • Before deploying version 2: three more adversarial lenses over its code, with the proofs of concept turned into regressions, so that if someone undoes a fix the suite turns red.
  • The high finding from September, that whoever opened a dispute could void an already approved resolution, is closed in version 2: the dispute belongs to the buyer alone, withdrawing it does not renew the deadline, and reopening only works while the original deadline is still alive.

The scope is worth saying plainly: these are internal reviews of the two contracts and their integration. There has been no independent external audit.

How to report a flaw

If you find a security flaw, we want to know before anyone else.

  1. 1Write to us through the contact form with "Security" in the subject: what you found, how to reproduce it and what impact it has.
  2. 2If you have an account, the Report a bug button in your dashboard reaches the same team and stays tied to you.
  3. 3We confirm receipt and tell you when it is fixed.

We ask you not to publish it until then. If yours is a problem with a specific purchase, this is not the route: open a dispute.

Next

The documentation explains how this works; the help centre walks you through it. Go to the help centre.