The type of the `ix_data` binding withing the solitaire! macro expansion
is explicitly annotated with its type, which comes from the macro's
pattern binding `$kind`. However, this type annotation is entirely
optional, since `ix_data` is passed in as an argument to `$fn`, whose
type forecs `ix_data` anyway, and rust will happily infer that from the
application. So we remove the explicit annotation which makes the entry
point macro easier to use.
commit-id:d428306c
* ethereum: p2w contract -> p2w emitter, fill in essential envs
Change-Id: I6fa9364a96738d2cc02ec829a31fedba0586d8e8
commit-id:0a56f1f8
* Add p2w-relay, a p2w-sdk integration test
commit-id:6bfab639
* p2w-sdk: Expand README
Change-Id: I17cb547d6aaddc240588923561c26d11a787df2e
commit-id:6ebd6a22
* p2w-sdk: don't build ETH contracts, only the types
Change-Id: I7cbd18328227700635d7688aa24a9671e8919fcd
commit-id:adf079f7
* p2w: configurability and sane envs
commit-id:f10fd90e
* Solitaire: Implement Option<T> support in structs
commit-id:31aa12d6
* bridge/governance.rs: Stop pestering about EMITTER_ADDRESS
commit-id:d5bd7234
* p2w-attest: price batching
This commit introduces support for multiple Pyth product/price pairs
per call. The initial maximum batch size is 5 and is enforced using a
`P2W_MAX_BATCH_SIZE` constant.
solana/pyth2wormhole/program:
* On-chain batching logic
* Batch message parsing logic
solana/pyth2wormhole/client:
* Off-chain batching logic - divides any number of symbols into
largest possible batches
* Use a multi-symbol config file instead of CLI arguments
third_party/pyth/p2w-sdk:
* Expose batch parsing logic
third_party/pyth/p2w-relay:
* Comment out target chain calls until ETH contract supports batching
* Test the batch parsing function
third_party/pyth/p2w_autoattest.py:
* Generate and use the symbol config file with pyth2wormhole-client
third_party/pyth/pyth_publisher.py:
* Add a configurable number of mock Pyth symbols
* Adjust HTTP endpoint for multiple symbols
commit-id:73787a61
* p2w-attest: mention attestation size in batch
This commit ensures that no matter the attestation format, a batch
will never contain attestations of different sizes. This guarantee
enables forward compatibility by adding new constant-size fields at
the end of a batch at all times. An older implementation will simply
not consume the remaining newer values while respecting the stated
batch member alignment.
commit-id:210da230
* pyth2wormhole-client: use fresh blockhashes, harden batch errors
This commit makes sure we don't have to deal with expired transactions
due to stale blockhashes. The problem existed with larger symbol
configs as well as on Solana mainnet. Additionally, the attestation logic
now treats transaction errors as non-critical - a failure for a batch
does not prevent attestation attempts for batches farther in the queue
commit-id:5e704f8b
The current lifetimes 'a/'b restrict the &data and &program_id lifetimes which makes the
entrypoint unusable in solana_test_program's processor!() harness, which expects the more
relaxed (but equivelent for us) type of:
fn processor<'a, 'b: 'a, 'c, 'd>(
program_id: &'c Pubkey,
accounts: &'a [AccountInfo<'b>],
data: &'d [u8]
)
It has no effect on our current programs.
Change-Id: Ia657462141165064c629fdff02b5ec451aab50f0
This commit takes the selected Pyth Price struct account and after
serialization places them inside a PostMessage cross-program
call to Wormhole.
Change-Id: If04123705290f4749de318c0dfaa8f1d840ed349
This fixes issues in places where an account is passed in multiple times both readable and writable
Change-Id: I9e75c6c273b894bf113c8d652a7dd7dcfa32b863
It would seem that Borsh, when deserializing an enum will consume a
large amount of stack space proportional to the number of discriminants.
This causes the entrypoint to trigger stack frame access violations
during the initial deserialization.
This change uses an enum represented by a u8 instead, and removes the
association between the discriminant and the data. Deserializing the
associated data is now pushed down to within the entrypoint match arms
instead.
Change-Id: I2dcb466bf7820b3344e175ad92988bb89f30cb15
This allows requesting attestations for various commitment/confirmation levels. This is helpful for low-latency applications like Pyth.
Change-Id: Ib49ace163365106b227613d2f66b787b3e5f5461
Revert submission 693
Reason for revert: Moving away from CPI abstraction
Reverted Changes:
I8c252e137:bridge, token_bridge: Use Many<T>
I6a721e8a8:Solitaire: Add an explicit Many<T> type for nested...
Ibdc94b4c6:Solitaire: Serialize CPI accounts as an AccountMet...
Iefa59f5d4:Solitaire: Extend Peel to support CPI re-wrapping
Change-Id: Iab567aea6dca5be1a7bf7efd4b86e0be05d2753c
Revert submission 693
Reason for revert: Moving away from CPI abstraction
Reverted Changes:
I8c252e137:bridge, token_bridge: Use Many<T>
I6a721e8a8:Solitaire: Add an explicit Many<T> type for nested...
Ibdc94b4c6:Solitaire: Serialize CPI accounts as an AccountMet...
Iefa59f5d4:Solitaire: Extend Peel to support CPI re-wrapping
Change-Id: I01733d16862aeac79ad76dff4f58386641488b3e
Revert submission 693
Reason for revert: Moving away from CPI abstraction
Reverted Changes:
I8c252e137:bridge, token_bridge: Use Many<T>
I6a721e8a8:Solitaire: Add an explicit Many<T> type for nested...
Ibdc94b4c6:Solitaire: Serialize CPI accounts as an AccountMet...
Iefa59f5d4:Solitaire: Extend Peel to support CPI re-wrapping
Change-Id: I4455479e4a19007893d4cdaac06eece70abfa797
This will make is easier to separate modules and solitaire in the future.
We also get rid of the old bridge code.
Change-Id: I4d663c36739dfec77cd5d3f1ed6b51f422fe0c91
Csongor Kiss
Stanisław Drozd
Hendrik Hofstadt
Reisen
Reisen
Stanislaw Drozd