Amplifier onboarding feedback

[StephenFluin]

• intro. needs more work to read better. generic abstract description of amplifier should end with something like: “a simple instantiation of Amplifier is to connect your own chain” … diagram for GMP is irrelevant there [it’s low resolution and quality]. developers don’t care whether the connection is Amplifier or not. Their API remains the same.
• Integrate a chain: we should start with some type of description / flow diagram of what a dev needs to do. [evm] -> instantiate contracts -> get approval from governance, [non-evm] -> pick a validation logic -> build contracts + relayers -> test/audit -> get review of the committee -> get approval from governance. [i’m skipping steps, but the flow needs to be clear].
• what does it mean to use existing contracts? for EVM chains? need to describe when developers should choose it. hide these code IDs ?
• formatting issues.
• missing governance / rewards sections.
• every new chain needs a verifier -> we’re re-using the initial verifier set. so chain just need to put rewards + convince enough verifiers to use their chain. only subsequently we’ll work on making it easy to reinstantiate the service to add more of your own verifiers.
• GMP example. not clear what the goal is. app devs don’t care. so is this for integrators to test their flows? is this towards a formal spec for writing relayers?
• Amplifier API docs? we don’t have anything that actually describes how to build a relayer.
• I find it confusing that most pages/sections don’t have context on the goals / audience.

[StephenFluin]

Bunch of PRs submitted to improve these points.

Regarding the open ones:

• @sergeynog can you clarify the formatting issues you are referring to?
• @canhtrinh can you share what rewards that are confirmed publicly for verifiers? I've seen the Amplifier Rewards spec from January but I don't know the status, finality
• Every new chain on the devnet needs a verifier. It doesn't make sense for integrators to onboard external verifiers on the devnet, but this is definitely a step they'll need to do to go to testnet/mainnet (cc @ffe9f8 to add)
• Re: relayer API, added content on the steps for this in the architecture overview using the axelar-examples broadcast tool which we want people to use rather than submitting their own transactions via the gateway, but we need a true end to end example (cc @benjamin852 or @Olanetsoft ?)
• RE GMP page: my take is this is helpful if you want to manually push through transactions on the devnet during integration, but won't be part of the real docs long term, as you should be using our relayer infra. Is that right @canhtrinh ?