10ProtocolContracts and governance
No single key changes the rules.
Five contracts, a 2-of-3 council and a timelock on every admin change.
dvdnd is five Soroban contracts written in Rust, one share token per company and Circle USDC. Testnet deployments:
| Contract | Role | Address |
|---|---|---|
registry | Companies, statuses, agreement hashes, payout share and schedule. | CCL5…Y2TZ ↗ |
gate | Credential Merkle tree (Poseidon) and Groth16 verification of residence proofs. | CBPU…DB7N ↗ |
offering | Raises, escrow, per-raise terms, eligibility, minting and holder authorization. | CCJC…SX5P ↗ |
vault | Locks and pro-rata USDC dividends per share token. | CDU5…OHKM ↗ |
timelock | Admin of registry and offering; delays every admin change. | CCHX…GCGZ ↗ |
council | 2-of-3 multisig account, master key disabled; the timelock's proposer. | GAS3…ZWVV ↗ |
Who can change what
- The council, a 2-of-3 multisig, can suspend companies and set the listing fee, but only through the timelock.
- The platform key verifies companies after the ownership check and issues credentials after an identity check. It can't move money or tokens.
- Each raise's compliance account acts on that raise's holders, with a recorded reason.
- Nobody can withdraw escrow, mint more tokens after a raise, or take dividends from the vault.
The timelock
The registry and offering contracts take the timelock as their admin. The council schedules a call (a target contract, a function and its arguments); after the delay anyone can execute it; until then the council can cancel it. Holders and companies see every pending admin change on-chain before it takes effect. Changing the delay or the proposer is itself a scheduled call, so it waits out the current delay too.
On-chain
- A call's id is the sha256 of its target, function and arguments, independent of time, so the transaction footprint is known when it is scheduled.
- The delay is 10 minutes on testnet, for demos. Production would use days.
- The council signs with
council-invoke.sh: build, simulate, collect two signatures, send.
Legal
- No single key, including dvdnd's, can change the rules of a live raise.
- A visible delay before admin changes is what investors would expect from a transfer agent or a fund administrator.
Stellar features doing the work
| BN254 host functions | Groth16 verification in the gate: g1_msm and one pairing_check. |
| Poseidon host function | The credential tree and the address binding, matching circomlib's Poseidon. |
| Asset authorization flags | Only authorized wallets can hold a share token; clawback for court orders. |
| Stellar Asset Contract | The offering is the SAC admin: it mints exactly what was sold and authorizes holders. |
| SDEX and path payments | Secondary trading and XLM → USDC in one operation. |
| SEP-10, SEP-24, SEP-1 | Anchor sign-in and bank transfers; a stellar.toml generated from the chain. |