FLIP 321: Redundancy Improvement - update service account signers

[laynelafrance]

FLIP PR: #325
The following content 👇 was copied into a FLIP file

---

status: draft
flip: 321
authors: Layne Lafrance
sponsor: Vishal Changrani
updated: 2025-03-19

FLIP 321: Update service account signers

Objective

The service account would benefit from additional redundancy. In order to achieve that redundancy the governance committee would like to add me as an additional external signer. This involves removing my keys from the existing setup and adding a new key to the service account. This will ensure more signers are available to review and sign for service account multi-sig operations.

Motivation

Redundancy in decentralized systems is a critical component of providing reliable security and service even in times of potential network degradation. This change will improve signer redundancy.

Users will not be impacted by this change. It will potentially speed up future service account signings to have more signers available.

User Benefit

The entire Flow ecosystem benefits from reliable, timely governance. The more the governance committee can do to keep things running smoothly and on-schedule - via more signers available to sign key changes at the right time - the easier things run overall.

This would also represent further community representation in Flow's governance structures.

Design Proposal

Transaction to Add New Key (+ revoke old)

https://github.com/onflow/flow-core-contracts/blob/master/transactions/accounts/add_key.cdc

https://github.com/onflow/flow-core-contracts/blob/master/transactions/accounts/revoke_key.cdc

Drawbacks

None - Because multiple signers already provide redundancy on my existing key, the addition of this new key only makes more signers available to us with no additional costs or changes to the existing setup.

Alternatives Considered

Any other community members who feel strongly about Flow's governance and have an observable track record contributing to the ecosystem should also be considered as additional signers.

Performance Implications

This change will not impact protocol performance.
The only measurable improvement would be reduced time to compete multi-signer signings when required.

Dependencies

• Dependencies: does this proposal add any new dependencies to Flow?

No

• Dependent projects: are there other areas of Flow or things that use Flow
  (Access API, Wallets, SDKs, etc.) that this affects?

Service Account

• How have you identified these dependencies and are you sure they are complete?
  If there are dependencies, how are you managing those changes?

@vishalchangrani will be verifying with SRE to confirm no other dependencies exist for the existing keys to be removed.

Engineering Impact

• Do you expect changes to binary size / build time / test times?

No

• Who will maintain this code? Is this code in its own buildable unit?
  Can this code be tested in its own?

The transaction to revoke key has been tested.
Revoking a key on the service account has been successfully done in the past.

• Is visibility suitably restricted to only a small API surface for others to use?

No - the change here is to the service account and will be visible to all users.

Best Practices

• Does this proposal change best practices for some aspect of using/developing Flow?
  How will these changes be communicated/enforced?

N/A

Tutorials and Examples

N/A

Compatibility

• Does the design conform to the backwards & forwards compatibility requirements?

Yes

• How will this proposal interact with other parts of the Flow Ecosystem?
  • How will it work with FCL?
  • How will it work with the Emulator?
  • How will it work with existing Flow SDKs?

This proposal will not change how these services interact with the service account.

User Impact

• What are the user-facing changes? How will this feature be rolled out?

None

Related Issues

• What related issues do you consider out of scope for this proposal, but could be addressed independently in the future?

Adding more signers to the service account which is always an option and something that should be considered following consistent contributions from community members.

Prior Art

#312
#310

Questions and Discussion

Please bring any questions / concerns to this issue

[bluesign]

I am against this.

I don't understand this proposal, you already have a key shared with Vishal no ?

I think @austinkline from flowty already suggested for this slot with community support. ( especially from me and @bjartek )

In order to achieve that redundancy the governance committee would like to add me as an additional external signer.

who is this so called "governance committee" ? they can come here and comment, so I can say what is on my mind to your faces.

[bjartek]

Currently the foundation has 3 keys. If we add a fourth under that single organization they can in principle sign whatever they want. This is a bad idea for governance.

[bluesign]

yeah this is good opportunity maybe foundation to revoke one more key to have 2 keys, and we give that one to some community contributor. it is obvious from this FLIP they don't know what they are doing.

[joshuahannan]

I think an important thing to understand is that Layne has not been an employee of the foundation for a while now, so technically she is an independent community member.

[bluesign]

I think an important thing to understand is that Layne has not been an employee of the foundation for a while now, so technically she is an independent community member.

@joshuahannan do you know this people from "governance committee" ? I think it is a bit more important than Layne being employee or not of foundation, some "foundation governance committee" is suggesting her here

[laynelafrance]

the governance committee is a term @vishalchangrani introduced and I believe refers to the existing signers responsible for signing multi-sig operations on the service account - identified here: https://github.com/onflow/service-account
it includes you @bluesign but @vishalchangrani and I first discussed the issue as it specifically relates to how he and I sign. We planned to discuss again with all of you in the next muti-sig call: March 25 8am PT

this was suggested because on a number of occasions myself, those who had access to sign with my key, and only one or two others were available to sign. The signing was stalled because even though enough people were present, we didn't have the signing weight. Signings and core network operations were delayed as a result and we're trying to prevent that.

As initially identified, I'm not opposed to more signers joining but this is not a proposal to add a signing slot, it's a proposal to address an existing problem which is that we have too many individuals on one key and one inactive community signer. By moving my active account into the inactive community slot (Ichi) it would free up my current slot for @vishalchangrani to have his own which, as the primary node upgrade coordinator, is important.

yeah this is good opportunity maybe foundation to revoke one more key to have 2 keys, and we give that one to some community contributor. it is obvious from this FLIP they don't know what they are doing.

Tbh @bluesign this is a pretty disappointing reaction (especially considering this issue is marked as a draft). Feel free to reach out with specific concerns but if you're suggesting this is a scheme to reduce community involvement, it is completely the contrary - see further below

I think an important thing to understand is that Layne has not been an employee of the foundation for a while now, so technically she is an independent community member.

Thank you for adding this @joshuahannan. Indeed, I am not and have not been employed by DLI nor the Flow Foundation since May 2024 with the sole intention and purpose of being independent to advocate for what I think the ecosystem needs, beyond the focus of major groups like DLI and the Flow Foundation.

[bluesign]

We can discuss on next call for sure but I see 2 issues ( maybe a misunderstanding on how signing works )

Service account has absolute power. I think signing power majority collected on community signers is an important concept.

Currently it is set up as foundation needs at least one independent community member ( which is a very low threshold tbh )

3 foundation, 4 community signer has a very sweet balance hanging barely. I would love 2 foundation 5 community ( but it is not practical to organize people )

I agree that inactive signer is bad; and we with @bjartek suggested to change/add active community members as I mentioned above.

Btw I think it is important to add people with community involvement, as those signing events are not just symbolic rubber stamps.

First of all I am happy that you want to be in the community side @laynelafrance we need more people involved with community proposals, discord and forums.

Maybe I overreacted a bit, but I checked your github profile was in @dapperlabs org, then I checked multisign calendar events, your email is : dapperlabs.com obviously I thought you are still working or somehow related to dapper. ( Walks like a duck, quacks like a duck )

Also our only interaction as community for a long time being this FLIP (personally) didn't help a lot.

But I am sorry if my reaction was too harsh, we europeans have direct approach like this, I know sometimes it can be received wrong.

[laynelafrance]

Summarizing the discussion we had around the above comments on this/last week's signing calls:

• The current signer setup of only one independent community member is the absolute minimum and we'd like to see more community approval required (FLIP coming for adding another signing seat)
• We are all in agreement that inactive signers are bad for the network and operations
• Signers should have active involvement in the community

@dzn It's understandable confusion because my dapperlabs account is still used for many legacy things like this which is why it's important we transition it off

For some visibility on work I've been doing outside of Dapper Labs + Flow Foundation here is the (not yet publicized/broadly shared) pilot of the podcast we've been recording: https://www.youtube.com/@finding-flow-state

Feedback welcome - it specifically aims to discuss the why of building in web3 and what broad social problems the tech can address. The upcoming episodes will be more application oriented so stayed tune for pitches we'll share there.