### Q1:
We had a few more questions left which we'd be keen to get your thoughts on, obviously also understand it's a lot of work to answer in depth so definitely don't stress about it if you're short on time!

> - For the universal verifier, how many different schemes do you expect to eventually support and what will you base the decision to (not) support on?
>
> So the ultimate goal is to build a proof aggregation VM, this VM consists:
> - cryptographic functions, such as ECC, Hash, etc as circuit
> - a memory arugment like TinyRAM to glue these functions
> - a simple DSL to express verification protocol
>
> Adding a new protocol, or a new "configuration" of the existing protocol, e.g. a newer version of plonk, would be extremely "simple", we don't need to write the new circuit, we just need to write a new DSL verifier program.
>
> We need to add cryptography primitives as cryptography evolves. For example, we need to add LWE or other post quantum primitive as new VM component if that becomes the choices of the newer proof systems. This would be quite infrenquent.
>
> The overall design philosophy is modularity in terms of universal verifier design.

### Q2
You mentioned wanting to lower DA cost, how do you view the security risks associated with certain alternative, cheaper DA layers and how important would a blobstream-like setup be to ensure that this works as intended?

> Our current plan is to make the DA part modular, in the sense that people can choose
> - using Ethereum Blobs after 4844
> - using Celestia/EigenDA/Avail
> - using NEBRA centralized DAC (We get a lot of demand on this, many cutsomers simply don't need censorship resistance)

### Q3
- Do you expect to see chains start to cater to verification (e.g. new curve support, changing gas limits?)

> This is going to happen, however, this will cause a lot of DX issues, even change the gas limits will hurt the compatibility with Ethereum L1. We don't expect this going to happen anytime soon.

### Q4
- 2 Supermajority epochs on Ethereum to wait for finality post ZKP verification, e.g. what some ZK apps/rollups do at this point?

> We are working on NEBRA's re-org proof design now, we have a initial design, can declose that soon. (is that the question you ask?)

### Q5
- In the HackMD writing you mention that you see your idea of 'universal' proof aggregation is the only way forward, but couldn't this approach also lead to a high likelihood of commoditization of the entire stack?

> Could be! I think we just need to become the tech. to be commoditized :)

### Q6
- Follow on to the previous question, how dependent are the scale effects you're hoping to reach on non-crypto zk applications getting traction, and how likely is it that competitors could undercut your scale effects by aggressively incentivizing behaviour (in essence again making proof aggregation more commoditized)?

> I think we will pull up a token based incentive design if a competitor vampire attack us. We have a staked decentralized prover design that can greatly improve both liveness and efficiency of the protocol. We will move to decentralized prover eventually so doing our own incentive is not a problem for us. We might be able to innovate on that regards as well.

### Q7
- Who are you talking to or looking to work with for potential hardware accel for the lower latency second gen protocol, and what percentage of use cases such as zkDID do you think you can facilitiate with the current 'high' latency protocol?

NEBRA will put a small check on Fabric's series A round to make sure we can get access to their chip when tapping out. I am a small angel investor for Cysic. We are closely in touch with Supranational as well.