Kevin Heavey

@enzoampil how should types with the same name be handled? Perhaps I am misunderstanding but I don't see what we can do with duplicate types

@enzoampil just checking in here

@enzoampil can you share the IDL? I'm still not sure how an IDL with duplicate types makes sense

Hey didn't see this until now! I'll ask around if there are good ways to publish multiple versions of the library with different features activated in the underlying Rust library

@WhatsWithAlex @QuanticCapital are you saying that one needs to specify the `fee_payer` of a Transaction or it doesn't work? Like should we just require that transasctions have a `fee_payer`?

@dustiwe can you try base64 decoding that data, then doing `my_keypair.sign(decoded)`?

Closed as inactive

I think this comes from the `.instructions` setter using the `self.fee_payer` property which assumes that the first account is the fee payer. After adding the first instruction, `self.fee_payer` is the...

I think the solution here is to require `fee_payer` when initializing a Transaction instead of making it optional. This is a breaking change though. Thoughts?

@benedictbrady for now if you pass the `fee_payer` arg when initializing `Transaction` it should work. Also if you're building complicated Transactions it's probably simpler to just use Solders directly as...