Trust Model

SyncVotes is not trustless. You rely on the app, and on whoever runs it, for some things and not for others. This page lists both, so you can decide what to use it for and which rules to choose.

Who Is Involved

Who	What they hold
You	Your key. Nothing is done as your party without its signature.
The app's provider party	Co-signs every contract you act on: accounts, DAOs, members, proposals, ballots, comments and profiles. It counts ballots, executes what passed, and keeps the balance records.
The app's validator	Hosts your party with confirmation rights and stores every contract of every DAO in the app.
The Canton Network	Orders transactions and runs the Daml model, which checks every step.

The provider party signing every contract is what makes the provider confirm every transaction, which is how a featured app earns app rewards. It is also what lets it count and execute.

What the App Cannot Do

• Act as you. It cannot vote, propose, comment, create a DAO or set a profile in your name. Each of those needs your key's signature, and the app's ledger user has no right to act as your party.
• Forge or alter a ballot. A ballot carries your signature, and the ledger checks every ballot it is handed.
• Count a ballot the ledger refuses: one cast late, by a non-member, by a member who joined or changed units after the proposal was made, or counted before.
• Change a DAO by hand. It can only execute a proposal that passed, and only the change that proposal carries.
• Invent a member or a proposal. Members need the DAO creator's signature as well as the provider's, and a proposal needs its proposer's.
• Pass a decision or a change to the DAO measured against the whole vote by leaving ballots out. Leaving ballots out only lowers the yes count against a fixed total.

What the App Can Do

• See everything. It reads every DAO, public or private, and every ballot, including secret ones. To keep your DAOs from us, host SyncVotes on your own validator: Self-Hosting.
• Delay. It chooses when to count and when to execute. It can hold a result back, or not execute a change that passed.
• Refuse service. It can refuse to prepare your transactions. If the validator is down, nothing of yours moves.
• Make a proposal fail by leaving yes ballots out of the count.
• Flip a result either way where the rule counts votes cast, by leaving out the ballots that go against the result it wants.
• Make a quorum fail by leaving out enough ballots, whatever the basis.
• Break a tie on a choice with one pick, by leaving out ballots for one of the tied options.
• Pick the runner-up on a choice with one pick whose rule is half or less: two options can both reach the rule, and the one with more votes wins, so leaving out the leader's ballots makes the other one chosen.
• Change a DAO without a vote, together with its creator. The DAO and its memberships carry the creator's signature and the provider's. Neither can change them alone, but the two acting together could.
• Skip a member in a membership change. When it executes a Members or Shares change, it hands the ledger the affected members' contracts. If it leaves one out, a removal is skipped, or a member ends up with a second membership and a second vote. The ledger cannot tell a missing membership from a withheld one, but either shows on the ledger: two memberships for one party, or one that should be gone.
• Write the balances. The records of what was topped up and spent are signed by the provider alone.
• Lose the data. Every contract of every DAO is stored on the app's validator, because it hosts every party involved. If that validator's data is lost or wiped, the DAOs go with it.

The Final Count

The ledger checks every ballot the app hands in, but it cannot see ballots the app did not hand in. When the app says that the last batch after the deadline is final, the ledger takes its word and decides the proposal. This is the one statement the ledger accepts from the app unchecked. Together with the app choosing which ballots to hand in, it is where the limits above come from.

Verification in Your Browser

Your browser checks every transaction before your key signs it. It recomputes the hash, and it refuses anything that does not act as you alone, is not one of the five actions you can take, uses another Daml package, targets another contract, or carries other arguments than the page built. At sign-up, it checks that your key is the only key that can sign for your party and that the validator gets confirmation rights only. See Keys and Parties.

These checks run in code the site serves you. To trust them, you trust that the site serves the published code.

Open Source and What Runs

The code is on GitHub, including the Daml model that the ledger enforces. Each site answers at /version (the Build link in the footer) with two lines:

• commit: the commit the site was built from. A site only runs committed code.
• package: the name and ID of the Daml package the app uploaded to its validator. The ID is what the validator knows the code by, so it can be matched against a build of that commit.