Captain McAteer pfp
Captain McAteer
@firn
i realized here people actually read what I write. just to explain what I'm working on: Firn is a privacy service which evades certain inefficiencies our competitors (read: Aztec) face. it's able to do this because it uses completely different cryptography (it's account-based privacy, instead of UTXO-based privacy).
2 replies
0 recast
1 reaction

✳️ dcposch on daimo pfp
✳️ dcposch on daimo
@dcposch.eth
is https://github.com/firnprotocol/snap intentionally private?
1 reply
0 recast
0 reaction

Captain McAteer pfp
Captain McAteer
@firn
correct, this is intentional (for now). but linking to a private repo was not 😀sorry about this. can you tell me where it is linked to?
1 reply
0 recast
0 reaction

✳️ dcposch on daimo pfp
✳️ dcposch on daimo
@dcposch.eth
do you have audits on any of the contracts? private payments is one of the highest-trust use cases there is. how did you build confidence that your frontend, contracts, and zk circuits are correct?
1 reply
0 recast
0 reaction

Captain McAteer pfp
Captain McAteer
@firn
it's a multi-step answer. first, the vast majority of the criticality resides in the contracts, rather than the front-end, since (most) contract bugs lead to loss of funds, while (most) front-end bugs lead only to temporary inaccessibility of funds.
1 reply
0 recast
0 reaction

Captain McAteer pfp
Captain McAteer
@firn
secondly, Firn actually doesn't use "circuits" in the sense of TCash, Aztec, etc., (those protocols break the cryptography into a "circuits" and a backend "prover"). Firn uses hand-designed zero-knowledge proofs, constructed specifically for its purposes. so these can/should be verified directly in the contracts.
1 reply
0 recast
1 reaction