M-of-N on DogeOS
Attesters & co-signers
Who signs a mint: DogeSoftBridge threshold 2 of 3 on DogeOS. Attester changes are timelocked.
A mint is an L2 mintFromL1Tx signed by registered attesters.
Doge Soft's bridge service runs one of the registered attester keys; see the current model below.
The user signs the L1 lock and the L2 burn. They do not sign the mint.
Threshold is 2 of 3. attesterThreshold() on DogeSoftBridge 2.6.0-ds-standard 0x762d952DDc9bbF11b8442347D2D1B66934703036 on DogeOS Chikyū testnet (chain id 6281971) returns 2. Registered attesters are 0xBD167EA0e54833117732e4FE1EC99e632F033dF5, 0x4aa6Fb82fc0a30117Db2d384D247268F7aB4437a, and 0xd4Cf42Fc283974FDA7d869ebee7F86d8f060D02b. One signature is not enough. Attester changes are timelocked.
Plain English
- User locks DRC-20 on Dogecoin L1.
- Each attester independently checks: “This txid:vout is real, confirmed, correct tick/amount, paid to custodian.”
- Each attester signs the mint message with their own key.
- The DogeSoftBridge contract on the destination chain counts signatures. If count ≥ threshold → mint. Otherwise → reject.
The on-chain threshold is 2, so one signature is not enough. Attester changes are timelocked.
Where signing happens
| Layer | Role |
|---|---|
| Dogecoin L1 | Real coins locked; no smart contract — only UTXOs and OP_RETURN |
| Off-chain verification | Core RPC + DogeSoft indexer build the mint digest (evidence hashes) |
| Destination L2 | DogeSoftBridge on DogeOS stores attester addresses, threshold, and enforces mintFromL1Tx |
Attester set & DogeOS co-signers
Attesters are registered Ethereum addresses on the bridge contract (isAttester).
The threshold (attesterThreshold) is public on-chain.
Current model:
- Doge Soft server signer — runs Core + indexer verification, signs with operator-controlled key.
- Ecosystem co-attesters (partners) — separate organizations with their own attester keys and their own Core + Doge Soft Inscription Standard verification before signing.
Partnership integration includes a co-attester slot on the DogeOS bridge contract. Plain requirements:
- Attester keys are separate — each partner holds and uses their own signing key.
- Verification is Core + Inscription Standard — not “trust DogeSoft’s API response.”
- A co-attester must be able to re-check the L1 outpoint themselves (own Dogecoin Core + own Doge Soft Inscription Standard parse) and refuse to sign if tick, amount, owner, custodian output, or confirmations do not match.
- Re-reading only the DogeSoft indexer API is not independent verification — that is a second signature on one truth source.
We do not pretend a second full wallet / explorer / AMM / oracle stack already exists. The co-attester requirement is: Core + Doge Soft Inscription Standard parser + own key + right to refuse on divergence.
Honest disclosure: Multiple signatures over a shared verification pipeline is weaker than each attester running fully isolated infrastructure. The partnership program exists to add independent operators and keys — not to pretend competing indexers already exist for Doginals/DRC-20 production.
What each attester checks before signing
- L1 transaction exists on Core and meets
l1ConfirmationsRequired. - The DRC-20 transfer to custody
D9K5fqJ6vhs3FfUgiEn69SYZJQQvtsB2SucarriesBRIDGE_L1_DEPOSITand a ref whose signed record matches the recipient and nonce. - The indexer confirms the sender held the DU$T before sending.
- Tick and amount match the bridge session and indexed DRC-20 state.
- The ref has not been used before (refs are single-use).
- Reserve attestation is fresh (under 7 days) and the mint stays under the 1,000,000 DU$T cap.
Partner / embed program
Integrators who embed DogeSoft Bridge or route volume through DogeOS can apply for:
- Registered co-attester address on the bridge contract.
- Reference attester implementation (verify Core + Doge Soft Inscription Standard, sign digest — not indexer-API-only).
- Published ABIs and verify playbook (Transparency).
Contact: dogesoft.io — partnerships / builders channel.