xrpl-price-persist-oracle-sam
A Serverless Application Model stack that persists the $XRP price to the XRPL every minute as a TrustLine. There are no servers, it is effectively a "smart contract" in Python for the XRPL.
This is a XRPL Oracle that publishes external data into the XRPL.
This Oracle was inspired by
XRPL-Labs/XRPL-Persist-Price-Oracle.
Also see the DEV post.
This Oracle is coded in python and built as a Serverless Application Model (SAM).
Deploying to your AWS account
To deploy to your AWS Account use the aws-sam-cli.
If you don't have aws-sam-cli installed, you can grab it from pip or follow the
installation documentation.
pip install -U aws-sam-cli
After installing aws-sam-cli, you can Build and Deploy.
# zip our function along with it's requirements from requirements.txt
# this also makes a new template pointing at those zips
sam build
# now it's built, you'll be prompted to deploy, do so interactively with:
sam deploy --guided
This will walk you through the deployment of the Oracle, name the stack input
the parameters (the wallet seed parameter is
NoEcho)
You may generate a Testnet wallet at the Testnet faucet: https://xrpl.org/xrp-testnet-faucet.html
Click "Generate Testnet Credentials" and use the Secret as
the input to the WalletSecret parameter.
Besides the one required parameter without a default (the wallet secret seed),
you can accept all the defaults (including the stack name) and you'll be persisting aggregate prices
to the XRPL Testnet. (An example testnet account.)
After deployment, you can tail the logs of the function like, where
my-stack-name is what you chose to name your stack during the --guided
deploy, if you chose the default it's sam-stack:
sam logs --stack-name my-stack-name -n OracleFunction -t
Note on NoEcho Cloudformation Parameter for Wallet Secret Seed
The NoEcho parameter of the wallet secret seed ensures that the parameter may
not be read or may not be logged during any cloudformation events.
The produced resource that !Ref's the parameter in use, the function
with it's environment variable. Be aware that any other user able to access
the AWS account used to stand this stack will be able to read the secret on
the lambda function itself.
If you're in a trusted account, and don't provide access to tools or services
that would have access to these things you'll be fine.
Otherwise, you'll have a couple options:
One option is to encrypt the Lambda environment vars in transit (they're
encrypted at rest by default). This would then require decrypting it in the
function using a KMS call.
(see Securing Environment Variables)
Alternatively you might want to call some key management service / secrets
management service independently.
There is two other AWS services that you could use, for managing encrypted secrets in transit.
One is Simple Systems Manager (ssm, specifically ssm-encrypted
parameter store type).
This includes some additional costs if the function needs to cold start (assuming you're
persisting the client in the outer scope for subsequent executions).
(see Sharing Secrets with AWS Lambda Using AWS Systems Manager Parameter Store)
Another is Secrets Manager aws-secrets-manager, which is also an additional cost.
(see secretsmanager_basics.py)
There are many options! This is just a minimal example :)
